Summary

  • RFC 3332's M3UA used a Routing Key to describe a traffic range, a Routing Context to identify that key, and Network Appearance to distinguish a local SS7 network context. They were related but not interchangeable names.
  • One ASP could serve multiple Application Servers through a shared SCTP association, while ASP state was maintained per AS. A green transport association therefore did not say which traffic set was active, whether an SS7 destination was reachable, or whether an MTP3-User received a message.

Three labels, three different questions

M3UA's naming scheme can look like a vocabulary problem until a point code is reused. Then it becomes a routing problem. One SS7 network may assign a point code that another network also uses. If a signalling gateway carries both networks over a common association, the number alone cannot identify which realm a message belongs to. M3UA therefore separates the network context from the rule that selects traffic and from the value that names that rule.

The distinction begins with what M3UA is for. RFC 3332, published in September 2002, defines adaptation for MTP3-User signalling such as ISUP or SCCP messages transported over IP. At a remote Application Server Process, M3UA offers the primitives expected by those MTP3 users. It does not itself become the SS7 MTP3 layer. A Signalling Gateway can receive SS7, while a remote application consumes the user part through the adaptation protocol. The M3UA control plane has to say both which messages go where and which SS7 context gives their fields meaning.

RFC 3332 drew that boundary with a small set of deliberately different objects. An Application Server is a logical service for a specific Routing Key. The key is the selection rule: a set of SS7 parameters defining the traffic range to be handled. Examples may include destination point code, originating point code and service indicator; an application can add user-part fields such as an ISUP circuit identification code or an SCCP subsystem number. Those are examples, not a universal recipe. A key can describe non-contiguous ranges, and its meaningful fields depend on the application and network.

The Routing Context is not a compressed copy of those criteria. It is a value that identifies the Routing Key. The SGP's message-distribution function evaluates traffic against the key; control messages use the associated context to refer to the traffic set that should start, stop or be registered. Think of the key as the rule, the context as the handle, and the Application Server as the service whose traffic that rule selects. Replacing one with another loses either the match criteria or the reference used in control operations.

A network appearance was local, not universal

Network Appearance answers a different question: in which SS7 network context should this signalling message be interpreted? A point code together with that context identifies a signalling node. This matters when a gateway participates in multiple national or private SS7 networks that reuse the same point-code value. Without the network dimension, an apparently precise address can still point to two different nodes.

But Network Appearance is not an Internet-wide network number. RFC 3332 made it a local reference coordinated between the Signalling Gateway Process and Application Server. RFC 4666, the 2006 revision that obsoletes RFC 3332, states the consequence plainly: the same underlying SS7 network may be represented by different Network Appearance values at different SGPs. An operator cannot safely compare the integer across gateways and assume it names the same thing without a mapping record.

The field is also optional in bounded arrangements. A gateway serving one SS7 network may not need it; nor may an association dedicated to one network context. Where context must be distinguished over a shared association, it can be carried for the receiver. Absence is therefore a property of the provisioned topology, not proof that “all networks are one.” Similarly, some restricted single-key cases can imply the Routing Context rather than send it in every message. The protocol permits omission when the configuration makes the value unambiguous. Operators still need the configuration to know why.

One association could contain several application states

The distinction matters again at failover. An ASP is a process instance, not the service definition itself. It may be configured for more than one Application Server, and a single SCTP association may carry traffic related to multiple ASs. RFC 3332 consequently maintains an ASP's state for each AS. ACTIVE is not merely a property of a socket or machine; it is the process's traffic state within a particular application service.

Traffic modes make the scope operational. Override can select one active ASP while others remain backups; Loadshare can divide traffic among active processes; Broadcast can send it to all eligible active processes. The suitable selection algorithm depends on the application. State changes, Routing Contexts and the configured key have to remain joined when the SGP decides which process receives a message. “ASP active” with no AS or context is underspecified; “SCTP association up” is even less informative about service eligibility.

The remote user's view adds another layer. M3UA can carry DATA and network-management indications for destinations that are unavailable, reachable, restricted or congested. A transport association proves that endpoints can communicate. It does not prove that the point-code and network-appearance pair resolved as intended, that the message matched an authorized Routing Key, that an ASP was ACTIVE for the corresponding AS, or that the remote ISUP/SCCP process completed its work. Each claim needs a receipt from its own layer.

Why the 2006 revision matters to a 2002 history

The historical subject is RFC 3332, not an assertion that its text remains the current edition. RFC 4666 obsoleted it in September 2006. The revised text keeps the same central distinctions: Routing Key describes traffic selection; Routing Context identifies that key; Network Appearance supplies SS7 network context and remains local. Reading the successor avoids treating an obsolete specification as today's normative text while showing which design boundaries persisted.

The IANA SCTP registry now lists payload protocol identifier 3 for M3UA and cites RFC 4666. The service-name registry lists m3ua on SCTP port 2905. These entries tell an engineer which code point and registered port are assigned. They do not show that a carrier uses M3UA, that an implementation conforms, or that a particular association carried a call. Likewise, RFC 9260 is the current SCTP specification; its status does not establish that a deployed M3UA system adopted it.

RFC 3331's M2UA is adjacent but different: it carries the MTP2-user boundary while the physical link stays at the gateway. M3UA instead transports MTP3-user signalling, which can include ISUP or SCCP payload. RFC 4233's IUA and RFC 4165's M2PA have their own adaptation boundaries. Shared SIGTRAN ancestry or an SCTP transport does not make their names or state models interchangeable.

The practical test is to ask four questions separately: what SS7 parameters selected this traffic; which Routing Context named that selection; what local Network Appearance made the point code meaningful at this SGP/ASP pair; and which AS-specific ASP state permitted delivery? Only then should the SCTP association be attached as the transport path. RFC 3332's most durable lesson is that the handle for a rule, the rule itself, the network realm and the wire carrying the message are not the same object.

Sources