Summary
- RFC 1461 defined an SNMP management table for multiprotocol traffic over X.25. Its outbound failure counter records an encapsulated address that cannot be resolved to a peer's X.121 address; another counter records the reverse failure on an incoming call.
- Each direction also preserves the last failed address and a time relative to device uptime. The specification even asks agents to count a failure when they cannot confidently assign it to an interface.
The packet knows where it wants to go in IP. The telephone-like X.25 network wants a different number. Between those statements sits the mapping that RFC 1461 made visible in May 1993. Its author, Mark Throop, was defining managed objects, not describing a particular outage. The distinction matters: a circuit can exist while the software still cannot match the packet's encapsulated address to a peer it knows how to call.
RFC 1356 had set the carriage rules for IP and other network-layer protocols over X.25. RFC 1461 supplied the management view. Its first table covers only X.25 interfaces actually carrying multiprotocol traffic. Its peer table stores the X.121 destination, the interface to use and a pointer to call parameters. A third table describes which encapsulations a peer can use. The tables make three different questions inspectable: is this interface participating, is there a peer to dial, and can that peer handle the packet's protocol?
The sharpest object is the outbound lookup-failure counter. It increases when an encapsulated address yields no X.121 destination, whether the implementation tried a peer table or an algorithm. The companion field preserves the last failed address. For IP, that field is five octets: a 0xCC type byte followed by the four address bytes. A third field stores the device-uptime value at the most recent failure. Those are enough to tell an operator which kind of lookup broke and what address last triggered it, without inventing a wall-clock incident time.
The triplet runs in the other direction too. An incoming X.25 call may present an X.121 address that the node cannot recognize as an encapsulated peer address. RFC 1461 gives that failure its own counter, last X.121 address and uptime-relative time. It also records Q-bit closures separately. A rejected caller, a missing outbound destination and a Q-bit closure are different problems; one generic “X.25 down” lamp would throw away that distinction.
The RFC makes a surprisingly frank concession about attribution. If a failed outbound lookup cannot be tied cleanly to a particular packet-layer interface, the agent should choose the first likely table entry and record it anyway. The count is valuable; the interface label may be provisional. A manager who reads the number without that sentence can mistake a bookkeeping choice for a precise fault location.
The underlying X.25 packet-layer MIB, RFC 1382, observes circuits and call parameters. RFC 1461 sits above it, where peer identity and encapsulation choice live. Its management objects reveal the failure before the drama of a circuit teardown: the destination can be absent from the address book while the line itself is perfectly real.
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





