In contrast to my original intention, I have decided not to just offer some hints about multicast architecture, but also to offer a quick qualitative introduction to UNIX multicast issues, routing, MBONE tunneling, and multicast-monitoring and -debugging techniques. I hope this provides just enough of a teaser to put things into perspective and to encourage you to play with intradomain multicast issues and eventually create enough interest that you seek out additional interdomain details. Three example applications are used to demonstrate multicasting:
nte (a network text editor)
ntpd (Network Time Protocol) in multicast mode
mtest (send and receive)
Multicast Deployments
Multicast is one-to-many (1:n) or many-to-many (n:m) source-to-sink data delivery for multicast applications over multicast-enabled transport networks and data link layers. The most obvious reason for multicast deployments is bandwidth and server resource conservation with regard to efficient content distribution. That can be summarized as efficient and scalable multicasting, instead of costly unicast services, by simultaneously delivering a single stream of information to thousands of subscribers or recipients.
This potential is especially interesting as an additional mechanism in modern converged networks with regard to videoconferencing, video on demand, Internet audio, interactive gaming, multimedia events, e-learning software distribution, newscasts, and content delivery. Converged networks transport voice, video, data, and storage traffic over multipurpose IP networks. This variety of applications spans multimedia and data-only uses with or without real-time (latency, jitter) and high-availability requirements. The following discussion separates multicasting into data link layer, network layer, and application layer multicasting. Because of its intrinsically connectionless mode of operation, multicast uses User Datagram Protocol (UDP) as its transport protocol. Occasionally, raw IP sockets are used. These are exceptions to the common UDP rule.
Multicasting essentially can be seen from both intradomain and interdomain points of view, similar to intra-and interdomain traditional unicast routing. An in-depth discussion of multiprotocol (multicast) BGP used for interdomain signaling goes beyond the scope of this book. Note that we have to abandon a client/server perception when discussing multicasting and think instead in terms of content sources, transport networks, and sinks. Another important aspect is the distribution of multicast sinks (group subscribers), which can be either dense or sparse. Some algorithms have proven more suitable for the former, and some others for the latter. As a rule of thumb, dense distributions correlate with LANs or small campus networks, whereas metropolitan networks or the global Internet show a sparse distribution of multicast participants. The purpose of multicast signaling protocols is to build efficient multicast distribution trees for each multicast group of subscribers and not to burden routers and links with group traffic when no associated recipients exist. The process of adding and removing branches to this tree is referred to as grafting and pruning.
Multicasting is easy to configure, but its foundation is quite complex, especially the interface between intra and interdomain multicasting. Therefore, I recommend extensive research before deploying multicast architectures.
NOTE
Currently we face a "hen and egg" problem: Internet service providers (ISPs) complain about the lack of multicast applications to make multicast service offerings commercially feasible, and application developers counter with the lack of multicast-enabled autonomous systems and interdomain multicast deployments. However, one thing is certain: Conventional unicast streams cause a horrible waste of network and server resources.
Multicast Addresses and Scope
On a single LAN segment, you need to map multicast groups to special MAC addresses for proper delivery to a network interface card (NIC). You accomplish this by mapping the least significant 23 bits of the multicast IP address into the least significant 23 bits of the Ethernet MAC address. In addition, all multicast MAC addresses start with the leading sequence 01:00:5E. For example, the multicast MAC address for RIPv2 routers (224.0.0.9) is represented as 01:00:5E:00:00:09.
Every address in the 224.0.0.0/4 Class D aggregate is referred to as multicast group. This is similar to FF:FF:FF:FF:FF:FF representing a subnet broadcast. This Class D address space is organized as presented in Table 14-1. However, from a modern classless point of view, you should avoid referring to "Class D" addresses.
Table 14-1. Important Multicast Address Ranges Class
Range
Reserved link-local addresses
224.0.0.0/24
Globally scoped addresses
224.0.1.0–238.255.255.255
Source-specific multicast (SSM)
232.0.0.0/8
GLOP addresses
233.0.0.0/8
Limited-scope addresses
239.0.0.0/8
GLOP integrates the autonomous system number (ASN) of a domain into the second and third octet of the 233.x.x.0/8 prefix to accomplish uniqueness for interdomain multicast routing. Relevant additional resources include the following:
RFC 3180/RFC 3138, "GLOP"
RFC 2365, "Administrative Scoped Multicast"
RFC 3171, "IANA Guidelines for IPv4 Multicast Address Assignments"
"Source-Specific Protocol Independent Multicast in 232/8," draft-ietf-mboned-ssm232-06.txt
"IPv4 Multicast Unusable Group And Source Addresses," draft-ietf-mboned-ipv4-mcast-unusable-01.txt
It is particularly interesting to ping the group address 224.0.0.1 (all multicast hosts on this subnet) and 224.0.0.2 (all multicast routers on this subnet) to figure out which hosts are multicast enabled on your LAN or act as multicast routers. For a complete list, see the Internet Assigned Numbers Authority (IANA) Internet multicast address summary at http://www.iana.org/assignments/multicast-addresses.
Some important multicast group addresses of the reserved local control block are printed in Table 14-2. Most likely, you will find a couple of familiar addresses. No multicast router—regardless of its Time To Live (TTL)—should ever forward IP datagrams with these destination addresses. Hence the name local scope.
Table 14-2. Important Reserved Local Multicast Group Addresses (Local Network Control Block, Local Scope Only) Address
Multicast Group Assignment
224.0.0.0
Base address (reserved)
224.0.0.1
All systems on this subnet
224.0.0.2
All routers on this subnet
224.0.0.3
Unassigned
224.0.0.4
DVMRP routers
224.0.0.5
All OSPF routers
224.0.0.6
All OSPF designated routers
224.0.0.7
Internet Stream Protocol V2+ (ST2+) routers
224.0.0.8
Internet Stream Protocol V2+ (ST2+) hosts/agents
224.0.0.9
RIPv2 routers
224.0.0.10
IGRP routers
224.0.0.11
Mobile agents
224.0.0.12
DHCP server/relay agent
224.0.0.13
All PIM routers
224.0.0.18
VRRP
224.0.0.102
HSRP
NOTE
It is necessary to set net.inet.icmp.bmcastecho to 1 on BSD systems for pings to multicast groups to succeed. Either add this entry to /etc/sysctl.conf or set it manually by typing sysctl -w net.inet.icmp.bmcastecho=1.
Administratively Scoped IP Multicast
Scoping is the art of limiting multicast traffic distribution to certain administrative boundaries defined by boundary routers capable of per-interface scoped IP multicast configurations and filters (RFC 2365). Historically, TTL scoping (topological scoping) has been used to control the distribution of multicast traffic, especially within the multicast backbone (MBONE). However, TTL scoping negatively impacts Distance Vector Multicast Routing Protocol (DVMRP) pruning efficiency.
The administratively scoped IPv4 multicast address space is defined as 239.0.0.0/8. Scoped addresses are required to be unique only within administrative boundaries. According to RFC 2365, "The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold."
Cisco boundary filters can be configured with the ip multicast boundary {ACL} interface command. mrouted scope examples are provided with the manual page and default configuration file; the setup is straightforward.
The Multicast Protocol Cocktail
An entire zoo of protocols is related to multicast and can be divided into intra- and interdomain multicast protocols.
The intradomain multicast protocols are as follows:
DVMRP— Distance Vector Multicast Routing Protocol, RFC 1075
PIM-SM/PIM-DM— Protocol Independent Multicast Sparse/Dense Mode, RFC 2362
IGMPv1/v2/v3— Internet Group Management Protocol, RFCs 2236 and 3376
CGMP— Cisco (proprietary) Group Management Protocol
MOSPF— Multicast OSPF, RFCs 1584 and 1585
CBTv2/v3— Core-Based Tree Multicast Protocol, RFC 2189
RGMP— Router-Port Group Management Protocol (IETF draft)
SDP— Session Directory Protocol
PGM— Pragmatic General Multicast, RFC 3208
MLD— Multicast Listener Discovery Protocol, RFC 3590
The interdomain multicast protocols are as follows:
MBGP— Multiprotocol BGP, a.k.a. "Multicast" BGP
MSDP— Multicast Source Discovery Protocol, RFC 3618
BGMP— Border Gateway Multicast Protocol, draft-ietf-bgmp-spec-05.txt
Figure 14-1. Important Multicast LAN Protocols
Although these really are a lot of standards and protocols, do not be intimidated. Although they all serve specific and structured purposes, this chapter deals only with IGMP, DVMRP, and PIM-DM/PIM-SM. These protocols are presented in a LAN context in Figure 14-1
There exists a clear differentiation between multicast signaling information and actual data forwarding (reverse-path forwarding to be precise). Some approaches rely on their own signaling (mrouted), whereas others require additional unicast routing information (for example, PIM). For an excellent introduction to these protocols, consult the Cisco.com article "Configuring IP Multicast Routing."
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
