Summary

  • TALI 2.0 had to treat a connected peer as version 1.0 until a moni message identified version 2.0; new opcodes were gated on that evidence.
  • RFC 3094 was an Informational Tekelec proposal, and its IESG Note explicitly said it was an alternative to SIGTRAN work that the IETF had not reviewed for technical soundness or completeness.

The boundary appears before any SS7 message is exchanged. RFC 3094 describes the Transport Adapter Layer Interface (TALI), a Tekelec proposal for moving signaling between a switched-circuit network and IP. A Signaling Gateway could carry SCCP, ISUP and MTP-related messages over TCP/IP, alongside management and circuit-registration functions. The document is detailed: it defines message formats, timers, peer states and separate TALI 1.0 and 2.0 behavior. But a detailed specification is still only a specification. The RFC's front matter makes that status unusually hard to miss.

The IESG Note says TALI presents a vendor's alternative to standards-track technology then being developed by the IETF SIGTRAN Working Group. It adds that the IETF had not reviewed the proposal for technical soundness or completeness and urges potential users to examine SIGTRAN before deciding whether to use it. The note does not say the IETF found TALI unsound, rejected it, or proved that it was never deployed. It states a limit on the review and a recommendation about what to compare.

Inside TALI, the sharpest engineering problem is backward compatibility. Version 1.0 did not provide a simple version-identification method. Version 2.0 reuses the existing moni (monitor) message. It reserves a fixed 12-byte version label in the data, leaving the rest available for implementation-specific information; the documented data portion must still stay within 200 bytes. The same message continues to support an echo function that can be used for round-trip timing or other local purposes.

That small label changes what a peer is allowed to send. On a new connection, a 2.0 implementation starts with far_end_version set to 1.0. It can announce itself through moni, but it must not infer that the other side supports 2.0 merely because the local process does. It must inspect an incoming monitor message for the recognized version string. If no identifying message arrives, or its label is not recognized, the peer remains classified as 1.0.

The version flag gates three new 2.0 opcodes: mgmt, xsrv and spcl. A 1.0 implementation would treat those opcodes as invalid and immediately drop the socket. So a 2.0 node must wait until it has identified the far end as 2.0 or later before sending them. If it sees a 1.0 peer, it falls back to 1.0 features. The document also describes 1.0 receivers ignoring the additional moni data and continuing their ordinary monitor/acknowledgement exchange. Compatibility is therefore not a promise that every side understands every feature; it is a rule for keeping the connection usable without sending an opcode the peer will reject.

This is a concrete control surface, not a general slogan about backward compatibility. The local implementation owns its version announcement; the remote implementation supplies evidence of its version; the state machine tracks that observation; and the opcode gate decides whether a capability can cross the socket. The design does not let a vendor label, a document's version number, or a local configuration stand in for a peer's observed declaration.

The surrounding standards history must be read with the same care. RFC 2719 had already described the SIGTRAN architecture. Later standards-track documents specified adaptation layers such as M2UA, M3UA and SUA, and SCTP became a transport path used in that work. RFC 3094 also discusses an SCTP stack alternative. These records establish parallel and later specification work. They do not, by themselves, show that TALI was replaced, that a particular network migrated, or that two implementations interoperated.

RFC 3094 is dated April 2001 and is marked Informational; it says it does not specify an Internet standard. It was published, its mechanisms were documented, and its review limit was stated. Those are three different facts. Neither the completeness of its state machine nor the IESG warning settles deployment or quality. For those conclusions, evidence would have to come from running implementations, test results, operator records or traffic—not from the RFC number alone.

Sources