draft-ietf-sigtran-m2ua-06.txt   draft-ietf-sigtran-m2ua-07.txt 
Network Working Group Ken Morneault Network Working Group Ken Morneault
INTERNET-DRAFT Ram Dantu INTERNET-DRAFT Ram Dantu
Cisco Systems Cisco Systems
Mallesh Kalla
Telcordia
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Tom George Tom George
Alcatel Alcatel
Brian Bidulock
OpenSS7
Jacob Heitz
Lucent
Expires in six months Nov 2000 Expires in six months Feb 2001
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-06.txt> <draft-ietf-sigtran-m2ua-07.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 4, line 13 skipping to change at page 4, line 13
Process. Process.
Signaling Link Terminal (SLT) - Refers to the means of performing all Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their of the functions defined at MTP level 2 regardless of their
implementation [2]. implementation [2].
Layer Management - Layer Management is a nodal function in an SG or Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the M2UA layer and a ASP that handles the inputs and outputs between the M2UA layer and a
local management entity. local management entity.
MTP - The Message Transfer Part of the SS7 protocol.
MTP2 - MTP Level 2, the signalling datalink layer of SS7
MTP3 - MTP Level 3, the signalling network layer of SS7
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Host - The computing platform that the ASP process is running on. Host - The computing platform that the ASP process is running on.
1.3 M2UA Overview 1.3 M2UA Overview
The framework architecture that has been defined for SCN signaling The framework architecture that has been defined for SCN signaling
transport over IP [6] uses multiple components, including a signaling transport over IP [6] uses multiple components, including a signaling
common transport protocol and an adaptation module to support the common transport protocol and an adaptation module to support the
services expected by a particular SCN signaling protocol from its services expected by a particular SCN signaling protocol from its
skipping to change at page 6, line 54 skipping to change at page 6, line 54
to a unique Application Server, based on the Interface Identifier of to a unique Application Server, based on the Interface Identifier of
the message. the message.
The Application Server is in practical terms a list of all ASPs currently The Application Server is in practical terms a list of all ASPs currently
registered to process MTP2-User messages from certain Interface registered to process MTP2-User messages from certain Interface
Identifiers. One or more ASPs in the list are normally active (i.e., Identifiers. One or more ASPs in the list are normally active (i.e.,
handling traffic) while any others MAY be unavailable or inactive, to be handling traffic) while any others MAY be unavailable or inactive, to be
possibly used in the event of failure or unavailability of the active possibly used in the event of failure or unavailability of the active
ASP(s). ASP(s).
The fail-over model supports an n+k redundancy model, where n ASPs The M2UA fail-over model supports an 1+k redundancy model, where 1 ASPs
is the minimum number of redundant ASPs required to handle traffic and is the minimum number of redundant ASPs required to handle traffic and
k ASPs are available to take over for a failed or unavailable ASP. k ASPs are available to take over for a failed or unavailable ASP.
Note that 1+1 active/standby redundancy is a subset of this model. Note that 1+1 active/standby redundancy is a subset of this model.
A simplex 1+0 model is also supported as a subset, with no ASP A simplex 1+0 model is also supported as a subset, with no ASP
redundancy. redundancy.
To avoid a single point of failure, it is recommended that a minimum of To avoid a single point of failure, it is recommended that a minimum of
two ASPs be in the list, resident in separate hosts and therefore two ASPs be in the list, resident in separate hosts and therefore
available over different SCTP Associations. For example, in the available over different SCTP Associations. For example, in the
network shown in Figure 2, all messages for the Interface Identifiers network shown in Figure 2, all messages for the Interface Identifiers
skipping to change at page 9, line 91 skipping to change at page 9, line 91
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 back-up ASP are available, M2UA peer protocol is a primary and a back-up 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 SG to reflect the active Application Server Process(es). the SG to reflect the active Application Server Process(es).
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 Stream Management 1.5.3 SCTP Specifics
1.5.3.1 SCTP Stream Management
SCTP allows user specified number of streams to be opened during the SCTP allows user specified number of streams to be opened during the
initialization. It is the responsibility of the M2UA layer to ensure initialization. It is the responsibility of the M2UA layer to ensure
proper management of these streams. Because of the unidirectional proper management of these streams. Because of the unidirectional
nature of streams, M2UA layers are not aware of the stream information nature of streams, M2UA layers are not aware of the stream information
from the peer M2UA layers. Instead, the Interface Identifier is from the peer M2UA layers. Instead, the Interface Identifier is
in the M2UA message header. 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 signaling elements. It is performance and reliability of the signaling elements. It is
recommended that a separate SCTP stream is used for each SS7 link. recommended that a separate SCTP stream is used for each SS7 link.
1.5.3.2 SCTP Send Primitive
M2UA shall set the lifetime parameter in the SEND primitive to SCTP
when sending a message. When SCTP times out a message, M2UA shall
abort the SCTP association and follow the same procedure as for a
failed SCTP association.
The default value for the lifetime shall be 2 seconds. Some messages,
like STATUS_FLUSH_BUFFERS may need a shorter lifetime. This is for
further study.
1.5.4 Seamless SS7 Network Management Interworking 1.5.4 Seamless SS7 Network Management Interworking
The M2UA layer on the SG SHOULD pass an indication of unavailability of The M2UA layer on the SG SHOULD pass an indication of unavailability of
the M2UA-User (MTP3) to the local Layer Management, if the currently the M2UA-User (MTP3) to the local Layer Management, if the currently
active ASP moves from the ACTIVE state. If the AS moves to the DOWN active ASP moves from the ACTIVE state. If the AS moves to the DOWN
state while SS7 links are in-service, the SG SHOULD follow the MTP 2 state while SS7 links are in-service, the SG SHOULD follow the MTP 2
processor outage procedures [2]. processor outage procedures [2].
1.5.5 Flow Control / Congestion 1.5.5 Flow Control / Congestion
It is possible for the M2UA layer to be informed of IP network congestion It is possible for the M2UA layer to be informed of IP network congestion
by means of an implementation-dependent function (i.e. an indication onset and abatement by means of an implementation-dependent function
from the SCTP). If the M2UA layer receives this indication, the action(s) (i.e. an indication from the SCTP).
taken are implementation dependent.
If the M2UA layer on the SG receives an IP network congestion onset
indication, the M2UA layer SHOULD inform the MTP2 layer of a Local
Processor Outage. When the M2UA layer on the SG receives an IP network
congestion abate indication, the M2UA layer SHOULD inform the MTP2 layer
of a Local Processor Outage condition has been cleared.
If the M2UA layer on the ASP receives an IP network congestion onset
indication, the M2UA layer SHOULD inform the MTP3 layer of a Local
Processor Outage. When the M2UA layer on the ASP receives an IP network
congestion abate indication, the M2UA layer SHOULD inform the MTP3 layer
of a Local Processor Outage condition has been cleared.
1.5.6 Audit of Link State
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.
The M2UA on the SG would respond to the audit request with information
regarding the current state of the link (i.e. in-service, 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 11, line 71 skipping to change at page 11, line 71
4 Release Request 4 Release Request
5 Release Confirm 5 Release Confirm
6 Release Indication 6 Release Indication
7 State Request 7 State Request
8 State Confirm 8 State Confirm
9 State Indication 9 State Indication
10 Data Retrieval Request 10 Data Retrieval Request
11 Data Retrieval Confirm 11 Data Retrieval Confirm
12 Data Retrieval Indication 12 Data Retrieval Indication
13 Data Retrieval Complete Indication 13 Data Retrieval Complete Indication
14 to 127 Reserved by the IETF 14 Congestion Indication
15 TTC Data
16 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MAUP extensions 128 to 255 Reserved for IETF-Defined MAUP extensions
Application Server Process State Maintenance (ASPSM) messages Application Server Process State Maintenance (ASPSM) messages
0 Reserved 0 Reserved
1 ASP Up (UP) 1 ASP Up (UP)
2 ASP Down (DOWN) 2 ASP Down (DOWN)
3 Heartbeat (BEAT) 3 Reserved
4 ASP Up Ack (UP ACK) 4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK) 5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK) 6 Reserved
7 to 127 Reserved by the IETF 7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions 128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASTM) messages Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved 0 Reserved
1 ASP Active (ACTIVE) 1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE) 2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK) 3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK) 4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF 5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASTM extensions 128 to 255 Reserved for IETF-Defined ASPTM extensions
Management (MGMT) Messages Management (MGMT) Messages
0 Error (ERR) 0 Error (ERR)
1 Notify (NTFY) 1 Notify (NTFY)
2 to 127 Reserved by the IETF 2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions 128 to 255 Reserved for IETF-Defined MGMT extensions
3.1.3 Reserved 3.1.3 Reserved
The Reserved field is 8-bits. It SHOULD be set to all '0's and The Reserved field is 8-bits. It SHOULD be set to all '0's and
ignored by the receiver. ignored by the receiver.
3.1.4 Message Length 3.1.4 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. including the header. The Message Length includes parameter
padding bytes, if any.
3.1.5 Variable-Length Parameter Format 3.1.5 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 12, line 144 skipping to change at page 12, line 145
The following section defines the messages and parameter contents. The 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 3) and the
M2UA message header (Figure 4). M2UA message header (Figure 4).
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 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The
Data message contains the protocol data. Data message contains the following parameter:
Protocol Data (Mandatory)
The format for the Data Message parameters is as follows: The format for the Data Message parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length | | Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data | | Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Signaling Information Octet (SIO). network byte order starting with the Signaling Information Octet (SIO).
3.3.1.2 Establish (Request, Confirmation) 3.3.1.2 TTC Data
The TTC Data message contains a TTC SS7 MTP2-User Protocol Data Unit
(PDU). The TTC Data message contains the following parameter:
Protocol Data (Mandatory)
The format for the TTC Data Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in
network byte order starting with the Length Indicator (LI) octet.
The Japanese TTC variant uses the spare bits of the LI octet for
priority.
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 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 the in-service, it will send the Establish Request message. Note that the
gateway MAY already have the SS7 link established at its layer. If so, gateway MAY already have the SS7 link established at its layer. If so,
upon receipt of an Establish Request, the gateway takes no action except upon receipt of an Establish Request, the gateway takes no action except
to send an Establish Confirm. 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
skipping to change at page 13, line 42 skipping to change at page 13, line 66
Establish Confirm. If the timer expires, the MGC would re-send the Establish Confirm. If the timer expires, the MGC would re-send 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 of Emergency) for bringing the link in service is The mode (Normal of Emergency) for bringing the link in service is
defaulted to Normal. The State Request (described in Section 3.3.1.4 defaulted to Normal. The State Request (described in Section 3.3.1.4
below) can be used to change the mode to Emergency. below) can be used to change the mode to Emergency.
3.3.1.3 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.4 State (Request, Confirm) 3.3.1.5 State Request
The State Request message can be sent from a MGC to cause an action The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway. The on a particular SS7 link supported by the Signaling Gateway. The
gateway sends a State Confirm to the MGC if the action has been success- gateway sends a State Confirm to the MGC if the action has been success-
fully completed. The State Confirm reflects that state value received fully completed. The State Confirm reflects that state value received
in the State Request message. in the State Request message.
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 14, line 26 skipping to change at page 13, line 101
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 procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure emergency) procedure
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit
buffers buffers
STATUS_CONTINUE 0x5 Continue STATUS_CONTINUE 0x5 Continue
STATUS_AUDIT 0x6 Audit state of link
3.3.1.5 State Indication 3.3.1.5 State Confirm
The State Confirm message will be sent by the SG in response to a State
Request from the MGC. The State Confirm reflects that state value
received in the State Request message. There is also a field to indicate
whether or not the the State Request was successfully completed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x16) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Request
message.
Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered
STATUS_EMER_SET 0x2 Request emergency alignment
procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit
buffers
STATUS_CONTINUE 0x5 Continue
STATUS_AUDIT 0x6 Audit state of link
The valid values for the Result field are shown in the following table.
Define Value Description
STATUS_SUCCESS 0x0 Successfully completed Request
STATUS_FAILURE 0x1 Failed to complete Request
3.3.1.6 State Indication
The MTP2 State Indication message can be sent from a gateway to an The MTP2 State Indication message can be sent from a gateway to an
ASP to indicate a condition on a link. ASP to indicate a condition on a link.
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 (0x11) | Length | | Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | | Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table.
Define Value Description
EVENT_RPO_ENTER 0x1 Remote entered processor outage
EVENT_RPO_EXIT 0x2 Remote exited processor outage
3.3.1.7 Congestion Indication
The Congestion Indication message can be sent from a gateway to an ASP
to indicate the congestion status and discard status of a link. When
the MSU buffer fill increases above an Onset threshold or decreases below
an Abatement threshold or crosses a Discard threshold in either
direction, the SG SHALL send a congestion indication message.
The SG shall send the message only when there is actually a change
in either the discard level or the congestion level to report,
meaning it is different from the previously sent message. In addition,
the SG SHALL use an implementation dependent algorithm to limit the
frequency of congestion indication messages.
An implementation may optionally send Congestion Indication messages on
a "high priority" stream in order to potentially reduce delay (Refer to
[12] for more details).
The Congestion Indication message contains the following parameters:
Congestion Status (Mandatory)
Discard Status (Optional)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x15) | Length | | Tag (0x15) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cong Level | | Congestion Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table. The valid values for Congestion Status and Discard Status are shown in
the following table.
Define Value Description Define Value Description
EVENT_CONG_ENTER 0x1 Link Congestion Entered LEVEL_NONE 0x0 No congestion.
EVENT_CONG_EXIT 0x2 Link Congestion Exited LEVEL_1 0x1 Congestion Level 1
EVENT_RPO_ENTER 0x3 Remote entered processor outage LEVEL_2 0x2 Congestion Level 2
EVENT_RPO_EXIT 0x4 Remote exited processor outage LEVEL_3 0x3 Congestion Level 3
The Cong Level parameter would only be used with a link congestion For networks that do not support multiple levels of congestion, only the
event. The Cong Level parameter would be used for National Networks LEVEL_NONE and LEVEL_1 values will be used. For networks that support
that make use of multiple congestion levels [2]. multiple levels of congestion, it is possible for all values to be used.
Refer to [2] and [9] for more details.
3.3.1.6 Retrieval (Request, Confirm) 3.3.1.8 Retrieval (Request, Confirm)
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
retransmit queue or to flush PDUs from the retransmit queue. retransmit queue or to flush PDUs from the retransmit queue.
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 (0x12) | Length | | Tag (0x12) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 40 skipping to change at page 15, line 40
When the Signaling Gateway sends a Retrieval Confirm to this request, When the Signaling Gateway sends a Retrieval Confirm to this request,
it echos the action and puts the Backward Sequence Number (BSN) in the it echos the action and puts the Backward Sequence Number (BSN) in the
seq_num field if the action was ACTION_RTRV_BSN. If there is a failure seq_num field if the action was ACTION_RTRV_BSN. If there is a failure
in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff). in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff).
For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of
of seq_num will be set to zero for success or -1 (0xffffffff) for failure. of seq_num will be set to zero for success or -1 (0xffffffff) for failure.
A failure means that the buffers could not be retrieved. For a Retrieval A failure means that the buffers could not be retrieved. For a Retrieval
Confirm with an Action of ACTION_DROP_MSGS, the value received in the Confirm with an Action of ACTION_DROP_MSGS, the value received in the
seq_num field will be ignored. seq_num field will be ignored.
3.3.1.7 Retrieval Indication 3.3.1.9 Retrieval Indication
The Retrieval Indication message is sent by the Signaling Gateway The Retrieval Indication message is sent by the Signaling Gateway
with a PDU from the retransmit queue. The Retrieval Indication with a PDU from the 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 retransmit queue. Protocol Data Unit (PDU) from the retransmit queue.
The M2UA implementation MAY consider the use of the bundling feature The M2UA implementation MAY consider the use of the bundling feature
of SCTP for Retrieval Indication messages. of SCTP for Retrieval Indication messages.
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 (0x14) | Length | | Tag (0x14) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU from retransmit queue | | PDU from retransmit queue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.1.8 Retrieval Complete Indication 3.3.1.10 Retrieval Complete Indication
The MTP2 Retrieval Complete Indication message is exactly the same as The MTP2 Retrieval Complete Indication message is exactly the same as
the MTP2 Retrieval Indication message except that it also indicates that the MTP2 Retrieval Indication message except that it also indicates that
it contains the last PDU from the retransmit queue. it contains the last PDU from the retransmit queue.
3.3.2 Application Server Process Maintenance (ASPM) Messages 3.3.2 Application Server Process Maintenance (ASPM) Messages
The ASPM messages will only use the common message header. The ASPM messages will only use the common message header.
3.3.2.1 ASP UP (ASPUP) 3.3.2.1 ASP UP (ASPUP)
skipping to change at page 19, line ? skipping to change at page 19, line ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Traffic Mode Type and Interface Identifier The format of the Traffic Mode Type and Interface Identifier
parameters is the same as for the ASP Inactive message parameters is the same as for the ASP Inactive message
(See Section 3.3.2.7). (See Section 3.3.2.7).
The format and description of the optional Info String parameter is The format and description of the optional Info String parameter is
the same as for the ASP Up message (See Section 3.3.2.1). the same as for the ASP Up message (See Section 3.3.2.1).
3.3.2.9 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the M2UA peers
are still available to each other. It is recommended for use when
the M2AU runs over a transport layer other than the SCTP, which has its
own heartbeat.
The BEAT message contains the following parameters:
Heartbeat Data Optional
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
| Heartbeat Data * |
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node.
The Heartbeat Data could include, for example, a Heartbeat Sequence
Number and, or Timestamp. The receiver of a Heartbeat message does
not process this field as it is only of significance to the sender.
The receiver MUST respond with a Heartbeat Ack message.
3.3.2.10 Heartbeat Ack (BEAT-Ack)
The Heartbeat Ack message is sent in response to a received Heartbeat
message. It includes all the parameters of the received Heartbeat
message, without any change.
3.3.3 Layer Management (MGMT) Messages 3.3.3 Layer Management (MGMT) Messages
3.3.3.1 Error (ERR) 3.3.3.1 Error (ERR)
The Error message is used to notify a peer of an error event The Error message is used to notify a peer of an error event
associated with an incoming message. For example, the message type associated with an incoming message. For example, the message type
might be unexpected given the current state, or a parameter value might might be unexpected given the current state, or a parameter value might
be invalid. be invalid.
The ERR message contains the following parameters: The ERR message contains the following parameters:
skipping to change at page 22, line 126 skipping to change at page 22, line 126
| +-------------+ | +-------------+
| ^ | | ^ |
ASP Down/ | ASP | | ASP Down / ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI SCTP CDI | Up | | SCTP CDI
| | v | | v
| +-------------+ | +-------------+
+--------------------->| | +--------------------->| |
| ASP Down | | ASP Down |
+-------------+ +-------------+
SCTP CDI The local SCTP layer's Communication Down Indication to the SCTP CDI: The local SCTP layer's Communication Down Indication to the
Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this
indication when it detects the loss of connectivity to the ASP's peer indication when it detects the loss of connectivity to the ASP's peer
SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE
notification and COMMUNICATION LOST notification from the SCTP. notification and COMMUNICATION LOST notification from the SCTP.
When an SCTP association fails at the SG, M2UA shall change the states
of all ASPs reached through the aborted SCTP association to ASP-DOWN.
When an SCTP association fails at the ASP, M2UA shall either cause other
ASPs to become active or send link-out-of-service primitives to MTP3.
4.3.1.2 AS States 4.3.1.2 AS States
The state of the AS is maintained in the M2UA layer on the SG. The state of the AS is maintained in the M2UA layer on the SG.
The state of an AS changes due to events. These events include the The state of an AS changes due to events. These events include the
following: following:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
The possible states of an AS are the following: The possible states of an AS are the following:
AS-DOWN: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP Down state for this AS. that all related ASPs are in the ASP Down state for this AS. When
Initially the AS will be in this state. the AS transitions to the AS-DOWN state, all of the SS7 links (Interface
Identifiers) for this AS should be taken out-of-service. Initially the
AS will be in this state.
AS-INACTIVE: The Application Server is available but no application traffic AS-INACTIVE: The Application Server is available but no application
is active (i.e., one or more related ASPs are in the ASP-Inactive state, traffic is active (i.e., one or more related ASPs are in the ASP-Inactive
but none in the ASP-Active state). state, but none in the ASP-Active state).
AS-ACTIVE: The Application Server is available and application traffic AS-ACTIVE: The Application Server is available and application traffic
is active. This state implies that one ASP is in the ASP-ACTIVE state. is active. This state implies that one ASP is in the ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned from active to inactive or AS-PENDING: An active ASP has transitioned from active to inactive or
down and it was the last remaining active ASP in the AS. A recovery down and it was the last remaining active ASP in the AS. A recovery
timer T(r) will be started and all incoming SCN messages will be timer T(r) will be started and all incoming SCN messages will be
queued by the SG. If an ASP becomes active before T(r) expires, the queued by the SG. If an ASP becomes active before T(r) expires, the
AS will move to AS-ACTIVE state and all the queued messages will be AS will move to AS-ACTIVE state and all the queued messages will be
sent to the active ASP. sent to the active ASP.
If T(r) expires before an ASP becomes active, the SG stops queuing If T(r) expires before an ASP becomes active, the SG stops queueing
messages and discards all previously queued messages. The AS will move messages and discards all previously queued messages. In addition,
to AS-Inactive if at least one ASP is in ASP-Inactive state, otherwise it the SG SHALL send the Stop primitive to MTP2 to take the link out of
will move to AS-DOWN state. service. The AS will move to AS-Inactive if at least one ASP is in
ASP-Inactive state, otherwise it will move to AS-DOWN state.
If an ASP transitions to the ASP-DOWN state and all ASPs in the AS are
in the ASP-DOWN state, then the SG SHALL send the Stop primitive to MTP2
to take the link out of service and moves the AS to the AS-DOWN state.
Figure 7 AS State Transition Diagram Figure 7 AS State Transition Diagram
+----------+ one ASP trans ACTIVE +-------------+ +----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| | | |------------------------>| |
| AS-INACT | | AS-ACTIVE | | AS-INACT | | AS-ACTIVE |
| | | | | | | |
| |< | | | |< | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ Tr Trigger ^ | ^ | \ Tr Expires ^ |
| | \ at least one | | | | \ at least one | |
| | \ ASP in UP | | | | \ ASP in UP | |
| | \ | | | | \ | |
| | \ | | | | \ | |
| | \ | | | | \ | |
one ASP | | \ one ASP | | Last ACTIVE ASP one ASP | | \ one ASP | | Last ACTIVE ASP
trans | | all ASP \------\ trans to | | trans to INACT trans | | all ASP \------\ trans to | | trans to INACT
to | | trans to \ ACTIVE | | or DOWN to | | trans to \ ACTIVE | | or DOWN
INACT | | DOWN \ | | (start Tr timer) INACT | | DOWN \ | | (start Tr timer)
| | \ | | | | \ | |
skipping to change at page 24, line 71 skipping to change at page 24, line 71
When an ASP Up message is received at an SG and internally the ASP is When an ASP Up message is received at an SG and internally the ASP is
not considered locked-out for local management reasons, the SG marks not considered locked-out for local management reasons, the SG marks
the remote ASP as Inactive. The SG responds with an ASP Up Ack message the remote ASP as Inactive. The SG responds with an ASP Up Ack message
in acknowledgement. The SG sends an-Up Ack message in response to a in acknowledgement. The SG sends an-Up Ack message in response to a
received ASP Up message even if the ASP is already marked as "Inactive" received ASP Up message even if the ASP is already marked as "Inactive"
at the SG. at the SG.
If for any local reason the SG cannot respond with an ASP Up, the SG If for any local reason the SG cannot respond with an ASP Up, the SG
responds to a ASP Up with a ASP Down Ack message. responds to a ASP Up with a ASP Down Ack message.
At the ASP, the ASP Up Ack message received from the SG is not When the ASP sends an ASP Up it starts timer T(ack). If the ASP does
acknowledged by the ASP. If the ASP does not receive a response from not receive a response to an ASP Up within T(ack), the ASP MAY restart
the SG, or an ASP Down is received, the ASP MAY resend ASP Up messages T(ack) and resend ASP Up messages until it receives an ASP Up Ack
every 2 seconds until it receives a ASP Up Ack message from the message. T(ack) SHOULD be provisionable, with a default of 2 seconds.
SG. The ASP MAY decide to reduce the frequency (say to every 5 Alternatively, retransmission of ASP Up messages MAY be put under
seconds) if an ASP Up Ack is not received after a few tries. control of Layer Management. In this method, expiry of T(ack) results
in a M-ASP-Up confirmation carrying a negative indication.
The ASP MUST wait for the ASP Up Ack message from the SG before The ASP MUST wait for the ASP Up Ack message from the SG before
sending any ASP traffic control messages (ASPAC or ASPIA) or Data sending any ASP traffic control messages (ASPAC or ASPIA) or Data
messages or it will risk message loss. If the SG receives Data messages or it will risk message loss. If the SG receives Data
messages before an ASP Up is received, the SG SHOULD discard. messages before an ASP Up is received, the SG SHOULD discard.
4.3.3.2 ASP Down 4.3.3.2 ASP Down
The ASP will send an ASP Down to an SG when the ASP is to be removed The ASP will send an ASP Down to an SG when the ASP is to be removed
from the list of ASPs in all Application Servers that it is a member from the list of ASPs in all Application Servers that it is a member
skipping to change at page 24, line 103 skipping to change at page 24, line 104
the ASP if one of the following events occur: the ASP if one of the following events occur:
- an ASP Down message is received from the ASP, - an ASP Down message is received from the ASP,
- another ASPM message is received from the ASP and the SG has - another ASPM message is received from the ASP and the SG has
locked out the ASP for management reasons. locked out the ASP for management reasons.
The SG sends anASP Down Ack message in response to a received ASP Down The SG sends anASP Down Ack message in response to a received ASP Down
message from the ASP even if the ASP is already marked as "Down" at message from the ASP even if the ASP is already marked as "Down" at
the SG. the SG.
If the ASP does not receive a response from the SG, the ASP MAY send At the ASP, the ASP Down Ack message received is not acknowledged.
ASP Down messages every 2 seconds until it receives an ASP Down Ack Layer Management is informed with an M-ASP Down confirm primitive.
message from the SG or the SCTP association goes down. The ASP MAY
decide to reduce the frequency (say to every 5 seconds) if an ASP Down When the ASP sends an ASP Down it starts timer T(ack). If the ASP does
Ack is not received after a few tries. not receive a response to an ASP Down within T(ack), the ASP MAY
restart T(ack) and resend ASP Down messages until it receives an
ASP Down Ack message. T(ack) SHOULD be provisionable, with a default
of 2 seconds. Alternatively, retransmission of ASP Down messages MAY
be put under control of Layer Management. In this method, expiry of
T(ack) results in a M-ASP-Down confirmation carrying a negative
indication.
4.3.3.3 M2UA Version Control 4.3.3.3 M2UA Version Control
If a ASP Up message with an unsupported version is received, the If a ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version the receiving end responds with an Error message, indicating the version the
receiving node supports. receiving node supports.
This is useful when protocol version upgrades are being performed in a This is useful when protocol version upgrades are being performed in a
network. A node upgraded to a newer version SHOULD support the older network. A node upgraded to a newer version SHOULD support the older
versions used on other nodes it is communicating with. Because ASPs versions used on other nodes it is communicating with. Because ASPs
skipping to change at page 24, line 133 skipping to change at page 24, line 140
Any time after the ASP has received a ASP Up Ack from the SG, the ASP Any time after the ASP has received a ASP Up Ack from the SG, the ASP
sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready
to start processing traffic. In the case where an ASP is configured/- to start processing traffic. In the case where an ASP is configured/-
registered to process the traffic for more than one Application Server registered to process the traffic for more than one Application Server
across an SCTP association, the ASPAC contains one or more Interface across an SCTP association, the ASPAC contains one or more Interface
Identifiers to indicate for which Application Servers the ASPAC applies. Identifiers to indicate for which Application Servers the ASPAC applies.
When an ASP Active (ASPAC) message is received, the SG responds to the When an ASP Active (ASPAC) message is received, the SG responds to the
ASP with a ASPAC Ack message acknowledging that the ASPAC was received ASP with a ASPAC Ack message acknowledging that the ASPAC was received
and starts sending traffic for the associated Application Server(s) and starts sending traffic for the associated Application Server(s)
to that ASP. to that ASP. Note that the SG sends an ASP Active Ack message in
response to a received ASP Active message even if the ASP is already
marked as "Active" at the SG.
The ASP MUST wait for the ASP-Active Ack message from the SG before The ASP MUST wait for the ASP Active Ack message from the SG before
sending any Data messages or it will risk message loss. If the SG sending any Data messages or it will risk message loss. If the SG
receives MAUP messages before an ASP Active is received, the SG SHOULD receives MAUP messages before an ASP Active is received, the SG SHOULD
discard these messages. discard these messages.
When the ASP sends an ASP Active it starts timer T(ack). If
the ASP does not receive a response to an ASP Active within T(ack), the
ASP MAY restart T(ack) and resend ASP Active messages until it
receives an ASP Active Ack message. T(ack) SHOULD be provisionable, with
a default of 2 seconds. Alternatively, retransmission of ASP Active
messages may be put under control of Layer Management. In this method,
expiry of T(ack) results in a M-ASP-Active confirmation carrying a
negative indication.
There is one mode of Application Server traffic handling in the SG There is one mode of Application Server traffic handling in the SG
M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the
mode used in a particular Application Server. If the SG determines that mode used in a particular Application Server. If the SG determines that
the mode indicates in an ASPAC is incompatible with the traffic handling the mode indicates in an ASPAC is incompatible with the traffic handling
mode currently used in the AS, the SG responds with an Error message mode currently used in the AS, the SG responds with an Error message
indicating Unsupported Traffic Handling Mode. indicating Unsupported Traffic Handling Mode.
For Over-ride mode AS, the reception of an ASPAC message at an SG causes For Over-ride mode AS, the reception of an ASPAC message at an SG causes
the redirection of all traffic for the AS to the ASP that sent the ASPAC. the redirection of all traffic for the AS to the ASP that sent the ASPAC.
The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. The SG responds to the ASPAC with an ASP-Active Ack message to the ASP.
skipping to change at page 24, line 178 skipping to change at page 24, line 196
ASPAC is incompatible with the traffic handling mode currently used in ASPAC is incompatible with the traffic handling mode currently used in
the AS, the SG responds with an Error message indicating Unsupported the AS, the SG responds with an Error message indicating Unsupported
Traffic Handling Mode. Traffic Handling Mode.
In the case of an Over-ride mode AS, where normally another ASP has In the case of an Over-ride mode AS, where normally another ASP has
already taken over the traffic within the AS with an Over-ride ASPAC, already taken over the traffic within the AS with an Over-ride ASPAC,
the ASP which sends the ASPIA is already considered by the SG to be the ASP which sends the ASPIA is already considered by the SG to be
"Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is
sent to the ASP, after ensuring that all traffic is stopped to the ASP. sent to the ASP, after ensuring that all traffic is stopped to the ASP.
When the ASP sends an ASP Inactive it starts timer T(ack). If the ASP
does not receive a response to an 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) SHOULD be provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Inactive
messages may be put under control of Layer Management. In this method,
expiry of T(ack) results in a M-ASP-Inactive confirmation carrying a
negative indication.
If no other ASPs are Active in the Application Server, the SG either If no other ASPs are Active in the Application Server, the SG either
discards all incoming messages for the AS or starts buffering the discards all incoming messages for the AS or starts buffering the
incoming messages for T(r)seconds, after which messages will be incoming messages for T(r)seconds, after which messages will be
discarded. T(r) is configurable by the network operator. If the SG discarded. T(r) is configurable by the network operator. If the SG
receives an ASPAC from an ASP in the AS before expiry of T(r), the receives an ASPAC from an ASP in the AS before expiry of T(r), the
buffered traffic is directed to the ASP and the timer is cancelled. buffered traffic is directed to the ASP and the timer is cancelled.
If T(r) expires, the AS is moved to the "Down" state.
4.3.3.6 Notify 4.3.3.6 Notify
A Notify message reflecting a change in the AS state is sent to all A Notify message reflecting a change in the AS state is sent to all
ASPs in the AS, except those in the "Down" state, with appropriate ASPs in the AS, except those in the "Down" state, with appropriate
Status Identification. Status Identification.
In the case where a Notify (AS-Pending) message is sent by an SG In the case where a Notify (AS-Pending) message is sent by an SG
that now has no ASPs active to service the traffic, the Notify does that now has no ASPs active to service the traffic, the Notify does
not explicitly force the ASP(s) receiving the message to become not explicitly force the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) action is active. The ASPs remain in control of what (and when) action is
taken. taken.
4.3.3.6 Heartbeat
The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than the
SCTP).
After receiving an ASP Up Ack message from the SG in response to an
ASP Up message, the ASP MAY optionally send Beat messages periodically,
subject to a provisionable timer T(beat). The SG M2UA, upon receiving
a BEAT message from the ASP, responds with a BEAT ACK message. If no
BEAT message (or any other M2UA message) is received from the ASP
within the timer 2*T(beat), the SG will consider the remote M2UA as
"Down". The SG will also send an ASP Down Ack message to the ASP.
At the ASP, if no BEAT ACK message (or any other M2UA message) is
received from the SG within 2*T(beat), the SG is considered
unavailable. Transmission of BEAT messages is stopped and ASP Up
procedures are used to re-establish communication with the SG M2UA
peer.
The BEAT message MAY optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Beat
Ack message. The ASP upon examining the contents of the returned
BEAT Ack message MAY choose to consider the remote ASP as
unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original
sender. The contents MAY be used, for example, to support a
Heartbeat sequence algorithm (to detect missing Heartbeats), and/or
a timestamp mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 4 "ASP state
transition diagram".
5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures
5.1 Establishment of associations between SG and MGC examples 5.1 Establishment of associations between SG and MGC examples
5.1.1 Single ASP in an Application Server (1+0 sparing) 5.1.1 Single ASP in an Application Server (1+0 sparing)
This scenario shows the example M2UA message flows for the establishment This scenario shows the example M2UA message flows for the establishment
of traffic between an SG and an ASP, where only one ASP is configured of traffic between an SG and an ASP, where only one ASP is configured
within an AS (no backup). It is assumed that the SCTP association is within an AS (no backup). It is assumed that the SCTP association is
already set-up. already set-up.
skipping to change at page 24, line 256 skipping to change at page 24, line 248
|--------ASP Up Ack------->| |--------ASP Up Ack------->|
| | | |
|<-------ASP Active--------| |<-------ASP Active--------|
|------ASP_Active Ack----->| |------ASP_Active Ack----->|
| | | |
5.1.2 Two ASPs in Application Server (1+1 sparing) 5.1.2 Two ASPs in Application Server (1+1 sparing)
This scenario shows the example M2UA message flows for the establishment This scenario shows the example M2UA message flows for the establishment
of traffic between an SG and two ASPs in the same Application Server, of traffic between an SG and two ASPs in the same Application Server,
where ASP1 is configured to be čactive¸ and ASP2 a standby in the event where ASP1 is configured to be active and ASP2 to be standby in the event
of communication failure or the withdrawal from service of ASP1. ASP2 MAY of communication failure or the withdrawal from service of ASP1. ASP2 MAY
act as a hot, warm, or cold standby depending on the extent to which ASP1 act as a hot, warm, or cold standby depending on the extent to which ASP1
and ASP2 share call/transaction state or can communicate call state under and ASP2 share call/transaction state or can communicate call state under
failure/withdrawal events. failure/withdrawal events.
SG ASP1 ASP2 SG ASP1 ASP2
| | | | | |
|<--------ASP Up----------| | |<--------ASP Up----------| |
|-------ASP Up Ack------->| | |-------ASP Up Ack------->| |
| | | | | |
skipping to change at page 24, line 296 skipping to change at page 24, line 288
|--------------------NTFY(AS-Down) (Optional)------->| |--------------------NTFY(AS-Down) (Optional)------->|
| | | | | |
|<------------------------------ ASP Active----------| |<------------------------------ ASP Active----------|
|-----------------------------ASP-Active Ack)------->| |-----------------------------ASP-Active Ack)------->|
| | | |
In this case, the SG notifies ASP2 that the AS has moved to the In this case, the SG notifies ASP2 that the AS has moved to the
Down state. The SG could have also (optionally) sent a Notify Down state. The SG could have also (optionally) sent a Notify
message when the AS moved to the Pending state. message when the AS moved to the Pending state.
Note: If the SG detects loss of the M2UA peer (M2UA heartbeat loss or Note: If the SG detects loss of the M2UA peer (through a detection
detection of SCTP failure), the initial SG-ASP1 ASP Inactive message of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange
exchange would not occur. would not occur.
5.2.2 (1+1 Sparing, Back-up Over-ride) 5.2.2 (1+1 Sparing, Back-up Over-ride)
Following on from the example in Section 5.1.2, and ASP2 wishes to over- Following on from the example in Section 5.1.2, and ASP2 wishes to over-
ride ASP1 and take over the traffic: ride ASP1 and take over the traffic:
SG ASP1 ASP2 SG ASP1 ASP2
| | | | | |
|<------------------------------ ASP Active----------| |<------------------------------ ASP Active----------|
|-----------------------------ASP-Active Ack-------->| |-----------------------------ASP-Active Ack-------->|
skipping to change at page 31, line 7 skipping to change at page 31, line 7
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG 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 Link Congestion
The SG can indicate that a link has become congested. It uses the State The SG can indicate that a link has become congested. It uses the
Indication message as shown below. Congestion Indication message as shown below.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG ASP ASP
----Cong Ind---->|--State Ind (EVENT_CONG_ENTER)->|----Cong Ind----> ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind---->
-Cong Cease Ind->|--State Ind (EVENT_CONG_EXIT)-->|-Cong Cease Ind-> -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind->
5.3.6 SS7 Link Changeover 5.3.6 SS7 Link Changeover
An example of the message flow for an error free changeover is shown An example of the message flow for an error free changeover is shown
below. In this example, there were three messages in the retransmission below. In this example, there were three messages in the retransmission
queue that needed to be retrieved. queue that needed to be retrieved.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG ASP ASP
skipping to change at page 31, line 103 skipping to change at page 31, line 103
The following message flow shows a request to continue. The following message flow shows a request to continue.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG ASP ASP
<---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req---
----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm-->
5.3.8 Auditing of SS7 link state
It may be necessary for the ASP to audit the current state of a SS7 link.
The flows below show an example of the request and all the potential
responses.
Below is an example in which the SS7 link is out-of-service.
MTP2 M2UA M2UA MGMT
SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->|
MTP3
ASP
|-----------Release Ind---------->|-Out of Serv Ind ->
Below is an example in which the SS7 link is in-service.
MTP2 M2UA M2UA MGMT
SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->|
MTP3
ASP
|-----------Establish Cfm-------->|---In Serv Ind -->
Below is an example in which the SS7 link is in-service, but congested.
MTP2 M2UA M2UA MGMT
SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->|
MTP3
ASP
|-----------Establish Ind-------->|---In Serv Ind -->
|----------Congestion Ind-------->|---Cong Ind ----->
Below is an example in which the SS7 link is in-service, but in Remote
Processor Outage.
MTP2 M2UA M2UA MGMT
SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->|
MTP3
ASP
|-----------Establish Ind-------->|---In Serv Ind -->
|---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter --->
6.0 Security 6.0 Security
M2UA is designed to carry signaling messages for telephony services. As such, M2UA is designed to carry signaling messages for telephony services. As such,
M2UA MUST involve the security needs of several parties: the end users M2UA MUST involve the security needs of several parties: the end users
of the services; the network providers and the applications involved. of the services; the network providers and the applications involved.
Additional requirements MAY come from local regulation. While having some Additional requirements MAY come from local regulation. While having some
overlapping security needs, any security solution SHOULD fulfill all of the overlapping security needs, any security solution SHOULD fulfill all of the
different parties' needs. different parties' needs.
6.1 Threats 6.1 Threats
skipping to change at page 31, line 131 skipping to change at page 31, line 198
M2UA runs on top of SCTP. SCTP [5] provides certain transport related M2UA runs on top of SCTP. SCTP [5] provides certain transport related
security features, such as: security features, such as:
* Blind Denial of Service Attacks * Blind Denial of Service Attacks
* Flooding * Flooding
* Masquerade * Masquerade
* Improper Monopolization of Services * Improper Monopolization of Services
When M2UA is running in professionally managed corporate or service When M2UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network includes provider network, it is reasonable to expect that this network includes
an appropriate security policy framework. The "Site Security Handbook" [9] an appropriate security policy framework. The "Site Security Handbook"
SHOULD be consulted for guidance. [10] SHOULD be consulted for guidance.
When the network in which M2UA runs in involves more than one party, it When the network in which M2UA runs in involves more than one party, it
MAY NOT be reasonable to expect that all parties have implemented security MAY NOT be reasonable to expect that all parties have implemented security
in a sufficient manner. In such a case, it is recommended that IPSEC is in a sufficient manner. In such a case, it is recommended that IPSEC is
used to ensure confidentiality of user payload. Consult [10] for more used to ensure confidentiality of user payload. Consult [11] for more
information on configuring IPSEC services. information on configuring IPSEC services.
6.2 Protecting Confidentiality 6.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality MAY Particularly for mobile users, the requirement for confidentiality MAY
include the masking of IP addresses and ports. In this case application include the masking of IP addresses and ports. In this case application
level encryption is not sufficient; IPSEC ESP SHOULD be used instead. level encryption is not sufficient; IPSEC ESP SHOULD be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP Regardless of which level performs the encryption, the IPSEC ISAKMP
service SHOULD be used for key management. service SHOULD be used for key management.
skipping to change at page 33, line 30 skipping to change at page 33, line 30
[6] Architectural Framework for Signaling Transport, RFC 2719, [6] Architectural Framework for Signaling Transport, RFC 2719,
October 1999 October 1999
[7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February
1995 1995
[8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T functions and messages using the services of ITU-T
Recommendation Q.2140', August 1995 Recommendation Q.2140', August 1995
[9] Site Security Handbook, RFC 2196, September 1997 [9] ITU-T Recommendation Q.751.1, 'Network Element Management Information
Model for the Messsage Transfer Part', October 1995
[10] Security Architecture for the Internet Protocol, RFC 2401
10.0 Issues To Be Addressed
1. SCTP failure (what does M2UA on SG and MGC do)
2. SCTP congestion (what does M2UA on SG and MGC do)
3. PRI/LI octet for TTC
4. auditing of link state
5. M2UA loses connectivity with MTP2 on SG
a. autonomously sends LPO to MTP3, or
b. sends LPO to MTP3 in response to Release Req (Stop) [10] Site Security Handbook, RFC 2196, September 1997
6. How to indicate failure to perform State Request [11] Security Architecture for the Internet Protocol, RFC 2401
(vs. current method of not sending State Confirm)
7. Use of "high priority" stream for link state [12] draft-stewart-srwnd-sctp-sigtran-01.txt, SCTP Stream Based Flow
messages (i.e. congestion) Control, November 2000
9. Adding text for T(ack) timer for ASP UP message 10.0 Issues To Be Addressed
9. Response in reply to Indication messages? 1. SCTP congestion (what does M2UA on SG and MGC do)
10.0 Author's Addresses 10.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Ram Dantu, Ph.D. Tel +1-469-255-0716 Ram Dantu, Ph.D. Tel +1-469-255-0716
Cisco Systems EMail rdantu@cisco.com Cisco Systems EMail rdantu@cisco.com
17919 Waterview 17919 Waterview
Dallas, TX 75252 Dallas, TX 75252
USA USA
Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: kalla@research.telcordia.com
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA
Greg Sidebottom Tel: +1-613-763-7305 Greg Sidebottom Tel: +1-613-763-7305
Nortel Networks EMail: gregside@nortelnetworks.com Nortel Networks EMail: gregside@nortelnetworks.com
3685 Richmond Rd, 3685 Richmond Rd,
Nepean, Ontario Nepean, Ontario
Canada K2H5B7 Canada K2H5B7
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
Brian Bidulock Tel +1-972-839-4489
OpenSS7 Project EMail: bidulock@openss7.org
c/o #424, 4701 Preston Park Blvd.
Dallas, TX 75093
USA
Jacob Heitz Tek +1-510-747-2917
Lucent Technologies Email: jheitz@lucent.com
1701 Harbor Bay Parkway
Alameda, CA, 94502
USA USA
This Internet Draft expires April 2001. This Internet Draft expires April 2001.
 End of changes. 

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