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-ietf-sigtran-sua-07

Description: Request For Comments

You can download source copies of the file as follows:

draft-ietf-sigtran-sua-07.txt in text format.

Listed below is the contents of file draft-ietf-sigtran-sua-07.txt.




INTERNET-DRAFT                                    J. Loughney (Editor) 
Internet Engineering Task Force                                  Nokia 
                                           G. Sidebottom, Guy Mousseau 
Issued:  20 July 2001                                  Nortel Networks 
Expires: 20 January 2002                                    S. Lorusso 
                                                   Unisphere Solutions 
                                                  L. Coene, G. Verwimp 
                                                               Siemens 
                                                             J. Keller 
                                                               Tekelec 
                                                            F. Escobar  
                                                              Ericsson 
                                                  W. Sully, S. Furniss 
                                                               Marconi 
 
                  SS7 SCCP-User Adaptation Layer (SUA) 
                    <draft-ietf-sigtran-sua-07.txt> 
 
 
Status of This Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as 'work in progress.' 
    
   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 draft expires on 20 January 2002 
    
Abstract 
    
   This Internet Draft defines a protocol for the transport of any SS7 
   SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the 
   Stream Control Transport Protocol.  The protocol should be modular 
   and symmetric, to allow it to work in diverse architectures, such as 
   a Signaling Gateway to IP Signaling Endpoint architecture as well as 
   a peer-to-peer IP Signaling Endpoint architecture.  Protocol 
   elements are added to allow seamless operation between peers in the 
   SS7 and IP domains.  
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
 
Abstract.............................................................1 
1. Introduction......................................................3 
 1.1 Scope...........................................................3 
 1.2 Terminology.....................................................3 
 1.3 Signaling Transport Architecture................................5 
 1.4 Services Provided by the SUA Layer.............................12 
 1.5 Internal Functions Provided in the SUA Layer...................14 
 1.6 Definition of SUA Boundaries...................................16 
2 Conventions.......................................................17 
3 Protocol Elements.................................................17 
 3.1 Common Message Header..........................................17 
 3.2 SUA Connectionless Messages....................................21 
 3.3 Connection Oriented Messages...................................23 
 3.4 Signaling Network Management Messages..........................32 
 3.5 Application Server Process State Maintenance Messages..........37 
 3.6 ASP Traffic Maintenance Messages...............................40 
 3.7 SUA Management Messages........................................43 
 3.8 Common Parameters..............................................44 
 3.9 SUA-Specific parameters........................................53 
4 Procedures........................................................64 
 4.1 SCCP û SUA Interworking at the SG..............................65 
 4.2 Primitives received from the local SUA-user....................67 
 4.3 Layer Management Procedures....................................67 
 4.4 SUA Management Procedures......................................68 
5 Examples of SUA Procedures........................................76 
 5.1 SG Architecture................................................76 
 5.2 IP-IP Architecture.............................................78 
6 Security..........................................................80 
 6.1 Introduction...................................................80 
 6.2 Threats........................................................80 
 6.3 Protecting Confidentiality.....................................81 
7 IANA Considerations...............................................81 
 7.1 SCTP Payload Protocol ID.......................................81 
 7.2 Port Number....................................................81 
 7.3 Protocol Extensions............................................81 
8 Timer Values......................................................83 
9 Acknowledgements..................................................83 
10 Authors' Addresses...............................................83 
11 References.......................................................84 
Copyright Statement.................................................87 

 
Loughney (editor)                                           [Page 2] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
1. Introduction 
 
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 and SS7-like signaling 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 may be some need for interworking between the SS7 and IP 
   domains. 
    
   This document details the delivery of SCCP-user messages (MAP & CAP 
   over TCAP, RANAP, etc.) and new third generation network protocol 
   messages over IP between two signaling endpoints.  Consideration is 
   given for the transport from an SS7 Signaling Gateway (SG) to an IP 
   signaling node (such as an IP-resident Database) as described in the 
   Framework Architecture for Signaling Transport [2719]. This protocol 
   can also support transport of SCCP-user messages between two 
   endpoints wholly contained within an IP network. 
    
   The delivery mechanism addresses the following criteria:  
    
     *    Support for transfer of SCCP-User Part messages (TCAP, RANAP, 
          etc.) 
     *    Support for SCCP connectionless service. 
     *    Support for SCCP connection oriented service. 
     *    Support for the seamless operation of SCCP-User protocol 
          peers. 
     *    Support for the management of SCTP transport associations 
          between a SG and one or more IP-based signaling nodes). 
     *    Support for distributed IP-based signaling nodes. 
     *    Support for the asynchronous reporting of status changes to 
          management. 
    
   The protocol is modular in design, allowing different 
   implementations to be made, based upon the environment that needs to 
   be supported. Depending upon the upper layer protocol supported, the 
   SUA will need to support SCCP connectionless service, SCCP connect-
   oriented service or both services. 
    
1.2 Terminology 
    
   Signaling Gateway (SG) - Network element that terminates SCN 
   signaling and transports SCCP-User signaling over IP to an IP 
   signaling endpoint.  A Signaling Gateway could be modeled as one or 
   more Signaling Gateway Processes, which are located at the border of 
   the SS7 and IP networks. 
    
   Application Server (AS) - A logical entity serving a specific 
   Routing Key.  An example of an Application Server is a virtual IP 
 
Loughney (editor)                                           [Page 3] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   database element handling all requests for a SCCP-user.  The AS 
   contains a set of one or more unique Application Server Processes, 
   of which one or more is normally actively processing traffic. 
    
   Application Server Process (ASP) - An Application Server Process 
   serves as an active or backup process of an Application Server 
   (e.g., part of a distributed signaling node or database element).  
   Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs.  An ASP 
   contains an SCTP end-point and may be configured to process traffic 
   within more than one Application Server. 
    
   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 SUA in a peer-to-peer fashion.  Conceptually, an IPSP does 
   not use the services of a Signaling Gateway. 
    
   Signaling Gateway Process (SGP) - A process instance of a Signaling 
   Gateway.  It serves as an active, standby or load-sharing process of 
   a Signaling Gateway. 
    
   Signaling Process - A process instance that uses SUA to communicate 
   with other signaling process.  An ASP, a SGP and an IPSP are all 
   signaling processes. 
    
   Association - An association refers to an SCTP association.  The 
   association provides the transport for the delivery of SCCP-User 
   protocol data units and SUA layer peer messages. 
    
   Routing Key - The Routing Key describes a set of SS7 parameters 
   and/or parameter-ranges that uniquely defines the range of signaling 
   traffic configured to be handled by a particular Application Server. 
   An example would be where a Routing Key consists of a particular SS7 
   SCCP SSN plus an identifier to uniquely mark the network that the 
   SSN belongs to, for which all traffic would be directed to a 
   particular Application Server.  Routing Keys are mutually exclusive 
   in the sense that a received SS7 signaling message cannot be 
   directed to more than one Routing Key.  Routing Keys can be 
   provisioned, for example, by a MIB. 
    
   Routing Context - An Application Server Process may be configured to 
   process traffic within more than one Application Server.  In this 
   case, the Routing Context parameter is exchanged between the SGP and 
   the ASP (or between two ASPs), identifying the relevant Application 
   Server.  From the perspective of an SGP/ASP, the Routing Context 
   uniquely identifies the range of traffic associated with a 
   particular Application Server, which the ASP is configured to 
   receive. There is a 1:1 relationship between a Routing Context value 
   and a Routing Key within an AS.  Therefore the Routing Context can 
   be viewed as an index into an AS Table containing the AS Routing 
   Keys. The Routing Context also uniquely identifies an SS7 entity 
   (point code) into a SS7 network, as presented by the SG.   
 
Loughney (editor)                                           [Page 4] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   Address Mapping Function (AMF) - The AMF is an implementation 
   dependent function that is responsible for resolving the address 
   presented in the incoming SCCP/SUA message to correct SCTP 
   association for the desired endpoint. The AMF MAY use routing 
   context / rouging key information as selection criteria for the 
   appropriate SCTP association. 
    
   Fail-over - The capability to re-route signaling 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. 
    
   Network Byte Order - Most significant byte first, a.k.a. Big Endian. 
    
   Layer Management - Layer Management is a nodal function that handles 
   the inputs and outputs between the M3UA layer and a local management 
   entity.   
    
   Host - The computing platform that the SGP or ASP process is running 
   on. 
    
   Stream - A stream refers to an SCTP stream; a uni-directional 
   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 un-ordered 
   delivery service. 
    
   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 an IP address and an SCTP port number.  Note, only 
   one SCTP port may be defined for each endpoint, but each SCTP 
   endpoint may have multiple IP addresses. 
  
1.3 Signaling Transport Architecture 
    
   The framework architecture that has been defined for SCN signaling 
   transport over IP [2719] uses multiple components, including an IP 
   transport protocol, a signaling common transport protocol and an 
   adaptation module to support the services expected by a particular 
   SCN signaling protocol from its underlying protocol layer.   
    
   In general terms, the SUA architecture can be modeled as a peer-to-
   peer architecture. The first section considers the SS7-IP 
   interworking architectures for connectionless and connection- 
   oriented transport.  For this case, it is assumed that the ASP 
   initiates the establishment of the SCTP association with SG. 
    
 
Loughney (editor)                                           [Page 5] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
1.3.1 Protocol Architecture for Connectionless Transport  
    
   In this architecture, the SCCP and SUA layers interface in the SG. 
   There needs to be interworking between the SCCP and SUA layers to 
   provide for the seamless transfer of the user messages as well as 
   the management messages.  For messages destined for an ASP, there 
   are two scenarios. 
    
        ********   SS7   ***************   IP   ******** 
        * SEP  *---------*             *--------*      * 
        *  or  *         *      SG     *        * ASP  * 
        * STP  *         *             *        *      * 
        ********         ***************        ******** 
    
        +------+                                +------+ 
        | SUAP |                                | SUAP | 
        +------+         +------+------+        +------+ 
        | SCCP |         | SCCP | SUA  |        | SUA  | 
        +------+         +------+------+        +------+ 
        | MTP3 |         | MTP3 |      |        |      | 
        +------|         +------+ SCTP |        | SCTP | 
        | MTP2 |         | MTP2 |      |        |      | 
        +------+         +------+------+        +------+ 
        |  L1  |         |  L1  |  IP  |        |  IP  | 
        +------+         +------+------+        +------+ 
            |               |         |            | 
            +---------------+         +------------+ 
    
          SUAP - SCCP/SUA User Protocol (TCAP, for example) 
          STP  - SS7 Signaling Transfer Point 

1.3.1.1 SG as endpoint 
    
   In this case, the connectionless SCCP messages are routed on PC and 
   SSN.  The subsystem identified by SSN and Routing Context is 
   regarded as local to the SG.  This means from SS7 point of view, the 
   SCCP-user is located at the SG.  
    
   By means of configuration, the SG knows the local SCCP-user is 
   actually represented by an AS, and serviced by a set of ASPs working 
   in n+k redundancy mode.  An ASP is selected and a CLDT message is 
   sent on the appropriate SCTP association/stream. 
    
   The selection criterion can be based on a round robin mechanism, or 
   any other method that guarantees a balanced load sharing over the 
   active ASPs. However, when TCAP messages are transported, load 
   sharing is only possible for the first message in a TCAP dialogue 
   (TC_Begin, TC_Query, TC_Unidirectional). All other TCAP messages in 
   the same dialogue are sent to the same ASP that was selected for the 
   first message, unless the ASPs are able to share state and maintain 
 
Loughney (editor)                                           [Page 6] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   in sequence delivery. To this end, the SGP needs to know the TID 
   allocation policy of the ASPs in a single AS: 
    
     -    State sharing 
     -    Fixed range of TIDs per ASP in the AS 
    
   This information may be preconfigured in the SG, or may be 
   dynamically exchanged via the ASP_Active message. 
    
   An example for a INAP/TCAP message exchange between SEP and ASP is 
   given below.  
    
   Address information in CLDT message (e.g. TC_Query) from SGP to ASP, 
   with association ID = SG-ASP, Stream ID based on SLS and possibly 
   other parameters, e.g. OPC or Network ID: 
    
     -   Routing Context: based on SS7 Network ID and AS membership, 
         so that the message can be transported to the correct ASP. 
     -   Source address: valid combination of SSN, PC and GT, as 
         needed for back routing to the SEP. 
     -   Destination address: at least SSN, to select the SCCP/SUA-
         user at the ASP. 
    
   Address information in CLDT message (e.g. TC_Response) from ASP to 
   SG, with association ID = ASP-SG, stream ID selected by 
   implementation dependent means with regards to in-sequence-delivery: 
    
     -  Routing Context: as received in previous message. 
     -  Source address: unique address provided so that when used as 
        the SCCP called party address in the SEP, it MUST yield the 
        same AS, the SSN might be sufficient. 
     -  Destination address: copied from source address in received   
        CLDT message. 
   
   Further messages from the SEP belonging to the same TCAP transaction 
   will now reach the same ASP. 

1.3.1.2 SG as relay-point 
    
   A Global Title translation is executed at the SG, before the 
   destination of the message can be determined.  The actual location 
   of the SCCP-user is irrelevant to the SS7 network.  GT Translation 
   yields an "SCCP entity set", which now may contain one or more ASÆs.  
   Selection of the AS is thus based on the SCCP called party address  
   (and possibly other SS7 parameters depending on the implementation).  
   Basically this means splitting the SS7 traffic over different ASÆs 
   based on GT information.  After this, the same as in 1.3.1.1 
   applies. 
    

 
Loughney (editor)                                           [Page 7] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
1.3.2 Protocol Architecture for Connection-Oriented Transport  
    
   In this architecture, the SCCP and SUA layers interface in the SGP 
   to associate the two connection sections needed for the connection- 
   oriented data transfer between SEP and ASP.  Both connection 
   sections are setup when routing the Connect Request messages from 
   SEP via SGP to ASP or the other way.  The routing of the Connect 
   Request message is done in the same way as described in 1.3.1. 
    
   Further messages for this connection are routed on DPC in the SS7 
   connection section (MTP routing label), and on IP address in the IP 
   connection section (SCTP header).  No other routing information is 
   present in the SCCP or SUA messages themselves. Resources are kept 
   within the SG to forward messages from one section to another and to 
   populate the MTP routing label or SCTP header, based on the 
   destination local reference of these messages (Connect Confirm, Data 
   Transfer, ...) 
    
   This means that in the SG, two local references are allocated, one 
   3-byte value used for the SS7 section and one 4 byte value for the 
   IP section. Also a resource containing the connection data for both 
   sections is allocated, and either of the two local references can be 
   used to retrieve this data e.g. for an incoming DT1 or CODT, for 
   example. 
    
        ********   SS7   ***************   IP   ******** 
        * SEP  *---------*             *--------*      * 
        *  or  *         *      SG     *        * ASP  * 
        * STP  *         *             *        *      * 
        ********         ***************        ******** 
    
        +------+                                +------+ 
        | SUAP |                                | SUAP | 
        +------+         +------+------+        +------+ 
        | SCCP |         | SCCP | SUA  |        | SUA  | 
        +------+         +------+------+        +------+ 
        | MTP3 |         | MTP3 |      |        |      | 
        +------|         +------+ SCTP |        | SCTP | 
        | MTP2 |         | MTP2 |      |        |      | 
        +------+         +------+------+        +------+ 
        |  L1  |         |  L1  |  IP  |        |  IP  | 
        +------+         +------+------+        +------+ 
            |               |         |            | 
            +---------------+         +------------+ 
    
          SUAP - SCCP/SUA Application Protocol (e.g. - RANAP/RNSAP) 
          STP  - SS7 Signaling Transfer Point 
    
   The above architecture may simplify, in some cases, to carrying SS7 
   application protocols between two IP based endpoints.  In this 

 
