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

Versions: 00                                                            
INTERNET DRAFT          EXPIRES DEC 1998                INTERNET DRAFT
Internet Draft                                             Matt Holdrege
June 1998                                          Ascend Communications


        The Reliable Signaling Gateway Control Protocol (RSGCP)
                      draft-rfced-info-holdrege-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).

   Copyright Notice

   Copyright  (C) The Internet Society (1998).  All Rights Reserved.


Abstract

   This memo describes the Control Protocol used between a Network
   Access Server (NAS) and a Signaling Gateway (SG). The requirements of
   this protocol are Call Control, Circuit Maintenance and Resource
   Management.  This protocol must be reliable in nature and support
   redundant links between the NAS and SG. It's important to note that
   the NAS could be handling either packetized voice or data for access
   to the Internet.

Introduction

   A need has arisen to better integrate Internet access and the Public
   Switched Telephone Network (PSTN). To accomplish this daunting task,
   several new techniques are being developed. One such technique is to
   establish communications between the main PSTN signaling network,
   known as Signaling System 7 (SS7) and dial-in internet NAS's. This
   allows multiple NAS access ports to collectively appear as a virtual
   resource of a PSTN switch. Another way to look at it is that the
   NAS's appear as a egress PSTN switch to an ingress PSTN switch.

   The communication between the NAS and SS7 is facilitated by the SG.
   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.



Holdrege                                                        [Page 1]


I-D         The Reliable Signaling Gateway Control Protocol    June 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 will be derived from the ITU-T protocol
   Q.931. Q.931 is a very reliable protocol that has been used for years
   mainly as an ISDN call control protocol. Q.931 has well defined
   procedures and a message set that is extensible to allow additional
   functionality to be added easily. Additionally, Q.931 has already
   been incorporated into NAS's minimizing the modifications required to
   implement the new Control Protocol.

   Due to the requirement for reliability and redundancy, a lower layer
   protocol is defined which is similar in nature to Q.921 or the link
   layer protocol.

   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

   Bearer Services and Interface Configuration
      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

   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.




Holdrege                                                        [Page 2]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   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.1 Format and Coding

3.2.1 Message Structure

   This section defines the messages the SG and NAS use for call
   processing, maintenance, and management. These messages are based on
   the ITU-T Recommendation Q.931 message set, and in most cases are
   simply specific codings of standard Q.931 messages. However, because
   the requirements of the SG based systems differ from those of ISDN
   access for which the Q.931 message set was developed, some messages
   described in this section are extensions of standard Q.931 messages.
   The Control Protocol message set consists of:


Message                         Value

   CONNect                         0x07
   CONNect ACKnowledge             0x0f
   CONTinuity                      0x11
   CONTinuity ACKnowledge          0x13
   DISConnect                      0x45
   REGistration                    0x1f
   REGistration ACKnowledge        0x17
   RELease                         0x4d
   RELease COMplete                0x5a
   RESTart                         0x46
   RESTart ACKnowledge             0x4e
   SERVice                         0x0f
   SERVice ACKnowledge             0x07
   SETUP                           0x05
   STATus                          0x7d
   STATus ENQuiry                  0x73
   LOGon                           0x7f


   Of the above messages, most are standardized in ITU-T Q.931. A few
   are added to meet the requirements of this protocol. They are:
   CONTinuity
   CONTinuity ACKnowledge
   REGistration
   REGistration ACKnowledge
   SERVice
   SERVice ACKnowledge
   LOGon

3.2.1.1 CONTinuity




Holdrege                                                        [Page 3]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   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           5

   Message Type            NAS -> SG   Mandatory           1

   Channel Identification  NAS -> SG   Mandatory           8

   Continuity Indicator    NAS -> SG   Mandatory           3

   The Continuity message is used by the NAS to indicate the outcome of
   a continuity test.

