Welcome to the Frequently Asked Questions (FAQ) File for Multicasting

What is Multicasting ?

Multicasting is a technique developed to send packets from one location in the Internet to many other locations, without any unnecessary packet duplication. In multicasting, one packet is sent from a source and is replicated as needed in the network to reach as many end-users as necessary.

The concept of a group is crucial to multicasting. Every multicast requires a multicast group; the sender (or source) transmits to the group address, and only members of the group can receive the multicast data. A group is defined by a Class D address.

Multicasting is not the same as broadcasting on the Internet or on a LAN. In networking jargon, broadcast data are sent to every possible receiver, while multicast packets are sent only to receivers that want them.

Why Should Anyone be Interested in Multicasting ?

Multicasting is useful because it conserves bandwidth, in many cases the most expensive part of network operations. It does this by replicating packets as needed within the network, thereby not transmitting unnecessary packets. Multicasting is the most economical technique for sending a packet stream (which could be audio, video, or data) from one location to many other locations on the Internet simultaneously. Its commercial applications include webcasting over the Internet (one to many multicasts), multiparty computer games and conference calls (many to many multicasts) and communication between devices behind the scenes (the focus of recent work on small group multicast, also called explicit multicast or Xcast).

What is the penetration of Multicast into the Internet ?

Unfortunately, not every Internet Service Provider (ISP) offers multicasting at present. Information about the current status and pentation of Multicast into the Internet is provided on our Multicast Status Page. At present (mid-April, 2001), the penetration of multicast into the commodity Internet seems to be between 3 and 5 per cent. This page also provides a dynamically updated list of Autonomous Systems with multicast routing as seen from Multicast Technologies.

A list of ISPs and other service providers supporting multicast is available at http://www.multicast-isp-list.com/. If your ISP supports multicasting and is not on the list, suggest that they join (inclusion is free if you answer the questions).

What Multicast Content is available ?

Multicast content (primarily streaming audio and video) is available from a number of sources, including On-the-I.com, our streaming audio broadcast service. In addition, we (Multicast Tech) maintain listings of all permanent multicast broadcasts at MulticastAudio.com and Multicast Video.com and Lucy Lynch of the University of Oregon provides a list of regular multicast content providers, together with a calendar of special multicast events. This web page also includes instructions on how to submit your events, if you are sourcing multicasts.

What if I want more information ?

The following books may be useful :

General Information on Multicast :

"Multicast Networking & Applications" by C. Kenneth Miller, 1999, ISBN 0-201-30979-3.

"Multicast Communication: Protocols, Programming, and Applications" by Ralph Wittmann and Martina Zitterbart, 2001, ISBN 1-55860-645-9.

"Multicast and Group Security" by Thomas Hardjono, Lakshminath R. Dondeti, 2003, ISBN: 1580533426


Planning, Developing and Debugging Multicast Networks :

"Cisco Multicast Routing and Switching", by William Parkhurst, 1999, ISBN 0-07-134647-3.

"Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks" by Beau Williamson, 2000, ISBN 1.57870-077-9.

"Interdomain Multicast Routing" by Edwards, Giuilano and Wright, 2002, ISBN 0-201-74612-3.


Programming Multicast Applications :

"Multicast Sockets" by David Makofske, Kevin Almeroth, 2002, ISBN: 155860846X.

What IETF working groups deal with multicast ?

There are quite a number :

Audio Video Transport or AVT, deals with streaming audio, video and multimedia using the Real Time Protocol (RTP).
Reliable Multicast Transport or RMT, deals with reliable transport proposals.
PIM deals with the Protocol Independent Multicast specification.
MBONED deals with issues of MBone deployment, and tends to have the most discussion about operational multicast issues.
MAGMA is responsible for IGMP v3 and MLD v2 (and IDMR was phased out).
There is a also an IETF Working Group on Multicast Security.
Finally, the SSM working group deals with Source Specific Multicasting

What is unicasting ?

Unicasting is the traditional method of data transport on the Internet, between one specific source and one specific receiver. The vast majority of all data transmissions on the Internet today, including all TCP, FTP and HTTP traffic, are unicast.

Can multicasting use TCP ?

No. Multicasting uses UDP (User Datagram Protocol) as its underlying transport protocol.

TCP (transmission control protocol) uses frequent transmission of acknowledgement (ACK) packets between the receiver and the transmitter for flow control, and also to determine if packets have arrived safely, in order that dropped packets can be retransmitted. This form of feedback and retransmission does not scale well into the one to many case, although some forms of reliable multicast do use negative acknowledgements (NACKs) to signal the need for retransmission.

UDP is a simpler protocol where there is no acknowledgement of the success or failure of the transmission of any packet, and no retransmission, at the transport layer. (In the jargon, UDP is called "best effort.") Strictly speaking, therefore, multicast data transport is unreliable, and any reliability must be engineered-in at a higher level.

What Multicast Routing Protocols are in Use Today ?

The protocols for multicast data transport have evolved over the years. The original multicast proposal was for dense mode, where all possible receivers are assumed to want multicast traffic initially and so multicast traffic is flooded throughout the network until receivers specifically request to leave the multicast group and stop receiving the traffic (i.e., are "pruned"). This "flood and prune" technique is relatively straightforward to implement, but is not very efficient as the size of the network increases (it "does not scale," in the jargon). The first multicast routing protocol in common use, DVMRP (for Distance Vector Multicast Routing Protocol), used this technique, and was the protocol of the MBONE for years.

More recently, a sparse mode protocol has come into common use. In sparse mode, no receiver is assumed to want multicast traffic until it explicitly asks for it. There is thus no unwanted flooding of traffic throughout the network, and so the protocol scales much better and is more usable with large networks. The new standard for multicast traffic is Protocol Independent Multicast - Sparse Mode - or PIM-SM. This protocol is called "Protocol Independent" as it uses the unicast routing information to route multicast traffic, regardless of how the unicast routing tables are constructed. There is also a PIM Dense Mode (PIM-DM), which combines the simplicity of the old DVMRP with the protocol independence and other improvements in PIM-SM for those situations where a Dense Mode protocol might be appropriate. Another protocol, which mixes the properties of Dense and Sparse Mode, but is only appropriate for domains using the Open Shortest Path First (OSPF) unicast routing protocol, is Multicast - OSPF, or MOSPF.

• Can I use multicast if my computer is not connected to a enabled multicast router ?

  Most office LANs are now Ethernets, and you do not need a router to multicast on an Ethernet. However, if your LAN is a set of Ethernets connected by bridges, hubs or switches, your multicast performance will depend on the details of the network, what sort of equipment is in use, and how it is configured. You will not be able to send or receive multicasts to or from places off of your LAN in any case, though.
  
  If you want to multicast to or from the wider world, and your network is not connected to the multicast enabled Internet, all is not lost. You can still use tunneling, where multicast packets are encapsulated in unicast packets over links that are not multicast enabled. Tunneling was used extensively in the old MBONE. It is much better to use native multicasting and avoid tunneling if possible.
  
  However, we here at Multicast Technologies do provide multicast transit and connectivity via tunnels. If you are interested, please send e-mail to info@multicasttech.com.

Why is the Protocol called "Protocol Independent" ?

The early DVMRP routing protocol actually constructs its own routing tables, independently of the unicast routing tables. Although this offers certain advantages, it is wasteful of router resources. Protocol Independent Multicast (PIM) is so-called because it uses the unicast routing information to route multicast data, regardless of the routing protocol used to derive the unicast routing data.

• What is a PIM-SM Rendezvous Point (RP)?

  PIM-SM requires at least one Rendezvous Point, or RP, per domain to function. Initially, receivers do not need to know the location of a source to function, as the address of the RP is distributed throughout the domain. When a receiver wants to join a group, G, it sends a IGMP member report to its first hop router, which sends a (*,G) join to the RP. (In case there is more than one first hop router, one is elected to be the Designated Router, or DR, and it carries out this task.) Similarly, when a source wants to begin transmitting to a group, its DR encapsulates and unicasts the multicast data to the RP, which strips off the encapsulation and multicasts it to the group members (if any).
  
  Note that the RP is always a router, while a source is a computer attached to a router, so that in general an RP is not a source directly.

  
  
• What is a Shared Tree (ST), and a Shortest Path Tree (SPT) ?

  The Shared Tree (also known as the Core Based Tree, or CBT, from the different routing protocol described in RFC 2189) is the set of paths from the RP to the complete set of group members.
  
  The Shortest Path Tree is the similar set of paths from a group source to the complete set of group members. It is called "shortest path" as the unicast routing table is used to determine the best route between the receiver and the source, which is assumed to be the best route between the source and the receiver. It may not be the "shortest" route in a geographical sense.
  
  Note also that the Shared Tree really is the Shortest Path Tree to the RP; but it will be generally suboptimal for transmissions from an arbitrarily located source.
  
  Having a long lasting Shared Tree could be very useful for some multicast applications, such as video-conferencing, where sources might join the group for brief intervals, and then leave the group. In this case, it might not be worth setting up a separate SPT for each transient source. In the case of long lasting sources doing one to many webcasting, though, there is plenty of time to set up a SPT from the source, and the increased latency and extra work imposed on the network by a suboptimal Shared Tree is to avoided.

  
  
• How does the source send to the group ?

  The source simply sends packets to the appropriate Class D group address. Behind the scenes, though, it is much more complex than that. Initially, the source packets are captured by the first hop router, or the DR if there is more than one first hop router, encapsulated, and unicast to the RP.
  
  After the initial transmission is established, the RP sends a (S,G) join message to source. When that is received by the DR, the encapsulation is stopped, and native multicasts of the source's output are sent to the RP.
  
  Still later, PIM-SM will switch from the Shared Tree to the SPT. A receiver's first hop router, or DR, will issue an (S,G) join towards the source. This join travels up the Shared Tree until it finds the source, or a router with (S,G) state that is already receiving from the source. At this point, multicast traffic starts flowing down the SPT to the receiver. At the router where the Shared Tree and the SPT diverge, traffic will be received from both trees. That router will then issue a prune towards the RP, stopping the traffic flowing down that branch of the Shared Tree. Eventually, a steady state may be reached, where all traffic is flowing down the SPT, and when the RP can cease transmissions.
  
  If you think this is complicated, you are not alone in that feeling. Everything in the above answer is short circuited by the SSM modifications to PIM-SM.

  
  
• When does PIM-SM switch between a Shared Tree and a Shorest Path Tree ?

  In practice, either immediately or never.
  
  After the initial transmission is established, the switch-over to the Shortest Path Tree occurs once a certain number of bits (the SPT-Threshold) have been sent down the Shared Tree. This threshold seems to be almost always set to zero, so that the transition starts immediately.
  
  If the only sources for a given group are on a LAN attached to the RP, the switch-over to a SPT never occurs, as the Shared Tree is the SPT for that group.

  
  
• In PIM-SM, how does a router actually becomes a rendezvous point ?

  Routers must be configured manually to be a candidate RP. One router in each PIM domain is elected by the other RPs to be the Bootstrap Router (BSR). The BSR floods messages announcing all of the suitable RPs (the RP-set) throughout the domain, so that all routers know the addresses of the RP-set.
  
  The RP can also be specified manually, which makes sense for a small domain with only a few routers.
  
  Note that a router can be set up to be a RP for only a subset of Class D group addresses. You could, for example, configure one of your routers to be a RP only for the groups that you were going to participate in.

  
  

• What is Source Specific Multicast ?

  Source Specific Multicasting (SSM) uses the capabilities of IGMP v3 to tune PIM-SM to the needs of large scale, one-to-many, webcasting. IGMP v3 allows a source to explicitly request traffic from a particular (S,G) pair, through an INCLUDE report. In SSM edge routers must be modified to generate a PIM-SM SPT (S,G) join directly from a IGMP v3 INCLUDE report, joining directly to the source without using a Rendezvous Point at all. In SSM, routers in the interior of the network do not have to be modified at all, and could run standard PIM-SM. Knowledge of the source and group pair is assumed to come from "out-of-band", such as from a web-page. Since the Internet address of the source is given explicitly, there is no need to run MSDP.
  
  SSM is now included as part of the PIM-SM v. 2 draft. More SSM implementation details can be obtained from my presentation at NANOG 21.
  
  The address range 232/8 has been reserved for SSM.

What is MSDP ? How does multicast traffic pass between autonomous systems ?

The Internet is divided into Autonomous Systems (AS's, or "domains"), which are networks under a common routing policy. Routing within an AS is done by whatever routing protocol is chosen by the AS administrator; routing between autonomous systems is done by an Exterior Gateway Protocol, currently BGP4, which maintains tables which describe the AS paths required to reach a given address block in some other AS. This presents a problem for multicasting - how can a router determine which AS contains the source for a given multicast group address ?

The Multicast Source Discovery Protocol ( MSDP) allows for a RP in a given AS to share information about active sources with RPs in other AS's. This allows multicast data to be forwarded between different AS's. It works with BGP4+, which actually gives the interdomain multicast routes.

In SSM, the source and group address are assumed to be known by other means, such as a web page, and a (S,G) join can go directly across AS boundaries without using MSDP.

NOTE : BGP4+ is also known as MBGP (MultiProtocol BGP). It is NOT the same as BGMP, the Border Gateway Multicast Protocol.

I work for an ISP. How do I connect to the multicast enabled Internet ?

This can be a complicated problem, but here are a few suggestions.

First, at least one of your upstream providers will need to support multicast, and you will need some assistence from them. If none of your upstream providers support multicast, you will need to tunnel, and you probably should contact us.

The Internet2 had a multicast workshop recently that addressed how to become enabled - you should take a look at the presentation material. Good references are the books, Interdomain Multicast Routing by Edwards, Giuilano and Wright, and Developing IP Multicast Networks: The Definitive Guide by Beau Williamson.

If you are running an autonomous system, you will need to run MBGP and set up PIM and MSDP Peers with your upstream peer - you should contact your technical reference there and request the necessary info. If you have trouble, you can ask questions on the IP Multicast Initiative multicast mailing list.

The accessgrid multicast beacon at http://dast.nlanr.net/Projects/Beacon/ (and its beacon view web page at http://beaconserver.accessgrid.org:9999/) is an excellent debugging tool. You may not want to devote the bandwidth to become a permanent beacon group member, but sourcing a beacon is a good way to test multicast transit both in and out bound.

You might want to consider, once you get multicast enabled, to being listed on our multicast ISP list at http://www.multicast-isp-list.com (inclusion is free if you answer the questions).

What is the Real Time Protocol (RTP) ?

RTP (and the closely related Real Time Control Protocol, or RTCP) provides a framework for sending real-time data over the Internet. It is designed to be independent of the underlying transport protocol, such as PIM-SM, and can be used with either multicasting or unicasting. RTP allows for sequence numbering and timing, which are crucial for the playback of an audio or video data stream. RTCP is used to communicate control information to receivers, and for quality control feedback from receivers to the source. RTP is defined by RFC 1889; a new draft is also in the works.

What is reliable multicast ?

"Reliable" in the context of multicasting generally means some form of re-transmission of missing packets, using NACKs or Tree based ACKs, but it also could mean "layered" techniques using Forward Error Correction (FEC). Development of reliable multicast is very much a work in progress; see the RMT working group, the drafts referenced by the RMT charter, and the IRTF RMRG working group.

There are a number of reliable multicast products in use. Cisco offers Practical General Multicast (PGM), which is now an Internet draft. Talarian offers reliable multicast based on their version of PGM, called SmartPGM and the Reliable Multicast Transport Protocol, version 2 (RMTP-II).

Can multicast addresses collide at the MAC (Ethernet) layer ?

Yes. Normally, an Ethernet device will only accept packets addressed to its unique MAC identity (or to the broadcast address). However, Ethernet devices are also engineered to accept packets from the multicast MAC address range. MAC addresses are 48 bits; of that, 25 bits are used in the multicast prefix : multicast MAC addresses must start with 01:00:5E in hexadecimal, and the next bit must be zero. This leaves only 23 bits to store the multicast Class D address. Since multicast group addresses must start with 1110, there are really only 28 independent bits in a Class D address, and so 5 bits are "lost" in the translation to a MAC address, and collisions can occur.

For a GLOP address in 233/8, a total of 8 bits of the Class D address are redundant, and so only one bit is lost (the highest order bit of the AS number, see below). Since no autonomous system has yet been assigned a ASN with that bit set to one, GLOP addresses will not yet be subject to MAC collisions (at least with other GLOP addresses).

How a GLOP Address Maps Into a MAC address

Note : You may need to enlarge your browser window to see this properly!
+--------------------------------0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1+
+-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------------|------233------|----------16 bits AS-----------|--local bits---|
+-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|--------------------01:00:5E-------------------|0|------15 lowest bits AS------|--local bits---|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Having a MAC collision may not be fatal, as applications can filter on the Internet address of the source, but it may mean that too much traffic is put on the local LAN. It may also put too much load on device CPUs, as the interface NIC card may not be able to filter out the unwanted, and may send it up the kernel stack to the CPU.

Although SSM addresses cannot collide at the IP level, due to the unique IP source address associated with each SSM Class D address, MAC collisions can occur for SSM addresses, and it is my personal opinion that a GLOP-like structuring of the SSM address space may be needed to prevent this.

Advertisment