IP Multicast Forwarding

Getting Started with IP Multicast

Unicast, Broadcast, and Multicast Communications

The three methods of IP communication are illustrated as follows:

·     Unicast is a one-to-one data transmission method used for communication between one source host and one destination host. Using this method, a switch or router forwards data but does not replicate data. Most data on a network, such as email, web browsing, and video on demand (VoD), is transmitted using unicast.

·     Broadcast is a one-to-all data transmission method used for communication between a source IP host and all other IP hosts on the same local area network (LAN). Using this method, a switch or router replicates and forwards data unconditionally, and all hosts can receive the data even if a host does not require the data. In this manner, broadcast communication not only wastes bandwidth, but can also cause broadcast storms due to routing loops. Therefore, broadcast data in a LAN cannot be transmitted to other LANs, and cannot be forwarded by routers. However, broadcast communication is still necessary in some scenarios, such as dynamic IP address obtaining through DHCP and MAC address learning through ARP.

·     Multicast is a one-to-many data transmission method used for communication between a source IP host and a selected group of IP hosts. Using this method, a switch or router replicates and forwards data only for hosts that require the data, not for all hosts. Typical multicast application scenarios include video/voice conferences, IPTV, and stock quotation releases.

Compared to unicast transmissions, multicast transmissions have significant advantages. For example, consider the situations illustrated below where 15 users have requested the same web page to view.

In unicast transmission mode, the server sends 15 identical copies of the data, which places a lot of pressure on the server and network devices involved (see the first illustration).

In multicast transmissions mode, the server sends only 1 copy of the data to all the 15 receivers (see the second illustration).

Multicast Distribution Tree (MDT)

A multicast distribution tree (MDT) is named as such due to the layout of the network topology. The root is the multicast source (the server) and the leaves are multicast receivers (clients). The total load of multicast data on the network does not increase with the addition of more clients, which is the biggest advantage of using multicast.

In the following example you will learn how multicast data packets transmit along an MDT on an IP network.

In unicast transmission mode, after receiving a data packet from a source, a router will look up the packet's destination IP address and then determine the packet's outbound interface recorded in the forwarding table.

Use the preceding figure as an example. If a data packet from the source is requested by 7 receivers, Router-X will read 7 destination IP addresses and find 2 outbound interfaces for the data packet. This destination IP address and outbound interface determination process is time-consuming and may overload the router when a large number of data packets are requested by numerous users. To resolve this issue, multicast groups were introduced.

Multicast Group

A multicast group consists of a group of receivers that require the same data stream, which does not identify specific hosts on a network. Multicast groups are unidirectional and useful only in the data transmission direction from a multicast source to receivers.

Multicast Group Address

Multicast IP addresses belong to Class D addresses (ranging from 224.0.0.0 and 239.255.255.255). They are used to identify multicast groups to implement correct IP packet forwarding at the network layer.

Addresses 224.0.0.0 to 224.0.0.255 are reserved for local network protocols. For example, 224.0.0.5 and 224.0.0.6 are used by OSPF. A router does not forward packets whose destinations are these two addresses, regardless of what the packet TTL values are.

MAC addresses are required for multicast packet forwarding at Layer 2 (data link layer). Similar to unicast MAC addresses, the length of a multicast MAC address is 48 bits, written as XX-XX-XX-XX-XX in hexadecimal notation. According to IEEE 802.3, the first bit of a MAC address indicates whether the address is a unicast, broadcast, or multicast address. If the first bit is 0, it indicates a unicast address; if the first bit is 1, it indicates a multicast or broadcast address. A broadcast address is written only in the format of FF-FF-FF-FF-FF-FF. Most multicast MAC addresses start with 0x01-00-5E and are written in the format of 01-00-5E-XX-XX-XX.

Multicast Forwarding Table Elements

In the example figure below, upon the receipt of a multicast data packet, Router-X first looks up the packet's destination IP address in the forwarding table to find the matching outbound interface. According to the preceding multicast group address explanation, the destination address in the multicast forwarding table is the multicast group address and the outbound interface list is {interface A, interface B}. If the multicast group address matches the destination address of the multicast packet, the multicast packet is then sent out from interfaces A or B.

However, because multicast packets are sent to a group of receivers, the potential for incorrect multicast data forwarding increases, which can severely interrupt the network. In the following figure, the blue arrows represent correct multicast data forwarding. If Router-X sends one copy of the multicast data to Router-Y by mistake, a lot of unnecessary multicast data (represented by red arrows) will flood the network, and waste resources (the negative impact further increases if routing loops exist).

