Network Working Group D. Auerbach INTERNET-DRAFT K. Morneault Cisco Systems R. Stewart Q. Xie Motorola Expires December 1999 5 June 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.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 adaptation modules for backhauling signaling protocols (SS7, ISDN and DPNSS) over packet networks. The adaptation modules are part of the framework referred to as signaling 'backhaul'. These adaptation modules would be used for signaling backhaul between a 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. Morneault, et al [Page 1] Internet Draft Signaling Backhaul Protocol June 1999 TABLE OF CONTENTS 1. Introduction..............................................3 1.1 Backhaul Discussion..................................3 2. Backhaul Design...........................................4 2.1 Design Goals.........................................5 2.2 Message Header.......................................5 2.2.1 Message Types......................................6 2.3 Layer-to-Layer Messages..............................6 2.3.1 Establish..........................................6 2.3.2 Release............................................7 2.3.3 Data...............................................7 2.3.4 MTP3 Data..........................................7 2.3.5 MTP2 Status........................................8 2.3.6 MTP3 Status........................................9 2.3.7 MTP2 Data Retrieval...............................10 2.3.8 MTP2 Data Retrieval Done..........................10 2.3.9 Flow Control......................................10 2.4 Management Messages.................................11 2.4.1 Mgmt Channel Reset................................11 2.4.2 Mgmt Error........................................11 3. Implementation Considerations............................11 3.1 ISDN................................................11 3.2 SS7.................................................14 3.3 DPNSS...............................................17 4. Future Enhancements......................................18 5. References...............................................18 6. Author's Addresses.......................................19 Morneault, et al [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 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. The general principle behind signaling backhaul is to reliably pass layers of a protocol stack through a gateway directly to the MGC. The lower layers (Layer 1 and/or Layer 2 and/or Layer 3) of the protocol stack are terminated on the gateway. This provides the advantage of distributing the protocol processing to allow for greater expandability and scaleability. The higher layers are transported (backhauled) to the MGC for processing. Spliting the signaling protocol stack between particular layers requires the primitives between those layers to be exposed across the IP transport. These primitives are well-documented in the references provided in Section 5.0. The signaling backhaul protocol described in this document provides an adaptation layer for transfering these primitives and information that may be associated with particular primitives. Several examples of scenarios requiring signaling backhaul are provided in Reference 7. Signaling backhaul requires a reliable and fast protocol to transport the signaling protocol over the packet network. The recommendation is to use Multi-Network Datagram Transport Protocol (MDTP) over IP. Refer to Reference 6 for more information on MDTP. Figure 1 below shows the relation between signaling backhaul (adaptation), the signaling protocol, and MDTP. +------------------------------+ | Signaling Application | | (ISUP, MTP3, Q.931, etc.) | +------------------------------+ | Signaling Backhaul | | (Adaptation Layer) | +------------------------------+ | MDTP | +------------------------------+ | UDP | +------------------------------+ Figure 1: Relationship of signaling backhaul to MDTP and signaling application Morneault, et al [Page 3] Internet Draft Signaling Backhaul Protocol Feb 1999 While MDTP is recommended, the signaling backhaul protocol is not dependent upon it. 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: * 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, SAP/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. For example, for backhaul of ISDN the channel identifier could be used to identify the T1/E1 ports of a SG that terminate ISDN D-channels. If MDTP is used for transport and each D-channel is assigned to a MDTP stream, the channel identifier could be used as the opaque stream information in the Stream Initiation datagram. Refer to Reference 6 for more details on MDTP streams and the stream information field. The value of the SAP/channel identifier 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. Morneault, et al [Page 4] Internet Draft Signaling Backhaul Protocol June 1999 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. The initial version is 1.0 (a value of 1). The header for these messages is shown in Figure 2. 0 15 16 31 +---------------+---------------+ | Protocol | Msg | | ID | ID | +---------------+---------------+ | Msg | Channel | | Type | ID | +---------------+---------------+ | Version | Length | | | | +---------------+---------------+ Figure 2, Message Header The types of messages passed between a gateway and a MGC can be categorized as Layer-to-Layer and Management messages. Morneault, et al [Page 5] Internet Draft Signaling Backhaul Protocol June 1999 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 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 | +---------------+---------------+ Morneault, et al [Page 6] Internet Draft Signaling Backhaul Protocol June 1999 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). 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 | +---------------+---------------+ Morneault, et al [Page 7] Internet Draft Signaling Backhaul Protocol June 1999 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 | +---------------+---------------+ 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. Morneault, et al [Page 8] Internet Draft Signaling Backhaul Protocol June 1999 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. 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 Morneault, et al [Page 9] Internet Draft Signaling Backhaul Protocol June 1999 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. 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 | +---------------+---------------+ Morneault, et al [Page 10] Internet Draft Signaling Backhaul Protocol June 1999 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. 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. Figure 3 shows a possible ISDN backhaul scenario. In this case a MG and a SG are collocated in the same piece of equipment. The SG terminates the ISDN D-channels up to Layer 2 (Q.921) and backhauls the Q.931 PDUs to the MGC. The SG does not look at the Q.931 PDUs. Morneault, et al [Page 11] Internet Draft Signaling Backhaul Protocol June 1999 The MGC and SG must coordinate the provisioning of the D-channels so that when the MGC receives a Q.931 PDU it will know which D-channel it came from. The identifier used to identify a D-channel is passed in the channel ID field of the backhaul header. Most likely, a single MDTP association would be created between the MGC and the SG. A stream would be opened for each D-channel and the channel ID would be passed as the opaque stream information. MGCU +-------------+ | [MGC] | | | | +-----|-------+ | | | Q.931/CTP O | +-----|-------+ | | | D-chan[0] -|----[SG] | | | | | | | D-chan[1] -|----[SG] | | | +-------------+ SGU/MGU Note: The bearers (device control) associated with the D-channels are not shown. Figure 3: Possible ISDN backhaul scenario 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. Morneault, et al [Page 12] Internet Draft Signaling Backhaul Protocol June 1999 * 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. 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 -----------> Morneault, et al [Page 13] Internet Draft Signaling Backhaul Protocol June 1999 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. 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. Morneault, et al [Page 14] Internet Draft Signaling Backhaul Protocol June 1999 * 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. 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. Morneault, et al [Page 15] Internet Draft Signaling Backhaul Protocol June 1999 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 ----------> 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 ----------> Morneault, et al [Page 16] Internet Draft Signaling Backhaul Protocol June 1999 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. * 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. Morneault, et al [Page 17] Internet Draft Signaling Backhaul Protocol June 1999 * 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. 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 Morneault, et al [Page 18] Internet Draft Signaling Backhaul Protocol June 1999 [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] Stewart, R. etc, "Multi-Network Datagram Transport Protocol", Internet Draft , June 1999 [7] Ong, L. etc, "Architectural Framework for Signaling Transport", Internet Draft