Loughney (editor)                                           [Page 8] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   scenario, full SG functionality is not needed.  This architecture is 
   considered in the next section. 
    
1.3.3 All IP Architecture 
    
   This architecture can be used to carry a protocol that uses the 
   transport services of SCCP, but is contained with an IP network.  
   This allows extra flexibility in developing networks, especially 
   when interaction between legacy signaling is not needed.  The 
   architecture removes the need for signaling gateway functionality. 
    
          ********   IP   ******** 
          *      *--------*      * 
          * IPSP *        * IPSP * 
          *      *        *      * 
          ********        ******** 
         
          +------+        +------+ 
          | SUAP |        | SUAP | 
          +------+        +------+ 
          | SUA  |        | SUA  | 
          +------+        +------+ 
          | SCTP |        | SCTP | 
          +------+        +------+ 
          |  IP  |        |  IP  | 
          +------+        +------+ 
             |                | 
             +----------------+ 
    
       SUAP - SCCP/SUA Application Protocol (e.g. - RANAP/RNSAP) 
    
   In the case where a collision occurs during initiation, there exist 
   two possible solutions: 1) if there are sufficient resources, both 
   initiations could be accepted; 2) both ASPs should back-off and 
   after some amount of time, later re-establish an initiation.   
    
1.3.4 Generalized Peer-to-Peer Network Architecture 
    
   Figure 1 shows an example network architecture that can support 
   robust operation and failover.  There need to be some management 
   resources at the AS to manage traffic. 
    
    

 
Loughney (editor)                                           [Page 9] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
         *********** 
         *   AS1   * 
         * +-----+ * SCTP Associations 
         * |ASP1 +-------------------+ 
         * +-----+ *                 |                   *********** 
         *         *                 |                   *   AS3   * 
         * +-----+ *                 |                   * +-----+ * 
         * |ASP2 +-----------------------------------------+ASP1 | * 
         * +-----+ *                 |                   * +-----+ * 
         *         *                 |                   *         * 
         * +-----+ *                 |                   * +-----+ * 
         * |ASP3 | *            +--------------------------+ASP2 | * 
         * +-----+ *            |    |                   * +-----+ * 
         ***********            |    |                   *********** 
                                |    | 
         ***********            |    |                   *********** 
         *   AS2   *            |    |                   *   AS4   * 
         * +-----+ *            |    |                   * +-----+ * 
         * |ASP1 +--------------+    +---------------------+ASP1 | * 
         * +-----+ *                                     * +-----+ * 
         *         *                                     *         * 
         * +-----+ *                                     * +-----+ * 
         * |ASP2 +-----------------------------------------+ASP1 | * 
         * +-----+ *                                     * +-----+ * 
         *         *                                     *********** 
         * +-----+ * 
         * |ASP3 | * 
         * +-----+ * 
         *         * 
         *********** 
    
                    Figure 1: Generalized Architecture 
    
   In this example, the Application Servers are shown residing within 
   one logical box, with ASPs located inside.  In fact, an AS could be 
   distributed among several hosts.  In such a scenario, the host 
   should share state as protection in the case of a failure.  
   Additionally, in a distributed system, one ASP could be registered 
   to more than one AS.  This draft should not restrict such systems - 
   though such a case in not specified. 
    
1.3.5 Signaling Gateway Network Architecture 
    
   When interworking between SS7 and IP domains is needed, the SGP acts 
   as the gateway node between the SS7 network and the IP network.  The 
   SGP will transport SCCP-user signaling traffic from the SS7 network 
   to the IP-based signaling nodes (for example IP-resident Databases). 
   The Signaling Gateway can be considered as a group of Application 
   Servers with additional functionality to interface towards an SS7 
   network. 
 
Loughney (editor)                                           [Page 10] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   The SUA protocol should be flexible enough to allow different 
   configurations and transport technology to allow the network 
   operators to meet their operation, management and performance 
   requirements.  
    
   An ASP may be connected to multiple SGPs (see figure 2). In such a 
   case, a particular SS7 destination may be reachable via more than 
   SG, therefore, more than one route. Given that proper SLS selection, 
   loadsharing, and SG selection based on point code availability is 
   performed at the ASP, it will be necessary for the ASP to maintain 
   the status of each distant SGPs to which it communicates on the 
   basis of the SG through which it may route.  
    
   Signaling Gateway 
    SCTP Associations 
   +----------+                                       ************** 
   | SG1      |                                       *  AS3       * 
   | ******** |                                       *  ********  *  
   | * SGP11+--------------------------------------------+ ASP1 *  * 
   | ******** |                                 /     *  ********  * 
   | ******** |                                 |     *  ********  * 
   | * SGP12+--------------------------------------------+ ASP2 *  * 
   | ******** |                   \           / |     *  ********  * 
   +----------+                    \          | |     *      .     * 
                                    \         | |     *      .     * 
   +----------+                      \        | |     *      .     * 
   | SG2      |                       \       | |     *      .     * 
   | ******** |                        \      | |     *  ********  *  
   | * SGP21+---------------------------------+-+     *  * ASPN *  * 
   | ******** |                          \            *  ********  * 
   | ******** |                           \           ************** 
   | * SGP22+---+--+                       \                
   | ******** | |  |                        \         ************** 
   +----------+ |  |                         \        *  AS4       * 
                |  |                          \       *  ********  *   
                |  +-------------------------------------+ ASP1 *  * 
                |                                     *  ********  * 
                |                                     *      .     * 
                |                                     *      .     * 
                |                                     *            * 
                |                                     *  ********  * 
                +----------------------------------------+ ASPn *  * 
                                                      *  ********  * 
                                                      ************** 
 
                Figure 2: Signaling Gateway Architecture 
 
   The pair of SGs can either operate as replicated endpoints or as 
   replicated relay points from the SS7 network point of view.  
    
 
Loughney (editor)                                           [Page 11] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   Replicated endpoints: the coupling between the SGs and the ASPs when 
   the SGs act as replicated endpoints is an implementation issue.  
    
   Replicated relay points: in normal circumstances, the path from SEP 
   to ASP will always go via the same SGP when in-sequence-delivery is 
   requested.  However, linkset failures may cause MTP to re-route to 
   the other SG. 
 
1.3.6 ASP Fail-over Model and Terminology 
    
   The SUA 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/registered to handle SCCP-user messages within a certain 
   range of routing information, 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 ASP(s). 
    
1.4 Services Provided by the SUA Layer 
    
1.4.1 Support for the transport of SCCP-User Messages 
    
   The SUA needs to support the transfer of SCCP-user messages. The SUA 
   layer at the SG needs to seamlessly transport the user messages. 
    
1.4.2 SCCP Protocol Class Support 
    
   Depending upon the SCCP-users supported, the SUA shall support the 4 
   possible SCCP protocol classes transparently.  The SCCP protocol 
   classes are defined as follows: 
    
     *    Protocol class 0 provides unordered transfer of SCCP-user 
          messages in a connectionless manner. 
    
     *    Protocol class 1 allows the SCCP-user to select the in-
          sequence delivery of SCCP-user messages in a connectionless 
          manner. 
    
     *    Protocol class 2 allows the bi-directional transfer of SCCP-
          user messages by setting up a temporary or permanent 
          signaling connection.   
    
     *    Protocol class 3 allows the features of protocol class 2 with 
          the inclusion of flow control.  Detection of message loss or  
          mis-sequencing is included. 
    
   Protocol classes 0 and 1 make up the SCCP connectionless service.  
   Protocol classes 2 and 3 make up the SCCP connection-oriented 
   service. 
 
Loughney (editor)                                           [Page 12] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
 
1.4.3 Native Management Functions 
    
   The SUA layer provides the capability to indicate errors associated 
   with the SUA-protocol messages and to provide notification to local 
   management and the remote peer as is necessary. 
    
1.4.4 Interworking with SCCP Network Management Functions 
    
   SUA uses the existing ASP management messages for ASP status 
   handling. The interworking with SCCP management consists on the 
   sending of DUNA, DAVA, DAUD, DRST or SCON messages on receipt of 
   SSP, SSA, SST or SSC to the appropriate ASPs. See also chapter 
   1.4.5. The primitives below are considered to be sent between the 
   SCCP and SUA management functions in the SG to trigger events in the 
   IP and SS7 domain. 
    
   Generic   |Specific   |  
   Name      |Name       |ANSI/ITU Reference                         
   ----------+-----------+--------------------------------------------- 
   N-State   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 14/Q.711)    
             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1) 
   ----------+-----------+--------------------------------------------- 
   N-Pcstate |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 15/Q.711)               
             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)  
    
1.4.5 Support for the management between the SGP and ASP. 
    
   The SUA layer should provide interworking with SCCP management 
   functions at the SG for seamless inter-operation between the SCN 
   network and the IP network.  It should: 
    
     *    Provide an indication to the SCCP-user at an ASP that a SS7 
          endpoint/peer is unreachable. 
     *    Provide an indication to the SCCP-user at an ASP that a SS7 
          endpoint/peer is reachable. 
     *    Provide congestion indication to SCCP-user at an ASP. 
     *    Provide the initiation of an audit of SS7 endpoints at the 
          SG. 
    
1.4.6 Relay function 
    
   For network scalability purposes, the SUA may be enhanced with a 
   relay functionality to determine the next hop SCTP association 
   towards the destination SUA endpoint. 
    
   The determination of the next hop may be based on Global Title 
   information (e.g. E.164 number), in analogy with SCCP GTT in SS7 
   networks, modeled in [ITU-T Q.714]. It may also be based on Hostname 
   information, IP address, or pointcode contained in the called party 
   address. 
 
Loughney (editor)                                           [Page 13] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   This allows for greater scalability, reliability and flexibility in 
   wide-scale deployments of SUA.  The usage of a relay function is a 
   deployment decision. 
    
1.5 Internal Functions Provided in the SUA Layer 
    
   To perform its addressing and relaying capabilities, the SUA makes 
   use of a Address Mapping Function (AMF). This function is considered 
   part of SUA, but the way it is realized is left implementation / 
   deployment dependent (local tables, DNS (ENUM), LDAP, etc.) 
    
   The AMF is invoked when a message is received at the incoming 
   interface. The AMF is responsible for resolving the address 
   presented in the incoming SCCP/SUA message to SCTP associations to 
   destinations within the IP network. The AMF will select the 
   appropriate SCTP association based upon routing context / routing 
   key information available. The destination might be the end SUA node 
   or a SUA relay node. The Routing Keys reference an Application 
   Server, which will have one or more ASPs processing traffic for the 
   AS.  The availability and status of the ASPs is handled by SUA ASP 
   management messages. 
    
   Possible SS7 address/routing information that comprise a Routing Key 
   entry includes, for example, OPC, DPC, SIO found in the MTP3 routing 
   label, SCCP subsystem number, or Transaction ID. IP addresses and 
   host names can also be used as Routing Key Information. 
    
   It is expected that the routing keys be provisioned via a MIB or 
   external process, such as a database.  
    
1.5.1 Address Mapping at the SG 
    
   Normally, one or more ASPs are active in the AS (i.e., currently 
   processing traffic) 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 return or refusal procedures. 
    
   If there is no match for an incoming message, a default treatment 
   MUST be specified.  Possible solutions are to provide a default 
   Application Server to direct all unallocated traffic to a (set of) 
   default ASP(s), or to drop the messages and provide a notification 
   to management. The treatment of unallocated traffic is 
   implementation dependent. 
    
1.5.2 Address Mapping at the ASP 
    

 
Loughney (editor)                                           [Page 14] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   To direct messages to the SS7 network, the ASP MUST perform an 
   address mapping to choose the proper SGP for a given message.  This 
   is accomplished by observing the Destination Point Code and other 
   elements of the outgoing message, SS7 network status, SGP 
   availability, and Routing Context configuration tables. 
    
   A Signaling Gateway may be composed of one or more SGPs. There is, 
   however, no SUA 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 SS7 connectivity to this ASP. 
    
   An ASP SHOULD send responses only to that SGP that it received 
   messages from; within the routing context which it is currently 
   active and receiving traffic.  The routing context itself is 
   effectively used by the ASP to select the SGP. 
      
1.5.3 Address Mapping Function at a Relay Node 
    
   The relay function is invoked when: 
    
     -    Routing is on Global Title 
     -    Routing is on Hostname   
     -    Routing is on SSN+PC or SSN+IP Address and the address 
          presented is not the one of the relay node 
    
   Translation/resolution of the above address information yields one   
   of the following: 
    
     -    Route on SSN: SCTP association ID towards the destination 
          node, SSN and optionally Routing Context and/or IP address. 
     -    Route on GT: SCTP association ID towards next relay node, 
          (new) GT and optionally SSN and/or Routing Context.  
     -    Routing on Hostname: SCTP association ID towards next relay 
          node, (new) Hostname and optionally SSN and/or Routing 
          Context. 
     -    A local SUA-user (combined relay/end node) 
    
   To prevent looping, a hop counter is used. The originating end node 
   (be it an SS7 or an IP node) sets the value of the hop counter to 
   the maximum value (15 or less). Each time the relay function is 
   invoked within an intermediate (relay) node, the hop counter MUST be 
   decremented. When the value reaches zero, the return or refusal 
   procedures are invoked with reason "Hop counter violation". 
    
1.5.4 SCTP Stream Mapping 
    
   The SUA supports SCTP streams. The SG/AS needs to maintain a list of 
   SCTP and SUA-users for mapping purposes.  SCCP-users requiring 
   sequenced message transfer need to be sent over a stream supporting 
   sequenced delivery. 
 
Loughney (editor)                                           [Page 15] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   SUA MUST use stream 0 for SUA management messages. It is recommended 
   that sequenced delivery be used to preserve the order of management 
   message delivery. 
    
   Stream selection based on protocol class: 
    
     -    Protocol class 0: SUA SHOULD select an unordered stream. 
     -    Protocol class 1: SUA MUST select an ordered stream, based on 
          a sequence parameter given by the upper layer over the 
          primitive interface. 
     -    Protocol classes 2 and 3: SUA will select an ordered stream, 
          based on its own source local reference. 
    
1.6 Definition of SUA Boundaries 
 
1.6.1 Definition of the upper boundary 
    
   The following primitives are supported between the SUA and an SCCP-
   user (a reference to ITU and ANSI sections where these primitives 
   and corresponding parameters are described, is also given): 
    
   Generic     |Specific  |  
   Name        |Name      |ANSI/ITU Reference                                   
   ------------+----------+-------------------------------------------    
   N-Connect   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)      
               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)   
               |Response  |  
               |Confirm   |  
   ------------+----------+------------------------------------------- 
   N-Data      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)      
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)   
   ------------+----------+------------------------------------------- 
   N-Expedited |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)      
   Data        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)   
   ------------+----------+------------------------------------------- 
   N-Reset     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)      
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)   
               |Response  |  
               |Confirm   |  
   ------------+----------+------------------------------------------- 
   N-Disconnect|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)      
               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1) 
   ------------+----------+------------------------------------------- 
   N-Inform    |Request   |ITU-Q.711   Chap 6.1.1.3.1 (Tab 7/Q.711)     
               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1) 
   ------------+----------+------------------------------------------- 
   N-Unit Data |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 10/Q.711)     
               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1) 
   ------------+----------+------------------------------------------- 
   N-Notice    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 11/Q.711)     
 
Loughney (editor)                                           [Page 16] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1) 
    
1.6.2 Definition of the lower boundary 
    
   The upper layer primitives provided by the SCTP are provided in 
   [SCTP]. 
    
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 
   [RFC2119]. 
    
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 SCCP-User Adaptation Protocol requires 
   a message structure which contains a version, message class, message 
   type, message length and message contents. This message header is 
   common among all signaling protocol adaptation layers:  
    
      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                          | 
    
   Note that the 'data' portion of SUA messages SHALL contain SCCP-User 
   data, not the encapsulated SCCP message. 
    
   Optional parameters can only occur at most once in an SUA message. 
    