To ensure correct forwarding, multicast data must be forwarded along the MDT. Reverse Path Forwarding (RPF) check is implemented to ensure the correct forwarding path is used, and to avoid routing loops. During RPF checks, when a router receives a multicast packet, it will look up the route of the multicast source in the unicast forwarding table. If the outbound interface used in this route is the inbound interface of the packet, the multicast packet passes the RPF check and is forwarded. Therefore, in multicast forwarding, both the source and destination of a multicast data packet are taken care of.

RPF check for every multicast packet, however, increases the router's workload. To solve this problem, unicast reverse path forwarding (uRPF) checks are implemented before the forwarding entry is generated in the routing table. In this way, the multicast source address, and the interface toward the multicast source, are also included in the forwarding entry. When multicast packets are forwarded, the router then only needs to check whether the source address of the packet is the multicast source of the forwarding table, and the destination address is the multicast group of the forwarding table.

If the result is correct, the router then checks whether the inbound interface of the packet is the interface toward the multicast source. If the result remains correct, the multicast packet is then forwarded; otherwise the packet is discarded.

In summary, a multicast forwarding table contains the following items: a multicast source, a multicast group, an interface connected to the multicast source, and the outbound interface list. The multicast source and group addresses are usually matched in pairs and displayed in the form of (S, G), in which S stands for a multicast source, and G for a multicast group. As shown in the figure below, the multicast forwarding entry generated by Router-X is (10.1.1.1, 255.1.1.1), GE1/0/0, {GE2/0/0, GE3/0/0}.

Multicast Forwarding Table of VPN-Instance: public net

Total 1 entry, 1 matched

00001. (10.1.1.1, 225.1.1.1), MID: 0, Flags: 0x0:0

     Uptime: 00:08:32, Timeout in: 00:03:26

     Incoming interface: GigabitEthernet1/0/0

     List of 1 outgoing interfaces:

       1: GigabitEthernet2/0/0

       2: GigabitEthernet3/0/0

 Matched 18696 packets(523488 bytes), Wrong If 0 packets

     Forwarded 18696 packets(523488 bytes)

To generate a multicast forwarding entry such as the above example, the router needs to discover the following:

·     How Are Multicast Groups Established?

·     What Are Receivers in a Multicast Group?

·     Multicast group sources

How Are Multicast Groups Established?

To establish multicast groups, routers must first learn the destination IP addresses in unicast transmissions. IP addresses are manually configured or dynamically allocated by the RADIUS server for hosts. These IP addresses are then advertised on the network for routers to learn the network topology and generate routes through network protocols. The router then selects the optimal routes and places them in the routing and forwarding tables. To forward a packet, the router looks up the IP address of the packet in the forwarding table to find the appropriate outbound interface.

The destination address of a multicast packet, however, is a multicast group address that does not represent a host address. As a result, the multicast group address cannot be allocated to a host or configured on an interface. Instead, a multicast group is a convention between the multicast source and receivers, similar in means as a TV channel. Using the figure below as an example, there is a list of TV channels corresponding with multicast group addresses on the set-to box (STB).

As shown in the above tables, the multicast group addresses of both the STB and the server are identical.

What Are Receivers in a Multicast Group?

Receivers in a multicast group are identified using the Internet Group Management Protocol (IGMP). IGMP sets up and manages the membership in a multicast group on directly connected network segments. To be more specific, it manages the group members on different interfaces.

IPTV is used as an example to illustrate how IGMP works:

·     When an STB user wants to watch a TV channel, the STB sends an IGMP Report message to join the multicast group of the selected TV channel (the multicast group 224.1.1.1 in this example).

·     When the viewer stops watching the TV channel, the STB sends an IGMP Leave message to leave the multicast group of this channel.

·     The router sends IGMP Query messages to learn whether there are receivers in a multicast group through the Report or Leave messages from hosts.

Similar to an audience selecting TV channels (an audience can turn the TV on and off, or switch between channels at any time), the STB can join or leave a multicast group anywhere and at anytime, without limit.

To enhance reliability, two or more routers are deployed on a LAN. A "representative" for these routers is selected by IGMP to forward the multicast data to all multicast receivers. This "representative" is called a receiver's Designated Router (DR). All multicast receivers receive multicast data and send IGMP messages through this DR. An example of this network is shown below:

Multicast routing protocols are also needed to ensure that the addresses and information about members of multicast groups are sent to all multicast routers on the network. Among various multicast routing protocols, the most widely used one is Protocol Independent Multicast (PIM). Protocol independent means that there is no special protocol requirement on unicast routing.

The PIM protocol has two modes: PIM-DM and PIM-SM.

PIM-DM

In the figure below, the viewer (Receiver A) turns on the TV to watch a TV channel. The STB reports that it wants to receive the multicast data of group G, using IGMP, to the receiver's DR (Router-1).

Router-1 receives the IP address of multicast group G. However, Router-1 does not know where the multicast source is, so a (*, G) entry is generated where * represents a multicast source.

