Basics of multicasting and its implementation on ethernet networks

Basics of Multicasting and its implementation on Ethernet Networks

By

V.Sasank Chaitanya Kumar

Network Engineer Reliance Communications [email protected]

Abstract:

The project is intended to give a basic overview on Multicast Communication. It further gives a brief

introduction on IP multicast, packet flow mechanisms, General architecture & Functional Overview of

Multicasting over metro Ethernet.

In today’s modern world multicasting has influence on triple play services. The requirements initially

started with exchange of information from point to point (uni-casting). The world is now moving

towards multicasting because of its applications and features.

To realize such complex type of communication it becomes imperative to understand the basic concepts

of multicasting. This paper gives a brief descriptions of the basic terminologies, key concepts, short

introduction to such definitions / Specifications / standards and Test Setups used to optimize and run

complex communication networks.

Basics of Multicasting and its implementation over Ethernet Netwoks

1 | P a g e

Introduction:

Multicasting is the process of sending data to a group of receivers. It might be argued that unicasting

and broadcasting are subsets of multicasting. In the case of unicasting, there is only a single member

Of the group in the case of broadcasting, all possible receivers are members of the group.

The delivery of radio and television programming is commonly called "broadcasting," but in reality it

is multicasting. A transmitter sends data on a certain frequency, and some group of receivers

Acquires the data by tuning in to that frequency. The frequency is, in this sense, a multicast address.

All receivers within the range of the transmission are capable of receiving the signal, but only those

Who listen to the correct frequency actually receive it.

If we observe Interest in multicasting has really taken off, as enterprises presently increasing demands

for one-to-many and many-to-many communications.

The three basic requirements for supporting multicast across a routed internetwork are as follows:

3.1. 1There must be a set of addresses by which multicast groups are identified.

3.1.2 There must be a mechanism by which hosts can join and leave groups

3.1.3 There must be a routing protocol that allows routers to efficiently deliver multicast traffic

to group members without overtaxing network resources.

IP Addressing for Multicasting:

The IANA has set Class D IP addresses for use as multicast addresses, the first four bits of a Class D

address are always 1110. Fin ding the minimum and maximum 32-bit numbers within this

constraint, the range of Class D addresses is 224.0.0.0–239.255.255.255.

Some Well-Known Reserved Multicast Addresses by IANA are:

IP ADDRESS GROUP

224.0.0.1 All systems on this subnet

224.0.0.2 All routers on this subnet

224.0.0.4 DVMRP routers

224.0.0.5 All OSPF routers

224.0.0.6 OSPF designated routers

224.0.0.9 RIP-2 routers

224.0.0.10 EIGRP routers

224.0.0.13 PIM routers

224.0.0.15 CBT routers

224.0.1.39 Cisco-RP-Announce

224.0.1.40 Cisco-RP-Discovery


2 | P a g e

The IANA reserves all the addresses in the range 224.0.0.0–224.255.255.255 for routing protocols

and other network maintenance functions.

Ethernet and FDDI interfaces map the lower 23 bits of the group IP address onto the lower 23

bits of the reserved MAC address to form a multicast MAC address. Reserved MAC address:

0100.5E00.0000

Fig: Principle of mapping IP address to MAC-address

Mechanism by which hosts can join and leave groups:

Internet Group Management Protocol (IGMP)

Regardless which of the several routing protocols used in a multicast inter network, IGMP is always

the "language" spoken between hosts and routers. All hosts that want to join multicast groups, and

all routers with interfaces on subnets containing multicast hosts, must implement IGMP.

Fig: Shows IGMP working principle


3 | P a g e

It is a control protocol like ICMP, sharing some functional similarities. Like ICMP, it is responsible

for managing higher-level data exchanges. IGMP messages are encapsulated in IP headers like

ICMP (with a protocol number of 2), but unlike ICMP, the messages are limited to the local data

link. This is guaranteed both by the IGMP implementation rules, which require that a router never

forward an IGMP message, and by always setting the TTL in the IP header to 1. Membership

Report messages are sent to indicate that a host wants to join a group. The messages are sent when a

host first joins a group, and sometimes in response to a Membership Query from a local router.

Multicast sessions are identified in the routers by a (source, group) pair of addresses, where source

is the address of the session's originator and group is the Class D group address. If the local

multicast router does not already have knowledge of the multicast session the host wants to join, it

sends a request upstream toward the source. The data stream is received, and the router begins

forwarding the stream onto the subnet of the host that requested membership.

Fig: The above figure shows the IGMP message format.

3.4. Multicast packet forwarding and Routing

Multicast Forwarding

Like any other router, the two fundamental functions of a multicast router are route discovery and

packet forwarding. This section addresses the unique requirements of multicast forwarding, and

the next section looks at the requirements for multicast route discovery.

Unicast packet forwarding involves forwarding a packet toward a certain destination. Unless

certain policies are configured, a unicast router is uninterested in the source of the packet. The

packet is received, the destination IP address is examined, a longest-match route lookup is

performed, and the packet is forwarded out a single interface toward the destination.

Instead of forwarding packets toward a destination, multicast routers forward packets away from a

source. This distinction may sound trifling at first glance, but it is actually essential to correct

multicast packet forwarding. A multicast packet is originated by a single source but is destined for


4 | P a g e

a group of destinations. At a particular router, the packet arrives on some incoming interface and

copies of the packet may be forwarded out multiple outgoing interfaces.

Fig : Explains multicast looping situation

If a loop exists so that one or more of the forwarded packets makes its way back to the incoming

interface, the packet is again replicated and forwarded out the same outgoing interfaces. The result

can be a multicast storm, in which packets continue to loop and be replicated until the TTL

expires. It is the replication that makes a multicast storm potentially so much more severe than a

simple unicast loop. Therefore, all multicast routers must be aware of the source of the packet and

must only forward packets away from the source. A useful and commonly used terminology is that

of upstream and downstream. Multicast packets Should always flow downstream from the source

to the destinations, never upstream toward the source. To ensure this behavior, each multicast

router maintains a multicast forwarding table in which (source, group) or (S, G) address pairs are

recorded. Packets from a particular source and destined for a particular group should always arrive

on an upstream interface and be forwarded out one or more downstream interfaces. By definition,

an upstream interface is closer to the source than any downstream interface. If a router receives a

multicast packet on any interface other than the upstream interface for that packet's source, it

quietly discards the packet.

Multicast Routing

The function of a multicast routing protocol is to determine the upstream interface—the closest

interface to the source. Because multicast routing protocols concern themselves with the shortest

path to the source, rather than the shortest path to the destination, the procedure of forwarding

multicast packets is known as reverse path forwarding. The easiest way for a multicast routing


5 | P a g e

protocol to determine the shortest path to a source is to consult the unicast forwarding table.

However, as the last section pointed out, multicast packets are forwarded based on the information

in a separate multicast forwarding table. The reason for this is that the router must record not only

the upstream interface for the source of a particular (S, G) pair, but also the downstream interfaces

associated with the group.

The simplest way to forward packets would be to merely declare all interfaces except the upstream

interface to be downstream interfaces. This approach, known as reverse path broadcasting (RPB),

has obvious shortcomings. As the name implies, packets are effectively broadcast to all subnets on

the routed internetwork. Group members probably exist on only a subset of the subnets—probably

small subset. Flooding a copy of every multicast packet onto every subnet not only defeats the

objective of multicasting to deliver packets only to interested receivers, but also actually defeats

the purpose of routing itself.

Implicit Joins Versus Explicit Joins

As was previously observed, members may join or leave a group at any time during the lifetime of

a multicast session, and as a result, the multicast tree can change dynamically. It is the job of the

multicast routing protocol to manage this changing tree, adding branches as members join and

pruning branches as members leave.

The multicast routing protocol may accomplish this task by using either an implicit or explicit join

strategy. Implicit joins are sender-initiated, whereas explicit joins are receiver-initiated. Multicast

routing protocols that maintain their trees by implicit joins are commonly called broadcast-and-

prune or flood-and-prune protocols. When a sender first initiates a session, each router in the

Internet work uses reverse path broadcasting to forward the packets out every interface except the

upstream interface. As a result, the multicast session initially reaches every router in the

internetwork. When a router receives the multicast traffic, it uses IGMP to determine whether

there are any group members on its directly connected subnets. If there are not, and there are no

downstream routers to which the traffic must be forwarded, the router sends a poison-reverse

message called a prune message to its upstream neighbor. That upstream neighbor then stops

forwarding the session traffic to the pruned router. If the neighbor also has no group members on

its subnets and all downstream routers have pruned themselves from the tree, that router also sends

prune message upstream. The result is that the multicast tree is eventually pruned of all branches

that do not lead to routers with attached group members. Members. Figure 5-20 illustrates the

broadcast-and prune Technique.


6 | P a g e

Fig (a): Multicast data flooding to all multicast router

Fig (b) : Multicast prune message from multicast routers

Fig (c): Multicast sessions on router:


7 | P a g e

For every (S, G) pair in its forwarding table, every router in the internetwork maintains state for

each of its downstream interfaces. The state is either forward or prune. The prune state has a timer

associated with it, and when the timer expires, the session traffic is again forwarded to neighbors

on that interface. Each neighbor once again checks for group members and floods the traffic to its

own downstream neighbors. If new group members are discovered, the traffic continues to be

accepted. Otherwise, a new prune message is sent upstream.

The broadcast-and-prune technique is better suited to dense topologies than to sparse ones. The

initial flooding to all routers, the periodic re flooding as prune states expire, and the maintenance

of prune states all contribute to a waste of network resources when many or most branches are

pruned. There is also a strong element of illogic in the maintenance of prune state, requiring

routers that are not participating in the multicast tree to remember that they are not a part of the

tree.

A better technique for sparse topologies is the explicit join, in which the routers with directly

attached group members initiate the join. When a group member signals its router, via IGMP, that

it wants to join a group, the router sends a message upstream toward the source, indicating the

join. In contrast to a prune message, this message can be thought of as a graft message; the router

sending the Message is grafting itself onto the tree. If all of a router's group member’s leave, and

the router has no downstream neighbors active on the group, the router prunes itself from the tree.

Because traffic is never forwarded to any router that does not explicitly request the traffic, network

resources are conserved. And because prune state is not kept by non participating routers, overall

memory is conserved. As a result, explicit joins scale better in sparse topologies. The argument

can be made, of course, that explicit joins always scale better, regardless of whether the topology

is sparse or dense.

Source-Based Trees versus Shared Trees

Some multicast routing protocols construct separate multicast trees for every multicast source.

These trees are source-based trees, because they are rooted at the source. The multicast trees that

have been presented in previous sections are source-based trees. You have learned that multicast

trees can change during the life time of a multicast session as members join and leave the group,

and that it is the responsibility of the multicast routing protocol to dynamically adapt the tree to

these changes. However, some parts of the tree might not change.

Figure 3.4.4 shows two multicast trees super imposed onto the same internetwork. Notice that

although the trees have different sources and different members, their paths pass through at least

one common router.


8 | P a g e

Figure: These Two Multicast Trees Have Different Shapes, but They Both Pass Through the Single

Router RP

Shared trees take advantage of the fact that many multicast trees can share a single router within the

network. Rather than root each tree at its source, the tree is rooted at a shared router called

(depending on the protocol) the rendezvous point (RP) or core. The RP is predetermined and

strategically located in the internetwork. When a source begins a multicast session, it registers with

the RP. It may be up to the source's directly connected router to determine the shortest path to the

RP, or it may be up to the RP to find the shortest path to each source. Explicit joins are used to build

trees from routers with attached group members to the RP. Rather than the (S, G) pair recorded for

source-based trees, the shared trees use a (*, G) state. This state reflects that fact that the RP is the

root of the tree to the group and that there may be many sources upstream of the RP. More

importantly, a separate (S, G) pair must be recorded for each distinct source on a source-based tree.

Shared trees, on the other hand, record only a single (*, G) for each group.

Administrative Scoping

Administrative scoping, described in RFC 2365,[7] takes a different approach to bounding multicast

traffic. Rather than filter on TTL values, a range of Class D addresses is reserved for scoping.

Filtering on these group addresses can then set boundaries. The reserved range of multicast

addresses is 239.0.0.0–239.255.255.255.


9 | P a g e

The administratively scoped address space can be further subdivided in a hierarchical manner. For

example, RFC 2365 suggests using the range 239.255.0.0/16 for local or site scope and the range

239.192.0.0/14 for organization wide scope. An enterprise is, however, free to utilize the address

space in any way it sees fit. In this regard, the reserved Class D range is similar to the RFC 1918

addresses reserved for private use. And like those addresses, the administratively scoped multicast

address space is non unique. Therefore, it is important to set filters for 239.0.0.0–239.255.255.255

so that none of the addresses in that range leak into the public Internet.

We have encountered both TTL scoping and address-based scoping already in this chapter and

elsewhere in this book. Recall that the TTL for IGMP and OSPF packets is always set to 1 to

