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) 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, , work in progress [rsgcp] Reliable Signaling Gateway Control Protocol (RSGCP), , 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]