[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/