3.1.1 SUA Protocol Version  
    
   The version field (ver) contains the version of the SUA adaptation 
   layer.  The supported versions are:  
    
     1   SUA version 1.0  
    
 
Loughney (editor)                                           [Page 17] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.1.2 Message Classes 
    
   Message Classes 
    
     0         SUA Management (MGMT) Message 
     1         Reserved 
     2         Signaling Network Management (SNM) Messages 
     3         ASP State Maintenance (ASPSM) Messages 
     4         ASP Traffic Maintenance (ASPTM) Messages 
     5         Reserved 
     6         Reserved 
     7         Connectionless Messages  
     8         Connection-Oriented Messages 
     9 - 127   Reserved by the IETF 
     128 - 255 Reserved for IETF-Defined Message Class Extensions 
    
3.1.3 Message Types 
    
   SUA Management Messages  
    
     0         Error (ERR)  
     1         Notify (NTFY) 
     2 - 127   Reserved by the IETF 
     128- 255  Reserved for IETF-Defined Message Class Extensions 
      
   Signaling Network Management (SNM) Messages  
    
     0         Reserved 
     1         Destination Unavailable (DUNA) 
     2         Destination Available (DAVA) 
     3         Destination State Audit (DAUD) 
     4         Network Congestion (SCON) 
     5         Reserved 
     6         Destination Restricted (DRST) 
     7 - 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 
      
   ASP Traffic Maintenance (ASPTM) Messages 
    
 
Loughney (editor)                                           [Page 18] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     0         Reserved 
     1         ASP Active (ACTIVE) 
     2         ASP Inactive (INACTIVE) 
     3         ASP Active Ack (ACTIVE ACK)  
     4         ASP Inactive Ack (INACTIVE ACK) 
     5 - 127   Reserved by the IETF 
     128 - 255 Reserved for IETF-Defined Message Class Extensions 
    
   Connectionless Messages  
    
     0         Reserved 
     1         Connectionless Data Transfer (CLDT)  
     2         Connectionless Data Response (CLDR)  
     3 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions 
      
   Connection-Oriented Messages  
    
     0         Reserved 
     1         Connection Request (CORE)  
     2         Connection Acknowledge (COAK) 
     3         Connection Refused (COREF)  
     4         Release Request (RELRE)  
     5         Release Complete (RELCO)  
     6         Reset Confirm (RESCO)  
     7         Reset Request (RESRE)  
     8         Connection Oriented Data Transfer (CODT) 
     9         Connection Oriented Data Acknowledge (CODA) 
     10        Connection Oriented Error (COERR) 
     11        Inactivity Test (COIT) 
     12 - 127  Reserved by the IETF 
     128 - 255 Reserved for IETF-Defined Message Class Extensions 
      
3.1.4 Message Length  
    
   The Message Length defines the length of the message in octets, 
   including the header and including all padding bytes.  
    
3.1.5 Tag-Length-Value Format 
    
   SUA messages consist of a Common 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.   

 
Loughney (editor)                                           [Page 19] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
      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) 
    
      Tag field is a 16-bit identifier of the type of parameter. It 
      takes a value of 0 to 65535.  
    
   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 be considered multiples of 4 bytes. 
      
   Parameter Value: variable-length. 
    
         The Parameter Value field contains the actual information to 
         be trasnfered 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 pads the parameter at the end (i.e., after the 
         Parameter Value field) with all zero bytes. The length of the 
         padding is NOT included in the parameter length field. A 
         sender should NEVER pad with more than 3 bytes. The receiver 
         MUST ignore the padding bytes. 
          
   Implementation note: the use of TLV in principle allows the 
   parameters to be placed in a random order in the message. However, 
   some guidelines should be considered for easy processing in the 
   following order: 
    
     -    Parameters needed to correctly process other message 
          parameters, preferably should precede these parameters (such 
          as Routing Context). 
     -    Mandatory parameters preferably SHOULD precede any optional 
          parameters. 
     -    The data parameter will normally be the final one in the 
          message. 
 
Loughney (editor)                                           [Page 20] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     -    The receiver SHOULD accept parameters in any order, except 
          where explicitly mandated. 
 
3.2 SUA Connectionless Messages 
    
   The following section describes the SUA Connectionless transfer 
   messages and parameter contents.  The general message format 
   includes a Common Message Header together with a list of zero or 
   more parameters as defined by the Message Type.  All Message Types 
   can have attached parameters.   
    
3.2.1 Connectionless Data Transfer (CLDT) 
    
   This message transfers data between one SUA to another. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0102          |            Length             |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                        Source Address                         /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0103          |            Length             |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                     Destination Address                       /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0003          |            Length             |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                             Data                              /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Routing Context               Mandatory 
     Flags                         Mandatory 
     Source Address                Mandatory 
     Destination Address           Mandatory 
     Data                          Mandatory 
    

 
Loughney (editor)                                           [Page 21] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   Implementation note: This message covers the following SCCP 
   messages: unitdata (UDT), extended unitdata (XUDT), long unitdata 
   (LUDT). 
 
3.2.2 Connectionless Data Response (CLDR) 
    
   This message is used as a response message by the peer to report 
   errors in the received CLDT message, when the return on error option 
   is set. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0106          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           SCCP Cause                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0102          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                        Source Address                         /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0103          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                     Destination Address                       /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0003          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                             Data                              /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Routing Context               Mandatory 
     Flags                         Mandatory 
     SCCP Cause                    Mandatory 
     Source Address                Mandatory 
     Destination Address           Mandatory 
     Data                          Optional 
    

 
Loughney (editor)                                           [Page 22] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   Implementation note: This message covers the following SCCP 
   messages: unitdata service (UDTS), extended unitdata service (XUDTS) 
   and long unitdata service (LUDTS). 
    
3.3 Connection Oriented Messages 
    
3.3.1 Connection Oriented Data Transfer (CODT) 
 
   This message transfers data between one SUA to another for 
   connection-oriented service. 
    
       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            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
      |         Tag = 0x0107          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Sequence number                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0003          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                             Data                              /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Routing Context               Mandatory 
     Sequence number               Mandatory *1 
     Destination Reference Number  Mandatory  
     Data                          Mandatory 
      
   NOTE *1:   This parameter is not present in case of Expedited Data 
              (ED). 
    
   Implementation note: This message covers the following SCCP 
   messages: DaTa form 1 (DT1), DaTa form 2 (DT2), Expedited Data (ED). 
 
3.3.2 Connection Oriented Data Acknowledge (CODA) 
    
   This message is used to acknowledge receipt of data by the peer.  
   This message is used only with protocol class 3. 
    

 
Loughney (editor)                                           [Page 23] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
       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            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |              Length           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0108          |              Length           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Receive Sequence Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x010A          |              Length           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            Credit                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Destination Reference Number  Mandatory 
     Receive Sequence number       Mandatory *1 
     Credit                        Mandatory *1 
    
   NOTE *1:    Mandatory when representing Data Acknowledgement (AK). 
    
   Implementation note: This message covers the following SCCP 
   messages: data AcKnowledgement (AK), Expedited data Acknowledgement 
   (EA). 
    
3.3.3 Connection Request (CORE) 
    
   This message is used for establishing a signaling connection between 
   two peer endpoints. 
    

 
Loughney (editor)                                           [Page 24] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
        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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0103          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Destination Address                       / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0102          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                        Source Address                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x010A          |           Length              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            Credit                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0003          |           Length              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                             Data                              / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Flags                         Mandatory 
     Source Reference Number       Mandatory 
     Destination Address           Mandatory 
     Source Address                Optional 
     Credit                        Mandatory, protocol class 3 only 
     Data                          Optional 
    
   Implementation note: This message covers the following SCCP message: 
   Connection Request (CR). 
    
3.3.4 Connection Acknowledge (COAK) 
    

 
Loughney (editor)                                           [Page 25] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   This message is used to acknowledge a connection request from the 
   peer endpoint. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 Destination Reference Number                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x010A          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            Credit                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0103          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Destination Address                       / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0003          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                             Data                              / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Flags                         Mandatory 
     Destination Reference Number  Mandatory 
     Source Reference Number       Mandatory 
     Credit                        Mandatory *2 
     Destination Address           Optional *1 
     Data                          Optional 
    
   NOTE *1:    Destination Address parameter will be present in case 
               that the received CORE message conveys the Source 
               Address parameter.  
    
 
Loughney (editor)                                           [Page 26] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   NOTE *2:    Only applicable for protocol class 3. 
    
   Implementation note: This message covers the following SCCP message: 
   Connection Confirm (CC). 
    
3.3.5 Connection Refused (COREF) 
    
   This message is used to refuse a connection request between two peer 
   endpoints. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      
      |         Tag = 0x0105          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 Destination Reference Number                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0106          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           SCCP Cause                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0103          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Destination Address                       / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0003          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                             Data                              / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context                    Mandatory 
     Destination Reference Number       Mandatory 
     SCCP Cause                         Mandatory 
     Destination Address                Optional *1 
     Data                               Optional 
    
   Note *1:   Destination Address parameter will be present in case 
              that the received CORE message conveys the Source Address 
              parameter.  
    
   Implementation note: This message covers the following SCCP message: 
   Connection REFused (CREF). 
    
 
Loughney (editor)                                           [Page 27] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.3.6 Release Request (RELRE) 
    
   This message is used to request a signaling connection between two 
   peer endpoints be released.  All associated resources can then be 
   released. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0106          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                          SCCP Cause                           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0003          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                             Data                              /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Routing Context               Mandatory 
     Destination Reference Number  Mandatory  
     Source Reference Number       Mandatory  
     SCCP Cause                    Mandatory  
     Flags                         Optional 
     Data                          Optional 
    
   Implementation note: This message covers the following SCCP message: 
   connection ReLeaSeD (RLSD). 
    
3.3.7 Release Complete (RELCO) 
    

 
Loughney (editor)                                           [Page 28] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   This message is used to acknowledge the release of a signaling 
   connection between two peer endpoints.  All associated resources 
   should be released. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Destination Reference Number  Mandatory  
     Source Reference Number       Mandatory  
    
   Implementation note: This message covers the following SCCP message: 
   ReLease Complete (RLC). 
    
3.3.8 Reset Request (RESRE) 
    
   This message is used to indicate that the sending SCCP/SUA wants to 
   initiate a reset procedure (re-initialization of sequence numbers) 
   to the peer endpoint. 
    

 
Loughney (editor)                                           [Page 29] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Source Reference Number                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0106          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           SCCP Cause                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory                      
     Destination Reference Number  Mandatory  
     Source Reference Number       Mandatory  
     SCCP Cause                    Mandatory 
      
   Implementation note: This message covers the following SCCP message: 
   ReSet Request (RSR). 
    
3.3.9 Reset Confirm (RESCO) 
    
   This message is used to confirm the Reset Request. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
 
Loughney (editor)                                           [Page 30] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   Parameters 
     Routing Context               Mandatory 
     Destination Reference Number  Mandatory  
     Source Reference Number       Mandatory  
      
   Implementation note: This message covers the following SCCP message: 
   ReSet Confirmation (RSC). 
      
3.3.10 Connection Oriented Error (COERR) 
    
   The COERR message is sent to indicate a protocol data unit error. 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                 Destination Reference Number                  |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0106          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                          SCCP Cause                           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Destination Reference Number  Mandatory 
     SCCP Cause                    Mandatory  
    
   Implementation note: This message covers the following SCCP message: 
   Protocol Data Unit ERRor (ERR). 
    
3.3.11 Connection Oriented Inactivity Test (COIT) 
    
   This message is used for auditing the signaling connection state and 
   the consistency of connection data at both ends of the signaling 
   connection. 

 
Loughney (editor)                                           [Page 31] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0101          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Flags                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0104          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0105          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 Destination Reference number                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0107          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Sequence number                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x010A          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            Credit                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Mandatory 
     Flags                         Mandatory 
     Source Reference Number       Mandatory 
     Destination Reference number  Mandatory 
     Sequence number               Mandatory *1 
     Credit                        Mandatory *1 
    
   NOTE *1:   Information in these parameter fields reflects those 
              values sent in the last data form 2 or data 
              acknowledgement message. They are ignored if the protocol 
              class indicates class 2.  
    
   Implementation note: This message covers the following SCCP message: 
   Inactivity Test (IT). 
    
3.4 Signaling Network Management Messages 
    
3.4.1 Destination Unavailable (DUNA) 
    

 
Loughney (editor)                                           [Page 32] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   In the scope of SUA, this message is covered by the PC- or N-state 
   indication passed between SCCP and local SCCP-user. The DUNA message 
   is sent from the SGP or relay node to all concerned ASPs (servicing 
   SCCP-users considered local to the SGP or relay node, see chapter 
   1.3.1.1), when a destination or SCCP-user has become unreachable.  
   The SUA-User at the ASP is expected to stop traffic to the affected 
   destination or SCCP-user through the SGP or relay node initiating 
   the DUNA.   
    
   The format for DUNA Message parameters is 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 = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0103          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                       Destination Address                     /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0004          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Optional 
     Destination Address           Mandatory *1 
     Info String                   Optional 
    
   Note 1:    The destination address refers to the node that has 
              become unavailable.  When the SSN is included in the 
              Destination Address parameter, the DUNA/DAVA/DRST/SCON 
              message corresponds to the SCCP N-STATE primitive. When 
              SSN is not included in the Destination Address parameter, 
              the DUNA/DAVA/DRST/SCON message corresponds to the     
              SCCP N-PCSTATE primitive. 
                
3.4.2 Destination Available (DAVA) 
    
   In the scope of SUA, this message is covered by the PC- and N-state 
   indication passed between SCCP and local SCCP-user. The DAVA message 
   is sent from the SGP or relay node to all concerned ASPs (servicing 
   SCCP-users considered local to the SGP or relay node, see chapter 
   1.3.1.1) to indicate that a destination (PC or SCCP-user) is now 
   reachable. The ASP SUA-User protocol is expected to resume traffic 
 
Loughney (editor)                                           [Page 33] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   to the affected destination through the SGP or relay node initiating 
   the DAVA.  
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0103          |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                     Destination Address                       /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0004          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Optional  
     Destination Address           Mandatory *1 
     Info String                   Optional 
    
   Note 1:    The destination address refers to the node that has 
              become unavailable.  When the SSN is included in the 
              Destination Address parameter, the DUNA/DAVA/DRST/SCON 
              message corresponds to the SCCP N-STATE primitive. When 
              SSN is not included in the Destination Address parameter, 
              the DUNA/DAVA/DRST/SCON message corresponds to the     
              SCCP N-PCSTATE primitive. 
    
3.4.3 Destination State Audit (DAUD) 
    
   The DAUD message can be sent from the ASP to the SGP (or relay node) 
   to query the availability state of the routes to an affected 
   destination. A DAUD may be sent periodically after the ASP has 
   received a DUNA, until a DAVA is received. The DAUD can also be sent 
   when an ASP recovers from isolation from the SGP (or relay node). 

 
Loughney (editor)                                           [Page 34] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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 = 0x0001          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Destination Address                       /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0004          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Optional  
     Destination Address           Mandatory *1 
     Info String                   Optional 
    
   Note 1:    The destination address refers to the node that has 
              become unavailable.  When the SSN is included in the 
              Destination Address parameter, the DUNA/DAVA/DRST/SCON 
              message corresponds to the SCCP N-STATE primitive. When 
              SSN is not included in the Destination Address parameter, 
              the DUNA/DAVA/DRST/SCON message corresponds to the     
              SCCP N-PCSTATE primitive. 
    
