Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-bidulock-sigtran-isua-00

Description: Request For Comments

You can download source copies of the file as follows:

draft-bidulock-sigtran-isua-00.txt in text format.
draft-bidulock-sigtran-isua-00.ps in ps format.
draft-bidulock-sigtran-isua-00.pdf in pdf format.

Listed below is the contents of file draft-bidulock-sigtran-isua-00.txt.




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation

Expires in six months                                    January 5, 2003

                     SS7 ISUP-User Adaptation Layer
                                  ISUA
                  <draft-bidulock-sigtran-isua-00.txt>

Status of this Memo

     This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 or 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 document defines a protocol for the transport of any SS7 ISUP-
  User signalling (e.g, Call Control) over IP using the Stream Control
  Transport Protocol [RFC 2960].  The protocol should be modular and
  symmetric, to allow it to work in diverse architectures, such as a
  Signalling Gateway and IP Signalling End-point architecture.  Protocol
  elements are added to allow seamless operation between peers in the
  SS7 and IP domains.

Contents

     A complete table of contents appears the end of this document.

B. Bidulock                    Version 0.0                        Page 1

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

1.  Introduction

     This draft defines a protocol for the transport of SS7 ISUP [Q.761,
  T1.113] Users (i.e, Call Control) signalling messages over IP using
  the Stream Control Transmission Protocol (SCTP) [RFC 2960].  This
  protocol would be used between a Signalling Gateway (SG) and
  Signalling End-point located in an IP network.  Additionally, the
  protocol can be used to transport SS7 ISUP users between two
  signalling end-points located within an IP network.

1.1.  Scope

     There is on-going integration of SCN networks and IP networks.
  Network service providers are designing all IP architectures that
  include support for SS7 signalling protocols.  IP provides an
  effective way to transport user data and for operators to expand their
  networks and build new services.  In these networks, there is a need
  for interworking between the SS7 and IP domains [RFC 2719].

     This document details the delivery of Call Control messages over IP
  between two signalling end-points.  Consideration is given for the
  transport from an SS7 Signalling Gateway (SG) to an IP signalling node
  (such as an IP-resident Database) as described in the Framework
  Architecture for Signalling Transport [RFC 2719] This protocol can
  also support transport of Call Control messages between two end-points
  wholly contained within and IP network.

  The delivery mechanism addresses the following criteria:

   - Support for transfer of ISUP messages (Call Control)
   - Support for the seamless operation of Call Control protocol peers.
   - Support for the management of SCTP transport associations between
     an SG and one ore more IP-based signalling nodes.
   - Support for distributed IP-based signalling nodes.
   - Support for the asynchronous reporting of status changes to
     management.

1.2.  Change History

    EDITOR'S NOTE:-  This change history section will be deleted if
    and when the draft is advanced.

1.2.1.  Version 0.0

     This is the initial version of this document.

1.3.  Terminology

  Application Server (AS) - a logical entity serving a specific Routing
     Key.  An example of an Application Server is a virtual database
     element handling all HLR or SCP transactions for a particular SS7
     Signalling Point.  The AS contains a set of one or more unique
     Application Server Processes, of which one or more is normally

B. Bidulock                    Version 0.0                        Page 2

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

     actively processing traffic.  There is a one-to-one relationship
     between an Application Server and a Routing Key.

  Application Server Process (ASP) - a process instance of an
     Application Server.  An Application Server Process serves as an
     active, backup, load-share or broadcast process of an Application
     Server (e.g, part of a distributed signalling node or database
     element).  Examples of ASPs are MGCs, IP SCPs, or IP HLRs.  An ASP
     contains an SCTP end-point and may be configured to process traffic
     within more that one Application Server.

  Association - refers to an SCTP association [RFC 2960].  The
     association provides the transport for the delivery of ISUP
     protocol data units and ISUA layer peer messages.

  Call Control - The layer above the ISDN User Part in the SS7 protocol
     stack that exchanges primitives with the ISUP provider.  Call
     Control has two major functional blocks: Call Processing and
     Circuit Supervision.  Unlike other layers of the SS7 stack, ISUP
     does not have individual "Users" or ISUP-SAPs.  A single Call
     Control entity is responsible for controlling both ISUP and other
     switch signalling stacks at the Application Layer of the ISO
     7-layer model.  for

  Call Processing] - Call Processing is a major functional block of both
     ISUP and Call Control which is responsible for signalling and
     controlling the state of calls (as opposed to circuits).

  Circuit Supervision] - Circuit Supervision is a major functional block
     of both ISUP and Call Control which is responsible for signalling
     and controlling the state of circuits (as opposed to calls).

  Fail-over - the capability to reroute signalling traffic as required
     to an alternate Application Server Process, or group of ASPs,
     within an Application Server in the event of failure or
     unavailability of a currently used Application Server Process.
     Fail-over may apply upon the return to service of a previously
     unavailable Application Server Process.

  Host - the computing platform that the process (SGP, ASP or IPSP) is
     running on.

  IP Server Process (IPSP) - a process instance of an IP-based
     application.  An IPSP is essentially the same as an ASP, except
     that it uses ISUA in a point-to-point fashion.

  ISDN User Part (ISUP) - The Integrated Services Digital Network (ISDN)
     User Part [Q.761, T1.113] of the SS7 protocol.

  Layer Management (LM) - a nodal function that handles the inputs and
     outputs between the ISUA layer and a local management entity.

  Message Transfer Part (MTP) - The Message Transfer Part [Q.701,
     T1.111] of the SS7 protocol.

