Topic
Multicast Routing
Within the Topic facet, Multicast Routing topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
IETF
QUIC Wants Multicast. The IETF Has Not Said Yes.
A November BoF will ask whether QUIC can use Source-Specific Multicast for common data while keeping an individual connection to each receiver. The meeting is designed to surface requirements; it will not charter a working group or choose a protocol.
IETF
The RPL Draft Wants Two Option Codes Already Taken
A low-power router asks its neighbours for a route, and the neighbours pay for the answer in airtime and battery. An IETF working-group draft tries to make that exchange less wasteful. Its two proposed option numbers, however, already have jobs in the IANA registry. The protocol…
History
One IGMP Report Could Prove Presence, Not Headcount
A 1989 standard made multicast membership visible to neighboring routers with a deliberately economical signal: one host report could speak for a whole local group, while silence after departure had to age out.
History
The Mac Could Join; the Reflector Had to Carry Everyone: CU-SeeMe, 1993–1995
CU-SeeMe made a modest Macintosh a place to send live pictures across the Internet. A second entity could connect directly. A third changed the problem: the group needed a Unix machine to receive streams, copy them, and redistribute them. The apparent simplicity at the desktop…
Leaders
Ellen Zegura and the Multicast Core That Could Move
When a multicast group’s receivers spread across a network, the router chosen as the group’s shared core can become a poor fit. A 1996 paper coauthored by Ellen Zegura and Michael J. Donahoo treated moving that core as part of the routing problem—and also asked how to measure its…
NANOG
Packets Reached CERN; Many Questions Did Not: NANOG 1 and the MBONE, 1994
In June 1994, organizers planned to multicast NANOG’s Ann Arbor meeting over the MBONE. The archive preserves three different kinds of evidence: one person could not find the session, another asked for a steadier view of the screen, and a listener at CERN reported no packet loss…
History
The Group Address Named Its Rendezvous Point. It Did Not Prove It Existed: RFC 3956
RFC 3956 let an IPv6 multicast group address carry the recipe for its own rendezvous point. Every compliant router could derive the same candidate, but the arithmetic could not prove that a router was there, reachable, trusted or ready to deliver a packet.
History
The Filter Could Change One Entry—or All at Once.
RFC 3678 did not ask every multicast application to learn a new membership vocabulary. It left the old calls in place, then offered two different ways to change a source filter: adjust one source, or replace the complete filter in a single operation.
History
No Reports Went to the Sender. The Receiver Still Controlled Its Rate: RFC 3738
In 2004, WEBRC proposed a multicast congestion-control loop that did not ask each receiver to report its condition to the sender. It moved the measurement and rate decision to each receiver, then expressed that decision through multicast-channel joins and leaves—a change in where…
IETF
The NAT Forwarded Both Streams. The Public `(S,G)` Could No Longer Tell Them Apart
Two encoders can be different on the private side, choose the same Source-Specific Multicast group, and still be perfectly distinguishable. RFC 5135 shows how that distinction can disappear at the NAT boundary even when the device follows its multicast rules. The operational…
IETF
Every Receiver Held the Key. None of Them Became the Sender.
A constructed multicast service admitted one receiver, delivered the group secret over an authenticated channel and began sending encrypted media. The receiver could decrypt exactly as intended. In a naïve symmetric design, it could also construct a tag that looked valid to every…
History
The First Packet Had to Arrive Before Its Labelled Branch Could Exist: RFC 3353
In 2002, multicast over MPLS contained a small operational paradox. A router could wait for traffic before spending a label on a new branch. But the downstream router that needed the branch could not see that traffic at Layer 2 until the branch had already been built. RFC 3353…
History
Reusable Blocks Could Still Fail Together: RFC 3269
Reliable multicast needed more than reusable pieces. RFC 3269 required each RMT building block to state its boundaries and dependencies, then made a complete protocol explain how those pieces fit.
IETF
The Receiver Saw the Failure. Did the Multicast Head Hear It?
In a multicast network, the receiver that notices silence is not necessarily the node that can act on it. The latest BIER BFD draft makes the route back to the sender—and the proof that an alert was matched to the right session—a separate operational question.
History
The Pi Multicast Group Was Not an IPv4 Address: RFC 3091
RFC 3091 imagined clients assembling π from a stream, a numbered UDP reply or multicast. Its multicast instructions began with a destination no IPv4 host could join, while the TCP and UDP ports elsewhere in the same document exceeded the fields that carry them.
History
The Notices Continued After the Directory Agent. New Services Could Still Be Missed: RFC 3082
RFC 3082 tried to replace wasteful polling with event-driven service discovery. Its recovery rules expose a more precise trade-off: a Directory Agent can lose subscription state while service agents already informed of that subscription keep announcing. A new service may enter…
IETF
The Claim Was Encrypted. It Still Did Not Own the Multicast Address.
GAAP-25 hardens the packet that carries a multicast-address claim. That is useful engineering. It is not a deed, a mandate, or evidence that the claimant may control what it names. The operational mistake would be to let a cryptographic success answer a question it was never…
IETF
GAAP-25 Makes Its Python API an Example, Not the Protocol
A programming example can become an accidental standard when readers treat its function names as the only way to implement a wire protocol. The latest GAAP draft draws a firmer line: the multicast Claim exchange is the shared entity; the application's API is not.
History
The Cache Row Said a Group Had Members. Management Could Have Created It: RFC 3019
RFC 3019 gave operators a table of IPv6 multicast membership. The same table let management create or delete rows and declare the local machine a member. Its most useful historical lesson is therefore not that a row was false, but that its origin and evidentiary limit had to…
History
The Replicas Agreed. The Clients Still Had to Return: RFC 2443
In the late 1990s, ATM networks could carry IP multicast, but a multicast client still needed a service that knew which groups existed and which endpoints belonged to them. RFC 2443 copied that knowledge among MARS servers. Its more revealing rule was what happened when the…