Network Working Group D. Auerbach
INTERNET-DRAFT D. Berg
K. Morneault
Cisco Systems
Expires in six months 25 Feburary 1999
SIGNALING BACKHAUL PROTOCOL
<draft-ietf-sigtran-signaling-backhaul-00.txt>
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
Datatracker
Report a datatracker bug
draft-ietf-sigtran-signaling-backhaul-00
None
| Document | Document type |
Expired Internet-Draft
(sigtran WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Roger Stewart
,
David Auerbach
,
Diane Berg
,
Ken Morneault
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |