draft-ietf-sigtran-m2ua-10.txt   draft-ietf-sigtran-m2ua-11.txt 
Network Working Group Ken Morneault Network Working Group Ken Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Ram Dantu Ram Dantu
NetRake NetRake
Greg Sidebottom Greg Sidebottom
Nortel Networks gregside consulting
Tom George Tom George
Alcatel Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Jacob Heitz Jacob Heitz
Lucent Lucent
Expires in March 2002 Sep 2001 Expires in May 2002 Nov 2001
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-10.txt> <draft-ietf-sigtran-m2ua-11.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups MAY also distribute and its working groups. Note that other groups MAY also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 11 skipping to change at page 2, line 11
interface using the SS7 Message Transfer Part (MTP) to provide interface using the SS7 Message Transfer Part (MTP) to provide
transport. The Signalling Gateway would act as a Signalling Link transport. The Signalling Gateway would act as a Signalling Link
Terminal. Terminal.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction..............................................3 1. Introduction..............................................3
1.1 Scope..................................................3 1.1 Scope..................................................3
1.2 Terminology............................................3 1.2 Terminology............................................3
1.3 Signalling Transport Architecture......................5 1.3 Signalling Transport Architecture......................5
1.4 Services Provide by the M2UA Adaptation Layer..........8 1.4 Services Provide by the M2UA Adaptation Layer..........7
1.5 Function Provided by the M2UA Layer...................10 1.5 Function Provided by the M2UA Layer....................9
1.6 Definition of the M2UA Boundaries.....................12 1.6 Definition of the M2UA Boundaries.....................11
2. Conventions..............................................15 2. Conventions..............................................13
3. Protocol Elements........................................15 3. Protocol Elements........................................13
3.1 Common Message Header.................................15 3.1 Common Message Header.................................13
3.2 M2UA Message Header...................................19 3.2 M2UA Message Header...................................17
3.3 M2UA Messages.........................................20 3.3 M2UA Messages.........................................18
4. Procedures...............................................51 4. Procedures...............................................48
4.1 Procedures to Support the M2UA-User Layer.............52 4.1 Procedures to Support the M2UA-User Layer.............49
4.2 Receipt of Primitives from the Layer Management.......52 4.2 Receipt of Primitives from the Layer Management.......49
4.3 AS and ASP State Maintenance..........................54 4.3 AS and ASP State Maintenance..........................51
4.4 Link Key Management Procedures........................65 4.4 Link Key Management Procedures........................62
5. Examples of MTP2 User Adaptation (M2UA) Procedures.......66 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......63
5.1 Establishment of associations between SG and MGC......66 5.1 Establishment of associations between SG and MGC......63
examples examples
5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........69 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........66
5.3 Layer Management Communication Examples...............69 5.3 Layer Management Communication Examples...............66
6. Timers...................................................74 6. Timers...................................................71
7. Security.................................................74 7. Security Considerations..................................71
7.1 Threats................................................74 7.1 Threats................................................71
7.2 Protecting Confidentiality.............................75 7.2 Protecting Confidentiality.............................72
8. IANA Considerations......................................75 8. IANA Considerations......................................72
8.1 SCTP Payload Protocol Identifier.......................75 8.1 SCTP Payload Protocol Identifier.......................72
8.2 IUA Protocol Extensions................................75 8.2 IUA Protocol Extensions................................72
9. Acknowledgements.........................................77 9. Acknowledgements.........................................74
10. References...............................................77 10. References...............................................74
11. Author's Addresses.......................................78 11. Author's Addresses.......................................75
1. Introduction 1. Introduction
This draft defines a protocol for the backhauling of SS7 [1] MTP2 User
[2] [3] (i.e. MTP3) signalling messages over IP using the Stream Control
Transmission Protocol (SCTP) [5]. This protocol would be used between
a Signalling Gateway (SG) and Media Gateway Controller (MGC).
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network SCN signalling protocol There is a need for Switched Circuit Network (SCN) signalling protocol
delivery from an Signalling Gateway (SG) to a Media Gateway delivery from an Signalling Gateway (SG) to a Media Gateway
Controller (MGC). The delivery mechanism addresses the following Controller (MGC) [6]. The delivery mechanism addresses the following
objectives: objectives:
* Support for MTP Level 2 / MTP Level 3 interface boundary * Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG * Support for communication between Layer Management modules on SG
and MGC and MGC
* Support for management of SCTP active associations between the SG and * Support for management of SCTP active associations between the SG and
MGC MGC
The SG will terminate up to MTP Level 2 and the MGC will terminate The SG will terminate up to MTP Level 2 and the MGC will terminate
MTP Level 3 and above. In other words, the SG will transport MTP MTP Level 3 and above. In other words, the SG will transport MTP
skipping to change at page 6, line 26 skipping to change at page 7, line 5
at either or both ends of an association, at either or both ends of an association,
- resistance to flooding and masquerade attacks, and - resistance to flooding and masquerade attacks, and
- data segmentation to conform to discovered path MTU size - data segmentation to conform to discovered path MTU size
There are scenarios without redundancy requirements and There are scenarios without redundancy requirements and
scenarios in which redundancy is supported below the transport scenarios in which redundancy is supported below the transport
layer. In these cases, the SCTP functions above MAY NOT be a layer. In these cases, the SCTP functions above MAY NOT be a
requirement and TCP can be used as the underlying common requirement and TCP can be used as the underlying common
transport protocol. transport protocol.
1.3.2 Support for the management of SCTP associations between the 1.3.2 ASP Fail-over Model and Terminology
SGPs and ASPs
The M2UA layer at the SG maintains the availability state of all
configured ASPs, in order to manage the SCTP associations and the
traffic between the SG and ASPs. As well, the active/inactive state
of remote ASP(s) are also maintained. The Active ASP(s) are the
one(s) currently receiving traffic from the SG.
The M2UA layer MAY be instructed by local management to establish an
SCTP association to a peer M2UA node. This can be achieved using the
M-SCTP_ESTABLISH primitive to request, indicate and confirm the
establishment of an SCTP association with a peer M2UA node.
The M2UA layer MAY also need to inform local management of the status of
the underlying SCTP associations using the M-SCTP_STATUS request and
indication primitive. For example, the M2UA MAY inform local management
of the reason for the release of an SCTP association, determined either
locally within the M2UA layer or by a primitive from the SCTP.
Also the M2UA layer may need to inform the local management of the
change in status of an ASP or AS. This may be achieved using the M-ASP
STATUS request or M-AS_STATUS request primitives.
1.3.3 Signalling Network Architecture
A Signalling Gateway will support the transport of MTP2-User signalling
traffic received from the SS7 network to one or more distributed ASPs
(e.g., MGCs). Clearly, the M2UA protocol description cannot in itself
meet any performance and reliability requirements for such transport.
A physical network architecture is required, with data on the
availability and transfer performance of the physical nodes involved in
any particular exchange of information. However, the M2UA protocol MUST
be flexible enough allow its operation and management in a variety of
physical configurations that will enable Network Operators to meet
their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, these Network Operators SHOULD
ensure that there is no single point of failure provisioned in the end-
to-end network architecture between an SS7 node and an IP ASP.
Depending of course on the reliability of the SGP and ASP functional
elements, this can typically be met by the spreading links in a linkset
across SGPs or SGs, the provision of redundant QoS-bounded IP network
paths for SCTP Associations between SCTP End Points, and redundant
Hosts. The distribution of ASPs within the available Hosts is also
important. For a particular Application Server, the related ASPs MAY
be distributed over at least two Hosts.
An example logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 2 below:
************** **************
* ********__*______________________________*__******** * Host1
SG1 * * SGP1 *__*________________ _______*__* ASP1 * *
* ******** * | | * ******** *
* . * | | * *
* . * | | **************
************** | |
| |
************** | |
* ********__*______________________|
SG2 * * SGP2 *__*________ |
* ******** * | |
* . * | |
* . * | |
************** | | **************
| |_____________*__******** * Host2
|_____________________*__* ASP2 * *
. * ******** *
. SCTP Associations * *
. **************
.
.
.
Figure 2 - Logical Model Example
For carrier grade networks, Operators SHOULD ensure that under failure
or isolation of a particular ASP, stable calls or transactions are not
lost. This implies that ASPs need, in some cases, to share the call/-
transaction state or be able to pass the call/transaction state between
each other. Also, in the case of ASPs performing call processing,
coordination MAY be required with the related Media Gateway to transfer
the MGC control for a particular trunk termination. However, this
sharing or communication is outside the scope of this document.
1.3.4 ASP Fail-over Model and Terminology
The M2UA layer supports ASP fail-over functions in order to support a The M2UA layer supports ASP fail-over functions in order to support a
high availability of call and transaction processing capability. All high availability of call and transaction processing capability. All
MTP2-User messages incoming to a SGP from the SS7 network are assigned MTP2-User messages incoming to a SGP from the SS7 network are assigned
to the unique Application Server, based on the Interface Identifier of to the unique Application Server, based on the Interface Identifier of
the message. the message.
The M2UA layer supports a n+k redundancy model (active-standby, The M2UA layer supports a n+k redundancy model (active-standby,
loadsharing, broadcast) where n is the minimum number of redundant loadsharing, broadcast) where n is the minimum number of redundant
ASPs required to handle traffic and k ASPs are available to take over ASPs required to handle traffic and k ASPs are available to take over
for a failed or unavailable ASP. Note that 1+1 active/standby for a failed or unavailable ASP. Note that 1+1 active/standby
redundancy is a subset of this model. A simplex 1+0 model is also redundancy is a subset of this model. A simplex 1+0 model is also
supported as a subset, with no ASP redundancy. supported as a subset, with no ASP redundancy.
To avoid a single point of failure, it is recommended that a minimum 1.3.3 Client/Server Model
oftwo ASPs be configured in an AS list, resident in separate hosts
and, therefore, available over different SCTP associations. For
example, in the network shown in Figure 2, all messages for the
Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in
Host2. The AS list at SGP1 might look like the following:
Interface Identifiers - Application Server #1
ASP1/Host1 - State = Active
ASP2/Host2 - State = Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP2 in Host2 would
normally be brought to the active state upon failure of ASP1/Host1.
In this example, both ASPs are Inactive or Active, meaning that the
related SCTP association and far-end M2UA peer is ready.
The two ASPs MAY share state information via shared memory, or MAY
use an ASP to ASP protocol to pass state information. The ASP to ASP
protocol is outside the scope of this document.
1.3.5 Client/Server Model
It is recommended that the SGP and ASP be able to support both client It is recommended that the SGP and ASP be able to support both client
and server operation. The peer endpoints using M2UA SHOULD be and server operation. The peer endpoints using M2UA SHOULD be
configured so that one always takes on the role of client and the configured so that one always takes on the role of client and the
other the role of server for initiating SCTP associations. The other the role of server for initiating SCTP associations. The
default orientation would be for the SGP to take on the role of server default orientation would be for the SGP to take on the role of server
while the ASP is the client. In this case, ASPs SHOULD initiate the while the ASP is the client. In this case, ASPs SHOULD initiate the
SCTP association to the SGP. SCTP association to the SGP.
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA The SCTP and TCP Registered User Port Number Assignment for M2UA
is 2904. is 2904.
1.4 Services Provided by the M2UA Adaptation Layer 1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
MTP Level 2 to MTP Level 3. MTP Level 2 to MTP Level 3.
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
skipping to change at page 9, line 29 skipping to change at page 8, line 16
Level 3 scenario, the following primitive is defined: Level 3 scenario, the following primitive is defined:
M-ERROR M-ERROR
The M-ERROR message is used to indicate an error with a received The M-ERROR message is used to indicate an error with a received
M2UA message (e.g., an interface identifier value is not known to the M2UA message (e.g., an interface identifier value is not known to the
SG). SG).
1.4.3 Support for management of active associations between SG and MGC 1.4.3 Support for management of active associations between SG and MGC
As discussed in Section 1.3.2, the M2UA layer on the SG keeps the state The M2UA layer on the SG keeps the state of the configured ASPs. A set
of the configured ASPs. A set of primitives between M2UA layer and the of primitives between M2UA layer and the Layer Management are defined
Layer Management are defined below to help the Layer Management manage below to help the Layer Management manage the association(s) between
the association(s) between the SG and the MGC. The M2UA layer can be the SG and the MGC. The M2UA layer can be instructed by the Layer
instructed by the Layer Management to establish a SCTP association to Management to establish a SCTP association to a peer M2UA node. This
a peer M2UA node. This procedure can be achieved using the M-SCTP procedure can be achieved using the M-SCTP ESTABLISH primitive.
ESTABLISH primitive.
M-SCTP_ESTABLISH M-SCTP_ESTABLISH
The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm
the establishment of a SCTP association to a peer M2UA node. the establishment of a SCTP association to a peer M2UA node.
M-SCTP_RELEASE M-SCTP_RELEASE
The M-SCTP_RELEASE primitives are used to request, indicate, and The M-SCTP_RELEASE primitives are used to request, indicate, and
confirm the release of a SCTP association to a peer M2UA node. confirm the release of a SCTP association to a peer M2UA node.
skipping to change at page 11, line 21 skipping to change at page 10, line 21
/ +->| AS |--+ Streams / +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+ / +----+ | +----+ stb+-----+
SS7 link2-------->|IID |-+ | ASP | SS7 link2-------->|IID |-+ | ASP |
+----+ +-----+ +----+ +-----+
where IID = Interface Identifier where IID = Interface Identifier
A SGP MAY support more than one AS. An AS MAY support more than A SGP MAY support more than one AS. An AS MAY support more than
one Interface Identifier. one Interface Identifier.
1.5.2 Status of ASPs 1.5.2 Support for the management of SCTP associations between the
SGPs and ASPs
The M2UA layer at the SG maintains the availability state of all
configured ASPs, in order to manage the SCTP associations and the
traffic between the SG and ASPs. As well, the active/inactive state
of remote ASP(s) are also maintained. The Active ASP(s) are the
one(s) currently receiving traffic from the SG.
The M2UA layer MAY be instructed by local management to establish an
SCTP association to a peer M2UA node. This can be achieved using the
M-SCTP_ESTABLISH primitive to request, indicate and confirm the
establishment of an SCTP association with a peer M2UA node.
The M2UA layer MAY also need to inform local management of the status of
the underlying SCTP associations using the M-SCTP_STATUS request and
indication primitive. For example, the M2UA MAY inform local management
of the reason for the release of an SCTP association, determined either
locally within the M2UA layer or by a primitive from the SCTP.
Also the M2UA layer may need to inform the local management of the
change in status of an ASP or AS. This may be achieved using the M-ASP
STATUS request or M-AS_STATUS request primitives.
1.5.3 Status of ASPs
The M2UA layer on the SG MUST maintain the state of the ASPs it is The M2UA layer on the SG MUST maintain the state of the ASPs it is
supporting. The state of an ASP changes because of reception of supporting. The state of an ASP changes because of reception of
peer-to-peer messages (ASPM messages as described in Section 3.3.2) peer-to-peer messages (ASPM messages as described in Section 3.3.2)
or reception of indications from the local SCTP association. ASP or reception of indications from the local SCTP association. ASP
state transition procedures are described in Section 4.3.1. state transition procedures are described in Section 4.3.1.
At a SGP, an Application Server list MAY contain active and inactive At a SGP, an Application Server list MAY contain active and inactive
ASPs to support ASP fail-over procedures. When, for example, both ASPs to support ASP fail-over procedures. When, for example, both
a primary and a backup ASP are available, M2UA peer protocol is a primary and a backup ASP are available, M2UA peer protocol is
required to control which ASP is currently active. The ordered required to control which ASP is currently active. The ordered
list of ASPs within a logical Application Server is kept updated in list of ASPs within a logical Application Server is kept updated in
the SGP to reflect the active Application Server Process. the SGP to reflect the active Application Server Process.
Also the M2UA layer MAY need to inform the local management of the Also the M2UA layer MAY need to inform the local management of the
change in status of an ASP or AS. This can be achieved using the M-ASP change in status of an ASP or AS. This can be achieved using the M-ASP
STATUS or M-AS_STATUS primitives. STATUS or M-AS_STATUS primitives.
1.5.3 SCTP Specifics 1.5.4 SCTP Specifics
1.5.3.1 SCTP Stream Management 1.5.4.1 SCTP Stream Management
SCTP allows a user specified number of streams to be opened during SCTP allows a user specified number of streams to be opened during
initialization of the association. It is the responsibility of the initialization of the association. It is the responsibility of the
M2UA layer to ensure proper management of these streams. Because of M2UA layer to ensure proper management of these streams. Because of
the unidirectional nature of streams, a M2UA layer is not aware of the the unidirectional nature of streams, a M2UA layer is not aware of the
stream information from its peer M2UA layer. Instead, the Interface stream information from its peer M2UA layer. Instead, the Interface
Identifier is in the M2UA message header. Identifier is in the M2UA message header.
The use of SCTP streams within M2UA is recommended in order to minimize The use of SCTP streams within M2UA is recommended in order to minimize
transmission and buffering delay, therefore improving the overall transmission and buffering delay, therefore improving the overall
performance and reliability of the signalling elements. A separate performance and reliability of the signalling elements. A separate
SCTP stream can be used for each SS7 link. Or, an implementation may SCTP stream can be used for each SS7 link. Or, an implementation may
choose to split the SS7 link across several streams based on SLS. choose to split the SS7 link across several streams based on SLS.
This method may be of particular interest for high speed links (MTP3b) This method may be of particular interest for high speed SS7 links
since high speed links have a 24-bit sequence number and the stream (MTP3b) since high speed links have a 24-bit sequence number and the
sequence number is 16-bits. stream sequence number is 16-bits.
SCTP Stream '0' SHOULD not be used for MTP2 User Adaptation (MAUP) SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
messages (see Section 3) since stream '0' SHOULD only be used for ASP messages (see Section 3) since stream '0' SHOULD only be used for ASP
Management (ASPM) messages (see Section 4.3.3). Management (ASPM) messages (see Section 4.3.3).
1.5.4 Seamless SS7 Network Management Interworking 1.5.5 Seamless SS7 Network Management Interworking
The M2UA layer on the SGP SHOULD pass an indication of unavailability The M2UA layer on the SGP SHOULD pass an indication of unavailability
of the M2UA-User (MTP3) to the local Layer Management, if the of the M2UA-User (MTP3) to the local Layer Management, if the
currently active ASP moves from the ACTIVE state. The actions taken by currently active ASP moves from the ACTIVE state. The actions taken by
M2UAon the SGP with regards to MTP Level 2 should be in accordance M2UAon the SGP with regards to MTP Level 2 should be in accordance
with the appropriate MTP specifications. with the appropriate MTP specifications.
1.5.5 Flow Control / Congestion 1.5.6 Flow Control / Congestion
It is possible for the M2UA layer to be informed of IP network It is possible for the M2UA layer to be informed of IP network
congestion onset and abatement by means of an implementation dependent congestion onset and abatement by means of an implementation dependent
function (i.e. an indication from the SCTP). The handling of function (i.e. an indication from the SCTP). The handling of
this congestion indication by M2UA is implementation dependent. this congestion indication by M2UA is implementation dependent.
However, the actions taken by the SG should be accordance with the However, the actions taken by the SG should be accordance with the
appropriate MTP specification and should enable SS7 functionality appropriate MTP specification and should enable SS7 functionality
(e.g. flow control) to be correctly maintained. (e.g. flow control) to be correctly maintained.
1.5.6 Audit of Link State 1.5.7 Audit of SS7 Link State
After a failover of one ASP to another ASP, it may be necessary for the After a failover of one ASP to another ASP, it may be necessary for the
M2UA on the ASP to audit the current SS7 link state to ensure consistency. M2UA on the ASP to audit the current SS7 link state to ensure consistency.
The M2UA on the SGP would respond to the audit request with information The M2UA on the SGP would respond to the audit request with information
regarding the current state of the link (i.e. in-service, out-of-service, regarding the current state of the SS7 link (i.e. in-service,
congestion state, LPO/RPO state). out-of-service, congestion state, LPO/RPO state).
1.6 Definition of the M2UA Boundaries 1.6 Definition of the M2UA Boundaries
1.6.1 Definition of the M2UA / MTP Level 3 boundary 1.6.1 Definition of the M2UA / MTP Level 3 boundary
DATA DATA
ESTABLISH ESTABLISH
RELEASE RELEASE
STATE STATE
DATA RETRIEVAL DATA RETRIEVAL
skipping to change at page 13, line 38 skipping to change at page 12, line 38
Purpose: ASP confirms to LM that it has released SCTP association Purpose: ASP confirms to LM that it has released SCTP association
with SGP. with SGP.
M-SCTP_RELEASE indication M-SCTP_RELEASE indication
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: SGP informs LM that ASP has released an SCTP association. Purpose: SGP informs LM that ASP has released an SCTP association.
M-SCTP_RESTART indication M-SCTP_RESTART indication
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: M2UA informs LM that a SCTP Restart indication has Purpose: M2UA informs LM that a SCTP Restart indication has
been received been received.
M-SCTP_STATUS request M-SCTP_STATUS request
Direction: LM -> M2UA Direction: LM -> M2UA
Purpose: LM requests M2UA to report status of SCTP association. Purpose: LM requests M2UA to report status of SCTP association.
M-SCTP_STATUS indication M-SCTP_STATUS indication
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: M2UA reports status of SCTP association. Purpose: M2UA reports status of SCTP association.
M-ASP_STATUS request M-ASP_STATUS request
skipping to change at page 14, line 54 skipping to change at page 12, line 109
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement
message from the SGP. message from the SGP.
M-ASP_INACTIVE request M-ASP_INACTIVE request
Direction: LM -> M2UA Direction: LM -> M2UA
Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP. Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.
M-ASP_INACTIVE confirm M-ASP_INACTIVE confirm
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement Purpose: ASP reports that is has received an ASP INACTIVE
message from the SGP. Acknowledgement message from the SGP.
M-LINK_KEY_REG Request M-LINK_KEY_REG Request
Direction LM -> M2UA Direction: LM -> M2UA
Purpose LM requests ASP to register Link Key with SG by sending REG REQ Purpose: LM requests ASP to register Link Key with SG by sending REG
message. REQ message.
M-LINK_KEY_REG Confirm M-LINK_KEY_REG Confirm
Direction M2UA -> LM Direction: M2UA -> LM
Purpose ASP reports to LM that it has successfully received a REG RSP Purpose: ASP reports to LM that it has successfully received a REG
message from SG. RSP message from SG.
M-LINK_KEY_REG Indication M-LINK_KEY_REG Indication
Direction M2UA -> LM Direction: M2UA -> LM
Purpose SG reports to LM that it has successfully processed an incoming Purpose: SG reports to LM that it has successfully processed an
REG REQ message from ASP. incoming REG REQ message from ASP.
M-LINK_KEY_DEREG Request M-LINK_KEY_DEREG Request
Direction LM -> M2UA Direction: LM -> M2UA
Purpose LM requests ASP to de-register Link Key with SG by sending DEREG Purpose: LM requests ASP to de-register Link Key with SG by sending
REQ message. DEREG REQ message.
M-LINK_KEY_DEREG Confirm M-LINK_KEY_DEREG Confirm
Direction M2UA -> LM Direction: M2UA -> LM
Purpose ASP reports to LM that it has successfully received a DEREG RSP Purpose: ASP reports to LM that it has successfully received a
message from SG. DEREG RSP message from SG.
M-LINK_KEY_DEREG Indication M-LINK_KEY_DEREG Indication
Direction M2UA -> LM Direction: M2UA -> LM
Purpose SG reports to LM that it has successfully processed an incoming Purpose: SG reports to LM that it has successfully processed an
DEREG REQ message from ASP. incoming DEREG REQ message from ASP.
2.0 Conventions 2.0 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [RFC2119]. in this document, are to be interpreted as described in [RFC2119].
3.0 Protocol Elements 3.0 Protocol Elements
This section describes the format of various messages used in this This section describes the format of various messages used in this
skipping to change at page 15, line 56 skipping to change at page 13, line 56
signalling protocol adaptation layers: signalling protocol adaptation layers:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Spare | Message Class | Message Type | | Version | Spare | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Common Message Header Figure 2 Common Message Header
All fields in an M2UA message MUST be transmitted in the network byte All fields in an M2UA message MUST be transmitted in the network byte
order, unless otherwise stated. order, unless otherwise stated.
3.1.1 Version 3.1.1 Version
The version field (vers) contains the version of the M2UA adaptation The version field (vers) contains the version of the M2UA adaptation
layer. The supported versions are: layer. The supported versions are:
Value Version Value Version
skipping to change at page 17, line 46 skipping to change at page 15, line 46
1 Registration Request (REG REQ) 1 Registration Request (REG REQ)
2 Registration Response (REG RSP) 2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ) 3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP) 4 Deregistration Response (DEREG RSP)
5 to 127 Reserved by the IETF 5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined IIM extensions 128 to 255 Reserved for IETF-Defined IIM extensions
3.1.5 Message Length 3.1.5 Message Length
The Message Length defines the length of the message in octets, The Message Length defines the length of the message in octets,
including the header. The Message Length includes parameter including the header. The Message Length MUST include parameter
padding bytes, if any. padding bytes, if any. The Message Length MUST NOT be longer
than a MTP3 message [2] [3] plus the length of the common and
M2UA message headers.
3.1.6 Variable-Length Parameter Format 3.1.6 Variable-Length Parameter Format
M2UA messages consist of a Common Header followed by zero or more M2UA messages consist of a Common Header followed by zero or more
variable-length parameters, as defined by the message type. The variable-length parameters, as defined by the message type. The
variable-length parameters contained in a message are defined in a variable-length parameters contained in a message are defined in a
Tag-Length-Value format as shown below. Tag-Length-Value format as shown below.
0 1 2 3 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 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
skipping to change at page 18, line 25 skipping to change at page 16, line 25
Mandatory parameters MUST be placed before optional parameters in a Mandatory parameters MUST be placed before optional parameters in a
message. message.
Parameter Tag: 16 bits (unsigned integer) Parameter Tag: 16 bits (unsigned integer)
The Type field is a 16 bit identifier of the type of parameter. It The Type field is a 16 bit identifier of the type of parameter. It
takes a value of 0 to 65534. The common parameters used by adaptation takes a value of 0 to 65534. The common parameters used by adaptation
layers are in the range of 0x00 to 0xff. The M2UA specific parameters layers are in the range of 0x00 to 0xff. The M2UA specific parameters
have Tags in the range 0x300 to 0x3ff. have Tags in the range 0x300 to 0x3ff.
The common parameter Tags (used by all User Adaptation layers) defined The common parameter tags (used by all User Adaptation layers) that
are as follows: M2UA uses are defined below:
Parameter Value Parameter Name Parameter Value Parameter Name
--------------- -------------- --------------- --------------
0 (0x0) Reserved 0 (0x00) Reserved
1 (0x1) Interface Identifier (Integer) 1 (0x01) Interface Identifier (Integer)
2 (0x2) Unused 2 (0x02) Unused
3 (0x3) Interface Identifier (Text) 3 (0x03) Interface Identifier (Text)
4 (0x4) Info String 4 (0x04) Info String
5 (0x5) Unused 5 (0x05) Unused
6 (0x6) Unused 6 (0x06) Unused
7 (0x7) Diagnostic Information 7 (0x07) Diagnostic Information
8 (0x8) Interface Identifier (Integer Range) 8 (0x08) Interface Identifier (Integer Range)
9 (0x9) Heartbeat Data 9 (0x09) Heartbeat Data
10 (0xa) Reason 10 (0x0a) Unused
11 (0xb) Traffic Mode Type 11 (0x0b) Traffic Mode Type
12 (0xc) Error Code 12 (0x0c) Error Code
13 (0xd) Status Type/Information 13 (0x0d) Status Type/Information
14 (0xe) ASP Identifier 14 (0x0e) Unused
15-255 Reserved 15 (0x0f) Unused
16 (0x10) Unused
17 (0x11) ASP Identifier
18-255 Reserved
The M2UA specific parameter Tags defined are as follows: The M2UA specific parameter Tags defined are as follows:
Parameter Value Parameter Name Parameter Value Parameter Name
--------------- -------------- --------------- --------------
768 (0x0300) Protocol Data 1 768 (0x0300) Protocol Data 1
769 (0x0301) Protocol Data 2 (TTC) 769 (0x0301) Protocol Data 2 (TTC)
770 (0x0302) State Request 770 (0x0302) State Request
771 (0x0303) State Event 771 (0x0303) State Event
772 (0x0304) Congestion Status 772 (0x0304) Congestion Status
skipping to change at page 19, line 9 skipping to change at page 17, line 9
782 (0x030e) Registration Status 782 (0x030e) Registration Status
783 (0x030f) De-Registration Result 783 (0x030f) De-Registration Result
784 (0x0310) De-Registration Status 784 (0x0310) De-Registration Status
785 (0x0311) Correlation Id 785 (0x0311) Correlation Id
786 (0x0312) Correlation Id Ack 786 (0x0312) Correlation Id Ack
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. The Parameter Length does not include any padding bytes. Value fields. Thus, a parameter with a zero-length Parameter Value
field would have a Length field of 4. The Parameter Length does not
include any padding bytes.
Parameter Value: variable-length. Parameter Value: variable-length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
transferred in the parameter. transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length and The total length of a parameter (including Tag, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero at the end (i.e., after the Parameter Value field) with all zero
skipping to change at page 19, line 50 skipping to change at page 17, line 52
text formatted Interface Identifier MAY optionally be supported. text formatted Interface Identifier MAY optionally be supported.
0 1 2 3 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 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 (0x1) | Length=8 | | Tag (0x1) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) | | Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 M2UA Message Header (Integer-based Interface Identifier) Figure 3 M2UA Message Header (Integer-based Interface Identifier)
The Tag value for Integer-based Interface Identifier is 0x1. The The Tag value for Integer-based Interface Identifier is 0x1. The
length is always set to a value of 8. length is always set to a value of 8.
0 1 2 3 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 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 (0x3) | Length | | Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (text) | | Interface Identifier (text) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 M2UA Message Header (Text-based Interface Identifier) Figure 4 M2UA Message Header (Text-based Interface Identifier)
The Tag value for the Text-based Interface Identifier is 0x3. The The Tag value for the Text-based Interface Identifier is 0x3. The
length is variable. length is equal to the string length of the Interface Identifier
name plus four bytes for the Tag and Length fields.
3.3 M2UA Messages 3.3 M2UA Messages
The following section defines the messages and parameter contents. The following section defines the messages and parameter contents.
The M2UA messages will use the common message header (Figure 3) and The M2UA messages will use the common message header (Figure 2) and
the M2UA message header (Figure 4). the M2UA message header (Figure 3).
3.3.1 MTP2 User Adaptation Messages 3.3.1 MTP2 User Adaptation Messages
3.3.1.1 Data 3.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU).
The Data message contains the following parameter: The Data message contains the following parameter:
Protocol Data (mandatory) Protocol Data (mandatory)
Correlation Id (optional) Correlation Id (optional)
skipping to change at page 21, line 16 skipping to change at page 19, line 16
0 1 2 3 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 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 (0x301) | Length | | Tag (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ / \
\ Protocol Data / \ Protocol Data /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x312) | Length = 8 | | Tag (0x311) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id | | Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in The Protocol Data field contains the MTP2-User application message in
network byte order starting with the Length Indicator (LI) octet. network byte order starting with the Length Indicator (LI) octet.
The Japanese TTC variant uses the spare bits of the LI octet for The Japanese TTC variant uses the spare bits of the LI octet for
priority. priority. The length of the Protocol Data MUST NOT exceed the length
of a MTP2-User application message [2] [3].
3.3.1.2 Data Acknowledge Message 3.3.1.2 Data Acknowledge Message
The Data Acknowledge message contains the Correlation Id of the Data The Data Acknowledge message contains the Correlation Id of the Data
message which the sending M2UA is acknowledging as successfully message which the sending M2UA is acknowledging as successfully
processed to the peer M2UA. processed to the peer M2UA.
The Data Acknowledge message contains the following parameter: The Data Acknowledge message contains the following parameter:
Correlation Id Mandatory Correlation Id Mandatory
skipping to change at page 22, line 11 skipping to change at page 20, line 11
The Data Ack message MUST be sent if a Correlation Id parameter is The Data Ack message MUST be sent if a Correlation Id parameter is
received from the peer. Otherwise the Data Ack message SHOULD NOT be received from the peer. Otherwise the Data Ack message SHOULD NOT be
sent. sent.
If the Data Acknowledge is not sent for Correlation Id(s) or is sent If the Data Acknowledge is not sent for Correlation Id(s) or is sent
with Invalid Correlation Id(s), the SS7 link will eventually fail with Invalid Correlation Id(s), the SS7 link will eventually fail
dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs. dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs.
3.3.1.3 Establish (Request, Confirmation) 3.3.1.3 Establish (Request, Confirmation)
The Establish Request message is used to establish the link or to The Establish Request message is used to establish the SS7 link or to
indicate that the channel has been established. The MGC controls the indicate that the channel has been established. The MGC controls the
state of the SS7 link. When the MGC desires the SS7 link to be state of the SS7 link. When the MGC desires the SS7 link to be
in-service, it will send the Establish Request message. Note that in-service, it will send the Establish Request message. Note that
the SGP MAY already have the SS7 link established at its layer. the SGP MAY already have the SS7 link established at its layer.
If so, upon receipt of an Establish Request, the SGP takes no action If so, upon receipt of an Establish Request, the SGP takes no action
except to send an Establish Confirm. except to send an Establish Confirm.
When the MGC sends an M2UA Establish Request message, the MGC MAY When the MGC sends an M2UA Establish Request message, the MGC MAY
start a timer. This timer would be stopped upon receipt of an M2UA start a timer. This timer would be stopped upon receipt of an M2UA
Establish Confirm. If the timer expires, the MGC would resend the Establish Confirm. If the timer expires, the MGC would resend the
M2UA Establish Request message and restart the timer. In other words, M2UA Establish Request message and restart the timer. In other words,
the MGC MAY continue to request the establishment of the data link the MGC MAY continue to request the establishment of the data link
on periodic basis until the desired state is achieved or take some on periodic basis until the desired state is achieved or take some
other action (notify the Management Layer). other action (notify the Management Layer).
The mode (Normal or Emergency) for bringing the link in service is The mode (Normal or Emergency) for bringing the SS7 link in service is
defaulted to Normal. The State Request (described in Section 3.3.1.5 defaulted to Normal. The State Request (described in Section 3.3.1.5
below) can be used to change the mode to Emergency. below) can be used to change the mode to Emergency.
3.3.1.4 Release (Request, Indication, Confirmation) 3.3.1.4 Release (Request, Indication, Confirmation)
This Release Request message is used to release the channel. The This Release Request message is used to release the channel. The
Release Confirm and Indication messages are used to indicate that the Release Confirm and Indication messages are used to indicate that the
channel has been released. channel has been released.
3.3.1.5 State Request 3.3.1.5 State Request
skipping to change at page 22, line 52 skipping to change at page 20, line 52
successfully completed. The State Confirm reflects that state value successfully completed. The State Confirm reflects that state value
received in the State Request message. received in the State Request message.
The State Request message contains the following parameter: The State Request message contains the following parameter:
State (mandatory) State (mandatory)
0 1 2 3 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 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 (0x302) | Length | | Tag (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard STATUS_CONG_DISCARD 0xa Congestion discard
3.3.1.6 State Confirm 3.3.1.6 State Confirm
skipping to change at page 23, line 37 skipping to change at page 21, line 36
Request from the MGC. The State Confirm reflects that state value Request from the MGC. The State Confirm reflects that state value
received in the State Request message. received in the State Request message.
The State Confirm message contains the following parameter: The State Confirm message contains the following parameter:
State (mandatory) State (mandatory)
0 1 2 3 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 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 (0x302) | Length | | Tag (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The value The valid values for State are shown in the following table. The value
of the State field should reflect the value received in the State of the State field should reflect the value received in the State
Request message. Request message.
Define Value Description Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard STATUS_CONG_DISCARD 0xa Congestion discard
3.3.1.7 State Indication 3.3.1.7 State Indication
The MTP2 State Indication message can be sent from a SGP to an ASP to The MTP2 State Indication message can be sent from a SGP to an ASP to
indicate a condition on a link. indicate a condition on a SS7 link.
The State Indication message contains the following parameter: The State Indication message contains the following parameter:
Event (mandatory) Event (mandatory)
0 1 2 3 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 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 (0x303) | Length | | Tag (0x303) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | | Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table. The valid values for Event are shown in the following table.
Define Value Description Define Value Description
EVENT_RPO_ENTER 0x1 Remote entered processor outage EVENT_RPO_ENTER 0x1 Remote entered processor outage
EVENT_RPO_EXIT 0x2 Remote exited processor outage EVENT_RPO_EXIT 0x2 Remote exited processor outage
EVENT_LPO_ENTER 0x3 Link entered processor outage EVENT_LPO_ENTER 0x3 Link entered processor outage
EVENT_LPO_EXIT 0x4 Link exited processor outage EVENT_LPO_EXIT 0x4 Link exited processor outage
3.3.1.8 Congestion Indication 3.3.1.8 Congestion Indication
The Congestion Indication message can be sent from a Signalling Gateway The Congestion Indication message can be sent from a Signalling Gateway
Process to an ASP to indicate the congestion status and discard status Process to an ASP to indicate the congestion status and discard status
of a link. When the MSU buffer fill increases above an Onset threshold of a SS7 link. When the MSU buffer fill increases above an Onset
or decreases below an Abatement threshold or crosses a Discard threshold threshold or decreases below an Abatement threshold or crosses a Discard
in either direction, the SGP SHALL send a congestion indication message. threshold in either direction, the SGP SHALL send a congestion indication
message.
The SGP SHALL send the message only when there is actually a change The SGP SHALL send the message only when there is actually a change
in either the discard level or the congestion level to report, in either the discard level or the congestion level to report,
meaning it is different from the previously sent message. In addition, meaning it is different from the previously sent message. In addition,
the SGP SHALL use an implementation dependent algorithm to limit the the SGP SHALL use an implementation dependent algorithm to limit the
frequency of congestion indication messages. frequency of congestion indication messages.
An implementation may optionally send Congestion Indication messages on An implementation may optionally send Congestion Indication messages on
a "high priority" stream in order to potentially reduce delay (Refer to a "high priority" stream in order to potentially reduce delay (Refer to
[12] for more details). [12] for more details).
The Congestion Indication message contains the following parameters: The Congestion Indication message contains the following parameters:
Congestion Status (mandatory) Congestion Status (mandatory)
Discard Status (optional) Discard Status (optional)
0 1 2 3 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 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 (0x304) | Length | | Tag (0x304) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Status | | Congestion Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x305) | Length | | Tag (0x305) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Status | | Discard Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Congestion Status and Discard Status are shown in The valid values for Congestion Status and Discard Status are shown in
the following table. the following table.
Define Value Description Define Value Description
LEVEL_NONE 0x0 No congestion. LEVEL_NONE 0x0 No congestion
LEVEL_1 0x1 Congestion Level 1 LEVEL_1 0x1 Congestion Level 1
LEVEL_2 0x2 Congestion Level 2 LEVEL_2 0x2 Congestion Level 2
LEVEL_3 0x3 Congestion Level 3 LEVEL_3 0x3 Congestion Level 3
For networks that do not support multiple levels of congestion, only For SS7 networks that do not support multiple levels of congestion, only
theLEVEL_NONE and LEVEL_3 values will be used. For networks that the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that
supportmultiple levels of congestion, it is possible for all values to supportmultiple levels of congestion, it is possible for all values to
be used. Refer to [2], [3] and [9] for more details on the congestion be used. Refer to [2], [3] and [9] for more details on the Congestion
status of signalling links. and Discard Status of SS7 signalling links.
3.3.1.9 Retrieval Request 3.3.1.9 Retrieval Request
The MTP2 Retrieval Request message is used during the MTP Level 3 The MTP2 Retrieval Request message is used during the MTP Level 3
changeover procedure to request the BSN, to retrieve PDUs from the changeover procedure to request the BSN, to retrieve PDUs from the
transmit and retransmit queues or to flush PDUs from the retransmit transmit and retransmit queues or to flush PDUs from the retransmit
queue. queue. Examples of the use of Retrieval Request for SS7 Link
Changeover are provided in Section 5.3.6.
The Retrieval Request message contains the following parameters: The Retrieval Request message contains the following parameters:
Action (mandatory) Action (mandatory)
Sequence Number (optional) Sequence Number (optional)
0 1 2 3 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 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 (0x306) | Length | | Tag (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length | | Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are shown in the following table. The valid values for Action are shown in the following table.
Define Value Description Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit
and retransmit queues and retransmit queues
In the Retrieval Request message, the Sequence Number field SHOULD NOT In the Retrieval Request message, the Sequence Number field SHOULD NOT
be present if the Action field is ACTION_RTRV_BSN. The Sequence Number be present if the Action field is ACTION_RTRV_BSN. The Sequence Number
field contains the Forward Sequence Number (FSN) of the far end if the field contains the Forward Sequence Number (FSN) of the far end if the
Action is ACTION_RTRV_MSGS. Action is ACTION_RTRV_MSGS.
3.3.1.10 Retrieval Confirm 3.3.1.10 Retrieval Confirm
The MTP2 Retrieval Confirm message is sent by the Signalling Gateway The MTP2 Retrieval Confirm message is sent by the Signalling Gateway
in response to a Retrieval Request message. in response to a Retrieval Request message. Examples of the use of
Retrieval Confirm for SS7 Link Changeover are provided in Section
5.3.6.
The Retrieval Confirm message contains the following parameters: The Retrieval Confirm message contains the following parameters:
Action (mandatory) Action (mandatory)
Result (mandatory) Result (mandatory)
Sequence Number (optional) Sequence Number (optional)
0 1 2 3 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 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 (0x306) | Length | | Tag (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x308) | Length | | Tag (0x308) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | | Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length | | Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are the same as in Retrieval Request. The valid values for Action are the same as in Retrieval Request.
The values for Result are shown below: in the following table. The values for Result are shown below: in the following table.
Define Value Description Define Value Description
RESULT_SUCCESS 0x0 Action successful RESULT_SUCCESS 0x0 Action successful
skipping to change at page 27, line 16 skipping to change at page 25, line 16
the Result field will indicate success or failure. A failure means the Result field will indicate success or failure. A failure means
that the buffers could not be retrieved. The Sequence Number field is that the buffers could not be retrieved. The Sequence Number field is
not used with ACTION_RTRV_MSGS. not used with ACTION_RTRV_MSGS.
3.3.1.11 Retrieval Indication 3.3.1.11 Retrieval Indication
The Retrieval Indication message is sent by the Signalling Gateway with The Retrieval Indication message is sent by the Signalling Gateway with
a PDU from the transmit or retransmit queue. The Retrieval Indication a PDU from the transmit or retransmit queue. The Retrieval Indication
message does not contain the Action or seq_num fields, just a MTP3 message does not contain the Action or seq_num fields, just a MTP3
Protocol Data Unit (PDU) from the transmit or retransmit queue. Protocol Data Unit (PDU) from the transmit or retransmit queue.
Examples of the use of Retrieval Indication for SS7 Link Changeover are
provided in Section 5.3.6.
0 1 2 3 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 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 (0x300) | Length | | Tag (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ / \
\ Protocol Data / \ Protocol Data /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 31 skipping to change at page 29, line 31
it is only of significance to the sender. The receiver echoes the it is only of significance to the sender. The receiver echoes the
content of the Heartbeat Data in a BEAT ACK message. content of the Heartbeat Data in a BEAT ACK message.
3.3.2.7 ASP Active (ASPAC) 3.3.2.7 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SGP that it is The ASPAC message is sent by an ASP to indicate to an SGP that it is
Active and ready to be used. Active and ready to be used.
The ASPAC message contains the following parameters: The ASPAC message contains the following parameters:
Traffic Mode Type (mandatory) Traffic Mode Type (optional)
Interface Identifier (optional) Interface Identifier (optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (optional) INFO String (optional)
The format for the ASPAC message using integer formatted Interface The format for the ASPAC message using integer formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 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 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
skipping to change at page 40, line 37 skipping to change at page 38, line 37
Invalid Version 0x1 Invalid Version 0x1
Invalid Interface Identifier 0x2 Invalid Interface Identifier 0x2
Unsupported Message Class 0x3 Unsupported Message Class 0x3
Unsupported Message Type 0x4 Unsupported Message Type 0x4
Unsupported Traffic Handling Mode 0x5 Unsupported Traffic Handling Mode 0x5
Unexpected Message 0x6 Unexpected Message 0x6
Protocol Error 0x7 Protocol Error 0x7
Unsupported Interface Identifier Type 0x8 Unsupported Interface Identifier Type 0x8
Invalid Stream Identifier 0x9 Invalid Stream Identifier 0x9
Invalid Parameter Value 0xa Not Used in M2UA 0xa
Refused - Management Blocking 0xb Not Used in M2UA 0xb
Error - ASP Currently Active for 0xc Not Used in M2UA 0xc
Interface Identifier Refused - Management Blocking 0xd
Reserved 0xd ASP Identifier Required 0xe
Error - ASP Identifier Required 0xe Invalid ASP Identifier 0xf
Error - Invalid ASP Identifier 0xf ASP Active for Interface Identifier(s) 0x10
Refused - ASP Identifier Required 0x10 Invalid Parameter Value 0x11
Parameter Field Error 0x12
Unexpected Parameter 0x13
The "Invalid Version" error would be sent if a message was The "Invalid Version" error would be sent if a message was
received with an invalid or unsupported version. The Error message received with an invalid or unsupported version. The Error message
would contain the supported version in the Common header. The would contain the supported version in the Common header. The
Error message could optionally provide the supported version in Error message could optionally provide the supported version in
the Diagnostic Information area. the Diagnostic Information area.
The "Invalid Interface Identifier" error would be sent by a SGP if The "Invalid Interface Identifier" error would be sent by a SGP if
an ASP sends a message (i.e. an ASP Active message) with an invalid an ASP sends a message (i.e. an ASP Active message) with an invalid
(unconfigured) Interface Identifier value. One of the optional (unconfigured) Interface Identifier value. One of the optional
Interface Identifier parameters (Integer-based, text-based or integer Interface Identifier parameters (Integer-based, text-based or integer
range) MUST be used with this error code to identify the invalid range) MUST be used with this error code to identify the invalid
Interface Identifier(s). Interface Identifier(s) received.
The "Unsupported Traffic Handling Mode" error would be sent by a SGP The "Unsupported Traffic Handling Mode" error would be sent by a SGP
if an ASP sends an ASP Active with an unsupported Traffic Handling if an ASP sends an ASP Active with an unsupported Traffic Handling
Mode. An example would be a case in which the SGP did not support Mode. An example would be a case in which the SGP did not support
load-sharing. One of the optional Interface Identifier parameters load-sharing. One of the optional Interface Identifier parameters
(Integer-based, text-based or integer range) MAY be used with this (Integer-based, text-based or integer range) MAY be used with this
error code to identify the Interface Identifier(s). error code to identify the Interface Identifier(s).
The "Unexpected Message" error would be sent by an ASP if it received The "Unexpected Message" error would be sent by an ASP if it received
a MAUP message from an SGP while it was in the Inactive state. a MAUP message from an SGP while it was in the Inactive state.
skipping to change at page 41, line 31 skipping to change at page 39, line 31
The "Unsupported Interface Identifier Type" error would be sent by The "Unsupported Interface Identifier Type" error would be sent by
a SGP if an ASP sends a Text formatted Interface Identifier and the a SGP if an ASP sends a Text formatted Interface Identifier and the
SGP only supports Integer formatted Interface Identifiers. When SGP only supports Integer formatted Interface Identifiers. When
the ASP receives this error, it will need to resend its message with the ASP receives this error, it will need to resend its message with
an Integer formatted Interface Identifier. an Integer formatted Interface Identifier.
The "Unsupported Message Class" error would be sent if a message with The "Unsupported Message Class" error would be sent if a message with
an unexpected or unsupported Message Class is received. an unexpected or unsupported Message Class is received.
The "Invalid Parameter Value" error is sent if a message is received
with an invalid parameter value.
The "Refused - Management Blocking" error is sent when an ASP Up or The "Refused - Management Blocking" error is sent when an ASP Up or
ASP Active message is received and the request is refused for ASP Active message is received and the request is refused for
management reasons (e.g., management lock-out"). management reasons (e.g., management lock-out").
The "Error - ASP Currently Active for Interface Identifier(s)" error is The "ASP Identifier Required" is sent by a SGP in response
to an ASPUP message which does not contain an ASP Identifier
parameter when the SGP requires one. The ASP should resend the
ASPUP message with a ASP Identifier.
The "Invalid ASP Identifier" is send by a SGP in response to an
ASPUP message with an invalid (i.e. non-unique) ASP Identifier.
The "ASP Currently Active for Interface Identifier(s)" error is
sent by a SGP when a Deregistration request is received from an ASP sent by a SGP when a Deregistration request is received from an ASP
that is active for Interface Identifier(s) specified in the that is active for Interface Identifier(s) specified in the
Deregistration request. One of the optional Interface Identifier Deregistration request. One of the optional Interface Identifier
parameters (Integer-based, text-based or integer range) MAY be used parameters (Integer-based, text-based or integer range) MAY be used
with this error code to identify the Interface Identifier(s). with this error code to identify the Interface Identifier(s).
The "Error - ASP Identifier Required" is sent by a SGP in response The "Invalid Parameter Value " error is sent if a message is received
to an ASPUP message which does not contain an ASP Identifier with an invalid parameter value (e.g., a State Request with an
parameter when the SGP requires one. The ASP should resend the an undefined State).
ASPUP message with a ASP Identifier.
The "Error - Invalid ASP Identifier" is send by a SGP in response The "Parameter Field Error" would be sent if a message with a
to an ASPUP message with an invalid (i.e. non-unique) ASP Identifier. parameter that has a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter.
The optional Diagnostic information can be any information germane to The optional Diagnostic information can be any information germane to
the error condition, to assist in identification of the error condition. the error condition, to assist in identification of the error condition.
In the case of an Invalid Version Error Code the Diagnostic information In the case of an Invalid Version Error Code the Diagnostic information
includes the supported Version parameter. In the other cases, the includes the supported Version parameter. In the other cases, the
Diagnostic information MAY be the first 40 bytes of the offending Diagnostic information SHOULD be the first 40 bytes of the offending
message. message.
3.3.3.2 Notify (NTFY) 3.3.3.2 Notify (NTFY)
The Notify message is used to provide an autonomous indication of M2UA The Notify message is used to provide an autonomous indication of M2UA
events to an M2UA peer. events to an M2UA peer.
The NTFY message contains the following parameters: The NTFY message contains the following parameters:
Status Type (mandatory) Status Type (mandatory)
skipping to change at page 54, line 32 skipping to change at page 51, line 32
operate, is maintained in the M2UA layer in the SGP. The state of a operate, is maintained in the M2UA layer in the SGP. The state of a
particular ASP in a particular AS changes due to events. The events particular ASP in a particular AS changes due to events. The events
include: include:
* Reception of messages from the peer M2UA layer at the ASP; * Reception of messages from the peer M2UA layer at the ASP;
* Reception of some messages from the peer M2UA layer at other ASPs * Reception of some messages from the peer M2UA layer at other ASPs
in the AS (e.g., ASP Active message indicating "Override"); in the AS (e.g., ASP Active message indicating "Override");
* Reception of indications from the SCTP layer; or * Reception of indications from the SCTP layer; or
* Local Management intervention. * Local Management intervention.
The ASP state transition diagram is shown in Figure 6. The possible The ASP state transition diagram is shown in Figure 5. The possible
states of an ASP are: states of an ASP are:
ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the
related SCTP association is down. Initially all ASPs will be in this related SCTP association is down. Initially all ASPs will be in this
state. An ASP in this state SHOULD NOT be sent any M2UA messages, with state. An ASP in this state SHOULD NOT be sent any M2UA messages, with
the exception of Heartbeat messages. the exception of Heartbeat messages.
ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the
related SCTP association is up) but application traffic is stopped. related SCTP association is up) but application traffic is stopped.
In this state the ASP MAY be sent any non-MAUP M2UA messages. In this state the ASP MAY be sent any non-MAUP M2UA messages.
ASP-ACTIVE: The remote M2UA peer at the ASP is available and ASP-ACTIVE: The remote M2UA peer at the ASP is available and
application traffic is active (for a particular Interface Identifier application traffic is active (for a particular Interface Identifier
or set of Interface Identifiers). or set of Interface Identifiers).
Figure 6: ASP State Transition Diagram Figure 5: ASP State Transition Diagram
+--------------+ +--------------+
| ASP-ACTIVE | | ASP-ACTIVE |
+----------------------| | +----------------------| |
| Other +-------| | | Other +-------| |
| ASP in AS | +--------------+ | ASP in AS | +--------------+
| Overrides | ^ | | Overrides | ^ |
| | ASP | | ASP | | ASP | | ASP
| | Active | | Inactive | | Active | | Inactive
| | | v | | | v
skipping to change at page 56, line 26 skipping to change at page 53, line 26
T(r) SHOULD be started and all incoming signalling messages SHOULD be T(r) SHOULD be started and all incoming signalling messages SHOULD be
queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires,
the AS is moved to the AS-ACTIVE state and all the queued messages will the AS is moved to the AS-ACTIVE state and all the queued messages will
be sent to the ASP. be sent to the ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing
messages and discards all previously queued messages. The AS will move messages and discards all previously queued messages. The AS will move
to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state, to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state,
otherwise it will move to AS-DOWN state. otherwise it will move to AS-DOWN state.
Figure 7 shows an example AS state machine for the case where the Figure 6 shows an example AS state machine for the case where the
AS/ASP data is pre-configured. For other cases where the AS/ASP AS/ASP data is pre-configured. For other cases where the AS/ASP
configuration data is created dynamically, there would be differences configuration data is created dynamically, there would be differences
in the state machine, especially at creation of the AS. in the state machine, especially at creation of the AS.
For example, where the AS/ASP configuration data is not created until For example, where the AS/ASP configuration data is not created until
Registration of the first ASP, the AS-INACTIVE state is entered Registration of the first ASP, the AS-INACTIVE state is entered
directly upon the first successful REG REQ from an ASP. Another directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until the example is where the AS/ASP configuration data is not created until the
first ASP successfully enters the ASP-ACTIVE state. In this case the first ASP successfully enters the ASP-ACTIVE state. In this case the
AS-ACTIVE state is entered directly. AS-ACTIVE state is entered directly.
Figure 7: AS State Transition Diagram Figure 6: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+ +----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- | | AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE | | INACTIVE | | ACTIVE |
| |<--- | | | |<--- | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ Tr Expiry, ^ | ^ | \ Tr Expiry, ^ |
| | \ at least one | | | | \ at least one | |
| | \ ASP in ASP-INACTIVE | | | | \ ASP in ASP-INACTIVE | |
| | \ | | | | \ | |
skipping to change at page 59, line 39 skipping to change at page 56, line 39
be removed from service in all Application Servers that it is a member be removed from service in all Application Servers that it is a member
and no longer receive any MAUP or ASPTM messages. This action MAY be and no longer receive any MAUP or ASPTM messages. This action MAY be
initiated at the ASP by an M-ASP_DOWN request primitive from Layer initiated at the ASP by an M-ASP_DOWN request primitive from Layer
Management or MAY be initiated automatically by an M2UA management Management or MAY be initiated automatically by an M2UA management
function. function.
Whether the ASP is permanently removed from any AS is a function of Whether the ASP is permanently removed from any AS is a function of
configuration management. In the case where the ASP previously used configuration management. In the case where the ASP previously used
the Registration procedures (see Section 4.3.5) to register within the Registration procedures (see Section 4.3.5) to register within
Application Servers but has not deregistered from all of them prior to Application Servers but has not deregistered from all of them prior to
sending the ASP Down message, the SGP SHOULD consider the ASP as sending the ASP Down message, the SGP MUST consider the ASP as
Deregistered in all Application Servers that it is still a member. Deregistered in all Application Servers that it is still a member.
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an The SGP marks the ASP as ASP-DOWN, informs Layer Management with an
M-ASP_Down indication primitive, and returns an ASP Down Ack message M-ASP_Down indication primitive, and returns an ASP Down Ack message
to the ASP. to the ASP.
The SGP MUST send an ASP Down Ack message in response to a received ASP The SGP MUST send an ASP Down Ack message in response to a received ASP
Down message from the ASP even if the ASP is already marked as ASP-DOWN Down message from the ASP even if the ASP is already marked as ASP-DOWN
at the SGP. at the SGP.
skipping to change at page 63, line 50 skipping to change at page 60, line 50
When the ASP sends an ASP Inactive message it starts timer T(ack). 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 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 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 messages until it receives an ASP Inactive Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively, provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M- Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication. ASP_Inactive confirm primitive carrying a negative indication.
If no other ASPs in the Application Server are in the state ASP-ACTIVE If no other ASPs in the Application Server are in the state ASP-ACTIVE,
or ASP-STANDBY, the SGP MUST send a Notify message ("AS-Pending") to the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs
all of the ASPs in the AS which are in the state ASP-INACTIVE. The SGP in the AS which are in the state ASP-INACTIVE. The SGP SHOULD start
SHOULD start buffering the incoming messages for T(r)seconds, after buffering the incoming messages for T(r)seconds, after which messages
which messages MAY be discarded. T(r) is configurable by the network MAY be discarded. T(r) is configurable by the network operator. If
operator. If the SGP receives an ASP Active message from an ASP in the the SGP receives an ASP Active message from an ASP in the AS before
AS before expiry of T(r), the buffered traffic is directed to that ASP expiry of T(r), the buffered traffic is directed to that ASP and the
and the timer is cancelled. If T(r) expires, the AS is moved to the timer is cancelled. If T(r) expires, the AS is moved to the
AS-INACTIVE state. AS-INACTIVE state.
4.3.4.6 Notify Procedures 4.3.4.6 Notify Procedures
A Notify message reflecting a change in the AS state MUST be sent to 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 all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, Layer Management is informed with an M-NOTIFY ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message MUST be sent whether the indication primitive. The Notify message MUST be sent whether the
AS state change was a result of an ASP failure or reception of an AS state change was a result of an ASP failure or reception of an
skipping to change at page 64, line 56 skipping to change at page 61, line 56
The Heartbeat message may optionally contain an opaque Heartbeat Data The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Heartbeat parameter that MUST be echoed back unchanged in the related Heartbeat
Ack message. The sender, upon examining the contents of the returned Ack message. The sender, upon examining the contents of the returned
Heartbeat Ack message, MAY choose to consider the remote M2UA peer as Heartbeat Ack message, MAY choose to consider the remote M2UA peer as
unavailable. The contents/format of the Heartbeat Data parameter is unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original implementation-dependent and only of local interest to the original
sender. The contents may be used, for example, to support a Heartbeat sender. The contents may be used, for example, to support a Heartbeat
sequence algorithm (to detect missing Heartbeats), and/or a timestamp sequence algorithm (to detect missing Heartbeats), and/or a timestamp
mechanism (to evaluate delays). mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 6 "ASP state Note: Heartbeat related events are not shown in Figure 5 "ASP state
transition diagram". transition diagram".
4.4 Link Key Management Procedures 4.4 Link Key Management Procedures
The Interface Identifier Management procedures are optional. They can The Interface Identifier Management procedures are optional. They can
be used to support automatic allocation of Signalling Terminals or be used to support automatic allocation of Signalling Terminals or
Signalling Data Links [2][3]. Signalling Data Links [2][3].
4.4.1 Registration 4.4.1 Registration
skipping to change at page 69, line 45 skipping to change at page 66, line 45
- Fill in the MAUP message, fill in M2UA Message Header, fill in - Fill in the MAUP message, fill in M2UA Message Header, fill in
Common Header Common Header
- Send the MAUP message to the remote M2UA peer in the ASP, over the - Send the MAUP message to the remote M2UA peer in the ASP, over the
SCTP association SCTP association
5.3.1 SS7 Link Alignment 5.3.1 SS7 Link Alignment
The MGC can request that a SS7 link be brought into alignment using the The MGC can request that a SS7 link be brought into alignment using the
normal or emergency procedure. An example of the message flow to bring normal or emergency procedure [2][3]. An example of the message flow
a SS7 link in-service using the normal alignment procedure is shown to bring a SS7 link in-service using the normal alignment procedure is
below. shown below.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP SGP SGP ASP ASP
<----Start Req---|<---Establish Req----|<----Start Req------ <----Start Req---|<---Establish Req----|<----Start Req------
---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind---->
An example of the message flow to bring a SS7 link in-service using the An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure. emergency alignment procedure.
skipping to change at page 71, line 18 skipping to change at page 68, line 18
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP SGP SGP ASP ASP
<---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req---
----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm---->
5.3.4 Notification of Remote Processor Outage 5.3.4 Notification of Remote Processor Outage
The SGP can indicate Remote has entered or exited the Processor Outage The SGP can indicate Remote has entered or exited the Processor Outage
condition. It uses the State Indication message as shown below. condition for a SS7 link. It uses the State Indication message as shown
below.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP SGP SGP ASP ASP
----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind---->
-RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind-->
5.3.5 Notification of Link Congestion 5.3.5 Notification of SS7 Link Congestion
The SGP can indicate that a link has become congested. It uses the The SGP can indicate that a SS7 link has become congested. It uses the
Congestion Indication message as shown below. Congestion Indication message as shown below.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP SGP SGP ASP ASP
----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind---->
-Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind->
5.3.6 SS7 Link Changeover 5.3.6 SS7 Link Changeover
skipping to change at page 74, line 50 skipping to change at page 71, line 50
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->
6.0 Timer Values 6.0 Timer Values
The recommended default values for M2UA timers are: The recommended default values for M2UA timers are:
T(r) 2 seconds T(r) 2 seconds
T(ack) 2 seconds T(ack) 2 seconds
T(beat) Heartbeat Timer 30 seconds T(beat) Heartbeat Timer 30 seconds
7.0 Security 7.0 Security Considerations
M2UA is designed to carry signalling messages for telephony services. M2UA is designed to carry signalling messages for telephony services.
As such, M2UA MUST involve the security needs of several parties: the As such, M2UA MUST involve the security needs of several parties: the
end users of the services; the network providers and the applications end users of the services; the network providers and the applications
involved. Additional requirements MAY come from local regulation. involved. Additional requirements MAY come from local regulation.
While having some overlapping security needs, any security solution While having some overlapping security needs, any security solution
SHOULD fulfill all of the different parties' needs. SHOULD fulfill all of the different parties' needs.
7.1 Threats 7.1 Threats
skipping to change at page 75, line 40 skipping to change at page 72, line 40
service SHOULD be used for key management. service SHOULD be used for key management.
8.0 IANA Considerations 8.0 IANA Considerations
8.1 SCTP Payload Protocol Identifier 8.1 SCTP Payload Protocol Identifier
A request will be made to IANA to assign an M2UA value for the Payload A request will be made to IANA to assign an M2UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered: Payload Protocol Identifier will be registered:
M2UA 0x10 M2UA "2"
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, The SCTP Payload Protocol Identifier is included in each SCTP Data chunk,
to indicate which protocol the SCTP is carrying. This Payload Protocol to indicate which protocol the SCTP is carrying. This Payload Protocol
Identifier is not directly used by SCTP but MAY be used by certain 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 network entities to identify the type of information being carried in a
Data chunk. Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being presented way of determining additional information about the data being presented
to it by SCTP. to it by SCTP.
skipping to change at line 4004 skipping to change at page 75, line 19
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Ram Dantu, Ph.D. Tel +1-214-291-1111 Ram Dantu, Ph.D. Tel +1-214-291-1111
NetRake Corporation EMail rdantu@netrake.com NetRake Corporation EMail rdantu@netrake.com
3000 Technology Drive 3000 Technology Drive
Plano, TX 75074 Plano, TX 75074
USA USA
Greg Sidebottom EMail: gregside@home.net Greg Sidebottom EMail: gregside@home.com
gregside consulting
Kanata, Ontario Kanata, Ontario
Canada Canada
Tom George Tel: +1-972-519-3168 Tom George Tel: +1-972-519-3168
Alcatel USA EMail: tom.george@usa.alcatel.com Alcatel USA EMail: tom.george@usa.alcatel.com
1000 Coit Road 1000 Coit Road
Plano, TX 74075 Plano, TX 74075
USA USA
Brian Bidulock Tel +1-972-839-4489 Brian Bidulock Tel +1-972-839-4489
skipping to change at line 4026 skipping to change at line 3969
c/o #424, 4701 Preston Park Blvd. c/o #424, 4701 Preston Park Blvd.
Plano, TX 75093 Plano, TX 75093
USA USA
Jacob Heitz Tek +1-510-747-2917 Jacob Heitz Tek +1-510-747-2917
Lucent Technologies Email: jheitz@lucent.com Lucent Technologies Email: jheitz@lucent.com
1701 Harbor Bay Parkway 1701 Harbor Bay Parkway
Alameda, CA, 94502 Alameda, CA, 94502
USA USA
This Internet Draft expires March 2002. Appendix A: Signalling Network Architecture
A Signalling Gateway will support the transport of MTP2-User signalling
traffic received from the SS7 network to one or more distributed ASPs
(e.g., MGCs). Clearly, the M2UA protocol description cannot in itself
meet any performance and reliability requirements for such transport.
A physical network architecture is required, with data on the
availability and transfer performance of the physical nodes involved in
any particular exchange of information. However, the M2UA protocol is
flexible enough allow its operation and management in a variety of
physical configurations that will enable Network Operators to meet
their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, these Network Operators should
ensure that there is no single point of failure provisioned in the end-
to-end network architecture between an SS7 node and an IP ASP.
Depending of course on the reliability of the SGP and ASP functional
elements, this can typically be met by the spreading SS7 links in a
SS7 linkset [1] across SGPs or SGs, the provision of redundant
QoS-bounded IP network paths for SCTP Associations between SCTP End
Points, and redundant Hosts. The distribution of ASPs within the
available Hosts is also important. For a particular Application
Server, the related ASPs MAY be distributed over at least two Hosts.
An example logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 7 below:
************** **************
* ********__*______________________________*__******** * Host1
SG1 * * SGP1 *__*________________ _______*__* ASP1 * *
* ******** * | | * ******** *
* . * | | * *
* . * | | **************
************** | |
| |
************** | |
* ********__*______________________|
SG2 * * SGP2 *__*________ |
* ******** * | |
* . * | |
* . * | |
************** | | **************
| |_____________*__******** * Host2
|_____________________*__* ASP2 * *
. * ******** *
. SCTP Associations * *
. **************
.
.
.
Figure 7: Logical Model Example
To avoid a single point of failure, it is recommended that a minimum
of two ASPs be configured in an AS list, resident in separate hosts
and, therefore, available over different SCTP associations. For
example, in the network shown in Figure 7, all messages for the
Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in
Host2. The AS list at SGP1 might look like the following:
Interface Identifiers - Application Server #1
ASP1/Host1 - State = Active
ASP2/Host2 - State = Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP2 in Host2 would
normally be brought to the active state upon failure of ASP1/Host1.
In this example, both ASPs are Inactive or Active, meaning that the
related SCTP association and far-end M2UA peer is ready.
For carrier grade networks, Operators should ensure that under failure
or isolation of a particular ASP, stable calls or transactions are not
lost. This implies that ASPs need, in some cases, to share the call/-
transaction state or be able to pass the call/transaction state between
each other. Also, in the case of ASPs performing call processing,
coordination MAY be required with the related Media Gateway to transfer
the MGC control for a particular trunk termination. However, this
sharing or communication is outside the scope of this document.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/