RFC 4666
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
3.5. ASP State Maintenance (ASPSM) Messages
3.5.1. ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all Routing Keys that the ASP is configured to serve.
The ASP Up message contains the following parameters:
ASP Identifier Optional
INFO String Optional
The format for ASP Up message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASP Identifier: 32-bit unsigned integer
The optional ASP Identifier parameter contains a unique value that
is locally significant among the ASPs that support an AS. The SGP
should save the ASP Identifier to be used, if necessary, with the
Notify message (see Section 3.8.2).
The format and description of the optional INFO String parameter
are the same as for the DUNA message (see Section 3.4.1).
3.5.2. ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP Up message
received from a remote M3UA peer.
The ASP Up Ack message contains the following parameters:
ASP Identifier Optional
INFO String Optional
The format for ASP Up Ack message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specifically useful for IPSP
communication. In that case, the IPSP answering the ASP Up message
MAY include its own ASP Identifier value.
The format and description of the optional INFO String parameter are
the same as for the DUNA message (see Section 3.4.1). The INFO
String in an ASP Up Ack message is independent from the INFO String
in the ASP Up message (i.e., it does not have to echo back the INFO
String received).
3.5.3. ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that
the adaptation layer is NOT ready to receive DATA, SSNM, RKM, or
ASPTM messages.
The ASP Down message contains the following parameter:
INFO String Optional
The format for the ASP Down message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are the same as for the DUNA message (see Section 3.4.1).3.5.4. ASP Down Acknowledgement (ASP Down Ack)
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer. The ASP Down Ack message contains the following parameter: INFO String Optional The format for the ASP Down Ack message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional INFO String parameter are the same as for the DUNA message (See Section 3.4.1). The INFO String in an ASP Down Ack message is independent from the INFO String in the ASP Down message (i.e., it does not have to echo back the INFO String received).3.5.5. Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP, which has its own heartbeat. The BEAT message contains the following parameter: Heartbeat Data Optional
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending
node. The Heartbeat Data could include, for example, a Heartbeat
Sequence Number and/or Timestamp. The receiver of a BEAT message
does not process this field, as it is only of significance to the
sender. The receiver MUST respond with a BEAT Ack message.
3.5.6. Heartbeat Acknowledgement (BEAT Ack)
The BEAT Ack message is sent in response to a received BEAT message.
It includes all the parameters of the received BEAT message, without
any change.
3.6. Routing Key Management (RKM) Messages [Optional]
3.6.1. Registration Request (REG REQ)
The REG REQ message is sent by an ASP to indicate to a remote M3UA
peer that it wishes to register one or more given Routing Keys with
the remote peer. Typically, an ASP would send this message to an SGP
and expect to receive a REG RSP message in return with an associated
Routing Context value.
The REG REQ message contains the following parameter:
Routing Key Mandatory
One or more Routing Key parameters MAY be included. The format for
the REG REQ message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Key: variable length
The Routing Key parameter is mandatory. The sender of this
message expects that the receiver of this message will create a
Routing Key entry and assign a unique Routing Context value to it,
if the Routing Key entry does not already exist.
The Routing Key parameter may be present multiple times in the
same message. This is used to allow the registration of multiple
Routing Keys in a single message.
The format of the Routing Key parameter is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Destination Point Code, Service Indicators, and
Originating Point Code List parameters MAY be repeated as a
grouping within the Routing Key parameter, in the structure shown
above.
Local-RK-Identifier: 32-bit unsigned integer
The mandatory Local-RK-Identifier field is used to uniquely
identify the registration request. The Identifier value is
assigned by the ASP and used to correlate the response in an REG
RSP message with the original registration request. The
Identifier value must remain unique until the REG RSP message is
received.
The format of the Local-RK-Identifier field is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer)
The optional Traffic Mode Type parameter identifies the traffic mode
of operation of the ASP(s) within an Application Server. The format
of the Traffic Mode Type Identifier is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Traffic Mode Type are shown in the following
table:
1 Override
2 Loadshare
3 Broadcast
Destination Point Code
The Destination Point Code parameter is mandatory, and it
identifies the Destination Point Code of incoming SS7 traffic
for which the ASP is registering. For an alias point code
configuration, the DPC parameter would be repeated for each
point code. The format is the same as described for the
Affected Destination parameter in the DUNA message (see Section
3.4.1). Its format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance
The optional Network Appearance parameter field identifies the SS7
network context for the Routing Key, and it has the same format as
in the DATA message (see Section 3.3.1) with the exception that it
does not have to be the first parameter in the message. If the
Network Appearance is not specified and the Routing Key applies to
all Network Appearances, then this Routing Key MUST be the only
one registered for the association; that is, Routing Context is
implied, and DATA and SSNM messages are discriminated on Network
Appearance rather than on Routing Context. Where Network
Appearance is not specified and there is only one Network
Appearance, then Network Appearance is implied. Its format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Indicators (SI): n X 8-bit integers
The optional SI [7,8] field contains one or more Service
Indicators from the values described in the MTP3-User Identity
field of the DUPU message. The absence of the SI parameter in the
Routing Key indicates the use of any SI value, excluding of course
MTP management. Where an SI parameter does not contain a multiple
of four SIs, the parameter is padded out to 32-byte alignment.
The SI format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPC List
The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as for the Destination
Point Code parameter. The absence of the OPC List parameter in
the Routing Key indicates the use of any OPC value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6.2. Registration Response (REG RSP)
The REG RSP message is used as a response to the REG REQ message from
a remote M3UA peer. It contains indications of success/failure for
registration requests and returns a unique Routing Context value for
successful registration requests, to be used in subsequent M3UA
Traffic Management protocol.
The REG RSP message contains the following parameter:
Registration Result Mandatory
One or more Registration Result parameters MUST be included. The
format for the REG RSP message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results
The Registration Result parameter contains the registration result
for a single Routing Key in an REG REQ message. The number of
results in a single REG RSP message MUST be anywhere from one to
the total number of number of Routing Key parameters found in the
corresponding REG REQ message. Where multiple REG RSP messages
are used in reply to REG REQ message, a specific result SHOULD be
in only one REG RSP message. The format of each result is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0212 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer
The Local-RK-Identifier contains the same value as found in the
matching Routing Key parameter found in the REG REQ message (See
Section 3.6.1).
Registration Status: 32-bit integer
The Registration Result Status field indicates the success or the
reason for failure of a registration request.
Its values may be:
0 Successfully Registered
1 Error - Unknown
2 Error - Invalid DPC
3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key
5 Error - Permission Denied
6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling Mode
11 Error - Routing Key Change Refused
12 Error - Routing Key Already Registered
Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value for
the associated Routing Key if the registration was successful. It
is set to "0" if the registration was not successful.
3.6.3. Deregistration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA
peer that it wishes to deregister a given Routing Key. Typically, an
ASP would send this message to an SGP and expects to receive a DEREG
RSP message in return with the associated Routing Context value.
The DEREG REQ message contains the following parameters:
Routing Context Mandatory
The format for the DEREG REQ message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: n X 32-bit integers
The Routing Context parameter contains (a list of) integers
indexing the Application Server traffic that the sending ASP is
currently registered to receive from the SGP but now wishes to
deregister.
3.6.4. Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message
from a remote M3UA peer.
The DEREG RSP message contains the following parameter:
Deregistration Result Mandatory
One or more Deregistration Result parameters MUST be included. The
format for the DEREG RSP message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deregistration Results
The Deregistration Result parameter contains the deregistration
status for a single Routing Context in a DEREG REQ message. The
number of results in a single DEREG RSP message MAY be anywhere
from one to the total number of number of Routing Context values
found in the corresponding DEREG REQ message.
Where multiple DEREG RSP messages are used in reply to DEREG REQ
message, a specific result SHOULD be in only one DEREG RSP
message. The format of each result is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0213 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value of
the matching Routing Key to deregister, as found in the DEREG REQ
message.
Deregistration Status: 32-bit integer
The Deregistration Result Status field indicates the success or
the reason for failure of the deregistration.
Its values may be:
0 Successfully Deregistered
1 Error - Unknown
2 Error - Invalid Routing Context
3 Error - Permission Denied
4 Error - Not Registered
5 Error - ASP Currently Active for Routing Context
3.7. ASP Traffic Maintenance (ASPTM) Messages
3.7.1. ASP Active
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it is ready to process signalling traffic for a particular Application Server. The ASP Active message affects only the ASP state for the Routing Keys identified by the Routing Contexts, if present. The ASP Active message contains the following parameters: Traffic Mode Type Optional Routing Context Optional INFO String Optional The format for the ASP Active message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x000b | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Traffic Mode Type: 32-bit (unsigned integer) The Traffic Mode Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Traffic Mode Type are shown in the following table: 1 Override 2 Loadshare 3 Broadcast
Within a particular Routing Context, Override, Loadshare, and
Broadcast SHOULD NOT be mixed. The Override value indicates that
the ASP is operating in Override mode, in which the ASP takes over
all traffic in an Application Server (i.e., primary/backup
operation), overriding any currently active ASPs in the AS. In
Loadshare mode, the ASP will share in the traffic distribution
with any other currently active ASPs. In Broadcast mode, the ASP
will receive the same messages as any other currently active ASP.
Routing Context: n X 32-bit integers
The optional Routing Context parameter contains (a list of)
integers indexing the Application Server traffic that the sending
ASP is configured/registered to receive.
There is a one-to-one relationship between an index entry and an
SGP Routing Key or AS Name. Because an AS can only appear in one
Network Appearance, the Network Appearance parameter is not
required in the ASP Active message.
An Application Server Process may be configured to process traffic
for more than one logical Application Server. From the
perspective of an ASP, a Routing Context defines a range of
signalling traffic that the ASP is currently configured to receive
from the SGP. For example, an ASP could be configured to support
signalling for multiple MTP3-Users, identified by separate SS7
DPC/OPC/SI ranges.
The format and description of the optional INFO String parameter are
the same as for the DUNA message (see Section 3.4.1).
3.7.2. ASP Active Acknowledgement (ASP Active Ack)
The ASP Active Ack message is used to acknowledge an ASP Active
message received from a remote M3UA peer.
The ASP Active Ack message contains the following parameters:
Traffic Mode Type Optional
Routing Context Optional
INFO String Optional
The format for the ASP Active Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are
the same as for the DUNA message (see Section 3.4.1).
The INFO String in an ASP Active Ack message is independent from the
INFO String in the ASP Active message (i.e., it does not have to echo
back the INFO String received).
The format of the Traffic Mode Type and Routing Context parameters is
the same as for the ASP Active message. (See Section 3.7.1.)
3.7.3. ASP Inactive
The ASP Inactive message is sent by an ASP to indicate to a remote
M3UA peer that it is no longer an active ASP to be used from within a
list of ASPs. The ASP Inactive message affects only the ASP state in
the Routing Keys identified by the Routing Contexts, if present.
The ASP Inactive message contains the following parameters:
Routing Context Optional
INFO String Optional
The format for the ASP Inactive message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and INFO
String parameters are the same as for the ASP Active message (see
Section 3.5.5.)
3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack)
The ASP Inactive Ack message is used to acknowledge an ASP Inactive
message received from a remote M3UA peer.
The ASP Inactive Ack message contains the following parameters:
Routing Context Optional
INFO String Optional
The format for the ASP Inactive Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter are
the same as for the DUNA message (see Section 3.4.1).
The INFO String in an ASP Inactive Ack message is independent from
the INFO String in the ASP Inactive message (i.e., it does not have
to echo back the INFO String received).
The format of the Routing Context parameter is the same as for the
ASP Inactive message. (see Section 3.7.3.)
3.8. Management (MGMT) Messages
3.8.1. Error
The Error message is used to notify a peer of an error event
associated with an incoming message. For example, the message type
might be unexpected given the current state, or a parameter value
might be invalid. Error messages MUST NOT be generated in response
to other Error messages.
The Error message contains the following parameters:
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Conditional
* Only mandatory for specific Error Codes.
The format for the Error message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag - 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Diagnostic Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code: 32 bits (unsigned integer)
The Error Code parameter indicates the reason for the Error
Message. The Error parameter value can be one of the following
values:
0x01 Invalid Version
0x02 Not Used in M3UA
0x03 Unsupported Message Class
0x04 Unsupported Message Type
0x05 Unsupported Traffic Mode Type
0x06 Unexpected Message
0x07 Protocol Error
0x08 Not Used in M3UA
0x09 Invalid Stream Identifier
0x0a Not Used in M3UA
0x0b Not Used in M3UA
0x0c Not Used in M3UA
0x0d Refused - Management Blocking
0x0e ASP Identifier Required
0x0f Invalid ASP Identifier
0x10 Not Used in M3UA
0x11 Invalid Parameter Value
0x12 Parameter Field Error
0x13 Unexpected Parameter
0x14 Destination Status Unknown
0x15 Invalid Network Appearance
0x16 Missing Parameter
0x17 Not Used in M3UA
0x18 Not Used in M3UA
0x19 Invalid Routing Context
0x1a No Configured AS for ASP
The "Invalid Version" error is sent if a message with an unsupported
version is received. The receiving end responds with an Error
message, indicating the version the receiving node supports, and
notifies layer management.
The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. For this error,
the Diagnostic Information parameter MUST be included with the first
40 octets of the offending message.
The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. For this error,
the Diagnostic Information parameter MUST be included with the first
40 octets of the offending message.
The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP
sends an ASP Active message with an unsupported Traffic Mode Type or
a Traffic Mode Type that is inconsistent with the presently
configured mode for the Application Server. An example would be a
case in which the SGP did not support loadsharing.
The "Unexpected Message" error MAY be sent if a defined and
recognized message is received that is not expected in the current
state (in some cases, the ASP may optionally silently discard the
message and not send an Error message). For example, silent discard
is used by an ASP if it received a DATA message from an SGP while it
was in the ASP-INACTIVE state. If the Unexpected message contained
Routing Contexts, the Routing Contexts SHOULD be included in the Error message. The "Protocol Error" error is sent for any protocol anomaly (i.e., receipt of a parameter that is syntactically correct but unexpected in the current situation). The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream (e.g., a Management message was received on a stream other than "0"). The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout). If this error is in response to an ASP Active message, the Routing Context(s) in the ASP Active message SHOULD be included in the Error message. The "ASP Identifier Required" error is sent by an SGP in response to an ASP Up message that does not contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier. The "Invalid ASP Identifier" error is sent by an SGP in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. The "Invalid Parameter Value" error is sent if a message is received with an invalid parameter value (e.g., a DUPU message was received with a Mask value other than "0". The "Parameter Field Error" would be sent if a message is received with a parameter having a wrong length field. The "Unexpected Parameter" error would be sent if a message contains an invalid parameter. The "Destination Status Unknown" error MAY be sent if a DAUD is received at an SG enquiring of the availability/congestion status of a destination and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included along with the Network Appearance and/or Routing Context associated with the Point Code(s). The "Invalid Network Appearance" error is sent by an SGP if an ASP sends a message with an invalid (unconfigured) Network Appearance value. For this error, the invalid (unconfigured) Network Appearance MUST be included in the Network Appearance parameter.
The "Missing Parameter" error would be sent if a mandatory parameter
were not included in a message. This error is also sent if a
conditional parameter is not included in the message but is required
in the context of the received message.
The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value.
For this error, the invalid Routing Context(s) MUST be included in
the Error message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known
by configuration data which Application Servers are referenced.
Diagnostic Information: variable length
When included, the optional Diagnostic Information can be any
information germane to the error condition, to assist in
identification of the error condition. The Diagnostic Information
SHOULD contain the offending message. A Diagnostic Information
parameter with a zero length parameter is not considered an error
(this means that the Length field in the TLV will be set to 4).
3.8.2. Notify
The Notify message used to provide an autonomous indication of M3UA
events to an M3UA peer.
The Notify message contains the following parameters:
Status Mandatory
ASP Identifier Conditional
Routing Context Optional
INFO String Optional
The format for the Notify message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Type: 16 bits (unsigned integer)
The Status Type parameter identifies the type of the Notify
message. The following are the valid Status Type values:
1 Application Server State Change (AS-State_Change)
2 Other
Status Information: 16 bits (unsigned integer)
The Status Information parameter contains more detailed
information for the notification, based on the value of the Status
Type. If the Status Type is AS-State_Change the following Status
Information values are used:
1 Reserved
2 Application Server Inactive (AS-INACTIVE)
3 Application Server Active (AS-ACTIVE)
4 Application Server Pending (AS-PENDING)
These notifications are sent from an SGP to an ASP upon a change
in status of a particular Application Server. The value reflects
the new state of the Application Server.
If the Status Type is Other, then the following Status Information
values are defined:
1 Insufficient ASP Resources Active in AS
2 Alternate ASP Active
3 ASP Failure
These notifications are not based on the SGP reporting the state
change of an ASP or AS. In the Insufficient ASP Resources case,
the SGP is indicating to an ASP_INACTIVE ASP in the AS that
another ASP is required to handle the load of the AS (Loadsharing
or Broadcast mode). For the Alternate ASP Active case, an ASP is
informed when an alternate ASP transitions to the ASP-ACTIVE state
in Override mode. The ASP Identifier (if available) of the
Alternate ASP MUST be placed in the message. For the ASP Failure
case, the SGP is indicating to ASPs in the AS that one of the
ASPs has failed. The ASP Identifier (if available) of the failed
ASP MUST be placed in the message.
The format and description of the conditional ASP Identifier is the
same as for the ASP Up message (see Section 3.5.1). The format and
description of the Routing Context and Info String parameters are the
same as for the ASP Active message (See Section 3.7.1)
(next page on part 4)
