Summary

  • RFC 3332 moved the adaptation boundary above MTP3. The Signalling Gateway terminated MTP2 and MTP3, then delivered ISUP, SCCP and other MTP3-user traffic to IP applications selected by a Routing Key and named on the wire by a Routing Context.
  • Registration, ASP activation and SS7 destination availability were separate receipts. A gateway could accept a key, activate an application process and still report the selected destination unavailable. RFC 4666 obsoleted RFC 3332 in 2006, so the earlier document is historical evidence, not the current protocol authority.

A route became a policy object

In a conventional SS7 node, the relationship between network routing and the local user part was largely contained inside one system. RFC 3332 distributed that relationship. Its Signalling Gateway received native SS7, terminated MTP2 and MTP3, and sent MTP3-user messages—such as ISUP call-control or SCCP traffic—over an IP transport to an Application Server Process. Selected MTP network-management events crossed the same boundary.

This was a different cut from RFC 3331's M2UA. M2UA left a physical signalling link and MTP2 at the gateway and let remote MTP3 operate their boundary through an Interface Identifier. M3UA cut one layer higher. MTP3 itself stayed at the gateway. The remote application received the service that an MTP3 user expected, not control of a particular physical link.

Once the upper-layer user had moved, the gateway needed a rule for deciding which remote application owned which signalling. RFC 3332 called that rule a Routing Key. A key could describe a range using the Service Information Octet, destination and originating point codes, circuit-identification ranges, or a destination/origin/SCCP subsystem combination. An Application Server was the logical entity serving one such key. A Routing Context was the compact value used to identify the key in protocol messages.

The change was conceptually large. A route was no longer merely a path through a signalling network. At the adaptation boundary, it also became an administrative statement: traffic with these attributes belongs to this application service. The key did not discover that truth. An operator provisioned it, or a peer proposed it through Routing Key Management and the gateway accepted or rejected the registration.

Acceptance was not authority

A successful registration response can be a useful receipt. It shows that, at a particular time, an SGP accepted a proposed mapping and returned a Routing Context. It does not show why the peer was entitled to represent the relevant point codes, whether another key overlapped, whether local policy was correct, or whether the destination was currently reachable.

That distinction matters because the fields in a Routing Key look authoritative. A destination point code, service indicator and circuit range resemble coordinates. Yet coordinates do not prove ownership. Network Appearance adds another local qualification: the same point-code value may be reused in separate SS7 networks, so the appearance helps the peers interpret which network the value belongs to. It is shared context, not a global certificate.

An incident investigator therefore needs the complete selection receipt: the key fields, Network Appearance, registration request and response, resulting Routing Context, configuration source and authorizing change. A packet containing a Routing Context proves only that the sender used a locally meaningful number. Without the map, it says nothing about the intended traffic domain.

Overlapping or overly broad keys are especially hazardous. They can deliver valid-looking signalling to the wrong application without breaking the SCTP association. A transport dashboard may remain green while call state or database transactions diverge behind it. The failure is not packet loss; it is a wrong policy expressed as a successful selection.

Three state machines refused to collapse

RFC 3332 separated transport, application and signalling-network state. SCTP supplied an association and streams. ASP state management distinguished DOWN, INACTIVE and ACTIVE processes. Application Server state and traffic modes—Override, Loadshare or Broadcast—determined which active process should receive selected traffic. None of those states described whether an SS7 destination could actually be reached.

Destination truth arrived through a different mechanism. Signalling Network Management messages reported Destination Unavailable, Destination Available, Signalling Congestion and Destination User Part Unavailable; an audit could ask for current destination state. When an ASP used several gateways, M3UA had to keep route status per gateway and derive the overall availability that it exposed to the MTP3 user.

This produces a perfectly valid but operationally awkward scene: the SCTP association is established, the ASP is ACTIVE for a Routing Context, and a DUNA says that a destination selected by the key is unavailable. No contradiction exists. The first fact concerns transport, the second concerns application eligibility, and the third concerns an SS7 route. A single health light would destroy information.

DAVA is bounded in the same way. It says the reporting M3UA layer considers the destination available under its current view. It does not prove that an ISUP call completed, that an SCCP transaction reached its final application, or that the destination remained reachable after the report. User-part outcome requires its own acknowledgement, response or error evidence.

Failover preserved selection, not necessarily knowledge

M3UA supported multiple ASPs and multiple SGPs so traffic could move when a process or path failed. That redundancy was valuable, but it widened the reconciliation problem. A replacement ASP could become active for the same key while holding stale destination state. A surviving association could continue carrying traffic after a route changed. A gateway switch could alter the available SS7 paths even though the Routing Context remained identical.

The safe sequence was not merely “association up, ASP active, resume.” It required reconciling the current Routing Key, authorized membership, traffic mode, per-SGP destination state, congestion and any restart condition. DAUD existed because remembered state was not enough. Even an audit response remained a time-bound observation that could race with the next DUNA, DAVA or congestion event.

Queueing makes the consequences harder to see. Load sharing may spread traffic across processes while one process has not reconstructed state. Override mode may move all work to a new owner. If the selection rule is wrong, redundancy repeats the wrong decision faster. If destination evidence is stale, failover preserves availability of the software while degrading the truth on which it routes.

The document itself has a time boundary

RFC 3332 was published in September 2002 as a Standards Track specification. RFC 4666, published four years later, explicitly obsoleted it. The historical document is valuable because it exposes the architectural transition and vocabulary, but current protocol interpretation belongs with the successor. Quoting RFC 3332 without that boundary would turn archival evidence into false present authority.

The same caution applies to adjacent records. RFC 2719 explains the SIGTRAN framework. RFC 9260 is the current SCTP base specification. RFC 3788 develops security considerations for SIGTRAN. RFC 4165 helps distinguish M2PA's peer-to-peer link model. IANA still records signalling-adaptation message classes, parameters and SCTP assignments. None of those records demonstrates that a particular operator deploys M3UA, that a route is live, or that an implementation conforms.

Security cannot be inferred from a successful exchange either. SCTP transport mechanisms do not authenticate the business meaning of a Routing Key. A peer can be cryptographically identified and still be unauthorized for a destination range; a configuration can be authorized and still be wrong. Transport protection, peer identity, routing authorization and destination status remain separate controls.

The lasting lesson is to preserve four receipts

RFC 3332's most durable insight is not that SS7 could cross IP. It is that distributing a network boundary turns implicit relationships into policy objects. Those objects must be named, versioned and observed without pretending that their state proves the state of the world behind them.

Preserve four receipts for every consequential transfer. First, the selection receipt: full Routing Key, Network Appearance, Routing Context and configuration provenance. Second, the application receipt: association, ASP/AS state, traffic mode and active membership. Third, the route receipt: chosen gateway, destination status, congestion, restart and audit sequence. Fourth, the outcome receipt: the user-part acknowledgement, response or failure that closes the transaction.

The gateway's key answered “which application should see this signalling?” It never answered “can the signalling destination be reached?” or “did the remote operation succeed?” The architecture worked because the protocol kept those questions apart. Operations fail when dashboards put them back together.

Sources