INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT
Internet Draft Matt Holdrege
Aug 1998 Ascend Communications
Jiri Matousek
Lyndon Ong
Bay Networks
Reliable Signaling Gateway Protocol (RSGP)
<draft-ong-rsgp-ss7-info-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstract.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net, ftp.nis.garr.it
(Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast),
or ftp.isi.edu (US West Coast).
Abstract
This memo describes a combined message set and function set for the
Control Protocol used between a Network Access Server (NAS) and a
Signaling Gateway (SG), based on the ASP and RSGCP drafts previously
submitted [asp, rsgcp]. The Control Protocol supports Call Control,
Circuit Maintenance and Resource Management.
Table of Contents
1. Overview.................................................1
2. Bearer Services..........................................2
3. Messages and Coding......................................3
4. Protocol Procedures......................................9
5. Detailed Procedures.....................................15
6. Transport...............................................16
7. Security Considerations.................................16
8. Message Flow Examples...................................16
9. Acronyms................................................21
10. Authors' Contact Information............................22
11. References..............................................22
1.0 Overview
This document defines a protocol for interface between a Signaling
Gateway (SG) and Network Access Server (NAS), which serves to
integrate Internet access and the Public Switched Telephone Network
(PSTN) using Signaling System 7 (SS7).
The SG has two fundamental interfaces. One is to the SS7 network
speaking standard SS7 protocols as defined in the ITU-T Q.700 series.
RSGP [Page 1]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
The other interface is TCP/IP speaking to the SG's defined NAS
population. This document describes the protocol that is carried
between the SG and the NAS.
Since there is no existing protocol that fits the requirements
completely, a new protocol has been derived from the ITU-T protocol
Q.931. Q.931 has the following advantages:
-- it is a very reliable protocol that has been used for many years
for ISDN call control, and is used for call control in H.323
-- Q.931 has well defined procedures and a message set that is
extensible to allow additional functionality to be added easily.
-- Q.931 has already been incorporated into NAS's to support ISDN,
minimizing the modifications required to implement a new Control
Protocol. A subset is also used in H.323 for call setup between
voice or multimedia over IP systems.
The following diagram shows the use of the SS7 Gateway and the RSGP
for interworking of SS7 and Internet.
........................ ......
. . .
. +------+ . . +-------+
. SS7 | / | . SS7 . | SS7 |
. Network | STP |------------|Gateway|
. /| / | . . +-------+
. / +------+ . . |
.........../.../........ . R|
/ / . S| I
__________ / / A-link . G| n
/ / . P| t
/ / . | e
+------+ +------+ . +-----+ r
| PSTN | | PSTN |-----TDM---------------| NAS |-------n
| SCP | |Switch|-----------------------| |Data e
+------+ +------+ Circuits . +-----+ t
.
.
Figure 1: SS7-Internet Interworking for Call Setup
It is assumed that the implementer has access to the Q.931 protocol
specification as well as an understanding of SS7 messages.
2.0 Bearer Services
The following describes the bearer services and interface configura-
tions that are supported from the Q.931 specification.
Bearer Services
Four (4) bearer services are supported in the Control Protocol:
1. Circuit Mode, 64-kbps, 8-khz structured, Speech
2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio
3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital
Transmission-Rate Adapted from 56-kbps
4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital
Transmission
RSGP [Page 2]
INTERNET DRAFT Reliable Signaling Gateway Control Protocol July 1998
Circuit Mode, 64-kbps, 8-khz structured, Speech The speech present at
the inter-machine trunk is coded by the standardized Mu-law or a-law
pulse code modulation (PCM) technique specified by CCITT
Recommendation G.711.
Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio The 3.1-khz
audio signal present at the inter-machine trunk is coded by the
standardized Mu-law or a-law PCM technique specified by CCITT
Recommendation G.711.
Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital
Transmission-Rate Adapted from 56-kbps An information transfer rate
of 56-kbps over a B channel is possible by rate adapting the user
data rate of 56-kbps to 64-kbps. The transmitting side shall set bit
eight (8) of each byte on the B-channel to a binary one, while the
other bits are populated from the 56 kbps data stream. Conversely,
the receiving side shall ignore the eighth bit of each byte.
Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital
Transmission This bearer service is used to originate and terminate
circuit-mode data calls at 64-kbps.
Interface Configuration: The Control Protocol is considered non-
facility associated signaling, where the signaling for specific B-
channels occur over a different physical facility. The bearer
channels are carried over inter machine trunks which are connected
between NAS units and central office exchanges. The control channel
is carried over an IP network.
3. Messages and Coding
3.1 Message Set
This section defines the messages the SG and NAS use for call
processing, maintenance, and management. Messages for call processing
are based on the ITU-T Recommendation Q.931 message set, and in most
cases use the standard Q.931 information elements and codings.
The call processing message set consists of:
Function Message Value
setup confirm CONNECT 0x07
optional CONNECT ACKNOWLEDGE 0x0f
optional DISCONNECT 0x45
release request RELEASE 0x4d
release confirm RELEASE COMPLETE 0x5a
call reset request RESTART 0x46
call reset confirm RESTART ACKNOWLEDGE 0x4e
setup request SETUP 0x05
status confirm STATUS 0x7d
status request STATUS ENQUIRY 0x73
data request/confirm FACILITY 0x62
The following messages are required for supporting voice connections,
in addition to connections for remote access:
call progress ALERTING 0x01
tones and announcements PROGRESS 0x03
RSGP [Page 3]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
New messages have been added to support registration and resource
management functions between the SG and NAS. These messages are
sent with Protocol Discriminator set to 0x43 (Maintenance). The new
messages are as follows:
Function Message Value
initialize request NAS STATUS 0x7f
initialize confirm NAS STATUS ACKNOWLEDGE 0x7f
continuity result CONTINUITY 0x11
result confirm CONTINUITY ACKNOWLEDGE 0x13
resource register req RESOURCE STATUS 0x1f
resource register conf RESOURCE STATUS ACKNOWLEDGE 0x17
action request SERVICE 0x0f
action confirm SERVICE ACKNOWLEDGE 0x07
3.2 Message Contents
Contents of standard Q.931 call control messages used in RSGP are
not shown in this document for brevity. The contents are a subset
of those used in the ITU-T Recommendation Q.931 specification.
The locking shift procedure of Q.931 is used with new information
elements in order to indicate an information element not defined in
ITU-T Recommendation Q.931.
3.2.1 CONTINUITY
The CONTINUITY message shall be formatted as shown:
Information Element Direction Inclusion Condition Length
Protocol Discriminator NAS -> SG Mandatory 1
Call Reference NAS -> SG Mandatory 3
Message Type NAS -> SG Mandatory 1
Channel Identification NAS -> SG Mandatory 4-*
Locking Shift (codeset 7) NAS -> SG Mandatory 1
Continuity Indicator NAS -> SG Mandatory 3
The CONTINUITY message is used by the NAS to indicate the outcome of
a continuity test.
3.2.2 CONTINUITY ACKNOWLEDGE
Information Element Direction Inclusion Condition Length
Protocol Discriminator SG -> NAS Mandatory 1
Call Reference SG -> NAS Mandatory 3
Message Type SG -> NAS Mandatory 1
Channel Identification SG -> NAS Mandatory 4-*
RSGP [Page 4]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
The CONTINUITY ACKNOWLEDGE message is used by the SG to acknowledge
the receipt of a CONTINUITY message from the NAS.
3.2.3 RESOURCE STATUS
The RESOURCE STATUS message shall be formatted as shown below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminator NAS -> SG Mandatory 1
Call Reference NAS -> SG Mandatory 3
Message Type NAS -> SG Mandatory 1
Locking Shift (codeset 7) NAS -> SG Mandatory 1
Interface Status NAS -> SG Optional 7+
Resource NAS -> SG Optional 7+
The RESOURCE STATUS message is sent by the NAS to register associated
interface and user port resources with the SG.
3.2.4 RESOURCE STATUS ACKNOWLEDGE
The RESOURCE STATUS ACKNOWLEDGE message shall be formatted as shown
below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminators SG -> NAS Mandatory 1
Call Reference SG -> NAS Mandatory 3
Message Type SG -> NAS Mandatory 1
The RESOURCE STATUS ACKNOWLEDGE message is sent by the SG to acknowledge
confirmation of a resource registration. The RESOURCE STATUS ACKNOWLEDGE
message is not part of the basic Q.931 message set.
3.2.5 SERVICE
The SERVICE message shall be formatted as shown below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminator BOTH Mandatory 1
Call Reference BOTH Mandatory 3
Message Type BOTH Mandatory 1
Channel Identification BOTH Mandatory 4-*
Locking Shift (codeset 7) BOTH Mandatory 1
Change Status BOTH Mandatory 3
RSGP [Page 5]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
The SERVICE message is sent by the SG or to request a change in interface
or channel status.
3.2.6 SERVICE ACKNOWLEDGE
The SERVICE ACKNOWLEDGE message shall be formatted as shown below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminator BOTH Mandatory 1
Call Reference BOTH Mandatory 3
Message Type BOTH Mandatory 1
Channel Identification BOTH Mandatory 4-*
Locking Shift (codeset 7) BOTH Mandatory 1
Change Status BOTH Mandatory 3
The SERVICE ACKNOWLEDGE message is sent by either the SG or the NAS
to indicate that the state of the specified interface or channel has
been changed.
The Change Status and Channel Identification IE's should be
equivalent to the corresponding values sent in the SERVICE Message.
3.2.7 NAS STATUS
The NAS STATUS message shall be formatted as shown below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminator BOTH Mandatory 1
Call Reference BOTH Mandatory 3
Message Type BOTH Mandatory 1
Locking Shift (codeset 7) BOTH Mandatory 1
NAS Status BOTH Mandatory 3
The NAS STATUS message is used to notify the remote end of a change in
status, such as NAS logon from a cold start, or NAS shutdown. The
receiving end replies with NAS STATUS ACKNOWLEDGE.
RSGP [Page 6]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
3.2.8 NAS STATUS ACKNOWLEDGE
The NAS STATUS ACKNOWLEDGE message shall be formatted as shown below:
Information Element Direction Inclusion Cond. Length
Protocol Discriminator BOTH Mandatory 1
Call Reference BOTH Mandatory 3
Message Type BOTH Mandatory 1
Cause BOTH Mandatory 1
The NAS STATUS ACKNOWLEDGE message is sent to confirm receiving
the NAS STATUS message.
3.3 Information Element Coding
Information Elements unchanged from ITU-T Q.931 are not re-
defined here for brevity.
The following new Information Elements are defined:
Information Element IE Identifier
Change Status 05
Continuity Indicator 07
Interface Status 04
NAS Status 02
Resource 03
The following existing Information Elements have additional
codepoints allocated:
Cause
3.3.1 Change Status
The format of the Change Status information element is as follows:
+---+---------------------------+
| 0 | 0 0 0 0 1 0 1 | IE Identifier
+---+---------------------------+
| Information Element Length |
+---+---------------+-----------+
| 1 | 0 0 0 0 | Status |
+---+---------------+-----------+
Status:
000 In Service
001 Loop Back
010 Out of Service
011 Request Continuity Check
100 Graceful Shutdown
else spare
RSGP [Page 7]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
3.3.2 Continuity Indicator
The format of the Continuity Indicator information element is as follows:
+---+---------------------------+
| 0 | 0 0 0 0 1 1 1 | IE Identifier
+---+---------------------------+
| Information Element Length |
+---+-----------------------+---+
| 1 | 0 0 0 0 0 0 | C |
+---+-----------------------+---+
C: Continuity Result
0 Continuity Check failed
1 Continuity Check successful
3.3.3 Interface Status
The format of the Resource information element is as follows:
+---+---------------------------+
| 0 | 0 0 0 0 1 0 0 | IE Identifier
+---+---------------------------+
| Information Element Length |
+---+---------------------------+
| 1 | Interface |
+---+-------------------+-------+
| 1 | 0 0 0 0 0 | State |
+---+-------------------+-------+
| 1 | Channel Count |
+---+-----------+---------------+
| Chan 1 State | Chan 2 State |
+---------------+---------------+
| Chan 3 State | Chan 4 State |
+---------------+---------------+
Interface:
Binary Interface number
State:
00 reserved
01 Maintenance (loopback)
10 Out of service (down)
11 In service (up)
Channel Count:
Binary count of channels supported by this interface
Channel State:
0000 Reserved/Filler
0001 Unavailable - blocked
0010 Call in progress
0011 Idle - no existing calls
other spare
RSGP [Page 8]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
3.3.4 NAS Status
The format of the NAS Status information element is as follows:
+---+---------------------------+
| 0 | 0 0 0 0 0 1 0 | IE Identifier
+---+---------------------------+
| Information Element Length |
+---+-------------------+-------+
| 1 | 0 0 0 0 0 | State |
+---+-------------------+-------+
State:
00 Cold start: NAS reboot
01 Warm start: NAS reestablishing connectivity to SG
10 Hot shutdown: NAS will disconnect abruptly, terminate all calls
11 Soft shutdown: NAS will shutdown when all calls have terminated
3.3.5 Resource
The format of the Resource information element is as follows:
+---+---------------------------+
| 0 | 0 0 0 0 0 1 1 | IE Identifier
+---+---------------------------+
| Information Element Length |
+---+-----------+---------------+
| 1 | Category | State |
+---+-----------+---------------+
| 1 | Capacity |
+---+---------------------------+
Category:
001 Modems
010 HDLC Channels
other spare
State:
0001 Available
other spare
Capacity:
Binary count of resources
3.3.6 Cause
The following new Cause information element codings are included:
125 NAS registered for calls
126 NAS registered for incoming and outgoing calls
127 NAS registration rejected
4. Protocol Procedures
This section describes the protocol procedures required for call
processing and resource management in RSGP.
RSGP [Page 9]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
Timers are defined in ITU-T Q.931 and are not re-defined here for
brevity.
4.1 Call Scenarios
The call scenarios defined in this section provide examples of the
main procedures used in the protocol, but do not describe all possible
cases. For more detailed information, see ITU-T Recommendation Q.699.
4.1.1 Network Initiated Call Origination
4.1.1.1 IAM Initiated with No COT Required
This scenario describes the signaling that proceeds when a call is
initiated by the reception of an IAM from the SS7 network and a
continuity test is not required.
* When the SG receives an IAM from the SS7 network, the Nature of
Connection indicators shall be examined to determine if COT is
required on the specified circuit. If COT is not required, the SG
shall send a SETUP message to the NAS.
* Once the NAS has determined that the call can be completed and the
specified channel has been connected to the called party, it shall
send a CONNECT message to the SG.
* Upon receipt of the CONNECT message, the SG shall send an ANM
message to the SS7 network, and may optionally send a CONNECT ACK-
NOWLEDGE message to the NAS.
4.1.1.2 IAM Initiated with Continuity Check Required
This scenario describes the signaling that proceeds when a call is
initiated by the reception of an IAM from the SS7 network and a
continuity test is required.
* When the SG receives an IAM from the SS7 network, the Nature of
Connection indicators shall be examined to determine if COT is
required on the specified circuit. If COT is required, the SG shall
send a SERVICE message to the NAS indicating that the specified
circuit should be placed in a loopback mode, and start timer Tserv.
* When the NAS receives the SERVICE message indicating the specified
circuit should be placed in loopback mode, the circuit shall be
marked as busy, placed in a loopback mode, and a SERVICE ACKNOWLEDGE
message indicating the circuit was successful placed in a loopback
mode, shall be sent to the SG.
* When the SG receives the SERVICE ACKNOWLEDGE message indicating the
circuit was successfully placed in a loopback mode, timer Tserv shall
be stopped.
* When the SG receives a COT message from the SS7 network indicating
the continuity test was successful, the SG shall send a SETUP message
to the NAS.
RSGP [Page 10]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
* Once the NAS has determined that the call can be completed and the
specified channel has been connected to the called party, it shall
send a CONNECT message to the SG.
* Upon receipt of the CONNECT message, the SG shall send an ANM
message to the SS7 network, and may optionally send a CONNECT ACK-
NOWLEDGE message to the NAS.
4.1.1.3 IAM Initiated with Continuity Check on Previous Circuit Required
This scenario describes the signaling that proceeds when a call is
initiated by the reception of an IAM from the SS7 network that
specifies a continuity test on a previous circuit is required.
* When the SG receives an IAM from the SS7 network, the Nature of
Connection indicators shall be examined to determine if continuity
check is required. If continuity check is required on a previous
circuit, then the SG does not send a SETUP message until a COT
is received indicating continuity check successful.
* Once the NAS has determined that the call can be completed and the
specified channel has been connected to the called party, it shall
send a CONNECT message to the SG. The NAS shall start timer T313 when
the CONNECT message is sent.
* Upon receipt of the CONNECT message, the SG shall send a CONNECT
ACKNOWLEDGE message to the NAS.
* Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop
timer T313.
4.1.2 Call Clearing
4.1.2.1 Network Initiated Call Clearing
This scenario describes the signaling that proceeds when a call
clearing is initiated by the SS7 network.
* Call clearing is initiated by the SS7 network when a REL is
received by the SG from the SS7 network. When the SG receives a REL
from the SS7 network, a corresponding RELEASE message shall be
sent to the NAS, and timer T308 shall be initiated.
* When the NAS receives a RELEASE message the associated circuit
shall be disconnected, and a RELEASE COMPLETE shall be sent to the SG.
* When the SG receives the RELEASE COMPLETE message timer T308 shall
be stopped, the channel shall be released, and the call reference
shall be released.
* The NAS shall also be capable of receiving a DISCONNECT message
from the SG, in which case the procedures in Section 4.1.2.2 are
followed.
4.1.2.2 NAS Initiated Call Clearing
This scenario describes the signaling that proceeds when a call
clearing is initiated by the NAS.
RSGP [Page 11]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
* When the NAS detects that an active call has been terminated by the
local subscriber, the NAS shall disconnect the associated circuit,
send a RELEASE message to the SG, and initiate timer T308.
* When the SG receives the RELEASE message, a RLS message shall be
sent out to the SS7 network, the circuit and call reference shall be
released, and a RELEASE COMPLETE shall be sent to the NAS.
* When the NAS receives the RELEASE COMPLETE message timer T308 shall
be stopped.
* The SG shall be capable of receiving a DISCONNECT message from the
NAS, in which case the procedures in section 4.1.2.1 are followed.
4.1.3 Call Failures and CCR
* message timer Tserv shall be stopped and a RLC shall be sent out to
the SS7 network.
4.1.3.1 IAM Initiated with Continuity Check on Previous Circuit Failed
This scenario describes the signaling that proceeds when a call is
initiated by the reception of an IAM from the SS7 network that
specifies a continuity test on a previous circuit is required and
consequently the continuity test fails.
* When the SG receives an IAM from the SS7 network, the Nature of
Connection indicators shall be examined to determine if COT is
required on the specified circuit, or on a previous circuit. If COT
is required on a previous circuit, the SG delays sending SETUP
out to the NAS.
* When the SG receives a REL message from the SS7 network, which
indicates the continuity test failed, the SG releases the circuit
and call without sending an indication to the NAS.
4.2 Management Procedures
4.2.1 Registration
This scenario describes the message flow that proceeds when a NAS
unit registers the available hardware interfaces.
* When the NAS detects that a resource has changed operational
states, a RESOURCE STATUS message is sent to the SG and Timer T350 shall
be initiated. Multiple RESOURCE STATUS messages may be send to carry
information about the interface status and resource status.
* When the SG receives the RESOURCE STATUS message, the indicated
resource states are updated and a RESOURCE STATUS ACKNOWLEDGE is
sent to the NAS. The Resource information elements in the
RESOURCE STATUS ACKNOWLEDGE must be identical to those received in
the original RESOURCE STATUS message.
* When the NAS receives the RESOURCE STATUS ACKNOWLEDGE message, timer
T350 shall be stopped.
RSGP [Page 12]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
4.2.2 Registration - T350 Timeout
This scenario describes the message flow that proceeds when a timeout
of Timer T350 occurs after the NAS has initiated registration of the
available hardware interfaces. It is important to note that the NAS
should continue to re-send the RESOURCE STATUS message and restart Timer
T350 until a corresponding RESOURCE STATUS ACKNOWLEDGE is received.
* When the NAS detects that a resource has changed operational
states, a RESOURCE STATUS message is sent to the SG and Timer T350 shall
be initiated.
* When Timer T350 expires on the NAS, the NAS shall re-send the
RESOURCE STATUS message and restart timer T350.
* When the SG receives the RESOURCE STATUS message, the indicated
resource states are updated and a RESOURCE STATUS ACKNOWLEDGE is
sent to the NAS.
* When the NAS receives the RESOURCE STATUS ACKNOWLEDGE message, timer
T350 shall be stopped.
4.2.3 SG Initiated Restart
This scenario describes the message flow that proceeds when a Restart
Request is initiated by the SG.
* When the SG initiates restart, it sends a RESTART message to the NAS and
timer T317 is initiated.
* When the NAS receives a RESTART message from the SG, the specified
interface or channel shall be restarted and a RESTART
ACKnowledgment shall be sent to the SG.
* When the SG Control Protocol receives a RESTART ACKNOWLEDGE from
the NAS, timer T317 shall be stopped.
4.2.4 NAS Initiated Restart
This scenario describes the message flow that proceeds when a RESTART
message is received by the SG Control Protocol from the NAS.
* If the NAS determines that a restart of a single DS0, or an entire
interface is necessary, a RESTART message shall be sent to the SG and
timer T317 shall be initiated.
* When the SG Control Protocol receives a RESTART message from the
NAS, a Restart Indication primitive shall be sent to the call control
and a RESTART ACKNOWLEDGE shall be sent to the NAS.
* When the NAS receives a RESTART ACKNOWLEDGE from the SG, timer
T317 shall be stopped, and the associated equipment shall be
restarted.
4.2.5 Service Message Procedures
RSGP [Page 13]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
The Service message is used to initiate circuit management procedures
at the NAS or Gateway for functions such as circuit blocking and loop
back (prior to remote continuity check). The procedures are as follows:
* When the SG or NAS initiates a Service procedure, it sends the Service
message and initiates timer Tserv.
* When the initiating SG or NAS receives the Service Acknowledge message,
timer Tserv is stopped.
* The following tables describe the detailed procedures for the NAS
in response to receipt of a Service message from the SG:
+------------+--------------------------+-------------------------+
| | Interface Specified | Channel Specified |
+------------+--------------------------+-------------------------+
| In Service | The NAS will attempt to | The NAS will mark the |
| | bring the T1/E1 into ser-| channel as available. |
| | vice. The NAS will | Established calls will |
| | respond with 'Out of | not be affected. |
| | Service' if the T1/E1 is | |
| | down (not framing). | |
+------------+--------------------------+-------------------------+
| Loop Back | The T1/E1 will be placed | The NAS will place the |
| | into loopback. All esta-| DS0 into loopback state |
| | blished calls will be | if there is no esta- |
| | torn down. | blished call. The NAS |
| | | will respond with 'In |
| | | Service' if a call is |
| | | in progress. |
+------------+--------------------------+-------------------------+
| Out of | The NAS will place the | The NAS will mark the |
| Service | T1/E1 into this state. | DS0 and tear down any |
| | All established calls | if there is no esta- |
| | will be torn down. | established calls. |
+------------+--------------------------+-------------------------+
| Request | The NAS will reject this | The NAS will execute the|
| Continuity | message and send STATUS | continuity check if |
| Check | message. | there is no established |
| | | call. The NAS will res-|
| | | pond with 'In Service' |
| | | if a call is in progress|
+------------+--------------------------+-------------------------+
| Graceful | The NAS will mark the | The NAS will mark the |
| Shutdown | T1/E1. It will not tear | DS0, but will not tear |
| (Blocking) | down any established | down any established |
| | calls. | calls. |
+------------+--------------------------+-------------------------+
* Upon completion of the action specified, the NAS responds to the SG
with a Service Acknowledge message.
RSGP [Page 14]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
* The following table describes the procedures at the SG upon receipt of
a Service message from the NAS:
+------------+--------------------------+-------------------------+
| | Interface Specified | Channel Specified |
+------------+--------------------------+-------------------------+
| In Service | The NAS will send this | The NAS can send this |
| | message when the T1/E1 | request for Channels it |
| | framing is achieved. The | previously took "Out of |
| | Gateway should not change| Service". The Gateway |
| | the state of any esta- | should not change the |
| | blished call. | state of any |
| | | established call. |
+------------+--------------------------+-------------------------+
| Loop Back | The NAS will not generate| The NAS will not gene- |
| | this request. The Gate- | rate this request. The |
| | way should respond with | Gateway should respond |
| | STATUS. | with STATUS. |
+------------+--------------------------+-------------------------+
| Out of | The NAS will place the | The NAS will send this |
| Service | T1/E1 into this state if | message in the case of |
| | T1/E1 framing is lost or | modem failure. Any |
| | if requested by the | established call will |
| | operator. All esta- | be torn down. |
| | blished calls will be | |
| | torn down. | |
+------------+--------------------------+-------------------------+
| Request | The NAS will not send | The NAS will use this |
| Continuity | this message. The Gate- | request as a result of |
| Check | way should respond with | an operator request. |
| | STATUS. | |
+------------+--------------------------+-------------------------+
| Graceful | The NAS will issue this | The NAS will not issue |
| Shutdown | request as a result of an| this message. The Gate-|
| (Blocking) | operator request. Any | way should reject this |
| | call in progress should | message using the |
| | not be affected. | STATUS message. |
+------------+--------------------------+-------------------------+
* Upon completion of the action specified, the SG responds to the NAS
with the Service Acknowledge message.
5. Detailed Procedures
This section provides detailed information that describes the
operation of the SG Control Protocol. A call progresses through
different states as various events occur, and this section describes
how the SG and NAS should process calls in each state. The table
below shows the call states that apply to the SG Control Protocol.
State Name Value
Null 0
Call Initiated 1
Call Present 6
Connect Request 8
Active 10
Disconnect Request 11
Disconnect Indication 12
Release Request 19
RSGP [Page 15]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
Additional procedures to be provided.
6. Transport
Detailed procedures to be provided.
Additional procedures may be added, for example, in order to monitor
performance of the connection between NAS and SG, and initiate recovery
procedures if it is determined that the connection has failed.
7. Security Considerations
SS7 protocol does not support internal authentication and encryption
functions. This is taken into consideration in current SS7
networks. Signaling gateways should be designed to protect the SS7
network and should employ thoughtful thresholds to make sure a NAS or
malicious intermediate entity cannot adversely affect the SS7 network
or any SS7 connected nodes.
If the network operator wishes to add IP level security functions it is
recommended but not required that the TCP/IP link from the NAS to the SG
be protected by IPsec AH and ESP [RFC 1826, 1827]. In the case that
the physical network between the NAS and SG is private, such security
techniques are optional. In the case that the network used is
shared with other applications and/or nodes, IPsec security is
strongly recommended. This is to prevent Denial of Service attacks
and false message attacks.
8. Message Flow Examples
8.1 NAS Registers with Gateway for Service
The following timing diagram shows the message flow during initial
NAS registration with the SG.
NAS Gateway
| |
| NAS STATUS (cold start) |
|------------------------------>|
| NAS STATUS ACK |
|<------------------------------|
| |
| |
| RESOURCE STATUS |
|------------------------------>|
| RESOURCE STATUS ACK |
|<------------------------------|
Note: multiple Resource Statue messages may be sent and acknowledged.
RSGP [Page 16]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
8.2 Gateway Originated Normal Call Setup and Release
The following diagram shows successful Call establishment and tear
down for a gateway originated call.
NAS Gateway
| |
| SETUP (Channel ID = n) |
|<------------------------------|
| CONNECT |
|------------------------------>|
| |
| RELEASE |
|<------------------------------|
| RELEASE COMPLETE |
|------------------------------>|
Note: The tear down sequence can be initiated by either the NAS or
by the gateway to hang-up the call.
8.3 NAS Originated Normal Call Setup
The following diagram shows successful Call establishment and tear
down for NAS originated calls. For NAS originated calls, the Gateway
selects the channel to be used in the call.
NAS Gateway
| |
| SETUP(channel not specified) |
|------------------------------>|
| CONNECT ( Channel ID = n ) |
|<------------------------------|
| |
| RELEASE |
|<------------------------------|
| RELEASE COMPLETE |
|------------------------------>|
Note: The tear down sequence can be initiated by either the NAS or
by the gateway to hang-up the call. Disconnection can be initiated
by either the DISCONNECT or RELEASE message.
8.4 Unsuccessful Call Establishment Sequence
The following sequence illustrates when a call is rejected by the
NAS.
NAS Gateway
| |
| SETUP |
|<------------------------------|
| RELEASE COMPLETE |
|------------------------------>|
RSGP [Page 17]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
8.5 Continuity check test as part of Incoming Call Setup - Success
The following sequence illustrates when the gateway receives an IAM
message indicating that a continuity test should be performed on
the circuit prior to the call establishment.
NAS Gateway
| |
| SERVICE (chan n loop back) |
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
| |
| SETUP |
|<------------------------------|
| CONNECT |
|------------------------------>|
Per Q.699 (3.1.18) continuity checking should be performed before
the SETUP is sent to the terminating end-point. SERVICE message
from the gateway to the NAS is used to initiate the loopback. If
the remote end-point indicates to the gateway that the continuity
check succeeded, the gateway proceeds with SETUP.
8.6 Continuity check test as part of Incoming Call Setup - Failure
If the remote end indicates failure, the gateway will send SERVICE
message to the NAS requesting that the channel be placed into the
in-service state.
NAS Gateway
| |
| SERVICE (chan n loop back) |
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
| |
| SERVICE (chan n in-service) |
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
RSGP [Page 18]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
8.7 Continuity check test as part of Outgoing Call Setup - Success
The following sequence illustrates when the NAS initiates call
setup and the SS7 Gateway determines that continuity test should be
performed on the circuit prior to the call establishment.
NAS Gateway
| |
| SETUP (channel not specified) |
|------------------------------>|
| |
| SERVICE (chan n request |
| continuity check) |
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
| CONTINUITY |
|------------------------------>|
| CONTINUITY ACK |
|<------------------------------|
| |
| CONNECT (Channel ID = n) |
|<------------------------------|
8.8 Continuity check test initiated by the SG operator
The gateway sends a SERVICE message to initiate the continuity
check. The NAS performs continuity check and reports the result
using the CONTINUITY message.
Not shown in this diagram is the corresponding action of the SG.
Upon receipt of the Service Ack from the NAS, the SG generates a
CCR message into the SS7 network, initiating loopback at the
remote switch.
NAS Gateway
| |
| SERVICE (chan n request |
| continuity check) |
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
| |
| CONTINUITY |
|------------------------------>|
| CONTINUITY ACK |
|<------------------------------|
8.7 NAS detects bearer T1/E1 line down (LOS, Red Alarm)
If the NAS detects that a particular T1/E1 line failed, it sends a
SERVICE message to the gateway. Established calls will be torn down
as part of normal processing - i.e the NAS modems will detect loss
of connection and the NAS will disconnect the call. The gateway
will request blocking of CICs associated with the particular T1/E1
using an SS7 Blocking or Circuit Group Blocking Message.
RSGP [Page 19]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
NAS Gateway
| |
| SERVICE (i/f 1 out-of-service)|
|------------------------------>|
| SERVICE ACK |
|<------------------------------|
8.8 Individual bearer channel taken out-of-service by NAS
NAS Gateway
| |
| SERVICE(chan n out-of-service)|
|------------------------------>|
| SERVICE ACK |
|<------------------------------|
8.9 Individual bearer channel taken out-of-service by Gateway
operator
NAS Gateway
| |
| SERVICE(chan n out-of-service)|
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
8.10 Bearer T1/E1 trunk abrupt shutdown initiated by Gateway
operator
NAS Gateway
| |
| SERVICE (i/f n out-of-service)|
|<------------------------------|
| SERVICE ACK |
|------------------------------>|
8.11 Bearer T1/E1 trunk abrupt shutdown initiated by NAS
NAS Gateway
| |
| SERVICE (i/f n out-of-service)|
|------------------------------>|
| SERVICE ACK |
|<------------------------------|
8.12 Bearer T1/E1 trunk graceful shutdown initiated by Gateway
operator
NAS Gateway
| |
| SERVICE (i/f n graceful shutdown) |
|<----------------------------------|
| SERVICE ACK |
|---------------------------------->|
RSGP [Page 20]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
8.13 Bearer T1/E1 trunk graceful shutdown initiated by NAS
NAS Gateway
| |
| SERVICE (i/f n graceful shutdown) |
|---------------------------------->|
| SERVICE ACK |
|<----------------------------------|
9. Acronyms
ANM Answer Message
SG Signaling Gateway
CCR Continuity Check Request
COT Continuity
CPE Customer Premises Equipment
IAM Initial Address Message
IE Information Element
IP Internet Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ISUP ISDN User Part
MTP Message Transfer Part
NAS Network Access Server
PCM Pulse Code Modulation
PSTN Public Switched Telephone Network
SCP Service Control Point
STP Signal Transfer Point
SS7 Signaling System Number 7
UL Upper Layer
RSGP [Page 21]
INTERNET DRAFT Reliable Signaling Gateway Protocol July 1998
10. Authors Addresses
Matt Holdrege Lyndon Ong Jiri Matousek
1701 Harbor Bay Pkwy 4401 Gt America Pkwy 5 Federal Street
Alameda, CA 94502 Santa Clara, CA 95054 Billerica, MA 01821
matt@ascend.com long@baynetworks.com jiri@baynetworks.com
11. References
[asp] Bay Networks SS7-Internet Access Signaling Protocol, <draft-long-
ss7-signal-00.txt>, work in progress
[rsgcp] Reliable Signaling Gateway Control Protocol (RSGCP), <draft-
rfced-info-holdrege-00.txt>, work in progress
Q.931 ITU-T Recommendation Q.931 DIGITAL SUBSCRIBER SIGNALLING SYSTEM
No. 1 (DSS 1) - ISDN USER-NETWORK INTERFACE LAYER 3 SPECIFICATION FOR BASIC
CALL CONTROL
Q.699 ITU-T Recommendation Q.699 Interworking between ISDN access and
non-ISDN access over ISDN User Part of Signalling System No. 7
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT
RGSP [Page 22]