prevent the packets from being forwarded by any receiving router. In this way, the scope is set to

the local subnet. Similarly, routers do not to forward packets whose addresses are in the range

224.0.0.0–224.0.0.255. This range, which includes all the addresses shown in Table earlier, is also

scoped to the local subnet.

Types of Multicast Routing Protocols:

Currently, five IP multicast routing protocols are in various stages of development and deployment:

1 Distance Vector Multicast Routing Protocol (DVMRP)

2 Multicast OSPF (MOSPF)

3 Core-Based Trees (CBT)

4 Protocol-Independent Multicast, Dense Mode (PIM-DM)

5 Protocol-Independent Multicast, Sparse Mode (PIM-SM)

Introduction to Protocol Independent Multicast (PIM)

Operation of Protocol Independent Multicast, Dense Mode (PIM-DM):

PIMv2 routers use Hello messages to discover neighbors. When a PIMv2 router (either PIM-DM or

PIMSM) becomes active, it periodically sends a Hello message on every interface on which PIM is

configured. PIMv1 routers have the same functionality, except that they use Query messages. The


10 | P a g e

Hello (or Query) messages contain a hold time, which specifies the maximum time the neighbor

should wait to hear a subsequent message before declaring the originating router dead. Both the

PIMv2 Hello interval and the PIMv1 Query interval are 30 seconds in Cisco IOS Software by

default. They cane changed on a per-interface basis with the command ip pim query-interval. The

hold time is set automatically to 3.5 times the Hello/Query interval. When a source begins sending

multicast packets, PIM-DM uses flood-and-prune to build the multicast tree. As each PIM-DM

router receives a multicast packet, the router adds an entry to its multicast forwarding table.

Ultimately, the packets are flooded to all leaf routers—that is, all routers that have No downstream

PIM neighbors. If a leaf router receives a multicast packet for which it has no attached group

members, the router must prune itself from the multicast tree. It does this by sending a Prune

message to the upstream neighbor toward the source. The destination address of the Prune message

is 224.0.0.13, and the address of the upstream router is encoded within the message. If that upstream

neighbor has no attached members of the packet's group, and either has no other downstream

neighbors or has received prunes from all of its downstream neighbors, it sends a Prune message to

its own upstream neighbor toward the source. Referring back to the bulleted list of PIMv2 message

types earlier in this section, we will see that there is no "Prune" message type. Instead, there is a

Join/Prune. This is a single message type that has separate fields for listing groups to be joined and

groups to be pruned. This section continues to use "Prune message" and "Join message" for clarity,

but you should be aware that a Prune message is actually a Join/Prune with a group address listed in

the prune section. Likewise, a Join message is a Join/Prune message with a group address in the

Join field.

Fig : figure shows the principle of Dense mode.


11 | P a g e

Operation of Protocol Independent Multicast, Sparse Mode (PIM-SM)

Figure shows a situation in which a source-based tree might be preferred over a shared tree. In this

topology, the source and destination are closer to each other than they are to the core router at

which the shared tree is rooted. A source-based tree directly between the source and destination is

preferable, if only the associated overhead could be reduced.

A Source-Based Tree Might Be Preferable to the Shared Tree in This Internetwork

PIM-SM supports both shared and source-based trees, which is the primary reason it is presently the

multicast routing protocol of choice in most modern internetworks.

Fig: principle of Sparse mode.


12 | P a g e

Notice that three of the messages (Hello, Join/Prune, and Assert) also are used by PIM-DM. There

are four messages unique to PIM-SM, just as there are two messages (Graft and Graft-Ack) used

only by PIM-DM.

Several functions are common to PIM-SM and PIM-DM:

l Neighbor discovery through exchange of Hello messages

l Recalculation of the RPF interface when the unicast routing table changes

l Election of a designated router on multi access networks

l The use of Prune Overrides on multi access networks

These functions are all described in the PIM-DM section and so are not described again here. Unlike

PIM-DM, PIM-SM uses explicit joins, making the creation of both shared and source-based multicast

trees more efficient. Finding the Rendezvous Point As we have already learned, a shared tree is rooted

at a router somewhere in the multicast internetwork rather than at the source. CBT calls this router the

core, and PIM-SM calls it the rendezvous point (RP). Before a shared tree can be established, the joining

routers must know how to find the RP. The router can learn the address of the RP in three ways:

l The RP address can be statically configured on all routers.

2 An open-standard bootstrap protocol can be used to designate and advertise the RP.

3 The Cisco-proprietary Auto-RP protocol can be used to designate and advertise the RP.

As with static routes, statically configuring RP addresses on all routers has the advantage of providing

very specific control of the internetwork, but at the cost of high administrative overhead.

PIM-SM and Shared Trees

The major difference between a shared tree route entry and a source-based or SPT route entry is that

the shared tree entry is not source-specific—in keeping with the fact that many sources share the

same tree. Therefore, the entry is a (*, G) pair, where the asterisk is a wildcard representing any and

all source addresses sending to the group G.

When a PIM-SM DR receives an IGMP Membership Report from a host requesting a join to a

multicast group, it first checks to see whether there is already an entry in the multicast table for the

group. If there is an entry for the group, the interface on which the IGMP message was received is

added to the entry as an outgoing interface. No other action is necessary. If no entry exists, a (*, G)

entry is created for the group, and the outgoing interface is added. The router then looks up the

group-to-RP mapping for this group , the unicast routing table is consulted for the route to the

specified RP, and the upstream interface to the RP is added to the incoming (RPF) interface.


13 | P a g e

Multicast VPN (MVPN)

The Multicast VPN (MVPN) provides the ability to support multicast over a Layer 3 Virtual Private

Network (VPN). As enterprises extend the reach of their multicast applications, Ethernet Network

can accommodate these enterprises over their Multiprotocol Label Switching (MPLS) core/access

network. IP multicast is used to stream video, voice, and data to an MPLS VPN network core.

Because Layer 3 VPNs support only unicast traffic connectivity, deploying in conjunction with a

Layer3 VPN allows tooffer both unicast and multicast connectivity to Layer 3 VPN customers.

Operation:

MVPN allows configuring and supporting multicast traffic in MPLS Layer3 Virtual Private

Network (VPN) environment. This feature supports routing and forwarding of multicast packets for

each individual VPN routing and forwarding (VRF) instance, and it also provides a mechanism to

transport VPN multicast packets across the service provider backbone.

An MVPN allows an enterprise to transparently interconnect its private network across the network

backbone of a Ethernet Network The use of an MVPN to interconnect an enterprise network in this

way does not change the way that enterprise network is administered, nor does it change general

enterprise connectivity.

Benefits of Multicast VPN

Provides a scalable solution to dynamically send multicast traffic to multiple locations.

Provides high-speed multicast delivery over layer 3VPN.

Provides connectivity through a shared infrastructure.

Multicast VPN Routing and Forwarding

MVPN introduces multicast routing information to the VPN routing and forwarding table. When a

provider edge (PE) router receives multicast data or control packets from a customer edge (CE)

router, forwarding is performed according to the information in the Multicast VPN routing and

forwarding instance (MVRF). MVPN does not use label switching. A set of MVRFs that can send

multicast traffic to each other constitutes a multicast domain.

Multicast Distribution Trees

MVPN establishes a static default MDT for each multicast domain. The default MDT defines the

path used by PE routers to send multicast data and control messages to every other PE router in the

multicast domain.

MVPN also supports the dynamic creation of MDTs for high-bandwidth transmission. Data MDTs

are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal

traffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can be

configured on a per-router or as per-VRF basis. When the multicast transmission exceeds the

defined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol


14 | P a g e

(UDP) message, which contains information about the data MDT to all routers on the default MDT.

The statistics to determine whether a multicast stream has exceeded the data MDT threshold are

examined once every second.

Data MDTs are created only for (S, G) multicast route entries within the VRF multicast routing

table. They are not created for (*, G) entries regardless of the value of the individual source data

rate.

Multicast Tunnel Interface

MVRF, which is created per multicast domain, requires the router to create a tunnel interface from

which all MVRF traffic is sourced. A multicast tunnel interface is an interface the MVRF uses to

access the multicast domain. One tunnel interface is created per MVRF.

Multicast Operational Overview

This diagram shows the recommended solution for multicast traffic within Ethernet Network. In this

scenario, there may be receivers and sources at any site within the customer intranet.

In the above example there is a video source at one site and a receiver at three sites. In reality there

may be multiple receivers at various sites across the intranet.

References:

Routing TCP/IP, Volume II (CCIE Professional Development) By Jeff Doyle CCIE #1919, Jennifer

DeHaven Carroll CCIE #1402

Technology

Basics of multicasting and its implementation on ethernet networks