3.4.4 Network Congestion (SCON) 
    
   The SCON message can be sent from the SGP or relay node to all 
   concerned ASPs to indicate that the congestion level in the SS7 
   network to a specified destination has changed. 

 
Loughney (editor)                                           [Page 35] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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 = 0x0001          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Destination Address                       /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x000F          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Congestion Level                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Tag = 0x0004          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Optional 
     Congestion Level              Mandatory 
     Destination Address           Mandatory *1 
     Info String                   Optional 
 
   Note 1:    The destination address refers to the node that has 
              become unavailable.  When the SSN is included in the 
              Destination Address parameter, the DUNA/DAVA/DRST/SCON 
              message corresponds to the SCCP N-STATE primitive. When 
              SSN is not included in the Destination Address parameter, 
              the DUNA/DAVA/DRST/SCON message corresponds to the     
              SCCP N-PCSTATE primitive. 
    
3.4.5 Destination Restricted (DRST) 
 
   The DRST message is optionally sent from the SGP to all concerned 
   ASPs to indicate that the SGP has determined that one or more 
   destinations are now restricted from the point of view of the SGP, 
   or in response to a DAUD message if appropriate. The SUA layer at 
   the ASP is expected to send traffic to the affected destination via 
   an alternate SGP of equal priority, but only if such an alternate 
   route exists and is available. If the affected destination is 
   currently considered unavailable by the ASP, the MTP3-User should be 
   informed that traffic to the affected destination can be resumed.  
   In this case, the SUA layer should route the traffic through the SGP 
   initiating the DRST message. 
 
Loughney (editor)                                           [Page 36] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   This message is optional for the SGP to send and it is optional for 
   the ASP to act on any information received in the message.  
    
       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 = 0x0001          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Destination Address                     /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Tag = 0x0004          |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context               Optional 
     Destination Address           Mandatory *1 
     Info String                   Optional 
    
   Note 1:    The destination address refers to the node that has 
              become unavailable.  When the SSN is included in the 
              Destination Address parameter, the DUNA/DAVA/DRST/SCON 
              message corresponds to the SCCP N-STATE primitive. When 
              SSN is not included in the Destination Address parameter, 
              the DUNA/DAVA/DRST/SCON message corresponds to the     
              SCCP N-PCSTATE primitive. 
 
3.5 Application Server Process State Maintenance Messages 
 
3.5.1 ASP Up (UP) 
    
   The ASP UP (UP) message is used to indicate to a remote SUA peer 
   that the Adaptation layer is up and running. 

 
Loughney (editor)                                           [Page 37] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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 = 0x000E       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Identifier                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
      |            Tag = 0x0109       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Capabilities                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Tag = 0x0004       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     ASP Identifier                Optional *1 
     ASP Capabilities              Optional 
     Info String                   Optional 
    
   Note 1:  ASP Identifier MUST be used where the IPSP/SGP cannot 
            identify the ASP by pre-configured address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).   
    
3.5.2 ASP Up Ack (UP ACK) 
    
   The ASP UP Ack message is used to acknowledge an ASP-Up message 
   received from a remote SUA peer. 
    
       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 = 0x000E       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Identifier                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
      |            Tag = 0x0109       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Capabilities                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Tag = 0x0004       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
 
Loughney (editor)                                           [Page 38] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     ASP Identifier                Optional *1 
     ASP Capabilities              Optional  
     Info String                   Optional 
    
   Note 1:  ASP Identifier MUST be used where the IPSP/SGP cannot 
            identify the ASP by pre-configured address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).   
    
3.5.3 ASP Down (DOWN) 
    
   The ASP Down (DOWN) message is used to indicate to a remote SUA peer 
   that the adaptation layer is not running. 
    
       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 = 0x0004       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Info String         Optional 
    
3.5.4 ASP Down Ack (DOWN ACK) 
    
   The ASP DOWN Ack message is used to acknowledge an ASP-Down message 
   received from a remote SUA peer. 
    
       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 = 0x0004       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Info String                   Optional 
    
   Note: ASP DOWN ACK will always be sent to acknowledge an ASP DOWN.   
    
3.5.5 Heartbeat (BEAT) 
    
   The Heartbeat message is optionally used to ensure that the SUA 
   peers are still available to each other.  
    
   The format for the BEAT message is as follows: 
 
Loughney (editor)                                           [Page 39] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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 = 0x0009       |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Heartbeat Data                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Heartbeat Data           Optional 
    
3.5.6 Heartbeat Ack (BEAT ACK) 
    
   The Heartbeat ACK message is sent in response to a BEAT message. A 
   peer MUST send a BEAT ACK in response to a BEAT message. It includes 
   all the parameters of the received Heartbeat message, without any 
   change. 
    
   The format for the BEAT ACK message is 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 = 0x0009       |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Heartbeat Data                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Heartbeat Data           Optional 
    
3.6 ASP Traffic Maintenance Messages 
    
3.6.1 ASP Active (ACTIVE) 
    
   The ASPAC message is sent by an ASP to indicate to a remote SUA peer 
   that it is Active and ready to process signaling traffic for a 
   particular Application Server. 
    
   The format for the ACTIVE message is as follows: 

 
Loughney (editor)                                           [Page 40] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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 = 0x000B         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                       Traffic Mode Type                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Tag = 0x0004         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Traffic Mode Type        Mandatory 
     Routing Context          Optional 
     Info String              Optional 
    
3.6.2 ASP Active Ack (ACTIVE ACK) 
    
   The ASPAC Ack message is used to acknowledge an ASP-Active message  
   received from a remote SUA peer. 
    
   The format for the ACTIVE Ack message is 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 = 0x000B         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                       Traffic Mode Type                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Tag = 0x0004         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Traffic Mode Type        Mandatory 
 
Loughney (editor)                                           [Page 41] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     Routing Context          Optional 
     Info String              Optional 
    
   The value of the Traffic Mode Type and Routing Context parameters is 
   the same as for the ASP-Active message. 
    
   The value of the optional Info String parameter is the same as for 
   the ASP-Active message. 
    
3.6.3 ASP Inactive (INACTIVE) 
    
   The INACTIVE message is sent by an ASP to indicate to a remote SUA 
   peer that it is no longer processing signaling traffic within a 
   particular Application Server.   
    
   The format for the ASPIA message parameters is 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 = 0x0006         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Tag = 0x0004         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          INFO String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context          Optional 
     INFO String              Optional 
    
3.6.4 ASP Inactive Ack (INACTIVE ACK) 
    
   The INACTIVE Ack message is used to acknowledge an ASP-Inactive 
   message received from a remote SUA peer. 
    
   The format for the INACTIVE Ack message is as follows: 

 
Loughney (editor)                                           [Page 42] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Tag = 0x0004         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          INFO String                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Parameters 
     Routing Context     Optional 
     INFO String         Optional 
    
   The value of the optional Info String parameter is the same as for 
   the ASP-Active message. 
    
3.7 SUA Management Messages  
 
   These messages are used for managing SUA and the representations of 
   the SCCP subsystems in the SUA layer. 
 
3.7.1 Error (ERR) 
    
   The ERR message is sent between two SUA peers to indicate an error 
   situation. The Data parameter is optional, possibly used for error 
   logging and/or debugging. 
    
       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 = 0x000C         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                          Error Code                           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0007         |             Length            |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                        Diagnostic Info                        / 
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Parameters 
     Error Code                    Mandatory  
     Diagnostic Info               Optional 
           

 
Loughney (editor)                                           [Page 43] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.7.2 Notify (NTFY) 
    
   The Notify message used to provide an autonomous indication of SUA 
   events to an SUA peer.   
    
       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 = 0x000D         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           Status                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Tag = 0x000E       |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Identifier                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
      |          Tag = 0x0006         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Tag = 0x0004         |             Length            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The NTFY message contains the following parameters: 
    
   Parameters 
     Status                        Mandatory 
     ASP Identifier                Optional *1 
     Routing Context               Optional 
     Info String                   Optional 
    
   Note 1:  ASP Identifier MUST be used where the IPSP/SGP cannot 
            identify the ASP by pre-configured address/port number 
            information (e.g., where an ASP is resident on a Host using 
            dynamic address/port number assignment).   
    
3.8 Common Parameters 
    
   These TLV parameters are common across the different adaptation 
   layers. 
    
   Parameter Name                     Parameter ID 
   ==============                     ============ 
   Reserved                             0x0000 
   Not used in SUA                      0x0001 
   Not used in SUA                      0x0002 
   Data                                 0x0003 
 
Loughney (editor)                                           [Page 44] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   Info String                          0x0004  
   Affected Point Code                  0x0005 
   Routing Context                      0x0006 
   Diagnostic Info                      0x0007 
   Not used in SUA                      0x0008 
   Heartbeat Data                       0x0009 
   Reason                               0x000A 
   Traffic Mode Type                    0x000B 
   Error Code                           0x000C 
   Status                               0x000D 
   ASP Identifier                       0x000E 
   Congestion Level                     0x000F 
    
3.8.1 Not Used  
    
   Use of Parameter ID 0x0001 in SUA messages is not supported. 
    
3.8.2 Not used 
      
   Use of Parameter ID 0x0002 in SUA messages is not supported. 
    
3.8.3 Data 
    
       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 = 0x0003         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                             Data                              / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The Data parameter field contains the SS7 SCCP-User application 
   message, for example an INAP/TCAP message. 
    
3.8.4 Info String  
    
   The INFO String parameter can carry any meaningful 8-BIT ASCII 
   character string along with the message.  Length of the INFO String 
   parameter is from 0 to 255 characters.  No procedures are presently 
   identified for its use but service providers may use the INFO String 
   for debugging purposes. 
    
       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 = 0x0004         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                          Info String                          / 
                                                                        
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
Loughney (editor)                                           [Page 45] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
3.8.5 Affected Point Code 
    
   The Affected Point Code parameter contains one or more Affected 
   Destination Point Codes, each a three-octet parameter to allow for 
   14-, 16- and 24-bit binary formatted SS7 Point Codes.  Affected 
   Point codes that are less than 24-bits, are padded on the left to 
   the 24-bit boundary.   
    
       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 = 0x0005         |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Mask       |                 Affected PC 1                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                             . . .                             / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The encoding is shown below for ANSI and ITU Point Code examples. 
    
   ANSI 24-bit Point Code: 
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Mask      |    Network    |    Cluster    |     Member    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
                      |MSB-----------------------------------------LSB| 
    
   ITU 14-bit Point Code: 
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Mask      |0 0 0 0 0 0 0 0 0 0|Zone |     Region    | SP  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
                                           |MSB--------------------LSB| 
    
   It is optional to send an Affected Point Code parameter with more 
   than one Affected PC but it is mandatory to receive it.  All the 
   Affected PCs included MUST be within the same Routing Context.  
   Including multiple Affected PCs may be useful when reception of a 
   management message or a linkset event simultaneously affects the  
   availability status of a list of destinations at an SG.   
    
   Mask: 8-bits 
    
 
Loughney (editor)                                           [Page 46] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   The Mask parameter can be used to identify a contiguous range of 
   Affected Destination Point Codes, independent of the point code 
   format.  Identifying a contiguous range of Affected PCs may be 
   useful when reception of an MTP3 management message or a linkset 
   event simultaneously affects the availability status of a series of  
   destinations at an SG.  
    
   The Mask parameter is an integer representing a bit mask that can be 
   applied to the related Affected PC field.  The bit mask identifies 
   how many bits of the Affected PC field are significant and which are 
   effectively "wild-carded".  For example, a mask of "8" indicates 
   that the last eight bits of the PC is "wild-carded".  For an ANSI 
   24-bit Affected PC, this is equivalent to signaling that all PCs in 
   an ANSI Cluster are unavailable.  A mask of "3" indicates that the 
   last three bits of the PC is "wild-carded".  For a 14-bit ITU 
   Affected PC, this is equivalent to signaling that an ITU Region is 
   unavailable. 
    
   For use in SUA, the mask parameter MUST always be coded zero and 
   there MUST be only a single point code present. 
    
3.8.6 Routing Context 
    
       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             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Routing Context                         / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The Routing Context parameter contains (a list of) 4-byte unsigned 
   integers indexing the Application Server traffic that the sending 
   ASP is configured/registered to receive.  There is a one-to-one 
   relationship between an index entry and a Routing Key or AS Name.   
    
   An Application Server Process may be configured to process traffic 
   for more than one logical Application Server.  From the perspective 
   of an ASP, a Routing Context defines a range of signaling traffic 
   that the ASP is currently configured to receive from the SG.   
    
   Additionally, the Routing Context parameter identifies the SS7 
   network context for the message, for the purposes of logically 
   separating the signaling traffic between the SGP and the Application 
   Server Process over a common SCTP Association, when needed.  An 
   example is where an SGP is logically partitioned to appear as an 
   element in several different national SS7 networks.  It implicitly 
   defines the SS7 Point Code format used, the SS7 Network Indicator 
   value and SCCP protocol type/variant/version used within a separate 
   SS7 network. It also defines the network context for the PC and SSN 
 
Loughney (editor)                                           [Page 47] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   values. Where an SGP operates in the context of a single SS7 
   network, or individual SCTP associations are dedicated to each SS7 
   network context, this functionality is not needed. 
    
   Where the optional Routing Context parameter is present, it SHOULD 
   be the first parameter in the message as it defines the format 
   and/or interpretation of the parameters containing a PC or SSN 
   value. 
    
3.8.7 Diagnostic Information 
    
   The Diagnostic Information can be used to convey any information 
   relevant to an error condition, to assist in the identification of 
   the error condition.  In the case of an Adaptation Layer Identifier 
   or Traffic Handling Mode, the Diagnostic Information includes the 
   received parameter.  In the other cases, the Diagnostic information 
   may be the first 40 bytes of the offending message. 
    
       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 = 0x0007          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                     Diagnostic Information                    / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
3.8.8 Not Used 
    
   Parameter ID 0x0008 is not used in SUA. 
    
3.8.9 Heartbeat Data 
    
   The sending node defines the Heartbeat Data field contents. It may 
   include a Heartbeat Sequence Number and/or Timestamp, or other 
   implementation specific details. 
    
   The receiver of a Heartbeat message does not process this field as 
   it is only of significance to the sender.  The receiver echoes the 
   content of the Heartbeat Data in a BEAT-Ack message. 
    
       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 = 0x0009          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      /                       Heartbeat Data                          / 
      \                                                               \ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    

 
Loughney (editor)                                           [Page 48] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   The data field can be used to store information in the heartbeat 
   message useful to the sending node (e.g. the data field can contain 
   a time stamp, a sequence number, etc.). 
    
3.8.10 Reason 
    
   The Reason parameter indicates the reason why the remote SUA 
   adaptation layer is unavailable.   
    
       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 = 0x000A          |            Length = 8         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Reason                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   Reason: 32-bit (unsigned integer) 
    
   The valid values for Reason are shown in the following table. 
    
          0         Unspecified 
          1         User Unavailable 
          2         Management Blocking 
          3         ASP Fault 
    
3.8.11 Traffic Mode Type 
 
   The Traffic Mode Type parameter identifies the traffic mode of 
   operation of the ASP within an AS.  
    
       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 = 0x000B         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      Traffic Mode Type                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The valid values for Type are shown in the following table. 
    
               1         Over-ride 
               2         Load-share 
               3         Over-ride (Standby) 
               4         Loadshare (Standby) 
    
   Within a Routing Context, Over-ride and Loadshare Types cannot be 
   mixed.  The Over-ride value indicates that the ASP is operating in 
   Over-ride mode, and the ASP wishes to take over all traffic for an 
   Application Server (i.e., primary/back-up operation), over-riding 
   any currently active ASP in the AS.  In Load-share mode, the ASP 
 
