SCTP).
Either IUA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer T(beat). Upon receiving a Heartbeat
message, the IUA peer MUST respond with a Heartbeat Ack message.
If no Heartbeat Ack message (or any other IUA message) is received
from the IUA peer within 2*T(beat), the remote IUA peer is considered
unavailable. Transmission of Heartbeat messages is stopped and the
signaling process SHOULD attempt to re-establish communication if it
is configured as the client for the disconnected IUA 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 6, "ASP State
Transition Diagram".
5. Examples
5.1. Establishment of Association and Traffic between SGs and ASPs
5.1.1. Single ASP in an Application Server (1+0 sparing)
This scenario shows the example IUA message flows for the
establishment 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 already setup.
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |
5.1.2. Two ASPs in Application Server (1+1 sparing)
This scenario shows the example IUA message flows for the
establishment 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 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 and ASP2 share call state or
can communicate call state under failure/withdrawal events. The
example message flow is the same whether the ASP Active messages are
Over-ride or Load-share mode although typically this example would
use an Over-ride mode.
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
5.1.3. Two ASPs in an Application Server (1+1 sparing, load-sharing
case)
This scenario shows a similar case to Section 5.1.2 but where the two
ASPs are brought to active and load-share the traffic load. In this
case, one ASP is sufficient to handle the total traffic load.
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
5.1.4. Three ASPs in an Application Server (n+k sparing, load-sharing
case)
This scenario shows the example IUA message flows for the
establishment of traffic between an SG and three ASPs in the same
Application Server, where two of the ASPs are brought to active and
share the load. In this case, a minimum of two ASPs are required to
handle the total traffic load (2+1 sparing).
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
| | | |
|<--------------------------ASP Up-------| |
|-----------------------ASP Up Ack------>| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|
5.1.5. Interface Identifier Configuration Mismatch Example
This scenario shows the example IUA message flows for the
establishment of traffic between an SG and an ASP in which some of
the Interface Identifiers have been misconfigured on the ASP side.
The SG in this case has Interface Identifiers 1-5 configured for
ASP1.
SG ASP1
| |
| |
|<----ASP Active (IIDs 1-10)-----|
|---ASP Active Ack (IIDs 1-5)--->|
|-------Error (IIDs 6)---------->|
|-------Error (IIDs 7)---------->|
|-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->|
| |
5.2. ASP Traffic Fail-over Examples
5.2.1. (1+1 Sparing, withdrawal of ASP, Backup Over-ride)
The following example shows a case in which an ASP withdraws from
service:
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
| | |
|----NTFY(AS-Pending)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| | |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|
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 message
when the AS moved to the Pending state.
Note: If the SG detects loss of the IUA peer (IUA heartbeat loss or
detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
exchange would not occur.
5.2.2. (1+1 Sparing, Backup Over-ride)
The following example shows a case in which ASP2 wishes to override
ASP1 and take over the traffic:
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |
In this case, the SG notifies ASP1 that an alternative ASP has
overridden it.
5.2.3. (n+k Sparing, Load-sharing case, withdrawal of ASP)
Following on from the example in Section 5.1.4, and ASP1 withdraws
from service:
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
In this case, the SG has knowledge of the minimum ASP resources
required (implementation dependent), for example, if the SG knows
that n+k = 2+1 for a load-share AS and n currently equals 1.
Note: If the SG detects loss of the ASP1 IUA peer (IUA heartbeat
loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive
message exchange would not occur.
5.3. Q.921/Q.931 Primitives Backhaul Examples
When the IUA layer on the ASP has a QPTM message to send to the SG,
it will do the following:
- Determine the correct SG
- Find the SCTP association to the chosen SG
- Determine the correct stream in the SCTP association based on
the D channel
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- Send the QPTM message to the remote IUA peer in the SG, over
the SCTP association
When the IUA layer on the SG has a QPTM message to send to the ASP,
it will do the following:
- Determine the AS for the Interface Identifier
- Determine the Active ASP (SCTP association) within the AS
- Determine the correct stream in the SCTP association based on
the D channel
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- Send the QPTM message to the remote IUA peer in the ASP, over
the SCTP association
An example of the message flows for establishing a data link on a
signaling channel, passing PDUs and releasing a data link on a
signaling channel is shown below. An active association between MGC
and SG is established (Section 5.1) prior to the following message
flows.
SG ASP
<----------- Establish Request
Establish Confirm ---------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
<----------- Data Request
Data Indication ----------->
<----------- Release Request (RELEASE_MGMT)
Release Confirm ---------->
An example of the message flows for a failed attempt to establish a
data link on the signaling channel is shown below. In this case, the
gateway has a problem with its physical connection (e.g., Red Alarm),
so it cannot establish a data link on the signaling channel.
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)
5.4. Layer Management Communication Examples
An example of the message flows for communication between Layer
Management modules between SG and ASP is shown below. An active
association between ASP and SG is established (Section 5.1) prior to
the following message flows.
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
6. Security
The security considerations discussed in "Security Considerations for
SIGTRAN Protocols", RFC 3788 [3], apply to this document.
7. IANA Considerations
7.1. SCTP Payload Protocol Identifier
The IANA has assigned an IUA value for the Payload Protocol
Identifier in SCTP Payload Data chunk. The following SCTP Payload
Protocol Identifier has been registered:
IUA "1"
The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but MAY be used by
certain network entities to identify the type of information being
carried in a Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being
presented to it by SCTP.
7.2. IUA Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types, and parameters
are an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [7].
The proposed extension must in no way adversely affect the general
working of the protocol.
7.2.1. IETF-Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class.
7.2.2. IETF-Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.