Basicsofmulticastinganditsimplementationonethernetnetworks

Basics of Multicasting and its implementation on Ethernet Networks

By

V.Sasank Chaitanya Kumar
Network Engineer
Reliance Communications
v.sasank.ece@gmail..com

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

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

1|Page


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

2|Page


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

3|Page


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

4|Page


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.

5|Page


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

Fig (b) : Multicast prune message from multicast routers

Fig (c): Multicast sessions on router:

6|Page


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.

7|Page


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.

8|Page


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

9|Page


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.

10 | 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.

11 | 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.

12 | 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

13 | 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

14 | P a g e

Basicsofmulticastinganditsimplementationonethernetnetworks

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to Basicsofmulticastinganditsimplementationonethernetnetworks (20)

Basicsofmulticastinganditsimplementationonethernetnetworks