Data message received for the AS, to accommodate any potential
failover or rebalancing of the offered load.
In the case of a Broadcast mode AS, reception of an ASP Active
message at an SGP or IPSP causes the direction of traffic to the ASP
sending the ASP Active message, in addition to all the other ASPs
that are currently active in the AS. The algorithm at the SGP for
broadcasting traffic within an AS to all the active ASPs is a simple
broadcast algorithm, where every message is sent to each of the
active ASPs.
An SGP or IPSP, upon reception of an ASP Active message for the first
ASP in a Broadcast AS, MAY choose not to direct traffic to a newly
active ASP until it determines that there are sufficient resources to
handle the expected load (e.g., until there are "n" ASPs in state
ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold
the Notify (AS-ACTIVE) until there are sufficient resources.
For the n+k redundancy case, ASPs which are in that AS should
coordinate among themselves the number of active ASPs in the AS, and
should start sending traffic only after n ASPs are active.
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
MUST tag the first DATA message broadcast in each traffic flow with
a unique Correlation Id parameter. The purpose of this Id is to
permit the newly active ASP to synchronize its processing of traffic
in each traffic flow with the other ASPs in the broadcast group.
4.3.4.3.1 IPSP Considerations (ASP Active)
Either of the IPSPs can initiate communication. When an IPSP receives
an ASP Active, it should mark the peer as ASP-ACTIVE and return an
ASP Active Ack message. An ASP receiving an ASP Active Ack message
may mark the peer as ASP-Active, if it is not already in the ASP-
ACTIVE state.
Alternatively, an interchange of ASP Active messages from each end
can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular
AS to be activated from each end. It is especially useful when an
IPSP is serving more than one AS. It would need four messages for
completion.
4.3.4.4 ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS,
the ASP sends an ASP Inactive message to the SGP or IPSP. This
action MAY be initiated at the ASP by an M-ASP_INACTIVE request
primitive from Layer Management or MAY be initiated automatically by
an M3UA management function. In the case where an ASP is processing
the traffic for more than one Application Server across a common SCTP
association, the ASP Inactive message contains one or more Routing
Contexts to indicate for which Application Servers the ASP Inactive
message applies. In the case where an ASP Inactive message does not
contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Servers the ASP is a member and
move the ASP to the ASP-INACTIVE state in all Application Servers. In
the case of an Override mode AS, where another ASP has already taken
over the traffic within the AS with an ASP Active ("Override")
message, the ASP that sends the ASP Inactive message is already
considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive
Ack message is sent to the ASP, after ensuring that all traffic is
stopped to the ASP.
In the case of a Loadshare mode AS, the SGP moves the ASP to the
ASP-INACTIVE state and the AS traffic is reallocated across the
remaining ASPs in the state ASP-ACTIVE, as per the loadsharing
algorithm currently used within the AS. A Notify message
("Insufficient ASP resources active in AS") MAY be sent to all
inactive ASPs, if required. An ASP Inactive Ack message is sent to
the ASP after all traffic is halted and Layer Management is informed
with an M-ASP_INACTIVE indication primitive.
In the case of a Broadcast mode AS, the SGP moves the ASP to the
ASP-INACTIVE state and the AS traffic is broadcast only to the
remaining ASPs in the state ASP-ACTIVE. A Notify message
("Insufficient ASP resources active in AS") MAY be sent to all
inactive ASPs, if required. An ASP Inactive Ack message is sent to
the ASP after all traffic is halted and Layer Management is informed
with an M-ASP_INACTIVE indication primitive.
Multiple ASP Inactive Ack messages MAY be used in response to an ASP
Inactive message containing multiple Routing Contexts, allowing the
SGP or IPSP to independently acknowledge for different (sets of)
Routing Contexts. The SGP or IPSP sends an Error message ("Invalid
Routing Context") message for each invalid or unconfigured Routing
Context value in a received ASP Inactive message.
The SGP MUST send an ASP Inactive Ack message in response to a
received ASP Inactive message from the ASP and the ASP is already
marked as ASP-INACTIVE at the SGP.
At the ASP, the ASP Inactive Ack message received is not
acknowledged. Layer Management is informed with an M-ASP_INACTIVE
confirm primitive. If the ASP receives an ASP Inactive Ack without
having sent an ASP Inactive message, the ASP should now consider
itself as in the ASP-INACTIVE state. If the ASP was previously in
the ASP-ACTIVE state, the ASP should then initiate procedures to
return itself to its previous state.
When the ASP sends an ASP Inactive message it starts timer T(ack).
If the ASP does not receive a response to an ASP Inactive message
within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive
messages until it receives an ASP Inactive Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication.
If no other ASPs in the Application Server are in the state ASP-
ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all of
the ASPs in the AS which are in the state ASP-INACTIVE. The SGP
SHOULD start buffering the incoming messages for T(r) seconds, after
which messages MAY be discarded. T(r) is configurable by the network
operator. If the SGP receives an ASP Active message from an ASP in
the AS before expiry of T(r), the buffered traffic is directed to
that ASP and the timer is cancelled. If T(r) expires, the AS is moved
to the AS-INACTIVE state.
4.3.4.4.1 IPSP Considerations (ASP Inactive)
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP
after an ASP Inactive or ASP Inactive Ack message has been received
from it.
Alternatively, an interchange of ASP Inactive messages from each end
can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular
AS to be deactivated from each end. It is especially useful when an
IPSP is serving more than one AS. It would need four messages for
completion.
4.3.4.5 Notify Procedures
A Notify message reflecting a change in the AS state MUST be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message must be sent whether the AS
state change was a result of an ASP failure or reception of an ASP
State management (ASPSM) / ASP Traffic Management (ASPTM) message.
In the second case, the Notify message MUST be sent after any related
acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active
Ack, or ASP Inactive Ack).
In the case where a Notify message ("AS-PENDING") message is sent by
an SGP that now has no ASPs active to service the traffic, or where a
Notify ("Insufficient ASP resources active in AS") message is sent in
the Loadshare or Broadcast mode, the Notify message does not
explicitly compel the ASP(s) receiving the message to become active.
The ASPs remain in control of what (and when) traffic action is
taken.
In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which
Application Servers the ASP is a member and take the appropriate
action in each AS.
4.3.4.5.1 IPSP Considerations (NTFY)
Notify works in the same manner as in the SG-AS case. One of the
IPSPs can send this message to any remote IPSP that is not in the
ASP-DOWN state.
4.3.4.6 Heartbeat Procedures
The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than SCTP).
Either M3UA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer T(beat). Upon receiving a Heartbeat
message, the M3UA peer MUST respond with a Heartbeat Ack message.
If no Heartbeat Ack message (or any other M3UA message) is received
from the M3UA peer within 2*T(beat), the remote M3UA peer is
considered unavailable. Transmission of Heartbeat messages is
stopped and the signalling process SHOULD attempt to re-establish
communication if it is configured as the client for the disconnected
M3UA peer.
The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Heartbeat
Ack message. The sender, upon examining the contents of the returned
Heartbeat Ack message, MAY choose to consider the remote M3UA peer as
unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original
sender. The contents may be used, for example, to support a
Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a
timestamp mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 3 "ASP state
transition diagram".
4.4 Routing Key Management Procedures [Optional]
4.4.1 Registration
An ASP MAY dynamically register with an SGP as an ASP within an
Application Server using the REG REQ message. A Routing Key
parameter in the REG REQ message specifies the parameters associated
with the Routing Key.
The SGP examines the contents of the received Routing Key parameter
and compares it with the currently provisioned Routing Keys. If the
received Routing Key matches an existing SGP Routing Key entry, and
the ASP is not currently included in the list of ASPs for the related
Application Server, the SGP MAY authorize the ASP to be added to the
AS. Or, if the Routing Key does not currently exist and the received
Routing Key data is valid and unique, an SGP supporting dynamic
configuration MAY authorize the creation of a new Routing Key and
related Application Server and add the ASP to the new AS. In either
case, the SGP returns a Registration Response message to the ASP,
containing the same Local-RK-Identifier as provided in the initial
request, and a Registration Result "Successfully Registered". A
unique Routing Context value assigned to the SGP Routing Key is
included. The method of Routing Context value assignment at the SGP
is implementation dependent but must be guaranteed to be unique for
each Application Server or Routing Key supported by the SGP.
If the SGP does not support the registration procedure, the SGP
returns an Error message to the ASP, with an error code of
"Unsupported Message Type".
If the SGP determines that the received Routing Key data is invalid,
or contains invalid parameter values, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error
Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network
Appearance" as appropriate.
If the SGP determines that a unique Routing Key cannot be created,
the SGP returns a Registration Response message to the ASP, with a
Registration Status of "Error - "Cannot Support Unique Routing" An
incoming signalling message received at an SGP should not match
against more than one Routing Key.
If the SGP does not authorize an otherwise valid registration
request, the SGP returns a REG RSP message to the ASP containing the
Registration Result "Error - Permission Denied".
If an SGP determines that a received Routing Key does not currently
exist and the SGP does not support dynamic configuration, the SGP
returns a Registration Response message to the ASP, containing a
Registration Result "Error - Routing Key not Currently Provisioned".
If an SGP determines that a received Routing Key does not currently
exist and the SGP supports dynamic configuration but does not have
the capacity to add new Routing Key and Application Server entries,
the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Insufficient Resources".
If an SGP determines that one or more of the Routing Key parameters
are not supported for the purpose of creating new Routing Key
entries, the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Unsupported RK parameter
field". This result MAY be used if, for example, the SGP does not
support RK Circuit Range Lists in a Routing Key because the SGP does
not support ISUP traffic, or does not provide CIC range granularity.
A Registration Response "Error - Unsupported Traffic Handling Mode"
is returned if the Routing Key in the REG REQ contains an Traffic
Handling Mode that is inconsistent with the presently configured mode
for the matching Application Server.
An ASP MAY register multiple Routing Keys at once by including a
number of Routing Key parameters in a single REG REQ message. The
SGP MAY respond to each registration request in a single REG RSP
message, indicating the success or failure result for each Routing
Key in a separate Registration Result parameter. Alternatively the
SGP MAY respond with multiple REG RSP messages, each with one or more
Registration Result parameters. The ASP uses the Local-RK-Identifier
parameter to correlate the requests with the responses.
Upon successful registration of an ASP in an AS, the SGP can now send
related SS7 Signalling Network Management messaging, if this did not
previously start upon the ASP transitioning to state ASP-INACTIVE
4.4.2 Deregistration
An ASP MAY dynamically deregister with an SGP as an ASP within an
Application Server using the DEREG REQ message. A Routing Context
parameter in the DEREG REQ message specifies which Routing Keys to
deregister. An ASP SHOULD move to the ASP-INACTIVE state for an
Application Server before attempting to deregister the Routing Key
(i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP
SHOULD deregister from all Application Servers that it is a member
before attempting to move to the ASP-Down state.
The SGP examines the contents of the received Routing Context
parameter and validates that the ASP is currently registered in the
Application Server(s) related to the included Routing Context(s). If
validated, the ASP is deregistered as an ASP in the related
Application Server.
The deregistration procedure does not necessarily imply the deletion
of Routing Key and Application Server configuration data at the SG.
Other ASPs may continue to be associated with the Application Server,
in which case the Routing Key data SHOULD NOT be deleted. If a
Deregistration results in no more ASPs in an Application Server, an
SG MAY delete the Routing Key data.
The SGP acknowledges the deregistration request by returning a DEREG
RSP message to the requesting ASP. The result of the deregistration
is found in the Deregistration Result parameter, indicating success
or failure with cause.
An ASP MAY deregister multiple Routing Contexts at once by including
a number of Routing Contexts in a single DEREG REQ message. The SGP
MAY respond to each deregistration request in a single DEREG RSP
message, indicating the success or failure result for each Routing
Context in a separate Deregistration Result parameter.
4.4.3 IPSP Considerations (REG/DEREG)
The Registration/Deregistration procedures work in the IPSP cases in
the same way as in AS-SG cases. An IPSP may register an RK in the
remote IPSP. An IPSP is responsible for deregistering the RKs that
it has registered.
4.5 Procedures to Support the Availability or Congestion Status of SS7
Destination
4.5.1 At an SGP
On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
primitive from the nodal interworking function at an SGP, the SGP
M3UA layer will send a corresponding SS7 Signalling Network
Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4)
to the M3UA peers at concerned ASPs. The M3UA layer must fill in
various fields of the SSNM messages consistently with the information
received in the primitives.
The SGP M3UA layer determines the set of concerned ASPs to be
informed based on the specific SS7 network for which the primitive
indication is relevant. In this way, all ASPs configured to
send/receive traffic within a particular network appearance are
informed. If the SGP operates within a single SS7 network
appearance, then all ASPs are informed.
DUNA, DAVA, SCON, and DRST messages may be sent sequentially and
processed at the receiver in the order sent.
Sequencing is not required for the DUPU or DAUD messages, which MAY
be sent unsequenced.
4.5.2 At an ASP
4.5.2.1 Single SG Configurations
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM)
message from the remote M3UA Peer, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users. Local
management is informed.
In the case where a local event has caused the unavailability or
congestion status of SS7 destinations, the M3UA layer at the ASP
SHOULD pass up appropriate indications in the primitives to the M3UA
User, as though equivalent SSNM messages were received. For example,
the loss of an SCTP association to an SGP may cause the
unavailability of a set of SS7 destinations. MTP-PAUSE indication
primitives to the M3UA User are appropriate.
4.5.2.2 Multiple SG Configurations
At an ASP, upon receiving a Signalling Network Management message
from the remote M3UA Peer, the M3UA layer updates the status of the
affected route(s) via the originating SG and determines, whether or
not the overall availability or congestion status of the effected
destination(s) has changed. If so, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users. Local
management is informed.
Implementation Note: To accomplish this, the M3UA layer at an ASP
maintains the status of routes via the SG, much like an MTP3 layer
maintains route-set status.
4.5.3 ASP Auditing
An ASP may optionally initiate an audit procedure to enquire of an
SGP the availability and, if the national congestion method with
multiple congestion levels and message priorities is used, congestion
status of an SS7 destination or set of destinations. A Destination
Audit (DAUD) message is sent from the ASP to the SGP requesting the
current availability and congestion status of one or more SS7
Destination Point Codes.
The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the
ASP in the following cases:
- Periodic. A Timer originally set upon reception of a DUNA, SCON
or DRST message has expired without a subsequent
DAVA, DUNA, SCON or DRST message updating the
availability/congestion status of the affected
Destination Point Codes. The Timer is reset upon
issuing a DAUD. In this case the DAUD is sent to the
SGP that originally sent the SSNM message.
- Isolation. The ASP is newly ASP-ACTIVE or has been
isolated from an SGP for an extended period. The ASP
MAY request the availability/congestion status of one
or more SS7 destinations to which it expects to
communicate.
IMPLEMENTATION NOTE: In the first of the cases above, the auditing
procedure must not be invoked for the case of a received SCON message
containing a congestion level value of "no congestion" or undefined"
(i.e., congestion Level = "0"). This is because the value indicates
either congestion abatement or that the ITU MTP3 international
congestion method is being used. In the international congestion
method, the MTP3 layer at the SGP does not maintain the congestion
status of any destinations and therefore the SGP cannot provide any
congestion information in response to the DAUD. For the same reason,
in the second of the cases above a DAUD message cannot reveal any
congested destination(s).
The SGP SHOULD respond to a DAUD message with the MTP3
availability/congested status of the routeset associated with each
Destination Point Code(s) in the DAUD message. The status of each
SS7 destination requested is indicated in a DUNA message (if
unavailable), a DAVA message (if available), or a DRST (if restricted
and the SGP supports this feature). Where the SGP maintains the
congestion status of the SS7 destination, and the SS7 destination is
congested, the SGP MUST additionally respond with an SCON message
before the DAVA or DRST message. If the SS7 destination is available
and congested, the SGP MUST respond with an SCON message and then a
DAVA message. If the SS7 destination is restricted and congested,
the SGP MUST respond with an SCON message immediately followed by a
DRST message. If the SGP has no information on the availability
status of the SS7 destination, the SGP responds with a DUNA message,
as it has no routing information to allow it to route traffic to this
destination.
Any DUNA or DAVA message in response to a DAUD message MAY contain a
list of Affected Point Codes.
An SG MAY refuse to provide the availability or congestion status of
a destination if, for example, the ASP is not authorized to know the
status of the destination. The SG MAY respond with an Error Message
(Error Code = "Destination Status Unknown")
4.6 MTP3 Restart
In the case where the MTP3 in the SG undergoes an MTP restart, event
communication SHOULD be handled as follows:
When the SG discovers SS7 network isolation, the SGPs send an
indication to all concerned available ASPs (i.e., ASPs in the ASP-
ACTIVE state) using DUNA messages for the concerned destinations.
When the SG has completed the MTP Restart procedure, the M3UA layers
at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
available/restricted SS7 destinations using the DAVA/DRST messages.
No message is necessary for those destinations still unavailable
after the restart procedure.
When the M3UA layer at an ASP receives a DUNA message indicating SS7
destination unavailability at an SG, MTP Users will receive an MTP-
PAUSE indication and will stop any affected traffic to this
destination. When the M3UA receives a DAVA/DRST message, MTP Users
will receive an MTP-RESUME indication and can resume traffic to the
newly available SS7 destination, provided the ASP is in the ASP-
ACTIVE state towards this SGP.
The ASP MAY choose to audit the availability of unavailable
destinations by sending DAUD messages. This would be for example the
case when an AS becomes active at an ASP and does not have current
destination statuses. If MTP restart is in progress at the SG, the
SGP returns a DUNA message for that destination, even if it received
an indication that the destination became available or restricted.
In the IPSP case, MTP restart could be considered if the IPSP also
has connection to an SS7 network. In that case, the same behavior as
described above for the SGP would apply to the restarting IPSP. This
would also be the case if the IPSPs were perceived as exchanging MTP
Peer PDUs, instead of MTP primitives between MTP User and MTP
Provider. In other words, M3UA does not provide the equivalent to
Traffic Restart Allowed messages indicating the end of the restart
procedure between peer IPSPs that would also be connected to an SS7
network.
5. Examples of M3UA Procedures
NOTE: Not all the Notify messages that are appropriate per the Notify
procedures are shown in these examples.
5.1 Establishment of Association and Traffic between SGPs and ASPs
These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two
IPSPs. In all cases it is assumed that the SCTP association is
already set up.
5.1.1 Single ASP in an Application Server ("1+0" sparing),
These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP where only one ASP
is configured within an AS (no backup).
5.1.1.1 Single ASP in an Application Server ("1+0" sparing),
No Registration
SGP ASP1
| |
|<-------------ASP Up-----------|
|-----------ASP Up Ack--------->|
| |
|<------- ASP Active(RCn)-------| RC: Routing Context
|-----ASP Active Ack (RCn)----->| (optional)
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: If the ASP Active message contains an optional Routing Context
parameter, the ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the SGP responds with an Error
message.
5.1.1.2 Single ASP in Application Server ("1+0" sparing),
Dynamic Registration
This scenario is the same as for 5.1.1.1 but with the optional
exchange of registration information. In this case the Registration
is accepted by the SGP.
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing
| | Context
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP will not subsequently send an ASP
Active message.
5.1.1.3 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 1 - Multiple
Registration Requests)
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Context
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP will not subsequently send an ASP
Active message. Each LRC/RK pair registration is considered
independently.
It is not necessary to follow a Registration Request/Response message
pair with an ASP Active message before sending the next Registration
Request. The ASP Active message can be sent at any time after the
related successful registration.
5.1.1.4 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 2 - Single
Registration Request)
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<---REGISTER REQ({LRC1,RK1},---|
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
Note: In the case of an unsuccessful registration attempt (e.g.,
Invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP will not subsequently send an ASP
Active message. Each LRC/RK pair registration is considered
independently.
The ASP Active message can be sent at any time after the related
successful registration, and may have more than one RC.
5.1.2 Two ASPs in Application Server ("1+1" sparing)
This scenario shows the example M3UA message flows for the
establishment of traffic between an SGP and two ASPs in the same
Application Server, where ASP1 is configured to be in the ASP-ACTIVE
state and ASP2 is to be a "backup" in the event of communication
failure or the withdrawal from service of ASP1. ASP2 may act as a
hot, warm, or cold backup depending on the extent to which ASP1 and
ASP2 share call/transaction state or can communicate call state under
failure/withdrawal events. The example message flow is the same
whether the ASP Active messages indicate "Override", "Loadshare" or
"Broadcast" mode, although typically this example would use an
Override mode.
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |
5.1.3 Two ASPs in an Application Server ("1+1" sparing,
loadsharing case)
This scenario shows a similar case to Section 5.1.2 but where the two
ASPs are brought to the state ASP-ACTIVE and subsequently loadshare
the traffic. In this case, one ASP is sufficient to handle the total
traffic load.
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|---------------------------NOTIFY (AS-ACTIVE------>|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |
5.1.4 Three ASPs in an Application Server ("n+k" sparing,
loadsharing case)
This scenario shows the example M3UA message flows for the
establishment of traffic between an SGP and three ASPs in the same
Application Server, where two of the ASPs are brought to the state
ASP-ACTIVE and subsequently share the load. In this case, a minimum
of two ASPs are required to handle the total traffic load (2+1
sparing).
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|---------Notify (AS-ACTIVE)----------->| |
|----------------------Notify (AS-ACTIVE)------------------>|
5.2 ASP Traffic Failover Examples
5.2.1 (1+1 Sparing, Withdrawal of ASP, Backup Override)
Following on from the example in Section 5.1.2, and ASP1 withdraws
from service:
SGP ASP1 ASP2
| | |
|<-----ASP Inactive------| |
|----ASP Inactive Ack--->| |
| | |
|----NTFY(AS-PENDING)--->| |
|-----------------------NTFY(AS-PENDING)----------->|
| | |
|<----------------------------- ASP Active----------|
|-----------------------------ASP Active Ack------->|
| | |
|----NTFY(AS-ACTIVE)---->| |
|-----------------------NTFY(AS-ACTIVE)------------>|
Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g.,
M3UA heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP to ASP1) would not occur.
5.2.2 (1+1 Sparing, Backup Override)
Following on from the example in Section 5.1.2, ASP2 wishes to
Override ASP1 and take over the traffic:
SGP ASP1 ASP2
| | |
|<----------------------------- ASP Active----------|
|------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)-->|
| | |
5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP)
Following on from the example in Section 5.1.4, and ASP1 withdraws
from service:
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |
For the Notify message to be sent, the SG maintains knowledge of the
minimum ASP resources required (e.g., if the SG knows that "n+k" =
"2+1" for a Loadshare AS and "n" currently equals "1").
Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA
heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP-ASP1) would not occur.
5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association
An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the
ASP has received an ASP Inactive Ack message) may now proceed to the
ASP-DOWN state, if it is to be removed from service. Following on
from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive"
state:
SGP ASP1
| |
|<-----ASP Inactive (RCn)------| RC: Routing Context
|----ASP Inactive Ack (RCn)--->|
| |
|<-----DEREGISTER REQ(RCn)-----| See Notes
| |
|---DEREGISTER RESP(LRCn,RCn)->|
| |
: :
| |
|<-----------ASP Down----------|
|---------ASP Down Ack-------->|
| |
Note: The Deregistration procedure will typically be used if the ASP
previously used the Registration procedures for configuration within
the Application Server. ASP Inactive and Deregister messages
exchanges may contain multiple Routing Contexts.
The ASP should be in the ASP-INACTIVE state and should have
deregistered in all its Routing Contexts before attempting to move to
the ASP-DOWN state.
5.4 M3UA/MTP3-User Boundary Examples
5.4.1 At an ASP
This section describes the primitive mapping between the MTP3 User
and the M3UA layer at an ASP.
5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP
5.4.1.1.1 Support for MTP-TRANSFER Request Primitive
When the MTP3-User on the ASP has data to send to a remote MTP3-User,
it uses the MTP-TRANSFER request primitive. The M3UA layer at the
ASP will do the following when it receives an MTP-TRANSFER request
primitive from the M3UA user:
- Determine the correct SGP;
- Determine the correct association to the chosen SGP;
- Determine the correct stream in the association (e.g.,
based on SLS);
- Determine whether to complete the optional fields of the DATA
message;
- Map the MTP-TRANSFER request primitive into the Protocol Data
field of a DATA message;
- Send the DATA message to the remote M3UA peer at the SGP,
over the SCTP association.
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |
5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive
When the M3UA layer on the ASP receives a DATA message from the M3UA
peer at the remote SGP, it will do the following:
- Evaluate the optional fields of the DATA message, if present;
- Map the Protocol Data field of a DATA message into the
MTP-TRANSFER indication primitive;
- Pass the MTP-TRANSFER indication primitive to the user part. In
case of multiple user parts, the optional fields of the Data
message are used to determine the concerned user part.
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |
5.4.1.1.3 Support for ASP Querying of SS7 Destination States
There are situations such as temporary loss of connectivity to the
SGP that may cause the M3UA layer at the ASP to audit SS7 destination
availability/congestion states. Note: there is no primitive for the
MTP3-User to request this audit from the M3UA layer as this is
initiated by an internal M3UA management function.
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |
5.4.2 At an SGP
This section describes the primitive mapping between the MTP3-User
and the M3UA layer at an SGP.
5.4.2.1 Support for MTP-TRANSFER Request Primitive at the SGP
When the M3UA layer at the SGP has received DATA messages from its
peer destined to the SS7 network it will do the following:
- Evaluate the optional fields of the DATA message, if present, to
determine the Network Appearance;
- Map the Protocol data field of the DATA message into an
MTP-TRANSFER request primitive;
- Pass the MTP-TRANSFER request primitive to the MTP3 of the
concerned Network Appearance.
SGP ASP
| |
<---MTP-TRANSFER req.|<---------DATA -----------|
| |
5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP
When the MTP3 layer at the SGP has data to pass its user parts, it
will use the MTP-TRANSFER indication primitive. The M3UA layer at
the SGP will do the following when it receives an MTP-TRANSFER
indication primitive:
- Determine the correct AS using the distribution function;
- Select an ASP in the ASP-ACTIVE state
- Determine the correct association to the chosen ASP;
- Determine the correct stream in the SCTP association (e.g.,
based on SLS);
- Determine whether to complete the optional fields of the DATA
message;
- Map the MTP-TRANSFER indication primitive into the Protocol Data
field of a DATA message;
- Send the DATA message to the remote M3UA peer in the ASP, over
the SCTP association
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |
5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication
Primitives
The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from
the MTP3 upper layer interface at the SGP need to be made available
to the remote MTP3 User Part lower layer interface at the concerned
ASP(s).
5.4.2.3.1 Destination Unavailable
The MTP3 layer at the SGP will generate an MTP-PAUSE indication
primitive when it determines locally that an SS7 destination is
unreachable. The M3UA layer will map this primitive to a DUNA
message. The SGP M3UA layer determines the set of concerned ASPs to
be informed based on internal SS7 network information associated with
the MTP-PAUSE indication primitive indication.
SGP ASP
| |
--MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
| |
5.4.2.3.2 Destination Available
The MTP3 at the SGP will generate an MTP-RESUME indication primitive
when it determines locally that an SS7 destination that was
previously unreachable is now reachable. The M3UA layer will map
this primitive to a DAVA message. The SGP M3UA determines the set of
concerned ASPs to be informed based on internal SS7 network
information associated with the MTP-RESUME indication primitive.
SGP ASP
| |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
| |
5.4.2.3.3 SS7 Network Congestion
The MTP3 layer at the SGP will generate an MTP-STATUS indication
primitive when it determines locally that the route to an SS7
destination is congested. The M3UA layer will map this primitive to
a SCON message. It will determine which ASP(s) to send the SCON
message to, based on the intended Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
| |
5.4.2.3.4 Destination User Part Unavailable
The MTP3 layer at the SGP will generate an MTP-STATUS indication
primitive when it receives an UPU message from the SS7 network. The
M3UA layer will map this primitive to a DUPU message. It will
determine which ASP(s) to send the DUPU based on the intended
Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |
5.5 Examples for IPSP communication.
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already
set up. Both single exchange and double exchange behavior are
included for illustrative purposes.
5.5.1 Single exchange:
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
5.5.2 Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be
considered as enough since the response by the other peer can be
considered as a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed since once
that an IPSP receives ASP_Down ack message it is itself considered as
being in the ASP_Down state and not allowed to receive ASPSM
messages.
6. Security Considerations
6.1 Introduction
M3UA is designed to carry signalling messages for telephony services.
As such, M3UA must involve the security needs of several parties: the
end users of the services; the network providers and the applications
involved. Additional requirements may come from local regulation.
While having some overlapping security needs, any security solution
should fulfill all of the different parties' needs.
6.2 Threats
There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, M3UA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
M3UA is recommended to be transported on SCTP. SCTP [17] provides
certain transport related security features, such as some protection
against:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When M3UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [22] should be consulted for guidance.
When the network in which M3UA runs in involves more than one party,
it may not be reasonable to expect that all parties have implemented
security in a sufficient manner. In such a case, it is recommended
that IPSEC is used to ensure confidentiality of user payload.
Consult [23] for more information on configuring IPSEC services.
6.3 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
may include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP [24] SHOULD
be used instead. Regardless of which level performs the encryption,
the IPSEC ISAKMP [25] service SHOULD be used for key management.
7. IANA Considerations
7.1 SCTP Payload Protocol Identifier
IANA has assigned an M3UA value for the Payload Protocol Identifier
in the SCTP DATA chunk. The following SCTP Payload Protocol
Identifier is registered:
M3UA "3"
The SCTP Payload Protocol Identifier value "3" SHOULD be included in
each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA
protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. This Payload Protocol Identifier is not
directly used by SCTP but MAY be used by certain network entities to
identify the type of information being carried in a DATA chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being
presented to it by SCTP.
7.2 M3UA Port Number
IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It
is recommended that SGPs use this SCTP port number for listening for
new connections. SGPs MAY also use statically configured SCTP port
numbers instead.
7.3 M3UA Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus these
extensions are assigned by IANA through an IETF Consensus action as
defined in Guidelines for Writing an IANA Considerations Section in
RFCs (25]
The proposed extension must in no way adversely affect the general
working of the protocol.
7.3.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the new message class;
(b) A detailed description of the purpose of the message class.
7.3.2 IETF Defined Message Types
The documentation for a new message type MUST include the following
information:
(a) A long and short name for the new message type;
(b) A detailed description of the structure of the message;.
(c) A detailed definition and description of intended use for each
field within the message;
(d) A detailed procedural description of the use of the new
message type within the operation of the protocol;
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type which it does not
support, it MUST respond with an Error (ERR) message ("Unsupported
Message Type").
7.3.3 IETF Defined Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type;
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2;
(c) Detailed definition of each component of the parameter value;
(d) Detailed description of the intended use of this parameter
type, and an indication of whether and under what
circumstances multiple instances of this parameter type may be
found within the same message.
8. References
8.1 Normative References
[1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7