B. Bidulock                    Version 0.0                        Page 3

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Nodal Interworking Function (NIF) - an implementation dependent
     interworking function present at a Signalling Gateway that
     interworks primitives and procedures between the ISUP and ISUA
     layers in the SG.

  Network Appearance (NA) - a value that identifies the SS7 network
     context of a Routing Key.  The Network Appearance value is of
     significance only within an administrative domain; it is
     coordinated between the SG and ASP.

  Network Byte Order - the ordering of bytes most-significant-byte
     first, also referred to as Big Endian.

  Routing Context (RC) - a value that uniquely identifies a Routing Key
     and an Application Server.  Routing Context values are either
     configured using a configuration management interface, or by using
     the Routing Key Management (RKM) messages and procedures defined
     for ISUA.

  Routing Key (RK) - describes a set of SS7 parameters and parameter
     values that uniquely define the range of signalling traffic to be
     handled by a particular Application Server.

  Signalling Gateway (SG) - a signalling agent that exchanges SCN native
     signalling at the edge of the IP network [RFC 2719].  An SG appears
     to the SS7 network as an SS7 Signalling Point.  An SG contains a
     set of one or more Signalling Gateway Processes, of which one or
     more is normally actively processing traffic.  When an SG contains
     more than one SGP, the SG is a logical entity and the contained
     SGPs are assumed to be coordinated into a single management view
     both toward the SS7 network and toward the supported Application
     Servers.

  Signalling Gateway Process (SGP) - a process instance of a Signalling
     Gateway.  It serves as an active, backup, load-sharing or broadcast
     process of a Signalling Gateway.

  Stream - an SCTP stream; a unidirectional logical channel established
     from one SCTP endpoint to another associated SCTP endpoint, within
     which all user messages are delivered in sequence, except for those
     submitted to the unordered delivery service.

  Circuit Mapping Function (CMF) - an implementation dependent function
     that is responsible for resolving the address and application
     context presented in the incoming ISUA message to the correct SCTP
     association and Routing Context for the desired application.  The
     CMF MAY use routing context or routing key information as selection
     criteria for the appropriate SCTP association.

  Transport Address - an address that serves as a source or destination
     for the unreliable packet transport service used by SCTP.  In IP
     networks, a transport address is defined by the combination of IP
     address and an SCTP port number [1].

B. Bidulock                    Version 0.0                        Page 4

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

1.4.  ISUA Overview

1.4.1.  Signalling Transport Architecture

     The framework architecture that has been defined for SCN signalling
  transport over IP [RFC 2719] uses multiple components, including an IP
  transport protocol, a signalling common transport protocol and an
  adaptation module to support the services expected by a particular SCN
  signalling protocol from its underlying protocol layer.

     In general terms, the ISUA architecture can be modeled as a peer-
  to-peer architecture.  The first section considers the SS7-to-IP
  interworking architectures for ISUP call control.  For this case, it
  is assumed that the ASP initiates the establishment of the SCTP
  association with the SG.

1.4.2.  Protocol Architecture for Call Control

     In this architecture (illustrated in Figure 1), the ISUP and ISUA
  layers interface in the SG.  A Nodal Interworking Function (NIF)
  provides for interworking between the ISUP and ISUA layers and
  provides for the transfer of the call processing as well as circuit
  supervision messages.

          .........         ...............        .........
          :       :         :             :        :       :
          :  SEP  :   SS7   :             :   IP   :       :
          :   or  :.........:     SG      :........:  ASP  :
          :  STP  :         :             :        :       :
          :.......:         :.............:        :.......:
           _______           _____________          _______
          |       |         |             |        |       |
          |  CC   |         |     NIF     |        |  CC   |
          |-------|         |------ ------|        |-------|
          | ISUP  |         | ISUP | ISUA |        | ISUA  |
          |-------|         |------|------|        |-------|
          | MTP3  |         | MTP3 |      |        |       |
          |-------|         |------| SCTP |        | SCTP  |
          | MTP2  |         | MTP2 |      |        |       |
          |-------|         |------|------|        |-------|
          |  L1   |         |  L1  |  IP  |        |  IP   |
          |_______|         |______|______|        |_______|
              |                |       |               |
              |________________|       |_______________|

                 CC  - Call Control
                 STP - SS7 Signaling Transfer Point
                 NIF - Nodal Interworking Function

                   Figure 1.  Protocol Architecture

B. Bidulock                    Version 0.0                        Page 5

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

1.4.3.  All IP Architecture

     This architecture, illustrated in Figure 2, can be used to carry a
  protocol which uses the transport services of ISUP, but is contained
  within an IP network.  This allows extra flexibility in developing
  networks, especially when interaction between legacy signalling is not
  needed.  The architecture removes the need for a signalling gateway
  function.

                   ........        ........
                   :      :   IP   :      :
                   :  AS  :........:  AS  :
                   :      :        :      :
                   :......:        :......:
                    ______          ______
                   |      |        |      |
                   |  AP  |        |  AP  |
                   |------|        |------|
                   | ISUA |        | ISUA |
                   |------|        |------|
                   | SCTP |        | SCTP |
                   |------|        |------|
                   |  IP  |        |  IP  |
                   |______|        |______|
                      |                |
                      |________________|

           AP - Application Protocol (e.g. - Call Control)

                    Figure 2.  All IP Architecture

