Summary

  • RFC 2098 let selected flows cross successive Cell Switch Routers through concatenated ATM virtual circuits without repeated datagram assembly or IP-header processing.
  • The shortcut did not replace routing: IP routing chose the inter-subnet CSR sequence, while ATM routing chose only the local virtual-circuit path between adjacent nodes.
  • An installed bypass proved selected forwarding state, not an optimal route, reserved quality, authorization, identity, delivery or continued validity after a route or failure change.

The cell met a fork, not a new authority

RFC 2098 asks the reader to imagine a router with an ATM switch inside it. When a cell reaches that Cell Switch Router, the device checks the incoming interface and VPI/VCI. If its ATM table contains a corresponding outgoing interface and VPI/VCI, the switch module forwards the cell directly. If there is no mapping—or the mapping points to the IP module—the device assembles the cell into an IP datagram and chooses the outgoing side from the datagram’s identifier.

That branch was the proposed gain. A selected flow could avoid repeated reassembly and IP-header processing at intermediate routers. But the branch was not a new route computation. It executed state that another layer had already justified.

The document was published in February 1997 as Informational. Its status text says it does not specify an Internet Standard. The IETF Datatracker record now labels it Legacy and says it has no formal standing in the IETF standards process. The RFC Editor errata search currently lists no matching errata. These facts make RFC 2098 an architectural record, not evidence of a deployed product or measured result.

Three pieces made the bypass visible

RFC 2098 defined a Default-VC between adjacent nodes for ordinary hop-by-hop IP forwarding. Cells arriving there were assembled into datagrams and handled through the IP path. This was not dead weight left behind by the faster design. It was the general path, the place traffic could travel before dedicated state existed and the fallback while setup was incomplete.

A Dedicated-VC belonged to a selected flow. The selector might use destination address, source and destination addresses, ports or an IPv6 flow label. When adjacent Dedicated-VCs carried the same flow, a CSR could concatenate the incoming and outgoing segments. Repeating that action across several CSRs produced what the RFC called an ATM Bypass-pipe.

The name matters. The pipe was not one ATM VCC crossing an entire cloud. It was a chain of local ATM VCs, each joining neighboring CSRs, hosts or routers. A visible end-to-end fast path was therefore made from several independently provisioned and controlled pieces.

IP chose the sequence; ATM chose each local segment

RFC 2098 is unusually explicit about the authority boundary. The bypass-pipe followed IP routing information in every CSR. In its example, traffic went through X.1, CSR1, CSR2 and Z.1 whether it used ordinary hop-by-hop forwarding or the bypass. IP routing selected that inter-subnet sequence and the egress. ATM routing chose the route of each component VC only between adjacent nodes.

This hierarchy also limited the claim of optimality. The RFC says the resulting end-to-end ATM path might be less optimal than an NHRP shortcut because it still passed routers at subnet boundaries. A fast-looking pipe therefore could not testify that the best possible ATM path had been chosen. It showed that the installed segments followed the IP route the CSRs currently knew.

RFC 1932 helps name the distinction. Routing exchanges the information needed to make a correct forwarding decision; forwarding applies that decision to traffic. RFC 2098 accelerated part of forwarding. It did not erase the route account on which forwarding depended.

The alternatives drew different boundaries

RFC 1577 described Classical IP over ATM. Nodes in one Logical IP Subnetwork could connect directly, but traffic beyond the IP-subnet boundary crossed a router. RFC 2225 later kept that classical model as a stable baseline when extensions were absent or failed.

NHRP took another route. The later RFC 2332 resolved an NBMA next hop toward a destination so a source could establish more direct connectivity across a multi-subnet cloud. RFC 2098’s CSR design retained the router-level sequence and accelerated traffic along it. It was neither Classical IP unchanged nor one NHRP-style cloud-wide circuit.

The nearest published BTW histories mark other edges. RFC 1953’s IFMP story is about a rejectable, expiring label agreement on one adjacent link. RFC 1954 is about how an accepted label and the default path were encoded on an ATM link. RFC 2022 separates a multicast receiver roster from the circuit a sender still had to build. RFC 2098’s own territory is the multi-CSR chain and the decision to keep that chain subordinate to IP routing.

Route changes turned installed state into old evidence

The RFC did not treat a bypass as permanent. When IP routing changed, affected CSRs could alter the relevant segments. The same idea applied after a node, link or router failure. The proposal said intermediate CSRs could repair related bypasses without tearing down and rebuilding the entire path from scratch.

That is a design intention, not a deployment receipt. To know whether a real flow remained valid, an operator would need the route version, the chosen CSR sequence, every adjacent VC, the mapping lifetime, the failure signal, the repair action and traffic observed after repair. The mere survival of a VPI/VCI entry would be ambiguous: it might be correct current state, state awaiting refresh, or stale acceleration detached from the route that once authorized it.

Low latency and reserved quality were different promises

RFC 2098 described a short-term bypass triggered by traffic volume or by seeing a higher-layer protocol such as FTP, NNTP or HTTP. That shortcut sought lower latency and less IP processing for bursts. The RFC says it carried no explicit bandwidth rule because the endpoints had supplied no bandwidth or QoS request. UBR was the easy ATM service choice, but it guaranteed no cell-loss quality.

The document separately considered a bypass built in response to an explicit request such as RSVP. RFC 2205 defines RSVP as a control protocol that requests service along a route and consults routing information; it is not itself a routing protocol. A dedicated VC could therefore exist without a reservation, while a reservation request did not prove that a bypass was installed or that delivery met the requested service.

The same restraint applies to identity and policy. RFC 2098 says security issues are not discussed. A flow selector or installed VPI/VCI map is not authentication. Detecting HTTP does not identify the application owner. A bypass control exchange between neighbors does not prove end-to-end authorization.

A fast path is an execution receipt with an expiry date

Lu Heng’s Running-Code Primacy argues that technical claims should return to what systems actually run. Minimum Initial Specification separates a common interoperable layer from later local choices. Reality Layers warns against allowing a symbolic claim to borrow the force of executable state.

RFC 2098 gives those ideas a concrete historical form. IP routing retained the shared account of inter-subnet reachability. ATM state accelerated a selected flow locally. The bypass was real when cells used it, but its meaning remained bounded: it was evidence of execution under one route and one moment’s state. It could not speak for the authority that selected the route, or for the outcome beyond the switch.

Sources