When the multicast source sends multicast data to the network, all multicast routers forward the data. As a result, Router-1, Router-2, and Router-3 all receive the same multicast data. Because Receiver A wants the data, Router-1 sends the data to Receiver A. Router-2 and Router-3 do not forward the data to Receiver B or C.

When multicast data is transmitted on the network, multicast routers can obtain the IP address of the multicast source, the inbound interfaces to the multicast source, and the IP addresses of multicast groups. The outbound interface list includes all interfaces connected to the downstream interfaces. At this point, multicast entries (S, G) can be generated. The receiver DR can identify its receivers and update the outbound interface list to get the correct multicast forwarding entries.

However, in the process detailed above, Router-2 and Router-3 do not have any receivers. To save network resources, they inform the upstream router to delete interfaces connected to them from the outbound interface list, so that the multicast data is not forwarded to them. This process is called Prune. When the Prune process is complete, all routers on the network have the correct forwarding entries, as shown in the following figure.

In addition, the multicast source may connect to the network with multiple routers. Using PIM-DM, a router is selected as the source's DR to send and receive multicast data.

However, some routers still have (S, G) entries listed after the Prune process has been completed, even when they do not have any receivers. Only their outbound interface lists are empty. To resolve this problem, PIM-SM was introduced.

PIM-SM

·     Selecting an "Agent"

A multicast router on the network is selected as the Rendezvous Point (RP) using PIM-SM. The RP works as an agent. All other routers on the network need to learn the RP position. By using PIM-SM, another router is selected as the source's DR to send and receive multicast data.

·     Establishing an "RP Tree"

Once the receiver's DR is selected, it sends a PIM Join message to the RP. The (*, G) entry, used to identify the RP address and the group address, is advertised to all routers between the receiver's DR and the RP. As a result, the RP is established as the root of the shared tree. Similar to PIM-DM, the receiver then sends an IGMP Join message to the receiver's DR to join multicast group G, and the receiver router generates the (*, G) entry.

·     Multicast Source Registration

When the source's DR receives multicast data from the multicast source, as it does not have the multicast forwarding entry, it encapsulates the received multicast data packet in a Register message and sends this message to the RP for notification. The source's DR then creates an (S, G) entry locally with an empty interface list.

After receiving the Register message, the RP decapsulates the message and sends the multicast data packet to receivers along the RPT. As a result, every router on the path can generate an (S, G) entry correctly and replicate all interface information from the (*, G) entry.

If there is no RPT when the RP receives the Register message, the RP discards the packet.

·     Establishing the Shortest Path Tree

If a lot of multicast data needs to be sent to the RP, the source's DR must first encapsulate the multicast data in Register messages.

The RP then has to decapsulate every Register message to extract the multicast data. This is a very inefficient process. To address this issue, the RP creates a shortest path tree (SPT) between itself and the source's DR to receive multicast data directly through the SPT. To establish an SPT, the RP creates an (S, G) entry in the multicast table, in which the inbound interface is the interface that receives Join messages. It then sends a Join message to the source's DR. This means that every RP's upstream routers can receive the correct (S, G) entry and that an SPT (with the source's DR as its root) is also created.

After receiving the RP's Join message and correct (S, G) entry, the source's DR can forward multicast data based on the (S, G) entry.

After the SPT is established, the RP can receive the multicast data of a multicast group through the SPT and changes the inbound interface to the interface that receives the multicast data.

The RP is also able to send a Register Stop message to the source's DR to stop the source's DR from sending multicast data in Register messages.

This allows the source's DR to send multicast data packets only through the SPT, stopping multicast data packets being encapsulated and sent as Register messages.

NOTE:

A source's DR will keep sending Register messages and multicast data packets through the SPT, until receiving a Register Stop message. This is due to the following scenario:

Join messages are multicast messages that contain:

§  A source IP address identical to the local interface

§  A destination address 224.0.0.13

§  A TTL value of 1

When a Join message sent upstream by the RP reaches the source's DR, the source IP address of the message is not that of the RP. As a result, the source's DR cannot identify whether the Register message was initially sent by the RP or the receiver's DR (the receiver's DR is also able to send a Join message to the source's DR). The source's DR also cannot determine whether the multicast packets it sent can be received by the RP. Only when the source's DR receives a Register Stop message can the source's DR confirm that its multicast packets can be received by the RP.

The source's DR also needs to confirm if its multicast data packets are received by the RP. In the (S, G) entries generated by the RP, when the RP receives Register messages from the source's DR, the inbound interface is the one that receives the Register message. However, the RP may not receive multicast data packets and Register messages on the same interface. As a result, the source's DR needs to confirm that the multicast packets it sent can be received by the RP before the source's DR stops sending Register messages.

