Network Working Group D. Auerbach INTERNET-DRAFT D. Berg K. Morneault Cisco Systems Expires in six months 25 Feburary 1999 SIGNALING BACKHAUL PROTOCOL Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft discusses a framework for transporting signaling protocols (SS7, ISDN and DPNSS) over packet networks. The framework is referred to as signaling 'backhaul'. The backhaul takes place between a Media Gateway (MG) or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the packet world (IP/ATM), and a Media Gateway Controller (MGC), which provides call processing. It is referred to as 'backhaul' because the gateway terminates the lower layers of the protocol (i.e. Layer 1 and 2) and backhauls the other layers to the MGC. Auerbach, Berg & Morneault [Page 1] Internet Draft Signaling Backhaul Protocol Feb 1999 TABLE OF CONTENTS 1. Introduction..............................................3 1.1 Backhaul Discussion..................................3 2. Backhaul Design...........................................3 2.1 Design Goals.........................................3 2.2 Message Header.......................................4 2.2.1 Message Types......................................5 2.3 Layer-to-Layer Messages..............................6 2.3.1 Establish..........................................6 2.3.2 Release............................................6 2.3.3 Data...............................................6 2.3.4 MTP3 Data..........................................7 2.3.5 MTP2 Status........................................7 2.3.6 MTP3 Status........................................8 2.3.7 MTP2 Data Retrieval................................9 2.3.8 MTP2 Data Retrieval Done..........................10 2.3.9 Flow Control......................................10 2.4 Management Messages.................................10 2.4.1 Mgmt Channel Reset................................10 2.4.2 Mgmt Error........................................10 3. Implementation Considerations............................11 3.1 ISDN................................................11 3.2 SS7.................................................12 3.3 DPNSS...............................................15 4. Future Enhancements......................................16 5. References...............................................17 6. Author's Addresses.......................................17 Auerbach, Berg & Morneault [Page 2] Internet Draft Signaling Backhaul Protocol Feb 1999 1. Introduction 1.1 Backhaul Discussion There is a need for backhauling signaling protocols (SS7, ISDN, and DPNSS) across packet networks. The backhaul takes place between a Media Gateway (MG) or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the packet world (IP/ATM), and a Media Gateway Controller (MGC), which provides call processing. For the rest of this document, Media Gateways that provide signaling backhaul and Signaling Gateways are more generically refered to as gateways. The general principle behind signaling backhaul is to reliably pass layers of a protocol stack through a gateway directly to the MGC. The lower level (Layer 1 and/or Layer 2) protocol processing are terminated on the gateway. This provides the advantage of distributing the protocol processing to allow for greater expandability/scaleability. The other layers are transported to the MGC for processing. Signaling backhaul requires a reliable and fast protocol to transport the signaling protocol over the packet network. The recommendation is to use Reliable UDP (RUDP) over IP. RUDP provides a socket like interface but also provides autonomous notification of “connected” sessions and “failed” sessions. There is a separate internet-draft that discusses RUDP (draft-ietf-reliable-udp-00.txt). In addition, Session Manager can be used when redundant networks or redundant MGCs exist. Session Manager provides another level of reliability transparently to the signaling protocol application. There is a separate internet-draft that discusses Session Manager (draft-ietf-session-mgr-00.txt). The figure below shows how backhaul fits in a layered architecture. +-------------------------------+ | Signaling Application | | (backhaul) | |-------------------------------| | Session Manager | |-------------------------------| | RUDP | +-------------------------------+ While RUDP and Session Manager are recommended, the 'backhaul' protocol is not dependent upon them. 2.0 Backhaul Design 2.1 Design Goals There is a need for signaling protocol delivery from a gateway to a MGC. The delivery mechanism should meet the following criteria: Auerbach, Berg & Morneault [Page 3] Internet Draft Signaling Backhaul Protocol Feb 1999 * Support for SS7, ISDN and DPNSS protocol families * Generic interface for all protocols regardless of where protocol layer split occurs * UDP port(s) per protocol family supported or single UDP port for multiple protocol families (i.e. the ability to multiplex PDUs from multiple protocols) * Limit the amount of IP message traffic * Provide better scaleability of MGC by allowing up to Layer 2/3 of signaling protocols to be terminated on a gateway * The gateway must provide autonomous signaling channel service state information to the MGC * The interface must provide a request/response mechanism for commanding the signaling channels in and out of service 2.2 Message Header The messages passed between a gateway and the MGC requires a message header which contains a message identifier, message type, channel identifier, protocol identifier and version number. The message identi- fier indicates whether it was a Layer-to-Layer or Management message. The Service Access Point (SAP) or channel identifier identifies the SAP or channel on the gateway. The value in this field must be coordinated between the gateway and the MGC as part of the provisioning or registration process. Provisioning and registration are out of the scope of this document. However, some examples would be the use of SNMP for provisioning and the use of MGCP or SIP for registration. The protocol identifier indicates which layer of the protocol is terminated on the gateway. For example, if the protocol identifier is set to MTP3, the gateway terminates MTP3 and the MGC terminates one or more SS7 User Parts. A gateway could terminate one or more protocols. If a gateway terminates multiple protocols, the protocol identifier field can be used to multiplex the protocols over a single IP connection. The valid protocol identifiers are: Reserved 0x0 MTP2 0x1 MTP3 0x2 SCCP 0x3 Q.921 0x4 DPNSS 0x6 The message identifier is used to separate Management from Layer-to-Layer messages. The valid message identifiers are: Layer-to-Layer message 0x0 Management message 0x1 The valid messages types are defined in Section 2.2.1 and the message contents are described in Section 2.3. The valid messages types are in the range of 0-0x7fff. Message types in the range of 0x8000-0xffff are reserved. Auerbach, Berg & Morneault [Page 4] Internet Draft Signaling Backhaul Protocol Feb 1999 The initial version are 1.0 (a value of 1). The header for these messages is shown in Figure 1. 0 15 16 31 +---------------+---------------+ | Protocol | Msg | | ID | ID | +---------------+---------------+ | Msg | Channel | | Type | ID | +---------------+---------------+ | Version | Length | | | | +---------------+---------------+ Figure 1, Message Header The types of messages passed between a gateway and a MGC can be categorized as Layer-to-Layer and Management messages. 2.2.1 Message Types The following list contains the message types for the defined messages. ESTABLISH_REQ 0x0006 ESTABLISH_CFM 0x0009 RELEASE_REQ 0x000a RELEASE_CFM 0x000b DATA_REQ 0x0010 MTP3_DATA_REQ 0x0034 MTP2_STATUS_REQ 0x0020 MTP3_STATUS_REQ 0x0030 MTP2_DATA_RTRV_REQ 0x0012 FLOW_CONTROL_CFM 0x0040 ESTABLISH_RSP 0x0007 ESTABLISH_IND 0x0008 RELEASE_IND 0x000c RELEASE_RSP 0x000d DATA_IND 0x0011 MTP3_DATA_IND 0x0033 MTP2_STATUS_RSP 0x0021 MTP2_STATUS_IND 0x0022 MTP3_STATUS_RSP 0x0031 MTP3_STATUS_IND 0x0032 MTP2_DATA_RTRV_RSP 0x0013 MTP2_DATA_RTRV_IND 0x0014 MTP2_DATA_RTRV_DONE_IND 0x0015 FLOW_CONTROL_IND 0x0041 MGMT_CHAN_RESET_REQ 0x1001 MGMT_ERROR_IND 0x1002 Auerbach, Berg & Morneault [Page 5] Internet Draft Signaling Backhaul Protocol Feb 1999 2.3 Layer-to-Layer Messages The following Layer-to-Layer messages are supported. 2.3.1 Establish (Request, Indication, Response, Confirmation) This message are used to establish the channel or to indicate that the channel has been established. Note that the gateway may already have the channel established at its layer. If so, upon receipt of an Establish Request, the gateway takes no action except to send an Establish Response. 0 31 +---------------+---------------+ | State | +---------------+---------------+ The valid values for State are shown in the following table. Define Value Description ESTABLISH_SIMUL_RESET 0x1 Follow startup procedure of reseting all DLCs simultaneously. ESTABLISH_SEQ_RESET 0x2 Follow startup procedure of reseting all DLCs sequentially. ESTABLISH_START 0x3 Follow normal procedure for establishing channel. 2.3.2 Release (Request, Indication, Response, Confirmation) This message are used to release the channel or to indicate that the channel has been released. 0 31 +---------------+---------------+ | Reason | +---------------+---------------+ The valid values for Reason are shown in the following table. Define Value Description RELEASE_MGMT 0x0 Management layer generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_DM 0x2 Specific to a request. Indicates Layer 2 should release and deny all requests from far end to establish channel (i.e. if SABME received, send a DM). 2.3.3 Data (Request, Indication) The Data message contains a Protocol Data Unit (PDU). Auerbach, Berg & Morneault [Page 6] Internet Draft Signaling Backhaul Protocol Feb 1999 2.3.4 MTP3 Data (Request, Indication) The MTP3 Data message contains a SS7 User Part PDU. In addition, it contains information from the MTP 3 routing label. The format for the MTP3 Data Request and Indication message is shown below. 0 31 +---------------+---------------+ | DPC | +---------------+---------------+ | OPC | +---------------+---------------+ | SIO | +---------------+---------------+ | SLS | +---------------+---------------+ | PRIOR | +---------------+---------------+ The SIO field contains the service indicator and sub-service field. The PRIOR field contains the priority of the message. The valid values for priority are zero to three with three being the highest priority. 2.3.5 MTP2 Status (Request, Indication, Response) The status request message can be sent from a MGC to cause an action on the gateway. The gateway sends a status response to the MGC if the action has been successfully completed. 0 31 +---------------+---------------+ | Status | +---------------+---------------+ The valid values for Status are shown in the following table. Define Value Description STATUS_LOC_PROC_SET 0x0 Request local processor outage. STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage recovered. STATUS_EMER_SET 0x2 Request emergency alignment procedure. STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel emergency) procedure. STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. STATUS_CONTINUE 0x5 Continue. The MTP2 Status Indication message can be sent from a gateway to a call agent to indicate a condition on a channel. 0 31 +---------------+---------------+ | Status | +---------------+---------------+ Auerbach, Berg & Morneault [Page 7] Internet Draft Signaling Backhaul Protocol Feb 1999 The valid values for Status are shown in the following table. Define Value Description EVENT_ENTER_LPO 0x0 Entered local processor outage. EVENT_EXIT_LPO 0x1 Exited local processor outage. EVENT_ENTER_CONG 0x2 Entered a congested state. EVENT_EXIT_CONG 0x3 Exited a congested state. EVENT_PHYS_UP 0x4 Physical interface operational. EVENT_PHYS_DOWN 0x5 Physical interface down. EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. EVENT_REM_ENTER_CONG 0xc Remote entered congestion. EVENT_REM_EXIT_CONG 0xd Remote exited congestion. EVENT_REM_ENTER_PO 0xe Remote entered processor outage. EVENT_REM_EXIT_PO 0xf Remote exited processor outage. 2.3.6 MTP3 Status (Request, Indication, Response) The status request message can be sent from a MGC to cause an action on the gateway. The gateway sends a status response to the MGC if the action has been successfully completed. The format for the MTP3 Status Request is shown below. The DPC field contains the point code of interest. The MTP3 Status Response contains the point code and the current status of the point code. The format of this message is shown below. 0 31 +---------------+---------------+ | DPC | +---------------+---------------+ | Status | +---------------+---------------+ | Congestion Level | +---------------+---------------+ The valid values for status are shown in the following table. Define Value Description STATUS_PAUSE 0x1 Pause STATUS_RESUME 0x2 Resume STATUS_CONGESTION 0x3 Congestion (see cong-level) The valid values for cong-level are zero (0) to three (3). The MTP3 Status Indication message can be sent from a gateway to a call agent to indicate a condition on a point code. Auerbach, Berg & Morneault [Page 8] Internet Draft Signaling Backhaul Protocol Feb 1999 0 31 +---------------+---------------+ | DPC | +---------------+---------------+ | Status | +---------------+---------------+ | Congestion Level | +---------------+---------------+ The valid values for Status are shown in the table below. The valid values for Congestion Level are zero (0) to three (3). Define Value Description STATUS_PAUSE 0x1 Pause STATUS_RESUME 0x2 Resume STATUS_CONGEST_BEGIN 0x3 Congestion begins (see cong-level) STATUS_REM_UPU 0x4 Remote User Part Unavailable STATUS_RESTRT_BEGIN 0x5 MTP Restart begins STATUS_RESTRT_END 0x6 MTP Restart ends STATUS_CONGEST_END 0x7 Congestion ends 2.3.7 MTP2 Data Retrieval (Request, Indication, Response) The data retrieval request message is used by the MGC in support for MTP3 backhaul. It is used to during the changeover procedure to request the BSN, retrieve PDUs from the retransmit queue or to flush PDUs from the retransmit queue. 0 31 +---------------+---------------+ | Action | +---------------+---------------+ | fsn_bsn | +---------------+---------------+ The valid values for Action are shown in the following table. Define Value Description ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit queue. ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. The fsn_bsn field contains the FSN of the far end if the action is ACTION_RTRV_MSGS. When the gateway sends a response to this request, it echos the action and fills in the BSN if the action was ACTION_RTRV_BSN. The data retrieval indication message is sent by the gateway with a PDU from the retransmit queue. Auerbach, Berg & Morneault [Page 9] Internet Draft Signaling Backhaul Protocol Feb 1999 2.3.8 MTP2 Data Retrieve Done (Indication) The data retrieval done indication message is exactly the same as the data retrieval indication message except that it also indicates that it contains the last PDU from the retransmit queue. 2.3.9 Flow Control (Indication, Confirmation) The flow control message can be sent from a gateway to indicate the need for flow control. This would typically occur if the gateway reached a buffer threshold (i.e. 80% of buffers full) and wanted to ensure that messages would not be lost (avoid exhausting supply of buffers). The MGC should confirm receipt of the flow control message and take appropriate action. 0 31 +---------------+---------------+ | Status | +---------------+---------------+ The valid values for Status are shown in the following table. Define Value Description STATUS_ONSET 0x0 Flow control onset - requesting flow control. STATUS_ABATE 0x1 Flow control abate. 2.4 Management Messages The following Management messages are supported. 2.4.1 Mgmt Channel Reset (Request) This message is used to request the gateway to reset the information on a channel or on all channels. 2.4.2 Mgmt Error (Indication) This message is used to indicate an error. It can be sent from the gateway or the MGC. 0 31 +---------------+---------------+ | Error | +---------------+---------------+ The valid values for Error are shown in the following table. Define Value Description ERROR_INVAL_CHAN_ID 0x0 Invalid channel ID in message header. ERROR_INVAL_PROT_ID 0x1 Invalid protocol ID in message header. ERROR_INVAL_MSG_ID 0x2 Invalid message ID in message header. ERROR_INVAL_MSG_TYPE 0x3 Invalid message type in message header. ERROR_INVAL_VERSION 0x4 Invalid version in message header. Auerbach, Berg & Morneault [Page 10] Internet Draft Signaling Backhaul Protocol Feb 1999 3.0 Implementation Considerations This section provides examples of the use of the generic signaling protocol backhaul specification for ISDN and SS7. 3.1 ISDN ISDN is the most straightforward and is most easily adapted to backhaul. Most implementations will split at the Layer 2 (Q.921) / Layer 3 (Q.931) boundary, therefore; this section only discusses the Layer 2 / Layer 3 split. Only a subset of the messages defined above are required for backhauling Q.931 over IP. The following Layer-to-Layer messages are used with this configuration: * Establish Request message - This message are sent by the MGC to request that a D-channel be brought in-service. The gateway initiates the necessary procedures to try to establish the D-channel. * Establish Response message - This message are sent by the gateway as a response to the Establish Request to indicate that a D-channel is in-service. * Establish Indication message - This message are sent by the gateway to indicate that a D-channel is in-service. * Establish Confirm message - This message are sent by the MGC to confirm receipt of the Establish Indication message. * Release Request message - This message are sent by the MGC to request that a D-channel be brought out-of-service. * Release Response message - This message are sent by the gateway as a response to the Release Request to indicate that a D-channel is out-of-service. * Release Indication message - This message are sent by the gateway to indicate that a D-channel is out-of-service. * Release Confirm message - This message are sent by the MGC to confirm receipt of the Release Indication message. * Data Request message - This message are sent by the MGC to transmit a PDU. * Data Indication message - This message are sent by the gateway. It contains a received PDU. The following Management messages are used with this configuration: * Mgmt Channel Reset message - This message are sent by the MGC to reset a channel (clear its state to initialized state). * Mgmt Error message - This message can be sent by the MGC or gateway to indicate an error. An example of the message flows for establishing a D-channel, passing PDUs and releasing the D-channel is shown below. Auerbach, Berg & Morneault [Page 11] Internet Draft Signaling Backhaul Protocol Feb 1999 gateway MGC <----------- Mgmt Channel Reset <----------- Establish Request (ESTABLISH_START) Establish Response -----------> <----------- Data Request Data Indication -----------> <----------- Data Request Data Indication -----------> <----------- Data Request <----------- Data Request Data Indication -----------> <----------- Release Request (RELEASE_MGMT) Release Response -----------> An example of the message flows for a failed attempt to establish a D-channel is shown below. In this case, the gateway has a problem with its physical connection (e.g. Red Alarm), so it cannot establish the D-channel. gateway MGC <----------- Mgmt Channel Reset <----------- Establish Request (ESTABLISH_START) Release Indication -----------> (RELEASE_PHYS) <----------- Release Confirm 3.2 SS7 SS7 has very intensive processing requirements at level 2. While the link is out-of-alignment, both sides must send and receive Link Status Signal Units (LSSUs) at close to line rate (~1200/second). Once a link is aligned, it must be filled using a Fill-In Signal Unit (FISU) during idle periods. The maximum number of FISUs received and transmitted at line speed can exceed 1200/second per DS0 (FISUs separated by a single flag). It is therefore essential for the gateway to transmit and filter duplicate FISUs and LSSUs. In other words, the gateway must support MTP 1. It is also preferable that the gateway support the MTP2 protocol layer. This section only discusses a Layer 2 (MTP2) / Layer 3 (MTP3) split. In this example, the gateway supports all of the MTP 1 and 2 functionality. In addition, MTP3 is backhauled from the gateway to the MGC. Auerbach, Berg & Morneault [Page 12] Internet Draft Signaling Backhaul Protocol Feb 1999 The following Layer-to-Layer messages are used with this configuration: * Establish Request message - This message are sent by the MGC to request that a link be brought in-service. * Establish Response message - This message are sent by the gateway as a response to the Establish Request to indicate that a link is in-service. * Establish Indication message - This message are sent by the gateway to indicate that a link is in-service. * Establish Confirm message - This message are sent by the MGC to confirm receipt of the Establish Indication message. * Release Request message - This message are sent by the MGC to request that a link be brought out-of-service. * Release Response message - This message are sent by the gateway as a response to the Release Request to indicate that a link is out-of-service. * Release Indication message - This message are sent by the gateway to indicate that a link is out-of-service. * Release Confirm message - This message are sent by the MGC to confirm receipt of the Release Indication message. * Data Request message - This message are sent by the MGC to transmit a PDU. * Data Indication message - This message are sent by the gateway. It contains a received PDU. * Status Request message - This message are sent by the MGC to request a condition for a link (normal or emergency alignment, local processor outage). * Status Response message - This message are sent by the gateway as a response to the Status Request. * Status Indication message - This message are sent by the gateway to indicate an event to the MGC. * Status Confirm message - This message are sent by the MGC to confirm receipt of the Status Indication message. * Data Retrieval Request message - This message are sent by the MGC to support the changeover procedure. * Data Retrieval Response message - This message are sent by the gateway in response to the Data Retrieval Request message. * Data Retrieval Indication message - This message are sent by the gateway with a PDU from its retransmit queue. * Data Retrieval Done Indication message - This message are sent by the gateway with the last PDU from tis retransmit queue. Auerbach, Berg & Morneault [Page 13] Internet Draft Signaling Backhaul Protocol Feb 1999 The following Management messages are used with this configuration: * Mgmt Channel Reset message - This message are sent by the MGC to reset a channel (clear its state to initialized state). * Mgmt Error message - This message can be sent by the MGC or gateway to indicate an error. An example of the message flow to bring a SS7 link in-service (using the emergency alignment procedure) and out-of-service is shown below. Note: Once STATUS_EMER_SET is accepted, that condition remains on that channel (link) until a STATUS_EMER_CLEAR is received or a Mgmt Channel Reset. gateway MGC <----------- Mgmt Channel Reset <----------- Status Request (STATUS_EMER_SET) Status Response ----------> <----------- Establish Request (ESTABLISH_START) Establish Response ----------> Note: The MGC does not have to wait for the Status Response before sending the Establish Request. <----------- Data Request Data Indication ------------> <----------- Data Request Data Indication ------------> <----------- Data Request Data Indication ------------> <------------ Release Request (RELEASE_MGMT) Release Response ------------> An example of the message flow to bring a SS7 link in-service using the normal alignment procedure is shown below. gateway MGC <----------- Mgmt Channel Reset <----------- Establish Request (ESTABLISH_START) Establish Response ----------> Auerbach, Berg & Morneault [Page 14] Internet Draft Signaling Backhaul Protocol Feb 1999 An example of the message flow for a changeover is shown below. gateway MGC <---------- Data Rtrvl Request (MTP2_RTRV_BSN) Data Rtrvl Confirm ----------> (with BSN) <---------- Data Rtrvl Request (MTP2_RTRV_MSGS with fsn) Data Rtrvl Confirm ----------> Data Rtrvl Ind -----------> Data Rtrvl Done Ind ----------> 3.3 DPNSS There are four issues related to backhauling DPNSS. * DPNSS has very short Layer 2 message timeouts (20 milliseconds). * At link initialization, an initialization message is sent for each bearer channel (including real and virtual). The switch will continue sending these messages at very short intervals until it gets responses. These messages can be sent simultaneously or in-sequence. * It is not a layered protocol (i.e. there is no clear boundary between Layer 2 and Layer 3). * Bearer (real and virtual) service state information is managed at 'Layer 2' of the DPNSS protocol. Due to the time and performance requirements of the first two issues, the gateway should support Layer 2 of DPNSS. The fourth issue requires a method of transferring bearer (real and virtual) service state information between the MGC and the gateway. This will require the addition of a Service Message to the DPNSS protocol. The Service Message would contain bearer channel service state information. Only a subset of the messages defined in the Functional Specification will be required for backhauling DPNSS over IP. The following Layer-to-Layer messages are used with this configuration: * Establish Request message - This message are sent by the MGC to request that a D-channel be brought in-service. The MGC may request that all DLCs be reset simultaneously or in-sequence. * Establish Response message - This message are sent by the gateway as a response to the Establish Request to indicate that the D-channel is in-service. * Establish Indication message - This message are sent by the gateway to indicate that a D-channel is in-service. Auerbach, Berg & Morneault [Page 15] Internet Draft Signaling Backhaul Protocol Feb 1999 * Establish Confirm message - This message are sent by the MGC to confirm receipt of the Establish Indication message. * Release Request message - This message are sent by the MGC to request that a D-channel be brought out-of-service. * Release Response message - This message are sent by the gateway as a response to the Release Request to indicate that a D-channel is out-of-service. * Release Indication message - This message are sent by the gateway to indicate that a D-channel is out-of-service. * Release Confirm message - This message are sent by the MGC to confirm receipt of the Release Indication message. * Data Request message - This message are sent by the MGC to transmit a PDU. * Data Indication message - This message are sent by the gateway. It contains a received PDU. The following Management messages are used with this configuration: * Mgmt Channel Reset message - This message are sent by the MGC to reset a channel (clear its state to initialized state). * Mgmt Error message - This message can be sent by the MGC or gateway to indicate an error. An example of the message flows for this configuration is shown below. gateway MGC <----------- Mgmt Channel Reset <----------- Establish Request (ESTABLISH_SIMUL_RESET) Establish Response -----------> <----------- Data Request Data Indication -----------> <----------- Data Request Data Indication -----------> <----------- Data Request <----------- Data Request Data Indication -----------> <----------- Release Request (RELEASE_MGMT) Release Response -----------> 4.0 Future Enhancements In the future, support for SCCP and CAS telemetry will be added. Auerbach, Berg & Morneault [Page 16] Internet Draft Signaling Backhaul Protocol Feb 1999 5.0 References [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling System No. 7 (SS7)' [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' [3] ITU-T Recommendation Q.931 (1993), ISDN user-network interface layer 3 specification for basic control [4] ITU-T Recommendation Q.921 (1993), ISDN user-network interface data link layer specification [5] BTNR 188 (January 1995), Digital Private Network Signaling System No1 (DPNSS) 6.0 Author's Addresses David Auerbach Tel: +1-703-484-3464 Cisco Systems Email: dea@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA Diane Berg Tel: +1-703-484-3461 Cisco Systems Email: dberg@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA Ken Morneault Tel: +1-703-484-3323 Cisco Systems Email: kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA