Basics

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

Multicast Addressing
y

What does (*,G) and (S,G) mean ? Any multicast transmission has a Class D multicast group address, G. A multicast group can have more than one source, and each such source will also have a "regular" (Class A, B or C, or CIDR) Internet address, S. The notation (*,G) means every possible source for a given group G, while (S,G) means a particular source, at a particular Internet address S, in the group G. With IGMP v1 and v2, you join all sources of a group, (*,G), while IGMP v3 will make it possible to join a specific source-group pair, (S,G).

What is a Class D address ? And what does jargon such as 233/8 mean ? The current Internet (IPv4) has a 32 bit address space. This space was originally divided into five classes (or address blocks), Class A, B, C, D and E, with Classes A, B and C being assigned to normal unicast routing. Later, the Classless InterDomain Routing (CIDR) protocol was established, so that blocks of Internet addresses in the Class A, B and C address space could be routed more efficiently. Upon the development of multicasting, Class D was assigned to multicast addresses (Class E is still reserved for experiments). Class D addresses all have 1110 as the first four bits. Since 11100000 is decimal 224, and 11101111 is decimal 239, this means that all Internet addresses from 224.0.0.0 to 239.255.255.255 are assigned to multicasting. It is cumbersome to refer to address blocks in the above fashion, so CIDR developed (and multicasting has adopted) a shorthand, where the start of a block, and the number of bits THAT ARE FIXED, are specified. In that shorthand, the multicast address space can be described as 224.0.0.0/4 or, even more simply, as 224/4. The fixed part of the address is referred to as the prefix, and this block would be pronounced "two twenty four slash four." So, in the above question, 233/8 means all addresses between 233.0.0.0 to 233.255.255.255, which is the GLOP address space. Note that the LARGER the number after the slash, the LONGER the

prefix and the SMALLER the actual address block. Note, too, that despite the use of this notation, multicast group addresses are not subject to CIDR.

Can I use any multicast address I want ? How do I apply for a multicast address ? You cannot use any multicast address that you want, but (except for very special cases involving control traffic) you cannot apply for multicast addresses either. What you can do is use a multicast address from a certain range for certain purposes. The use of the multicast address space is governed by RFC3171, which describes the following blocks that have been assigned by the Internet Assigned Names and Numbers Authority, or IANA.

Multicast Address BLocks Assigned by IANA (from RFC 3171). Start Address 224.0.0.0 224.0.1.0 224.0.2.0 224.1.0.0 224.2.0.0 224.252.0.0 225.0.0.0 232.0.0.0 233.0.0.0 234.0.0.0 Stop Address 224.0.0.255 224.0.1.255 224.0.255.0 224.1.255.255 224.2.255.255 CIDR Notation 224.0.0/24 Name

Local Network Control Block Internetwork Control 224.0.1/24 Block 224.1/16 224.2/16 AD-HOC Block ST Multicast Groups SSDP/SAP Block DIS Transient Block RESERVED Source Specific Multicast (SSM) Block GLOP Block RESERVED

224.255.255.255 231.255.255.255 232.255.255.255 232/8 233.255.255.255 233/8 238.255.255.255 -

239.0.0.0

239.255.255.255 239/8

Administratively Scoped Block

Of these blocks, most users will use an address from the SDP/SAP Block (given out by SDR or a similar program), the GLOP Block, the SSM block, and the Administratively Scoped Block. The uses of these blocks is described below.

What is scoping ? Scoping is the restriction of multicast data transport to certain limited regions of the Internet. It comes in two flavors, TTL scoping and administrative scoping.

What is TTL scoping ? Every Internet Protocol Packet has a Time To Live (TTL) field, which despite the name is really a count of the number of hops (transmission from one router to the next) the packet is allowed. The TTL field is decremented by one each time a packet leaves a router, and a packet with a TTL of zero is discarded. Although the TTL field was implemented to prevent packets from looping forever in the network, the TTL field can be set low to prevent packets from leaving a particular domain. The problem with TTL scoping is that the hop-distance to the edge of a network or domain from a given source may not uniform, and so it may not be possible to both service the entire domain with multicast traffic and prevent that traffic from leaking to other domains, no matter what TTL value is chosen.

What is Administrative Scoping ? Administrative scoping is the restriction of multicast transport based on the address range of the multicast group. It is defined by RFC 2365. Administrative scoping is restricted to the address range 239/8, with the 239.255/16 address space being reserved for the "local network" (i.e., those packets should not be forwarded)

and 239.192/14 is reserved for "organizational scoping." Such large scale administrative scoping must be announced, so that others know what the scope is, which is supposed to be done by MZAP, the Multicast-Scope Zone Announcement Protocol, described in RFC 2776. The most widespread current use of administratively scoped multicast is UU.net and their UUCAST multicast service. Many domains will filter out all 239/8 traffic at their borders, so that any address in this range could be used for internal multicasts.

What is the GLOP address space ? The "GLOP" address space (this is not an acronym!) is a means of assigning addresses in 233/8 based on an autonomous system number, as described in RFC 2770. Basically, a /24 is assigned to each Autonomous System based on the 16 bit Autonomous System Number (ASN), in the form
+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--| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

For a given ASN number, converted into two octets (say X and Y) in the usual fashion of Internet addresses, the GLOP space is therefore 233.X.Y/24. This address range is assumed to be assigned by default and does not have to be explicitly requested. Note, however, that a GLOP allocation only provides 256 separate addresses, which is widely viewed as not enough for large scale broadcasters. If you know your Autonomous System Number, you can find your GLOP range using Greg Shepherd's GLOP Calculator.
y

Are there restrictions on the usage of GLOP address space ? There are no restrictions of use of your GLOP space.

Joining a Multicast Group with IGMP

How Do I Join a Multicast Group? What is IGMP ? A computer joins a multicast group by sending an Internet Group Management Protocol (IGMP) membership report message. IGMP is common to all multicast router protocols - it isolates end users from the routing protocol in use. IGMP packets are always sent with a TTL of 1, and are not supposed to be forwarded. Join latencies are typically very short, a few seconds at most.

What are the differences between IGMP version 1 and 2 (v1 and v2) ? The biggest operational difference is a that IGMP v2 has an explicit Leave Group message, while in IGMP v1 it is necessary to time out to leave a group. IGMP v2 leave latencies are a few seconds or less, while v1 latencies can be 5 minutes, which can be a real problem if an unwanted multicast transmission is a substantial portion of the total available bandwidth.

Can IGMP v2 and v1 interoperate on the same network. ? No. In case that IGMP v1 messages are present, all routers are supposed to be configured manually to use version 1.

What improvements will IGMP v3 bring ?

IGMP version 3, or IGMP v3, allows for specific (S,G) joins and leaves,
through the addition of source specific INCLUDE reports, so that it will be possible to join a specific source of a specific group directly. This capability will make SSM possible.

What if my router is not IGMP enabled ? CISCO and other vendors support the concept of a stub router, where IGMP packets are passed untouched to a router that does support IGMP, which effectively becomes the first hop router for IGMP traffic from the stub domain. For this to work the stub router must recognize IGMP packets and forward them without decrementing the TTL. Of course it is always possible to tunnel.

Multicast Routing

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 (PIMDM), 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.
y

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.

Protocol Independent Multicast

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

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 SPTThreshold) 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 webpage. 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.

Interdomain Multicast Routing

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

Miscellaneous 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-78-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-34-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.