Summary

  • RFC 5133 is a Proposed Standard that updates RFC 4233.
  • RFC 4129 had already assigned management message type 5 to a DUA DLC Status Request.
  • RFC 4233 later assigned the same management type 5 to an IUA TEI Query Request.
  • With the same class and type, a receiver could not distinguish the two operations from that header.
  • RFC 5133 requires TEI Query Requests to use management message type 8.
  • IANA now records type 5 for DLC Status Request and type 8 for TEI Query Request.
  • A registry assignment creates a unique meaning; it does not prove that deployed binaries use it.
  • An SCTP association proves a transport relationship, not RFC 5133 capability or application readiness.
  • RFC 4129 may use DUA PPID 10, but also permits IUA PPID 1 for DUA in combined backhaul deployments.
  • SCTP does not itself interpret the Payload Protocol Identifier, so PPID is not an authorization or semantic-enforcement receipt.
  • TEI status ASSIGNED is bounded Q.921 layer-management state, not a subscriber, device or service identity.
  • Safe migration needs separate registry, build, configuration, transport, wire, decode, response, state and outcome receipts.

A collision in one byte

The original IUA specification in RFC 3057 did not define a TEI Query Request. RFC 4129 extended IUA for DPNSS and DASS 2 and introduced three DLC Status management messages: request type 5, confirm type 6 and indication type 7. RFC 4233 later revised IUA, added the TEI query and placed its request at type 5 as well.

The result was an impossible decoding choice. Both messages were in the management class. Both used type 5. One meant “report the status of these DUA data-link connections.” The other meant “report the TEIs known by the Q.921 side.” A decoder that saw only the common header could not recover the author's intent. Logs could assign a label, but the label would be an implementation guess, not a fact carried by the packet.

RFC 5133 is unusually compact because the required protocol repair is compact. TEI Query messages must use type 8 instead of type 5. IANA reserved management type 8 for that request. The current registry therefore gives the two operations separate coordinates: class 0/type 5 for DLC Status Request and class 0/type 8 for TEI Query Request.

That is a complete namespace correction and an incomplete operational story. A new number does not reach backwards into installed software. It does not announce capability, negotiate a transition or tell an operator whether an old peer will reject type 8. The standard changes what conforming implementations must emit. Running code determines what a particular system actually emits and accepts.

The outer label could not repair the inner ambiguity

It is tempting to argue that SCTP's Payload Protocol Identifier already distinguishes IUA from DUA. RFC 4129 recommends PPID 10 for DUA and PPID 1 for IUA as the primary option. If every deployment used separate identifiers consistently, a receiver could bring useful outer context to the message.

But the same RFC permits the IUA PPID to carry DUA, for example when ISDN and DPNSS are backhauled over one SCTP association. It also states that SCTP does not directly use the PPID; certain network entities may use it to identify the information in a DATA chunk. The PPID is a label delivered to the upper layer, not a semantic firewall enforced by transport.

That distinction explains why the message-type repair was necessary. Optional outer context cannot make a colliding inner namespace safe. Configuration can be wrong. Capture tooling can omit PPID. A combined association can intentionally reuse it. A middlebox may display the number without understanding the application profile. The receiver still needs a class/type pair with one defined meaning.

Nor should the conclusion be reversed. Seeing PPID 1 and management type 8 is strong wire evidence for an IUA TEI Query under the current registry. It is not proof of the sender's organizational identity, its authorization to query the interface, the receiver's implementation version or the eventual status of any terminal. Every field stops at its layer.

Transport up is not application agreement

IUA commonly uses SCTP between a Signaling Gateway and an Application Server Process. RFC 4233 distinguishes the transport association, ASP availability and application traffic state. An SCTP association can be established while an ASP remains inactive. The mapping between an interface identifier and an association or stream can change during failover and can temporarily be invalid.

This makes “SCTP up” a valuable but bounded receipt. It shows that transport setup completed with a peer endpoint under the observed association context. It does not show that the peer understands type 8, selected the same IUA or DUA profile, activated the intended application server, mapped the interface correctly or queried Q.921.

A migration test must therefore go beyond a socket or association health check. Capture the DATA chunk and its PPID. Preserve the SCTP association identity and stream. Decode the IUA common header. Confirm version, class, type and declared length. Record which parser branch handled it. Observe whether the receiver returned Unsupported Message Type, Unexpected Message, another protocol error, silence or TEI Status Indications.

