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-04

Description: Request For Comments

You can download source copies of the file as follows:

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

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




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation
Intended status: PROPOSED STANDARD                      February 3, 2007

Expires in August 2007

                     SS7 ISUP-User Adaptation Layer
                                 (ISUA)
                  <draft-bidulock-sigtran-isua-04.txt>

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

    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.

    This Internet-Draft will expire in August 2007.

Copyright

    Copyright (C) The IETF Trust (2007).

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 [SCTP].  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.

B. Bidulock                    Version 0.4                        Page 1

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

Contents

    A complete table of contents, list of illustrations, list of tables
  and document change history appear at the end of this document.

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) [SCTP].  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 [RFC2719].

    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 [RFC2719] 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.  Abbreviations and Terminology

1.2.1.  Abbreviations

      ANSI -- American National Standards Institute.
      API  -- Application Programming Interface.
      AS   -- Application Server.
      ASP  -- Application Server Process.

B. Bidulock                    Version 0.4                        Page 2

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      BLA  -- Blocking Acknowledgement.
      BLO  -- Blocking Request.
      CA   -- Certificate Authority.
      CC   -- Call Control.
      CCR  -- Continuity Check Request.
      CGBA -- Circuit Group Blocking Acknowledgement.
      CGB  -- Circuit Group Blocking Request.
      CGUA -- Circuit Group Unblocking Acknowledgement.
      CGU  -- Circuit Group Unblocking Request.
      CMF  -- Circuit Mapping Function.
      COT  -- Continuity Test.
      CP   -- Call Processing.
      CQM  -- Circuit Group Query Request.
      CQR  -- Circuit Group Query Response.
      CTP  -- Common Transport Protocol.
      ETSI -- European Telecommunication Standards Institute.
      GRS  -- Group Reset.
      HLR  -- Home Location Register.
      IANA -- Internet Assigned Numbers Authority.
      IETF -- Internet Engineering Task Force.
      IP   -- Internet Protocol.
      IPSP -- IP Signalling Point.
      ISDN -- Integrated Services Digital Network.
      ISO  -- International Standards Organization.
      ISUA -- SS7 ISUP-User Adaptation Layer.
      ISUP -- ISDN User Part.
      ITU  -- International Telecommunications Union.
      L1   -- Layer 1.
      LM   -- Layer Management.
      LPA  -- Loop Back Acknowledgement.
      MGC  -- Media Gateway Controller.
      MTP2 -- MTP Level 2.
      MTP3 -- MTP Level 3.
      MTP  -- Message Transfer Part.
      NA   -- Network Appearance.
      NIF  -- Network Interworking Function.
      PSTN -- Public Switched Telephone Network.
      RC   -- Routing Context.
      RFC  -- Request For Comments.
      RK   -- Routing Key.
      RKM  -- Routing Key Management.
      RSC  -- Reset Circuit.
      SCN  -- Switch Circuit Network.
      SCP  -- Service Control Point.
      SCTP -- Stream Control Transmission Protocol.
      SG   -- Signalling Gateway.
      SGP  -- Signalling Gateway Process.
      SS7  -- Signalling System No. 7.
      SSP  -- Service Switching Point.
      STP  -- Signalling Transfer Point.
      TLI  -- Transport Layer Interface.
      TLS  -- Transport Layer Security.

B. Bidulock                    Version 0.4                        Page 3

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      TLV  -- Tag-Length-Value.
      UBA  -- Unblocking Acknowledgement.
      UBL  -- Unblocking Request.
      VPN  -- Virtual Private Network.
      XTI  -- X/Open Transport Interface.

1.2.2.  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
      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 [SCTP].  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.

B. Bidulock                    Version 0.4                        Page 4

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  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.

  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 [RFC2719].  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.

B. Bidulock                    Version 0.4                        Page 5

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  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>.

1.3.  ISUA Overview

1.3.1.  Signalling Transport Architecture

    The framework architecture that has been defined for SCN signalling
  transport over IP [RFC2719] 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.3.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.

B. Bidulock                    Version 0.4                        Page 6

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

          .........         ...............        .........
          :       :         :             :        :       :
          :  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

1.3.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.

B. Bidulock                    Version 0.4                        Page 7

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

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

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

                       Figure 2.  All IP Architecture

1.3.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.3.5.  Services Provided by the ISUA Layer

1.3.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.

1.3.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:

B. Bidulock                    Version 0.4                        Page 8

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    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.3.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.3.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
  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.

B. Bidulock                    Version 0.4                        Page 9

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

           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    |             |             |            |
 +--------------+------------+-------------+-------------+------------+

    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.3.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
  traffic between ISUA peers.  As well, the active/inactive and
  congestion state of remote ASPs is maintained.

B. Bidulock                    Version 0.4                       Page 10

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    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.4.  Functional Areas

1.4.1.  Circuit Identifiers, Routing Contexts and Routing Keys

1.4.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,
  the Routing Context parameter uniquely identifies the range of
  signalling traffic associated with each Application Server that the

B. Bidulock                    Version 0.4                       Page 11

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  ASP is configured to receive.

1.4.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.4.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.4.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.4.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.4                       Page 12

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    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 messages 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.4.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.4                       Page 13

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

1.4.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.4.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 messages (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.4.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.4.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.4                       Page 14

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    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.4.2.  Redundancy Models

1.4.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.4.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.4.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

B. Bidulock                    Version 0.4                       Page 15

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

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

1.5.  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.5.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 |
    +-------------+------------+---------------+---------------+------+

B. Bidulock                    Version 0.4                       Page 16

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    +-------------+------------+---------------+---------------+------+
    |Generic      | Specific   |  ITU-T Q.764  |  ANSI T1.113  | ISUA |
    |Name         | Name       |    Message    |    Message    | Msg  |
    +-------------+------------+---------------+---------------+------+
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |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.5.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.

B. Bidulock                    Version 0.4                       Page 17

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  M-SCTP_ESTABLISH confirm
  Direction: ISUA -> LM
  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.

B. Bidulock                    Version 0.4                       Page 18

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

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

  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

B. Bidulock                    Version 0.4                       Page 19

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Purpose:   LM requests ASP to send an ASP Active (ASPAC) message to
             its peer.

  M-ASP_ACTIVE confirm
  Direction: ISUA -> LM
  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.

    If the ISUA layer supports dynamic registration of Routing Key, the
  layer MAY support the following additional primitives:

  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

B. Bidulock                    Version 0.4                       Page 20

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  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
  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.5.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)"
  [SCTP].

Notes for Section 1

  <1>  IMPLEMENTATION NOTE:-  Only one SCTP port may be defined for
       each endpoint, but each SCTP endpoint may have multiple IP
       addresses [SCTP].

2.  Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

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

B. Bidulock                    Version 0.4                       Page 21

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    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 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.
   + The Reserved field SHALL be coded zero by the sender of the message
     and SHALL be ignored by the receiver of the message.

B. Bidulock                    Version 0.4                       Page 22

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

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
        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

B. Bidulock                    Version 0.4                       Page 23

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      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)
      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         Loop Back (CLBK)

B. Bidulock                    Version 0.4                       Page 24

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      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-Length-
  Value format as shown below <1>.

     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                         /
    \