Loughney (editor)                                           [Page 49] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   wishes to share in the traffic distribution with any other currently 
   active ASPs.  The Standby versions of the Over-ride and Loadshare 
   Types indicate that the ASP is declaring itself ready to accept 
   traffic but leaves it up to the sender as to when the traffic is 
   started. Over-ride (Standby) indicates that the traffic sender 
   continues to use the currently active ASP until it can no longer 
   send/receive traffic (i.e., the currently active ASP transitions to 
   Down or Inactive).  At this point the sender may immediately move 
   the ASP to Active and commence traffic.  Loadshare (Standby) is 
   similar - the sender continues to loadshare to the current ASPs 
   until it is determined that there is insufficient resources in the 
   Loadshare group.  When there are insufficient ASPs, the sender may 
   immediately move the ASP to Active. 
 
3.8.12 Error Code 
    
       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 =0x000C            |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                          Error Code                           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The Error Code parameter indicates the reason for the Error Message.  
   The Error parameter value can be one of the following values: 
    
        Invalid Version                                0x01 
        n/a                                            0x02 
        Unexpected Message Class                       0x03 
        Invalid Message Type                           0x04 
        Unsupported Traffic Handling Mode              0x05 
        Unexpected Message                             0x06 
        Protocol Error                                 0x07 
        Invalid Routing Context                        0x08 
        Invalid Stream Identifier                      0x09 
        Parameter Field Error                          0x0B 
        Unexpected Parameter                           0x0C 
        Duplicated Parameter                           0x0D 
        Error - ASP Identifier Required                0x0E 
        Error - Invalid ASP Identifier                 0x0F  
        Refused - ASP Identifier Required              0x10 
         
   The "Invalid Version" error would be sent if a message was received 
   with an invalid or unsupported version.  The Error message would 
   contain the supported version in the Common header.  The Error 
   message could optionally provide the supported version in the 
   Diagnostic Information area. 
    
   The "Invalid Routing Context" error would be sent by a SG if an ASP 
   sends a message with an invalid (unconfigured) Routing Context 
 
Loughney (editor)                                           [Page 50] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   value.  The Error message could optionally provide the invalid 
   Routing Context in the Diagnostic Information area. 
    
   The "Unexpected Message Class" error would be sent if a message with 
   an unsupported Message Class were received. 
    
   The "Unexpected Message Type" error would be sent if a message with 
   an unsupported Message Type were received. 
    
   The "Unsupported Traffic Handling Mode" error would be sent by a SGP 
   if an ASP sends an ASP Active with an unsupported Traffic Handling 
   Mode.  An example would be a case in which the SGP did not support 
   load sharing. 
    
   The "Unexpected Message" error would be sent by an ASP if it 
   received a message that is unexpected in the ASP's current state. 
    
   The "Protocol Error" error would be sent for any protocol anomaly 
   (i.e. a bogus message). 
    
   The "Invalid Routing Context" error would be sent by a SGP if the 
   routing context cannot be supported, e.g. not unique. 
    
   The "Invalid Stream Identifier" error would be sent if a message was 
   received on an unexpected SCTP stream. 
    
   The "Parameter Field Error" would be sent if a message with a 
   parameter having a wrong length field. 
    
   The "Unexpected Parameter" error would be sent if a message contains 
   an invalid parameter. 
     
   The "Duplicated Parameter" error would be sent if a message contains 
   a parameter more than once. 
    
   To be sent in response to an ASPUP message which does not contain an 
   ASP Id parameter when the SGP requires one.  Then, instead of simply 
   adding 8 bytes to ever ASPUP message as proposed, the ASP can go 
   around again a second time with an ASP ID. 
    
3.8.13 Status  
    
   The Status parameter identifies the type of the status that is being 
   notified and the Status ID. 
    
       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 = 0x000D         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Status Type           |            Status ID          | 
 
Loughney (editor)                                           [Page 51] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The valid values for Status Type (16 bit unsigned integer) are: 
    
          1     Application Server state change (AS_State_Change) 
          2     Other  
    
   The Status ID parameter contains more detailed information for the 
   notification, based on the value of the Status Type. 
    
   If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit 
   unsigned integer) values are: 
    
          1    reserved 
          2    Application Server Inactive (AS-Inactive) 
          3    Application Server Active (AS-Active) 
          4    Application Server Pending (AS-Pending) 
    
    
   These notifications are sent from an SGP to an ASP upon a change in 
   status of a particular Application Server. The value reflects the 
   new state of the Application Server. 
    
   If the Status Type is ôOther", then the following Status Information 
   values are defined: 
    
          1    Insufficient ASP resources active in AS 
          2    Alternate ASP Active 
              
   These notifications are not based on the SGP reporting the state 
   change of an ASP or AS.  In the Insufficient ASP Resources case, the 
   SGP is indicating to an "Inactive" ASP(s) in the AS that another ASP 
   is required to handle the load of the AS (Load-sharing mode).  For 
   the Alternate ASP Active case, an ASP is informed when an alternate 
   ASP transitions to the ASP-Active state in Over-ride mode.   
    
3.8.14 ASP Identifier 
    

 
Loughney (editor)                                           [Page 52] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
       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 = 0x000E          |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        ASP Identifier                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   ASP Identifier field: 32-bits (unsigned integer) 
    
   The ASP Identifier field contains a unique value that is locally 
   significant amoung the ASPs that support an AS.  The SGP should save 
   the ASP Identifier to be used, if necessary, with the Notify message 
   (see Section 3.7.2). 
    
3.8.15 Congestion Level 
    
       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 = 0x000E          |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Congestion Level                        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       
   Congestion Level field: 8-bits (unsigned integer) 
    
   The valid values for the Congestion Level parameter range from 0 to 
   7, where 0 indicates least congested and 7 indicates most congested 
   subsystem. 
    
3.9 SUA-Specific parameters  
    
   These TLV parameters are specific to the SUA protocol. 
 
   Parameter Name                     Parameter ID 
   ==============                     ============ 
   Flags                                0x0101 
   Source Address                       0x0102 
   Destination Address                  0x0103 
   Source Reference Number              0x0104 
   Destination Reference Number         0x0105 
   SCCP Cause                           0x0106 
   Sequence Number                      0x0107 
   Receive Sequence Number              0x0108 
   ASP Capabilities                     0x0109 
   Credit                               0x010A 
   Reserved                             0x010B 
   SMI / Subsystem                      0x010C 

 
Loughney (editor)                                           [Page 53] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   Destination/Source Address Sub-Parameters 
   =========================================== 
   Global Title                         0x8001  
   Point Code                           0x8002 
   Subsystem Number                     0x8003 
   IPv4 Address                         0x8004 
   Hostname                             0x8005           
   IPv6 Addresses                       0x8006 
    
3.9.1 Flags 
    
   The Flags parameter is a conglomerate of following parameters, 
   described in ITU-T Recommendation Q.713: 
    
      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 = 0x0101          |             Length = 8        | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Seq. Control  |  Importance   |  Hop Counter  |  Protocol Cl. | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Sequence Control (1.1.2/Q.714) 
    
         Bits 1-5 are coded with the value of the sequence control 
         parameter associated with a group of messages and are chosen 
         so as to ensure proper loadsharing of message groups over SLS 
         values while ensuring that sequence control values within 
         message groups have the sequence control value coded with the 
         same value as the initial message of the message group. 
          
         Bits 6-8 are spare bits and should be coded zero. 
    
   Protocol class (3.6/Q.713) 
           
          Bits 1-2 indicate the protocol class. 
    
          Value     Description  
            0       Class 0 (connectionless service)  
            1       Class 1 (connectionless service)  
            2       Class 2 (connection-oriented service)  
            3       Class 3 (connection-oriented service) 
    
          Bit 8 indicates the use of the return on error procedure. 
    
          Value     Description  
           0x0      No special options 
           0x1      Return message on error 
    
          Bits 3-7 are spare and should be coded zero. 
 
Loughney (editor)                                           [Page 54] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   Hop Counter (3.18/Q.713) 
    
         The value of the hop counter is decremented with each global 
         title translation, and should be in the range 15 to 1. 
    
   Importance (3.19/Q.713) 
    
         Bits 1-3 are coded to indicate the importance of the messages. 
         The values are between 0 and 7, where the value of 0 indicates 
         the least important and 7 indicates the most important. 
    
         Bits 4-8 are spare bits and should be coded zero. 
 
3.9.2 Source Address  
    
       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 = 0x0102         |      Parameter Length         |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      Routing Indicator        |       Address Indicator       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      /                       Address parameter(s)                    /  
      \                                                               \  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    
   The Source Address field may contain the SCCP Calling Party Address. 
   See chapters 3.4 and 3.5 of ITU-T Recommendation Q.713. 
    
   The following combinations of address parameters are valid : 
    
     -    Global Title (e.g. E.164 number) + optional PC and/or SSN, 
          SSN may be zero, when routing is done on Global Title 
     -    SSN (non-zero) + optional PC and/or Global Title, when 
          routing is done on PC + SSN. The PC is mandatory in the 
          source address when sending from SGP to ASP, and in the 
          destination address when sending from ASP to SGP to reach the 
          SS7 SEP. 
     -    Hostname + optional SSN, when routing is done by Hostname 
     -    SSN (non-zero) and optional IP address (IPv4 or IPv6) when 
          routing is done on IP address + SSN 

3.9.2.1 Routing Indicator 
    
   The following values are valid for the routing indicator : 
    
     Reserved                      0 
     Route on Global Title         1 
     Route on SSN + PC             2 
 
Loughney (editor)                                           [Page 55] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     Route on Hostname             3 
     Route on SSN + IP Address     4 
    
   The routing indicator determines which address parameters need to be 
   present in the address parameters field. 
    
3.9.2.2 Address Indicator 
 
   This parameter is needed for interworking with SS7 networks. The 
   address indicator specifies what address parameters are actually 
   received in the SCCP address from the SS7 network, or are to be 
   populated in the SCCP address when the message is sent into the SS7 
   network. The value of the routing indicator needs to be taken into 
   account. 
    
   The address indicator is coded as follows: 
    
    Bit 1 is used to indicate inclusion of the SSN 
    
    0         Do not include SSN when optional 
     1         Include SSN 
    
     Bit 2 is used to indicate inclusion of the PC 
    
    0         Do not include PC, regardless of the routing indicator 
              value 
     1        Include PC 
    
    Bit 3 is used to indicate inclusion of the Global Title 
    
    0         Do not include GT when optional (routing indicator /= 1) 
     1        Include GT 
    
   Bits 4-8 are spare and should be coded zero. 

3.9.2.3 Global Title 
      
     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 = 0x8001          |            Length             | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |   No. Digits  | Trans. type   |    Num. Plan  | Nature of Add | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                         Global Title Digits                   | 
     /                                                               / 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Number of Digits: 
 
Loughney (editor)                                           [Page 56] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   This is the number of digits contained in the Global Title. 
    
   Translation type: 
    
     0              Unknown 
     1 - 63         International services 
     64 - 127       Spare 
     128 û 254      National network specific 
     255            Reserved 
    
   Numbering Plan: 
    
     0         unknown 
     1         ISDN/telephony numbering plan (Recommendations E.163 and 
               E.164) 
     2         generic numbering plan 
     3         data numbering plan (Recommendation X.121) 
     4         telex numbering plan (Recommendation F.69) 
     5         maritime mobile numbering plan (Recommendations E.210, 
               E.211) 
     6         land mobile numbering plan (Recommendation E.212) 
     7         ISDN/mobile numbering plan (Recommendation E.214) 
     8 - 13    spare 
     14        private network or network-specific numbering plan 
     15 - 126  spare 
     127       reserved. 
    
   Nature of Address: 
    
     0         unknown 
     1         subscriber number 
     2         reserved for national use 
     3         national significant number 
     4         international number 
     5 - 255   Spare 
    
   Global Title: 
    
    Octets contain a number of address signals and possibly filler as 
    shown: 
    

 
Loughney (editor)                                           [Page 57] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
      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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.| 
     |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |        .............          |filler |N addr.|   filler      | 
     |                               |if req | sig.  |               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   All filler bits MUST be set to 0. 
    
   Address signals to be coded as defined in ITU-T Q.713 Section 
   3.4.2.3.1. 
    
   The actual Global Title format to be used for interworking with the 
   SS7 network is defined by the network ID, or is implicitly 
   understood if the SGP only operates in one SS7 network partition. 
   The formats are defined in chapter 3.4.2.3 of Q.713. The following 
   conversions of the Translation Type, Numbering Plan and Nature of 
   Address elements apply: 
    
   1) SS7 network uses GTI = 0001 
    
   Nature of Address is ignored. It is implicitly assumed that 
   Translation Type = Unknown and Numbering Plan = E.164 (value 1).  
    
   2) SS7 network uses GTI = 0010 
    
   This is most commonly used in North American networks. The 
   Translation Type implicitly determines Nature of Address and 
   Numbering Plan. This data can be configured in the SG. The number of 
   digits is always even and determined by the SCCP address length.  
    
   3) SS7 network uses GTI = 0011 
    
   Numbering Plan and Translation Type are taken over. It is implicitly 
   assumed that the Nature of Address = Unknown.  
    
   4) SS7 network uses GTI = 0100 
    
   This format is used in international networks and most commonly in 
   networks outside North America. All information to populate the 
   source address is present in the SCCP Address. 

 
Loughney (editor)                                           [Page 58] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.9.2.4 Point Code 
    
     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 = 0x8002          |            Length = 8         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                            Point Code                         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   See chapter 3.2.5 Affected Point Code for the layout of the Point 
   Code field. 

3.9.2.5 Subsystem Number 
    
     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 = 0x8003          |            Length = 8         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                            spare       | SSN value     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The internationally standardized SSN values are described in chapter 
   3.4.2.2 of Q.713. 

3.9.2.6 IP Addresses 
    
   The IP address formats can use different tags. It should be noted 
   that if the source address is in a certain IP version, the 
   destination address should also be in the same IP version. 
    
     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 = 0x8004/0x8006      |            Length             | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                        IPv4 or IPv6 Address                   | 
     /                                                               / 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Note: The tag value 0x8004 is for an IPv4 address and 0x8006 is for 
   IPv6. 
    

 
Loughney (editor)                                           [Page 59] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.9.2.7 Hostname 
    
     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 = 0x8005          |            Length             | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                            Host Name                          | 
     /                                                               / 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   If the type of address is Host Name, then the labels in the host 
   name have to be reversed to obtain an efficient Host Name encoding 
   form for the Global title translation function. 
    
   hostname: zzzz.yyy....edc.ab  
   should be transformed to 
   HTname : ab.edc....yyy.zzzz 
    
   The labels of the Host Name are then encoded using the encoding 
   rules of the labels described in [IDNS]. The end of the Host name is 
   indicated by 0x00. 
    
   Example: 
   hostname = www.reindael.security.org 
   First the name has to be reverse to have the gTLD on the left side. 
   Global Title name: org.security.reindael.www  
    
   Then the result of applying the rules of the iDNS is: 
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    x |       3       |       O       |       R       |       G       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +4 |       8       |       S       |       E       |       C       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +8 |       U       |       R       |       I       |       T       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +12|       Y       |       8       |       R       |       E       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +16|       I       |       N       |       D       |       A       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +20|       E       |       L       |       3       |       W       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   +24|       W       |       W       |       00      |               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

 
Loughney (editor)                                           [Page 60] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
3.9.3 Destination Address 
    
      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 = 0x0103         |      Parameter Length         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |      Routing Indicator        |       Address Indicator       | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     /                       address parameter(s)                    / 
     \                                                               \ 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The format of this parameter is identical to the Source Address 
   parameter. 
 
3.9.4 Source Reference Number 
    
       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 = 0x0104         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Source Reference Number                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The source reference number is a 4 octet long integer. This is 
   allocated by the source SUA instance. 
 
