Summary
- RFC 1954 turned an accepted IFMP label into an ATM VPI/VCI and one of three AAL-5 payload formats; traffic without accepted state, and IFMP control traffic itself, remained on the default VPI 0, VCI 15 path.
- A labelled unit proves a link-local encapsulation and forwarding selection at an observation point. It does not prove that the packet was delivered, the sender was authenticated, the action was authorized, the design was deployed widely, or later MPLS mechanisms descended from it.
The revealing part of RFC 1954 is not the word label. It is the list of bytes that disappear.
Flow Type 0 removes the familiar LLC/SNAP prefix but leaves the IPv4 datagram intact. Flow Type 2 omits ten original IPv4-header octets but inserts two Reserved octets, making the frame eight octets shorter. Flow Type 1 removes sixteen, including the source and destination addresses, the protocol field and, for TCP or UDP, both ports. An observer who sees the resulting payload cannot interpret it correctly from those bytes alone. The virtual channel and the flow state that selected it have become part of the packet's meaning.
That is a sharper historical lesson than the usual claim that Ipsilon anticipated MPLS. RFC 1954 documents a private, Informational protocol, not an IETF working-group product or a Standards Track architecture. Its durable value lies in the boundary it draws between a control decision and its physical expression on one ATM link.
The default path never disappeared
RFC 1953 defines the preceding bargain. A downstream node may ask an adjacent upstream node to attach a link-level label to a flow. The upstream node may ignore the request. If it accepts, the binding lasts only until the node stops using it or its lifetime expires. A conflicting binding sends the flow back to default forwarding.
RFC 1954 starts after that decision. It does not decide whether the Redirect should be trusted or accepted. It tells an ATM interface what an accepted decision looks like on the wire.
The memo reserves VPI 0, VCI 15 for default encapsulation. Ordinary IPv4 frames there begin with the eight-octet RFC 1483 LLC/SNAP identifier and then carry the complete IPv4 datagram in an AAL-5 CPCS-PDU. The IPv4 MTU is 1500 octets. IFMP control messages must use this default format too.
This is not a cosmetic fallback. It is the common path on which control remains intelligible before, outside and after the shortcut. If a Redirect is ignored, expires or conflicts with current state, forwarding does not need to invent a new frame grammar. It returns to the path whose protocol identity is carried in the LLC/SNAP prefix.
Only two other VPI/VCI meanings are reserved by RFC 1954: VPI 0, VCI 0 marks an unassigned cell, and 0/15 carries the default. The design does not conscript ATM OAM cells, the Cell Loss Priority bit or Available Bit Rate resource-management cells into its mechanism. A capture showing any of those features cannot be credited to RFC 1954 merely because the same link also carried IFMP traffic.
The label became an ATM address
The 32-bit IFMP Label field is not transmitted as an independent shim. On ATM, its low sixteen bits become the VCI, the next twelve become the VPI, and the upper four are reserved. Links that implement fewer VCI or VPI bits zero the unused most-significant positions. Senders should zero the reserved bits; receivers ignore them.
The label therefore selects a virtual channel rather than announcing a global identity. Its meaning belongs to one direction of one adjacency and to the current flow binding. Seeing VPI/VCI x/y at one port does not establish that the same pair means anything at another port, on another switch, after an adjacency restart or in the reverse direction.
This distinction also separates RFC 1954 from GSMP. RFC 1987 gives a controller an asymmetric protocol for creating and deleting switch connections, managing ports, reading configuration and statistics, and receiving switch events. RFC 1954 specifies how IPv4 material is placed into the selected AAL-5 payload. Switch programming and payload format touch the same VPI/VCI, but they are different decisions owned by different evidence.
A complete reconstruction therefore needs at least the accepted IFMP binding, its Flow Type, direction and lifetime; the physical link's VPI/VCI width; the actual VC selected at ingress; the switch connection present at that instant; and the AAL-5 reassembly result. The number alone is not enough.
Three payloads, three different dependencies
Flow Type 0 is the least compressed form. It uses RFC 1483 VC-based multiplexing with null encapsulation: no LLC/SNAP header, but the full IPv4 datagram begins at the first payload octet. Its IPv4 MTU remains 1500. Protocol identification has moved from an in-band prefix to the pre-established VC binding, but ordinary IP parsing still has the complete header.
Flow Type 1 goes much further. It omits Version, IHL, Type of Service, TTL, Protocol, source address and destination address. It also omits the first four octets after the IP header—the TCP or UDP source and destination ports when those protocols are present. What remains begins with Total Length, Identification, flags, fragment offset and a checksum, followed by data. Its MTU is 1484, reflecting the sixteen omitted octets.
Flow Type 2 occupies the middle ground. It omits ten original IPv4-header octets—Version/IHL, TTL and both IP addresses—but inserts two Reserved octets, while retaining Type of Service, Protocol and the first four post-header octets. The net reduction is eight octets, so its MTU is 1492.
Both compressed types retain the original IPv4 Total Length rather than shrinking it to the transmitted byte count. Both transmit a header checksum normalized to the value it would have if TTL were zero. Those decisions are practical clues that the receiver is expected to reconstruct state, not treat the compact payload as a novel autonomous datagram.
The formats cannot safely be guessed from length. Padding may add zero to forty-seven octets before the eight-octet AAL-5 trailer, fragmentation changes the retained fields, and two flows may carry different application data of similar size. The correct parser comes from the Flow Type bound to the VC. If that state is stale, the same bytes can be assigned the wrong header grammar.
The optimization thus saves repeated information by moving it from every packet into shared state. It does not eliminate the information. It relocates it—and relocates the failure mode with it.
What a captured cell can establish
ATM forwards cells, while AAL-5 frames a larger CPCS-PDU across a sequence of them. A cell observed on a labelled VPI/VCI is evidence that an upstream interface selected that channel at that point. Once the complete AAL-5 PDU is reassembled and validated, the payload format may show which Flow Type was applied.
That observation still ends at the link boundary. It does not prove that every cell arrived, the AAL-5 trailer validated, the next node reconstructed the omitted fields correctly, the IPv4 packet survived its next forwarding decision, or the application received useful data. It does not prove that the purported sender owned the flow. RFC 1954 contains no security analysis; the label is neither a credential nor an authorization token.
Even the checksum has a narrower role than its familiar appearance suggests. Normalizing it as if TTL were zero helps the reconstruction convention survive a field that changes hop by hop. It does not authenticate the header, bind the VC to a person, or attest to the route taken before or after the observed link.
The evidence ladder should therefore remain explicit: Redirect received; Redirect accepted; binding current; switch connection programmed; labelled VC selected; complete AAL-5 PDU reassembled; omitted fields reconstructed; IPv4 packet forwarded; next hop received; endpoint received; application acted. Each rung may support the next. None can be silently collapsed into it.
A resemblance is not a genealogy
Later label-switching documents make comparison irresistible. RFC 2105 describes Tag Switching. RFC 3031 defines MPLS forwarding equivalence classes, label stacks and label-switched paths. RFC 5036 specifies LDP and includes ATM label mechanisms. They share vocabulary and confront related problems: moving repeated forwarding work into state and using compact labels in the data plane.
But RFC 1954 supplies no evidence that those later architectures were caused by this one, that deployed implementations were interoperable, or that an IFMP VPI/VCI should be read as an MPLS label stack. Similarity is a research question, not a lineage receipt. It would require design records, author testimony, implementation history and interoperable traces beyond the specifications themselves.
Heng Lu's running-code principle gives the better reading. A common document is valuable when it makes a narrow operation deterministic and locally verifiable. It becomes misleading when publication, nomenclature or institutional familiarity is promoted above what the running system can show. RFC 1954's narrowness is a virtue: it says which VC and which bytes, not who must adopt them or what success ultimately means.
The cell carried a label. The label selected a local execution path. Everything beyond that point still needed evidence of its own.
Sources
- RFC Editor record for RFC 1954
- RFC 1954 — Transmission of Flow Labelled IPv4 on ATM Data Links
- RFC 1953 — Ipsilon Flow Management Protocol
- RFC 1483 — Multiprotocol Encapsulation over ATM Adaptation Layer 5
- RFC 1987 — General Switch Management Protocol
- RFC 2105 — Cisco Systems' Tag Switching Architecture Overview
- RFC 3031 — Multiprotocol Label Switching Architecture
- RFC 5036 — LDP Specification
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Reality Layers and Symbolic Power
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

