Chapter 1. Introduction to IP Multicast
There are three data communication methods in IP networks: unicast, broadcast, and multicast. To establish a baseline, it is important to understand the fundamental elements of unicast and broadcast before we explore the details of multicast communication methods.
Unicast communication at Layer 3 (the Network layer) of the Open Systems Interconnect (OSI) model is based on the IP address of the destination device. Routers learn about routes by static or dynamic methods and forward traffic by looking at the destination IP address. Layer 2 (the Data Link layer) uses another mechanism to establish communication between devices using media access control (MAC) addresses.
Take a look at Figure 1-1. The sender is sending a message to Receiver A, and this requires a combination of both L2 and L3 services. The sender learns the MAC address of the gateway using the Address Resolution Protocol (ARP) and sends IP traffic destined to any network other than the local subnet to the gateway/router. The router looks at the destination IP address and forwards the packet to the next router based on the information in the routing table (Layer 3). The destination router receives the packet and forwards it to the receiver (Receiver A, in this example). As you can see, the Sender never learns the MAC address of Receiver A because Receiver A is not on the same subnet.
Most nontechnical people are familiar with broadcasting. A broadcast, in this classic sense, is a signal that is propagated through electromagnetic waves in the air. The signal saturates the broadcast area, and retrieving the communication is a simple matter of tuning in to a specific frequency. In the networking world, a broadcast is a message sent to all devices on a subnet or a Layer 2 domain, and every device has an obligation to check the message to validate whether they are an intended recipient.
An Ethernet broadcast is very different from an IP broadcast. Remember that IP packets (Layer 3) are encapsulated inside an Ethernet frame (Layer 2). There are source addresses and destination addresses at each layer, and each receives different treatment by networking devices. The destination address of a Layer 3 broadcast in IP is all ones in the host portion of the address. Thus, all hosts would be 255.255.255.255. At Layer 2, an all-hosts broadcast is ffff.ffff.ffff, and switches must replicate these packets when forwarding in order to reach all intended recipients, regardless of physical segment (known as flooding). If a device was looking for a particular IP host but did not know the destination MAC address, it could send an IP unicast message encapsulated in an all-hosts Ethernet broadcast. Every machine on the Ethernet segment receives the packet, but only the intended IP host processes the packet fully and responds. In fact, this is exactly what an initial ARP request looks like.
We have traditionally used a router or Layer 3–capable switch to segment broadcast domains and protect devices from unwanted traffic. This means the router or Layer 3 switch must inspect Ethernet and IP headers and search for broadcast messages. If a packet is a broadcast packet, the router must make a forwarding decision on the destination address. If the address is a local broadcast (intended for only local hosts) the router should drop the packet because this is usually in the format of an all-hosts broadcast (255.255.255.255). If the address is a directed broadcast (a broadcast intended for a specific segment or subnet, such as, for example, 10.1.1.255) the router may forward the broadcast toward the targeted segment, or it may respond if the receiving interface is on the intended segment.
A multicast message is a similar, more efficient version of a broadcast, which is a replicated packet that is sent to a set of hosts. The primary exception is that with a multicast message, the intended recipients of the flow could be on any segment instead of on one specific segment. This process of receiving a single packet, replicating it, and sending copies to additional network interfaces is the key to understanding how multicast works, from the highest to the lowest level. Routers and switches must replicate the packet from the source interface and forward toward receivers. Multicast incorporates the concept of selective learning of data flow by multiple receivers in Layer 2 and 3 domains. Multicast data distribution methods optimize bandwidth usage and create an efficient method of data distribution.
What Problem Does Multicast Solve?
The purpose of multicast is to send information to a select group of devices and to avoid duplication of traffic streams, consequently saving precious network resources such as bandwidth utilization.
Consider the other two mechanisms to propagate information throughout a network—unicast and broadcast. Using the example of an Internet radio station transmitting information, unicast requires that each device on the network interested in listening to the audio stream has a unique session established. As shown in Figure 1-2, unicast has one sender and three receivers. A sender is a device that generates information and advertises it to a group, and a receiver is a device that listens to the information.
Because each stream is being replicated, the sender must replicate the information for each client and the network connection takes three times the bandwidth. This may not be a big problem for a low-bandwidth audio session with only three users, but consider scaling to tens of thousands or millions of sessions. Replicating information for every client creates a significant impact on network resources.
By using broadcasts, the radio station can minimize the number of sessions the sender has to be concerned with, which reduces bandwidth from the sender to the network; however, in this case, the radio station has a different challenge. Referring to Figure 1-3, the problem of replicating numerous streams has been eliminated, and the bandwidth challenge has been mitigated, but now every device receives the radio station whether they are interested in listening to it or not. As the number of radio stations increases, every device on the network becomes more and more inundated with information it might not want. The receivers are now obligated to process the radio streams and to decide whether that information is relevant. Welcome to networking in the 1980s and 1990s, when broadcast storms were a common occurrence.
Multicast to the rescue! We have the best of both worlds with multicast, minimizing the number of sessions required by the sender and reducing the network load to a single traffic flow. We also obtain the benefits of unicast by sending the radio station packets only to the devices interested in receiving them. Referring to Figure 1-4, with multicast, only a single stream is sent and replicated to the interested receivers.
IP multicast messages are transmitted from one-to-many, from many-to-many, and/or from many-to-one over an IP infrastructure that may span Layer 3 boundaries. The destination nodes (receivers) send join and leave messages that create an on-demand community of devices interested in receiving the multicast stream. Multicast optimally uses network resources by requiring the source to send a single packet stream, even though large numbers of receivers might need to receive the messages. The replication of messages takes place at the network node(s) or Layer 3 device(s) and diverges the stream to the receivers. The optimization of the message flow of multicast is leveraged by many applications. These applications are one of the major driving forces for the adoption of multicast in the network infrastructure. Some of the more common applications that rely on multicast are as follows:
Stock exchanges
Computer imaging applications
Music-on-hold services
Sensor updates
Video distribution
Corporate webcasts
Having a good understanding of the nuances of multicast enables you to effectively support those applications and services that rely on multicast as a transport mechanism. This chapter covers some of the applications and services that rely on multicast, examines the history of multicast, and delves into some of the standards.
Multicast Applications and Services
The network infrastructure is in place to support applications and services. These applications and services allow an entity—a government agency, bank, retail organization, hospital, emergency services, or any other business or institution—to fulfill its mission or business objective. Establishing an infrastructure that enables the effective use of these multicast applications and services helps to ensure the success of that organization.
One-to-Many Multicast Applications
The most common form of multicast applications is one-to-many, as shown in Figure 1-5.
As the name implies, there is one sender and multiple simultaneous receivers. Typical applications include video and audio broadcast, but there are many other applications as well, including the following:
Television
Radio
Distance learning
Presentation sharing and whiteboard applications
Computer imaging software and application updates
Data distribution and caching
Informational updates:
Weather
News
Time—Network Time Protocol (NTP)
Sensors that collect environment information (water levels, temperatures, seismic readings, and so on).
Many-to-Many Multicast Applications
With many-to-many multicast applications, the senders also act as receivers. This permits all the devices in the group to simultaneously communicate with one another, as shown in Figure 1-6.
Many-to-many applications include the following:
Audio and video communication
Document sharing and whiteboard applications
Data distribution, caching, and synchronization
Group chat applications
Financial applications
Polling applications
Multiplayer games.
Many-to-One Multicast Applications
Many-to-one applications have many senders but only one or few receivers, as shown in Figure 1-7. This is not a common multicast offering, and it has a significant challenge in that the receiver might not be able to process the information when many devices are sending multicast flows. Scalability is a significant concern with this model. In some ways, this model is not an improvement over using unicast streams but instead allows configuration flexibility for the application. In fact, in many cases, the receiver will respond to senders via a unicast flow. See RFC 3170 for more details on many-to-one applications.
Some of the applications for many-to-one include the following:
Data collection
Service discovery
Polling
Multicast applications can consume a tremendous amount of bandwidth, as with high-definition video, or it can consume very little network bandwidth, as in time updates. All of these applications rely on the infrastructure for the successful operation of the previously mentioned applications and services.
Multicast Packet
As mentioned previously, multicast is a communication method for reaching many participants with a single message flow. In an Ethernet network running Internet Protocol (IP), the active components that make up the infrastructure, primarily routers and switches, are responsible for replicating the single packet flow into multiple packets or messages that are efficiently distributed to other devices interested in receiving those messages.
This warrants a brief review of the Open Systems Interconnect (OSI) model and an explanation of where multicast is applied to the different layers. The OSI model is comprised of the elements shown in Table 1-1.
Multicast applications commonly use User Datagram Protocol (UDP) on IP. Consequently, the Transport layer is used, and this would not be possible without the Network layer running the IP protocol. The IP layer is also where routers primarily function. The Data Link layer is where Ethernet switches replicate multicast traffic on a subnet using multicast media access control (MAC) addresses.
You need to have a solid understanding of the OSI model to comprehend the dynamics of IP multicast technologies and how each layer interacts with one another.
We refer to a frame as a Layer 2 message in that we are focusing on the source and/or destination MAC address. A packet is a Layer 3 message that includes a source and a destination IP address.
It is important to understand exactly how routers build a multicast routing information base (MRIB) and how they use the unicast routing information base (RIB) to ensure loop-free forwarding paths. Mathematically, a tree is the best way for a routing or switching device to guarantee loop free topologies. Multicast routers and switches are master tree builders, which will be covered in more detail throughout this book.
What Is a Source?
When speaking about multicast, there are always two types of hosts, a multicast source and a multicast receiver. A multicast source can be any device with an IP address in the network. To become a source, a host only needs to send a message to a multicast group IP address. (See Figure 1-8.) The three senders in this diagram are all sending to the same multicast destination address of 239.1.1.1.
A source does not need to indicate any intention to send to a group before sending a multicast message. Any IP enabled device, including a router or switch, can send packets toward a multicast group. When an IP multicast router processes a message destined to a multicast group, a new multicast forwarding entry is created. This is the Source, Group entry and is called source comma group, (S, G). The (S, G) entry for Sender A in Figure 1-8 would be (192.168.0.2, 239.1.1.1).
The (S, G) entry refers to the source IP address and the destination group separated by a comma. The IP addresses of the senders in Figure 1-8 are the source (S) addresses, whereas the destination IP address of the group is G. Notice that the three devices are all sending to the same group address. Could this be a problem? Keep that thought in the back of your mind as you continue reading.
What Is a Receiver?
A receiver is any multicast-enabled device that has expressed interest in a particular multicast group or a specific (S, G) pair. Unless the multicast is link-local (not passed on through the network by any router, such as, for example, the “all-routers” IPv4 group of 224.0.0.2), the IP devices must be configured by the administrator or by an application to subscribe to a specific multicast group. After it’s subscribed, a multicast receiver listens for packets that arrive with the multicast group destination address, like group 239.1.1.1 used in Figure 1-8.
Group subscription is managed by the Internet Group Messaging Protocol (IGMP). When a receiver subscription for a specific group or set of groups is received or initiated by a router, the router adds what is called a star comma G, (*, G) entry to the MRIB. The (*, G) entry simply represents that the router has an interest in the group.
Note
Multicast forwarding information based (MFIB) and multicast routing information base (MRIB) are terms used to understand the multicast flow in Cisco routers.
The MRIB is responsible for routing information that is generated by multicast protocols. This information feeds into the MFIB responsible for forwarding multicast packets and collecting statistics on the multicast flow.
L3 Multicast Is Built on the TCP/IP Protocol Stack
IP multicast is built on the TCP/IP protocol stack. That means that the protocols necessary to transport multicast frames and packets are controlled by the Internet Engineering Task Force (IETF). IETF members develop and manage protocols through the RFC process, which means that IP multicast protocols are open standards.
Note
Multicast protocol IETF development applies to both IPv4 and IPv6 multicast technologies; however, as with other IP-based protocols, that does not mean that every manufacturer treats multicast the same. It also does not mean that every implementation of multicast protocols is perfectly standard-compliant.
Using the TCP/IP stack also means that IP multicast is subject to the Internet Assigned Numbers Authority (IANA). IANA controls and coordinates the assignment and use of IP addresses in public spaces. This includes multicast address assignment.
It’s a Group Thing
A contrast and comparison between L3 unicasts, broadcasts, and multicasts will illustrate the uniqueness of multicast transmissions. The primary difference between a broadcast and a multicast is that multicast receivers can connect anywhere on any network segment or subnet, whereas subnets define broadcast boundaries, called broadcast domains. Routers and switches must therefore have a way of recognizing which segments and subnets connect interested multicast hosts. Senders and receivers manage this process through group membership.
A broadcast uses a specific destination IP address in the packet to reach each receiving host. Routers and switches immediately recognize broadcasts without any additional protocol overhead because the subnet defines the broadcast boundary. The following packet header breakdowns show the difference between a unicast IPv4 packet, a broadcast IPv4 packet, and a multicast IPv4 packet. Figure 1-9 illustrates a basic unicast IP packet.
Forwarding a unicast message is a simple task—follow the route to the IP destination. Broadcasts are equally simple to forward. Broadcast packets also follow the route to the destination, but they are replicated on any switch ports that belong to the appropriate logical Ethernet segment (VLAN or subnet). There are two types of broadcasts, all-hosts broadcasts and directed broadcasts. An all-hosts broadcast is intended for every IP host on every subnet in which it is forwarded. A directed broadcast is intended for every IP host only within a given subnet/supernet or VLAN.
Note
Replication is the simple process of making a copy of a packet to forward through the network. Replication is required anytime a single packet has more than one intended recipient, as, for example, with broadcasts and multicasts. Replication is a basic function of any active networking device such as a switch or router.
If the broadcast includes all-hosts, then the local switch simply replicates the broadcast packet for each interface in the logical segment on which the packet was received. Figure 1-10 depicts an all-hosts broadcast on a local segment. Routers, by their nature, do not forward all-hosts broadcasts received on an interface in a given subnet, consequently segmenting the broadcast domain from the rest of the network.
Figure 1-10 All-Hosts Broadcast Packet (Indicated by 255.255.255.255 as the Destination IPv4 Address and ffff.ffff.ffff as the Destination MAC Address)
If a broadcast is directed, it is sent through the network toward the intended subnet and replicated by any switch on that subnet, as shown in Figure 1-11.
Figure 1-11 Directed Broadcast Packet (Indicated by the 10.2.2.255 Destination IPv4 Address, or All Hosts on the 10.2.2.0 Subnet)
The difference between a multicast and a broadcast with hosts on a single subnet is subtle. What if only a few of the hosts on the subnet need to receive the packets? Using a group address to which hosts can subscribe would ease the burden of sending packets to the select hosts on that segment, reduce replication overhead, and use the bandwidth only in the LAN where the hosts are located. Figure 1-12 illustrates just such a scenario.
The major difference between a broadcast and multicast is that subscribed hosts of a multicast flow may exist on multiple segments. How can routers and switches then forward to only those hosts without replicating the packet for every segment in a network or on the Internet? Multicast senders transmit IP packets using a specific destination IP address known as a group address using a specific multicast MAC address. You may have noticed the L2 destination address is not an address on the local subnet. This will be discussed further in Chapter 2, “Network Access and Layer 2 Multicast.”
IPv4 Layer 3 Multicast Addressing Defines Groups
The group address simply identifies a group of nodes interested in a flow. The group address combined with the source IP address identifies the multicast flow. Host receivers express interest in the flow by notifying upstream network devices of group membership. This expression of interest is known as joining the group.
IPv4 and IPv6 group addressing is controlled by a combination of IETF RFCs. The most important and current IPv4 RFC is 5771, which finalizes assignment of the multicast group address space and the individual group types within that space. The multicast group block address space is derived from IPv4 classful address space. Table 1-2 details classful routing addressing assignment.
Class D addressing is reserved by RFC 5771 for multicast group assignments. RFC 5771 replaced or updated several RFCs, including RFC 988, which in 1986 originally proposed 1110 as the high-order bit reservation for IPv4 multicast group identification. RFC 988 supersedes RFC 966, the original IP multicast theory RFC. Both RFC 988 and 966 are important to the history of multicast, and a thorough understanding of the theory in each is a great starting point for anyone wishing to dive more deeply into the roots of multicast technology and terminology.
IPv4 Multicast Group Address Assignments
RFC 5771 further expands the Class D address for suggested IANA multicast group address assignment and deployment. Table 1-3 illustrates this assignment.
The following is a brief explanation of each block type, and the proper usage:
Local Network Control block (224.0.0/24): The local control block is used for specific protocol control traffic. Router interfaces listen to but do not forward local control multicasts; for example, OSPF “all routers” (224.0.0.5). Assignments in this block are publicly controlled by IANA. You can find a complete list of Local Network Control address assignments at the IANA website (www.iana.org).
Note
Routers listen for local control packets only if the control group feature is enabled on the node. For example, a router interface would only process RIPv2 control group packets (group 224.0.0.9) if RIPv2 is enabled on that interface.
Internetwork Control block (224.0.1/24): The Internetwork Control block is for protocol control traffic that router interfaces may forward through the autonomous system number (ASN) or through the Internet. Examples include 224.0.1.1 Network Time Protocol (NTP), defined in RFC 4330, and 224.0.1.68 mdhcpdiscover, defined in RFC 2730. Internetwork Control group assignments are also publicly controlled by IANA.
AD-HOC blocks (I: 224.0.2.0–224.0.255.255, II: 224.3.0.0–224.4.255.255, and III:233.252.0.0–233.255.255.255): Traditionally assigned to applications that do not fit in either the Local or Internetwork Control blocks. Router interfaces may forward AD-HOC packets globally. Most applications using AD-HOC blocks require few group addresses (such as, for example, less than a /24 space). IANA controls any public AD-HOC Block assignments and future assignments will come from AD-HOC block III, if they are not more suited to Local Control or Internetwork Control. Public use of unassigned AD-HOC space is also permitted.
SDP/SAP block (224.2.0.0/16): The Session Description Protocol/Session Announcement Protocol (SDP/SAP) block is assigned to applications that receive addresses through the SAP as described in RFC 2974.
Source-Specific Multicast block (232.0.0.0/8): SSM addressing is defined by RFC 4607. SSM is a group model of IP Multicast in which multicast traffic is forwarded to receivers from only those multicast sources for which the receivers have explicitly expressed interest. SSM is mostly used in one-to-many applications. No official assignment from IANA is required to use the SSM block because the application is local to the host; however, according to IANA policy, the block is explicitly reserved for SSM applications and must not be used for any other purpose. SSM will be discussed further in subsequent sections of this and other chapters.
Note
The 232.0.0.0/8 block was originally assigned by IANA for use by the Versatile Message Transaction Protocol (VMTP).
GLOP block (233.0.0.0/8): These addresses are statically assigned with a global scope. Each GLOP static assignment corresponds to a domain with a public 16-bit autonomous system number (ASN), which is issued by IANA. The ASN is inserted in dotted-decimal into the middle two octets of the multicast group address (X.Y). An example GLOP assignment for an ASN of X.Y would be 233.X.Y.0/24. Domains using an assigned 32-bit ASN should apply for group assignments from the AD-HOC III Block. Another alternative is to use IPv6 multicast group addressing. Because the ASN is public, IANA does not need to assign the actual GLOP groups. The GLOP Block is intended for use by public content, network, and Internet service providers. IANA considers GLOP addressing to be experimental, and 233.252–255.0.0 is reserved.
Administratively Scoped block (239.0.0.0/8): Administratively Scoped addresses are intended for local use within a private domain as described by RFC 2365. These group addresses serve a similar function as RFC 1918 private IP address block (such as, for example, 10.0.0.0/8 or 172.16-31.0.0/16 blocks). Network architects can create an address schema using this block that best suits the needs of the private domain and can further split scoping into specific geographies, applications, or networks. Further information on best practices for scoping this block can be found in Chapter 5, “IP Multicast Design Considerations and Implementation.”
Important Multicast Groups and Group Considerations
There are many multicast groups, each subdivided from a larger block of multicast group ranges. Each of the group block ranges has a specific application or scope. The scope of each block ranges from single segments to large enterprise multicast networks to the global Internet. It is important to understand the RFC and standards for multicast groups when designing multicast networks. Multicast group addresses play a very important part in “scoping” the multicast domains. Chapter 5 explains this concept in more detail.
Note
IANA manages globally scoped address assignments as well as any protocol assignments for applications. Without control over these addresses, there would be little possibility of using them for protocol interchange or standards-driven communication.
IPv4 Local Network Control
The Local Network Control block, also known as the Link-Local block, consists of IANA assigned addresses between 224.0.0.0 and 224.0.0.255. These multicast groups are intended for use within a single subnet or segment. They are not to be forwarded by routers, and therefore have a time-to-live (TTL) value of 1. Many well-known applications and communications protocols have reserved address assignments.
Application developers and network administrators should not use group addresses in this block for any purpose other than the IANA assigned application. Table 1-4 lists some of the most relevant assignments from the link-local multicast address, taken directly from the IANA database. The table lists the reserved multicast addresses, the protocol function assigned, and relevant RFCs.
As the table illustrates, many important network functions rely on link-local multicasting. Routing protocols, including EIGRP, RIPv2, and OSPF use these protocols to send updates to neighbor routers. IGMP also uses a link-local multicast address to notify gateway routers of group subscription. The important point to remember is that the Layer 3 devices will not replicate or forward these packets. Layer 2 devices will forward link-local multicast frames only on ports within the same Layer 2 domain (VLAN or subnet).
IPv4 Inter-Network Control
The Inter-Network Control block is similar to the Local Network Control block, with the exception that multicast applications using this block may require that multicast packets be forwarded beyond the local segment. The block ranges from 224.0.1.0 to 224.0.1.255. Table 1-5 provides a partial list of some of the more important Internetwork Control block assignments as made by IANA.
Many infrastructure protocols use assigned Inter-Network Control block group addresses for protocol communication. A good example of Inter-Network Control multicast is the Cisco Auto-RP protocol. Cisco Auto-RP uses multicast groups 224.0.1.39 and 224.0.1.40 to dynamically assign, advertise, and discover rendezvous points (RPs) in a PIM sparse mode network domain; 224.0.1.39 is used for Cisco Announce; and 224.0.1.40 is used for Cisco Discovery.
Using IP multicast for infrastructure communication simplifies the protocol design process. After a multicast address is assigned to a particular application or protocol, developers need only send packets to the assigned address to facilitate protocol intercommunication between many devices. Several of the existing assignments from the Inter-Network Control block may be for applications or protocols that will never be deployed on a large scale. Approximately one-third of the block space remains for future development.
The History of Multicast
Necessity is the mother of invention. Steve Deering was a student of Stanford University in the early 1980s, working on a distributed processing project. One of the underlying communication mechanisms allowed one device to send a message to many other devices as a single update. As the project grew, so did the requirement for compute resources. These resources were distributed throughout the campus, which required a mechanism to communicate to those devices over a router (L3) infrastructure. This could have been accomplished using multiple unicast messages, or by broadcasting the messages across the entire network. Neither of these methods were an acceptable solution in this case because they were too inefficient. The resolution required a unique single group address, the ability for the routers to participate in sending the messages, and the capability to have the hosts join or leave the group at will—hence, the birth of multicast.
The MBone
The multicast backbone (MBone) project was started ten years after Dr. Deering’s invention of multicast. The routers that comprised the Internet at that time did not have the capability to support native multicast; consequently, the MBone was a handful of Unix hosts connected over tunnels using Distance Vector Multicast Routing Protocol (DVMRP), running a daemon called mrouted. The MBone at that time was driven by higher-education institutions and was used to deliver content such as the Internet Engineering Task Force (IETF) meetings, concerts, and so on, all with a very limited scope of viewing.
Native Internet Multicast
Native Internet multicast would allow anyone with an Internet connection to view content. Could you imagine being able to watch any TV channel, listen to any radio station, participate in distance learning sessions, all via multicast? Unfortunately, the experiment of the MBone driven by academia in the 1990s has still not moved to a mainstream service offered by Internet Service Providers (ISPs), because many service providers do not support the transport of multicast traffic across their network. The adoption of multicast by ISPs has been slowed by security concerns, the complexity of implementation, and the capability to easily share multicast routing information.
This has not diminished the need for multicast within private networks. As we reviewed earlier, there are many applications that benefit from an infrastructure that transports multicast traffic. We can still take advantage of the transport services of the Internet by tunneling multicast traffic over it, even if it is not supported natively.
IPv6 Multicast
The rapid growth of the Internet is causing the depletion of IPv4 address space. Consequently, IPv6 is taking hold to provide for the expansion of the Internet and to permit our ability to access any device on the planet.
IPv4 addresses use 32 bits for a numerical value to distinguish individual devices, whereas IPv6 uses 128 bits. This increase offers tremendous scalability. The implementation of IPv6 has another interesting characteristic in that it no longer supports network broadcasts. The two methods of communication with IPv6 are either unicast or multicast. Because multicast was considered during the creation of the protocol, there are inherent capabilities that improve the operation. Besides the greater amount of address space, there are other features in IPv6 that make the multicast designs simpler. You will learn much more about the functionality of IPv6 and multicast in Chapter 6, “IPv6 Multicast Networks.”
Multicast Development and Standardization
Just as with many other networking technologies, the effort being made to improve multicast has continued. There have been many enhancements to address the shortfalls and feature enhancements that were not foreseen during the creation of the protocol.
Could you imagine if every developer decided to write code based on how they thought it should work? Fortunately, standardization groups collaborate on how to solve technical challenges and create documentation on how those solutions are to be addressed to achieve compatibility and interoperability. There are two major standards bodies that help to drive common implementation methodologies, the Internet Engineering Task Force (IETF) and the Institute of Electrical and Electronic Engineers (IEEE).
Note
The charter of the Internet Engineering Task Force (IETF) is to make the Internet work better by producing high-quality and relevant technical documents that influence the way people design, use, and manage the Internet. The IETF generates documents such as requests for comment (RFC) and best current practices (BCP).
The Institute of Electrical and Electronics Engineers (IEEE) is the largest technical professional society and is an association dedicated to advancing innovation and technological excellence for the benefit of humanity. Besides developing standards for Ethernet, the IETF develops standards for many other areas.
Summary
The three data communication methods in IP networks are unicast, broadcast, and multicast. Each of these methods has advantages and disadvantages depending on the application. Multicast offers an efficient communication mechanism for sending messages to multiple recipients in separate locations. It is also capable of supporting many-to-many and many-to-one communication.
Multicast applications commonly use User Datagram Protocol (UDP) on IP. Messages are sent by a source (called the sender) and will send messages (termed as a stream) even if there is not another device on the network interested in receiving that information. Receivers, on the other hand, must subscribe to a particular multicast stream in order to inform the network to forward those messages.
IP addressing for multicast is also unique. There are many public and private addresses that have been allocated for different applications and services. It is imperative to understand what addresses you plan to use prior to building out a multicast network.
Multicast was developed in the early 1980s from a research project at Stanford University. Improvements continue as new applications and services are developed and to address security concerns.