3.2.1.2 CONTinuity ACKnowledge

   Information Element     Direction   Inclusion Condition Length

   Protocol Discriminator  SG -> NAS   Mandatory           1

   Call Reference          SG -> NAS   Mandatory           5

   Message Type            SG -> NAS   Mandatory           1

   Channel Identification  SG -> NAS   Mandatory           8

   The Continuity Acknowledge message is used by the SG to acknowledge
   the receipt of a Continuity message from the NAS.

3.2.1.3 REGistration

   The Registration message shall be formatted as shown below:

   Information Element             Direction   Inclusion Cond.  Length

   Protocol Discriminator          NAS -> SG   Mandatory           1

   Call Reference                  NAS -> SG   Mandatory           5

   Message Type                    NAS -> SG   Mandatory           1

   Resource                        NAS -> SG   Mandatory           3-5

   Channel Identification          NAS -> SG   Optional            7+

   Channel State ID                NAS -> SG   Optional            7+

   The Registration message is sent by the NAS to register associated
   trunk and user port resources. For each Resource information element
   that specifies a trunk resource, there must be a corresponding
   Channel State Identification information element, immediately



Holdrege                                                        [Page 4]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   following.  If no trunk resources are specified in the Resource
   information element, the Channel Identification State information
   element may be omitted. When the NAS detects both links fail between
   the SG, if at least one link comes back up again, it will send the
   Registration message to inform the Gateway the available resources.
   The protocol discriminator of the Registration message is 0x43
   (Maintenance Protocol Discriminator).

3.2.1.4 REGistration ACKnowledge

   The Registration 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           5

   Message Type                    SG -> NAS   Mandatory           1

   The Registration Acknowledge message is sent by the SG to acknowledge
   confirmation of a resource registration.  For each Resource
   information element that specifies a trunk resource, there must be a
   corresponding Channel State Identification information element,
   immediately following.  The Registration Acknowledge message is not
   part of the basic Q.931 message set. The protocol discriminator of
   the Registration Ack is 0x43 (Maintenance Protocol Discriminator).

3.2.1.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           5

   Message Type                    BOTH        Mandatory           1

   Resource                        BOTH        Mandatory           3

   Channel Identification          BOTH        Mandatory           7+

   The Service message is sent by the SG to request a change in channel
   status and by the NAS to indicate a change in channel status.

3.2.1.6 SERVice ACKnowledge

   The Service ACKnowledge message shall be formatted as shown below:

   Information Element             Direction   Inclusion Cond.  Length




Holdrege                                                        [Page 5]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   Protocol Discriminator          BOTH        Mandatory           1

   Call Reference                  BOTH        Mandatory           5

   Message Type                    BOTH        Mandatory           1

   Resource                        BOTH        Mandatory           3

   Channel Identification          BOTH        Mandatory           7+

   The Service Acknowledge message is sent by either the SG or the NAS
   to indicate that the state of the specified 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.1.7 LOGon

   The Logon message shall be formatted as shown below:

   Information Element             Direction   Inclusion Cond.  Length

   Protocol Discriminator          NAS -> SG   Mandatory           1

   Call Reference                  NAS -> SG   Mandatory           5

   Message Type                    NAS -> SG   Mandatory           1

   When the NAS cold restarts, it will send a LOGon message to notify
   the SG. Then the NAS will send REGistration messages to inform the SG
   of the available resources. The Protocol Discriminator of the Logon
   message is 0x43 (Maintenance Protocol Discriminator).

Details

   Information Elements are defined in ITU-T Q.931 and are not re-
   defined here for brevity.

   Timers are defined in ITU-T Q.931 and are not re-defined here for
   brevity.

4. Basic Call Control

   This section describes the basic call control capabilities required
   for processing calls in the SG based NAS system.

4.1 Call Scenarios

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.



Holdrege                                                        [Page 6]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   * When the SG receives a 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.  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 and an ANM message out to the SS7
   network.

   * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop
   timer T313.

