Summary

  • RFC 2105 described an Informational Cisco architecture in which a short tag indexed a Tag Information Base, was replaced at each hop and selected an outgoing interface without repeating a longest-prefix lookup.
  • Existing routing protocols plus tag-binding and distribution mechanisms built the state beforehand; topology, rather than packet arrival, could trigger allocation for destination routes.
  • The design separated a stable forwarding primitive from control modules for unicast, multicast, hierarchy, explicit routes, ATM and QoS, but a carried tag proved only a local binding—not standards consensus, identity, authorization, delivery or end-to-end path truth.

One exact match hid a long chain of decisions

RFC 2105’s forwarding loop is almost austere. A tagged packet arrives. The switch treats the incoming tag as an exact-match index into its Tag Information Base, or TIB. The matching entry supplies one or more triples: an outgoing tag, an outgoing interface and outgoing link-layer information. The machine substitutes the new tag and link-layer fields, then transmits.

The appeal was not merely that a short comparison could be quick. Conventional IP forwarding usually chose a longest matching prefix from a network-layer address. Tag Switching moved that work out of the repeated packet path. Its small fixed-length index was simple enough for hardware, and the same operation could drive one unicast output or several multicast outputs.

But the TIB lookup was the end of a decision chain, not the beginning. A value in the packet did not explain which route created the binding, which neighbor supplied it, whether that neighbor was still the next hop, whether an explicit path overrode ordinary destination routing, or whether the packet reached the intended endpoint. The visible tag was an execution handle for state held somewhere else.

The stable machine sat below changing control

The architecture’s consequential split was between forwarding and control. The forwarding component performed the same lookup-and-swap operation regardless of whether the binding represented a destination prefix, a multicast tree, a routing hierarchy, an explicitly chosen path or a service class. The control component created bindings and distributed them among switches.

RFC 2105 organized control as a collection of modules. A new routing function could add a new module without changing the forwarding primitive. That was a practical evolutionary bargain: keep the expensive fast path stable while allowing routing logic to grow around it. A switch did not need a new packet-processing machine every time the network acquired a new way to classify or steer traffic.

Decoupling also created an evidence boundary. If the forwarding hardware swapped a tag correctly, it proved that one local entry was usable at that moment. It did not prove that the module which created the entry had fresh inputs, that distribution had converged, or that the policy behind the binding was authorized. A data plane can faithfully execute stale control.

Routing built the route-shaped bindings first

For destination-based forwarding, a tag switch still participated in OSPF, BGP or another network-layer routing protocol and built a Forwarding Information Base. Tags did not replace route computation. They gave the forwarding plane a compact way to execute a result.

The RFC allowed three allocation directions: downstream, downstream on demand and upstream. In the ordinary downstream scheme, a switch allocated a tag for each route in its FIB, created a TIB entry and advertised the binding to adjacent switches. A receiving switch used the binding from its next hop as the outgoing tag for that route. The proposed Tag Distribution Protocol could carry the exchange, or binding information could travel with an existing routing protocol.

That ordering matters. The switch first learned reachability, then created and distributed a local handle for it. The tag was not an independent route announcement. Nor was the proposed TDP the later standardized LDP merely wearing an older name. RFC 5036 specifies a distinct protocol with its own discovery, session, mapping and error procedures.

Topology, not traffic, could populate the TIB

Many fast-path schemes of the period reacted to observed flows. RFC 2105 emphasized a different scaling property for destination routes. A FIB entry could cause tag allocation before any user packet arrived. The scheme was topology-driven rather than traffic-driven.

That choice bounded tag state by routing state instead of by the number and volatility of active conversations. A single tag could represent one prefix or a group of routes. The switch avoided classifying every flow merely to decide whether it deserved a fast path. Traffic spikes therefore did not automatically multiply control state.

Precomputation did not make the state timeless. A topology-driven binding was only as current as the route, next hop and distribution epoch that produced it. If any of those changed while the old entry remained executable, the TIB could continue to offer an efficient answer to an obsolete question.

The ordinary network layer never disappeared

The proposal did not claim that every packet could remain inside label swapping forever. An untagged packet still required a normal network-layer lookup before the first tag could be added. That work could happen at the first-hop router or at the first Tag Switching participant on the path.

Aggregation created another exception. If several routes were compressed behind one tag but did not share a next hop, the aggregation point had to inspect the network-layer destination to choose correctly. A compact tag could intentionally discard distinctions that the next decision still needed.

These exceptions expose the architecture’s limit. The fast path was valuable because it reused a decision. At ingress or at a point where aggregation erased too much context, the system had to reconstruct the question from the packet header. Tag Switching reduced repeated interpretation; it did not abolish interpretation.

A stack moved exterior knowledge to the border

RFC 2105 also used a stack of tags to separate interior and exterior routing knowledge. Between domains, a packet could carry one tag. At the ingress to a domain, the border switch could push a second tag above it. Interior switches processed only the top tag to reach the egress border. The lower tag remained for the egress decision, and the upper one could be popped by the egress or penultimate switch.

The operational gain was selective knowledge. Interior switches did not all need the full exterior routing table; border switches carried that burden. The stack preserved two forwarding contexts without asking every device to understand both.

Yet a stack was not a travel diary. The top value was locally meaningful in one level of hierarchy, and the next value belonged to another. Observing both did not reveal every control-plane message, discarded alternative or transient route that produced them. The stack encoded executable context, not an auditable history of the path.

One forwarding primitive served different control ambitions

For multicast, routing procedures first built a shared or source-specific tree. The Tag Switching module then associated local outgoing tags with the tree’s interfaces and installed a multi-output TIB entry. The tag did not discover receivers or construct the tree; it executed the forwarding state after those decisions existed.

For explicit routing, control could install bindings that departed from destination-based paths. That made traffic engineering possible without changing the swap operation. It also widened the governance surface: a correct TIB hit could follow a deliberately chosen path whose policy, capacity and approval lived outside the packet.

ATM looked attractive because its VPI/VCI fields already supported label-like switching. But an ATM switch joining Tag Switching still needed network-layer routing participation and the control component; aggregation could require ordinary forwarding too. A traditional ATM control plane could coexist with Tag Switching through partitioned resources, without one validating the other.

QoS followed the same separation. An initial classifier could apply a tag for a service class, allowing later switches to find scheduling state quickly. Scheduling and queueing remained orthogonal. The presence of a class tag therefore did not prove reserved bandwidth, acceptable loss, delay or delivery.

An Informational architecture was not a standards receipt

The status boundary is unusually explicit. RFC 2105 was not produced by an IETF working group, was not standards track and did not specify an Internet standard. Datatracker now labels it Legacy and says it has no formal standing in the IETF standards process. Its security section states only that security issues were not discussed, while its intellectual-property section recorded Cisco’s possible patent position.

Those facts do not erase the architecture’s historical interest. They discipline the claim. Four years later, the Standards Track MPLS architecture specified locally significant labels, forwarding-equivalence classes, stacks and per-hop replacement. The structural resemblance is visible. RFC 3031, however, does not cite RFC 2105 by number or title. The honest historical statement is therefore bounded: Tag Switching showed one path toward the label-switched architecture that MPLS later standardized; RFC 2105 alone does not prove direct causation, implementation lineage or adoption.

Lu Heng’s running-code argument sharpens that distinction. A publication can describe a mechanism, but operation makes it real. His minimum-specification principle separates shared interoperability from later local choice, while his reality-layer analysis warns against allowing symbolic claims to borrow the force of execution. In RFC 2105, a tag was executable at the forwarding layer. The document, the control binding, the installed TIB entry and the observed delivery remained four different receipts.

Sources