[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]