4.1.1.2 IAM Initiated with 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 required.

   * When the SG receives a 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.

   * 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 and an ANM message out to the SS7
   network.

   * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop
   timer T313.



Holdrege                                                        [Page 7]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


4.1.1.3 IAM Initiated with COT 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 a 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 shall send a SETUP message
   out to the control link.

   * 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.

   * When the SG receives a COT message from the SS7 network indicating
   the continuity test was successful, the SG shall send a ANM message
   out to the SS7 network.

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 DISCONNECT message with a Cause Value of 16,
   "normal clearing", is sent to the NAS.

   * When the NAS receives a DISCONNECT message the associated circuit
   shall be disconnected, a RELEASE shall be sent to the SG, and timer
   T308 shall be initiated.

   * When the SG receives the RELEASE message, a RELEASE COMPLETE shall
   be sent to the NAS and a RLC shall be sent out to the SS7 network.

   * When the NAS receives the RELEASE COMPLETE message timer T308 shall
   be stopped, the channel shall be released, and the call reference
   shall be released.

   4.1.2.2 NAS Initiated Call Clearing This scenario describes the
   signaling that proceeds when a call clearing is initiated by the NAS.

   * When the NAS detects that an active call has been terminated by the



Holdrege                                                        [Page 8]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   local subscriber, the NAS  shall disconnect the associated circuit,
   send a DISCONNECT message to the SG, and initiate timer T305.

   * When the SG receives a DISCONNECT from the NAS, a RELEASE message
   shall be sent to the NAS, and a RLS message shall be sent out to the
   SS7 network.

   * When the NAS receives the RELEASE message timer T305 shall be
   stopped, the circuit shall be released, the call reference shall be
   released, and a RELEASE COMPLETE shall be sent to the SG.

   * When the NAS receives the RELEASE COMPLETE message timer T308 shall
   be stopped, the B-channel shall be release, and the call reference
   shall be released.

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 COT 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 a 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 shall send a SETUP message
   out to the control link.

   * 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.

   * When the SG receives a REL message from the SS7 network, which
   indicates the continuity test failed, a DISCONNECT message with a
   Cause Value of 16, "normal clearing", is sent to the NAS.

   * When the NAS receives a DISCONNECT message the associated circuit
   shall be disconnected, a RELEASE shall be sent to the SG, and timer
   T308 shall be initiated.

   * When the SG receives the RELEASE message, a RELEASE COMPLETE shall
   be sent to the NAS and a RLC shall be sent out to the SS7 network.



Holdrege                                                        [Page 9]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   * When the NAS receives the RELEASE COMPLETE message timer T308 shall
   be stopped, the channel shall be released, and the call reference
   shall be released.

4.1.4 Resource Registration

4.1.4.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 REGistration message is sent to the SG and Timer T350 shall
   be initiated.

   * When the SG receives the REGistration message, the indicated
   resource states are updated and a REGistration ACKnowledgement is
   sent to the NAS.  The Resource information elements in the
   REGistration ACKnowledgement must be identical to those received in
   the original REGistration message.

   * When the NAS receives the REGistration ACKnowledge message, timer
   T350 shall be stopped.

   4.1.4.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 REGistration message and restart Timer
   T350 until a corresponding REGistration ACKnowledge is received.

   * When the NAS detects that a resource has changed operational
   states, a REGistration 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
   REGistration message and restart timer T350.

   * When the SG receives the REGistration message, the indicated
   resource states are updated and a REGistration ACKnowledgement is
   sent to the NAS.  The Resource information elements in the
   REGistration ACKnowledgement must be identical to those received in
   the original REGistration message.

   * When the NAS receives the REGistration ACKnowledge message, timer
   T350 shall be stopped.

4.1.4.3 SG Initiated Restart

   This scenario describes the message flow that proceeds when a Restart
   Request primitive is received by the SG Control Protocol from the
   call control.




Holdrege                                                       [Page 10]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   * When the SG Control Protocol receives a Restart Request primitive
   from the call control, a RESTart message is sent to the NAS and timer
   T317 is initiated.

   * When the NAS receives a RESTart message from the SG Control
   Protocol, the specified device shall be restarted and a RESTart
   ACKnowledgment shall be sent to the SG.

   * When the SG Control Protocol receives a RESTart ACKnowledgment from
   the NAS, timer T317 shall be stopped.

4.1.4.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, as shown
   in figure Figure 28 - NAS Initiated Restart.

   * If the NAS determines that a restart of a single DS0, an entire
   DS1/E1, or the entire NAS system 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 ACKnowledgment shall be sent to the NAS.

   * When the NAS receives a RESTart ACKnowledgment from the SG, timer
   T317 shall be stopped, and the associated equipment shall be
   restarted.

4.2 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

5.0 Redundancy

   For redundancy support, the SG and the NAS are connected via two
   independent links, a primary link (D1) and a secondary link (D2). The
   D1 and D2 entities on the NAS will attempt to establish sessions with
   their peers on the SG. When a session is established or lost, the
   Data Link Layer Entity (DLLE) will notify the Link Selection Control



Holdrege                                                       [Page 11]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   (LS) entity.

   The LS entity selects an available link (based on the reports from D1
   and D2) and directs all NMI messages to that link. When an active
   link fails or is administratively declared inactive, the LS entity
   looks for an alternate link.

   In general, the NAS Messaging Interface (NMI) is unaware of the link
   selection mechanism. As far as the NMI is concerned, there is a
   single pipe between the Gateway and the NAS. Therefore, the queue of
   outgoing messages (including those that are still unacknowledged)
   must be shared between the two D1 and D2 entities.

   The message exchange between the Gateway and the NAS will use TCP
   over IP.  The TCP port to be used should be user settable.

   The usual physical connection between the Gateway and the NAS will be
   Ethernet. Transmission of IP over Ethernet follows the usual rules.
   Other physical connections are possible.

   All numbers should be in binary, encoded in Network Byte Order (Big
   Endian).

   Sequence numbers follow the rules defined in RFC 1982 ("Serial Number
   Arithmetic").

   The procedures have been designed assuming that the Gateway will
   listen for TCP connections, while the NAS will initiate the TCP
   connections.

   Piggy-back acknowledgments are allowed and encouraged.
   Acknowledgments should not be delayed excessively.

5.1 Formats

5.1.1 NMI packet format

   The NMI packets are transported using the TCP protocol over IP. The
   IP and TCP protocols are standard and are not defined in this
   document. Refer to RFC791 and RFC793 for further details.

   The NMI header is defined below. The Information field is optional
   and it is used to carry NMI messages.

5.1.2 NMI header format

   The NMI header is four bytes long.

          7 6 5 4 3 2 1 0
         +-+-+-+-+-+-+-+-
       0 |     N(r)
         +-+-+-+-+-+-+-+-
       1 |     N(s)
         +-+-+-+-+-+-+-+-



Holdrege                                                       [Page 12]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


       2 |0 0 0 0 0 0
         +-+-+-+-+-+-+-+-
       3 | Info Field Lng

   The N(r) field carries the received sequence number. The N(s) field
   carries the send sequence number. These numbers are used to detect
   duplicated data packets when using multiple links. Duplicate data
   packets can occur on the receiver when the sender switches from one
   active link to another.

   The information field length indicates the length in bytes of the
   information field following the NMI header, if any.  If the
   information field is not present, the length field is set to zero.
   The field is encoded in big-endian format.


5.1.3 Packet types

   Depending on the presence of the information field, there are two
   kinds of packets: Information packets and ACK packets.

5.1.3.1 Information (I) packet

   The function of the Information (I) packet is to transfer
   sequentially numbered NMI messages. In this case, the header is
   followed by an information field containing the NMI message.

   I packets may also be used to acknowledge previously received I
   packets numbered up to and including N(r) - 1. This function is
   commonly referred to "piggy-back acknowledge".

5.1.3.2 Acknowledge (ACK) packet

   The function of the Acknowledge (ACK) packet is to acknowledge
   previously received I packets numbered up to and including N(r) - 1.

5.2 Recommended system parameters

5.2.1 Maximum number of outstanding data packets - k

   The maximum number (k) of sequentially numbered data packets that may
   be outstanding (that is, unacknowledged) at any given time should not
   exceed 63.

5.2.2 Maximum number of received data packets pending acknowledgement -
   m

   The maximum number (m) of sequentially numbered data packets received
   pending acknowledgement at any given time must be smaller or equal to
   the value of k.

5.2.3 ACK delay timer - T1

   The ACK delay timer (T1) specifies the maximum time that an



Holdrege                                                       [Page 13]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   acknowledge response can be delayed after correctly receiving an I
   packet.

5.2.4 Transmission timeout timer - T2

   The transmission timeout timer (T2) specifies the maximum time that
   an end point should wait for an acknowledgement.

5.2.5 Persistent error timer - T3

   The transmission timeout timer (T3) specifies the maximum time that
   the Link Selection layer will wait for a link to establish.  When
   this timer expires, the LS layer will indicate the error with an L2-
   ERROR indication.  When the error condition is removed (i.e., a TCP
   session is established), another L2-ERROR indication will be issued
   with a "no error" indication.

5.3 Variables and sequence numbers

5.3.1 Sequence numbers

   Each NMI message is sequentially numbered.  The sequence numbers
   cycle through the range 1 through 255. The number following 255 is 1,
   the number before 1 is 255. The value 0 has special meaning.

   Arithmetic operations on state variables representing sequence
   numbers are affected by the fact that 0 is a forbidden value.

5.3.2 Link selection (LS) layer

5.3.2.1 Active link - L(a)

   L(a) denotes an identifier associated with the currently selected
   link.  Valid values are system dependent. In UNIX systems, this value
   could be the TCP socket number.

5.3.2.2 Inactive link - L(i)

   L(i) denotes an identifier associated with the other link. Valid
   values are system dependent. In UNIX systems, this value could be the
   TCP socket number.

5.3.2.3 Send state variable - V(s)

   V(s) denotes the sequence number of the next NMI message to be
   transmitted.  V(s) can take on the value 1 through 255. The value of
   V(s) will be incremented by 1 with each successive NMI message
   transmission, and will not exceed V(a) by more than the maximum
   number of outstanding data packets k. The value of k (send window
   size) must be in the range 1 less than or equal to k less than or
   equal to 63.

5.3.2.4 Acknowledge state variable - V(a)




Holdrege                                                       [Page 14]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   V(a) identifies the last NMI message that has been acknowledged by
   its peer [V(a) - 1 equals N(s) of the last acknowledged NMI message].
   V(a) can take on the value 1 through 255. The value of V(a) will be
   updated by the valid N(r) values received from the peer. A valid N(r)
   value is one that is in the range V(a) less than or equal to N(r)
   less than or equal to V(s).

5.3.2.5 Receive state variable - V(r)

   V(r) denotes the sequence number of the next in-sequence NMI message
   expected to be received. V(r) can take on the value 0 through 255.
   The value of V(r) will be incremented by one with the receipt of an
   error-free, in-sequence NMI message whose N(s) equals V(r).

   When the value of V(r) is 0, it will match any received N(s) exactly.
   This is used during sequence synchronization.

5.3.2.6 Receive packets pending acknowledgement counter - RP

   RP denotes the count of received packets that are pending
   acknowledgement.  RP can take on the value 0 through m - 1.  The
   value of RP will be incremented by one with the receipt of an error-
   free, in-sequence NMI message whose N(s) equals V(r). It is reset to
   0 when a packet is transmitted (either an I packet or an ACK packet).

5.3.3 Data link (DL) layer

5.3.3.1 Send sequence number - N(s)

   All packets carry N(s), the send sequence number of transmitted NMI
   messages. At the time that a packet is designated for transmission,
   the value of N(s) is set equal to V(s).  The valid range is 1 through
   255.

5.3.3.2 Receive sequence number - N(r)

   All packets carry N(r), the expected send sequence number of the next
   received NMI message. At the time that a packet is designated for
   transmission, the value of N(r) is set equal to V(r). N(r) indicates
   that the DLLE transmitting the N(r) has correctly received all data
   packets numbered up to and including N(r) - 1.

   A valid N(r) value is one that is in the range V(a) less than or
   equal to N(r) less than or equal to V(s).

   The valid range of values is 0 through 255. The value 0 indicates
   that the sender of the packet needs to synchronize sequence numbers.

5.4 Primitives

5.4.1 NP <-> LS primitives

5.4.1.1 L2-START




Holdrege                                                       [Page 15]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   The L2-START primitive is used to request the establishing of a
   redundant session.

5.4.1.2 L2-STOP

   The L2-STOP primitive is used to request the release of an
   established redundant session. All pending outgoing data will be
   delivered before the session is released.

5.4.1.3 L2-ABORT

   The L2-ABORT primitive is used to request the immediate release of an
   established session. All pending outgoing data is discarded.

5.4.1.4 L2-DATA

   The L2-DATA primitives are used to request and indicate NMI messages
   which are to be transmitted, or have been received, by the data link
   layer.

5.4.1.5 L2-ERROR

   The L2-ERROR primitive is used to indicate when an error condition
   has occurred. Some of the possible conditions include:

            Loss of communication with peer.

            Persistent loss of communication with peer.

            Error condition removed.

5.4.2 LS <-> DL primitives

5.4.2.1 DL-ESTABLISH

   The DL-ESTABLISH primitives are used to request and confirm the
   outcome of procedures for establishing a TCP session.

5.4.2.2 DL-RELEASE

   The DL-RELEASE primitives are used to request, indicate and confirm
   the release of an established TCP session.

5.4.2.3 DL-ACTIVE

   The DL-ACTIVE primitives are used to request, indicate and confirm
   the outcome of procedures for activating a link.

5.4.2.4 DL-DATA

   The DL-DATA primitives are used to request and indicate NMI messages
   which are to be transmitted, or have been received, by the data link
   layer.




Holdrege                                                       [Page 16]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


5.4.2.5 DL-ERROR

   The DL-ERROR primitive is used to indicate when an error has
   occurred.

5.4.3 DL <-> DA primitives

5.4.3.1 DD-SYNC

   The DD-SYNC primitive is used to request and indicate the
   synchronization of a data link.

5.4.3.2 DD-LOSS

   The DD-LOSS primitive is used to indicate that a data link is no
   longer available. The TCP session should be closed and reestablished.
   Some of possible reasons include:

   Loss of TCP connection (such as reception of an RST or FIN flag).

   Timeout while waiting for an acknowledge after sending an I packet.

   Reception of an invalid N(r).

   Reception of an invalid N(s).

5.4.3.3 DD-DATA

   The DD-DATA primitives are used to request and indicate NMI messages
   which are to be transmitted, or have been received, by the data link
   layer.

5.4.4 TCP primitives

5.4.4.1 TCP-CONNECT

   The TCP-CONNECT primitives are used to request and confirm
   establishing a TCP session.

5.4.4.2 TCP-CLOSE

   The TCP-CLOSE primitives are used to request and indicate the release
   of an established TCP session.

5.4.4.3 TCP-ABORT

   The TCP-ABORT primitives is used to request the immediate release of
   a TCP session.

6. State transition tables

6.1 State machines overview

6.1.1 Layer 2 - Link selection state machine (LS)



Holdrege                                                       [Page 17]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   The link selection (LS) layer implements redundant data delivery,
   link management and selection for both data links. The following is a
   list of the Link Selection layer states:

   State   Name            Comments

   0       Inactive        NMI layer 2 is disabled.

   1       Selecting       Layer 2 starting. Waiting for DL-ESTABLISH.

   2       Active          Layer 2 active: a link is active and data
                           transfer is possible.

   3       Restarting      Layer 2 restarting with new parameters.
                           Waiting for both links to be released. Any
                           pending data will be sent before the active
                           link is released.

   4       Stopping        Layer 2 stopping. Waiting for both links to
                           be released.

   5       Stopping-       Layer 2 stopping and restarting. Waiting for
           restart         both links to be released before the new
                           parameters are effected.

6.1.2 Link control state machine (LC)

   Each redundant link is controlled by a 'Link Control State Machine'.
   The following is a list of the Link Control states:

   State   Name            Comments

   0       Inactive

   1       Unavailable     Link establishment in progress.

   2       Available       Link established and ready.

   3       Pending         Link established and ready. Synchronization
                           activation pattern received.

   4       Active          Link active. Data transfer occurs on this
                           link.

   5       Stopping        Active link stopping. Waiting for all pending
                           outgoing data to be delivered.

   6       Closing         Active link closing. Waiting for TCP
                           confirmation of link closed.

   7       Releasing       Inactive link closing. Waiting for TCP
                           confirmation of link closed.

6.1.3 Link state machine - active mode (LA)



Holdrege                                                       [Page 18]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   The following is a list of the link states while in active mode. A
   link is said to be in active mode if it is the currently selected
   link. A link that is in the active mode is enabled for data transfer.

   State   Name            Comments

   0       Idle            Link control state is one of the following:
                           INACTIVE, UNAVAILABLE, AVAILABLE, RELEASING
                           and CLOSING.

   1       Sync sent       Active link, synchronization request sent.
                           Waiting for synchronization response.

   2       Established     Active link, no data to send and no
                           acknowledge pending.

   3       Acknowledge     Active link, data has been received but a
                           pending acknowledgement has not been sent.

   4       Data sent       Active link, data sent but not acknowledged.

   5       Data sent,      Active link, data sent but not acknowledged
           acknowledge     and data has been received but an
           pending         acknowledgement has not been sent.

7. Security Considerations

   SS7 is a critical network component in the PSTN and must be protected
   at all costs. This is taken into consideration in all current SS7
   networks.  Signaling gateways are designed also 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.

   Also, it is recommended but not required that the TCP/IP link from
   the NAS to the SG be protected by IPsec AH and ESP. In the case that
   the physical network between the NAS and SG is private, such security
   techniques are optional. In the case that the IP backbone 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 which cannot be prevented by SG thresholds.

8. Acronyms

   ANM             Answer Message

   SG              Signaling SG

   CCR             Continuity Check Request

   COT             Continuity

   CPE             Customer Premises Equipment




Holdrege                                                       [Page 19]


I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   CRM             Circuit Reservation Message

   IAM             Initial Address Message

   ICD             Interface Control Document

   IE              Information Element

   IP              Internet Protocol

   ISDN            Integrated Services Digital Network

   ISP             Internet Service Provider

   ISUP            ISDN User Part

   MTP             Message Transfer Part

   PCM             Pulse Code Modulation

   PSTN            Public Switched Telephone Network

   SPCS            Stored Program Control System

   SS7             Signaling System Number 7

   UL              Upper Layer

10. Authors Address

      Matt Holdrege
      1701 Harbor Bay Pkwy
      Alameda, CA 94502
      510-747-2711
      matt@ascend.com

   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.




Holdrege                                                       [Page 20]

I-D         The Reliable Signaling Gateway Control Protocol    June 1998


   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 DEC 1998        INTERNET DRAFT