·     SPT Switchover

In the preceding process, all multicast data must be forwarded by the RP, which may overload the RP when the multicast packet sending rate is high.

To resolve this issue, PIM-SM allows the receiver's DR to send Join messages along the shortest path tree to the source's DR. This generates the SPT from the receiver's DR to the source's DR. The receiver's DR then sends a Prune message to the RP to prune the original RPT. The source's DR prunes the SPT between the source's DR and the RP, allowing multicast data to be forwarded along its SPT instead of through the RP. The process is illustrated in the following figure.

IP Multicast Forwarding Process

The IP multicast forwarding process is shown in the following figures, with an emphasis on multicast forwarding based on the forwarding table.

IP multicast forwarding process:

1.    Determine whether the destination MAC of the packet is a multicast MAC. If it is, the packet proceeds to the next step. If not, unicast forwarding is performed.

2.    Determine whether the packet is an IP packet. If it is, the packet proceeds to the next step. If not, other forwarding processes (such as MPLS forwarding) are performed.

3.    Check whether the length, IP address, and checksum of the packet are correct. If they are, the packet proceeds to the next step. If not, the packet is discarded.

4.    Check whether the IP address is a multicast address. If it is, the packet proceeds to the next step. If not, the packet is discarded.

5.    Check whether IP multicast is enabled on the inbound interface. If it is, the packet proceeds to Step 7. If not, the packet proceeds to the next step.

6.    Check whether there is an (S, G) entry in the multicast FIB (MFIB) table of the public network or the VPN that matches the packet. If there is a matching (S, G) entry, the following scenarios may occur:

·         If the inbound interface of the forwarding entry is the same as that on which the packet was received, the packet proceeds to Step 7. However, if the outbound interface of a device is in Register state, the device is the source's DR, and has not received a Register-Stop message. The multicast packets received by this device first needs to be sent to the CPU, encapsulated in Register messages, and then sent to the RP.

·         If the inbound interface is not the same as that on which the packet was received, the packet is sent to the CPU for processing. The CPU performs RPF check. If the interface toward the multicast source is the same as the inbound interface in the (S, G) entry based on the unicast routing table, the (S, G) entry is correct, but the packet is forwarded along an incorrect path, and therefore discarded. If not, the (S, G) entry is aged out. The inbound interface in the (S, G) entry, based on the unicast routing table, is then updated, as well as the forwarding table. The router then checks whether the interface on which the packet is received is the updated interface. If it is, the packet proceeds to Step 7. If not, the packet is discarded.

·         When there is no matching (S, G) entry, the following scenarios may occur:

§  If the router is the source's DR and receives the first multicast packet from the multicast source, this means that (S, G) entries have not been created. Multicast packets must first be sent to the CPU to be encapsulated into Register messages and then sent to the RP. The CPU sends (S, G) entries in which there is no outbound interface. Upon the receipt of RP's Register messages, the CPU adds outbound interfaces to the (S, G) entries. If the source's DR fails to register to the RP, to alleviate the workload of CPU, the multicast data afterwards is forwarded directly, not in Register messages. The outbound interface in the (S, G) entry, however, is empty, which causes the packet to be discarded.

§  If the routers along the RPT only have (*, G) entries but no (S, G) entries when the first packet of a multicast group is sent from the RP to the receiver, multicast packets are sent to the CPU for processing. The CPU generates the (S, G) entry and copies the outbound interface list from the (*, G) entry. It then performs the RPF check on the packet. If it passes the RPF check, the packet proceeds to Step 7. If it fails, the packet is discarded.

7.    Check whether there is a multicast group member matching the (S, G) entry. If there is a matching entry, the packet proceeds to the next step. If no match is found, or the outbound interface list is empty, the packet is discarded.

8.    Check whether the inbound interface of the packet is the same as that in the (S, G) entry. If it is, the packet proceeds to the next step. If not, the packet is discarded.

9.    Perform follow-up procedures (such as for uplink TMs, intra-board multicast replication is performed, and for downlink TMs, inter-board multicast replication is performed). See Chapters 1 to 6 for details about these procedures.

 

Related subjects:

[IP Adventure] A Packet's Adventures on Routers - 07

[IP Adventure] A Packet's Adventures on Routers - 06

[IP Adventure] A Packet's Adventures on Routers - 05

[IP Adventure] A Packet's Adventures on Routers - 04

[IP Adventure] A Packet's Adventures on Routers - 03

[IP Adventure] A Packet's Adventures on Routers - 02

[IP Adventure] A Packet's Adventures on Routers - 01

[IP Adventure] A Packet's Adventures on Routers - Introduction

good files

Thanks for sharing the details.

Nice documentation related with IP Multicast Forwarding

IP multicast forward explained in better way

extremely good data