3.9.5 Destination Reference Number 
    
       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 = 0x0105         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 Destination Reference Number                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The destination reference number is a 4 octet long integer. This is 
   allocated by the destination SUA instance. 
    
3.9.6 SCCP Cause 
 

 
Loughney (editor)                                           [Page 61] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
       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 = 0x0106          |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Spare               |   Cause Type  |  Cause Value  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This parameter bundles the SCCP parameters Release cause, Return 
   cause, Reset cause, Error cause and Refusal cause. 
    
   Cause Type can have the following values: 
    
        Return Cause          0x1 
        Refusal Cause         0x2 
        Release Cause         0x3 
        Reset Cause           0x4 
        Error Cause           0x5 
    
   Cause Value contains the specific cause value.  Below gives examples 
   for ITU SCCP values.  ANSI references can be found in ANSI T1.112.3 
    
   Cause value in        Correspondence with Reference 
   SUA message           SCCP parameter  
   ------------------    -----------------   --------- 
   CLDR                  Return Cause        ITU-T Q.713 Chap 3.12 
   COREF                 Refusal Cause       ITU-T Q.713 Chap 3.15 
   RELRE                 Release Cause       ITU-T Q.713 Chap 3.11 
   RESRE                 Reset Cause         ITU-T Q.713 Chap 3.13 
   ERR                   Error Cause         ITU-T Q.713 Chap 3.14  
    
3.9.7 Sequence Number 
    
       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 = 0x0107         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Spare               |  Rec Seq Num|M| Sent Seq Num  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This parameter is used to indicate whether ômoreö data will follow 
   in subsequent CODT messages, and/or to number each CODT message 
   sequentially for the purpose of flow control. It contains the 
   received as well as the sent sequence number, P(R) and P(S) in 
   Q.713, chapters 3.7 and 3.9.  
    
   As such it can also be used to acknowledge the receipt of data 
   transfers from the peer in case of protocol class 3. 
    
   Sent Sequence Number is one octet and is coded as follows: 
 
Loughney (editor)                                           [Page 62] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
          Bits 2-8 are used to indicate the Send Sequence Number P(S). 
          Bit 1 (LSB) of octet 1 is spare. 
    
   Received Sequence Number is one octet, and is coded as follows: 
    
          Bits 2-8 are used to indicate the Received Sequence Number  
          P(R). 
          Bit 1 (LSB) is used for the more data indication, as follows: 
           
          0         no more data 
          1         more data 
    
3.9.8 Receive Sequence Number 
    
    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 = 0x0108         |             Length = 8        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    spare                      |  Rec Seq Num  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   This parameter is used exclusively for protocol class 3 in the data 
   acknowledgment message to indicate the lower edge of the receiving 
   window. See Q.713, chapter 3.8. 
    
   It is a 1 octet long integer coded as follows: 
    
      Bits 8-2 are used to indicate the Receive Sequence Number P(R). 
    
      Bit 1 is spare. 
    
3.9.9 ASP Capabilities 
    
   This parameter is used so that the ASP can report its capabilities 
   regarding SUA for supporting different protocol classes and 
   interworking scenarios. 
    
       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 = 0x0109         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            spare              |0 0 0 0|a|b|c|d| Interworking  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Flags 
    
     a - Protocol Class 3 
     b - Protocol Class 2 
 
Loughney (editor)                                           [Page 63] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
     c - Protocol Class 1 
     d - Protocol Class 0 
    
     It is mandatory to support at least Protocol Class 0. 
    
   Interworking  
    
     Values 
    
     0x0 indicates no interworking with SS7 Networks. 
     0x1 indicates IP Signaling Endpoint (ASP), interworking with SS7 
         networks. 
     0x2 indicates Signaling Gateway. 
     0x3 indicates relay node support.  
    
3.9.10 Credit 
    
       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 = 0x010A         |             Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            Credit                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The length of the credit field is is one octet.  See ITU-T Q.713  
   Chapter 3.10. The parameter is used for protocol class 3 
   exclusively. 
    
3.9.11 SMI / Subsystem 
    
      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 = 0x010C       |             Length = 8        | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |             SMI               |     Spare     |      SSN      | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Subsystem Number (SSN) is one octet. 
    
   Subsystem Multiplicity Indicator (SMI) can have the following 
   values: 
    
     0x00      Reserved 
     0x01      Replicated 
     0x02      Solitary 
     0x03      Unknown 
      
4 Procedures 
    
 
Loughney (editor)                                           [Page 64] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   The SUA layer needs to respond to various local primitives it 
   receives from other layers as well as the messages that it receives 
   from the peer SUA layers.  This section describes the SUA procedures 
   in response to these events. 
    
4.1 SCCP û SUA Interworking at the SG 
    
   On the SG, the SCCP routing or interworking function determines that 
   the message is sent to an AS via the SUA stack, based on information 
   in the incoming message. The SUA Address Mapping Function identifies 
   the appropriate Application Server (AS) and selects an active ASP 
   from the list of ASPs servicing this AS. The appropriate ASP can be 
   determined based on the routing information in the incoming message, 
   local load sharing information, etc. The appropriate SUA message is 
   then constructed and sent to the appropriate endpoint, via the 
   correct SCTP association and stream. 
    
   The SGP MUST take care of any segmentation / reassembly issues at 
   the border of the SS7 and IP networks.  The IPSP may not have any 
   knowledge about the requirements regarding the maximum supported 
   message length of the SS7 network to which it is sending. However, 
   since there is in principle no limit to the use of the more 
   indicator in SS7 networks, there is still need for connection-
   oriented segmentation / reassembly procedures in the IPSP as well.  
    
   If a SGP is operated in mated pair configuration, and it receives a 
   non-first XUDT segment for which no reassembly process exists, it 
   should pass on this segment to it's mate; if the segment was already 
   received from the mated SGP or if no mated SGP is available, the 
   return on error procedures is invoked. 
    
4.1.1 Connection Oriented Procedures 
    
   On receipt of a CR message from the SS7 network, a first connection 
   section is established between the SGP and SS7 originating node. A 
   second connection section is to be setup between the SGP and the 
   appropriate ASP, determined by the SUA outgoing mapping function. 
    
   Local resources and source local reference numbers are allocated to 
   keep/retrieve the required address information and the connection 
   state to format and route subsequent messages for the connection 
   based on reference numbers only. The existing SCCP procedures MAY be 
   deployed at the SGP to perform this coupling. 
    
   The same applies for a CORE message received from the IP network, 
   destined for an SS7 node. After allocating the necessary resources, 
   the SUA incoming mapping function formats the appropriate SCCP 
   message and passes it on to SCCP routing for further processing 
   (sending into the SS7 network). 
    

 
Loughney (editor)                                           [Page 65] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   The SGP MUST take care of any segmentation / reassembly issues at 
   the border of the SS7 and IP networks.  The IPSP may not have any 
   knowledge about the requirements regarding the maximum supported 
   message length of the SS7 network to which it is sending. However, 
   since there is in principle no limit to the use of the more 
   indicator in SS7 networks, there is still need for connection-
   oriented segmentation / reassembly procedures in the IPSP as well. 
    
4.1.2 Connectionless Procedures 
    
   The existing SCCP routing functions may be enhanced to support 
   interworking with the SUA layer. The function of SUA can be limited 
   to outgoing mapping (formatting of the CLDT or CLDR message) and 
   selection of the correct SCTP association (ASP) and stream. For the 
   direction ASP to SG, the SUA incoming mapping formats the 
   appropriate SCCP message (UDT(S), XUDT(S) or LUDT(S)) and passes it 
   on to SCCP routing for further processing. 
    
4.1.3 SS7 Signaling Network Management Procedures 
    
   When an SCCP Subsystem Management (SCMG) message is received from 
   the SS7 network, the SGP needs to determine whether there are 
   concerned Application Servers interested in subsystem status 
   changes. The SUA management function is informed with the N-State 
   indication primitive upon which it formats and transfers the 
   applicable SNM message to the list of concerned ASPs using stream ID 
   "0". 
    
   When MTP-3 Management indications are received (MTP-PAUSE, MTP-
   RESUME, MTP-STATUS), SCCP Subsystem Management determines whether 
   there are concerned local SCCP-users. When these local SCCP-users 
   are in fact Application Servers, serviced by ASPs, SUA management is 
   informed with the PC-State indication primitive upon which it 
   formats and transfers the applicable SNM message (DUNA, DAVA, DRST 
   or SCON) to the list of concerned ASPs using stream ID "0".   
    
   If an ASP receives a DUNA, DRST or SCON from a SGP, the SUA layer at 
   the ASP is expected to send traffic to the affected destination via 
   an alternate SGP of equal priority, but only if such an alternate 
   route exists and is available. The local ASP SHOULD maintain the 
   status of the possible routes to the peer endpoint in the SS7 
   network.  By maintaining the status of the possible routes, the ASP 
   can determine if the remote peer is unavailable. 
    
   When the DAUD message is received at the SGP from an ASP, the SGP 
   checks the status of the specified SS7 destination and returns DAVA, 
   DUNA, DRST or SCON depending on the result of the check. The SGP 
   initiates SST (Subsystem Status Test) procedures by following the 
   SCCP procedures described in Q.714; the receipt of a DAUD message 
   does not trigger these. 
    
 
Loughney (editor)                                           [Page 66] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   SCCP Subsystem Management procedures may also be triggered in case 
   of AS state changes, see chapter 4.4.1.2. 
    
4.2 Primitives received from the local SUA-user 
    
   These support the SUA transport of SCCP-User/SCCP boundary 
   primitives. The same services as supported by SCCP (connectionless 
   and connection-oriented) are to be provided by SUA. The SCCP-users 
   at the SGP should be able to use the same primitive interface to 
   SCCP/SUA without any changes. The SCCP-SUA interworking function 
   takes care of selecting the appropriate stack. 
    
   The SUA needs to setup and maintain the appropriate SCTP association 
   to the selected endpoint. SUA also manages the usage of SCTP 
   streams. 
    
   The address information passed by the SUA-user at an ASP MUST 
   contain either: 
    
     -    A valid SS7 address to reach a destination in the SS7 network 
          via the appropriate SCTP association to a SG. 
     -    A valid IP address/hostname to reach another ASP in the IP 
          network via the appropriate SCTP association. 
    
4.3 Layer Management Procedures  
    
   On receiving primitives from the local Layer Management, the SUA 
   layer will take the requested action and provide a response to Layer 
   Management. 
    
   An M-SCTP-ESTABLISH request from Layer Management will initiate the 
   establishment of an SCTP association. An M-SCTP-ESTABLISH confirm 
   will be sent to Layer Management when the initiated association set-
   up is complete. An M-SCTP-ESTABLISH indication is sent upon 
   successful completion of an incoming SCTP association set-up from a 
   peer SUA node. 
    
   An M-SCTP-RELEASE request from Layer Management initiates the 
   teardown of an SCTP association. An M-SCTP-RELEASE confirm is sent 
   to Layer Management when the association teardown is complete. An M-
   SCTP-RELEASE indication is sent to Layer Management upon successful 
   teardown of an SCTP association initiated by a peer SUA. 
    
   An M-SCTP-STATUS request supports a Layer Management query of the 
   local status of a particular SCTP association. The SUA responds with 
   the association status in an M-SCTP-STATUS confirm. No peer SUA 
   protocol is invoked. 
    
   An M-ASP-STATUS request supports a Layer Management query of the 
   status of a particular local or remote ASP. The SUA responds with an 
   M-ASP-STATUS confirm. No peer SUA protocol is invoked. 
 
Loughney (editor)                                           [Page 67] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   An M-AS-STATUS request supports a Layer Management query of the 
   status of a particular AS. The SUA responds with an M-AS-STATUS 
   confirm. No peer SUA protocol is invoked. 
    
   M-ASP-UP, -DOWN, -ACTIVE and ûINACTIVE request primitives allow 
   Layer Management at an IPSP to force state changes. Upon successful 
   completion, a corresponding confirm primitive is issued by SUA to 
   the Layer Management. If the invocation is unsuccessful, an Error 
   indication is provided. 
    
   SUA Management informs layer Management about AS/ASP state changes 
   with the corresponding indications. It is also informed of received 
   NTFY or ERR messages, see chapter 4.4.3. 
    
4.4 SUA Management Procedures 
    
   This functionality comprises the handling of AS/ASP state and 
   traffic management messages, SUA peer management messages, SCTP 
   notifications and the interface with local Layer Management. 
   These procedures support the SUA management of SCTP Associations and 
   ASP paths between SGs and ASPs. 
    
4.4.1 AS and ASP State and Traffic Management 
    
   The SUA layer on each IPSP (e.g. SG) needs to maintain the state of 
   each connected IPSP (e.g. ASP), as a way to manage the traffic to 
   these IPSPs and the (logical) ASs they service.  In particular at a 
   SG, the state of each connected ASP is needed as input to the SGs 
   routing function. 
    
4.4.1.1 ASP States 
    
   The state of each ASP is maintained in the SUA layer at the 
   controlling AS. The state of an ASP changes due to events. The 
   events include: 
    
     -    ASP Management messages (ASP-Up, ASP-Down, ASP-Active, ASP-
          Inactive). 
     -    SCTP Communication Down Notification (SCTP CDI). 
    
   The state of the ASP within each AS is important in particular for 
   the routing function at the SG, to direct traffic for a specific 
   routing key (AS) to the appropriate ASP. 
    
   At an ASP, if it is connected to a set of redundant SGs, this set 
   can also be seen as an AS handling all traffic destined for the SS7 
   network. 
    
   The ASP state transition diagram is shown in Figure 4. The possible  
   states of an ASP are: 
 
Loughney (editor)                                           [Page 68] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
   ASP-DOWN: The Application Server Process is unavailable. Initially 
   all ASPs will be in this state. 
    
   ASP-UP: The Application Server Process is available but application 
   traffic is not possible. The ASP can only handle management 
   messages. 
    
   ASP-ACTIVE: The Application Server Process is available and 
   application traffic is possible. Whether traffic will be directed to 
   this ASP depends on the Traffic Mode Type (over-ride, loadshare with 
   or without Standby option). 
                                   +-------------+ 
                                   | ASP-ACTIVE  | 
            +----------------------|     or      |       
            |               +------| ASP-STANDBY*| 
            |         AS    |      +-------------+  
            |      Override |          ^     |  
            |               |   ASP    |     | ASP      
            |               |   Active |     | Inactive 
            |               |          |     v            
            |               |      +-------------+  
            |               +------|             |               
            |                      | ASP-INACTIVE| 
            |                      +-------------+ 
            |                          ^    | 
   ASP Down |                     ASP  |    | ASP Down / 
   SCTP CDI |                     Up   |    | SCTP CDI 
            |                          |    v 
            |                      +-------------+ 
            |                      |             | 
            +--------------------->|  ASP-DOWN   | 
                                   |             | 
                                   +-------------+ 
    
   * Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is 
   currently receiving Data traffic within the AS. 
    
                  Figure 4: ASP State Transition Diagram 
    
   SCTP CDI: The local SCTP layer's SHUTDOWN COMPLETE notification or 
   COMMUNICATION LOST notification. The shutdown of an SCTP association 
   may have been requested by local Layer Management, see chapter 4.3. 
    
   Local Layer Management  
    
4.4.1.2 AS States 
    
   The AS is configured in the IPSP as a logical entity to handle 
   traffic for a specific (unique) routing key. The state of the AS is 
   maintained in the SUA layer, and can change due to following events: 
 