1.4.4.  ASP Fail-over Model and Terminology

     The ISUA protocol supports ASP fail-over functions to support a
  high availability of transaction processing capability.

     An Application Server can be considered as a list of all ASPs
  configured or registered to handled Call Control messages within a
  certain range of routing information, or within a certain set of
  transaction dialogues, known as a `Routing Key.'  One or more ASPs in
  the list may normally be active to handle traffic, while others may be
  inactive but available in the event of failure or unavailability of
  the active ASPs.

     For operational considerations, see Appendix A.

1.4.5.  Services Provided by the ISUA Layer

1.4.5.1.  Support for the transport of Call Control Messages

     The ISUA supports the transfer of Call Control messages.  The ISUA
  layer at the SG and the ASP support the seamless transport of user
  messages between the SG and the ASP.

B. Bidulock                    Version 0.0                        Page 6

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

1.4.5.1.1.  ISUP Call Control Support

     Depending on the specific implementation of Call Control supported,
  the ISUA shall support Call Control transparently.  Call Control
  consists of two major functional blocks:

     Call Processing is responsible for signalling and control of calls
  (as opposed to circuits).  Call processing functions move a call
  through its life-cycle by providing the following functions:

   - call setup,
   - call suspend/resume,
   - call release,
   - call exception handling.

     Circuit Supervision is responsible for signalling and control of
  circuits (as opposed to calls).  Circuit supervision functions affect
  the management state of circuits and provides the following functions:

   - circuit testing,
   - circuit reset,
   - circuit blocking and unblocking due to hardware failure and
     recovery events,
   - circuit blocking and unblocking maintenance action,
   - circuit state query.

1.4.5.2.  Native Management Functions

     The ISUA layer provides the capability to indicate errors
  associated with the ISUA protocol messages and to provide notification
  to local circuit management and the remote peer as necessary.

1.4.5.3.  Interworking with Circuit Supervision Functions

     The ISUA layer provides interworking with Circuit Supervision
  functions at the SG for seamless inter-operation between the SCN
  network and the IP network.  ISUA provides the following circuit
  supervision functions:

   - Provides an indication or accpets a request to perform a continuity
     check on a circuit.
   - Provides an indication or accepts a request to reset a circuit or
     circuit group.
   - Provides an indication or accepts a request to block a circuit or
     circuit group.
   - Provides an indication or accepts a request to unblock a circuit or
     circuit group.
   - Provides an indication or accepts a request to query a circuit or
     circuit group.

     The interworking with ISUP circuit supervision messages consists of
  CCNT, CCNA, CREP, CRSC, CBLO, CBLA, CUBL, CUBA, CQRY and CQRA messages
  on receipt of circuit supervision events to the appropriate ASPs.  The

B. Bidulock                    Version 0.0                        Page 7

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

           Table 1. Mapping of Circuit Supervision Primitives

  +---------------------------+---------------------------+------------+
  |           Name            |          Message          |    ISUA    |
  +--------------+------------+-------------+-------------+ Cc't Supv. |
  | Generic [2]  | Specific   | ITU-T Q.764 | ANSI T1.113 |  Message   |
  +--------------+------------+-------------+-------------+------------+
  |CONT RECHECK  | Request    |     CCR     |     CCR     |    CCNT    |
  |              | Indication |             |             |            |
  |              +------------+-------------+-------------+------------+
  |              | Response   |      -      |     LPA     |    CCNA    |
  |              | Confirm    |             |             |            |
  +--------------+------------+-------------+-------------+------------+
  |CONT REPORT   | Request    |     COT     |     COT     |    CREP    |
  |              | Indication |             |             |            |
  +--------------+------------+-------------+-------------+------------+
  |RESET         | Request    |  RSC, GRS   |  RSC, GRS   |    CRSC    |
  |              +------------+-------------+-------------+------------+
  |              | Confirm    |  RLC, GRA   |  RLC, GRA   |    CRSA    |
  +--------------+------------+-------------+-------------+------------+
  |BLOCKING      | Request    |  BLO, CGB   |  BLO, CGB   |    CBLO    |
  |              | Indication |             |             |            |
  |              +------------+-------------+-------------+------------+
  |              | Response   |  BLA, CGBA  |  BLA, CGBA  |    CBLA    |
  |              | Confirm    |             |             |            |
  +--------------+------------+-------------+-------------+------------+
  |UNBLOCKING    | Request    |  UBL, CGU   |  UBL, CGU   |    CUBL    |
  |              | Indication |             |             |            |
  |              +------------+-------------+-------------+------------+
  |              | Response   |  UBA, CGUA  |  UBA, CGUA  |    CUBA    |
  |              | Confirm    |             |             |            |
  +--------------+------------+-------------+-------------+------------+
  |CCT GRP QUERY | Request    |     CQM     |     CQM     |    CQRY    |
  |              | Indication |             |             |            |
  |              +------------+-------------+-------------+------------+
  |              | Response   |     CQR     |     CQR     |    CQRA    |
  |              | Confirm    |             |             |            |
  +--------------+------------+-------------+-------------+------------+

  primitives in Table 1 are sent between the ISUP and ISUA circuit
  supervision functions in the SG to trigger events in the IP and SS7
  domain.

     The ISUA layer provides transparent passing of circuit reset,
  blocking and query primitives (RESET, BLOCKING, UNBLOCKING, CCT GROUP
  QUERY) as provided for in ITU-T Q.724 [Q.724] Q.764 [Q.764], and ANSI
  T1.113 [T1.113].

1.4.5.4.  Support for the Management of SCTP Associations

     The ISUA layer at the SGP maintains the availability state of all
  configured remote ASPs, to manage the SCTP Associations and the

B. Bidulock                    Version 0.0                        Page 8

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  traffic between ISUA peers.  As well, the active/inactive and
  congestion state of remote ASPs is maintained.

     The ISUA layer MAY be instructed by local management to establish
  an SCTP association to a peer ISUA node.  This can be achieved using
  the M-SCTP_ESTABLISH primitives to request, indicate and confirm the
  establishment of an SCTP association with a peer ISUA node.  To avoid
  redundant SCTP associations between two ISUA peers, one side (client)
  SHOULD be designated to establish the SCTP association, or ISUA
  configuration information maintained to detect redundant associations
  (e.g, via knowledge of the expected local and remote SCTP endpoint
  addresses).

     Local management MAY request from the ISUA layer the status of the
  underlying SCTP associations using the M-SCTP_STATUS request and
  confirm primitives.  Also, the ISUA MAY autonomously inform local
  management of the reason for the release of an SCTP association,
  determined either locally within the ISUA layer or by a primitive from
  the SCTP.

     Also, the ISUA layer MAY inform the local management of the change
  in status of an ASP or AS.  This MAY be achieved using the M-
  ASP_STATUS request or M-AS_STATUS request primitives.

1.5.  Functional Areas

1.5.1.  Circuit Identifiers, Routing Contexts and Routing Keys

1.5.1.1.  Overview

     The mapping of ISUP messages into calls between the SGP and the
  Application Servers is determined by Circuit Identifiers, Routing Keys
  and their associated Routing Contexts.

     A Routing Key is essentially a set of ISUP parameters used to
  direct ISUP messages; whereas, the Routing Context parameter is a
  4-byte value (unsigned integer) that is associated to that Routing Key
  in a one-to-one relationship.  The Routing Context therefore can be
  viewed as an index into a sending node's Circuit Mapping Function
  tables containing the Routing Key entries.

     Possible ISUP address/routing information that comprise a Routing
  Key entry includes, for example, a local and remote Point Code, and a
  Circuit Identification Code or Call Control specific information such
  as Circuit Group or Trunk Group Identifiers.  The particular
  information used to define a ISUA Routing Key is application and
  network dependent, and none of the above examples are requirements for
  ISUA.

     An Application Server Process (ASP) may be configured to process
  signalling traffic related to more than one Application Server (AS),
  over a single SCTP Association.  ASP Active (ASPAC) and ASP Inactive
  (ASPIA) management messages (see Section 3) use the Routing Context to
  discriminate signalling traffic to be started or stopped.  At an ASP,

B. Bidulock                    Version 0.0                        Page 9

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  the Routing Context parameter uniquely identifies the range of
  signalling traffic associated with each Application Server that the
  ASP is configured to receive.

1.5.1.2.  Routing Key Limitations

     Routing Keys SHOULD be unique in the sense that each received ISUP
  message SHOULD have a full or partial match to a single routing
  result.  It is not necessary for the parameter range values within a
  particular Routing Key to be continuous.  For example, an AS could be
  configured to support call processing for multiple ranges of circuits
  that are not represented by contiguous Circuit Identification Codes.

1.5.1.3.  Managing Routing Context and Routing Keys

     There are two ways to provision a Routing Key at an SGP.  A Routing
  Key may be configured statically using an implementation dependent
  management interface, or dynamically managed using the the ISUA
  Routing Key registration procedures.

     When using a management interface to configure Routing Keys, the
  Circuit Mapping Function within the SGP is not limited to the set of
  parameters defined in this document.  Other implementation dependent
  distribution algorithms may be used.

1.5.1.4.  Circuit Mapping Function

     To perform its addressing and relaying capabilities, the ISUA makes
  use of an Circuit Mapping Function (CMF).  This function is considered
  part of ISUA, but the way it is realized is left implementation or
  deployment dependent (local tables, database, etc.)

     The CMF is invoked when a message is received at the incoming
  interface.  The CMF is responsible for resolving the Circuit
  Identification Code (CIC) and any necessary ISUP message parameters
  presented in the incoming ISUP message to SCTP associations and
  destinations within the IP network.  The CMF will select the key
  information available.  The Routing Keys reference an Application
  Server, which will normally have one or more ASPs processing
  transactions for the AS.  The availability and status of the ASPs is
  handled by ISUA ASP management messages.

     Possible SS7 routing information that comprise a Routing Key entry
  includes, for example, ISUP Circuit Identification Code (CIC), Range
  and Status parameters.

     It is expected that the routing keys will be provisioned via a MIB,
  dynamic registration or an external process, such as a database.

1.5.1.4.1.  Circuit Mapping at the SG

     To direct messages received from the SS7 network to the appropriate
  IP destination, the SGP must perform a circuit mapping function using
  information from the received ISUP message.

B. Bidulock                    Version 0.0                       Page 10

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

     To support this circuit mapping, the SGP might, for example,
  maintain the equivalent of a network address translation table,
  mapping incoming ISUP message information to an Application Server for
  a particular application and set of transactions.  This could be
  accomplished by comparing the circuit identification code and range
  and status portions of the incoming ISUP message to currently defined
  Routing Keys in the SGP.  These Routing Keys could in turn map
  directly to an Application Server that is enabled by one or more ASPs.
  These ASPs proxy dynamic status information regarding their
  availability, call handling capabilities and congestion to the SGP
  using various management messages defined in the ISUA protocol.

     The list of ASPs in the AS is assumed to be dynamic, taking into
  account the availability, call handling capability and congestion
  status of the individual ASPs in the list, as well as configuration
  changes and possible fail-over mechanisms.

     Normally, one or more ASPs are active in the AS (i.e, currently
  processing calls) but in certain failure and transition cases it is
  possible that there may not be an active ASP available.  The SGP will
  buffer the message destined for this AS for a time T(r) or until an
  ASP becomes available.  When no ASP becomes available before expiry of
  T(r), the SGP will flush the buffered messages and initiate the
  appropriate ISUP call clearing procedures.

     If there is no match for an incoming message, a default treatment
  MAY be specified.  Possible solutions are to provide a default
  Application Server to direct all unallocated call processing and
  circuit supervision messges to a (set of) default ASP(s), or to drop
  the messages and provide a notification to management.  The treatment
  of unallocated circuits is implementation dependent.

1.5.1.4.2.  Circuit Mapping at the ASP

     To direct messages to the SS7 network, the ASP MAY perform a
  circuit mapping to choose the proper SGP for the given message.  This
  is accomplished by observing the Circuit Identification Code, Range
  and Status, and other elements of the outgoing message, SS7 network
  status, SGP availability, and Routing Context configuration tables.

     A Signalling Gateway may be composed of one or more SGPs.  There
  is, however, no ISUA messaging to manage the status of an SGP.
  Whenever an SCTP association to an SGP exists, it is assumed to be
  available.  Also, every SGP of one SG communicating with one ASP
  regarding one AS provides identical call control to this ASP.

     In general, an ASP routes responses to the SGP that it received
  messages from; within the routing context which it is currently active
  and receiving transactions.  The routing context itself is used by the
  ASP to select the SGP.

B. Bidulock                    Version 0.0                       Page 11

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

1.5.1.5.  Signalling Gateway SS7 Layers

     The SG is responsible for terminating up to the Call Control of the
  SS7 protocol, and offering an IP-based extension to its users.

     From an SS7 perspective, it is expected that the Signalling Gateway
  transmits and receives ISUP messages to and from the SS7 Network over
  standard SS7 network interfaces, using the services of the MTP [Q.704]
  to provide transport of the messages.

     Note that it is also possible for the MTP services to be provided
  using the services of the MTP-User Adaptation Layer (M3UA) [M3UA].

     The ISUP-SAP through which ISUA at the SG obtains its services
  could reside at a Signalling Transfer Point (STP) or Signalling End
  Point (SEP) [Q.701].

1.5.1.6.  SS7 and ISUA Interworking at the SG

     The SGP provides a functional interworking of transport functions
  between the SS7 network and the IP network by also supporting the ISUA
  adaptation layer.  It allows the ISUP application to exchange call
  control messages with an IP-based Application Server Process where the
  peer Call Control protocol layer exists.

     To perform ISUP circuit supervision, it is required that the Call
  Control protocols at ASPs receive indications of circuit state, as
  well as call state as they would be expected by an SS7 ISUP
  application.  To accomplish this, the RESET, BLOCKING, UNBLOCKING and
  CCT GROUP QUERY primitives received at the ISUP upper layer interface
  at the SG need to be propagated to the remote Call Control lower layer
  interface at the ASP.

     ISUP call processing and circuit supervision mesages (such as BLO,
  BLA, CGB, CGBA) received from the SS7 network MUST NOT be
  encapsulated.  The SG MUST terminate these messages and generate ISUA
  message as appropriate.

1.5.1.7.  Application Server

     A cluster of Application Servers is responsible for providing the
  overall support for one ore more SS7 upper layers.  From an ISUP
  standpoint, Call Control provides complete support for the upper layer
  service for given Circuits or Trunk Groups.  As an example, Call
  Control could provide complete support for Central Office Call Control
  for a given point code.

1.5.1.8.  SCTP Stream Mapping

     The ISUA supports SCTP streams.  The SG and AS need to maintain a
  list of SCTP and Call Control for mapping purposes.  Call Control
  requiring sequenced message transfer need to be sent over a stream
  using sequenced delivery.

B. Bidulock                    Version 0.0                       Page 12

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

     ISUA SHOULD NOT use stream 0 for ISUA circuit supervision messages.
  It is OPTIONAL that sequence delivery be used to preserve the order of
  circuit supervision message delivery.

     All ISUA Circuit Supervision (CS) messages MAY select unordered
  delivery, depending on the requirements of Call Control.  Normally one
  stream is used to send ISUA Circuit Supervision (CS) messages between
  peers, regardless of Application Server.

     All Call Processing (CP) messages MUST be sent using ordered
  delivery.  All Call Processing (CP) messages relating to the same call
  MUST be sent on the same stream as other Call Processing (CP) messages
  relating to the same call.  The stream selected is based upon the Call
  Reference given by the Call Control over the primitive interface and
  other traffic information available to the SGP or ASP.

1.5.2.  Redundancy Models

1.5.2.1.  Application Server Redundancy

     All CSET and Circuit Supervision (CS) messages (e.g, SETUP, RESET,
  BLOCKING) which match a provisioned Routing Key at an SGP are mapped
  to an Application Server.

     The Application Server is the set of all ASPs associated with a
  specific Routing Key.  Each ASP in this set may be active, inactive or
  unavailable.  Active ASPs handle traffic; inactive ASPs might be used
  when active ASPs become unavailable.

     The fail-over model supports an "n+k" redundancy model, where "n"
  ASPs is the minimum number of redundant ASPs required to handle
  traffic and "k" ASPs are available to take over for a failed or
  available ASP.  A "1+1" active/backup redundancy is a subset of this
  model.  A simplex "1+0" model is also supported as a subset, with no
  ASP redundancy.

1.5.3.  Flow Control

     Local Management at an ASP may wish to stop traffic across an SCTP
  association to temporarily remove the association from service or to
  perform testing and maintenance activity.  The function could
  optionally be used to control the start of traffic onto a newly
  available SCTP association.

1.5.4.   Congestion Management

     The ISUA layer is informed of local and IP network congestion by
  means of an implementation-dependent function (e.g, an implementation-
  dependent indication from the SCTP of IP network congestion).

     At an ASP or IPSP, the ISUA layer indicates congestion to local
  Call Control by means of an appropriate ISUP primitive, as per current
  ISUP procedures, to invoke appropriate upper layer responses.  When an
  SG determines that the transport of SS7 messages is encountering

B. Bidulock                    Version 0.0                       Page 13

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  congestion, the SG might trigger SS7 Congestion messages to
  originating SS7 nodes, per the congestion procedures of the relevant
  ISUP [Q.764, T1.113] or MTP [Q.704, T1.111] standard.  (The triggering
  of SS7 Management messages from an SG is an implementation-dependent
  function.)

1.6.  Definition of ISUA Boundaries

     ISUA has three protocol boundaries: an upper boundary between ISUA
  and Call Control; a lower boundary between ISUA and SCTP; and a layer
  management boundary between ISUA and the Layer Management Function.
  Figure 3 illustrates the ISUA protocol boundaries.

                      ...........
                      :   CC    :
                      :.........:  Layer
            Upper Boundary :       Management
                       ____:____   Boundary   ............
                      |   ISUA  |.............:    LM    :
                      |_________|             :..........:
            Lower Boundary :
                      .....:.....
                      :   SCTP  :
                      :.........:

                 Figure 3.  ISUA Protocol Boundaries

1.6.1.  Definition of Upper Boundary

     The primitives and messages listed in Table 2 are provided between
  the ISUA and Call Control in support of Call Control [Q.761, T1.113].

               Table 2. Mapping of Call Control Primitives

    +-------------+------------+---------------+---------------+------+
    |Generic      | Specific   |  ITU-T Q.764  |  ANSI T1.113  | ISUA |
    |Name         | Name       |    Message    |    Message    | Msg  |
    +-------------+------------+---------------+---------------+------+
    |Call Setup Messages                                              |
    +-------------+------------+---------------+---------------+------+
    |SETUP        | Request    |      IAM      |      IAM      | CSET |
    |             | Indication |               |               |      |
    |             +------------+---------------+---------------+------+
    |             | Response   |   ANM, CON    |      ANM      | CCON |
    |             | Confirm    |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |MORE INFO    | Request    |       -       |       -       | CMOR |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+

B. Bidulock                    Version 0.0                       Page 14

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

    +-------------+------------+---------------+---------------+------+
    |Generic      | Specific   |  ITU-T Q.764  |  ANSI T1.113  | ISUA |
    |Name         | Name       |    Message    |    Message    | Msg  |
    +-------------+------------+---------------+---------------+------+
    |TIMEOUT      | Indication |       -       |       -       | CTOT |
    +-------------+------------+---------------+---------------+------+
    |INFO         | Request    |      SAM      |      SAM      | CINF |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |PROC         | Request    |   ACM, CPG    |   ACM, CPG    | CPRO |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |ALERT        | Request    |   ACM, CPG    |   ACM, CPG    | CALR |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |PROG         | Request    |   ACM, CPG    |   ACM, CPG    | CPRG |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |Call Established Messages                                        |
    +-------------+------------+---------------+---------------+------+
    |SUSPEND      | Request    |      SUS      |      SUS      | CSUS |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |RESUME       | Request    |      RES      |      RES      | CRES |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |Call Termination Messages                                        |
    +-------------+------------+---------------+---------------+------+
    |REATTEMPT    | Indication |       -       |       -       | CREA |
    +-------------+------------+---------------+---------------+------+
    |CALL FAILURE | Indication | RST, REL, RLC | RST, REL, RLC | CERR |
    +-------------+------------+---------------+---------------+------+
    |IBI          | Request    |   ACM, CPG    |   ACM, CPG    | CIBI |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |RELEASE      | Request    |      REL      |      REL      | CREL |
    |             | Indication |               |               |      |
    |             +------------+---------------+---------------+------+
    |             | Response   |   REL, RLC    |   REL, RLC    | CRLC |
    |             | Confirm    |               |               |      |
    +-------------+------------+---------------+---------------+------+

1.6.2.  Definition of Boundary between ISUA and Layer Management

  M-SCTP_ESTABLISH request
  Direction: LM->ISUA
  Purpose:   LM request ASP to establish an SCTP association with its
             peer.

  M-SCTP_ESTABLISH confirm
  Direction: ISUA -> LM

B. Bidulock                    Version 0.0                       Page 15

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Purpose:   ASP confirms to LM that it has established an SCTP
             association with its peer.

  M-SCTP_ESTABLISH indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that a remote ASP has established an SCTP
             association.

  M-SCTP_RELEASE request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to release an SCTP association with its
             peer.

  M-SCTP_RELEASE confirm
  Direction: ISUA -> LM
  Purpose:   ASP confirms to LM that it has released SCTP association
             with its peer.

  M-SCTP_RELEASE indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that a remote ASP has released an SCTP
             Association or the SCTP association has failed.

  M-SCTP RESTART indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that an SCTP restart indication has been
             received.

  M-SCTP_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of an SCTP
             association.

  M-SCTP_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA responds with the status of an SCTP association.

  M-SCTP_STATUS indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports the status of an SCTP association.

  M-ASP_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of a local or
             remote ASP.

  M-ASP_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA reports status of local or remote ASP.

  M-AS_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of an AS.

B. Bidulock                    Version 0.0                       Page 16

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  M-AS_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA reports the status of an AS.

  M-NOTIFY indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that it has received a Notify (NTFY) message
             from its peer.

  M-ERROR indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that it has received an Error (ERR) message
             from its peer or that a local operation has been
             unsuccessful.

  M-ASP_UP request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to start its operation and send an ASP Up
             (ASPUP) message to its peer.

  M-ASP_UP confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that is has received an ASP UP Ack (ASPUP
             ACK) message from its peer.  T} ; ls l1lw(5.7i).  M-
             ASP_UP indication Direction:;ISUA -> LM Purpose:;T{ ISUA
             reports it has successfully processed an incoming ASP Up
             (ASPUP) message from its peer.

  M-ASP_DOWN request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to stop its operation and send an ASP
             Down (ASPDN) message to its peer.

  M-ASP_DOWN confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that is has received an ASP Down Ack (ASPDN
             ACK) message from its peer.

  M-ASP_DOWN indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Down (ASPDN) message from its peer, or the SCTP
             association has been lost or reset.

  M-ASP_ACTIVE request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to send an ASP Active (ASPAC) message to
             its peer.

  M-ASP_ACTIVE confirm
  Direction: ISUA -> LM

B. Bidulock                    Version 0.0                       Page 17

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Purpose:   ASP reports that is has received an ASP Active Ack (ASPAC
             ACK) message from its peer.

  M-ASP_ACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Active (ASPAC) message from its peer.

  M-ASP_INACTIVE request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to send an ASP Inactive (ASPIA) message
             to its peer.

  M-ASP_INACTIVE confirm
  Direction: LM -> ISUA
  Purpose:   ASP reports that is has received an ASP Inactive Ack
             (ASPIA ACK) message from its peer.

  M-ASP_INACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Inactive (ASPIA) message from its peer.

  M-AS_ACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that an AS has moved to the AS-ACTIVE state.

  M-AS_INACTIVE indication
  Direction: ISUA -> LM
  Purpose:   UA reports that an AS has moved to the AS-INACTIVE state.

  M-AS_DOWN indication
  Direction: ISUA -> LM
  Purpose:   UA reports that an AS has moved to the AS-DOWN state.

  M-RK_REG request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to register RK(s) with its peer by
             sending Registration Request (REG REQ) message

  M-RK_REG confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that it has received Registration Response
             (REG RSP) message with registration status as successful
             from its peer.

  M-RK_REG indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that it has successfully processed an
             incoming Registration Request (REG REQ) message.

  M-RK_DEREG request
  Direction: LM -> ISUA

B. Bidulock                    Version 0.0                       Page 18

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Purpose:   LM requests ASP to deregister RK(s) with its peer by
             sending Deregistration Request (DEREG REQ) message.

  M-RK_DEREG confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that it has received Deregistration Request
             (DEREG REQ) message with deregistration status as
             successful from its peer.

  M-RK_DEREG indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that it has successfully processed an
             incoming Deregistration Request (DEREG REQ) message from
             its peer.

1.6.3.  Definition of the Lower Boundary

  The upper layer primitives provided by the SCTP are provided in the
  SCTP specification "Stream Control Transmission Protocol (SCTP)" [RFC
  2960].

2.  Conventions

     The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
  appear in this document, are to be interpreted as described in [RFC
  2119].

  In this document, the following conventions are used to describe how a
  parameter is used in the message:

    Mandatory     The parameter MUST be present in the message.  A
                  message listing a parameter as Mandatory without
                  containing such a parameter is is incorrectly
                  formatted.

    Conditional   The parameter SHOULD be present in the message
                  under the conditions specified.  A message listing
                  a parameter as Conditional without containing such
                  a parameter under the conditions specified is
                  incorrectly formatted.

    Optional      The parameter MAY be present in the message as
                  specified.  A message listing a parameter as
                  Optional without containing such a parameter is
                  correctly formatted.

3.  Protocol Elements

     The general message format includes a Common Message Header
  together with a list of zero or more parameters as defined by the

B. Bidulock                    Version 0.0                       Page 19

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Message Type.

     For forward compatibility, all Message Types MAY have attached
  parameters even if none are specified in this version.

3.1.  Common Message Header

     The protocol messages for the ISUP-User Adaptation Protocol (ISUA)
  require a message structure that contains a version, message type,
  message length and message contents:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    |   Reserved    | Message Class | Message Type  |
    +---------------+---------------+---------------+---------------+
    |                        Message Length                         |
    +---------------------------------------------------------------+
    |                         Message Data                          |

  Notes:

   - This message header is common among all signalling protocol
     adaptation layers.
   - The 'data' portion of ISUA messages SHALL contain zero or more ISUA
     parameters, and SHALL NOT contain an encapsulated ISUP message.
   - All fields in the ISUA message MUST be transmitted in the network
     byte order, unless otherwise stated.

3.1.1.  ISUA Protocol Version

  Version: 8-bits (unsigned integer)

    The Version field of the Common Message Header contains the version
    of the ISUA adaptation layer.  The supported versions are:

        1 - ISUA Version 1.0

3.1.2.  Message Classes

  Message Class: 8-bits (unsigned integer)

    The Message Class field of the Common Message Header contains the
    class of the message.  The supported classes are as follows:

      0        Management (MGMT) Message
      7        Reserved for Other Signalling Adaptation Layers
      2        Reserved for Other Signalling Adaptation Layers
      3        ASP State Maintenance (ASPSM) Messages

B. Bidulock                    Version 0.0                       Page 20

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

      4        ASP Traffic Maintenance (ASPTM) Messages
      5        Reserved for Other Signalling Adaptation Layers
      6        Reserved for Other Signalling Adaptation Layers
      7        Reserved for Other Signalling Adaptation Layers
      8        Reserved for Other Signalling Adaptation Layers
      9        Routing key Management (RKM) Messages
     10        ISUA Call Processing (CP) Messages
     11        ISUA Circuit Supervision (CS) Messages
     12 - 127  Reserved by the IETF
    128 - 255  Reserved for IETF-Defined Message Class Extensions

3.1.3.  Message Types

  Message Type: 8-bits (unsigned integer)

    The Message Type field of the Common Message Header contains the
    type of message within a message class.  The supported types of
    messages within the supported classes are as follows:

    Management (MGMT) Messages
      0         Error (ERR)
      1         Notify (NTFY)
      2 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Application Server Process State Maintenance (ASPSM) Messages
      0         Reserved
      1         ASP Up (UP)
      2         ASP Down (DOWN)
      3         Heartbeat (BEAT)
      4         ASP Up Ack (UP ACK)
      5         ASP Down Ack (DOWN ACK)
      6         Heartbeat Ack (BEAT ACK)
      7 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Application Server Process Traffic Maintenance (ASPTM) Messages
      0         Reserved
      1         ASP Active (ASPAC)
      2         ASP Inactive (ASPIA)
      3         ASP Active Ack (ASPAC ACK)
      4         ASP Inactive Ack (ASPIA ACK)
      5 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Routing Key Management (RKM) Messages
      0         Reserved
      1         Registration Request (REG REQ)
      2         Registration Response (REG RSP)
      3         Deregistration Request (DEREG REQ)

B. Bidulock                    Version 0.0                       Page 21

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

      4         Deregistration Response (DEREG RSP)
      5 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    ISUA Call Processing (CP) Messages
      0         Reserved
      1         Setup (CSET)
      2         More Information (CMOR)
      3         Timeout (CTOT)
      4         Information (CINF)
      5         Proceeding (CPRO)
      6         Alerting (CALR)
      7         Progress (CPRG)
      8         Connect (CCON)
      9         Suspend (CSUS)
     10         Resume (CRES)
     11         Reattempt (CREA)
     12         Failure (CERR)
     13         In Band Information (CIBI)
     14         Release (CREL)
     15         Release Complete (CRLC)
     16 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    ISUA Circuit Supervision (CS) Messages
      0         Reserved
      1         Continuity Check (CCNT)
      2         Loopback (CLBK)
      3         Report (CREP)
      4         Reset (CRSC)
      5         Reset Acknowledgement (CRSA)
      6         Block (CBLO)
      7         Block Acknowledgement (CBLA)
      8         Unblock (CUBL)
      9         Unblock Acknowledgement (CUBA)
     10         Query (CQRY)
     11         Query Acknowledgement (CQRA)
     12 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

3.1.4.  Message Length

  Message Length: 32-bits (unsigned integer)

    The Message Length field of the Common Message Header defines the
    length of the message in octets, including the header.

3.1.5.  Tag-Length-Value Format

     ISUA messages consist of a Common Message Header followed by zero
  or more parameters, as defined by the message type.  The Tag-Length-
  Value (TLV) parameters contained in a message are defined in a Tag-

B. Bidulock                    Version 0.0                       Page 22

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

  Length-Value format as shown below [2].

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Parameter Tag        |       Parameter Length        |
    +-------------------------------+-------------------------------+
    \                                                               \
    /                       Parameter Value                         /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Parameter Tag: 16-bits (unsigned integer)

    The Parameter Tag field is a 16-bit identifier of the type of
    parameter.  It takes a value of 0 to 65534.

  Parameter Length: 16-bits (unsigned integer)

    The Parameter Length field contains the size of the parameter in
    bytes, including the Parameter Tag, Parameter Length, and Parameter
    Value fields.  The Parameter Length does not include any padding
    bytes.  However, composite parameters will contain all padding
    bytes, since all parameters contained within this composite
    parameter will considered multiples of 4 bytes.

  Parameter Value: variable-length

    The Parameter Value field contains the actual information to be
    transferred in the parameter.  The total length of a parameter
    (including Tag, Parameter Length and Value fields) MUST be a
    multiple of 4 bytes.  If the length of the parameter is not a
    multiple of 4 bytes, the sender MUST pad the Parameter at the end
    (i.e., after the Parameter Value field) with all zero bytes.  The
    length of the padding MUST NOT be included in the parameter length
    field.  A sender SHOULD NOT pad with more than 3 bytes.  The
    receiver MUST ignore the padding bytes.

3.2.  ISUA Message Header

     In addition to the Common Message Header, a specific message header
  is included for ISUA messages.  The ISUA message header will
  immediately follow the Common Message Header in ISUA Call Processing
  (CP) and Circuit Supervision (CS) messages.

  The ISUA Message Header is formatted as follows:

B. Bidulock                    Version 0.0                       Page 23

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Routing Context                        |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0013          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Correlation Id                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ISUA Message header can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      Correlation Id              Conditional   *2

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context MUST be present in the ISUA Message
          Header.  The Routing Context SHOULD always be placed in the
          ISUA Message Header.  When the Routing Context is present in
          the ISUA Message Header it SHOULD be placed first in the
          header because the context of the Correlation Id depends on
          the Routing Context.

  Note 2: Under some circumstances, the Correlation Id parameter MUST be
          included in the ISUA Message Header.  See sections "3.9.9 -
          Correlation Id" and "4.3.4.3 - ASP Active Procedures".

3.3.  ISUA Call Processing (CP) Messages

     The following section describes the ISUA Call Processing (CP)
  messages and parameter contents.  The general message format includes
  a Common Message Header, the ISUA Message Header and the CP Message
  Header, together with a list of zero or more parameters as defined by
  the Message Type.  For forward compatibility, all Message Types MAY
  have optional attached parameters in addition to the message headers.

  These messages are ISUA Call Processing (CP) messages:

              ISUA Call Processing (CP) Messages
      ----------------------------------------------------
      Message Name                 Message Type   Section
      ----------------------------------------------------
      CP Header                                   3.3.1
      Setup                 CSET         1        3.3.2
      More Information      CMOR         2        3.3.3

B. Bidulock                    Version 0.0                       Page 24

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

      Timeout               CTOT         3        3.3.4
      Information           CINF         4        3.3.5
      Proceeding            CPRO         5        3.3.6
      Alerting              CALR         6        3.3.7
      Progress              CPRG         7        3.3.8
      Connect               CCON         8        3.3.9
      Suspend               CSUS         9        3.3.10
      Resume                CRES        10        3.3.11
      Reattempt             CREA        11        3.3.12
      Failure               CERR        12        3.3.13
      In Band Information   CIBI        13        3.3.14
      Release               CREL        14        3.3.15
      Release Complete      CRLC        15        3.3.16
      ----------------------------------------------------

3.3.1.  CP Message Header

     In addition to the Common Message Header and ISUA Message Header, a
  specific message header is included for ISUA Call Processing (CP)
  messages.  The CP Message Header will immediately follow the ISUA
  Message header in these messages.

  The CP Message Header is formatted as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0520          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Circuit Id                          |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0501          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Call Reference                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CP Message Header contains the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Id                  Conditional   *1
      Call Reference              Conditional   *2

  Note 1: The Circuit Id MUST be placed in the ISUA CP Message Header
          for all CP messages sent from the SGP to the ASP, and is
          OPTIONAL in the ISUA CP Message Header for all CP messages
          sent from the ASP to the SGP for which a Circuit Id was
          assigend to the call by the SGP before the message was sent.
          If Circuit Id was not assigned by the SGP before the ASP sends
          a CP message, the ASP MAY include the Circuit Id parameter for

B. Bidulock                    Version 0.0                       Page 25

Internet Draft       SS7 ISUP-User Adaptation Layer      January 5, 2003

          simplicity, but it MUST then be coded zero (0).  CP messages
          for which a Circuit Id has not been assigned by the SGP
          include only the Setup (CSET) request message sent from the
          ASP to the SGP.

  Note 2: The Call Reference MUST be placed in the ISUA CP Message
          Header for all CP messages sent from ASP to the SGP, and is