Summary

  • RFC 3353 showed that a traffic-driven multicast LSP could contain a bootstrap dependency: the new branch needed traffic as its trigger, while Layer 2 could not carry that traffic before the branch existed.
  • Mixed Layer 2/Layer 3 forwarding or upstream-initiated label establishment provided a bridge, but packet arrival, routing state, label signaling, programmed replication and receiver delivery remained separate facts.

Consider a multicast tree that already carries packets to one receiver. A second receiver appears behind a different downstream label-switching router. The economical policy is attractive: allocate labels only when traffic exists. The second router should see a packet, learn that the stream matters, and trigger the new labelled branch.

It cannot, at least not by Layer 2 alone. The packet will not arrive on a label-switched path that has not been established. The trigger waits for the path; the path waits for the trigger.

That is the “chicken and egg problem” described in section 5.3.1 of RFC 3353. The phrase matters because it reveals what a framework diagram can conceal. “Traffic-driven” sounds like a self-contained policy. In a branching system, it is a dependency graph. Someone must observe the first packet before the downstream labelled path exists, and someone must have authority to turn that observation into a binding.

RFC 3353 was an Informational overview, not a protocol standard. Its job was to map the choices created when IP multicast routing met MPLS. Unicast had made label switching look comparatively linear: a forwarding equivalence class points toward a next hop, and labels can follow a stable route. Multicast had a source, a group and several outgoing interfaces. Its forwarding object was a tree, and different routing protocols could build different trees.

The granularity was already more expensive. A shared tree used (*,G) state, one tree for a group regardless of source. A source tree used (S,G) state, one tree for each source and group. Shared state could reduce the number of labels, but mapping it end to end could require multipoint-to-multipoint behavior and merging. Source-specific state avoided some merging problems while consuming more labels. RFC 3353 did not pretend that one representation dominated every network.

Flood-and-prune protocols made the timing sharper. They could create state when data appeared, prune unwanted branches, and later remove state after inactivity. Their trees were volatile. If Layer 2 mirrored every change, label setup needed to be fast and label space could churn. If labels were installed before traffic, unused trees consumed resources. If installation waited for traffic, the first packet became part of the control mechanism.

The framework separated three triggers. A request-driven LSP could follow a multicast Join, Prune or resource-reservation message. A topology-driven LSP could copy the multicast routing table even when no packets flowed. A traffic-driven LSP could wait until actual data arrived. Each method bought one property and spent another: control coupling, idle state, setup latency, protocol extensions or observation complexity.

The bootstrap problem appears when the traffic-driven choice meets label direction. Suppose an upstream LSR already switches a stream toward one branch and a second downstream LSR joins. For the new downstream node to trigger from traffic, it must receive the stream. If it receives the stream at Layer 2, the missing LSP has somehow already been created. If it receives the stream at Layer 3, the upstream node must be able to route the new branch while switching the old one.

RFC 3353 called that ability mixed L2/L3 forwarding. One incoming multicast packet could leave some interfaces through label switching and others through ordinary IP forwarding. The Layer 3 engine also had to know which branches were already served at Layer 2, or it could emit duplicates. Mixed forwarding was not an aesthetic hybrid. It was a reversible bootstrap surface: the first packet could take the routed branch, supply the observation needed for setup, and allow later packets to move onto the labelled branch.

Without mixed forwarding, initiative had to move upstream. The upstream LSR could request a downstream label or advertise an upstream-assigned label, depending on the distribution model. RFC 3353's compatibility table made the constraint explicit. Traffic-driven operation with the downstream side requesting the label worked only when mixed L2/L3 forwarding was present. Trigger and distribution mode were not independent menu selections.

This is the article's central evidence boundary. A packet observed at the upstream node proves that one packet reached one observation point. A multicast forwarding-cache miss proves that a local cache lacked an entry. A multicast routing-table row proves that a local control process installed or retained a branch description. A label message proves a bounded exchange. A programmed replication entry proves a local forwarding action. None, alone, proves that every leaf received the stream.

RFC 3353's Unix forwarding-cache example makes the same boundary visible after setup. A first multicast packet could miss in the kernel's Multicast Forwarding Cache. The multicast daemon supplied the route; later packets could then be switched at Layer 2. But once Layer 2 took over, the Layer 3 path stopped seeing those packets. If the Layer 3 cache expired entries according to traffic counters, its view could now age out a live stream.

The proposed answer was to update Layer 3 cache counters using Layer 2 measurements. That was practical, but it created a projection. The counter no longer meant “packets this Layer 3 path forwarded.” It meant “activity reported from the layer now doing the work.” Its usefulness depended on source, timing, reset behavior and attribution. Moving execution down a layer did not eliminate observation; it made observation cross a layer boundary.

Shared and source trees added another transitional problem. In PIM-SM, (*,G) and (S,G) state could coexist while a receiver moved from the rendezvous-point tree to a source tree. The same source's packets might briefly reach a router through both incoming paths. Layer 3 could suppress the inappropriate copy using source-specific state. Pure Layer 2 operation could accept temporary duplicates or require more labels and merging. Again, the label did not erase the routing semantics that decided which copy belonged.

Encapsulation drew a harder line. A sender on a shared tree could tunnel packets toward the root, where they were decapsulated. Those were Layer 3 operations, so the path could not be one uninterrupted end-to-end Layer 2 LSP across that boundary. MPLS could still switch other branches or the tunnel, but an architectural diagram had to show where packet interpretation returned to IP.

The label-distribution mechanism carried its own tradeoffs. Piggy-backing a mapping on multicast routing messages synchronized two kinds of state and reduced separate messages. It also tied MPLS behavior to each multicast protocol, excluded some trigger combinations, and often traded LDP's reliable TCP exchange for periodic soft state. A synchronized announcement was useful evidence, not proof that the branch was installed or that traffic survived the transition.

Multi-access links complicated ownership further. Several downstream routers could need the same multicast label on one shared medium. They might remember every assignment, divide the label space, or elect an allocator. Upstream allocation simplified the fact that one upstream node fed the tree, but a topology change could replace that allocator. Downstream allocation could preserve a label across an upstream change, yet several downstream nodes might propose different values. RFC 3353 left the selection open because the correct answer depended on failure and operational costs.

Later standards made the tree more explicit. RFC 4461 described requirements for point-to-multipoint traffic-engineered LSPs, including branch replication, leaf addition and deletion, failure reporting and scaling. RFC 4875 then defined RSVP-TE signaling in which a P2MP LSP consisted of multiple source-to-leaf sub-LSPs combined at branch routers. It included a vital qualification: signaling state could branch even when the data plane did not replicate traffic there. The tree in the control plane was still not the packet receipt.

RFC 5332 also corrected one piece of the 2002 picture. RFC 3353 noted separate link-layer codepoints for MPLS unicast and multicast. RFC 5332 recorded that this use was never deployed and redefined the second codepoint around upstream-assigned labels on multi-access media. Historical architecture must preserve that correction: the early framework captured a design space, not a guaranteed deployment path.

By 2012, RFC 6513's multicast VPN architecture still exposed a choice between distribution trees and ingress replication through unicast tunnels. Replicate at the edge and spend bandwidth; build shared transport state and spend control-plane complexity. The names and protocols changed, but replication never became free.

RFC 3353 is valuable because it refused the fiction of instantaneous automation. Before the labelled branch there was a packet, a routed escape path or an upstream decision. After signaling there was still programming, replication and observation to verify. The sequence was the system.

Sources