Loughney (editor)                                           [Page 69] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
     -    ASP state changes: when the first ASP within an AS goes UP or 
          ACTIVE, or when the last ASP within an AS goes DOWN or 
          INACTIVE 
     -    Recovery Timer expiry 
    
   The possible states of an AS are: 
    
   AS-DOWN: The Application Server is unavailable.  This state implies 
   that all related ASPs are in the ASP-DOWN state for this AS. 
   Initially the AS will be in this state. 
    
   AS-UP: The Application Server is available but no application 
   traffic is possible (i.e. one or more related ASPs are in the ASP-UP 
   state, but none in the ASP-ACTIVE state). 
    
   AS-ACTIVE: The Application Server is available and application 
   traffic is possible. This state implies that at least one ASP is in 
   the ASP-ACTIVE state. 
    
   AS-PENDING: An active ASP has transitioned from active to inactive 
   or down and it was the last remaining active ASP in the AS. A 
   recovery timer T(r) will be started and all incoming SCN messages 
   will be queued by the SG. If an ASP becomes active before T(r) 
   expires, the AS will move to AS-ACTIVE state and all the queued 
   messages will be sent to the active ASP.  
    
   If T(r) expires before an ASP becomes active, the SGP stops queuing 
   messages and discards all previously queued messages. The AS will 
   move to AS-UP if at least one ASP is in ASP-UP state, otherwise it 
   will move to AS-DOWN state. 
    

 
Loughney (editor)                                           [Page 70] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
         +----------+ one ASP trans to ASP-ACTIVE +-------------+  
         |          |---------------------------->|             |      
         |  AS-UP   |                             |  AS-ACTIVE  |  
         |          |<---                         |             |  
         +----------+    \                        +-------------+  
            ^   |         \ Tr Expiry,                ^    |  
            |   |          \ at least one             |    |  
            |   |           \ ASP in ASP-INACTIVE     |    |  
            |   |            \                        |    |  
            |   |             \                       |    |  
            |   |              \                      |    |  
    one ASP |   | all ASP       \            one ASP  |    | Last ACT. 
    trans   |   | trans to       \           trans to |    | ASP trans  
    to ASP- |   | ASP-DOWN        -------\  ASP-ACTIVE|    | to ASP-  
    INACTIVE|   |                         \           |    | INACTIVE  
            |   |                          \          |    | or ASP- 
            |   |                           \         |    | DOWN 
            |   |                            \        |    |  
            |   v                             \       |    v         
         +----------+                          \  +-------------+  
         |          |                           --|             |      
         | AS-DOWN  |                             | AS-PENDING  |  
         |          |                             |  (queuing)  |  
         |          |<----------------------------|             |  
         +----------+       Tr Expiry no ASP      +-------------+  
                            in ASP-INACTIVEstate  
    
    
         Tr = Recovery Timer 
                                       
                    Figure 5: AS State Transition Diagram 
    
   The SGP maintains the availability of the ASs, and will need to 
   issue the correct SCCP management message (where applicable) to the 
   SS7 node(s). 
    
   When an AS transitions to the UP or DOWN state, and it is the only 
   (or last) one handling traffic for a certain SSN, an SSP message is 
   broadcast to the concerned remote SCCP-users in the SS7 network. 
    
   When an AS transitions to the ACTIVE state, and it is the first one 
   handling traffic for a certain SSN, an SSA message is broadcast to 
   the concerned remote SCCP-users in the SS7 network. 
 
4.4.2 AS/ASP Management procedures 
    
   Once an SCTP association is established between two IPSPs, one (or 
   both) side(s) might issue an ASP-UP message.  
    
4.4.2.1 ASP-Up 
    
 
Loughney (editor)                                           [Page 71] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   An ASP sends an ASP-UP to each communication partner.  When the ASP-
   UP message is received, the receiving IPSP can react in three 
   different ways: 
    
     -    Mark the remote ASP Inactive and reply with an ASP-UP Ack 
          message in acknowledgement to every received ASP-UP, even if 
          the ASP is already marked as Inactive. 
     -    If for any local reason (e.g. management lock-out) the IPSP 
          cannot respond with an ASP-UP Ack, it responds with an ASP-
          DOWN Ack message. 
     -    If an unknown version is received with the ASP-UP message, 
          the receiving end MUST respond with an Error message with 
          Error Code ôInvalid Versionö. The version field in the common 
          header will indicate to the sender which version(s) the 
          receiving node supports. This is useful when protocol version 
          upgrades are being performed. A node with the newer version 
          should support the older versions as well to fallback upon in 
          a subsequent ASP-UP message. 
    
   If the ASP does not receive any of the above reactions, the ASP may 
   resend ASP-Up messages until it receives a response. The ASP MUST 
   wait for the ASP-UP Ack message before sending any other messages. 
   If the remote peer receives any other SUA messages from an ASP, 
   before an ASP-UP is received and acknowledged, the message should be 
   discarded. 
    
   If the ASP Up message contains an ASP Identifier, the SGP should 
   save the ASP Identifier for that ASP, to be used in any Notify 
   messages, which are sent indicating a change in the state of the 
   ASP. 
    
4.4.2.2 ASP-Down 
    
   The IPSP will mark an ASP as down if one of the following events 
   occur: 
    
        - An ASP Down (DOWN) message is received from the ASP. 
        - The ASP is locked by local Layer Management. 
    
   The IPSP sends an ASP DOWN Ack message in response to a received 
   ASP-DOWN message from the ASP even if the ASP is already marked as 
   Down. 
    
   The IPSP will send an ASP DOWN message whenever it wants to take 
   down an ASP. Since it is possible for ASP DOWN and ASP DOWN Ack 
   messages to be lost (for example, during a node failover), the IPSP 
   can send ASP DOWN messages repeatedly until the path comes down 
   (i.e. until it receives a ASP-DOWN message from the remote peer or 
   the SCTP association goes down). 
    

 
Loughney (editor)                                           [Page 72] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
4.4.2.3 ASP-Active 
    
   When an ASP is ready to start processing traffic, it sends an ASP-
   ACTIVE message to the remote peer. When an ASP-ACTIVE message is 
   received, the remote peer responds with an ASP-ACTIVE Ack. The ASP 
   cannot send any other messages until after the ASP-ACTIVE Ack is 
   received. If the ASP-ACTIVE Ack is not received within a certain 
   time, the ASP may resend the ASP-ACTIVE message. 
    
   The ASP-ACTIVE message optionally contains a list of one or more 
   Routing Contexts, indicating which Application Servers the ASP is 
   joining. If no Routing Contexts are present, then local 
   configuration data is used to determine to which Application 
   Server(s) the ASP belongs. 
    
   The Traffic Mode Type parameter in the ASP-ACTIVE message indicates 
   the traffic handling mode used in a particular Application Server, 
   either Over-ride, Over-ride (Standby), Load-share or Load-share 
   (Standby). If the remote peer determines that the mode indicated in 
   an ASP-ACTIVE is incompatible with the mode currently used in the 
   AS, the remote peer responds with an Error message indicating 
   "Invalid Traffic Handling Mode". 
    
   In the Over-ride mode, reception of an ASP-ACTIVE message at a 
   remote peer causes the all traffic for the AS to be sent to the ASP 
   that sent the ASP-ACTIVE. All previously active ASPs in the AS are 
   now considered Inactive and will no longer receive traffic for that 
   particular AS.  The remote peer sends a Notify (Alternate ASP-
   Active) to the previously active ASP in the AS, after stopping all 
   traffic to that ASP. All existing connections/transactions with the 
   previously active ASP should be terminated however. 
    
   In the Over-ride (Standby) mode, the actions are the same with the 
   exception that the traffic is not started to the ASP until the 
   previously active ASP transitions to the "Inactive or "Down" state. 
   At this point the ASP that sent the Over-Ride (Standby) ASP-ACTIVE 
   message takes over the traffic. No Notify messages are needed. 
    
   In the Load-share mode, reception of an ASP-ACTIVE message causes 
   the redistribution of traffic to the ASP sending the ASP-ACTIVE, in 
   addition to all the other ASPs that are currently active in the AS.  
   The algorithm at the SGP for load-sharing traffic within an AS to 
   all the active ASPs is implementation dependent. All ASPs marked for 
   load sharing should be able to handle any traffic within the AS, to 
   accommodate any potential fail-over or re-balancing of the offered 
   load. 
    
   In the Load-share (Standby) mode, the actions are the same as the 
   Load-share mode, with the exception that the traffic is not started 
   to the ASP until the remote peer determines that additional 
   resources are needed to service the AS. When needed, the ASP that 
 
Loughney (editor)                                           [Page 73] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   sent the Loadshare (Standby) ASP-ACTIVE message is taken up in the 
   loadsharing scheme and traffic is started. No Notify messages are 
   needed to be sent. 
    
   A node that receives an ASP-ACTIVE with an incorrect Traffic Mode 
   Type for a particular Routing Context will respond with an Error 
   Message with Error Cause ôInvalid Traffic Handling Modeö. A node 
   that receives an unknown Routing Context value responds with an 
   Error message with Error Cause ôInvalid Routing Contextö. 
    
4.4.2.4 ASP-Inactive 
    
   When an ASP wishes to withdraw from handling traffic, it sends an 
   ASP-INACTIVE to the applicable remote peers, specifying the AS 
   (Routing Context) from which it is withdrawing. If the ASP is 
   withdrawing from more than one AS, then the ASP issues either 
   multiple ASP-INACTIVE messages, if multiple SCTP associations exist 
   to the remote ASPs; or a single ASP-INACTIVE message containing 
   multiple Routing Contexts. 
    
   The ASP could have been in one of two modes, Over-ride or Load-
   sharing.  In the Over-ride mode, the ASP that sent the ASP-INACTIVE 
   is marked as Inactive. No further traffic is sent from and to the 
   ASP marked Inactive.  The remote peer now should notify the 
   remaining ASPs of situation. 
     
   In the Load-sharing mode, the peer marks the ASP as Inactive and re-
   allocates the traffic to the remaining active ASPs. The load-sharing 
   mechanism used is outside of the scope of SUA. If there are 
   insufficient resources, a NTFY (Insufficient ASPs) may be sent to 
   all inactive ASPs within the AS.  If a Loadshare (Standby) ASP is 
   available, it may be now immediately included in the loadshare group 
   and a Notify message MUST not be sent.  An ASP-INACTIVE Ack message 
   is sent to the ASP after all traffic is halted. 
    
   In the case when no other ASPs are active or standby in the 
   Application Server, the remote peer should send a NTFY (AS-Pending) 
   to all inactive ASPs of the AS. The remote peer then either discards 
   all incoming messages for the AS or starts buffering the incoming 
   messages for T(r) seconds, after which messages will be discarded.  
   T(r) is configurable by the network operator.   
    
   If the remote peer receives an ASP-ACTIVE from an ASP in the AS 
   before expiry of T(r), the buffered traffic is directed to the ASP 
   and the timer is cancelled.  If T(r) expires, the AS is moved to the 
   "Down" state. 
    
4.4.3 SUA peer management messages 
    
