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.
History
Before Reliable Multicast Could Become a Standard, It Had to Prove It Would Not Become Everyone Else’s Congestion: RFC 2357
Reliable multicast promised to send one copy of a file and let the network distribute it to many receivers. RFC 2357 asked who would pay when that economy multiplied feedback, prolonged a transfer or crowded out unrelated traffic. Its answer was unusual for 1998: publication…
IETF
An mDNS Filter Can Make a Multicast Address Look Available
The proposed IPv6 multicast allocator needs no central clerk, but it does need devices to hear one another. An IETF Last Call brings the quiet assumption in its design into focus: no conflict message is useful evidence only when the network carries those messages.
IETF
BIER Ping Won Approval. The Diagnostic Contract Still Needs Its Final Handoff
The IETF has approved a common way to ask where a BIER multicast path fails. The decision is a standards milestone, not a published RFC or a certificate that every vendor can answer the same probe. The remaining IANA and RFC Editor steps matter because an operator's diagnostic…
History
The Address Said “Stay Here.” Only the Router Could Enforce It: RFC 2365
An IPv4 multicast packet can carry a destination inside 239/8 and still escape the region its operator intended. RFC 2365 made that uncomfortable distinction explicit: the address describes an administrative scope, while containment is performed by boundary routers whose…
History
The Join Had No Receipt. The Tree Survived by Refresh: RFC 2117
RFC 2117 did not build a sparse multicast tree as one transaction. A local membership indication created one record; a Join/Prune refreshed records hop by hop; a source initially reached a rendezvous point inside Register messages; a branch could later move to source-specific…
History
The Counter Passed One Receiver’s Window. It Did Not Name the Sender: RFC 2085
RFC 2085 placed a 64-bit replay counter inside one HMAC-MD5 Authentication Header transform, but only when the Security Association selected it. A receiver could admit unseen packets within its own reordering window and reject a repeated value. That was useful freshness evidence…
IETF
EVPN Can Select One Multicast Source. It Cannot Certify Redundancy.
A receiver may show one clean programme while two contribution sources are transmitting. RFC 9856 explains how an EVPN can suppress the extra copy. It does not establish that the surviving source was healthy, equivalent, or switched without loss. Those are separate operational…
IETF
Where TreeDN’s replication saving stops
A network can send fewer copies of a live programme and still owe the viewer a usable picture. RFC 9706 makes replication easier to buy; it also exposes how much of delivery sits outside the replication contract.
History
Eve Schooler and the Invitation That Did Not Carry the Conversation
The most consequential line in an Internet call is not the one carrying a voice. It is the one that finds the other person, proposes a session and then gets out of the way. Eve Schooler’s path from experimental conference control to the early Session Initiation Protocol helps…
IETF
The Anycast Root Survived. The Multicast State Did Not
The route recovers quickly. The shared address remains reachable, the reverse-path check points at a healthy interface, and ordinary availability monitors turn green. Yet some multicast receivers remain silent. Nothing in the address-level evidence says whether the replacement…
IETF
PIM Light’s Missing Hello Leaves Two Redundancy Decisions Outside the Interface
RFC 9739 lets multicast state cross a boundary without first establishing a PIM neighbour. The useful simplification leaves the network responsible for choosing who forwards a Join, preventing duplicate streams and turning a detected failure into an actual withdrawal.
IETF
The Highest-CoS Probe Does Not Measure Every BIER Service
A green continuity result can be both correct and dangerously overinterpreted. RFC 9974 allows an operator, in a particular composite-flow case, to test the highest Class of Service and derive the continuity state of lower classes. The sentence is operationally useful. It is not…
IETF
The Router Remembered a Listener. The Receiver Saw Nothing: RFC 9777
MLDv2 gives an IPv6 router a disciplined account of multicast interest on one attached link. The danger begins when that local, aging account is promoted into proof that an authorized application still wants the traffic—or that the traffic arrived.
IETF
A P2MP Tree Is Not an Audience Mandate
The operations screen is green. A ping addressed to a particular point-to-multipoint tree instance has returned from every expected leaf. The controller has built the efficient branches, the labels agree, and the old instance is ready to be removed. None of those facts answers…
History
RFC 2022: The Roster Named the Receivers, but the Packet Still Needed a Circuit
RFC 2022 did not turn an IP multicast group into one ATM connection. It split the problem in two: MARS reported the endpoints believed to be listening, while each sender still had to build and repair the one-way circuit that might reach them. The roster was actionable control…
CASE FILE
The Underlay Group Was Requested. The Receivers Were Not Proved: RFC 9798
One multicast-valued Receiver RLOC reaches a root ITR. It looks like a destination and may cause real forwarding state, but it answers neither “which ETRs asked?” nor “who received data?” RFC 9798 makes the division of labour precise enough to build a better receipt: preserve the…
History
The Packet Reached the Area. It Had Not Reached the Person: RFC 2009
RFC 2009 tried to fit a physical polygon inside a logical Internet address by routing approximately first and deciding precisely at the edge—a scaling bargain that made location, delivery and outcome separate facts.
CASE FILE
Two Sources, One Election, No Continuity Verdict: RFC 9856
RFC 9856 gives an EVPN fabric disciplined ways to choose among redundant multicast sources. The useful discipline begins by refusing a tempting shortcut: the chosen path is not the received service.
IETF
Standards Become Infrastructure When Operators Must Carry Their State
IETF standards do not operate networks. They define the state machines, security dependencies and recovery procedures that networks must implement if they are to interoperate. That distinction matters when a protocol becomes part of the Internet’s operating surface: continuity no…
History
RFC 10028 and the Institutional Boundary of IPv6 Multicast
RFC 10028 did more than tidy an IPv6 registry. It shows how an IETF decision becomes operational authority: a standards document changes the allocation map, and IANA gives that decision a durable administrative surface. The result is a cleaner boundary between multicast uses—but…