Basics of multicasting and its implementation on ethernet networks
Upcoming SlideShare
Loading in...5
×
 

Basics of multicasting and its implementation on ethernet networks

on

  • 2,552 views

Basics of Multicasting and its implementation on Ethernet Networks

Basics of Multicasting and its implementation on Ethernet Networks

Statistics

Views

Total Views
2,552
Views on SlideShare
2,552
Embed Views
0

Actions

Likes
0
Downloads
87
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • good
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Basics of multicasting and its implementation on ethernet networks Basics of multicasting and its implementation on ethernet networks Document Transcript

  • Basics of Multicasting and its implementation on Ethernet Networks By V.Sasank Chaitanya Kumar Network Engineer Reliance Communications v.sasank.ece@gmail..comAbstract:The project is intended to give a basic overview on Multicast Communication. It further gives a briefintroduction on IP multicast, packet flow mechanisms, General architecture & Functional Overview ofMulticasting over metro Ethernet.In today’s modern world multicasting has influence on triple play services. The requirements initiallystarted with exchange of information from point to point (uni-casting). The world is now movingtowards multicasting because of its applications and features.To realize such complex type of communication it becomes imperative to understand the basic conceptsof multicasting. This paper gives a brief descriptions of the basic terminologies, key concepts, shortintroduction to such definitions / Specifications / standards and Test Setups used to optimize and runcomplex communication networks.
  • Basics of Multicasting and its implementation over Ethernet NetwoksIntroduction:Multicasting is the process of sending data to a group of receivers. It might be argued that unicastingand broadcasting are subsets of multicasting. In the case of unicasting, there is only a single memberOf 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 itis multicasting. A transmitter sends data on a certain frequency, and some group of receiversAcquires 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 thoseWho listen to the correct frequency actually receive it.If we observe Interest in multicasting has really taken off, as enterprises presently increasing demandsfor 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
  • Basics of Multicasting and its implementation over Ethernet Netwoks 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-addressMechanism 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
  • Basics of Multicasting and its implementation over Ethernet NetwoksIt is a control protocol like ICMP, sharing some functional similarities. Like ICMP, it is responsiblefor managing higher-level data exchanges. IGMP messages are encapsulated in IP headers likeICMP (with a protocol number of 2), but unlike ICMP, the messages are limited to the local datalink. This is guaranteed both by the IGMP implementation rules, which require that a router neverforward an IGMP message, and by always setting the TTL in the IP header to 1. MembershipReport messages are sent to indicate that a host wants to join a group. The messages are sent when ahost 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 sourceis the address of the sessions originator and group is the Class D group address. If the localmulticast router does not already have knowledge of the multicast session the host wants to join, itsends a request upstream toward the source. The data stream is received, and the router beginsforwarding 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
  • Basics of Multicasting and its implementation over Ethernet Netwoksa group of destinations. At a particular router, the packet arrives on some incoming interface andcopies of the packet may be forwarded out multiple outgoing interfaces.Fig : Explains multicast looping situationIf a loop exists so that one or more of the forwarded packets makes its way back to the incominginterface, the packet is again replicated and forwarded out the same outgoing interfaces. The resultcan be a multicast storm, in which packets continue to loop and be replicated until the TTLexpires. It is the replication that makes a multicast storm potentially so much more severe than asimple unicast loop. Therefore, all multicast routers must be aware of the source of the packet andmust only forward packets away from the source. A useful and commonly used terminology is thatof upstream and downstream. Multicast packets Should always flow downstream from the sourceto the destinations, never upstream toward the source. To ensure this behavior, each multicastrouter maintains a multicast forwarding table in which (source, group) or (S, G) address pairs arerecorded. Packets from a particular source and destined for a particular group should always arriveon 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 amulticast packet on any interface other than the upstream interface for that packets source, itquietly discards the packet. Multicast RoutingThe function of a multicast routing protocol is to determine the upstream interface—the closestinterface to the source. Because multicast routing protocols concern themselves with the shortestpath to the source, rather than the shortest path to the destination, the procedure of forwardingmulticast packets is known as reverse path forwarding. The easiest way for a multicast routing 4|Page
  • Basics of Multicasting and its implementation over Ethernet Netwoksprotocol 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 informationin a separate multicast forwarding table. The reason for this is that the router must record not onlythe upstream interface for the source of a particular (S, G) pair, but also the downstream interfacesassociated with the group.The simplest way to forward packets would be to merely declare all interfaces except the upstreaminterface 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 onthe routed internetwork. Group members probably exist on only a subset of the subnets—probablysmall subset. Flooding a copy of every multicast packet onto every subnet not only defeats theobjective of multicasting to deliver packets only to interested receivers, but also actually defeatsthe purpose of routing itself. Implicit Joins Versus Explicit JoinsAs was previously observed, members may join or leave a group at any time during the lifetime ofa multicast session, and as a result, the multicast tree can change dynamically. It is the job of themulticast routing protocol to manage this changing tree, adding branches as members join andpruning branches as members leave.The multicast routing protocol may accomplish this task by using either an implicit or explicit joinstrategy. Implicit joins are sender-initiated, whereas explicit joins are receiver-initiated. Multicastrouting 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 theInternet work uses reverse path broadcasting to forward the packets out every interface except theupstream interface. As a result, the multicast session initially reaches every router in theinternetwork. When a router receives the multicast traffic, it uses IGMP to determine whetherthere are any group members on its directly connected subnets. If there are not, and there are nodownstream routers to which the traffic must be forwarded, the router sends a poison-reversemessage called a prune message to its upstream neighbor. That upstream neighbor then stopsforwarding the session traffic to the pruned router. If the neighbor also has no group members onits subnets and all downstream routers have pruned themselves from the tree, that router also sendsprune message upstream. The result is that the multicast tree is eventually pruned of all branchesthat do not lead to routers with attached group members. Members. Figure 5-20 illustrates thebroadcast-and prune Technique. 5|Page
  • Basics of Multicasting and its implementation over Ethernet NetwoksFig (a): Multicast data flooding to all multicast routerFig (b) : Multicast prune message from multicast routersFig (c): Multicast sessions on router: 6|Page
  • Basics of Multicasting and its implementation over Ethernet Netwoks For every (S, G) pair in its forwarding table, every router in the internetwork maintains state foreach of its downstream interfaces. The state is either forward or prune. The prune state has a timerassociated with it, and when the timer expires, the session traffic is again forwarded to neighborson that interface. Each neighbor once again checks for group members and floods the traffic to itsown downstream neighbors. If new group members are discovered, the traffic continues to beaccepted. Otherwise, a new prune message is sent upstream.The broadcast-and-prune technique is better suited to dense topologies than to sparse ones. Theinitial flooding to all routers, the periodic re flooding as prune states expire, and the maintenanceof prune states all contribute to a waste of network resources when many or most branches arepruned. There is also a strong element of illogic in the maintenance of prune state, requiringrouters that are not participating in the multicast tree to remember that they are not a part of thetree.A better technique for sparse topologies is the explicit join, in which the routers with directlyattached group members initiate the join. When a group member signals its router, via IGMP, thatit wants to join a group, the router sends a message upstream toward the source, indicating thejoin. In contrast to a prune message, this message can be thought of as a graft message; the routersending the Message is grafting itself onto the tree. If all of a routers group member’s leave, andthe 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, networkresources are conserved. And because prune state is not kept by non participating routers, overallmemory is conserved. As a result, explicit joins scale better in sparse topologies. The argumentcan be made, of course, that explicit joins always scale better, regardless of whether the topologyis sparse or dense. Source-Based Trees versus Shared TreesSome 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 thathave been presented in previous sections are source-based trees. You have learned that multicasttrees 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 tothese 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 thatalthough the trees have different sources and different members, their paths pass through at leastone common router. 7|Page
  • Basics of Multicasting and its implementation over Ethernet NetwoksFigure: These Two Multicast Trees Have Different Shapes, but They Both Pass Through the SingleRouter 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 sources 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
  • Basics of Multicasting and its implementation over Ethernet NetwoksThe administratively scoped address space can be further subdivided in a hierarchical manner. Forexample, RFC 2365 suggests using the range 239.255.0.0/16 for local or site scope and the range239.192.0.0/14 for organization wide scope. An enterprise is, however, free to utilize the addressspace in any way it sees fit. In this regard, the reserved Class D range is similar to the RFC 1918addresses reserved for private use. And like those addresses, the administratively scoped multicastaddress space is non unique. Therefore, it is important to set filters for 239.0.0.0–239.255.255.255so 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 andelsewhere in this book. Recall that the TTL for IGMP and OSPF packets is always set to 1 toprevent the packets from being forwarded by any receiving router. In this way, the scope is set tothe local subnet. Similarly, routers do not to forward packets whose addresses are in the range224.0.0.0–224.0.0.255. This range, which includes all the addresses shown in Table earlier, is alsoscoped 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 orPIMSM) becomes active, it periodically sends a Hello message on every interface on which PIM isconfigured. PIMv1 routers have the same functionality, except that they use Query messages. The 9|Page
  • Basics of Multicasting and its implementation over Ethernet NetwoksHello (or Query) messages contain a hold time, which specifies the maximum time the neighborshould wait to hear a subsequent message before declaring the originating router dead. Both thePIMv2 Hello interval and the PIMv1 Query interval are 30 seconds in Cisco IOS Software bydefault. They cane changed on a per-interface basis with the command ip pim query-interval. Thehold time is set automatically to 3.5 times the Hello/Query interval. When a source begins sendingmulticast packets, PIM-DM uses flood-and-prune to build the multicast tree. As each PIM-DMrouter 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 downstreamPIM neighbors. If a leaf router receives a multicast packet for which it has no attached groupmembers, the router must prune itself from the multicast tree. It does this by sending a Prunemessage to the upstream neighbor toward the source. The destination address of the Prune messageis 224.0.0.13, and the address of the upstream router is encoded within the message. If that upstreamneighbor has no attached members of the packets group, and either has no other downstreamneighbors or has received prunes from all of its downstream neighbors, it sends a Prune message toits own upstream neighbor toward the source. Referring back to the bulleted list of PIMv2 messagetypes earlier in this section, we will see that there is no "Prune" message type. Instead, there is aJoin/Prune. This is a single message type that has separate fields for listing groups to be joined andgroups 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 inthe prune section. Likewise, a Join message is a Join/Prune message with a group address in theJoin field. Fig : figure shows the principle of Dense mode. 10 | P a g e
  • Basics of Multicasting and its implementation over Ethernet Netwoks 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 InternetworkPIM-SM supports both shared and source-based trees, which is the primary reason it is presently themulticast routing protocol of choice in most modern internetworks. Fig: principle of Sparse mode. 11 | P a g e
  • Basics of Multicasting and its implementation over Ethernet Netwoks 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 networksThese functions are all described in the PIM-DM section and so are not described again here. UnlikePIM-DM, PIM-SM uses explicit joins, making the creation of both shared and source-based multicasttrees more efficient. Finding the Rendezvous Point As we have already learned, a shared tree is rootedat a router somewhere in the multicast internetwork rather than at the source. CBT calls this router thecore, and PIM-SM calls it the rendezvous point (RP). Before a shared tree can be established, the joiningrouters 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 providingvery 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
  • Basics of Multicasting and its implementation over Ethernet NetwoksMulticast VPN (MVPN)The Multicast VPN (MVPN) provides the ability to support multicast over a Layer 3 Virtual PrivateNetwork (VPN). As enterprises extend the reach of their multicast applications, Ethernet Networkcan accommodate these enterprises over their Multiprotocol Label Switching (MPLS) core/accessnetwork. 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 aLayer3 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 PrivateNetwork (VPN) environment. This feature supports routing and forwarding of multicast packets foreach individual VPN routing and forwarding (VRF) instance, and it also provides a mechanism totransport VPN multicast packets across the service provider backbone.An MVPN allows an enterprise to transparently interconnect its private network across the networkbackbone of a Ethernet Network The use of an MVPN to interconnect an enterprise network in thisway does not change the way that enterprise network is administered, nor does it change generalenterprise 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 ForwardingMVPN introduces multicast routing information to the VPN routing and forwarding table. When aprovider 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 andforwarding instance (MVRF). MVPN does not use label switching. A set of MVRFs that can sendmulticast traffic to each other constitutes a multicast domain. Multicast Distribution TreesMVPN establishes a static default MDT for each multicast domain. The default MDT defines thepath used by PE routers to send multicast data and control messages to every other PE router in themulticast domain.MVPN also supports the dynamic creation of MDTs for high-bandwidth transmission. Data MDTsare intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimaltraffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can beconfigured on a per-router or as per-VRF basis. When the multicast transmission exceeds thedefined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol 13 | P a g e
  • Basics of Multicasting and its implementation over Ethernet Netwoks (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, JenniferDeHaven Carroll CCIE #1402 14 | P a g e