4.4.3.1 Notify 
    
 
Loughney (editor)                                           [Page 74] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   A NTFY message reflecting a change in the AS state MUST be sent to 
   all ASPs in the AS, except those in the ASP-DOWN state, with 
   appropriate Status Type/ID and ASP Identifier of the failed ASP.  
   The Notify message MUST be sent after any ASP State or Traffic 
   Management acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, 
   ASP Active Ack, or ASP Inactive Ack). 
    
   In the case where a NTFY (AS-Pending) message is sent by an SGP that 
   now has no active ASPs to service the traffic, or a NTFY 
   (Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not 
   explicitly force the ASP(s) receiving the message to become active. 
   The ASPs remain in control of what (and when) action is taken. 
 
4.4.3.2 Error 
    
   The ERR message is used to signal invalid protocol behavior. 
    
4.4.4 Heartbeat procedure 
    
   The optional Heartbeat message may be sent to query the status of 
   the remote peer.  It is optional to send, but mandatory to 
   acknowledge.  It MAY be used when operating over transport layers 
   that do not have their own heartbeat mechanism for detecting loss of 
   the transport association (i.e., other than SCTP).   
    
   After an ASP or IPSP has received an ASP Up Ack from an SUA peer in 
   response to an ASP Up message, either M3UA peer MAY optionally send 
   Heartbeat messages periodically, subject to a provisionable timer 
   T(beat).  Upon receiving a Heartbeat message, the SUA peer MUST 
   respond with a Heartbeat ACK message.  
    
   If no Heartbeat Ack message (or any other SUA message) is received 
   from the peer within 2*T(beat), the remote peer is considered 
   unavailable.  Transmission of Heartbeat messages is stopped and the
   signaling process SHOULD attempt to re-establish communication, if 
   it is configured as the client for the disconnected M3UA peer. 
    
   The data field can be used to store information in the heartbeat 
   message useful to the sending node (e.g. the data field can contain 
   a time stamp, a sequence number, etc.).  The data field MUST be 
   echoed back unchanged in the related Heartbeat Ack message. The 
   contents/format of the Heartbeat Data parameter is implementation-
   dependent and only of local interest to the original sender. The ASP 
   sender, upon examining the contents of the returned Heartbeat Ack 
   message, MAY choose to consider the remote M3UA peer as unavailable. 
    
   Note: Heartbeat related events are not shown in the "ASP state 
   transition diagram".  
    

 
Loughney (editor)                                           [Page 75] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
5 Examples of SUA Procedures 
 
   The following sequence charts overview the procedures of SUA.  These 
   are meant as examples, they do not, in and of themselves, impose 
   additional requirements upon an instance of SUA. 
    
5.1 SG Architecture 
 
   The sequences below outline logical steps for a variety of scenarios 
   within a SG architecture.  Please note that these scenarios cover a 
   Primary/Backup configuration.  Where there is a load-sharing 
   configuration then the SGP can declare availability when 1 ASP 
   issues ASPAC but can only declare unavailability when all ASPs have 
   issued ASPIA. 
    
5.1.1 Establishment of SUA connectivity 
 
   The following is established before SUA/SCCP traffic can flow. 
    
   Each node is configured (via MIB, for example) with the connections 
   that need to be setup. 
    
    
        ASP-a1            ASP-a2                SG                  SEP 
       (Primary)           (Backup)                                       
          |------Establish SCTP Association------| 
                             |--Estab. SCTP Ass--| 
                                                 |--Align SS7 link---| 
                
               Each ASP declares to the SGP that it is running. 
                
          +----------------ASP Up----------------> 
          <--------------ASP Up Ack--------------+ 
                             +------ASP Up-------> 
                             <---ASP Up Ack------+ 
    
               The Primary ASP declares to the SGP that it is active. 
               The SGP notifies all ASPs. 
                
          +-------------ASP Active---------------> 
          <----------ASP Active Ack--------------+ 
          <----------NTFY (ASP Active)-----------+ 
                             <-NTFY (ASP Active)-+ 
                
               The SGP declares the availability of the signaling  
               user on ASP-a1 to the SEP.  The SGP has been  
               configured (via a MIB) that the SEP is concerned 
               about its signaling users.  The SGs SS7 address 
               is presented in the SSA, i.e. the SGP represents the 
               availability of ASP-a1 to the SEP.   
                
 
Loughney (editor)                                           [Page 76] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
                                                 +--------SSA--------> 
    
               The SEP declares its availability to the SGP since 
               the SGP appears within its concerned list.  Similarly, 
               the SGP informs the active ASP of the availability of 
               the SEP as dictated by SGs concerned list.  N.B. 
               The SGP maps the SS7 address of the SEP to an 
               IP address that the SGP knows ASP-a1 will understand. 
                
                                                 <--------SSA--------+ 
          <-----------------DAVA-----------------+ 
    
               Traffic can now flow.  A connectionless flow is shown 
               for simplicity.  Nevertheless, the SGP is responsible 
               for mapping IP to SS7 addresses and vice-versa.  Only 
               the Routing Context for ASP-a1 persists from ASP-a1 to  
               SEP. 
                
          +-----------------CLDT-----------------> 
                                                 +--------UDT--------> 
    
5.1.2 Failover scenarios 
    
   The following sequences address failover of SEP and ASP 
    
5.1.2.1 SEP Failover 
    
   The SEP knows that the SGP is 'concerned' about its availability.  
   Similarly, the SGP knows that ASP-a1 is concerned about the SEPs 
   availability; therefore the incoming SSP is translated into DUNA.  
   ASP-a1 uses a DAUD to instruct the SGP to invoke the SS7 Sub-system 
   Test procedure. 
    
        ASP-a1            ASP-a2                SG                  SEP 
      (Primary)           (Backup)                                       
                                                 <--------SSP--------+ 
          <-----------------DUNA-----------------+ 
          +-----------------DAUD-----------------> 
                                                 +--------SST--------> 
 
5.1.2.2 Successful ASP Failover scenario 
    
   The following is an example of a successful failover scenario, where 
   there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.  
   During the failover, the SGP buffers any incoming data messages from 
   the SEP, forwarding them when the Backup becomes available. 
    

 
Loughney (editor)                                           [Page 77] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
        ASP-a1            ASP-a2                SG                  SEP 
      (Primary)           (Backup)                                       
          +-------------ASP Inactive-------------> 
          <----------NTFY (ASP Inactive)---------+ 
                             <-NTFY (ASP Inact.)-+ 
                             +----ASP Active-----> 
                             <--ASP Active Ack---+ 
                             <-NTFY (ASP Active)-+ 
          <----------NTFY (ASP Active)-----------+ 
    
5.1.2.3 Unsuccessful ASP Failover scenario 
 
        ASP-a1            ASP-a2                SG                  SEP 
      (Primary)           (Backup)                                       
          +-------------ASP Inactive-------------> 
          <----------NTFY (ASP Inactive)---------+ 
                             <-NTFY (ASP Inact.)-+ 
    
                After some time elapses (i.e. timeout). 
    
                                                 +--------SSP--------> 
                                                 <--------SST--------+ 
                                                  
5.2 IP-IP Architecture 
 
   The sequences below outline logical steps for a variety of scenarios 
   within an IP-IP architecture.  Please note that these scenarios 
   cover a Primary/Backup configuration.  Where there is a load-sharing 
   configuration then the AS can declare availability when 1 ASP issues 
   ASPAC but can only declare unavailability when all ASPs have issued 
   ASPIA. 
    
5.2.1 Establishment of SUA connectivity 
    
   The following shows an example establishment of SUA connectivity.  
   In this example, each IPSP consists of an Application Server and two 
   ASPs.  
    
   The following is established before SUA traffic can flow. A 
   connectionless flow is shown for simplicity. 
    
   Each node is configured (via MIB, for example) with the connections 
   that need to be setup. 
    

 
Loughney (editor)                                           [Page 78] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   IP SEP A                                                  IP SEP B 
   AS A                                                          AS B 
   ASP-a1     ASP-a2                                 ASP-b2    ASP-b1 
   (Primary) (Backup)                               (Backup) (Primary) 
    
                       [Establish SCTP Connectivity] 
    
   |------------- Establish SCTP Association -------------|  
   |------------------ Establish SCTP Association ------------------| 
    
              |------- Establish SCTP Association --------|  
              |------------ Establish SCTP Association -------------|  
                  
                       [Establish SUA Connectivity] 
    
   +----------------------ASP Up--------------------------> 
   <--------------------ASP Up Ack------------------------+ 
    
   +---------------------------ASP Up-------------------------------> 
   <-------------------------ASP Up Ack-----------------------------+ 
    
              <----------------ASP Up---------------------+ 
              +----------------ASP Up Ack-----------------> 
    
              +------------------------ASP Up-----------------------> 
              <----------------------ASP Up Ack---------------------+ 
    
   +---------------------------ACTIVE-------------------------------> 
   <-------------------------ACTIVE Ack-----------------------------+ 
    
               [Traffic can now flow directly between ASPs] 
    
   +-----------------------------CLDT-------------------------------> 
    
    
5.2.2 Failover scenarios 
    
   The following sequences address failover of ASP 

5.2.2.1 Successful ASP Failover scenario 
    
   The following is an example of a successful failover scenario, where 
   there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.  
   Since data transfer passes directly between peer ASPs, ASP-b1 is 
   notified of the failover of ASP-a1 and buffers outgoing data 
   messages until ASP-a2 becomes available. 
    

 
Loughney (editor)                                           [Page 79] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   IP SEP A                                                  IP SEP B 
   ASP-a1     ASP-a2                                 ASP-b2    ASP-b1 
   (Primary) (Backup)                               (Backup) (Primary) 
    
   +-----------------------------ASP Inact------------------------> 
   <---------------------------ASP Inact Ack----------------------+ 
    
              <---------------NTFY (ASP-a1 Inactive)--------------+ 
    
              +---------------------ASP Act-----------------------> 
              <-------------------ASP Act Ack---------------------+ 

5.2.2.2 Unsuccessful ASP Failover scenario 
    
   The sequence is the same as 4.2.2.1 except that, since the backup 
   fails to come in then, the Notify messages declaring the 
   availability of the backup are not sent. 
    
6 Security 
    
6.1 Introduction 
    
   SUA is designed to carry signaling messages for telephony services. 
   As such, SUA involves the security needs of several parties: the end 
   users of the services; the network providers and the applications 
   involved.  Additional security requirements may come from local 
   regulation.  While having some overlapping security needs, any 
   security solution should fulfill all of the different parties' 
   needs.  
 
6.2 Threats 
    
   There is no quick fix, one-size-fits-all solution for security.  As 
   a transport protocol, SUA has the following security objectives: 
    
    * Availability of reliable and timely user data transport. 
    * Integrity of user data transport. 
    * Confidentiality of user data. 
    
   SUA runs on top of SCTP.  SCTP provides certain transport related 
   security features, such as: 
    
    * Blind Denial of Service Attacks 
    * Flooding 
    * Masquerade 
    * Improper Monopolization of Services 
    
   When SUA is running in professionally managed corporate or service 
   provider network, it is reasonable to expect that this network 

 
Loughney (editor)                                           [Page 80] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   includes an appropriate security policy framework. The "Site 
   Security Handbook" [2196] should be consulted for guidance. 
    
   When the network in which SUA runs in involves more than one party, 
   it may not be reasonable to expect that all parties have implemented 
   security in a sufficient manner. End-to-end security should be the 
   goal; therefore, it is recommended that IPSEC is used to ensure 
   confidentiality of user payload.  Consult [2409] for more 
   information on configuring IPSEC services. 
    
6.3 Protecting Confidentiality  
    
   Particularly for mobile users, the requirement for confidentiality 
   may include the masking of IP addresses and ports.  In this case 
   application level encryption is not sufficient; IPSEC ESP should be 
   used instead. Regardless of which level performs the encryption, the 
   IPSEC ISAKMP service should be used for key management. 
    
7 IANA Considerations 
 
7.1 SCTP Payload Protocol ID 
    
   IANA has assigned a SUA value for the Payload Protocol Identifier in 
   the SCTP DATA chunk.  The following SCTP Payload Protocol Identifier 
   is registered: 
    
           SUA    "4" 
    
   The SCTP Payload Protocol Identifier value "4" SHOULD be included in 
   each SCTP DATA chunk, to indicate that the SCTP is carrying the SUA 
   protocol. The value "0" (unspecified) is also allowed but any other 
   values MUST not be used.  This Payload Protocol Identifier is not 
   directly used by SCTP but MAY be used by certain network entities to 
   identify the type of information being carried in a DATA chunk. 
    
   The User Adaptation peer MAY use the Payload Protocol Identifier as 
   a way of determining additional information about the data being 
   presented to it by SCTP.A request will be made to IANA to assign CTP 
   Payload Protocol IDs.   
    
7.2 Port Number 
    
   IANA has registered SCTP Port Number 14001 for SUA.  This port 
   number is the port that the SGPs listen to when receiving SCTP 
   datagrams.   
    
7.3 Protocol Extensions 
    
   This protocol may also be extended through IANA in three ways: 
    
    - Through definition of additional message classes. 
 
Loughney (editor)                                           [Page 81] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    - Through definition of additional message types. 
    - Through definition of additional message parameters. 
    
   The definition and use of new message classes, types and parameters 
   is an integral part of SIGTRAN adaptation layers.  Thus, these 
   extensions are assigned by IANA through an IETF Consensus action as 
   defined in [RFC2434]. 
    
   The proposed extension MUST in no way adversely affect the general 
   working of the protocol. 
    
7.3.1 IETF Defined Message Classes 
    
   The documentation for a new message class MUST include the following 
   information: 
   (a) A long and short name for the message class; 
   (b) A detailed description of the purpose of the message class. 
    
7.3.2 IETF Defined Message Types 
    
   Documentation of the message type MUST contain the following 
   information: 
    
   (a) A long and short name for the new message type; 
   (b) A detailed description of the structure of the message. 
   (c) A detailed definition and description of intended use of each 
      field within the message. 
   (d) A detailed procedural description of the use of the new message 
      type within the operation of the protocol. 
   (e) A detailed description of error conditions when receiving this 
      message type. 
    
   When an implementation receives a message type which it does not 
   support, it MUST respond with an Error (ERR) message, with an Error 
   Code = Unsupported Message Type. 
    
7.3.4 IETF-defined TLV Parameter Extension 
    
   Documentation of the message parameter MUST contain the following 
   information: 
    
   (a) Name of the parameter type. 
   (b) Detailed description of the structure of the parameter field.  
       This structure MUST conform to the general type-length-value  
       format described earlier in the document. 
   (c) Detailed definition of each component of the parameter value. 
   (d) Detailed description of the intended use of this parameter type, 
       and an indication of whether and under what circumstances 
       multiple instances of this parameter type may be found within  
       the same message type. 
    
 
Loughney (editor)                                           [Page 82] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
8 Timer Values 
    
     Ta                                      2 seconds 
     Tr                                      2 seconds 
     T(ack)                                  2 seconds 
     T(ias)    Inactivity Send timer         7 minutes 
     T(iar)    Inactivity Receive timer      15 minutes 
     T(beat)   Heartbeat Timer               30 seconds 
    
9 Acknowledgements 
    
   The authors would like to thank Brian Bidulock, Martin Booyens, 
   Klaus Gradischnig, Miguel A. Garcia, Marja-Liisa Hamalainen, Sherry 
   Karl, Markus Maanoja, Chirayu Patel, Michael Purcell, Michael 
   Tuexen, Al Varney, Ben Wilson, Michael Wright and James Yu for their 
   insightful comments and suggestions. 
    
   Funding for the RFC editor function is currently provided by the 
   Internet Society. 
    
10 Authors' Addresses 
    
   John Loughney 
   Nokia Research Center 
   PO Box 407 
   FIN-00045 Nokia Group 
   Finland 
   EMail: john.loughney@nokia.com 
    
   Greg Sidebottom 
   Kanata, Ontario 
   Canada 
   EMail: gregside@home.com 
    
   Guy Mousseau 
   Nortel Networks 
   3685 Richmond Rd 
   Nepean, Ontario,  
   Canada K2H 5B7 
    
   Stephen Lorusso 
   Unisphere Networks 
   10 Technology Park Drive 
   Westford, MA  01886 
   USA 
   Phone: +1 (978) 589-0533 
   EMail: SLorusso@UnisphereNetworks.com 
    
   Lode Coene 
   Siemens Atea 
   Atealaan 34 
 
Loughney (editor)                                           [Page 83] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   B-2200 Herentals 
   Belgium 
   Phone: +32-14-252081 
   EMail: lode.coene@siemens.atea.be 
    
   Gery Verwimp 
   Siemens Atea 
   34 Atealaan 
   PO 2200 
   Herentals 
   Belgium 
   Phone: +32 14 25 3424 
   EMail: gery.verwimp@siemens.atea.be 
    
   Joe Keller 
   Tekelec 
   5200 Paramount Parkway 
   Morrisville, NC 27560 
   USA 
   EMail: joe.keller@tekelec.com 
    
   Florencio Escobar Gonzalez 
   Ericsson Spain S.A. 
   Retama 7, 2nd floor 
   28045, Madrid 
   Spain 
   EMail: florencio.escobar@ericsson.com 
    
   Steven Furniss 
   Marconi 
   New Century Park 
   Coventry CV3 1HJ 
   United Kingdom 
   EMail: steven.furniss@marconi.com 
    
   William Sully 
   Marconi 
   New Century Park 
   Coventry CV3 1HJ 
   United Kingdom 
   EMail: william.sully@marconi.com 
    
11 References 
    
   [2196]         RFC 2196, "Site Security Handbook", B. Fraser Ed., 
                  September 1997. 
    
   [2396]         Berners-Lee, T., Fielding, R.T. and L. Masinter, 
                  "Uniform Resource Identifiers (URI): Generic Syntax", 
                  RFC 2396, August 1998. 
    
 
Loughney (editor)                                           [Page 84] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
   [2401]         RFC 2401, "Security Architecture for the Internet 
                  Protocol", S. Kent, R. Atkinson, November 1998. 
    
   [2434]         RFC 2434 "Guidelines for Writing an IANA 
                  Considerations Section in RFCs", T. Narten, H. 
                  Alvestrand, October 1998. 
    
   [2719]         RFC 2719, "Framework Architecture for Signaling 
                  Transport" 
    
   [ANSI-MTP]     ANSI T1.111 'Signaling System Number 7 - Message 
                  Transfer Part' 
    
   [ANSI SCCP]    ANSI T1.112 'Signaling System Number 7 - Signaling 
                  Connection Control Part' 
    
   [ANSI TCAP]    ANSI T1.114 'Signaling System Number 7 - Transaction 
                  Capabilities Application Part' 
    
   [ENUM]         RFC 2916 "E.164 number and DNS", P. Faltstrom, 
                  September 2000. 
    
   [IDNS]         Blanchet, M., Hoffman, P., "Internationalized domain 
                  names using EDNS (IDNE)", <draft-ietf-idn-idne-
                  01.txt>, Work in progress, July 2000 
    
   [ITU-MTP]      ITU-T Recommendations Q.701-Q.705, 'Signalling System 
                  No. 7 (SS7) - Message Transfer Part (MTP)' 
    
   [ITU SCCP]     ITU-T Recommendations Q.711-714, 'Signaling System 
                  No. 7 (SS7) - Signaling Connection Control Part 
                  (SCCP)' 
    
   [ITU TCAP]     ITU-T Recommendation Q.771-775 'Signaling System No. 
                  7 SS7) - Transaction Capabilities (TCAP) 
    
   [M3UA]         MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
                  06.txt>, March 2001, Work in Progress. 
    
   [RANAP]        3G TS 25.413 V3.5.0 (2001-03) 'Technical 
                  Specification 3rd Generation Partnership Project; 
                  Technical Specification Group Radio Access Network; 
                  UTRAN Iu Interface RANAP Signalling' 
    
   [SCTP]         RFC 2960 "Stream Control Transport Protocol" R. 
                  Stewart, et al, November 2000. 
    
   [UTRAN IUR]    3G TS 25.422 V3.5.0 (2000-12) "Technical 
                  Specification 3rd Generation Partnership Project; 
                  Technical Specification Group Radio Access Network; 

 
Loughney (editor)                                           [Page 85] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
                  UTRAN Iur Interface Signaling Transport (Release 
                  1999)" 

 
Loughney (editor)                                           [Page 86] 
 
 
Internet Draft       SS7 SCCP-User Adaptation Layer      July 20, 2001 
 
 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 

 
Loughney (editor)                                           [Page 87] 
 



Last modified: Thu, 13 Nov 2014 05:15:02 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.