Absence of an error is not enough. The receiver might discard silently, a monitor might miss the reverse direction, or an implementation might accept type 8 while failing later in interface lookup. Positive evidence requires the expected response set within a defined time and context.

A query number does not identify a terminal

RFC 4233 defines the TEI Query as a request from the ASP to query TEIs. It consists of the common header and IUA header. The DLCI in that IUA header must be ignored by the Signaling Gateway. The SG answers with one or more TEI Status Indications.

The instruction to ignore DLCI matters. A generic parser may expose a familiar-looking field, but this operation does not authorize an operator to give that field significance. The query concerns the TEI set, not a target selected by the carried DLCI. An observability system that groups query outcomes by this ignored value invents a relationship the protocol expressly removes.

The status vocabulary is also narrow. ASSIGNED means the TEI is considered assigned by Q.921. UNASSIGNED means it is considered unassigned. Neither value names a person, authenticates equipment, binds a customer account or proves that useful signaling currently crosses a data link. “Considered assigned” is deliberately a statement by one layer-management entity.

RFC 4233 explains why the information is useful. An ASP can prepare for signaling, decide whether to request data-link establishment and investigate a link established for a TEI it did not know was assigned. Those are next actions, not hidden implications. The response can guide a data-link operation; it does not prove the operation has occurred.

For a service claim, continue the chain. Establish which TEI Status Indications correspond to the query and interface. Verify completeness and freshness. Observe Q.921 state. If a link is requested, record the Establish exchange and local primitive. Then observe signaling traffic and the application or service result. A type-8 packet is the beginning of that evidence sequence, not its conclusion.

The dangerous kindness of fallback

During a mixed-version rollout, a new sender may transmit type 8 to an old receiver that knows only RFC 4233's type 5 assignment. The receiver may return Unsupported Message Type, treat the message as unexpected or fail without a useful reply. An operator facing an outage may propose a simple fallback: retry the same query as type 5.

That fallback is not equivalent to retrying on another route. It changes the semantic discriminator to the value that caused the collision. In a DUA context, or where DUA uses the IUA PPID, the retry can be interpreted as DLC Status Request. The compatibility measure silently recreates the ambiguity that RFC 5133 removed.

If legacy acceptance is unavoidable, it needs a bounded compatibility contract. Identify the exact peers allowed to receive type 5. Separate IUA-only conditions from DUA or combined associations. Emit telemetry for every fallback. Reject ambiguous contexts. Set a retirement date. Test negative cases in which a type-5 packet must never enter the TEI-query parser.

Do not let “temporary” become an unobservable permanent dialect. Once a shim makes the fleet look green, the incentive to upgrade the final peers disappears. The system then depends on role configuration to decide what identical bytes mean. That is institutional debt encoded in a parser.

Registry truth, fleet truth and packet truth

The IANA registry answers a specific question: which management message type is assigned to which operation under the standard namespace? Its present answer is clear. That record is essential for implementers, tests and protocol analyzers. It is not a live inventory of every device.

A software bill of materials or vendor declaration provides a different receipt. It can show that a release claims RFC 5133 support. A reproducible test or code inspection can show the behavior of a build. Configuration shows which build and mode a node is expected to run. A packet trace shows what bytes appeared at one observation point. A receiver trace shows which code path acted. A response shows what the peer reported. None should be substituted for another.

This separation prevents two opposite errors. The first is fatalism: treating a 2007 collision as if it still makes every current deployment unknowable. The registry and updated implementations solve the ambiguity when type 8 is used correctly. The second is paperwork optimism: treating publication and reservation as if they upgraded a fleet. They did not.

Running code is not an argument against standards. It is how the standard becomes observable. The standard gives an unambiguous expected bit pattern. The deployment proves whether that pattern is present, accepted and effective.

What the sources establish

The RFC Editor and Datatracker records establish RFC 5133's publication status, date and update relationship. RFC 5133 establishes the collision and the mandatory change from 5 to 8. RFC 4129 establishes the DUA DLC Status types and the optional PPID-sharing condition. RFC 4233 establishes IUA headers, errors, TEI procedures, ASP states and security context. IANA records the current allocation. SCTP documents define the transport beneath these application semantics.

They do not establish a named vendor's implementation, the upgrade state of a production peer, a packet capture, a terminal's human or organizational identity, or a service outcome. Those require deployment-specific evidence. The honest conclusion is neither “the registry proves the network” nor “the registry is irrelevant.” The registry makes a testable distinction possible. Operations must collect the rest.

Sources