INTERNET-DRAFT J. Loughney Internet Engineering Task Force Nokia G. Sidebottom, Guy Mousseau Issued: 4 October 2000 Nortel Networks Expires: 4 May 2001 S. Lorusso Unisphere Solutions SS7 SCCP-User Adaptation Layer (SUA) 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 4 May 2001 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 2, 2000 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 ...............................9 1.5 Internal Functions Provided in the SUA Layer ....................10 1.6 Definition of SUA Boundaries ....................................11 2 Protocol Elements...................................................11 2.1 Common Message Header ...........................................12 2.2 SUA Connectionless Messages .....................................13 2.3 Connection Oriented Messages ....................................15 2.4 SS7 Signaling Network Management Messages .......................21 2.5 Application Server Process Maintenance Messages .................24 2.6 ASP Traffic Maintenance Messages ................................26 2.7 Management Messages .............................................29 2.8 Common Parameters ...............................................31 2.9 SUA-Specific parameters .........................................35 3 Procedures..........................................................42 3.1 Peer Message Procedures .........................................42 3.2 Signaling Gateway Related Procedures ............................42 3.3 Layer Management Procedures .....................................43 3.4 SCTP Management Procedures ......................................43 4 Examples of SUA Procedures..........................................48 4.1 Establishment of Association ....................................48 4.2 ASP fail-over Procedures ........................................49 4.3 SUA/SCCP-User Boundary Examples .................................49 5 Security............................................................49 5.1 Introduction ....................................................49 5.2 Threats .........................................................49 5.3 Protecting Confidentiality ......................................50 6 IANA Considerations.................................................50 6.1 SCTP Payload Protocol ID ........................................50 6.2 Port Number .....................................................50 7 Timer Values........................................................50 8 Acknowledgements....................................................50 9 Authors' Addresses..................................................51 10 References.........................................................51 Appendix A: Message mapping between SCCP and SUA......................52 Appendix B: SCTP to SUA Message Mapping Examples......................53 Copyright Statement...................................................53 Loughney, et al. [Page 2] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 1. Introduction 1.1 Scope There is on-going integration of SCN networks and IP networks. Network service providers are designing all IP architectures which 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 SHOULD meet the following criteria: * Support for transfer of SS7 SCCP-User Part messages (e.g., 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. Deepending upon the upper layer protocol supported, the SUA will need to support SCCP connectionless service, SCCP connect-orient 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 Application Servers, which is 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 an IP database handling all request for a unique set of SCCP-users. 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 standby 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. Loughney, et al. [Page 3] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 Association - An association refers to an SCTP association. The association provides the transport for the delivery of SCCP-User protocol data units and SUA adaptation layer peer messages. Routing Key - The Routing Key describes a set of SS7 parameter 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 PC and SSN to 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. A Routing Key cannot extend across more than a single SS7 PC, in order to more easily support SS7 Management procedures. It is not necessary for the parameter ranges within a particular Routing Key to be contiguous. 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 two ASPs, identifying the relevant Application Server. From the perspective of an 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. 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-back may apply upon the return to service of a previously unavailable Application Server Process. Signaling Point Management Cluster (SPMC) - A complete set of Application Servers represented to the SS7 network under the same SS7 Point Code. SPMCs are used to sum the availability / congestion / User_Part status of an SS7 destination point code that is distributed in the IP domain, for the purpose of supporting management procedures at an SG. Network Appearance - The Network Appearance identifies an SS7 network context for the purposes of logically separating the signaling traffic between the SG and the Application Server Processes over a common SCTP Association. An example is where an SG is logically partitioned to appear as an element in four separate national SS7 networks. A Network Appearance implicitly defines the SS7 Point Code(s), Network Indicator and SCCP protocol type/variant/version used within a specific SS7 network partition. An physical SS7 route- set or link-set at an SG can appear in only one network appearance. The Network Appearance is not globally significant and requires coordination only between the SG and the ASP. Network Byte Order - Most significant byte first, a.k.a. Big Endian. Layer Management - Layer Management is a nodal function in an SG or ASP that handles the inputs and outputs between the SUA layer and a local management entity. Loughney, et al. [Page 4] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 Host - The computing platform that the 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 which 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. 1.3.1 Protocol Architecture for TCAP 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. The SUA handles the SS7 address to IP address mapping. ******** SS7 *************** IP ******** * SEP *---------* *--------* * * or * * SG * * ASP * * STP * * * * * ******** *************** ******** +------+ +------+ | TCAP | | TCAP | +------+ +------+------+ +------+ | SCCP | | SCCP | SUA | | SUA | +------+ +------+------+ +------+ | MTP3 | | MTP3 | | | | +------| +------+ SCTP | | SCTP | | MTP2 | | MTP2 | | | | +------+ +------+------+ +------+ | L1 | | L1 | IP | | IP | +------+ +------+------+ +------+ | | | | +---------------+ +------------+ TCAP - Transaction Capability Application Protocol STP - SS7 Signaling Transfer Point Loughney, et al. [Page 5] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 1.3.2 Protocol Architecture for RANAP Transport In this architecture, the SS7 application protocol is invoked at the SG. For messages destined for an ASP, the SUA handles address translation, for example by way of Global Title Translation or via mapping table, resolving the destination specified by SS7 Application to a SCTP association / IP address. ******** SS7 *************** IP ******** * SEP *---------* *--------* * * or * * SG * * ASP * * STP * * * * * ******** *************** ******** +------+ +-------------+ +------+ | S7AP | | S7AP | | S7AP | +------+ +------+------+ +------+ | SCCP | | SCCP | SUA | | SUA | +------+ +------+------+ +------+ | MTP3 | | MTP3 | | | | +------| +------+ SCTP | | SCTP | | MTP2 | | MTP2 | | | | +------+ +------+------+ +------+ | L1 | | L1 | IP | | IP | +------+ +------+------+ +------+ | | | | +---------------+ +------------+ S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP) STP - SS7 Signaling Transfer Point This architecture may simplify, in some cases, to carrying an SS7 application protocol between two IP based endpoints. In this scenario, full SG functionality may not be needed. This architecture is considered in the next section. 1.3.3 All IP Architecture This architecture can be used to carry a protocol which 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 ******** * *--------* * * AS * * AS * * * * * ******** ******** +------+ +------+ | AP | | AP | +------+ +------+ | SUA | | SUA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ Loughney, et al. [Page 6] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 | | +----------------+ AP - 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 Point-to-Point Network Architecture Figure 1 shows an example network architecture which can support robust operation and failover support. There needs to be some management resources at the AS to manage traffic. *********** * 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. Loughney, et al. [Page 7] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 1.3.5 Generalized Signaling Gateway Network Architecture When interworking between SS7 and IP domains is needed, the SG acts as the gateway node between the SS7 network and the IP network. The SG 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. 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. Figure 2 shows a possible realization of this architecture, with Signaling Gateway functionality. Signaling Gateway **************** * +----------+ * ************** * | AS1 | * * AS3 * * | ******** | * * ******** * * | * ASP1 +---------------------------------------------+ ASP1 * * * | ******** | * * ******** * * | ******** | * * ******** * * | * ASP2 +--------------------------+ +----------+ ASP2 * * * | ******** | * | | * ******** * * +----------+ * | | * . * * +----------+ * | | * . * * | AS2 | * | | * . * * | ******** | * | | * ******** * * | * ASP1 +----------------------------------+ * * ASPN * * * | ******** | * SCTP Associations | * ******** * * | ******** | * | ************** * | * ASP2 +---------------- | * | ******** | * | | ************** * +----------+ * | | * AS4 * **************** | | * ******** * | +------------------+ ASP1 * * | * ******** * | * . * | * . * | * * | * ******** * +-----------------------------+ ASPn * * * ******** * ************** Figure 2: Signaling Gateway Architecture 1.3.6 ASP Fail-over Model and Terminology The SUA protocol supports ASP fail-over functions in order 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 Loughney, et al. [Page 8] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 ASPs in the list may normally be active to handle traffic, while others may while any others are inactive but available in the event of failure or unavailability of the active ASP(s). The fail-over model supports an "n+k" redundancy model, where "n" ASPs is the minimum number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. Note that "1+1" active/standby redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no ASP redundancy. To avoid a single point of failure, it is recommended that a minimum of two ASPs be resident in the list, resident in separate physical hosts and therefore available over different SCTP Associations. 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. 1.4.3 Native Management Functions The SUA layer may provide management of the underlying SCTP layer to ensure that transport is available according to the degree specified by the SCCP-user application. 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 Loughney, et al. [Page 9] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The SUA layer needs to support the following SCCP network management functions: Coord Request Coord Indication Coord Response Coord Confirm State Request State Indication Pcstate Indication 1.4.5 Support for the management between the SG 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 remote SS7 endpoint/peer is unreachable. * Provide an indication to the SCCP-user at an ASP that a remote SS7 endpoint/peer is reachable. * Provide congestion indication to SCCP-user at an ASP. * Provide the initiation of an audit of remote SS7 endpoints at the SG. 1.5 Internal Functions Provided in the SUA Layer 1.5.1 Address Translation and Mapping at the SG SCCP users may present the following options to address their peer endpoints: Global Title PC + SSN Host Name IP Address(es) Global Titles are an interesting option for addressing. Currently, the ITU does not support translation of Global Titles to IP addresses. However, IP addresses are global in scope. There exist many proprietary schemes for managing SS7 Address Translation to IP addresses, and is considered outside of the scope of this document to specify how this is done. Some discussion of address translation should be made to insure interoperability between implementations of the SUA. For further instruction in the use of Global Titles the rules detailed in Annex B of ITU Q.713 [ITU SCCP] or [ANSI SCCP] should be consulted. That being said, currently, there is some work within the IETF studying translation of E.164 numbers to Host Names [ENUMS], [E.164- DNS]. In many cases, the network operator may have some control over the SCCP-user protocols being transported by SUA. If possible, the Upper Layer can present a Host Name or IP Address, which then can be directly passed to SCTP. Loughney, et al. [Page 10] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 An example of address translation at the SG would be that the CDPA is extracted from the SCCP Header, processed by the SUA routing function which yields a SA. The SA is fed back into extended SUA routing analysis which yields the ASP to route the message to. This is why the Source Address and Destination address-routing should be performed based on the CDPA. 1.5.2 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. SUA MUST use stream 0 for SUA management messages. It is recommended that sequenced delivery be in order to preserve the order of management message delivery. 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. Unit Data Request Unit Data Indication Notice Indication Connect Request Connect Indication Connect Responding Connect Confirm Data Request Data Indication Expedited Data Request Expedited Data Indication Disconnect Request Disconnect Indication Reset Request Reset Indication Reset Response Reset Confirm 1.6.2 Definition of the lower boundary The upper layer primitives provided by the SCTP are provided in [SCTP]. 2 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. Loughney, et al. [Page 11] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 For forward compatibility, all Message Types may have attached parameters even if none are specified in this version. 2.1 Common Message Header The protocol messages for the SCCP-User Adaptation Protocol requires a message structure which contains a version, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg 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. 2.1.1 SUA Protocol Version The version field (ver) contains the version of the SUA adaptation layer. The supported versions are: 01 SUA version 1.0 2.1.2 Message Classes Message Classes 0 Management (MGMT) Message 1 Reserved 2 SS7 Signaling Network Management (SSNM) Messages 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 5 Reserved 6 Reserved 7 Connectionless Messages 9 Connection-Oriented Messages 8 - 255 Reserved 2.1.3 Message Types SUA Management Messages 0 Error (ERR) 1 Audit (AUD) 2 Notify (NTFY) 3 - 255 Reserved SS7 Signaling Network Management (SSNM) Messages 0 Reserved Loughney, et al. [Page 12] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 1 Destination Unavailable (DUNA) 2 Destination Available (DAVA) 3 Destination State Audit (DAUD) 4 Destination User Part Unavailable (DUPU) 5 SCCP Management (SCMG) 6 - 255 Reserved for SSNM Messages Application Server Process Maintenance (ASPM) Messages 0 Reserved 1 ASP Up (UP) 2 ASP Down (DOWN) 3 Heartbeat (HEARTBEAT) 4 ASP Up Ack (UP ACK) 5 ASP Down Ack (Down ACK) 6 - 255 Reserved for ASPSM Messages ASP Traffic Maintenance (ASPTM) Messages 0 Reserved 1 ASP Active (ACTIVE) 2 ASP Inactive (INACTIVE) 3 ASP Active Ack (ACTIVE ACK) 4 ASP Inactive Ack (INACTIVE ACK) 5 to 255 Reserved for ASPTM Messages Connectionless Messages 0 Reserved 1 Connectionless Data Transfer (CLDT) 2 Connectionless Data Response (CLDR) 3 - 255 Reserved 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 - 255 reserved 2.1.4 Message Length The Message Length defines the length of the message in octets, including the header. 2.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 Loughney, et al. [Page 13] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 parameters as defined by the Message Type. All Message Types can have attached parameters. 2.2.1 Connectionless Data Transfer 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 = 0x0105 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0102 | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Source Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0103 | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / destination address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Flags Mandatory Source Address Mandatory Destination Address Mandatory Data Mandatory Implementation note: This message covers the following SCCP messages: unitdata (UDT), extended unitdata (XUDT), long unitdata (LUDT). 2.2.2 Connectionless Data Response This message is used as a response message by the peer and/or report errors. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0104 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCCP Error Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0102 | Length | Loughney, et al. [Page 14] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Source Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0103 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / destination address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed Lengths Parameters Flags Mandatory Return Cause Mandatory Source Address Mandatory Destination Address Mandatory Data Optional Implementation note: This message covers the following SCCP messages: long unitdata service (LUDTS), unitdata service (UDTS), extended unitdata service (XUDTS). 2.3 Connection Oriented Messages 2.3.1 Connection Oriented Data Transfer 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0105 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0101 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Data Mandatory Loughney, et al. [Page 15] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 Flags Mandatory *1 Sequence number Mandatory *2 NOTE *1: Mandatory for representing DT1 message. NOTE *2: Mandatory for protocol class 3; Optional for protocol class 2. Implementation note: This message covers the following SCCP messages: data form 1 (DT1), data form 2 (DT2), expedited data (ED). 2.3.2 Connection Oriented Data Acknowledge This message is used to acknowledge receipt of data by the 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0101 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Sequence number Mandatory *1 NOTE *1: Mandatory for protocol class 3; Optional for protocol class 2. Implementation note: This message covers the following SCCP messages: data acknowledgement (AK), expedited data acknowledgement (EA). 2.3.3 Connect Request This message is used for establishing a signaling connection between two peer endpoints. This is used 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 = 0x0105 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0103 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 16] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 / Destination Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0102 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Source Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010C | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Flags Mandatory Source Reference Number Mandatory Destination Address Mandatory Source Address Optional Credit Optional Data Optional 2.3.4 Connection Acknowledge This message is used to acknowledge 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0105 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010C | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0103 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Destination Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Data / \ \ Loughney, et al. [Page 17] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Source Reference Number Mandatory Flags Optional Credit Optional Destination Address Optional *1 Credit Optional 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 confirm (CC). 2.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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCCP Error Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0103 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Destination Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0101 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory SCCP Error 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. Loughney, et al. [Page 18] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 2.3.5 Release Request 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0104 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0105 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Source Reference Number Mandatory Return Cause Mandatory Flags Optional Data Optional Implementation Note: This message covers the following SCCP message: connection refused (CREF). 2.3.6 Release Complete 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source reference number | Loughney, et al. [Page 19] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Source Reference Number Mandatory 2.3.7 Reset Request This message is used to indicate that the sending SCCP/SUA wants to initiate a reset procedure (re-initialization of sequence numbers) 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0109 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCCP Error Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Source Reference Number Mandatory SCCP Error Cause Mandatory 2.3.8 Reset Confirm 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory Source Reference Number Mandatory 2.3.9 Connection Oriented Error (COERR) The COERR message is sent when an invalid value is found in an incoming message. 0 1 2 3 Loughney, et al. [Page 20] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0109 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCCP Error | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Destination Reference Number Mandatory SCCP Error Mandatory Implementation Note: This message covers the following SCCP message: Protocol data unit error (ERR) 2.4 SS7 Signaling Network Management Messages 2.4.1 Destination Unavailable The DUNA message is sent from the SG to all concerned ASPs to indicate that the SG has determined that an SS7 destination is unreachable. The SUA-User at the ASP is expected to stop traffic to the affected destination through the SG 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0001 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Affected Point Code Mandatory Network Appearance Optional Info String Optional 2.4.2 Destination Available The DAVA message is sent from the SG to all concerned ASPs to indicate that the SG has determined that an SS7 destination is now reachable. The ASP SUA-User protocol is expected to resume traffic to the affected destination through the SG initiating the DUNA. Loughney, et al. [Page 21] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0005 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Affected Point Code Mandatory Network Appearance Optional Info String Optional 2.4.3 Destination State Audit The DAUD message can be sent from the ASP to the SG to query the availability state of the SS7 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 SG. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0001 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Affected Point Code Mandatory Network Appearance Optional Info String Optional 2.4.4 Destination User Part Unavailable The DUPU message is used by an SG to inform an ASP that a remote peer MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. Loughney, et al. [Page 22] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The format for DUPU 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0005 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0001 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Cause Mandatory Affected Point Code Mandatory Note *1 Network Appearance Optional Info String Optional The Cause Code parameter indicates the reason that the remote SUA adaptation layer is unavailable. The valid values for Cause are as follows: Value Description 0 Unknown 1 Unequipped Remote User 2 Inaccessible Remote User Note *1: Affected Point Code can only contain a single affected point code. 2.4.5 SCCP Management Message The SCMG message is sent from the between SUA Peers to indicate status of subsystems. Only one SCMG message type can be sent per 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 = 0x010D | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCMG Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x010E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI | Subsystem | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 23] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 | Tag = 0x0005 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected PC / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0108 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | congestion level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / INFO String \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters SCMG Message Type Mandatory Subsystem/SMI Mandatory Affected Point Code Mandatory *1 Congestion Level Mandatory *2 Info String Optional Note *1: In the SCMG message, the Affected Point Code Parameter MUST contain, at most, a single Affected Point Code. Note *2: When the SCMG Message Type is SSC, then the Congestion Level parameter is Mandatory, otherwise it is optional. 2.5 Application Server Process Maintenance Messages 2.5.1 ASP Up (ASPUP) The ASP UP (ASPUP) message is used to indicate to a remote SUA peer that the Adaptation layer is ready to receive traffic or maintenance messages. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0002 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ALI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters ASP Capabilities Mandatory Adaptation Layer Identifier Optional Info String Optional Loughney, et al. [Page 24] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 2.5.2 ASP Up Ack (UPACK) 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 = 0x010A | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0002 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ALI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters ASP Capabilities Mandatory Adaptation Layer Identifier Optional Info String Optional 2.5.3 ASP Down (ASPDN) The ASP Down (ASPDN) message is used to indicate to a remote SUA peer that the adaptation layer is not ready to receive traffic or maintenance messages. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Cause Code Mandatory Info String Optional The Cause Code parameter indicates the reason that the remote SUA adaptation layer is unavailable. The valid values for Reason are shown in the following table. Value Description 0x1 Processor Outage 0x2 Management Inhibit Implementation note: Loughney, et al. [Page 25] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 This message covers the following SCCP message: subsystem-prohibited (SSP). 2.5.4 ASP Down Ack (DNACK) 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 = 0x0002 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ALI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Adaptation Layer Identifier Optional Info String Optional 2.5.5 Heartbeat (BEAT) The Heartbeat message is optionally used to ensure that the SUA peers are still available to each other. It is recommended for use when the SUA runs over a transport layer other than the SCTP, which has its own heartbeat. The BEAT message contains no parameters. 2.6 ASP Traffic Maintenance Messages 2.6.1 ASP Active (ASPAC) 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 ASPAC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 26] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The ASPAC message contains the following parameters: Type Mandatory Routing Context Optional INFO String Optional Type: 32-bit (unsigned integer) The Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table. 1 Over-ride 2 Load-share Within a particular Routing Context, only one Type can be used. The Over-ride value indicates that the ASP is operating in Over-ride mode, where the ASP takes over all traffic in an Application Server (i.e., primary/back-up operation), over-riding any currently active ASP in the AS. In Load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs. A node that receives an ASPAC with an incorrect Type for a particular Routing Context will respond with an Error Message (Cause: Invalid Traffic Handling Mode. 2.6.2 ASP Active Ack The ASPAC Ack message is used to acknowledge an ASP-Active message received from a remote SUA peer. The format for the ASPAC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ASPAC Ack message contains the following parameters: Type Mandatory Routing Context Optional INFO String Optional Type: 32-bit (unsigned integer) Loughney, et al. [Page 27] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table. 1 Over-ride 2 Load-share The type field in the ASPAC Ack message should contain the type as the ASPAC message to which the message is acknowledging. 2.6.3 ASP Inactive (ASPIA) The ASPIA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ASPIA message contains the following parameters: Type Mandatory Routing Context Optional INFO String Optional The Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table. Value Description 0x1 Over-ride 0x2 Load-share Within a particular Routing Context, only one Type can be used. The Override value indicates that the ASP is operating in Over-ride mode, and will no longer handle traffic within an Application Server (i.e., it is now a backup in a primary/back-up arrangement). The Load-share value indicates that the ASP is operating in Load-share mode and will no longer share in the traffic distribution with any other currently active ASPs. A node that receives an ASPIA with an incorrect Type for a particular Routing Context will respond with an Error Message (Cause: Invalid Traffic Handling Mode. Loughney, et al. [Page 28] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 2.6.4 ASP Inactive Ack The ASPIA Ack message is used to acknowledge an ASP-Inactive message received from a remote SUA peer. The format for the ASPIA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Type Mandatory Routing Context Optional INFO String Optional The Type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for Type are shown in the following table. 1 Over-ride 2 Load-share The type field in the Ack message should contain the type as the ASPIA message to which the message is acknowledging. 2.7 Management Messages These messages are used for managing SUA and the representations of the SCCP subsystems in the SUA layer. 2.7.1 Error (ERR) The ERR message is sent between two SUA peers to indicate an error situation. The Data parameter is option, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / data / Loughney, et al. [Page 29] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Cause Mandatory Data Optional The Cause parameter can be one of the following values: Invalid Version 0x1 Invalid Network Appearance 0x2 Invalid Adaptation Layer Identifier 0x3 Invalid Message Type 0x4 Invalid Traffic Handling Mode 0x5 Unexpected Message Type 0x6 Protocol Error 0x7 2.7.2 Audit This message is used to audit the current state of 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 = 0x0005 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0001 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Affected Point Code Mandatory Network Appearance Optional Info String Optional 2.7.3 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 = 0x010B | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / Loughney, et al. [Page 30] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / info string / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The NTFY message contains the following parameters: Parameters Status Type Mandatory Routing Context Optional Info String Optional 2.8 Common Parameters These TLV parameters are common across the different adaptation layers. Parameter Name Parameter ID ============== ============ Network Appearance 0x0001 Application Layer Identifier 0x0002 Data 0x0003 Info String 0x0004 Affected Point Code 0x0005 Routing Context 0x0006 Diagnostic Info 0x0007 2.8.1 Network Appearance The Network Appearance parameter identifies the SS7 network context for the message, for the purposes of logically separating the signaling traffic between the SG and the Application Server Processes over common SCTP Associations. An example is where an SG is logically partitioned to appear as an element in four different national SS7 networks. A Network Appearance implicitly defines the SS7 Destination Point Code used, the SS7 Network Indicator value and SCCP/SCCP-User protocol type/variant/version used within the SS7 network partition. Where an SG operates in the context of a single SS7 network, or individual SCTP associations are dedicated to each SS7 network appearance, the Network Appearance parameter is not required. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | network appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In an SSNM message, the Network Appearance parameter defines the format of the Affected PC(s) in the Affected Destination parameter. The PC point code length (e.g., 14-, 16-, or 24-bit) and sub-field definitions (e.g., ANSI 24-bit network/cluster/member, ITU- international 14-bit zone/region/signal_point, many national field variants, ...) are fixed within a particular Network Appearance. Loughney, et al. [Page 31] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 Where an SG operates in the context of a single SS7 network, or individual SCTP associations are dedicated to each SS7 network context, the Network Appearance parameter is not required and the format of the Affected PC(s) is understood implicitly. The format of the Network Appearance parameter is an integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP. Where the optional Network Appearance parameter is present, it must be the first parameter in the message as it defines the format of the Affected PCs in the Affected Destination parameter. 2.8.2 Adaptation Layer Identifier 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 = 0x0002 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ALI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The optional Adaptation Layer Identifier (ALI) is a string that identifies the adaptation layer. This string MUST be set to "SUA" which results in a length of 3. The ALI would normally only be used in the initial ASP Up message across a new SCTP association to ensure both peers are assuming the same adaptation layer protocol. 2.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 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.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 the INFO String may be used by Operators 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, et al. [Page 32] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 2.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 4- , 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 Pointe 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 Network Appearance. Including multiple Affected PCs may be useful when reception of an management message or a linkset event simultaneously affects the availability status of a list of destinations at an SG. Mask: 8-bits The Mask parameter is 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. Loughney, et al. [Page 33] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 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 is significant and which are effectively "wildcarded". For example, a mask of "8" indicates that the last eight bits of the PC is "wildcarded". 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 "wildcarded". For a 14-bit ITU Affected PC, this is equivalent to signaling that an ITU Region is unavailable. 2.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type parameter identifies the message as an Over-ride or Load- share Active message. The valid values for Type are shown in the following table. Value Description 0x1 Over-ride 0x2 Load-share Within a particular Routing Context, only one Type can be used. The optional Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is configured to receive. There is one-to-one relationship between an index entry and an AS Name. Because an AS can only appear in one Network Appearance, the Network Appearance parameter is not required in the ASPAC message 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. 2.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 Invalid Network Appearance, 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 Loughney, et al. [Page 34] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0007 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Diagnostic Information* / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.9 SUA-Specific parameters These TLV parameters are specific to the SUA protocol. Parameter Name Parameter ID ============== ============ Sequence Number 0x0101 Source Address 0x0102 Destination Address 0x0103 Return Cause 0x0104 Flags 0x0105 Source Reference Number 0x0106 Destination Reference Number 0x0107 Congestion Level 0x0108 SCCP Error 0x0009 ASP Capabilities 0x000A Status 0x000B Credit 0x000C SCMG Message Type 0x000D SMI / Subsystem 0x000E 2.9.1 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 = 0x0101 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This parameter is mapped from the SCCP Sequencing/segmenting parameter. It is used exclusively for protocol class 3. It is used to number each DT message sequentially for the purpose of flow control. 2.9.2 Source Address (=CLG) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Source Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of Address field is used to aid in the identification of the type of address. If this field is set to 0, then the address field needs to be analyzed. Loughney, et al. [Page 35] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 Type of Address Unknown/Undeterminable 0x00000000 SS7 SCCP CLG 0x00000001 Host Name 0x00000002 IPv4 Address 0x00000003 IPv6 Address 0x00000004 The combinations of SS7 addressing schemes (ITU, ANSI, etc). supported is implementation dependant. The Source Address field can contain the SCCP Calling Party Address. It is possible to simply encapsulate the information, as presented by the upper layer. 2.9.3 Destination Address (=CLD) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / destination address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of Address field is used to aid in the identification of the type of address. If this field is set to 0, then the address field needs to be analyzed. Type of Address Unknown/Undeterminable 0x00000000 SS7 SCCP CLD 0x00000001 Host Name 0x00000002 IPv4 Address 0x00000003 IPv6 Address 0x00000004 Note: the combinations of SS7 addressing schemes(ITU, ANSI, etc). supported is implementation dependant. The Destination Address field can contain the SCCP Called Party Address. It is possible to simply encapsulate the information, as presented by the upper layer. 2.9.4 Return Cause The Return Cause corresponds to the return cause of the SCCP 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 = 0x0104 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 36] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The Length is a one octet unsigned integer. Possible values for the Return Cause are: 0x01 no translation for an address of such nature 0x02 no translation for this specific address 0x03 subsystem congestion 0x04 subsystem failure 0x05 unequipped user 0x06 MTP failure 0x07 network congestion 0x08 unqualified 0x09 error in message transport (Note) 0x0A error in local processing (Note) 0x0B destination cannot perform reassembly (Note) 0x0C SCCP failure 0x0D hop counter violation 0x0E segmentation not supported 0x0F segmentation failure NOTE: Only applicable to XUDT(S) message. 2.9.5 Flags 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Counter | segmenting |D| B |A| C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Error Return option Value Description 0x0 No error message 0x1 Return message on error B Protocol class Value Description 0x0 Class 0 (connectionless service) 0x1 Class 1 (connectionless service) 0x2 Class 2 (connection-oriented service) 0x3 Class 3 (connection-oriented service C Importance Value Description 0x0 Least important : 0x7 Highest importance D Segmentation Value Description 0x0 No segmentation 0x1 Segmentation Segmenting field corresponds to the SCCP Segmenting parameter. Loughney, et al. [Page 37] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+ | segmenting | +-+-+-+-+-+-+-+-+-+ Bit 8 is coded as the following: _ 0: in all segments but the first; _ 1: first segment. Bit 7 is used to keep in the message in sequence delivery option required by the SCCP user and is coded as follows: _ 0: Class 0 selected; _ 1: Class 1 selected. Bits 6 and 5 are spare bits. Bits 4-1 of octet 1 are used to indicate the number of remaining segments. The values 0000 to 1111 are possible; the value 0000 indicates the last segment. Hop Counter Value Description 0x0 : 0x15 Maximum number of GTT 0x16 - 0x255 Spare 2.9.6 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 = 0x0106 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The source reference number is a 3 octet long integer, which is generated by the local source to identify a connection. Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved for future use. 2.9.7 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 = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination reference number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 38] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 The Destination Reference Number is a 3 octet long integer, which is generated by the destination node to identify a connection. Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved for future use. 2.9.8 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 = 0x0108 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | congestion level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length is one octet. The valid values for the Congestion Level parameter range from 0 to 7, where 0 indicates least congested and 7 indicates most congested. 2.9.9 SCCP 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 = 0x0109 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | spare | Cause Type | Cause Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 error value. Below gives examples for ITU SCCP values. Cause value in Correspondence with Reference SUA message SCCP parameter ------------------ ----------------- --------- CLDA Return Cause ITU-T Q.713 Chapter 3.12 COREF Refusal Cause ITU-T Q.713 Chapter 3.15 RELRE Release Cause ITU-T Q.713 Chapter 3.11 RESRE Reset Cause ITU-T Q.713 Chapter 3.13 ERR Error Cause ITU-T Q.713 Chapter 3.14 2.9.10 ASP Capabilities This parameter is used so that the ASP can report it's capabilities 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney, et al. [Page 39] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 | Tag = 0x010A | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCCP Variant |0 0 0 0|a|b|c|d| interworking | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length is two octets. SCCP Variant field can contain the following values: Unidentified/unknown 0x0 ITU-I SCCP 0x1 ITU-N SCCP 0x2 ANSI SCCP 0x3 Japanese SCCP 0x4 Chinese SCCP 0x5 Other 0x6 Flags a - Protocol Class 3 b - Protocol Class 2 c - Protocol Class 1 d - Protocol Class 0 0 indicates no support for the Protocol Class. Interworking Values 0x0 indicates no interworking with SS7 Networks. 0x1 indicates IP Signaling Endpoint. 0x2 indicates Signaling Gateway. 2.9.11 Status The Status Type parameter identifies the type of the status that is being notified. 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 = 0x010B | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Type | Status ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values are shown in the following table. 1 Application Server state change (AS_State_Change) 2 Other The Status Id parameter identifies the status that is being notified. The valid values are shown in the following table. If the Status Type is AS_STATE_CHANGE If the Status Type is AS_State_Change the following Status Information values are used: Loughney, et al. [Page 40] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 1 Application Server Down (AS_Down) 2 Application Server Up (AS_Up) 3 Application Server Active (AS_Active) 4 Application Server Pending (AS_Pending) 5 Alternate ASP Active 6 Insufficient ASPs If the Status Type is Other, then the following Status Information values are defined: 1 Insufficient ASP resources active in AS This notification is not based on the SG reporting the state change of an ASP or AS. For the value defined the SG is indicating to an ASP(s) in the AS that another ASP is required in order to handle the load of the AS. 2.9.12 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 = 0x010C | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length is one octet. 2.9.13 SCMG Message Type 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 = 0x010D | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCMG Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SCMG Message Type field may have the following values: 0 Reserved 1 SSA 2 SSP 3 SST 4 SOR 5 SOG 6 SSC 7 - 252 Reserved 253 SNR 254 SBR 255 SRT 2.9.14 SMI / Subsystem Loughney, et al. [Page 41] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 3 Procedures 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 SCU procedures in response to these events. 3.1 Peer Message Procedures On receiving a message, the SUA layer performs address translation and mapping (if needed), to determine the appropriate Application Server Process (ASP). 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. 3.1.1 Connection Oriented Timers The SUA layer needs to start a timer after sending a CR, RLSD or RSR message. Add more text. 3.2 Signaling Gateway Related Procedures These support the SUA transport of SCCP-User/SCCP boundary primitives. On receiving a SCCP message at the SG, the SUA layer performs address translation and mapping, to determine the appropriate Application Server Process (ASP). The appropriate ASP can be determined based on the 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. The SUA needs to setup and maintain the appropriate SCTP association to the selected endpoint. SUA also manages the usage SCTP streams. 3.2.1 MTP 3 - SUA interaction The Signaling Gateway will need to manage the availability of the ASPs within the IP network; while reporting the status of endpoints Loughney, et al. [Page 42] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 in the SS7 network. Therefore, there will be interworking between the MTP 3 layer and SUA. MTP 3 indication messages (MTP Pause, MTP resume, MPT Status) need to be indicated to the peer SUA layer. MTP_PAUSE, MTP_STATUS (UPU) and SSP should be mapped on DUNA messages. It is possible that several ASPs must be informed via DUNA, depending on the ASs affected. MTP_RESUME and SSA should be mapped on DAVA messages to the affected ASPs. MTP_STATUS (Congestion) and SSC should be mapped on SCON messages to the affected ASPs. SST should be mapped on DAUD message to the affected ASPs. 3.3 Layer Management Procedures The SUA layer needs to send and receive layer management messages. 3.4 SCTP Management Procedures These procedures support the SUA management of SCTP Associations and ASP Paths between SGs and ASPs. 3.4.1 State Management The SUA layer on at each AS needs to maintain the state of each ASP under its control, as a way to manage the state and connections of the local ASPs. At a SG, the state of each ASP is needed as input to the SGs address translation and mapping function. 3.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: * Reception of messages from that ASP's SUA layer * Reception of messages from a different ASP's SUA layer * Reception of indications from the SCTP layer * Switch over timer triggers The ASP state transition diagram is shown in Figure 4. The possible states of an ASP are: 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 stopped. ASP-ACTIVE: The Application Server Process is available and application traffic is active. Figure 4: ASP State Transition Diagram Loughney, et al. [Page 43] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +-------------+ | | +----------------------| ASP-ACTIVE | | Alternate +-------| |<------------+ | ASP | +-------------+ | | Takeover | ^ | | | | ASP | | ASP | | | Active | | Inactive | ASP | | | v |Takeover | | +-------------+ | | | | |-------------+ | +------>| ASP-UP |-------------+ | +-------------+ | | ^ | | ASP Down | ASP | | ASP Down / | ASP SCTP Down| Up | | SCTP Down | Down/ | | v | SCTP | +-------------+ | Down | | | | +--------------------->| ASP-DOWN |<------------+ | | +-------------+ Figure 4: ASP State Transition Diagram SCTP Down: The local SCTP layer's SHUTDOWN COMPLETE notification or COMMUNICATION LOST notification. 3.4.1.2 AS States The state of the AS is maintained in the SUA layer. The state of an AS changes due to events. These events include: * ASP state transitions * Recovery timer triggers 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 active (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 active. This state implies that 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. Loughney, et al. [Page 44] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 If T(r) expires before an ASP becomes active, the SG 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, et al. [Page 45] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 +----------+ one ASP trans to ACTIVE +-------------+ | |---------------------------->| | | AS-UP | | AS-ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ ASP in UP | | | | \ | | | | \ | | | | \ | | one ASP | | all ASP \ one ASP | | Last ACTIVE trans | | trans to \ trans to | | asp trans to UP | | DOWN -------\ ACTIVE | | to UP or | | \ | | DOWN | | \ | | | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<----------------------------| | +----------+ Tr Expiry no ASP +-------------+ in UP state Tr = Recovery Timer Figure 5: AS State Transition Diagram 3.4.2 ASPM procedures for primitives Before the establishment of an SCTP association the ASP state at both the AS and ASP is assumed to be "Down". When the SUA layer receives an M-SCTP ESTABLISH request primitive from the Layer Management, the SUA layer will try to establish an SCTP association with the remote SUA peer. Upon reception of an eventual SCTP-Communication Up confirm primitive from the SCTP, the SUA layer will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. Alternatively, if the remote SUA-peer establishes the SCTP association first, the SUA layer will receive an SCTP Communication Up indication primitive from the SCTP. The SUA layer will then invoke the primitive M-SCTP ESTABLISH indication to the Layer Management. Once the SCTP association is established, The SUA layer at an ASP will then find out the state of its local SUA-user from the Layer Management using the primitive M-ASP STATUS. Based on the status of the local SUA-User, the local ASP SUA Application Server Process Maintenance (ASPM) function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. Loughney, et al. [Page 46] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 If the SUA layer subsequently receives an SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP STATUS indication primitive. The state of the ASP will be moved to "Down." At an ASP, the Layer Management may try to reestablish the SCTP association using M-SCTP ESTABLISH request primitive. 3.4.3 ASPM procedures for peer-to-peer messages 3.4.3.1 ASP-Up The AS will mark the path as up if an explicit ASP UP (ASPUP) message is received and internally the path is allowed to come up (i.e., not in a locked local maintenance state). An ASP UP (ASPUP) message will be sent to acknowledge the received ASPUP. The SG will respond to a ASPUP with a ASPDN message if the path is in a locked maintenance state. The receiving ASP will send a ASPUP message in response to a received ASPUP message from the ASP even if that path was already marked as UP. The paths are controlled by the ASP. The ASP will send ASPUP messages every t(a) seconds until the path comes up (i.e. until it receives a ASPUP message from the remote peer for that path). The ASP may decide to reduce the frequency (say to every 5 seconds) if the an acknowledgement is not received after a few tries. The ASP should wait for the ASPUP message from the remote peer before transmitting ASP maintenance messages (ASPIA or ASPAC) or SUA messages or it will risk message loss. 3.4.3.2 ASP Down The AS will mark the ASP as down and send a ASPDN message to the ASP if one of the following events occur: - an ASP Down(ASPDN) message is received from the ASP, - the ASP is locked by local maintenance. The AS will also send a ASPDN message when the ASP is already down and a ASPDN) message is received from the ASP. The ASP will send ASPDN whenever it wants to take down a ASP. Since it is possible for ASPDN messages and responses can be lost (for example, during a node failover), the ASP can send ASPDN messages every t(a) seconds until the path comes down (i.e. until it receives a ASPDN message from the remote peer for that path). 3.4.3.3 ASP Version Control If a ASP Up message with an unknown version is received, the receiving end will respond with an Error message. This will indicate to the sender which version the receiving node supports. Loughney, et al. [Page 47] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 This is useful when protocol version upgrades are being performed. A node with the newer version should support the older versions used on other nodes it is communicating with. The version field in the Error message header associated will indicate the version supported by the node. 3.4.3.4 ASP Active When an ASP Active (ASPAC) message is received, the ASP will start traffic routing to that ASP. Reception of a ASPAC message overrides any previous ASPAC messages and results in the ASP associated with the ASPAC message to become the newly active ASP. 3.4.3.5 ASP Inactive When a ASPIA message is received, message transmission to that ASP ceases. The ASP will either discard all incoming messages or start buffering the incoming messages for T(r)seconds after which messages will be discarded. If the ASP is down, all of the Paths that were supported by that ASP are, by default, down. 4 Examples of SUA Procedures 4.1 Establishment of Association 4.1.1 SG Architecture SG ASP1 ASP2 (Primary) (Backup) | | | <----ASP Up--------+ | +----ASP Up Ack ---> | | | | <-----------------------ASP Up---------+ +-----------------------ASP Up (Ack)---> | | | <----ASP Active----+ | +-ASP Active Ack---> | | | | 4.1.2 IP to IP Architecture ASP1 (AS1) ASP1 (AS2) ASP2 (AS2) (Primary) (Backup) | | | <----ASP Up--------+ | +----ASP Up Ack ---> | | | | <-----------------------ASP Up---------+ +-----------------------ASP Up Ack ----> | | | <----ASP Active----+ | +-ASP Active Ack---> | | | | Loughney, et al. [Page 48] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 4.2 ASP fail-over Procedures SG ASP1 ASP2 | | | |<-----ASP Inactive-------| | |---NTFY(ASP Inactive)--->| | |--------------------NTFY(ASP-Inactive) (Optional)-->| | | | |<------------------------------ ASP Active----------| |-----------------------------NTFY(ASP-Active)------>| | | 4.3 SUA/SCCP-User Boundary Examples 4.3.1 Data Transfer This is an example of data transfer, assuming associations are already established. Note that the SCTP sack is shown purely for illustrative reasons. SEP SG SG ASP ASP SCCP SUA SCTP SCTP SUA | | | | | +----UDT-----> | | | | +---Send----> | | | |.. . . . . . . CLDT . . . . . . . .> | | +---data----> | | | | +-data arr--> | | | <-rec data--| | | <---sack----+ | | <-data arr--+ | | | +-rec data--> | | | < . . . . . . . CLDA . . . . . . . .. | | | | | 5 Security 5.1 Introduction SUA is designed to carry signaling messages for telephony services. As such, SUA must involve 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. 5.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: Loughney, et al. [Page 49] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 * 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 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. 5.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. 6 IANA Considerations 6.1 SCTP Payload Protocol ID A request will be made to IANA to assign SCTP Payload Protocol IDs. A Payload ID for the SUA will be registered. The Payload ID is included in each SCTP data chunk, to indicate which protocol SCTP is carrying. This Payload ID is not directly used by SCTP but may be used by certain network entities to identify the type of information being carried in this DATA chunk. It is assumed that the Payload ID for SUA will be 3. 6.2 Port Number SUA will use port number 14001, which is currently registered to "ITU-T SCCP". This Port Number is the port which the SG listen to when receiving SCTP datagrams. 7 Timer Values Ta 2 seconds Tr 2 seconds 8 Acknowledgements The authors would like to thank Lode Coene, Joe Keller, Florencio Escobar-Gonzalez, Marja-Liisa Hamalainen and Markus Maanoja for their insightful comments and suggestions. Funding for the RFC editor function is currently provided by the Internet Society. Loughney, et al. [Page 50] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 9 Authors' Addresses John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland john.loughney@nokia.com Greg Sidebottom Nortel Networks 3685 Richmond Rd, Nepean, Ontario, Canada K2H 5B7 gregside@nortelnetworks.com Guy Mousseau Nortel Networks 3685 Richmond Rd Nepean, Ontario, Canada K2H 5B7 Stephen Lorusso Unisphere Solutions One Executive Drive Chelmsford, MA 01824 USA email: SLorusso@UnisphereSolutions.com 10 References [2719] RFC 2719, "Framework Architecture for Signaling Transport" [ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System No. 7 (SS7) - Signaling Connection Control Part (SCCP)' [ANSI SCCP] ANSI T1.112 'Signaling System Number 7 - Signaling Connection Control Part' [ITU TCAP] ITU-T Recommendation Q.771-775 'Signaling System No. 7 SS7) - Transaction Capabilities (TCAP) [ANSI TCAP] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities Application Part' [RANAP] 3G TS 25.413 V3.0.0 (2000-01) 'Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling' [SCTP] Stream Control Transport Protocol , July 2000, Work in Progress. [M3UA] MTP3-User Adaptation Layer , July 2000, Work in Progress. [2401] RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Atkinson, November 1998. Loughney, et al. [Page 51] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 [UTRAN IUR] 3G TS 25.420 V3.0.0 (2000-01) "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iur Interface General Aspects and Principles" [2196] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997. [ENUM] "ENUM Requirements" , December 1999, Work in Progress. [E.164-DNS] "E.164 number and DNS", , July 2000, Work in Progress. Appendix A: Message mapping between SCCP and SUA. This is for illustrative purposes only. SUA SCCP SCCP Classes Mgt. SUA Name Name Full Name 0 1 2 3 Msg. Usage ===================================================================== Connectionless Messages CLDT UDT Unitdata X X - - - - CLDT XUDT Extended unitdata X X - - - - CLDT LUDT Long unitdata X X - - - - CLDA UDTS Unitdata service X X - - - - CLDA XUDTS Extended unitdata serv. X X - - - - CLDA LUDTS Long unitdata service X X - - - - Connection-Oriented Messages CODT DT1 Data form 1 - - X - - - CODT DT2 Data form 2 - - - X - - CODT ED Expedited data - - - X - - CODA AK Data acknowledgement - - - X - - CODA EA Expedited data ack. - - - X - - CORE CR Connection request - - X X - - COAK CC Connection confirm - - X X - - COAK CREF Connection refused - - X X - - RELRE RLSD Released - - X X - - RELCO RLC Release complete - - X X - - RESRE RSR Reset request - - - X - - RESCO RSC Reset confirm - - - X - - General Protocol Messages ERR ERR Protocol data unit error - - X X - X AUD IT Inactivity test - - X X - X SS7 MGT Messages DUNA n/a n/a - - - - - X DAVA n/a n/a - - - - - X DAUD n/a n/a - - - - - X SCMG SSC SCCP/subsystem-congested - - - - X - SCMG SSA subsystem-allowed - - - - X - SCMG SSP subsystem-prohibited - - - - X - SCMG SST subsystem-status-test - - - - X - SCMG SOR subsystem-oos-req - - - - X - Loughney, et al. [Page 52] Internet Draft SS7 SCCP-User Adaptation Layer July 2, 2000 SCMG SOG subsystem-oos-grant - - - - X - SUA MGT Messages ASPUP n/a n/a - - - - - X ASPDN n/a n/a - - - - - X ASPAC n/a n/a - - - - - X ASPIA n/a n/a - - - - - X NTFY n/a n/a - - - - - X - = Message not applicable for this protocol class. X = Message applicable for this protocol class. n/a = not applicable Appendix B: SCTP to SUA Message Mapping Examples CLDT - Pointer to Optional part shall be coded as 0 (as long as there is no optional parameter). - A and B flags are mapped from 'Protocol Class' parameter received in XUDT/LUDT/UDT (or from Data Request primitive). - C flag is mapped from 'Importance parameter' received in XUDT/LUDT (or from Data Request primitive), or if not present a default value for the message type shall be used. 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, et al. [Page 53]