From 773ea5a6b73132030bc7ee2f9f438432ce148b4d Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 7 Mar 2016 14:35:42 +0100 Subject: add RFC 3868 (SUA) spec in HTML --- ...ion_Control_Part_User_Adaptation_Layer_SUA.html | 7535 ++++++++++++++++++++ 1 file changed, 7535 insertions(+) create mode 100644 specs/RFC_3868__Signalling_Connection_Control_Part_User_Adaptation_Layer_SUA.html diff --git a/specs/RFC_3868__Signalling_Connection_Control_Part_User_Adaptation_Layer_SUA.html b/specs/RFC_3868__Signalling_Connection_Control_Part_User_Adaptation_Layer_SUA.html new file mode 100644 index 0000000..2ed631d --- /dev/null +++ b/specs/RFC_3868__Signalling_Connection_Control_Part_User_Adaptation_Layer_SUA.html @@ -0,0 +1,7535 @@ + + + + + + + + + + + + + + + + + + + + + RFC 3868 - Signalling Connection Control Part User Adaptation Layer (SUA) + + + + + + + + +
+
+
+ +
+[Docs] [txt|pdf] [draft-ietf-sigtra...] [Diff1] [Diff2] [IPR]
+
+ PROPOSED STANDARD
+
+
+Network Working Group                                   J. Loughney, Ed.
+Request for Comments: 3868                                         Nokia
+Category: Standards Track                                  G. Sidebottom
+                                                   Signatus Technologies
+                                                                L. Coene
+                                                              G. Verwimp
+                                                            Siemens n.v.
+                                                               J. Keller
+                                                                 Tekelec
+                                                             B. Bidulock
+                                                     OpenSS7 Corporation
+                                                            October 2004
+
+
+    Signalling Connection Control Part User Adaptation Layer (SUA)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a protocol for the transport of any Signalling
+   Connection Control Part-User signalling over IP using the Stream
+   Control Transmission Protocol.  The protocol is designed to be
+   modular and symmetric, to allow it to work in diverse architectures,
+   such as a Signalling Gateway to IP Signalling Endpoint architecture
+   as well as a peer-to-peer IP Signalling Endpoint architecture.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 1]
+

+RFC 3868                          SUA                       October 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.2.  Abbreviations and Terminology. . . . . . . . . . . . . .  4
+       1.3.  Signalling Transport Architecture. . . . . . . . . . . .  6
+       1.4.  Services Provided by the SUA Layer . . . . . . . . . . .  9
+       1.5.  Internal Functions Provided in the SUA Layer . . . . . . 11
+       1.6.  Definition of SUA Boundaries . . . . . . . . . . . . . . 14
+   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 19
+   3.  Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 19
+       3.1.  Common Message Header. . . . . . . . . . . . . . . . . . 20
+       3.2.  SUA Connectionless Messages. . . . . . . . . . . . . . . 24
+       3.3.  Connection Oriented Messages . . . . . . . . . . . . . . 27
+       3.4.  Signalling Network Management (SNM) Messages . . . . . . 42
+       3.5.  Application Server Process State Maintenance Messages. . 49
+       3.6.  ASP Traffic Maintenance Messages . . . . . . . . . . . . 53
+       3.7.  SUA Management Messages. . . . . . . . . . . . . . . . . 56
+       3.8.  Routing Key Management (RKM) Messages. . . . . . . . . . 58
+       3.9.  Common Parameters. . . . . . . . . . . . . . . . . . . . 61
+       3.10. SUA-Specific parameters. . . . . . . . . . . . . . . . . 74
+   4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 92
+       4.1.  Procedures to Support the SUA-User Layer . . . . . . . . 92
+       4.2.  Receipt of Primitives from the Layer Management. . . . . 93
+       4.3.  AS and ASP State Maintenance . . . . . . . . . . . . . . 95
+       4.4.  Routing Key Management Procedures. . . . . . . . . . . .109
+       4.5.  Availability and/or Congestion Status of SS7
+             Destination Support101 . . . . . . . . . . . . . . . . .112
+       4.6.  MTP3 Restart . . . . . . . . . . . . . . . . . . . . . .115
+       4.7.  SCCP - SUA Interworking at the SG. . . . . . . . . . . .115
+   5.  Examples of SUA Procedures . . . . . . . . . . . . . . . . . .117
+       5.1.  SG Architecture. . . . . . . . . . . . . . . . . . . . .117
+       5.2   IPSP Examples. . . . . . . . . . . . . . . . . . . . . .119
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . .121
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .121
+       7.1.  SCTP Payload Protocol ID . . . . . . . . . . . . . . . .121
+       7.2.  Port Number. . . . . . . . . . . . . . . . . . . . . . .121
+       7.3.  Protocol Extensions. . . . . . . . . . . . . . . . . . .121
+   8.  Timer Values . . . . . . . . . . . . . . . . . . . . . . . . .123
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .123
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .123
+       10.1. Normative References . . . . . . . . . . . . . . . . . .123
+       10.2. Informative References . . . . . . . . . . . . . . . . .124
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 2]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Appendix A.  Signalling Network Architecture . . . . . . . . . . .125
+       A.1.  Generalized Peer-to-Peer Network Architecture. . . . . .125
+       A.2.  Signalling Gateway Network Architecture. . . . . . . . .126
+       A.3.  Signalling Gateway Message Distribution
+             Recommendations. . . . . . . . . . . . . . . . . . . . .128
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .129
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .131
+
+1.  Introduction
+
+   There is ongoing integration of switched circuit networks and IP
+   networks.  Network service providers are designing IP-based
+   signalling architectures that need support for SS7 and SS7-like
+   signalling protocols.  IP provides an effective way to transport user
+   data and for operators to expand their networks and build new
+   services.  In these networks, there is need for interworking between
+   the SS7 and IP domains [2719].
+
+   This document defines a protocol for the transport SS7 SCCP-User
+   protocols [ANSI SCCP] [ITU SCCP], such as TCAP and RANAP, over IP
+   using the Stream Control Transmission Protocol (SCTP) [2960].
+
+1.1.  Scope
+
+   This document details the delivery of SCCP-user messages (MAP & CAP
+   over TCAP [ANSI TCAP] [ITU TCAP], RANAP [RANAP], etc.) messages over
+   IP between two signalling endpoints.  Consideration is given for the
+   transport from a signalling gateway to an IP signalling node (such as
+   an IP-resident Database) as described in the Framework Architecture
+   for Signalling Transport [2719].  This protocol can also support
+   transport of SCCP-user messages between two endpoints wholly
+   contained within an IP network.
+
+   The delivery mechanism addresses the following criteria:
+
+   *  Support for transfer of SCCP-User Part messages
+   *  Support for SCCP connectionless service.
+   *  Support for SCCP connection oriented service.
+   *  Support for the operation of SCCP-User protocol peers.
+   *  Support for the management of SCTP transport associations between
+      signalling gateways and IP-based signalling nodes.
+   *  Support for distributed IP-based signalling nodes.
+   *  Support for the asynchronous reporting of status changes to
+      management functions.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 3]
+

+RFC 3868                          SUA                       October 2004
+
+
+1.2.  Abbreviations and Terminology
+
+1.2.1.  Abbreviations
+
+   CAP - CAMEL Application Protocol.
+
+   GTT - Global Title Translation.
+
+   MAP - Mobile Application Protocol.
+
+   PC - Signalling System no. 7 Point Code.
+
+   RANAP - Radio Access Network Application Protocol.
+
+   SCTP - Stream Control Transmission Protocol.
+
+   SS7 - Signalling System no. 7.
+
+   TCAP - Transaction Capabilities Application Protocol.
+
+1.2.2.  Terminology
+
+   Signalling Gateway (SG) - Network element that terminates switched
+   circuit networks and transports SCCP-User signalling over IP to an IP
+   signalling endpoint.  A Signalling Gateway could be modeled as one or
+   more Signalling Gateway Processes, which are located at the border of
+   the SS7 and IP networks.  Where an SG contains more than one SGP, the
+   SG is a logical entity and the contained SGPs are assumed to be
+   coordinated into a single management view to the SS7 network and to
+   the supported Application Servers.
+
+   Application Server (AS) - A logical entity serving a specific Routing
+   Key.  An example of an Application Server is a virtual IP database
+   element handling all requests for an SCCP-user.  The AS contains a
+   set of one or more unique Application Server Processes, of which one
+   or more is normally actively processing traffic.
+
+   Application Server Process (ASP) - An Application Server Process
+   serves as an active or backup process of an Application Server (e.g.,
+   part of a distributed signalling node or database element). Examples
+   of ASPs are MGCs, IP SCPs, or IP-based HLRs.  An ASP contains an SCTP
+   endpoint and may be configured to process traffic within more than
+   one Application Server.
+
+   IP Server Process (IPSP) - A process instance of an IP-based
+   application.  An IPSP is essentially the same as an ASP, except that
+   it uses SUA in a peer-to-peer fashion.  Conceptually, an IPSP does
+   not use the services of a Signalling Gateway.
+
+
+
+Loughney, et al.            Standards Track                     [Page 4]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Signalling Gateway Process (SGP) - A process instance of a Signalling
+   Gateway.  It serves as an active, load-sharing or broadcast process
+   of a Signalling Gateway.
+
+   Signalling Process - A process instance that uses SUA to communicate
+   with other signalling process.  An ASP, a SGP and an IPSP are all
+   signalling processes.
+
+   Association - An association refers to an SCTP association.  The
+   association provides the transport for the delivery of SCCP-User
+   protocol data units and SUA layer peer messages.
+
+   Routing Key - The Routing Key describes a set of SS7 parameters
+   and/or parameter ranges that uniquely defines the range of signalling
+   traffic configured to be handled by a particular Application Server.
+   An example would be where a Routing Key consists of a particular SS7
+   SCCP SSN plus an identifier to uniquely mark the network that the SSN
+   belongs to, for which all traffic would be directed to a particular
+   Application Server.  Routing Keys are mutually exclusive in the sense
+   that a received SS7 signalling message cannot be directed to more
+   than one Routing Key.  Routing Keys can be provisioned, for example,
+   by a MIB or registered using SUA's dynamic registration procedures.
+   Routing keys MUST NOT span multiple network appearances.
+
+   Routing Context - An Application Server Process may be configured to
+   process traffic within more than one Application Server.  In this
+   case, the Routing Context parameter is exchanged between the SGP and
+   the ASP (or between two ASPs), identifying the relevant Application
+   Server.  From the perspective of an SGP/ASP, the Routing Context
+   uniquely identifies the range of traffic associated with a particular
+   Application Server, which the ASP is configured to receive.  There is
+   a 1:1 relationship between a Routing Context value and a Routing Key
+   within an AS.  Therefore the Routing Context can be viewed as an
+   index into an AS Table containing the AS Routing Keys.
+
+   Address Mapping Function (AMF) - The AMF is an implementation
+   dependent function that is responsible for resolving the address
+   presented in the incoming SCCP/SUA message to correct SCTP
+   association for the desired endpoint.  The AMF MAY use routing
+   context / routing key information as selection criteria for the
+   appropriate SCTP association.
+
+   Fail-over - The capability to reroute signalling traffic as required
+   to an alternate Application Server Process, or group of ASPs, within
+   an Application Server in the event of failure or unavailability of a
+   currently used Application Server Process. Fail-over may apply upon
+   the return to service of a previously unavailable Application Server
+   Process.
+
+
+
+Loughney, et al.            Standards Track                     [Page 5]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Host - The computing platform that the SGP or ASP process is running
+   on.
+
+   Layer Management - Layer Management is a nodal function that handles
+   the inputs and outputs between the SUA layer and a local management
+   entity.
+
+   Network Appearance - The Network Appearance is an SUA local reference
+   (typically an integer) shared by SG and AS that together with a
+   Signalling Point Code uniquely identifies an SS7 node by indicating
+   the specific SS7 network it belongs to.
+
+   Network Byte Order - Most significant byte first, a.k.a. Big Endian.
+
+   Stream - A stream refers to an SCTP stream; a unidirectional logical
+   channel established from one SCTP endpoint to another associated SCTP
+   endpoint, within which all user messages are delivered sequenced
+   except for those submitted to the unordered delivery service.
+
+   Transport address - an address that serves as a source or destination
+   for the unreliable packet transport service used by SCTP.  In IP
+   networks, a transport address is defined by the combination of an IP
+   address and an SCTP port number.  Note, only one SCTP port may be
+   defined for each endpoint, but each SCTP endpoint may have multiple
+   IP addresses.
+
+1.3.  Signalling Transport Architecture
+
+   The framework architecture that has been defined for switched circuit
+   networks signalling transport over IP [2719] uses multiple
+   components, including an IP transport protocol, a signalling common
+   transport protocol and an adaptation module to support the services
+   expected by a particular switched circuit networks signalling
+   protocol from its underlying protocol layer.
+
+   In general terms, the SUA architecture can be modeled as a peer-to-
+   peer architecture.  The first section considers the SS7 to IP
+   interworking architectures for connectionless and connection-oriented
+   transport.  For this case, it is assumed that the ASP initiates the
+   establishment of the SCTP association with SG.
+
+1.3.1.  Protocol Architecture for Connectionless Transport
+
+   In this architecture, the SCCP and SUA layers interface in the SG.
+   Interworking between the SCCP and SUA layers is needed to provide for
+   the transfer of the user messages as well as the management messages.
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 6]
+

+RFC 3868                          SUA                       October 2004
+
+
+      ********   SS7   ***************   IP   ********
+      * SEP  *---------*             *--------*      *
+      *  or  *         *      SG     *        * ASP  *
+      * STP  *         *             *        *      *
+      ********         ***************        ********
+
+      +------+                                +------+
+      | SUAP |                                | SUAP |
+      +------+         +------+------+        +------+
+      | SCCP |         | SCCP | SUA  |        | SUA  |
+      +------+         +------+------+        +------+
+      | MTP3 |         | MTP3 |      |        |      |
+      +------+         +------+ SCTP |        | SCTP |
+      | MTP2 |         | MTP2 |      |        |      |
+      +------+         +------+------+        +------+
+      |  L1  |         |  L1  |  IP  |        |  IP  |
+      +------+         +------+------+        +------+
+          |               |         |            |
+          +---------------+         +------------+
+
+        SUAP - SCCP/SUA User Protocol (TCAP, for example)
+        STP  - SS7 Signalling Transfer Point
+
+   See Appendix A.3.1 for operation recommendations.
+
+1.3.1.1.  SG as endpoint
+
+   In this case, the connectionless SCCP messages are routed on point
+   code (PC) and subsystem number (SSN).  The subsystem identified by
+   SSN and Routing Context is regarded as local to the SG.  This means
+   from SS7 point of view, the SCCP-user is located at the SG.
+
+1.3.1.2.  Signalling Gateway as relay-point
+
+   A Global Title translation is executed at the signalling gateway,
+   before the destination of the message can be determined.  The actual
+   location of the SCCP-user is irrelevant to the SS7 network.  GT
+   Translation yields an "SCCP entity set", from which an Application
+   Server can be derived.  Selection of the Application Server is based
+   on the SCCP called party address (and possibly other SS7 parameters
+   depending on the implementation).
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 7]
+

+RFC 3868                          SUA                       October 2004
+
+
+1.3.2.  Protocol Architecture for Connection-Oriented Transport
+
+   In this architecture, the SCCP and SUA layers share an interface in
+   the signalling gateway process to associate the two connection
+   sections needed for the connection-oriented data transfer between SEP
+   and ASP.  Both connection sections are setup when routing the Connect
+   Request messages from the signalling end point via signalling gateway
+   process to ASP and visa versa.  The routing of the Connect Request
+   message is performed in the same way as described in 1.3.1.
+
+      ********   SS7   ***************   IP   ********
+      * SEP/ *---------*      SG     *--------* ASP  *
+      * STP  *         *             *        *      *
+      ********         ***************        ********
+
+      +------+                                +------+
+      | SUAP |                                | SUAP |
+      +------+         +------+------+        +------+
+      | SCCP |         | SCCP | SUA  |        | SUA  |
+      +------+         +------+------+        +------+
+      | MTP3 |         | MTP3 |      |        |      |
+      +------|         +------+ SCTP |        | SCTP |
+      | MTP2 |         | MTP2 |      |        |      |
+      +------+         +------+------+        +------+
+      |  L1  |         |  L1  |  IP  |        |  IP  |
+      +------+         +------+------+        +------+
+          |               |         |            |
+          +---------------+         +------------+
+
+        SUAP - SCCP/SUA Application Protocol (e.g., - RANAP/RNSAP)
+        STP  - SS7 Signalling Transfer Point
+
+   See Appendix A.3.2 for operation recommendations.
+
+1.3.3.  All IP Architecture
+
+   This architecture can be used to carry a protocol that uses the
+   transport services of SCCP within an IP network.  This allows
+   flexibility in developing networks, especially when interaction
+   between legacy signalling is not needed.  The architecture removes
+   the need for signalling gateway functionality.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 8]
+

+RFC 3868                          SUA                       October 2004
+
+
+      ********   IP   ********
+      * IPSP *--------* IPSP *
+      ********        ********
+
+      +------+        +------+
+      | SUAP |        | SUAP |
+      +------+        +------+
+      | SUA  |        | SUA  |
+      +------+        +------+
+      | SCTP |        | SCTP |
+      +------+        +------+
+      |  IP  |        |  IP  |
+      +------+        +------+
+         |                |
+         +----------------+
+
+      SUAP - SCCP/SUA Application Protocol (e.g., - RANAP/RNSAP)
+
+1.3.4.  ASP Fail-over Model and Terminology
+
+   The SUA protocol supports ASP fail-over functions to support a high
+   availability of transaction processing capability.
+
+   An Application Server can be considered as a list of all ASPs
+   configured/registered to handle SCCP-user messages within a certain
+   range of routing information, known as a Routing Key.  One or more
+   ASPs in the list may normally be active to handle traffic, while
+   others may be inactive but available in the event of failure or
+   unavailability of the active ASP(s).
+
+   For operation recommendations, see Appendix A.
+
+1.4.  Services Provided by the SUA Layer
+
+1.4.1.  Support for the transport of SCCP-User Messages
+
+   The SUA supports the transfer of SCCP-user messages.  The SUA layer
+   at the signalling gateway and at the ASP support the seamless
+   transport of user messages between the signalling gateway and the
+   ASP.
+
+1.4.2.  SCCP Protocol Class Support
+
+   Depending upon the SCCP-users supported, the SUA supports the 4
+   possible SCCP protocol classes transparently.  The SCCP protocol
+   classes are defined as follows:
+
+
+
+
+
+Loughney, et al.            Standards Track                     [Page 9]
+

+RFC 3868                          SUA                       October 2004
+
+
+   *  Protocol class 0 provides unordered transfer of SCCP-user messages
+      in a connectionless manner.
+
+   *  Protocol class 1 allows the SCCP-user to select the sequenced
+      delivery of SCCP-user messages in a connectionless manner.
+
+   *  Protocol class 2 allows the bidirectional transfer of SCCP-user
+      messages by setting up a temporary or permanent signalling
+      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 provides the capability to indicate errors associated
+   with the SUA-protocol messages and to provide notification to local
+   management and the remote peer as is necessary.
+
+1.4.4.  Interworking with SCCP Network Management Functions
+
+   SUA uses the existing ASP management messages for ASP status
+   handling.  The interworking with SCCP management messages consists of
+   DUNA, DAVA, DAUD, DRST, DUPU or SCON messages (defined in section 3)
+   on receipt of SSP, SSA, SST or SSC (defined by SCCP) to the
+   appropriate ASPs.  See also chapter 1.4.5.  The primitives below are
+   sent between the SCCP and SUA management functions in the SG to
+   trigger events in the IP and SS7 domain.
+
+   Generic   |Specific   |
+   Name      |Name       |ANSI/ITU Reference
+   ----------+-----------+---------------------------------------------
+   N-State   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
+             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
+   ----------+-----------+---------------------------------------------
+   N-PCstate |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 1/Q.711)
+             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
+   ----------+-----------+---------------------------------------------
+   N-Coord   |Request    |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
+             |Indication |ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
+             |Response   |
+             |Confirm    |
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 10]
+

+RFC 3868                          SUA                       October 2004
+
+
+1.4.5.  Support for the management between the SGP and ASP.
+
+   The SUA layer provides interworking with SCCP management functions at
+   the SG for operation between the switched circuit networks and the IP
+   network.  It should:
+
+   *  Provide an indication to the SCCP-user at an ASP that a SS7
+      endpoint/peer is unreachable.
+   *  Provide an indication to the SCCP-user at an ASP that a SS7
+      endpoint/peer is reachable.
+   *  Provide congestion indication to SCCP-user at an ASP.
+   *  Provide the initiation of an audit of SS7 endpoints at the SG.
+
+1.4.6.  Relay function
+
+   For network scalability purposes, the SUA may be enhanced with a
+   relay functionality to determine the next hop SCTP association toward
+   the destination SUA endpoint.
+
+   The determination of the next hop may be based on Global Title
+   information (e.g., E.164 number), in analogy with SCCP GTT in SS7
+   networks, modeled in [ITU-T Q.714].  It may also be based on Hostname
+   information, IP address or pointcode contained in the called party
+   address.
+
+   This allows for greater scalability, reliability and flexibility in
+   wide-scale deployments of SUA.  The usage of a relay function is a
+   deployment decision.
+
+1.5.  Internal Functions Provided in the SUA Layer
+
+   To perform its addressing and relaying capabilities, the SUA makes
+   use of an Address Mapping Function (AMF).  This function is
+   considered part of SUA, but the way it is realized is left
+   implementation / deployment dependent (local tables, DNS [3761],
+   LDAP, etc.)
+
+   The AMF is invoked when a message is received at the incoming
+   interface.  The AMF is responsible for resolving the address
+   presented in the incoming SCCP/SUA message to SCTP associations to
+   destinations within the IP network.  The AMF will select the
+   appropriate SCTP association based upon routing context / routing key
+   information available.  The destination might be the end SUA node or
+   a SUA relay node.  The Routing Keys reference an Application Server,
+   which will have one or more ASPs processing traffic for the AS.  The
+   availability and status of the ASPs is handled by SUA ASP management
+   messages.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 11]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Possible SS7 address/routing information that comprise a Routing Key
+   entry includes, for example, OPC, DPC, SIO found in the MTP3 routing
+   label, SCCP subsystem number, or Transaction ID.  IP addresses and
+   hostnames can also be used as Routing Key Information.
+
+   It is expected that the routing keys be provisioned via a MIB,
+   dynamic registration or external process, such as a database.
+
+1.5.1.  Address Mapping at the SG
+
+   Normally, one or more ASPs are active in the AS (i.e., currently
+   processing traffic) but in certain failure and transition cases it is
+   possible that there may not be an active ASP available.  The SGP will
+   buffer the message destined for this AS for a time T(r) or until an
+   ASP becomes available.  When no ASP becomes available before expiry
+   of T(r), the SGP will flush the buffered messages and initiate the
+   appropriate return or refusal procedures.
+
+   If there is no address mapping match for an incoming message, a
+   default treatment MAY be specified.  Possible solutions are to
+   provide a default Application Server to direct all unallocated
+   traffic to a (set of) default ASP(s), or to drop the messages and
+   provide a notification to management.  The treatment of unallocated
+   traffic is implementation dependent.
+
+1.5.2.  Address Mapping at the ASP
+
+   To direct messages to the SS7 network, the ASP MAY perform an address
+   mapping to choose the proper SGP for a given message.  This is
+   accomplished by observing the Destination Point Code and other
+   elements of the outgoing message, SS7 network status, SGP
+   availability, and Routing Context configuration tables.
+
+   A Signalling Gateway may be composed of one or more SGPs.  There is,
+   however, no SUA messaging to manage the status of an SGP.  Whenever
+   an SCTP association to an SGP exists, it is assumed to be available.
+   Also, every SGP of one SG communicating with one ASP regarding one AS
+   provides identical SS7 connectivity to this ASP.
+
+   An ASP routes responses to the SGP that it received messages from;
+   within the routing context which it is currently active and receiving
+   traffic.
+
+1.5.3.  Address Mapping Function at a Relay Node
+
+   The relay function is invoked when:
+
+   -  Routing is on Global Title
+
+
+
+Loughney, et al.            Standards Track                    [Page 12]
+

+RFC 3868                          SUA                       October 2004
+
+
+   -  Routing is on Hostname
+   -  Routing is on SSN and PC or SSN and IP Address and the address
+      presented is not the one of the relay node
+
+   Translation/resolution of the above address information yields one of
+   the following:
+
+   -  Route on SSN: SCTP association ID toward the destination node, SSN
+      and optionally Routing Context and/or IP address.
+   -  Route on GT: SCTP association ID toward next relay node, (new) GT
+      and optionally SSN and/or Routing Context.
+   -  Routing on Hostname: SCTP association ID toward next relay node,
+      (new) Hostname and optionally SSN and/or Routing Context.
+   -  A local SUA-user (combined relay/end node)
+
+   To prevent looping, an SS7 hop counter is used.  The originating end
+   node (be it an SS7 or an IP node) sets the value of the SS7 hop
+   counter to the maximum value (15 or less).  Each time the relay
+   function is invoked within an intermediate (relay) node, the SS7 hop
+   counter is decremented.  When the value reaches zero, the return or
+   refusal procedures are invoked with reason "Hop counter violation".
+
+1.5.4.  SCTP Stream Mapping
+
+   The SUA supports SCTP streams.  Signalling Gateway SG and Application
+   Servers need 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 with sequenced delivery.
+
+   SUA uses stream 0 for SUA management messages.  It is OPTIONAL that
+   sequenced delivery be used to preserve the order of management
+   message delivery.
+
+   Stream selection based on protocol class:
+
+   -  Protocol class 0: SUA MAY select unordered delivery.  The stream
+      selected is based on traffic information available to the SGP or
+      ASP.
+
+   -  Protocol class 1: SUA MUST select ordered delivery.  The stream
+      selected is based upon the sequence parameter given by the upper
+      layer over the primitive interface and other traffic information
+      available to the SGP or ASP
+
+   -  Protocol classes 2 and 3: SUA MUST select ordered delivery. The
+      stream selected is based upon the source local reference of the
+      connection and other traffic information available to the SGP or
+      ASP.
+
+
+
+Loughney, et al.            Standards Track                    [Page 13]
+

+RFC 3868                          SUA                       October 2004
+
+
+1.5.5.  Flow Control
+
+   Local Management at an ASP may wish to stop traffic across an SCTP
+   association to temporarily remove the association from service or to
+   perform testing and maintenance activity.  The function could
+   optionally be used to control the start of traffic on to a newly
+   available SCTP association.
+
+1.5.6.  Congestion Management
+
+   The SUA layer is informed of local and IP network congestion by means
+   of an implementation-dependent function (e.g., an implementation-
+   dependent indication from the SCTP of IP network congestion).
+
+   At an ASP or IPSP, the SUA layer indicates congestion to local SCCP-
+   Users by means of an appropriate SCCP primitive (e.g., N-INFORM, N-
+   NOTICE), as per current SCCP procedures, to invoke appropriate upper
+   layer responses.  When an SG determines that the transport of SS7
+   messages is encountering congestion, the SG MAY trigger SS7 SCCP
+   Congestion messages to originating SS7 nodes, per the congestion
+   procedures of the relevant SCCP standard.  The triggering of SS7 SCCP
+   Management messages from an SG is an implementation-dependent
+   function.
+
+   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
+   SUA peer with an SCON message.  When an SG receives a congestion
+   message (SCON) from an ASP, and the SG determines that an endpoint is
+   now encountering congestion, it MAY trigger congestion procedures of
+   the relevant SCCP standard.
+
+1.6.  Definition of SUA Boundaries
+
+1.6.1.  Definition of the upper boundary
+
+   The following primitives are supported between the SUA and an SCCP-
+   user (a reference to ITU and ANSI sections where these primitives and
+   corresponding parameters are described, is also given):
+
+   Generic     |Specific  |
+   Name        |Name      |ANSI/ITU Reference
+   ------------+----------+-------------------------------------------
+   N-CONNECT   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
+               |Response  |
+               |Confirm   |
+   ------------+----------+-------------------------------------------
+   N-DATA      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
+
+
+
+Loughney, et al.            Standards Track                    [Page 14]
+

+RFC 3868                          SUA                       October 2004
+
+
+   ------------+----------+-------------------------------------------
+   N-EXPEDITED |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)
+   DATA        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
+   ------------+----------+-------------------------------------------
+   N-RESET     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
+               |Response  |
+               |Confirm   |
+   ------------+----------+-------------------------------------------
+   N-DISCONNECT|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
+   ------------+----------+-------------------------------------------
+   N-INFORM    |Request   |ITU-Q.711   Chap 6.1.1.3.2 (Tab 8/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
+   ------------+----------+-------------------------------------------
+   N-UNITDATA  |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 12/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
+   ------------+----------+-------------------------------------------
+   N-NOTICE    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 13/Q.711)
+               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
+   ------------+----------+--------------------------------------------
+   N-STATE     |Request   |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
+   ------------+----------+--------------------------------------------
+   N-PCSTATE   |Indication|ITU-Q.711   Chap 6.3.2.3.3 (Tab 17/Q.711)
+               |          |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
+   ------------+----------+--------------------------------------------
+   N-COORD     |Request   |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
+               |Indication|ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
+               |Response  |
+               |Confirm   |
+
+1.6.2.  Definition of the lower boundary
+
+   The upper layer primitives provided by the SCTP are provided in
+   [SCTP].
+
+1.6.3.  Definition of the Boundary between SUA and Layer Management
+
+   M-SCTP_ESTABLISH request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to establish an SCTP association with its
+             peer.
+
+   M-SCTP_ESTABLISH confirm
+   Direction: SUA -> LM
+   Purpose:  ASP confirms to LM that it has established an SCTP
+             association with its peer.
+
+
+
+Loughney, et al.            Standards Track                    [Page 15]
+

+RFC 3868                          SUA                       October 2004
+
+
+
+   M-SCTP_ESTABLISH indication
+   Direction: SUA -> LM
+   Purpose:  SUA informs LM that a remote ASP has established an SCTP
+             association.
+
+   M-SCTP_RELEASE request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to release an SCTP association with its
+             peer.
+
+   M-SCTP_RELEASE confirm
+   Direction: SUA -> LM
+   Purpose:  ASP confirms to LM that it has released SCTP association
+             with its peer.
+
+   M-SCTP_RELEASE indication
+   Direction: SUA -> LM
+   Purpose:  SUA informs LM that a remote ASP has released an SCTP
+             Association or the SCTP association has failed.
+
+   M-SCTP RESTART indication
+   Direction: SUA -> LM
+   Purpose:  SUA informs LM that an SCTP restart indication has been
+             received.
+
+   M-SCTP_STATUS request
+   Direction: LM -> SUA
+   Purpose:  LM requests SUA to report the status of an SCTP
+             association.
+
+   M-SCTP_STATUS confirm
+   Direction: SUA -> LM
+   Purpose:  SUA responds with the status of an SCTP association.
+
+   M-SCTP STATUS indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports the status of an SCTP association.
+
+   M-ASP_STATUS request
+   Direction: LM -> SUA
+   Purpose:  LM requests SUA to report the status of a local or remote
+               ASP.
+
+   M-ASP_STATUS confirm
+   Direction: SUA -> LM
+   Purpose:  SUA reports status of local or remote ASP.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 16]
+

+RFC 3868                          SUA                       October 2004
+
+
+   M-AS_STATUS request
+   Direction: LM -> SUA
+   Purpose:  LM requests SUA to report the status of an AS.
+
+   M-AS_STATUS confirm
+   Direction: SUA -> LM
+   Purpose:  SUA reports the status of an AS.
+
+   M-NOTIFY indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports that it has received a Notify message from its
+             peer.
+
+   M-ERROR indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports that it has received an Error message from its
+             peer or that a local operation has been unsuccessful.
+
+   M-ASP_UP request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to start its operation and send an ASP Up
+             message to its peer.
+
+   M-ASP_UP confirm
+   Direction: SUA -> LM
+   Purpose:  ASP reports that is has received an ASP UP Ack message
+             from its peer.
+
+   M-ASP_UP indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports it has successfully processed an incoming ASP
+             Up message from its peer.
+
+   M-ASP_DOWN request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to stop its operation and send an ASP Down
+             message to its peer.
+
+   M-ASP_DOWN confirm
+   Direction: SUA -> LM
+   Purpose:  ASP reports that is has received an ASP Down Ack message
+             from its peer.
+
+   M-ASP_DOWN indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports it has successfully processed an incoming ASP
+             Down message from its peer, or the SCTP association has
+             been lost/reset.
+
+
+
+Loughney, et al.            Standards Track                    [Page 17]
+

+RFC 3868                          SUA                       October 2004
+
+
+
+   M-ASP_ACTIVE request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to send an ASP Active message to its peer.
+
+   M-ASP_ACTIVE confirm
+   Direction: SUA -> LM
+   Purpose:  ASP reports that is has received an ASP Active Ack message
+             from its peer.
+
+   M-ASP_ACTIVE indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports it has successfully processed an incoming ASP
+             Active message from its peer.
+
+   M-ASP_INACTIVE request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to send an ASP Inactive message to its
+             peer.
+
+   M-ASP_INACTIVE confirm
+   Direction: LM -> SUA
+   Purpose:  ASP reports that is has received an ASP Inactive
+             Ack message from its peer.
+
+   M-ASP_INACTIVE indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports it has successfully processed an incoming ASP
+             Inactive message from its peer.
+
+   M-AS_ACTIVE indication
+   Direction: SUA -> LM
+   Purpose:  SUA reports that an AS has moved to the AS-ACTIVE state.
+
+   M-AS_INACTIVE indication
+   Direction: SUA -> LM
+   Purpose: SUA reports that an AS has moved to the AS-INACTIVE state.
+
+   M-AS_DOWN indication
+   Direction: SUA -> LM
+   Purpose: SUA reports that an AS has moved to the AS-DOWN state.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 18]
+

+RFC 3868                          SUA                       October 2004
+
+
+   If the SUA layer supports dynamic registration of Routing Key, the
+   layer MAY support the following additional primitives:
+
+   M-RK_REG request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to register RK(s) with its peer by sending
+             REG REQ message.
+
+   M-RK_REG confirm
+   Direction: SUA -> LM
+   Purpose:  ASP reports that it has received REG RSP message with
+             registration status as successful from its peer.
+
+   M-RK_REG indication
+   Direction: SUA -> LM
+   Purpose:  SUA informs LM that it has successfully processed an
+             incoming REG REQ message.
+
+   M-RK_DEREG request
+   Direction: LM -> SUA
+   Purpose:  LM requests ASP to deregister RK(s) with its peer by
+             sending DEREG REQ message.
+
+   M-RK_DEREG confirm
+   Direction: SUA -> LM
+   Purpose:  ASP reports that it has received DEREG RESP message with
+             deregistration status as successful from its peer.
+
+   M-RK_DEREG indication
+   Direction: SUA -> LM
+   Purpose:  SUA informs LM that it has successfully processed an
+             incoming DEREG REQ from its peer.
+
+2.  Conventions
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
+   they appear in this document, are to be interpreted as described in
+   BCP 14, RFC 2119 [2119].
+
+3.  Protocol Elements
+
+   The general message format includes a Common Message Header together
+   with a list of zero or more parameters as defined by the Message
+   Type.
+
+   For forward compatibility, all Message Types may have attached
+   parameters even if none are specified in this version.
+
+
+
+Loughney, et al.            Standards Track                    [Page 19]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The Reserved field is set to 0 in messages sent and is not to be
+   examined in messages received.
+
+3.1.  Common Message Header
+
+   The protocol messages for the SCCP-User Adaptation Protocol requires
+   a message structure which contains a version, message class, message
+   type, message length and message contents.  This message header is
+   common among all signalling protocol adaptation layers:
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |    Version    |   Reserved    | Message Class | Message Type  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Message Length                         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Message Data                          |
+
+   Note that the 'data' portion of SUA messages SHALL contain SCCP-User
+   data, not the encapsulated SCCP message.
+
+   Optional parameters can only occur at most once in an SUA message.
+
+3.1.1.  SUA Protocol Version
+
+   The version field (ver) contains the version of the SUA adaptation
+   layer.  The supported versions are:
+
+      1   SUA version 1.0
+
+3.1.2.  Message Classes
+
+   Message Classes
+
+      0         SUA Management (MGMT) Message
+      1         Reserved
+      2         Signalling Network Management (SNM) Messages
+      3         ASP State Maintenance (ASPSM) Messages
+      4         ASP Traffic Maintenance (ASPTM) Messages
+      5         Reserved
+      6         Reserved
+      7         Connectionless Messages
+      8         Connection-Oriented Messages
+      9         Routing Key Management (RKM) Messages.
+      10 - 127  Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 20]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.1.3.  Message Types
+
+   SUA Management Messages
+
+      0         Error (ERR)
+      1         Notify (NTFY)
+      2 - 127   Reserved by the IETF
+      128- 255  Reserved for IETF-Defined Message Class Extensions
+
+   Signalling Network Management (SNM) Messages
+
+      0         Reserved
+      1         Destination Unavailable (DUNA)
+      2         Destination Available (DAVA)
+      3         Destination State Audit (DAUD)
+      4         Signalling Congestion (SCON)
+      5         Destination User Part Unavailable (DUPU)
+      6         Destination Restricted (DRST)
+      7 - 127   Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+   Application Server Process State Maintenance (ASPSM) Messages
+
+      0         Reserved
+      1         ASP Up (UP)
+      2         ASP Down (DOWN)
+      3         Heartbeat (BEAT)
+      4         ASP Up Ack (UP ACK)
+      5         ASP Down Ack (DOWN ACK)
+      6         Heartbeat Ack (BEAT ACK)
+      7 - 127   Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+   ASP Traffic Maintenance (ASPTM) Messages
+
+      0         Reserved
+      1         ASP Active (ACTIVE)
+      2         ASP Inactive (INACTIVE)
+      3         ASP Active Ack (ACTIVE ACK)
+      4         ASP Inactive Ack (INACTIVE ACK)
+      5 - 127   Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 21]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Routing Key Management (RKM) Messages
+
+      0         Reserved
+      1         Registration Request (REG REQ)
+      2         Registration Response (REG RSP)
+      3         Deregistration Request (DEREG REQ)
+      4         Deregistration Response (DEREG RSP)
+      5 - 127   Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+   Connectionless (CL) Messages
+
+      0         Reserved
+      1         Connectionless Data Transfer (CLDT)
+      2         Connectionless Data Response (CLDR)
+      3 - 127   Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+   Connection-Oriented (CO) Messages
+
+      0         Reserved
+      1         Connection Request (CORE)
+      2         Connection Acknowledge (COAK)
+      3         Connection Refused (COREF)
+      4         Release Request (RELRE)
+      5         Release Complete (RELCO)
+      6         Reset Confirm (RESCO)
+      7         Reset Request (RESRE)
+      8         Connection Oriented Data Transfer (CODT)
+      9         Connection Oriented Data Acknowledge (CODA)
+      10        Connection Oriented Error (COERR)
+      11        Inactivity Test (COIT)
+      12 - 127  Reserved by the IETF
+      128 - 255 Reserved for IETF-Defined Message Class Extensions
+
+3.1.4.  Message Length
+
+   The Message Length defines the length of the message in octets,
+   including the header and including all padding bytes.  Message Length
+   is a 32-bit identifier.
+
+3.1.5.  Tag-Length-Value Format
+
+   SUA messages consist of a Common Header followed by zero or more
+   parameters, as defined by the message type.  The Tag-Length-Value
+   (TLV) parameters contained in a message are defined in a Tag-Length-
+   Value format as shown below.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 22]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Parameter Tag        |       Parameter Length        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                       Parameter Value                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameter Tag: 16 bits (unsigned integer)
+
+      Tag field is a 16-bit identifier of the type of parameter.  It
+      takes a value of 0 to 65535.
+
+   Parameter Length: 16 bits (unsigned integer)
+
+      The Parameter Length field contains the size of the parameter in
+      bytes, including the Parameter Tag, Parameter Length, and
+      Parameter Value fields.  The Parameter Length does not include any
+      padding bytes.  However, composite parameters will contain all
+      padding bytes, since all parameters contained within this
+      composite parameter will be considered multiples of 4 bytes.
+
+   Parameter Value: variable-length.
+
+      The Parameter Value field contains the actual information to be
+      transfered in the parameter.
+
+      The total length of a parameter (including Tag, Parameter Length
+      and Value fields) MUST be a multiple of 4 bytes.  If the length of
+      the parameter is not a multiple of 4 bytes, the sender pads the
+      parameter at the end (i.e., after the Parameter Value field) with
+      all zero bytes.  The length of the padding is NOT included in the
+      parameter length field.  A sender SHOULD NOT pad with more than 3
+      bytes.  The receiver MUST ignore the padding bytes.
+
+   Implementation note: The use of TLV in principle allows the
+   parameters to be placed in a random order in the message.  However,
+   some guidelines should be considered for easy processing in the
+   following order:
+
+   -  Parameters needed to correctly process other message parameters,
+      preferably should precede these parameters (such as Routing
+      Context).
+   -  Mandatory parameters preferably SHOULD precede any optional
+      parameters.
+   -  The data parameter will normally be the final one in the message.
+
+
+
+Loughney, et al.            Standards Track                    [Page 23]
+

+RFC 3868                          SUA                       October 2004
+
+
+   -  The receiver SHOULD accept parameters in any order, except where
+      explicitly mandated.
+
+3.2.  SUA Connectionless Messages
+
+   The following section describes the SUA Connectionless transfer
+   messages and parameter contents.  The general message format includes
+   a Common Message Header together with a list of zero or more
+   parameters as defined by the Message Type.  All Message Types can
+   have attached parameters.
+
+3.2.1.  Connectionless Data Transfer (CLDT)
+
+   This message transfers data between one SUA to another.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0115          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Protocol Class                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0102          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Source Address                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0103          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Destination Address                       /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0116         |             Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Control                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0101          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         SS7 Hop Count                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+
+
+
+Loughney, et al.            Standards Track                    [Page 24]
+

+RFC 3868                          SUA                       October 2004
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0114          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Message Priority                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0013          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Correlation ID                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0117          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Segmentation                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010B          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Protocol Class                Mandatory
+     Source Address                Mandatory
+     Destination Address           Mandatory
+     Sequence Control              Mandatory
+     SS7 Hop Count                 Optional
+     Importance                    Optional
+     Message Priority              Optional
+     Correlation ID                Optional
+     Segmentation                  Optional
+     Data                          Mandatory
+
+   Implementation note: This message covers the following SCCP messages:
+   unitdata (UDT), extended unitdata (XUDT), long unitdata (LUDT).
+
+3.2.2.  Connectionless Data Response (CLDR)
+
+   This message is used as a response message by the peer to report
+   errors in the received CLDT message, when the return on error option
+   is set.
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 25]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           SCCP Cause                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0102          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Source Address                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0103          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Destination Address                       /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0101          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         SS7 Hop Count                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0114          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Message Priority                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0013          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Correlation ID                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0117          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Segmentation                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010b          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 26]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Parameters
+     Routing Context               Mandatory
+     SCCP Cause                    Mandatory
+     Source Address                Mandatory
+     Destination Address           Mandatory
+     SS7 Hop Count                 Optional
+     Importance                    Optional
+     Message Priority              Optional
+     Correlation ID                Optional
+     Segmentation                  Optional
+     Data                          Optional
+
+   Implementation note: This message covers the following SCCP messages:
+   unitdata service (UDTS), extended unitdata service (XUDTS) and long
+   unitdata service (LUDTS).
+
+3.3.  Connection Oriented Messages
+
+3.3.1.  Connection Oriented Data Transfer (CODT)
+
+   This message transfers data between one SUA to another for
+   connection-oriented service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 27]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0107          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0114          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Message Priority                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0013          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Correlation ID                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010b          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Sequence Number               Optional *1
+     Destination Reference Number  Mandatory
+     Message Priority              Optional
+     Correlation ID                Optional
+     Data                          Mandatory
+
+   NOTE *1:   This parameter is not present in case of Expedited Data
+              (ED).
+
+   Implementation note: For the CODT to represent DT1, DT2 and ED
+   messages, the following conditions MUST be met:
+
+   DT1 is represented by a CODT when:
+     Sequence Number parameter is present (contains "more" indicator).
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 28]
+

+RFC 3868                          SUA                       October 2004
+
+
+   DT2 is represented by a CODT when:
+     Sequence Number parameter is present (contains P(S), P(R) and more
+     indicator)
+
+   ED is represented by a CODT with:
+     Sequence Number parameter is not present
+
+3.3.2.  Connection Oriented Data Acknowledge (CODA)
+
+   The peer uses this message to acknowledge receipt of data.  This
+   message is used only with protocol class 3.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0108          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Receive Sequence Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010A          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Credit                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     Receive Sequence Number       Optional *1
+     Credit                        Mandatory *1
+
+   NOTE *1:    Mandatory when representing Data Acknowledgement (AK).
+
+   Implementation note: For the CODA to represent DA and EA messages,
+   the following conditions MUST be met:
+
+   DA is represented by a CODA when:
+     Receive Sequence Number parameter is present (contains P(S), P(R)
+     and more indicator)
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 29]
+

+RFC 3868                          SUA                       October 2004
+
+
+   EA is represented by a CODA when:
+     Receive Sequence Number parameter is not present
+
+3.3.3.  Connection Request (CORE)
+
+   This message is used for establishing a signalling connection between
+   two peer endpoints.
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0115          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Protocol Class                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0103          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Destination Address                       /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0116          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Control                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0107          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0102          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Source Address                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0101          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         SS7 Hop Count                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Loughney, et al.            Standards Track                    [Page 30]
+

+RFC 3868                          SUA                       October 2004
+
+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0114          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Message Priority                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010A          |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Credit                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010b          |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Protocol Class                Mandatory
+     Source Reference Number       Mandatory
+     Destination Address           Mandatory
+     Sequence Control              Mandatory
+     Sequence Number               Optional *1
+     Source Address                Optional
+     SS7 Hop Count                 Optional
+     Importance                    Optional
+     Message Priority              Optional
+     Credit                        Optional *1
+     Data                          Optional
+
+   NOTE *1:    Mandatory for protocol class 3 only.
+
+   Implementation note: This message covers the following SCCP message:
+   Connection Request (CR).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 31]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.4.  Connection Acknowledge (COAK)
+
+   This message is used to acknowledge a connection request from the
+   peer endpoint.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0115          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Protocol Class                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x01116          |            Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Control                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010A          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Credit                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0102          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Source Address                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0114          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Message Priority                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0103          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Loughney, et al.            Standards Track                    [Page 32]
+

+RFC 3868                          SUA                       October 2004
+
+
+   /                     Destination Address                       /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010b          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Protocol Class                Mandatory
+     Destination Reference Number  Mandatory
+     Source Reference Number       Mandatory
+     Sequence Control              Mandatory
+     Credit                        Mandatory *2
+     Source Address                Optional
+     Importance                    Optional
+     Message Priority              Optional
+     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.
+
+   NOTE *2:    Only applicable for protocol class 3.
+
+   Implementation note: This message covers the following SCCP message:
+   Connection Confirm (CC).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 33]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.5.  Connection Refused (COREF)
+
+   This message is used to refuse a connection request between two peer
+   endpoints.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           SCCP Cause                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0102          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Source Address                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0103          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Destination Address                       /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010B          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 34]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Parameters
+     Routing Context                    Mandatory
+     Destination Reference Number       Mandatory
+     SCCP Cause                         Mandatory
+     Source Address                     Optional
+     Destination Address                Optional *1
+     Importance                         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 REFused (CREF).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 35]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.6.  Release Request (RELRE)
+
+   This message is used to request a signalling connection between two
+   peer endpoints be released.  All associated resources can then be
+   released.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          SCCP Cause                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010b          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     Source Reference Number       Mandatory
+     SCCP Cause                    Mandatory
+     Importance                    Optional
+     Data                          Optional
+
+   Implementation note: This message covers the following SCCP message:
+   connection ReLeaSeD (RLSD).
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 36]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.7.  Release Complete (RELCO)
+
+   This message is used to acknowledge the release of a signalling
+   connection between two peer endpoints.  All associated resources
+   should be released.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0113          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Importance                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     Source Reference Number       Mandatory
+     Importance                    Optional
+
+   Implementation note: This message covers the following SCCP message:
+   ReLease Complete (RLC).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 37]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.8.  Reset Request (RESRE)
+
+   This message is used to indicate that the sending SCCP/SUA wants to
+   initiate a reset procedure (reinitialization of sequence numbers) to
+   the peer endpoint.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Source Reference Number                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           SCCP Cause                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     Source Reference Number       Mandatory
+     SCCP Cause                    Mandatory
+
+   Implementation note: This message covers the following SCCP message:
+   ReSet Request (RSR).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 38]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.9.  Reset Confirm (RESCO)
+
+   This message is used to confirm the Reset Request.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     Source Reference Number       Mandatory
+
+   Implementation note: This message covers the following SCCP message:
+   ReSet Confirmation (RSC).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 39]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.10.  Connection Oriented Error (COERR)
+
+   The COERR message is sent to indicate a protocol data unit error.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          SCCP Cause                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Destination Reference Number  Mandatory
+     SCCP Cause                    Mandatory
+
+   Implementation note: This message covers the following SCCP message:
+   Protocol Data Unit ERRor (ERR).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 40]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.3.11.  Connection Oriented Inactivity Test (COIT)
+
+   This message is used for auditing the signalling connection state and
+   the consistency of connection data at both ends of the signalling
+   connection.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0115          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Protocol Class                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0104          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0105          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0107          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010A          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Credit                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Mandatory
+     Protocol Class                Mandatory
+     Source Reference Number       Mandatory
+     Destination Reference number  Mandatory
+     Sequence Number               Mandatory *1
+     Credit                        Mandatory *1
+
+   NOTE *1:    Information in these parameter fields reflects those
+               values sent in the last data form 2 or data
+               acknowledgement message.  They are ignored if the
+               protocol class indicates class 2.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 41]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Implementation note: This message covers the following SCCP message:
+   Inactivity Test (IT).
+
+3.4.  Signalling Network Management (SNM) Messages
+
+3.4.1.  Destination Unavailable (DUNA)
+
+   In the scope of SUA, this message is covered by the PC- or N-state
+   indication passed between SCCP and local SCCP-user.  The DUNA message
+   is sent from the SG or relay node to all concerned ASPs (servicing
+   SCCP-users considered local to the SG or relay node, see chapter
+   1.3.1.1), when a destination or SCCP-user has become unreachable. The
+   SUA-User at the ASP is expected to stop traffic to the affected
+   destination or SCCP-user through the SG or relay node initiating the
+   DUNA.
+
+   The format for DUNA Message parameters is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSN                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0112          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SMI                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 42]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     SSN                           Optional *1
+     SMI                           Optional
+     Info String                   Optional
+
+   Note 1:    When the SSN is included, the DUNA message
+              corresponds to the SCCP N-STATE primitive.  When SSN
+              is not, the DUNA message corresponds to the SCCP N-PCSTATE
+              primitive.  The Affected Point Code parameter can only
+              contain one point code when SSN is present.
+
+3.4.2.  Destination Available (DAVA)
+
+   In the scope of SUA, this message is covered by the PC- and N-state
+   indication passed between SCCP and local SCCP-user.  The DAVA message
+   is sent from the SG or relay node to all concerned ASPs (servicing
+   SCCP-users considered local to the SG or relay node, see chapter
+   1.3.1.1) to indicate that a destination (PC or SCCP-user) is now
+   reachable.  The ASP SUA-User protocol is expected to resume traffic
+   to the affected destination through the SG or relay node initiating
+   the DAVA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 43]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSN                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0112          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SMI                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     SSN                           Optional *1
+     SMI                           Optional
+     Info String                   Optional
+
+   Note 1:    When the SSN is included, the DAVA message corresponds to
+              the SCCP N-STATE primitive.  When SSN is not included, the
+              DAVA message corresponds to the SCCP N-PCSTATE primitive.
+              The Affected Point Code can only contain one point code
+              when SSN is present.
+
+3.4.3.  Destination State Audit (DAUD)
+
+   The DAUD message can be sent from the ASP to the SG (or relay node)
+   to query the availability state of the routes to an affected
+   destination.  A DAUD may be sent periodically after the ASP has
+   received a DUNA, until a DAVA is received.  The DAUD can also be sent
+   when an ASP recovers from isolation from the SG (or relay node).
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 44]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSN                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010C          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           User/Cause                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     SSN                           Optional *1
+     User / Cause                  Optional
+     Info String                   Optional
+
+   Note 1:    If the SSN is present, the DAUD is "soliciting" N-STATE
+              primitives, otherwise it is "soliciting" N-PCSTATE
+              primitives.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 45]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.4.4.  Signalling Congestion (SCON)
+
+   The SCON message can be sent from the SG or relay node to all
+   concerned ASPs to indicate that the congestion level in the SS7
+   network to a specified destination has changed.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSN                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0118          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Congestion Level                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0112          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SMI                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     SSN                           Optional *1
+     Congestion Level              Mandatory
+     SMI                           Optional
+     Info String                   Optional
+
+   Note 1:    When the SSN is included, the SCON message corresponds to
+              the SCCP N-STATE primitive.  When the SSN is not
+              included, the SCON message corresponds to the SCCP
+
+
+
+Loughney, et al.            Standards Track                    [Page 46]
+

+RFC 3868                          SUA                       October 2004
+
+
+              N-PCSTATE primitive reporting signalling point or network
+              congestion status.
+
+3.4.5.  Destination User Part Unavailable (DUPU)
+
+   The DUPU message is used by an SG to inform an ASP that a remote peer
+   at an SS7 node is unavailable.
+
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010C          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           User/Cause                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                          INFO String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     User/Cause                    Mandatory
+     Info String                   Optional
+
+   Note 1:    The DUPU corresponds to the SCCP N-PCSTATE primitive.
+
+3.4.6.  Destination Restricted (DRST)
+
+   The DRST message is optionally sent from the SG to all concerned ASPs
+   to indicate that the SG has determined that one or more destinations
+   are now restricted from the point of view of the SG, or in response
+   to a DAUD message if appropriate.  The SUA layer at the ASP is
+
+
+
+Loughney, et al.            Standards Track                    [Page 47]
+

+RFC 3868                          SUA                       October 2004
+
+
+   expected to send traffic to the affected destination via an alternate
+   SG of equal priority, but only if such an alternate route exists and
+   is available.  If the ASP currently considers the affected
+   destination unavailable, the peer should be informed that traffic to
+   the affected destination could be resumed.  In this case, the SUA
+   layer should route the traffic through the SG initiating the DRST
+   message.
+
+   This message is optional for the SG to send and it is optional for
+   the ASP to act on any information received in the message.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Affected Point Code                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              SSN                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0112          |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Reserved                  |       SMI      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0004          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context               Optional
+     Affected Point Code           Mandatory *1
+     SSN                           Optional *1
+     SMI                           Optional *1
+     Info String                   Optional
+
+   Note 1:    The Affected Point Code refers to the node to which
+              become restricted or which has requested coordinated
+              service outage.  When SSN is included in the message
+
+
+
+Loughney, et al.            Standards Track                    [Page 48]
+

+RFC 3868                          SUA                       October 2004
+
+
+              parameter, the DRST message corresponds to the SCCP
+              N-COORD primitive.  If the SMI parameter is also included
+              in the message, the DRST message corresponds to the
+              N-COORD Request and N-COORD Indication primitives,
+              otherwise, the DRST message correspondence to the N-COORD
+              Response and N-COORD Confirm primitives.  The Affected
+              Point Code can only contain one point code when SSN is
+              present.  When SSN is not present, DRST corresponds to
+              N-PCSTATE primitive.
+
+3.5.  Application Server Process State Maintenance Messages
+
+3.5.1.  ASP Up (UP)
+
+   The ASP UP (UP) message is used to indicate to a remote SUA peer that
+   the Adaptation layer is up and running.
+
+    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 = 0x0011       |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        ASP Identifier                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Tag = 0x0004       |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     ASP Identifier                Optional *1
+     Info String                   Optional
+
+   Note 1:    ASP Identifier MUST be used where the IPSP/SGP cannot
+              identify the ASP by provisioned address/port number
+              information (e.g., where an ASP is resident on a Host
+              using dynamic address/port number assignment).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 49]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.5.2.  ASP Up Ack (UP ACK)
+
+   The ASP UP Ack message is used to acknowledge an ASP-Up message
+   received from a remote SUA peer.
+
+    0                     1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Tag = 0x0004       |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Info String              Optional
+
+3.5.3.  ASP Down (DOWN)
+
+   The ASP Down (DOWN) message is used to indicate to a remote SUA peer
+   that the adaptation layer is not running.
+
+    0                     1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0004        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Info String         Optional
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 50]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.5.4.  ASP Down Ack (DOWN ACK)
+
+   The ASP DOWN Ack message is used to acknowledge an ASP-Down message
+   received from a remote SUA peer.
+
+    0                     1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0004        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Info String         Optional
+
+   Note:    ASP DOWN ACK will always be sent to acknowledge an ASP DOWN.
+
+3.5.5.  Heartbeat (BEAT)
+
+   The Heartbeat message is optionally used to ensure that the SUA peers
+   are still available to each other.
+
+   The format for the BEAT message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0009        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Heartbeat Data                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Heartbeat Data      Optional
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 51]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.5.6.  Heartbeat Ack (BEAT ACK)
+
+   The Heartbeat ACK message is sent in response to a BEAT message.  A
+   peer MUST send a BEAT ACK in response to a BEAT message.  It includes
+   all the parameters of the received Heartbeat message, without any
+   change.
+
+   The format for the BEAT ACK message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0009        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Heartbeat Data                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Heartbeat Data      Optional
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 52]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.6.  ASP Traffic Maintenance Messages
+
+3.6.1.  ASP Active (ACTIVE)
+
+   The ASPAC message is sent by an ASP to indicate to a remote SUA peer
+   that it is Active and ready to process signalling traffic for a
+   particular Application Server.
+
+   The format for the ACTIVE message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x000B        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Traffic Mode Type                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0006        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0110         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           TID Label                           |
+   +-------------------------------+-------------------------------+
+   |          Tag = 0x010F         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           DRN Label                           |
+   +-------------------------------+-------------------------------+
+   |           Tag = 0x0004        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Traffic Mode Type   Optional
+     Routing Context     Optional
+     TID Label           Optional
+     DRN Label           Optional
+     Info String         Optional
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 53]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.6.2.  ASP Active Ack (ACTIVE ACK)
+
+   The ASPAC Ack message is used to acknowledge an ASP-Active message
+   received from a remote SUA peer.
+
+   The format for the ACTIVE Ack message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x000B        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Traffic Mode Type                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0006        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0004         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Traffic Mode Type   Optional
+     Routing Context     Mandatory
+     Info String         Optional
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 54]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.6.3.  ASP Inactive (INACTIVE)
+
+   The INACTIVE message is sent by an ASP to indicate to a remote SUA
+   peer that it is no longer processing signalling traffic within a
+   particular Application Server.
+
+   The format for the ASPIA message parameters is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0006        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tag = 0x0004        |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          INFO String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Parameters
+     Routing Context     Optional
+     INFO String         Optional
+
+3.6.4.  ASP Inactive Ack (INACTIVE ACK)
+
+   The INACTIVE Ack message is used to acknowledge an ASP-Inactive
+   message received from a remote SUA peer.
+
+   The format for the INACTIVE Ack message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0004         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          INFO String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 55]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Parameters
+     Routing Context     Optional
+     INFO String         Optional
+
+3.7.  SUA Management Messages
+
+   These messages are used for managing SUA and the representations of
+   the SCCP subsystems in the SUA layer.
+
+3.7.1.  Error (ERR)
+
+   The ERR message is sent between two SUA peers to indicate an error
+   situation.  The Diagnostic Information parameter is optional,
+   possibly used for error logging and/or debugging.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x000C         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Error Code                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0012          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Mask     |                 Affected PC 1                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                              ...                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Mask     |                 Affected PC n                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010D          |         Length = 8            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Network Appearance                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0007         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        Diagnostic Info                        /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 56]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Parameters
+     Error Code                    Mandatory
+     Routing Context               Mandatory *1
+     Network Appearance            Mandatory *1
+     Affected Point Code           Mandatory *1
+     Diagnostic Information        Optional
+
+   Note 1:    Only mandatory for specific error codes.
+
+3.7.2.  Notify (NTFY)
+
+   The Notify message used to provide an autonomous indication of SUA
+   events to an SUA peer.
+
+    0                     1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x000D         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Status                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Tag = 0x0011       |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        ASP Identifier                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0004         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The NTFY message contains the following parameters:
+
+   Parameters
+     Status                        Mandatory
+     ASP Identifier                Optional *1
+     Routing Context               Optional
+     Info String                   Optional
+
+   Note 1:    ASP Identifier MUST be used where the IPSP/SGP cannot
+              identify the ASP by provisioned address/port number
+              information (e.g., where an ASP is resident on a Host
+              using dynamic address/port number assignment).
+
+
+
+Loughney, et al.            Standards Track                    [Page 57]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.8.  Routing Key Management (RKM) Messages
+
+3.8.1.  Registration Request (REG REQ)
+
+   The REG REQ message is sent by an ASP to indicate to a remote SUA
+   peer that it wishes to register one or more given Routing Keys with
+   the remote peer.  Typically, an ASP would send this message to an
+   SGP, and expects to receive a REG RSP message in return with an
+   associated Routing Context value.
+
+   The format for the REG REQ message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x010E         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                         Routing Key 1                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                              ...                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x010E         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                         Routing Key n                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Tag = 0x0109       |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        ASP Capabilities                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The REG REQ message contains the following parameters:
+
+   Parameters
+     Routing Key                   Mandatory *1
+     ASP Capabilities              Optional
+
+   Note 1:   One or more Routing Key parameters MAY be included in a
+             single REG REQ message.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 58]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.8.2.  Registration Response (REG RSP)
+
+   The REG RSP message is sent by an SG to an ASP indicate the result of
+   a previous REG REQ from an ASP.  It contains indications of
+   success/failure for registration requests and returns a unique
+   Routing Context value for successful registration requests, to be
+   used in subsequent SUA Traffic Management protocol messages.
+
+   The format for the REG RSP message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0014         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Registration Result 1                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                              ...                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0014         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Registration Result n                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The REG RSP message contains the following parameters:
+
+   Parameters
+     Registration Result           Mandatory *1
+
+   Note 1:   One or more Registration Result parameters MAY be included
+             in a single REG RSP message.  The number of results in a
+             single REG RSP message can be anywhere from one to the
+             total number of Routing Key parameters found in the
+             corresponding REG REQ message.
+
+3.8.3.  Deregistration Request (DEREG REQ)
+
+   The DEREG REQ message is sent by an ASP to indicate to a remote SUA
+   peer that it wishes to deregister a given Routing Key.  Typically, an
+   ASP would send this message to an SGP, and expects to receive a DEREG
+   RSP message in return with the associated Routing Context value.
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 59]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The format for the DEREG REQ message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0006            |           Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The DEREG REQ message contains the following parameters:
+
+   Parameters
+     Routing Context               Mandatory
+
+3.8.4.  Deregistration Response (DEREG RSP)
+
+   The DEREG RSP message is used as a response to the DEREG REQ message
+   from a remote SUA peer.
+
+   The format for the DEREG RSP message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0015         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Deregistration Result 1                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                              ...                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0015         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Deregistration Result n                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The DEREG RSP message contains the following parameters:
+
+   Parameters
+     Deregistration Result         Mandatory *1
+
+   Note 1:    One or more Deregistration Result parameters MAY be
+              included in one DEREG RSP message.  The number of results
+              in a single DEREG RSP message can be anywhere from one to
+              the total number of Routing Context parameters found in
+              the corresponding DEREG REQ message.
+
+
+
+Loughney, et al.            Standards Track                    [Page 60]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.  Common Parameters
+
+   These TLV parameters are common across the different adaptation
+   layers.
+
+   Parameter Name                     Parameter ID
+   ==============                     ============
+   Reserved                             0x0000
+   Not used in SUA                      0x0001
+   Not used in SUA                      0x0002
+   Not used in SUA                      0x0003
+   Info String                          0x0004
+   Not used in SUA                      0x0005
+   Routing Context                      0x0006
+   Diagnostic Info                      0x0007
+   Not used in SUA                      0x0008
+   Heartbeat Data                       0x0009
+   Not Used in SUA                      0x000A
+   Traffic Mode Type                    0x000B
+   Error Code                           0x000C
+   Status                               0x000D
+   Not used in SUA                      0x000E
+   Not used in SUA                      0x000F
+   Not used in SUA                      0x0010
+   ASP Identifier                       0x0011
+   Affected Point Code                  0x0012
+   Correlation ID                       0x0013
+   Registration Result                  0x0014
+   Deregistration Result                0x0015
+   Registration Status                  0x0016
+   Deregistration Status                0x0017
+   Local Routing Key Identifier         0x0018
+
+3.9.1.  Not Used
+
+   Use of Parameter ID 0x0001 in SUA messages is not supported.
+
+3.9.2.  Not Used
+
+   Use of Parameter ID 0x0002 in SUA messages is not supported.
+
+3.9.3.  Not Used
+
+   Use of Parameter ID 0x0003 in SUA messages is not supported.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 61]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.4.  Info String
+
+   The optional INFO String parameter can carry any meaningful UTF-8
+   [3629] character string along with the message.  Length of the INFO
+   String parameter is from 0 to 255 octets.  No procedures are
+   presently identified for its use but service providers may use the
+   INFO String for debugging purposes.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0004         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                          Info String                          /
+
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.9.5.  Not Used in SUA
+
+   Use of Parameter ID 0x0005 in SUA messages is not supported.
+
+3.9.6.  Routing Context
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Routing Context                         /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Routing Context parameter contains (a list of) 4-byte unsigned
+   integers indexing the Application Server traffic that the sending ASP
+   is configured/registered to receive.  There is a one-to-one
+   relationship between an index entry and a Routing Key or AS Name.
+
+   An Application Server Process may be configured to process traffic
+   for more than one logical Application Server.  From the perspective
+   of an ASP, a Routing Context defines a range of signalling traffic
+   that the ASP is currently configured to receive from the SG.
+
+   Additionally, the Routing Context parameter identifies the SS7
+   network context for the message, for the purposes of logically
+   separating the signalling traffic between the SGP and the Application
+   Server Process over a common SCTP Association, when needed.  An
+   example is where an SGP is logically partitioned to appear as an
+
+
+
+Loughney, et al.            Standards Track                    [Page 62]
+

+RFC 3868                          SUA                       October 2004
+
+
+   element in several different national SS7 networks.  It implicitly
+   defines the SS7 Point Code format used, the SS7 Network Indicator
+   value and SCCP protocol type/variant/version used within a separate
+   SS7 network.  It also defines the network context for the PC and SSN
+   values.  Where an SGP operates in the context of a single SS7
+   network, or individual SCTP associations are dedicated to each SS7
+   network context, this functionality is not needed.
+
+   If the Routing Context parameter is present, it SHOULD be the first
+   parameter in the message as it defines the format and/or
+   interpretation of the parameters containing a PC or SSN value.
+
+3.9.7.  Diagnostic Information
+
+   The Diagnostic Information can be used to convey any information
+   relevant to an error condition, to assist in the identification of
+   the error condition.  In the case of an Adaptation Layer Identifier
+   or Traffic Handling Mode, the Diagnostic Information includes the
+   received parameter.  In the other cases, the Diagnostic information
+   may be the first 40 bytes of the offending message.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0007          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Diagnostic Information                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.9.8.  Not Used
+
+   Parameter ID 0x0008 is not used in SUA.
+
+3.9.9.  Heartbeat Data
+
+   The sending node defines the Heartbeat Data field contents.  It may
+   include a Heartbeat Sequence Number and/or Timestamp, or other
+   implementation specific details.
+
+   The receiver of a Heartbeat message does not process this field as it
+   is only of significance to the sender.  The receiver echoes the
+   content of the Heartbeat Data in a BEAT-Ack message.
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 63]
+

+RFC 3868                          SUA                       October 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0009          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Heartbeat Data                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The data field can be used to store information in the heartbeat
+   message useful to the sending node (e.g., the data field can contain
+   a time stamp, a sequence number, etc.).
+
+3.9.10.  Not Used
+
+   Parameter ID 0x000A is not used in SUA.
+
+3.9.11.  Traffic Mode Type
+
+   The Traffic Mode Type parameter identifies the traffic mode of
+   operation of the ASP within an AS.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x000B         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Traffic Mode Type                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The valid values for Type are shown in the following table.
+
+      1         Override
+      2         Loadshare
+      3         Broadcast
+
+   Within a Routing Context, Override, Loadshare Types and Broadcast
+   cannot be mixed.  The Override value indicates that the ASP is
+   operating in Override mode, and the ASP wishes to take over all
+   traffic for an Application Server (i.e., primary/backup operation),
+   overriding any currently active ASP in the AS.  In Loadshare mode,
+   the ASP wishes to share in the traffic distribution with any other
+   currently active ASPs.  In Broadcast mode, the ASP wishes to receive
+   the same traffic as any other currently active ASPs.  When there are
+   insufficient ASPs, the sender may immediately move the ASP to Active.
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 64]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.12.  Error Code
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Tag =0x000C            |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Error Code                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Error Code parameter indicates the reason for the Error Message.
+   The Error parameter value can be one of the following values:
+
+      0x01      Invalid Version
+      0x02      Not Used in SUA
+      0x03      Unsupported Message Class
+      0x04      Unsupported Message Type
+      0x05      Unsupported Traffic Handling Mode
+      0x06      Unexpected Message
+      0x07      Protocol Error
+      0x08      Not used in SUA
+      0x09      Invalid Stream Identifier
+      0x0a      Not used in SUA
+      0x0b      Not used in SUA
+      0x0c      Not used in SUA
+      0x0d      Refused - Management Blocking
+      0x0e      ASP Identifier Required
+      0x0f      Invalid ASP Identifier
+      0x10      Not Used in SUA
+      0x11      Invalid Parameter Value
+      0x12      Parameter Field Error
+      0x13      Unexpected Parameter
+      0x14      Destination Status Unknown
+      0x15      Invalid Network Appearance
+      0x16      Missing Parameter
+      0x17      Not Used in SUA
+      0x18      Not Used in SUA
+      0x19      Invalid Routing Context
+      0x1a      No Configured AS for ASP
+      0x1b      Subsystem Status Unknown
+      0x1c      Invalid loadsharing label
+
+   The "Invalid Version" error is sent if a message was received with an
+   invalid or unsupported version.  The Error message contains the
+   supported version in the Common header.  The Error message could
+   optionally provide the unsupported version in the Diagnostic
+   information area.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 65]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The "Unsupported Message Class" error is sent if a message with an
+   unexpected or unsupported Message Class is received.
+
+   The "Unsupported Message Type" error is sent if a message with an
+   unexpected or unsupported Message Type is received.
+
+   The "Unsupported Traffic Handling Mode" error is sent by a SGP if an
+   ASP sends an ASP Active message with an unsupported Traffic Mode Type
+   or a Traffic Mode Type that is inconsistent with the presently
+   configured mode for the Application Server.  An example would be a
+   case in which the SGP did not support loadsharing.
+
+   The "Unexpected Message" error MAY be sent if a defined and
+   recognized message is received that is not expected in the current
+   state (in some cases the ASP may optionally silently discard the
+   message and not send an Error message).  For example, silent discard
+   is used by an ASP if it received a DATA message from an SGP while it
+   was in the ASP-INACTIVE state.  If the Unexpected message contained
+   Routing Context(s), the Routing Context(s) SHOULD be included in the
+   Error message.
+
+   The "Protocol Error" error is sent for any protocol anomaly (i.e.,
+   reception of a parameter that is syntactically correct but unexpected
+   in the current situation.
+
+   The "Invalid Stream Identifier" error is sent if a message is
+   received on an unexpected SCTP stream.
+
+   The "Refused - Management Blocking" error is sent when an ASP Up or
+   ASP Active message is received and the request is refused for
+   management reasons (e.g., management lockout").  If this error is in
+   response to an ASP Active message, the Routing Context(s) in the ASP
+   Active message SHOULD be included in the Error message.
+
+   The "ASP Identifier Required" is sent by a SGP in response to an ASP
+   Up message that does not contain an ASP Identifier parameter when the
+   SGP requires one.  The ASP SHOULD resend the ASP Up message with an
+   ASP Identifier.
+
+   The "Invalid ASP Identifier" is send by a SGP in response to an ASP
+   Up message with an invalid ASP Identifier.
+
+   The "Invalid Parameter Value" error is sent if a message is received
+   with an invalid parameter value (e.g., a DUPU message was received
+   with a Mask value other than "0".
+
+   The "Parameter Field Error" would be sent if a message is received
+   with a parameter having a wrong length field.
+
+
+
+Loughney, et al.            Standards Track                    [Page 66]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The "Unexpected Parameter" error would be sent if a message contains
+   an invalid parameter.
+
+   The "Invalid Network Appearance" error is sent by a SGP if an ASP
+   sends a message with an invalid (not configured) Network Appearance
+   value.  For this error, the invalid (not configured) Network
+   Appearance MUST be included in the Network Appearance parameter.
+
+   The "Missing Parameter" error would be sent if a mandatory parameter
+   were not included in a message.
+
+   The "Invalid Routing Context" error would be sent by a SG if an ASP
+   sends a message with an invalid (not configured) Routing Context
+   value.  For this error, the invalid (not configured) Routing
+   Context(s) MUST be included in the Routing Context parameter.
+
+   The "No Configured AS for ASP" error is sent if a message is received
+   from a peer without a Routing Context parameter and it is not known
+   by configuration data, which Application Servers are referenced.
+
+   The "Destination Status Unknown" Error MAY be sent if a DAUD is
+   received at an SG inquiring of the availability or congestion status
+   of a destination, and the SG does not wish to provide the status
+   (e.g., the sender is not authorized to know the status).  For this
+   error, the invalid or unauthorized Point Code(s) MUST be included
+   along with the Network Appearance and Routing Context associated with
+   the Point Code(s).
+
+   The "Subsystem Status Unknown" Error MAY be sent if a DAUD is
+   received at an SG inquiring of the availability or congestion status
+   of a subsystem, and the SG does not wish to provide the status (e.g.,
+   the sender is not authorized to know the status).  For this error,
+   the invalid or unauthorized Point Code and Subsystem Number MUST be
+   included along with the Network Appearance and Routing Context
+   associated with the Point Code and Subsystem Number.
+
+3.9.13.  Status
+
+   The Status parameter identifies the type of the status that is being
+   notified and the Status ID.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x000D         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Status Type           |            Status ID          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Loughney, et al.            Standards Track                    [Page 67]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The valid values for Status Type (16 bit unsigned integer) are:
+
+      1     Application Server state change (AS_State_Change)
+      2     Other
+
+   The Status ID parameter contains more detailed information for the
+   notification, based on the value of the Status Type.
+
+   If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit
+   unsigned integer) values are:
+
+      1    reserved
+      2    Application Server Inactive (AS-Inactive)
+      3    Application Server Active (AS-Active)
+      4    Application Server Pending (AS-Pending)
+
+   These notifications are sent from an SGP to an ASP upon a change in
+   status of a particular Application Server.  The value reflects the
+   new state of the Application Server.
+
+   If the Status Type is "Other", then the following Status Information
+   values are defined:
+
+      1    Insufficient ASP resources active in AS
+      2    Alternate ASP Active
+      3    ASP failure
+
+   These notifications are not based on the SGP reporting the state
+   change of an ASP or AS.  In the Insufficient ASP Resources case, the
+   SGP is indicating to an "Inactive" ASP(s) in the AS that another ASP
+   is required to handle the load of the AS (Loadsharing mode or
+   Broadcast mode).  For the Alternate ASP Active case, an ASP is
+   informed when an alternate ASP transitions to the ASP-Active state in
+   Override mode.
+
+3.9.14.  Not Used in SUA
+
+   Parameter ID 0x000E is not used in SUA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 68]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.15.  Not Used in SUA
+
+   Parameter ID 0x000F is not used in SUA.
+
+3.9.16.  Not Used in SUA
+
+   Parameter ID 0x0010 is not used in SUA.
+
+3.9.17.  ASP 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 = 0x0011          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        ASP Identifier                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   ASP Identifier field: 32-bits (unsigned integer)
+
+   The ASP Identifier field contains a unique value that is locally
+   significant among the ASPs that support an AS.  The SGP should save
+   the ASP Identifier to be used, if necessary, with the Notify message
+   (see Section 3.7.2).
+
+3.9.18.  Affected Point Code
+
+   The Affected Point Code Destinations parameter contains a list of
+   Affected Point Code fields, each a three-octet parameter to allow for
+   14-, 16- and 24-bit binary formatted SS7 Point Codes.  Affected Point
+   Codes that are less than 24-bits are padded on the left to the 24-bit
+   boundary.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0012         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Mask       |                 Affected PC 1                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             . . .                             /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The encoding is shown below for ANSI and ITU Point Code examples.
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 69]
+

+RFC 3868                          SUA                       October 2004
+
+
+   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 for an implementation to generate an Affected Point
+   Code parameter with more than on Affected PC but the implementation
+   MUST accept and process an Affected Point Code parameter with more
+   than one Affected PC.
+
+   Mask: 8-bits
+
+   The Mask parameter can be used to identify a contiguous range of
+   Affected Destination Point Codes, independent of the point code
+   format.  Identifying a contiguous range of Affected PCs may be useful
+   when reception of an MTP3 management message or a linkset event
+   simultaneously affects the availability status of a series of
+   destinations at an SG.
+
+   The Mask parameter is an integer representing a bit mask that can be
+   applied to the related Affected PC field.  The bit mask identifies
+   how many bits of the Affected PC field are significant and which are
+   effectively "wild-carded".  For example, a mask of "8" indicates that
+   the last eight bits of the PC is "wild-carded".  For an ANSI 24-bit
+   Affected PC, this is equivalent to signalling that all PCs in an ANSI
+   Cluster are unavailable.  A mask of "3" indicates that the last three
+   bits of the PC is "wild-carded".  For a 14-bit ITU Affected PC, this
+   is equivalent to signalling that an ITU Region is unavailable.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 70]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.19.  Correlation ID
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0013         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Correlation ID                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Correlation ID is a 32-bit identifier that is attached to CLDT
+   messages to indicate to a newly entering ASP in a Broadcast AS where
+   in the traffic flow of CLDT messages the ASP is joining.  It is
+   attached to the first CLDT message sent to an ASP by an SG after
+   sending an ASP Active Ack or otherwise starting traffic to an ASP.
+   The Correlation ID is only significant within a Routing Context.
+
+   Implementation note: Correlation ID parameter can be used for
+   features like Synchronisation of ASPs/SGPs in a Broadcast Mode AS/SG;
+   avoid message duplication and mis-sequencing in case of failover of
+   association from one ASP/SGP to other ASP/SGP etc.
+
+3.9.20.  Registration Result
+
+    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 = 0x0018         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Routing Key Identifier                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0016         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Registration Status                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Routing Context                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Routing Key Identifier contains the same TLV formatted parameter
+   value as found in the matching Routing Key parameter in the REG REQ
+   message.
+
+   Routing Context contains the same TLV formatted Routing Context
+   parameter for the associated Routing Key if the registration was
+   successful.  It is set to "0" if the registration was not successful.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 71]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.9.21.  Deregistration Result
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0006         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Routing Context                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0017         |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Deregistration Status                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Routing Context: 32-bit integer
+
+      Routing Context contains the Routing Context value of the matching
+      Routing key to deregister, as found in the DEREG REQ message.
+
+   Deregistration Status: 32-bit integer
+
+      Deregistration Status parameter indicates the success or the
+      reason for failure of the deregistration.
+
+3.9.22.  Registration Status
+
+    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 = 0x0016      |          Length = 8             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Registration Status                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Registration Status: 32-bits (unsigned integer)
+
+      The Registration Status field indicates the success or the reason
+      for failure of a registration request.
+
+   Its values may be:
+             0           Successfully Registered
+             1           Error - Unknown
+             2           Error - Invalid Destination Address
+             3           Error - Invalid Network Appearance
+             4           Error - Invalid Routing Key
+             5           Error - Permission Denied
+             6           Error - Cannot Support Unique Routing
+             7           Error - Routing Key not Currently Provisioned
+
+
+
+Loughney, et al.            Standards Track                    [Page 72]
+

+RFC 3868                          SUA                       October 2004
+
+
+             8           Error - Insufficient Resources
+             9           Error - Unsupported RK parameter Field
+            10           Error - Unsupported/Invalid Traffic Mode Type
+            11           Error - Routing Key Change Refused
+
+3.9.23.  Deregistration Status
+
+    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 = 0x0017      |          Length = 8             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Deregistration Status                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Deregistration Status: 32-bit integer
+
+   The Deregistration Result Status field indicates the success or the
+   reason for failure of the deregistration.
+
+   Its values may be:
+
+   0           Successfully Deregistered
+   1           Error - Unknown
+   2           Error - Invalid Routing Context
+   3           Error - Permission Denied
+   4           Error - Not Registered
+   5           Error - ASP Currently Active for Routing Context
+
+3.9.24.  Local Routing Key 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 = 0x0018        |        Length = 8             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Local Routing Key Identifier                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Local Routing Key Identifier field is a 32-bits unsigned integer.
+   The Identifier value is assigned by the ASP and is used to correlate
+   the response in a REG RSP message with the original registration
+   request.  The Identifier value must remain unique until the REG RSP
+   message is received.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 73]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.  SUA-Specific parameters
+
+   These TLV parameters are specific to the SUA protocol.
+
+   Parameter Name                     Parameter ID
+   ==============                     ============
+   SS7 Hop Counter                      0x0101
+   Source Address                       0x0102
+   Destination Address                  0x0103
+   Source Reference Number              0x0104
+   Destination Reference Number         0x0105
+   SCCP Cause                           0x0106
+   Sequence Number                      0x0107
+   Receive Sequence Number              0x0108
+   ASP Capabilities                     0x0109
+   Credit                               0x010A
+   Data                                 0x010B
+   User/Cause                           0x010C
+   Network Appearance                   0x010D
+   Routing Key                          0x010E
+   DRN Label                            0x010F
+   TID Label                            0x0110
+   Address Range                        0x0111
+   SMI                                  0x0112
+   Importance                           0x0113
+   Message Priority                     0x0114
+   Protocol Class                       0x0115
+   Sequence Control                     0x0116
+   Segmentation                         0x0117
+   Congestion Level                     0x0118
+
+   Destination/Source Address Sub-Parameters
+   ===========================================
+   Global Title                         0x8001
+   Point Code                           0x8002
+   Subsystem Number                     0x8003
+   IPv4 Address                         0x8004
+   Hostname                             0x8005
+   IPv6 Addresses                       0x8006
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 74]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.1.  SS7 Hop counter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0101          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Reserved                         | SS7 Hop Count |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   SS7 Hop Counter (3.18/Q.713)
+
+   The value of the SS7 Hop Counter is decremented with each global
+   title translation and is in the range 15 to 1.
+
+3.10.2.  Source Address
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0102         |      Parameter Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Routing Indicator        |       Address Indicator       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Address parameter(s)                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The following combinations of address parameters are valid:
+
+   -  Global Title (e.g., E.164 number) + optional PC and/or SSN, SSN
+      may be zero, when routing is done on Global Title
+
+   -  SSN (non-zero) + optional PC and/or Global Title, when routing is
+      done on PC + SSN.  The PC is mandatory in the source address when
+      sending from SGP to ASP, and in the destination address when
+      sending from ASP to SGP to reach the SS7 SEP.
+
+   -  Hostname + optional SSN, when routing is done by Hostname
+
+   -  SSN (non-zero) and optional IP address (IPv4 or IPv6) when routing
+      is done on IP address + SSN
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 75]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.2.1.  Routing Indicator
+
+   The following values are valid for the routing indicator:
+
+      Reserved                      0
+      Route on Global Title         1
+      Route on SSN + PC             2
+      Route on Hostname             3
+      Route on SSN + IP Address     4
+
+   The routing indicator determines which address parameters need to be
+   present in the address parameters field.
+
+3.10.2.2.  Address Indicator
+
+   This parameter is needed for interworking with SS7 networks.  The
+   address indicator specifies what address parameters are actually
+   received in the SCCP address from the SS7 network, or are to be
+   populated in the SCCP address when the message is sent into the SS7
+   network.  The value of the routing indicator needs to be taken into
+   account.  It is used in the ASP to SG direction.  For example, the PC
+   parameter is present in the destination address of the CLDT sent from
+   ASP->SG, but bit 2 is set to "0" meaning "do not populate this in the
+   SCCP called party address".  The effect is that the SG only uses the
+   PC to populate the MTP routing label DPC field, but does not include
+   it in the SCCP called party address.
+
+   In the SG->ASP direction, the source address PC parameter is present
+   (PC of SS7 SEP).  However, this may have been populated from the OPC
+   in the received MTP routing label, not from the PC field in the SCCP
+   calling party address.  In this case, bit 2 = "0" denotes that.  The
+   AI gives further instructions to the SG how and when to populate the
+   SCCP addresses; in the SG->ASP direction, the AI gives information to
+   the ASP as to what was actually present in the received SCCP
+   addresses.
+
+   The address indicator is coded as follows:
+
+   Bit 1 is used to indicate inclusion of the SSN
+
+   0         Do not include SSN when optional
+    1         Include SSN
+
+   Bit 2 is used to indicate inclusion of the PC
+
+   0         Do not include PC, regardless of the routing indicator
+             value
+    1        Include PC
+
+
+
+Loughney, et al.            Standards Track                    [Page 76]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Bit 3 is used to indicate inclusion of the Global Title
+
+   0         Do not include GT when optional (routing indicator /= 1)
+    1        Include GT
+
+   The remaining bits are spare and SHOULD be coded zero, and MUST be
+   ignored by the receiver.
+
+3.10.2.3.  Global Title
+
+   0                 1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8001          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                Reserved                       |      GTI      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   No. Digits  | Trans. type   |    Num. Plan  | Nature of Add |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                         Global Title Digits                   /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Number of Digits:
+
+   This is the number of digits contained in the Global Title.
+
+   GTI (Global Title Indicator, defined in chapter 3.4.2.3 of Q.713).
+
+   0000     Invalid
+   0001     Nature of Address is taken over. It is implicitly assumed
+             that the Translation Type = Unknown and Numbering Plan =
+             E.164 (value 1).
+   0010     This is most commonly used in North American networks.
+             The Translation Type implicitly determines Nature of
+             Address and Numbering Plan.  This data can be configured
+             in the SG.  The number of digits is always even and
+             determined by the SCCP address length.
+   0011     Numbering Plan and Translation Type are taken over.  It is
+             implicitly assumed that the Nature of Address = Unknown.
+   0100     This format is used in international networks and most
+             commonly in networks outside North America.  All
+             information to populate the source address is present in
+             the SCCP Address.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 77]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Translation type:
+
+   0              Unknown
+   1 - 63         International services
+   64 - 127       Spare
+   128 - 254      National network specific
+   255            Reserved
+
+   Numbering Plan:
+
+   0         unknown
+   1         ISDN/telephony numbering plan (Recommendations E.163 and
+             E.164)
+   2         generic numbering plan
+   3         data numbering plan (Recommendation X.121)
+   4         telex numbering plan (Recommendation F.69)
+   5         maritime mobile numbering plan (Recommendations E.210,
+             E.211)
+   6         land mobile numbering plan (Recommendation E.212)
+   7         ISDN/mobile numbering plan (Recommendation E.214)
+   8 - 13    spare
+   14        private network or network-specific numbering plan
+   15 - 126  spare
+   127       reserved.
+
+   Nature of Address:
+
+   0         unknown
+   1         subscriber number
+   2         reserved for national use
+   3         national significant number
+   4         international number
+   5 - 255   Spare
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 78]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Global Title:
+
+   Octets contain a number of address signals and possibly filler as
+   shown:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
+   |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        .............          |filler |N addr.|   filler      |
+   |                               |if req | sig.  |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All filler bits SHOULD be set to 0.
+
+   Address signals to be coded as defined in ITU-T Q.713 Section
+   3.4.2.3.1.
+
+3.10.2.4.  Point Code
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8002          |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Point Code                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   See chapter 3.9.18 Affected Point Code for the layout of the Point
+   Code field.
+
+3.10.2.5.  Subsystem Number
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8003          |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Reserved                      |   SSN value   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The internationally standardized SSN values are described in chapter
+   3.4.2.2 of Q.713.
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 79]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.2.6.  IP Addresses
+
+   The IP address formats can use different tags.  It should be noted
+   that if the source address is in a certain IP version, the
+   destination address should also be in the same IP version.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Tag = 0x8004/0x8006      |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                        IPv4 or IPv6 Address                   /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Note:    The tag value 0x8004 is for an IPv4 address and 0x8006 is
+            for IPv6.
+
+3.10.2.7.  Hostname
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x8005          |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                           Host Name                           /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Host Name: variable length
+
+   This field contains a host name in "host name syntax" per RFC 1123
+   Section 2.1 [1123].  The method for resolving the host name is out of
+   scope for this document.
+
+   Note:    At least one null terminator is included in the Host Name
+            string and must be included in the length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 80]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.3.  Destination Address
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0103         |      Parameter Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Routing Indicator        |       Address Indicator       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Address Parameter(s)                    /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The format of this parameter is identical to the Source Address
+   parameter.
+
+3.10.4.  Source Reference Number
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0104         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Source Reference Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The source reference number is a 4 octet long integer.  This is
+   allocated by the source SUA instance.
+
+3.10.5.  Destination Reference Number
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0105         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Destination Reference Number                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The destination reference number is a 4 octet long integer.  This is
+   allocated by the destination SUA instance.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 81]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.6.  SCCP Cause
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x0106          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Reserved              |   Cause Type  |  Cause Value  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This parameter bundles the SCCP parameters Release cause, Return
+   cause, Reset cause, Error cause and Refusal cause.
+
+   Cause Type can have the following values:
+
+      Return Cause          0x1
+      Refusal Cause         0x2
+      Release Cause         0x3
+      Reset Cause           0x4
+      Error Cause           0x5
+
+   Cause Value contains the specific cause value.  Below gives examples
+   for ITU SCCP values.  ANSI references can be found in ANSI T1.112.3
+
+   Cause value in        Correspondence with Reference
+   SUA message           SCCP parameter
+   ------------------    -----------------   ---------
+   CLDR                  Return Cause        ITU-T Q.713 Chap 3.12
+   COREF                 Refusal Cause       ITU-T Q.713 Chap 3.15
+   RELRE                 Release Cause       ITU-T Q.713 Chap 3.11
+   RESRE                 Reset Cause         ITU-T Q.713 Chap 3.13
+   ERR                   Error Cause         ITU-T Q.713 Chap 3.14
+
+3.10.7.  Sequence Number
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0107         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Reserved              |  Rec Seq Num|M| Sent Seq Num  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This parameter is used to indicate whether "more" data will follow in
+   subsequent CODT messages, and/or to number each CODT message
+   sequentially for the purpose of flow control.  It contains the
+   received as well as the sent sequence number, P(R) and P(S) in Q.713,
+   chapters 3.7 and 3.9.
+
+
+
+Loughney, et al.            Standards Track                    [Page 82]
+

+RFC 3868                          SUA                       October 2004
+
+
+   As such it can also be used to acknowledge the receipt of data
+   transfers from the peer in case of protocol class 3.
+
+   Sent Sequence Number is one octet and is coded as follows:
+
+      Bits 2-8 are used to indicate the Send Sequence Number P(S).
+      Bit 1 (LSB) of octet 1 is spare.
+
+   Received Sequence Number is one octet, and is coded as follows:
+
+      Bits 2-8 are used to indicate the Received Sequence Number
+      P(R).
+      Bit 1 (LSB) is used for the more data indication, as follows:
+
+      0         no more data
+      1         more data
+
+3.10.8.  Receive Sequence Number
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0108         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Reserved                   |  Rec Seq Num  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This parameter is used exclusively for protocol class 3 in the data
+   acknowledgement message to indicate the lower edge of the receiving
+   window.  See Q.713, chapter 3.9.
+
+   It is a 1 octet long integer coded as follows:
+
+      Bits 8-2 are used to indicate the Received Sequence Number P(R).
+
+      Bit 1 is spare.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 83]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.9.  ASP Capabilities
+
+   This parameter is used so that the ASP can report its capabilities
+   regarding SUA for supporting different protocol classes and
+   interworking scenarios.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x0109         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Reserved              |0 0 0 0|a|b|c|d| Interworking  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Flags
+
+     a - Protocol Class 3
+     b - Protocol Class 2
+     c - Protocol Class 1
+     d - Protocol Class 0
+
+   It is mandatory to support at least Protocol Class 0.
+
+   Interworking
+
+   Values
+
+     0x0 indicates no interworking with SS7 Networks.
+     0x1 indicates IP Signalling Endpoint (ASP), interworking with SS7
+        networks.
+     0x2 indicates Signalling Gateway.
+     0x3 indicates relay node support.
+
+3.10.10.  Credit
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Tag = 0x010A         |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Reserved                     |     Credit     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The length of the credit field is one octet.  See ITU-T Q.713 Chapter
+   3.10.  The parameter is used for protocol class 3 exclusively.
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 84]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.11.  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 = 0x010b         |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                             Data                              /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Data parameter field contains the SS7 SCCP-User application
+   message, for example an INAP/TCAP message.
+
+3.10.12.  User/Cause
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Tag = 0x010c          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             Cause             |            User               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   "User" is coded to that SCCP's SI value.  There may be several SCCP's
+   at a given point code, each with different SI values, although
+   normally there is only one with SI = 3.
+
+   Cause may take the following values
+
+   0    remote SCCP unavailable, reason unknown;
+   1    remote SCCP unequipped;
+   2    remote SCCP inaccessible;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 85]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.13.  Network Appearance
+
+    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 = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Network Appearance                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Network Appearance field: 32-bits (unsigned integer)
+
+      The Network Appearance field identifies the SS7 network context
+      for the Routing Key.  The Network Appearance value is of local
+      significance only, coordinated between the SG and ASP.  Therefore,
+      in the case where the ASP is connected to more than one SG, the
+      same SS7 Network context may be identified by different Network
+      Appearance values depending upon to which SG the ASP is
+      registering.
+
+      In the Routing Key, the Network Appearance identifies the SS7
+      Point Code and Global Title Translation Type format used, and the
+      SCCP and possibly the SCCP-User protocol (type, variant and
+      version) used within the specific SS7 network.
+
+3.10.14.  Routing Key
+
+       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 = 0x010E          |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Tag = 0x0018          |        Length = 8             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Local Routing Key Identifier                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                         Key parameter(s)                      \
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Local Routing Key Identifier field: 32-bits (unsigned integer)
+
+      Key field: variable
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 86]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The Key field contains the following parameters:
+
+      Parameter
+         Traffic Mode Type          Optional
+         Network Appearance         Optional *1
+         Source Address             Optional
+         Destination Address        Optional
+         Address Range              Optional
+
+   Note 1:    The Network Appearance parameter must be included in the
+              Routing Key when the ASP is able to register in multiple
+              SS7 Network contexts.
+
+3.10.15.  DRN Label
+
+    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 = 0x010F         |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     start     |      end      |         label value           |
+   +---------------+---------------+-------------------------------+
+
+   The Start parameter is the start position of label, between 0 (LSB)
+   and 23 (MSB).
+
+   The End parameter is the end position of label, between 0 (LSB) and
+   23 (MSB).
+
+   Label value is a 16-bit integer, which is unique across an AS.
+
+3.10.16.  TID Label
+
+    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 = 0x0110         |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     start     |      end      |         label value           |
+   +---------------+---------------+-------------------------------+
+
+   The Start parameter is the start position of label, between 0 (LSB)
+   and 31 (MSB).
+
+   The End parameter is the end position of label, between 0 (LSB) and
+   31 (MSB).
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 87]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Label value is a 16-bit integer, which is unique across an AS.
+
+3.10.17.  Address Range
+
+    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 = 0x0111          |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                       Address parameter(s)                    \
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Address field:
+
+   The Address field the following parameters:
+
+   Parameter
+     Source Address              Optional *1
+     Destination Address         Optional *1
+
+   Note 1:    The Address field must contain pairs of Source Addresses
+              or pairs of Destination Addresses but MUST NOT mix Source
+              Addresses with Destination Addresses in the same Address
+              field.
+
+3.10.18.  SMI
+
+    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 = 0x0112          |            Length = 8         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Reserved                   |      SMI      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subsystem Multiplicity Indicator (SMI) can have the following
+   values:
+
+   0x00       Reserved/Unknown
+   0x01       Solitary
+   0x02       Duplicated
+   0x03       Triplicated
+   0x04       Quadruplicated
+   0xff       Unspecified
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 88]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.19.  Importance
+
+    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 = 0x0113          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                Reserved                       |   Importance  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Importance (3.19/Q.713)
+
+   Possible values of the Importance Parameter are between 0 and 7,
+   where the value of 0 indicates the least important and 7 indicates
+   the most important.
+
+3.10.20.  Message Priority (or Priority)
+
+    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 = 0x0114          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Reserved                         |  Msg Priority |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Priority
+
+   Priority value ranges from 0 to 3.  If the Priority value has not
+   been specified by the SCCP user, it should be set to 0xFF.  The SG
+   MAY take the priority into account for determining the MTP message
+   priority.  In the all-IP case, this parameter MAY be used.
+
+   The Message Priority parameter is optional in the CLDT, CLDR, CORE,
+   COAK and CODT messages.  However, for networks, which support Message
+   Priority (e.g., ANSI), this parameter MUST be included but it is not
+   required for those which don't (e.g., International).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 89]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.21.  Protocol Class
+
+    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 = 0x0115          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Reserved                         |  Protocol Cl. |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Protocol class (3.6/Q.713)
+
+   Bits 1-2 indicate the protocol class.
+
+      Value     Description
+        0       Class 0 (connectionless service)
+        1       Class 1 (connectionless service)
+        2       Class 2 (connection-oriented service)
+        3       Class 3 (connection-oriented service)
+
+   Bit 8 indicates the use of the return on error procedure.
+
+       Value     Description
+        0x0      No special options
+        0x1      Return message on error
+
+   Bits 3-7 are spare and SHOULD be coded zero, and MUST be
+   ignored by the receiver.
+
+3.10.22.  Sequence Control
+
+    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 = 0x0116          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence  Control         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Sequence Control (6.2.2.2.2/Q.711)
+
+   The field is coded with the value of the sequence control parameter
+   associated with a group of messages and are chosen so as to ensure
+   proper loadsharing of message groups over SLS values while ensuring
+   that sequence control values within message groups have the sequence
+   control value coded with the same value as the initial message of the
+   message group.
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 90]
+

+RFC 3868                          SUA                       October 2004
+
+
+3.10.23.  Segmentation
+
+    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 = 0x0117          |            Length = 32        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | first/remain  |             Segmentation Reference            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The first/remaining segments field is formatted as follows: bit 8
+   (MSB): indicates whether this is the first segment (1) or not (0)
+
+   bits 1-7: indicate the number of remaining segments, value between 0
+   and 15
+
+   The field would thus be coded 1000 0000 (first, no remaining
+   segments) for a unsegmented CLDT.
+
+   The segmentation reference field is a 3 byte integer, assigned by the
+   ASP.
+
+3.10.24.  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 = 0x0118          |             Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Congestion Level                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Congestion Level field: 8-bits (unsigned integer)
+
+   The Congestion Level field contains the level at which congestion has
+   occurred.
+
+   When the Congestion Level parameter is included in a SCON message
+   that corresponds to an N-PCSTATE primitive, the Congestion Level
+   field indicates the MTP congestion level experienced by the local or
+   affected signalling point as indicated by the Affected Point Code(s)
+   also in the SCON message.  In this case, valid values for the
+   Congestion Level field are as follows:
+
+      0  No Congestion or Undefined
+      1  Congestion Level 1
+      2  Congestion Level 2
+      3  Congestion Level 3
+
+
+
+Loughney, et al.            Standards Track                    [Page 91]
+

+RFC 3868                          SUA                       October 2004
+
+
+   When the Congestion Level parameter is included in a SCON message
+   that corresponds to an N-STATE primitive, the Congestion Level field
+   indicates the SCCP restricted importance level experienced by the
+   local or affected subsystem as indicated by the Affected Point Code
+   and Subsystem Number also in the SCON message. In this case, valid
+   values for the Congestion Level field range from 0 to 7, where 0
+   indicates the least congested and 7 indicates the most congested
+   subsystem.
+
+4.  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 layer.  This section describes the SUA procedures
+   in response to these events.
+
+4.1.  Procedures to Support the SUA-User Layer
+
+4.1.1.  Receipt of Primitives from SCCP
+
+   When an SCCP Subsystem Management (SCMG) message is received from the
+   SS7 network, the SGP needs to determine whether there are concerned
+   Application Servers interested in subsystem status changes.  The SUA
+   management function is informed with the N-State or N-Coord primitive
+   upon which it formats and transfers the applicable SNMM message to
+   the list of concerned ASPs using stream ID "0".
+
+   When MTP-3 Management indications are received (MTP-PAUSE, MTP-
+   RESUME, MTP-STATUS), SCCP Subsystem Management determines whether
+   there are concerned local SCCP-users.  When these local SCCP-users
+   are in fact Application Servers, serviced by ASPs, SUA management is
+   informed with the N-PCSTATE indication primitive upon which it
+   formats and transfers the applicable SNM message (DUNA, DAVA, DRST or
+   SCON) to the list of concerned ASPs using stream ID "0".
+
+   The SUA message distribution function determines the Application
+   Server (AS) based on comparing the information in the N-UNITDATA
+   request primitive with a provisioned Routing Key.
+
+   From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE
+   state is selected and a DATA message is constructed and issued on the
+   corresponding SCTP association.  If more than one ASP is in the ASP-
+   ACTIVE state (i.e., traffic is to be load-shared across more than one
+   ASP), one of the ASPs in the ASP_ACTIVE state is selected from the
+   list.  If the ASPs are in Broadcast Mode, all active ASPs will be
+   selected and the message sent to each of the active ASPs.  The
+   selection algorithm is implementation dependent but could, for
+   example, be round robin or based on the SLS.  The appropriate
+
+
+
+Loughney, et al.            Standards Track                    [Page 92]
+

+RFC 3868                          SUA                       October 2004
+
+
+   selection algorithm must be chosen carefully as it is dependent on
+   application assumptions and understanding of the degree of state
+   coordination between the ASP_ACTIVE ASPs in the AS.
+
+   In addition, the message needs to be sent on the appropriate SCTP
+   stream, again taking care to meet the message sequencing needs of the
+   signalling application.  DATA messages MUST be sent on an SCTP stream
+   other than stream '0' when there is more than one stream.
+
+   When there is no Routing Key match, or only a partial match, for an
+   incoming SS7 message, a default treatment MAY be specified.  Possible
+   solutions are to provide a default Application Server at the SGP that
+   directs all unallocated traffic to a (set of) default ASP(s), or to
+   drop the message and provide a notification to Layer Management in an
+   M-ERROR indication primitive.  The treatment of unallocated traffic
+   is implementation dependent.
+
+4.2.  Receipt of Primitives from the Layer Management
+
+   On receiving primitives from the local Layer Management, the SUA
+   layer will take the requested action and provide an appropriate
+   response primitive to Layer Management.
+
+   An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP
+   or IPSP will initiate the establishment of an SCTP association.  The
+   SUA layer will attempt to establish an SCTP association with the
+   remote SUA peer by sending an SCTP-ASSOCIATE primitive to the local
+   SCTP layer.
+
+   When an SCTP association has been successfully established, the SCTP
+   will send an SCTP-COMMUNICATION_UP notification primitive to the
+   local SUA layer.  At the ASP or IPSP that initiated the request, the
+   SUA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer
+   Management when the association setup is complete.  At the peer SUA
+   layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer
+   Management upon successful completion of an incoming SCTP association
+   setup.
+
+   An M-SCTP_RELEASE request primitive from Layer Management initiates
+   the shutdown of an SCTP association.  The SUA layer accomplishes a
+   graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN
+   primitive to the SCTP layer.
+
+   When the graceful shutdown of the SCTP association has been
+   accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE
+   notification primitive to the local SUA layer.  At the SUA Layer that
+   initiated the request, the SUA layer will send an M-SCTP_RELEASE
+   confirm primitive to Layer Management when the association shutdown
+
+
+
+Loughney, et al.            Standards Track                    [Page 93]
+

+RFC 3868                          SUA                       October 2004
+
+
+   is complete.   At the peer SUA Layer, an M-SCTP_RELEASE indication
+   primitive is sent to Layer Management upon abort or successful
+   shutdown of an SCTP association.
+
+   An M-SCTP_STATUS request primitive supports a Layer Management query
+   of the local status of a particular SCTP association.  The SUA layer
+   simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS
+   primitive to the SCTP layer.  When the SCTP responds, the SUA layer
+   maps the association status information to an M-SCTP_STATUS confirm
+   primitive.  No peer protocol is invoked.
+
+   Similar LM-to-SUA-to-SCTP and/or SCTP-to-SUA-to-LM primitive mappings
+   can be described for the various other SCTP Upper Layer primitives in
+   RFC 2960 [2960] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT,
+   REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET
+   PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK
+   STATUS CHANGE.  Alternatively, these SCTP Upper Layer primitives (and
+   Status as well) can be considered for modeling purposes as a Layer
+   Management interaction directly with the SCTP Layer.
+
+   M-NOTIFY indication and M-ERROR indication primitives indicate to
+   Layer Management the notification or error information contained in a
+   received SUA Notify or Error message respectively.  These indications
+   can also be generated based on local SUA events.
+
+   An M-ASP_STATUS request primitive supports a Layer Management query
+   of the status of a particular local or remote ASP.  The SUA layer
+   responds with the status in an M-ASP_STATUS confirm primitive.  No
+   SUA peer protocol is invoked.  An M-AS_STATUS request supports a
+   Layer Management query of the status of a particular AS.  The SUA
+   responds with an M-AS_STATUS confirm primitive.  No SUA peer protocol
+   is invoked.
+
+   M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-
+   ASP_INACTIVE request primitives allow Layer Management at an ASP to
+   initiate state changes.  Upon successful completion, a corresponding
+   confirm primitive is provided by the SUA layer to Layer Management.
+   If an invocation is unsuccessful, an Error indication primitive is
+   provided in the primitive.  These requests result in outgoing ASP Up,
+   ASP Down, ASP Active and ASP Inactive messages to the remote SUA peer
+   at an SGP or IPSP.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 94]
+

+RFC 3868                          SUA                       October 2004
+
+
+4.2.1.  Receipt of SUA Peer Management Messages
+
+   Upon successful state changes resulting from reception of ASP Up, ASP
+   Down, ASP Active and ASP Inactive messages from a peer SUA, the SUA
+   layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and
+   M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication
+   primitives to the local Layer Management.
+
+   M-NOTIFY indication and M-ERROR indication primitives indicate to
+   Layer Management the notification or error information contained in a
+   received SUA Notify or Error message.  These indications can also be
+   generated based on local SUA events.
+
+   All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack,
+   SHOULD be sent with sequenced delivery to ensure ordering.  All non-
+   Transfer messages, with the exception of ASPTM, BEAT and BEAT Ack
+   messages SHOULD be sent on SCTP stream '0'.  ASPTM messages MAY be
+   sent on one of the streams used to carry data traffic related to the
+   Routing Context(s), to minimize possible message loss.  BEAT and BEAT
+   Ack messages MAY be sent using out-of-order delivery, and MAY be sent
+   on any stream.
+
+4.3.  AS and ASP State Maintenance
+
+   The SUA layer on the SGP maintains the state of each remote ASP, in
+   each Application Server that the ASP is configured to receive
+   traffic, as input to the SUA message distribution function.
+   Similarly, where IPSPs use SUA in a point-to-point fashion, the SUA
+   layer in an IPSP maintains the state of remote IPSPs.
+
+   Two IPSP models are defined with regards to the number of messages
+   that are needed to a IPSP state change.  They are defined as follows:
+
+   1. IPSP Single Exchange (SE) model.  Only a single exchange of ASPTM
+      or ASPSM messages is needed to change the IPSP state. This means
+      that a set of request from one end and acknowledge from the other
+      will be enough.
+
+   2. IPSP Double Exchange (DE) model.  Both IPSPs have to send request
+      messages and both IPSPs have to acknowledge the request messages
+      from the other end.  This results in a double exchange of ASPTM
+      and ASPSM message, one from each end.  This configuration supports
+      dynamic routing key configuration by using RKM messages in the
+      same way as ASP-SGP scenario.
+
+   To ensure interoperability, an SUA implementation supporting IPSP
+   communication MUST support IPSP SE model and MAY implement IPSP DE
+   model.
+
+
+
+Loughney, et al.            Standards Track                    [Page 95]
+

+RFC 3868                          SUA                       October 2004
+
+
+   In section 4.3.1: ASP/IPSP States, only the SGP-ASP and the IPSP SE
+   scenarios are described.  For the IPSP DE model, both IPSPs MUST
+   follow the SGP side of the SGP-ASP procedures.
+
+   In section 4.3.2, only the SGP-ASP scenario is described.  All of the
+   procedures referring to an AS served by ASPs are also applicable to
+   ASs served by IPSPs.
+
+   In section 4.3.3, only the Management procedures for the SGP-ASP
+   scenario are described.  The corresponding Management procedures for
+   IPSPs are directly inferred.
+
+   The remaining sections contain specific IPSP Considerations
+   subsections.
+
+4.3.1.  ASP States
+
+   The state of each remote ASP/IPSP, in each AS that it is configured
+   to operate, is maintained in the peer SUA layer (i.e., in the SGP or
+   peer IPSP, respectively).  The state of a particular ASP/IPSP in a
+   particular AS changes due to events.  The events include:
+
+   * Reception of messages from the peer SUA layer at the ASP/IPSP;
+   * Reception of some messages from the peer SUA layer at other
+     ASPs/IPSPs in the AS (e.g., ASP Active message indicating
+     "Override");
+   * Reception of indications from the SCTP layer; or
+   * Local Management intervention.
+
+   The ASP/IPSP state transition diagram is shown in Figure 1.  The
+   possible states of an ASP/IPSP are:
+
+   ASP-DOWN: The remote SUA peer at the ASP/IPSP is unavailable and/or
+   the related SCTP association is down.  Initially all ASPs/IPSPs will
+   be in this state.  An ASP/IPSP in this state SHOULD NOT be sent any
+   SUA messages, with the exception of Heartbeat, ASP Down Ack and Error
+   messages.
+
+   ASP-INACTIVE: The remote SUA peer at the ASP/IPSP is available (and
+   the related SCTP association is up) but application traffic is
+   stopped.  In this state the ASP/IPSP SHOULD NOT be sent any DATA or
+   SSNM messages for the AS for which the ASP/IPSP is inactive.
+
+   ASP-ACTIVE: The remote SUA peer at the ASP/IPSP is available and
+   application traffic is active (for a particular Routing Context or
+   set of Routing Contexts).
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 96]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Figure 1: ASP/IPSP State Transition Diagram, per AS
+
+                                      +--------------+
+                                      |              |
+               +----------------------|  ASP-ACTIVE  |
+               |   Other ASP/ +-------|              |
+               |   IPSP in AS |       +--------------+
+               |   Overrides  |           ^     |
+               |              |    ASPAC/ |     | ASPIA/
+               |              |[ASPAC-Ack]|     | [ASPIA-Ack]
+               |              |           |     v
+               |              |       +--------------+
+               |              |       |              |
+               |              +------>| ASP-INACTIVE |
+               |                      |              |
+               |                      +--------------+
+               |                          ^       |
+        ASPDN/ |                          |     | ASPDN /
+   [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
+     SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
+     SCTP RI   |                          |     | SCTP RI
+               |                          |     v
+               |                      +--------------+
+               |                      |              |
+               +--------------------->|   ASP-DOWN   |
+                                      |              |
+                                      +--------------+
+
+
+   The transitions in brackets are just valid for the IPSP SE model
+   communication while the rest are valid for both ASPs and IPSPs.
+
+   SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
+   Down Indication to the Upper Layer Protocol (SUA) on an SGP.  The
+   local SCTP layer will send this indication when it detects the loss
+   of connectivity to the ASP's peer SCTP layer.  SCTP CDI is understood
+   as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
+   notification from the SCTP layer.
+
+   SCTP RI: The local SCTP layer's Restart indication to the upper layer
+   protocol (SUA) on an SG.  The local SCTP will send this indication
+   when it detects a restart from the ASP's peer SCTP layer.
+
+4.3.2.  AS States
+
+   The state of the AS is maintained in the SUA layer on the SGP.  The
+   state of an AS changes due to events.  These events include:
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 97]
+

+RFC 3868                          SUA                       October 2004
+
+
+      * 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.
+                An Application Server is in the AS-DOWN state before it
+                can be removed from a configuration.
+
+   AS-INACTIVE: The Application Server is available but no application
+                traffic is active (i.e., one or more related ASPs are in
+                the ASP-INACTIVE state, but none in the ASP-ACTIVE
+                state).  The recovery timer T(r) is not running or has
+                expired.
+
+   AS-ACTIVE :  The Application Server is available and application
+                traffic is active.  This state implies that at least one
+                ASP is in the ASP-ACTIVE state.
+
+   AS-PENDING:  An active ASP has transitioned to ASP-INACTIVE or ASP-
+                DOWN and it was the last remaining active ASP in the AS.
+                A recovery timer T(r) SHOULD be started and all incoming
+                signalling messages SHOULD be queued by the SGP.  If an
+                ASP becomes ASP-ACTIVE before T(r) expires, the AS is
+                moved to the AS-ACTIVE state and all the queued messages
+                will be sent to the ASP.
+
+   If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
+   alternative, the SGP may stop queueing messages and discard all
+   previously queued messages.  The AS will move to the AS-INACTIVE
+   state if at least one ASP is in ASP-INACTIVE state, otherwise it will
+   move to AS-DOWN state.
+
+   Figure 2 shows an example AS state machine for the case where the
+   AS/ASP data is provisioned.  For other cases where the AS/ASP
+   configuration data is created dynamically, there would be differences
+   in the state machine, especially at creation of the AS.
+
+   For example, where the AS/ASP configuration data is not created until
+   Registration of the first ASP, the AS-INACTIVE state is entered
+   directly upon the first successful REG REQ from an ASP.  Another
+   example is where the AS/ASP configuration data is not created until
+   the first ASP successfully enters the ASP-ACTIVE state.  In this case
+   the AS-ACTIVE state is entered directly.
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 98]
+

+RFC 3868                          SUA                       October 2004
+
+
+                    Figure 2: AS State Transition Diagram
+
+        +----------+   one ASP trans to ACTIVE   +-------------+
+        |    AS-   |---------------------------->|     AS-     |
+        | INACTIVE |                             |   ACTIVE    |
+        |          |<---                         |             |
+        +----------+    \                        +-------------+
+           ^   |         \ Tr Expiry,                ^    |
+           |   |          \ at least one             |    |
+           |   |           \ ASP in ASP-INACTIVE     |    |
+           |   |            \                        |    |
+           |   |             \                       |    |
+           |   |              \                      |    |
+   one ASP |   | all ASP       \            one ASP  |    | Last ACTIVE
+   trans   |   | trans to       \           trans to |    | ASP trans to
+   to      |   | ASP-DOWN        -------\   ASP-     |    | ASP-INACTIVE
+   ASP-    |   |                         \  ACTIVE   |    | or ASP-DOWN
+   INACTIVE|   |                          \          |    | (start Tr)
+           |   |                           \         |    |
+           |   |                            \        |    |
+           |   v                             \       |    v
+        +----------+                          \  +-------------+
+        |          |                           --|             |
+        | AS-DOWN  |                             | AS-PENDING  |
+        |          |                             |  (queueing) |
+        |          |<----------------------------|             |
+        +----------+    Tr Expiry and no ASP     +-------------+
+                        in ASP-INACTIVE state
+
+       Tr = Recovery Timer
+
+4.3.2.1.  IPSP Considerations
+
+   The AS state diagram for the AS-SG case is applicable for IPSP
+   communication.
+
+4.3.3.  SUA Management Procedures for Primitives
+
+   Before the establishment of an SCTP association the ASP state at both
+   the SGP and ASP is assumed to be in the state ASP-DOWN.
+
+   Once the SCTP association is established (see Section 4.2.1) and
+   assuming that the local SUA-User is ready, the local SUA ASP
+   Maintenance (ASPM) function will initiate the relevant procedures,
+   using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
+   the ASP state to the SGP (see Section 4.3.4).
+
+
+
+
+
+Loughney, et al.            Standards Track                    [Page 99]
+

+RFC 3868                          SUA                       October 2004
+
+
+   If the SUA layer subsequently receives an SCTP-COMMUNICATION_DOWN or
+   SCTP-RESTART indication primitive 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 ASP-
+   DOWN.
+
+   In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to
+   reestablish the SCTP association.  This MAY be done by the SUA layer
+   automatically, or Layer Management MAY reestablish using the M-
+   SCTP_ESTABLISH request primitive.
+
+   In the case of an SCTP-RESTART indication at an ASP, the ASP is now
+   considered by its SUA peer to be in the ASP-DOWN state.  The ASP, if
+   it is to recover, must begin any recovery with the ASP-Up procedure.
+
+4.3.4.  ASPM Procedures for Peer-to-Peer Messages
+
+4.3.4.1.  ASP Up Procedures
+
+   After an ASP has successfully established an SCTP association to an
+   SGP, the SGP waits for the ASP to send an ASP Up message, indicating
+   that the ASP SUA peer is available.  The ASP is always the initiator
+   of the ASP Up message.  This action MAY be initiated at the ASP by an
+   M-ASP_UP request primitive from Layer Management or MAY be initiated
+   automatically by an SUA management function.
+
+   When an ASP Up message is received at an SGP and internally the
+   remote ASP is in the ASP-DOWN state and not considered locked-out for
+   local management reasons, the SGP marks the remote ASP in the state
+   ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication
+   primitive.  If the SGP is aware, via current configuration data,
+   which Application Servers the ASP is configured to operate in, the
+   SGP updates the ASP state to ASP-INACTIVE in each AS that it is a
+   member.
+
+   Alternatively, the SGP may move the ASP into a pool of Inactive ASPs
+   available for future configuration within Application Server(s),
+   determined in a subsequent Registration Request or ASP Active
+   procedure.  If the ASP Up message contains an ASP Identifier, the SGP
+   should save the ASP Identifier for that ASP.  The SGP MUST send an
+   ASP Up Ack message in response to a received ASP Up message even if
+   the ASP is already marked as ASP-INACTIVE at the SGP.
+
+   If for any local reason (e.g., management lock-out) the SGP cannot
+   respond with an ASP Up Ack message, the SGP responds to an ASP Up
+   message with an Error message with Reason "Refused - Management
+   Blocking".
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 100]
+

+RFC 3868                          SUA                       October 2004
+
+
+   At the ASP, the ASP Up Ack message received is not acknowledged.
+   Layer Management is informed with an M-ASP_UP confirm primitive.
+
+   When the ASP sends an ASP Up message it starts timer T(ack).  If the
+   ASP does not receive a response to an ASP Up message within T(ack),
+   the ASP MAY restart T(ack) and resend ASP Up messages until it
+   receives an ASP Up Ack message.  T(ack) is provisioned, with a
+   default of 2 seconds.  Alternatively, retransmission of ASP Up
+   messages MAY be put under control of Layer Management.  In this
+   method, expiry of T(ack) results in an M-ASP_UP confirm primitive
+   carrying a negative indication.
+
+   The ASP must wait for the ASP Up Ack message before sending any other
+   SUA messages (e.g., ASP Active or REG REQ).  If the SGP receives any
+   other SUA messages before ASPUP message is received (other than ASPDN
+   - see section 4.3.4.2), the SGP SHOULD discard them.
+
+   If an ASP Up message is received and internally the remote ASP is in
+   the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
+   an Error message ("Unexpected Message), and the remote ASP state is
+   changed to ASP-INACTIVE in all relevant Application Servers.
+
+   If an ASP Up message is received and internally the remote ASP is
+   already in the ASP-INACTIVE state, an ASP Up Ack message is returned
+   and no further action is taken.
+
+4.3.4.1.1.  SUA Version Control
+
+   If an ASP Up message with an unsupported version is received, the
+   receiving end responds with an Error message, indicating the version
+   the receiving node supports and notifies Layer Management.
+
+   This is useful when protocol version upgrades are being performed in
+   a network.  A node upgraded to a newer version should support the
+   older versions used on other nodes it is communicating with.  Because
+   ASPs initiate the ASP Up procedure it is assumed that the Error
+   message would normally come from the SGP.
+
+4.3.4.1.2.  IPSP Considerations
+
+   An IPSP may be considered in the ASP-INACTIVE state after and ASPUP
+   or ASPUP Ack has been received from it.  An IPSP can be considered in
+   the ASP-DOWN state after an ASPDN or ASPDN Ack has been received from
+   it.  The IPSP may inform Layer Management of the change in state of
+   the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation
+   primitives.
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 101]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Alternatively, when using IPSP DE model, an interchange of ASP Up
+   messages from each end MUST be performed.  Four messages are needed
+   for completion.
+
+   If for any local reason (e.g., management lock-out) and IPSP cannot
+   respond to an ASP Up message with an ASP Up Ack message, it responds
+   to an ASP Up message with an Error message with Reason "Refused -
+   Management Blocking" and leaves the remote IPSP in the ASP-DOWN
+   state.
+
+4.3.4.2.  ASP Down Procedures
+
+   The ASP will send an ASP Down message to an SGP when the ASP wishes
+   to be removed from service in all Application Servers that it is a
+   member and no longer receive any Connectionless or Connection -
+   Oriented, SSNM or ASPTM messages.  This action MAY be initiated at
+   the ASP by an M-ASP_DOWN request primitive from Layer Management or
+   MAY be initiated automatically by an SUA management function.
+
+   Whether the ASP is permanently removed from any AS is a function of
+   configuration management.  In the case where the ASP previously used
+   the Registration procedures (see Section 4.4.1) to register within
+   Application Servers but has not deregistered from all of them prior
+   to sending the ASP Down message, the SGP MUST consider the ASP as
+   deregistered in all Application Servers that it is still a member.
+
+   The SGP marks the ASP as ASP-DOWN, informs Layer Management with an
+   M-ASP_Down indication primitive, and returns an ASP Down Ack message
+   to the ASP.
+
+   The SGP MUST send an ASP Down Ack message in response to a received
+   ASP Down message from the ASP even if the ASP is already marked as
+   ASP-DOWN at the SGP.
+
+   At the ASP, the ASP Down Ack message received is not acknowledged.
+   Layer Management is informed with an M-ASP_DOWN confirm primitive. If
+   the ASP receives an ASP Down Ack without having sent an ASP Down
+   message, the ASP should now consider itself as in the ASP-DOWN state.
+   If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state,
+   the ASP should then initiate procedures to return itself to its
+   previous state.
+
+   When the ASP sends an ASP Down message it starts timer T(ack).  If
+   the ASP does not receive a response to an ASP Down message within
+   T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until
+   it receives an ASP Down Ack message.  T(ack) is provisioned, with a
+   default of 2 seconds.  Alternatively, retransmission of ASP Down
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 102]
+

+RFC 3868                          SUA                       October 2004
+
+
+   messages MAY be put under control of Layer Management.  In this
+   method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive
+   carrying a negative indication.
+
+4.3.4.3.  ASP Active Procedures
+
+   Anytime after the ASP has received an ASP Up Ack message from the SGP
+   or IPSP, the ASP MAY send an ASP Active message to the SGP indicating
+   that the ASP is ready to start processing traffic.  This action MAY
+   be initiated at the ASP by an M-ASP_ACTIVE request primitive from
+   Layer Management or MAY be initiated automatically by an SUA
+   management function.  In the case where an ASP wishes to process the
+   traffic for more than one Application Server across a common SCTP
+   association, the ASP Active message(s) SHOULD contain a list of one
+   or more Routing Contexts to indicate for which Application Servers
+   the ASP Active message applies.  It is not necessary for the ASP to
+   include all Routing Contexts of interest in a single ASP Active
+   message, thus requesting to become active in all Routing Contexts at
+   the same time.  Multiple ASP Active messages MAY be used to activate
+   within the Application Servers independently, or in sets.  In the
+   case where an ASP Active message does not contain a Routing Context
+   parameter, the receiver must know, via configuration data, which
+   Application Server(s) the ASP is a member.
+
+   For the Application Servers that the ASP can be successfully
+   activated, the SGP or IPSP responds with one or more ASP Active Ack
+   messages, including the associated Routing Context(s) and reflecting
+   any Traffic Mode Type value present in the related ASP Active
+   message.  The Routing Context parameter MUST be included in the ASP
+   Active Ack message(s) if the received ASP Active message contained
+   any Routing Contexts.  Depending on any Traffic Mode Type request in
+   the ASP Active message, or local configuration data if there is no
+   request, the SGP moves the ASP to the correct ASP traffic state
+   within the associated Application Server(s).  Layer Management is
+   informed with an M-ASP_Active indication.  If the SGP or IPSP
+   receives any Data messages before an ASP Active message is received,
+   the SGP or IPSP MAY discard them.  By sending an ASP Active Ack
+   message, the SGP or IPSP is now ready to receive and send traffic for
+   the related Routing Context(s).  The ASP SHOULD NOT send Data or SSNM
+   messages for the related Routing Context(s) before receiving an ASP
+   Active Ack message, or it will risk message loss.
+
+   Multiple ASP Active Ack messages MAY be used in response to an ASP
+   Active message containing multiple Routing Contexts, allowing the SGP
+   or IPSP to independently acknowledge the ASP Active message for
+   different (sets of) Routing Contexts.  The SGP or IPSP MUST send an
+   Error message ("Invalid Routing Context") for each Routing Context
+   value that cannot be successfully activated.
+
+
+
+Loughney, et al.            Standards Track                   [Page 103]
+

+RFC 3868                          SUA                       October 2004
+
+
+   In the case where an "out-of-the-blue" ASP Active message is received
+   (i.e., the ASP has not registered with the SG or the SG has no static
+   configuration data for the ASP), the message MAY be silently
+   discarded.
+
+   The SGP MUST send an ASP Active Ack message in response to a received
+   ASP Active message from the ASP, if the ASP is already marked in the
+   ASP-ACTIVE state at the SGP.
+
+   At the ASP, the ASP Active Ack message received is not acknowledged.
+   Layer Management is informed with an M-ASP_ACTIVE confirm primitive.
+   It is possible for the ASP to receive Data message(s) before the ASP
+   Active Ack message as the ASP Active Ack and Data messages from an SG
+   or IPSP may be sent on different SCTP streams.  Message loss is
+   possible, as the ASP does not consider itself in the ASP-ACTIVE state
+   until reception of the ASP Active Ack message.
+
+   When the ASP sends an ASP Active message it starts timer T(ack).  If
+   the ASP does not receive a response to an ASP Active message within
+   T(ack), the ASP MAY restart T(ack) and resend ASP Active messages
+   until it receives an ASP Active Ack message.  T(ack) is provisioned,
+   with a default of 2 seconds.  Alternatively, retransmission of ASP
+   Active messages MAY be put under control of Layer Management.  In
+   this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm
+   primitive carrying a negative indication.
+
+   There are three modes of Application Server traffic handling in the
+   SGP SUA layer: Override, Loadshare and Broadcast.  When included, the
+   Traffic Mode Type parameter in the ASP Active message indicates the
+   traffic-handling mode to be used in a particular Application Server.
+   If the SGP determines that the mode indicated in an ASP Active
+   message is unsupported or incompatible with the mode currently
+   configured for the AS, the SGP responds with an Error message
+   ("Unsupported / Invalid Traffic Handling Mode").  If the traffic-
+   handling mode of the Application Server is not already known via
+   configuration data, then the traffic-handling mode indicated in the
+   first ASP Active message causing the transition of the Application
+   Server state to AS-ACTIVE MAY be used to set the mode.
+
+   In the case of an Override mode AS, reception of an ASP Active
+   message at an SGP causes the (re)direction of all traffic for the AS
+   to the ASP that sent the ASP Active message.  Any previously active
+   ASP in the AS is now considered to be in state ASP-INACTIVE and
+   SHOULD no longer receive traffic from the SGP within the AS.  The SGP
+   or IPSP then MUST send a Notify message ("Alternate ASP Active") to
+   the previously active ASP in the AS, and SHOULD stop traffic to/from
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 104]
+

+RFC 3868                          SUA                       October 2004
+
+
+   that ASP.  The ASP receiving this Notify MUST consider itself now in
+   the ASP-INACTIVE state, if it is not already aware of this via
+   inter-ASP communication with the Overriding ASP.
+
+   In the case of a Loadshare mode AS, reception of an ASP Active
+   message at an SGP or IPSP causes the direction of traffic to the ASP
+   sending the ASP Active message, in addition to all the other ASPs
+   that are currently active in the AS.  The algorithm at the SGP for
+   loadsharing traffic within an AS to all the active ASPs is
+   implementation dependent.  The algorithm could, for example, be round
+   robin or based on information in the Data message (e.g., the SLS or
+   SSN).
+
+   An SGP or IPSP, upon reception of an ASP Active message for the first
+   ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
+   active ASP until it determines that there are sufficient resources to
+   handle the expected load (e.g., until there are "n" ASPs in state
+   ASP-ACTIVE in the AS).
+
+   All ASPs within a load-sharing mode AS must be able to process any
+   Data message received for the AS, to accommodate any potential fail-
+   over or rebalancing of the offered load.
+
+   In the case of a Broadcast mode AS, reception of an ASP Active
+   message at an SGP or IPSP causes the direction of traffic to the ASP
+   sending the ASP Active message, in addition to all the other ASPs
+   that are currently active in the AS.  The algorithm at the SGP for
+   broadcasting traffic within an AS to all the active ASPs is a simple
+   broadcast algorithm, where every message is sent to each of the
+   active ASPs.  An SGP or IPSP, upon reception of an ASP Active message
+   for the first ASP in a Broadcast AS, MAY choose not to direct traffic
+   to a newly active ASP until it determines that there are sufficient
+   resources to handle the expected load (e.g., until there are "n" ASPs
+   in state ASP-ACTIVE in the AS).
+
+   Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
+   MUST tag the first DATA message broadcast in each traffic flow with a
+   unique Correlation Id parameter.  The purpose of this Correlation Id
+   is to permit the newly active ASP to synchronize its processing of
+   traffic in each traffic flow with the other ASPs in the broadcast
+   group.
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 105]
+

+RFC 3868                          SUA                       October 2004
+
+
+4.3.4.3.1.  IPSP Considerations
+
+   Either of the IPSPs can initiate communication.  When an IPSP
+   receives an ASP Active, it should mark the peer as ASP-ACTIVE and
+   return an ASP Active Ack message.  An ASP receiving an ASP Active Ack
+   message may mark the peer as ASP-Active, if it is not already in the
+   ASP-ACTIVE state.
+
+   Alternatively, when using IPSP DE model, an interchange of ASP Active
+   messages from each end MUST be performed.  Four messages are needed
+   for completion.
+
+4.3.4.4.  ASP Inactive Procedures
+
+   When an ASP wishes to withdraw from receiving traffic within an AS,
+   or the ASP wants to initiate the process of deactivation, the ASP
+   sends an ASP Inactive message to the SGP or IPSP.
+
+   An ASP Inactive message MUST be always responded by the peer
+   (although other messages may be sent in the middle):
+
+   -  If the corresponding RK is registered (statically or dynamically),
+      the peer should respond with an ASP Inactive Ack message.
+
+   -  If the RK is not registered, or the RC information is not valid,
+      the peer must respond with an ERROR message with Error Code =
+      "Invalid Routing Context".
+
+   -  If the RC is missing and its specification is needed according to
+      the used configuration, the peer must respond with an ERROR
+      message with Error Code = "No Configured AS for ASP".
+
+   The action of sending the ASP Inactive message MAY be initiated at
+   the ASP by an M-ASP_INACTIVE request primitive from Layer Management
+   or MAY be initiated automatically by an SUA management function.  In
+   the case where an ASP is processing the traffic for more than one
+   Application Server across a common SCTP association, the ASP Inactive
+   message contains one or more Routing Contexts to indicate for which
+   Application Servers the ASP Inactive message applies.
+
+   In the case where an ASP Inactive message does not contain a Routing
+   Context parameter, the receiver must know, via configuration data,
+   which Application Servers the ASP is a member and move the ASP to the
+   ASP-INACTIVE state in each all Application Servers.
+
+   In the case of an Override mode AS, where another ASP has already
+   taken over the traffic within the AS with an ASP Active ("Override")
+   message, the ASP that sends the ASP Inactive message is already
+
+
+
+Loughney, et al.            Standards Track                   [Page 106]
+

+RFC 3868                          SUA                       October 2004
+
+
+   considered by the SGP to be in state ASP-INACTIVE.  An ASP Inactive
+   Ack message is sent to the ASP, after ensuring that all traffic is
+   stopped to the ASP.
+
+   In the case of a Loadshare mode AS, the SGP moves the ASP to the
+   ASP-INACTIVE state and the AS traffic is reallocated across the
+   remaining ASPs in the state ASP-ACTIVE, as per the loadsharing
+   algorithm currently used within the AS.  A Notify message
+   ("Insufficient ASP resources active in AS") MAY be sent to all
+   inactive ASPs, if required.  An ASP Inactive Ack message is sent to
+   the ASP after all traffic is halted and Layer Management is informed
+   with an M-ASP_INACTIVE indication primitive.
+
+   In the case of a Broadcast mode AS, the SGP moves the ASP to the
+   ASP-INACTIVE state and the AS traffic is broadcast only to the
+   remaining ASPs in the state ASP-ACTIVE.  A Notify message
+   ("Insufficient ASP resources active in AS") MAY be sent to all
+   inactive ASPs, if required.  An ASP Inactive Ack message is sent to
+   the ASP after all traffic is halted and Layer Management is informed
+   with an M-ASP_INACTIVE indication primitive.
+
+   Multiple ASP Inactive Ack messages MAY be used in response to an ASP
+   Inactive message containing multiple Routing Contexts, allowing the
+   SGP or IPSP to independently acknowledge for different (sets of)
+   Routing Contexts.  The SGP or IPSP sends an Error message ("Invalid
+   Routing Context") message for each invalid or not configured Routing
+   Context value in a received ASP Inactive message.
+
+   The SGP MUST send an ASP Inactive Ack message in response to a
+   received ASP Inactive message from the ASP and the ASP is already
+   marked as ASP-INACTIVE at the SGP.
+
+   At the ASP, the ASP Inactive Ack message received is not
+   acknowledged.  Layer Management is informed with an M-ASP_INACTIVE
+   confirm primitive.  If the ASP receives an ASP Inactive Ack without
+   having sent an ASP Inactive message, the ASP should now consider
+   itself as in the ASP-INACTIVE state.  If the ASP was previously in
+   the ASP-ACTIVE state, the ASP should then initiate procedures to
+   return itself to its previous state.  When the ASP sends an ASP
+   Inactive message it starts timer T(ack).  If the ASP does not receive
+   a response to an ASP Inactive message within T(ack), the ASP MAY
+   restart T(ack) and resend ASP Inactive messages  until it receives an
+   ASP Inactive Ack message.  T(ack) is provisioned, with a default of 2
+   seconds.  Alternatively, retransmission of ASP Inactive messages MAY
+   be put under control of Layer Management.  In this method, expiry of
+   T(ack) results in a M-ASP_Inactive confirm primitive carrying a
+   negative indication.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 107]
+

+RFC 3868                          SUA                       October 2004
+
+
+   If no other ASPs in the Application Server are in the state ASP-
+   ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all of
+   the ASPs in the AS which are in the state ASP-INACTIVE.  The SGP
+   SHOULD start buffering the incoming messages for T(r) seconds, after
+   which messages MAY be discarded.  T(r) is configurable by the network
+   operator.  If the SGP receives an ASP Active message from an ASP in
+   the AS before expiry of T(r), the buffered traffic is directed to
+   that ASP and the timer is cancelled.  If T(r) expires, the AS is
+   moved to the AS-INACTIVE state.
+
+4.3.4.4.1.  IPSP Considerations
+
+   An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP
+   after an ASP Inactive or ASP Inactive Ack message has been received
+   from it.
+
+   Alternatively, when using IPSP DE model, an interchange of ASP
+   Inactive messages from each end MUST be performed.  Four messages are
+   needed for completion.
+
+4.3.4.5.  Notify Procedures
+
+   A Notify message reflecting a change in the AS state MUST be sent to
+   all ASPs in the AS, except those in the ASP-DOWN state, with
+   appropriate Status Information and any ASP Identifier of the failed
+   ASP.  At the ASP, Layer Management is informed with an M-NOTIFY
+   indication primitive.  The Notify message must be sent whether the AS
+   state change was a result of an ASP failure or reception of an ASP
+   State management (ASPSM) / ASP Traffic Management (ASPTM) message.
+   In the second case, the Notify message MUST be sent after any ASP
+   State or Traffic Management related acknowledgement messages  (e.g.,
+   ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack).
+
+   In the case where a Notify ("AS-PENDING") message is sent by an SGP
+   that now has no ASPs active to service the traffic, or where a Notify
+   ("Insufficient ASP resources active in AS") message MUST be sent in
+   the Loadshare or Broadcast mode, the Notify message does not
+   explicitly compel the ASP(s) receiving the message to become active.
+   The ASPs remain in control of what (and when) traffic action is
+   taken.
+
+   In the case where a Notify message does not contain a Routing Context
+   parameter, the receiver must know, via configuration data, of which
+   Application Servers the ASP is a member and take the appropriate
+   action in each AS.
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 108]
+

+RFC 3868                          SUA                       October 2004
+
+
+4.3.4.5.1.  IPSP Considerations (NTFY)
+
+   Notify works in the same manner as in the SG-AS case.  One of the
+   IPSPs can send this message to any remote IPSP that is not in the
+   ASP-DOWN state.
+
+4.3.4.6.  Heartbeat Procedures
+
+   The optional Heartbeat procedures MAY be used when operating over
+   transport layers that do not have their own heartbeat mechanism for
+   detecting loss of the transport association (i.e., other than SCTP).
+
+   Either SUA peer may optionally send Heartbeat messages periodically,
+   subject to a provisioned timer T(beat).  Upon receiving a Heartbeat
+   message, the SUA peer MUST respond with a Heartbeat Ack message.
+
+   If no Heartbeat Ack message (or any other SUA message) is received
+   from the SUA peer within 2*T(beat), the remote SUA peer is considered
+   unavailable.  Transmission of Heartbeat messages is stopped and the
+   signalling process SHOULD attempt to reestablish communication if it
+   is configured as the client for the disconnected SUA peer.
+
+   The Heartbeat message may optionally contain an opaque Heartbeat Data
+   parameter that MUST be echoed back unchanged in the related Heartbeat
+   Ack message.  The sender, upon examining the contents of the returned
+   Heartbeat Ack message, MAY choose to consider the remote SUA peer as
+   unavailable.  The contents/format of the Heartbeat Data parameter is
+   implementation-dependent and only of local interest to the original
+   sender.  The contents may be used, for example, to support a
+   Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a
+   timestamp mechanism (to evaluate delays).
+
+   Note: Heartbeat related events are not shown in Figure 2 "ASP state
+   transition diagram".
+
+4.4.  Routing Key Management Procedures
+
+4.4.1.  Registration
+
+   An ASP MAY dynamically register with an SGP as an ASP within an
+   Application Server using the REG REQ message.  A Routing Key
+   parameter in the REG REQ message specifies the parameters associated
+   with the Routing Key.
+
+   The SGP examines the contents of the received Routing Key parameter
+   and compares it with the currently provisioned Routing Keys.  If the
+   received Routing Key matches an existing SGP Routing Key entry, and
+   the ASP is not currently included in the list of ASPs for the related
+
+
+
+Loughney, et al.            Standards Track                   [Page 109]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Application Server, the SGP MAY authorize the ASP to be added to the
+   AS.  Or, if the Routing Key does not currently exist and the received
+   Routing Key data is valid and unique, an SGP supporting dynamic
+   configuration MAY authorize the creation of a new Routing Key and
+   related Application Server and add the ASP to the new AS.  In either
+   case, the SGP returns a Registration Response message to the ASP,
+   containing the same Local-RK-Identifier as provided in the initial
+   request, and a Registration Result "Successfully Registered".  A
+   unique Routing Context value assigned to the SGP Routing Key is
+   included.  The method of Routing Context value assignment at the SGP
+   is implementation dependent but must be guaranteed to be unique for
+   each Application Server or Routing Key supported by the SGP.  If the
+   SGP determines that the received Routing Key data is invalid, or
+   contains invalid parameter values, the SGP returns a Registration
+   Response message to the ASP, containing a Registration Result "Error
+   - Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid
+   Network Appearance" as appropriate.
+
+   If the SGP does not support the registration procedure, the SGP
+   returns an Error message to the ASP, with an error code of
+   "Unsupported Message Type".
+
+   If the SGP determines that a unique Routing Key cannot be created,
+   the SGP returns a Registration Response message to the ASP, with a
+   Registration Status of "Error - Cannot Support Unique Routing".  An
+   incoming signalling message received at an SGP should not match
+   against more than one Routing Key.
+
+   If the SGP does not authorize the registration request, the SGP
+   returns a REG RSP message to the ASP containing the Registration
+   Result "Error - Permission Denied".
+
+   If an SGP determines that a received Routing Key does not currently
+   exist and the SGP does not support dynamic configuration, the SGP
+   returns a Registration Response message to the ASP, containing a
+   Registration Result "Error - Routing Key not Currently Provisioned".
+
+   If an SGP determines that a received Routing Key does not currently
+   exist and the SGP supports dynamic configuration but does not have
+   the capacity to add new Routing Key and Application Server entries,
+   the SGP returns a Registration Response message to the ASP,
+   containing a Registration Result "Error - Insufficient Resources".
+
+   If an SGP determines that one or more of the Routing Key parameters
+   are not supported for the purpose of creating new Routing Key
+   entries, the SGP returns a Registration Response message to the ASP,
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 110]
+

+RFC 3868                          SUA                       October 2004
+
+
+   containing a Registration Result "Error - Unsupported RK parameter
+   field".  This result MAY be used if, for example, the SGP does not
+   support RK Address parameter.
+
+   A Registration Response "Error - Unsupported Traffic Handling Mode"
+   is returned if the Routing Key in the REG REQ contains a Traffic
+   Handling Mode that is inconsistent with the presently configured mode
+   for the matching Application Server.
+
+   An ASP MAY register multiple Routing Keys at once by including a
+   number of Routing Key parameters in a single REG REQ message.  The
+   SGP MAY respond to each registration request in a single REG RSP
+   message, indicating the success or failure result for each Routing
+   Key in a separate Registration Result parameter.  Alternatively the
+   SGP MAY respond with multiple REG RSP messages, each with one or more
+   Registration Result parameters.  The ASP uses the Local-RK-Identifier
+   parameter to correlate the requests with the responses.
+
+   An ASP MAY modify an existing Routing Key by including a Routing
+   Context parameter in the REG REQ.  If the SGP determines that the
+   Routing Context applies to an existing Routing Key, the SG MAY adjust
+   the existing Routing Key to match the new information provided in the
+   Routing Key parameter.  A Registration Response "Routing Key Change
+   Refused" is returned if the SGP does not accept the modification of
+   the Routing Key.
+
+   Upon successful registration of an ASP in an AS, the SGP can now send
+   related SS7 Signalling Network Management messaging, if this did not
+   previously start upon the ASP transitioning to state ASP-INACTIVE.
+
+4.4.2.  Deregistration
+
+   An ASP MAY dynamically deregister with an SGP as an ASP within an
+   Application Server using the DEREG REQ message.  A Routing Context
+   parameter in the DEREG REQ message specifies which Routing Keys to
+   deregister.  An ASP SHOULD move to the ASP-INACTIVE state for an
+   Application Server before attempting to deregister the Routing Key
+   (i.e., deregister after receiving an ASP Inactive Ack).  Also, an ASP
+   SHOULD deregister from all Application Servers that it is a member
+   before attempting to move to the ASP-Down state.
+
+   The SGP examines the contents of the received Routing Context
+   parameter and validates that the ASP is currently registered in the
+   Application Server(s) related to the included Routing Context(s).  If
+   validated, the ASP is deregistered as an ASP in the related
+   Application Server.
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 111]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The deregistration procedure does not necessarily imply the deletion
+   of Routing Key and Application Server configuration data at the SGP.
+   Other ASPs may continue to be associated with the Application Server,
+   in which case the Routing Key data SHOULD NOT be deleted.  If a
+   Deregistration results in no more ASPs in an Application Server, an
+   SGP MAY delete the Routing Key data.
+
+   The SGP acknowledges the deregistration request by returning a DEREG
+   RSP message to the requesting ASP.  The result of the deregistration
+   is found in the Deregistration Result parameter, indicating success
+   or failure with cause.
+
+   An ASP MAY deregister multiple Routing Contexts at once by including
+   a number of Routing Contexts in a single DEREG REQ message.  The SGP
+   MAY respond to each deregistration request in a single DEREG RSP
+   message, indicating the success or failure result for each Routing
+   Context in a separate Deregistration Result parameter.
+
+4.4.3.  IPSP Considerations (REG/DEREG)
+
+   The Registration/Deregistration procedures work in the IPSP cases in
+   the same way as in AS-SG cases.  An IPSP may register an RK in the
+   remote IPSP.  An IPSP is responsible for deregistering the RKs that
+   it has registered.
+
+4.5.  Availability and/or Congestion Status of SS7 Destination Support
+
+4.5.1.  At an SGP
+
+   On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive
+   from the nodal interworking function at an SGP, the SGP SUA layer
+   will send a corresponding SS7 Signalling Network Management (SNM)
+   DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers
+   at concerned ASPs.  The SUA layer must fill in various fields of the
+   SNM messages consistently with the information received in the
+   primitives.
+
+   The SGP SUA layer determines the set of concerned ASPs to be informed
+   based on the specific SS7 network for which the primitive indication
+   is relevant.  In this way, all ASPs configured to send/receive
+   traffic within a particular network appearance are informed.  If the
+   SGP operates within a single SS7 network appearance, then all ASPs
+   are informed.
+
+   DUNA, DAVA, SCON, and DRST messages are sent sequentially and
+   processed at the receiver in the order sent.  SCTP stream 0 SHOULD
+   NOT be used.  The Unordered bit in the SCTP DATA chunk MAY be used
+   for the SCON message.
+
+
+
+Loughney, et al.            Standards Track                   [Page 112]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Sequencing is not required for the DUPU or DAUD messages, which MAY
+   be sent unordered.  SCTP stream 0 is used, with optional use of the
+   Unordered bit in the SCTP DATA chunk.
+
+4.5.2.  At an ASP
+
+4.5.2.1.  Single SG Configurations
+
+   At an ASP, upon receiving an SS7 Signalling Network Management (SSNM)
+   message from the remote SUA Peer, the SUA layer invokes the
+   appropriate primitive indications to the resident SUA-Users.  Local
+   management is informed.
+
+   In the case where a local event has caused the unavailability or
+   congestion status of SS7 destinations, the SUA layer at the ASP
+   SHOULD pass up appropriate indications in the primitives to the SUA
+   User, as though equivalent SSNM messages were received.  For example,
+   the loss of an SCTP association to an SGP may cause the
+   unavailability of a set of SS7 destinations.  N-PCSTATE indication
+   primitives to the SUA User are appropriate.
+
+   Implementation Note: To accomplish this, the SUA layer at an ASP
+   maintains the status of routes via the SG.
+
+4.5.2.2.  Multiple SG Configurations
+
+   At an ASP, upon receiving a Signalling Network Management message
+   from the remote SUA Peer, the SUA layer updates the status of the
+   affected route(s) via the originating SG and determines, whether or
+   not the overall availability or congestion status of the effected
+   destination(s) has changed.  If so, the SUA layer invokes the
+   appropriate primitive indications to the resident SUA-Users.  Local
+   management is informed.
+
+4.5.3.  ASP Auditing
+
+   An ASP may optionally initiate an audit procedure to inquire of an
+   SGP the availability and, if the national congestion method with
+   multiple congestion levels and message priorities is used, congestion
+   status of an SS7 destination or set of destinations.  A Destination
+   Audit (DAUD) message is sent from the ASP to the SGP requesting the
+   current availability and congestion status of one or more SS7
+   destinations or subsystems.
+
+   The DAUD message MAY be sent unordered.  The ASP MAY send the DAUD in
+   the following cases:
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 113]
+

+RFC 3868                          SUA                       October 2004
+
+
+   - Periodic.  A Timer originally set upon reception of a DUNA, SCON or
+                DRST message has expired without a subsequent DAVA,
+                DUNA, SCON or DRST message updating the
+                availability/congestion status of the affected
+                Destination Point Code.  The Timer is reset upon issuing
+                a DAUD.  In this case the DAUD is sent to the SGP that
+                originally sent the SSNM message.
+
+   - Isolation. The ASP is newly ASP-ACTIVE or has been isolated from an
+                SGP for an extended period.  The ASP MAY request the
+                availability/congestion status of one or more SS7
+                destinations to which it expects to communicate.
+
+   Implementation Note:
+
+      In the first of the cases above, the auditing procedure must not
+      be invoked for the case of a received SCON message containing a
+      congestion level value of "no congestion" or undefined" (i.e.,
+      congestion Level = "0").  This is because the value indicates
+      either congestion abatement or that the ITU MTP3 international
+      congestion method is being used.  In the international congestion
+      method, the MTP3 layer at the SGP does not maintain the congestion
+      status of any destinations and therefore the SGP cannot provide
+      any congestion information in response to the DAUD.  For the same
+      reason, in the second of the cases above a DAUD message cannot
+      reveal any congested destination(s).
+
+   The SGP SHOULD respond to a DAUD message with the availability and
+   congestion status of the subsystem.  The status of each SS7
+   destination or subsystem requested is indicated in a DUNA message (if
+   unavailable), a DAVA message (if available), or a DRST (if restricted
+   and the SGP supports this feature).  If the SS7 destination or
+   subsystem is available and congested, the SGP responds with an SCON
+   message in addition to the DAVA message.  If the SS7 destination or
+   subsystem is restricted and congested, the SGP responds with an SCON
+   message in addition to the DRST.  If the SGP has no information on
+   the availability / congestion status of the SS7 destination or
+   subsystem, the SGP responds with a DUNA message, as it has no routing
+   information to allow it to route traffic to this destination or
+   subsystem.
+
+   An SG MAY refuse to provide the availability or congestion status of
+   a destination or subsystem if, for example, the ASP is not authorized
+   to know the status of the destination or subsystem.  The SG MAY
+   respond with an Error Message (Error Code = "Destination Status
+   Unknown") or Error Message (Error Code = "Subsystem Status Unknown").
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 114]
+

+RFC 3868                          SUA                       October 2004
+
+
+4.6.  MTP3 Restart
+
+   In the case where the MTP3 in the SG undergoes an MTP restart, event
+   communication SHOULD be handled as follows:
+
+   When the SG discovers SS7 network isolation, the SGPs send an
+   indication to all concerned available ASPs (i.e., ASPs in the ASP-
+   ACTIVE state) using DUNA messages for the concerned destinations.
+   When the SG has completed the MTP Restart procedure, the SUA layer at
+   the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
+   available/restricted SS7 destinations using the DAVA/DRST message.
+   No message is necessary for those destinations still unavailable
+   after the restart procedure.
+
+   When the SUA layer at an ASP receives a DUNA message indicating SS7
+   destination unavailability at an SG, SCCP Users will receive an N-
+   PCSTATE indication and will stop any affected traffic to this
+   destination.  When the SUA receives a DAVA/DRST message, SCCP Users
+   will receive an N-PCSTATE indication and can resume traffic to the
+   newly available SS7 destination via this SGP, provided the ASP is in
+   the ASP-ACTIVE state toward this SGP.
+
+   The ASP MAY choose to audit the availability of unavailable
+   destinations by sending DAUD messages.  This would be for example the
+   case when an AS becomes active at an ASP and does not have current
+   destination statuses.  If MTP restart is in progress at the SG, the
+   SGP returns a DUNA message for that destination, even if it received
+   an indication that the destination became available or restricted.
+
+4.7.  SCCP - SUA Interworking at the SG
+
+4.7.1.  Segmenting / Reassembly
+
+   When it is expected that signalling messages will not fit into a PDU
+   of the most restrictive transport technology used (e.g., 272-SIF of
+   MTP3), then segmenting/reassembly could be performed at the SG, ASP
+   or IPSP.  If the SG, ASP or IPSP is incapable of performing a
+   necessary segmentation/reassembly, it can inform the peer of the
+   failure using the appropriate error in a CLDR or RESRE/COERR message.
+
+4.7.2.  Support for Loadsharing
+
+   Within an AS (identified by RK/RC parameters) several loadsharing
+   ASPs may be active.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 115]
+

+RFC 3868                          SUA                       October 2004
+
+
+   However, to assure the correct processing of TCAP transactions or
+   SCCP connections, the loadsharing scheme used at the SG must make
+   sure that messages continuing or ending the transactions/connections
+   arrive at the same ASP where the initial message (TC_Query, TC_Begin,
+   CR) was sent to/received from.
+
+   When the ASP can be identified uniquely based on RK parameters (e.g.,
+   unique DPC or GT), loadsharing is not required.  When the ASPs in the
+   AS share state or use an internal distribution mechanism, the SG must
+   only take into account the in-sequence-delivery requirement.  In case
+   of SCCP CO traffic, when the coupled approach is used, loadsharing of
+   messages other than CR is not required.
+
+   If these assumptions cannot be made, both SG and ASP should support
+   the following general procedure in a loadsharing environment.
+
+4.7.2.1.  Association Setup, ASP going active
+
+   After association setup and registration, an ASP normally goes active
+   for each AS it registered for.  In the ASPAC message, the ASP
+   includes a TID and/or DRN Label Parameter, if applicable for the AS
+   in question.  All the ASPs within the AS must specify a unique label
+   at a fixed position in the TID or DRN parameter.  The same ASPAC
+   message is sent to each SG used for interworking with the SS7
+   network.
+
+   The SG builds, per RK, a list of ASPs that have registered for it.
+   The SG can now build up and update a distribution table for a certain
+   Routing Context, any time the association is (re-)established and the
+   ASP goes active.  The SG has to perform some trivial plausibility
+   checks on the parameters:
+
+   - Start and End parameters values are between 0 and 31 for TID.
+   - Start and End parameters values are between 0 and 23 for DRN
+   - 0 < (Start - End + 1) <= 16 (label length maximum 16-bit)
+   - Start values are the same for each ASP within a RC
+   - End values are the same for each ASP within a RC
+   - TID and DRN Label values must be unique across the RC
+
+   If any of these checks fail, the SG refuses the ASPAC request, with
+   an error, "Invalid loadsharing label."
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 116]
+

+RFC 3868                          SUA                       October 2004
+
+
+4.7.3.  Routing and message distribution at the SG
+
+4.7.3.1.  TCAP traffic
+
+   Messages not containing a destination (or "responding") TID, i.e.,
+   Query, Begin, Unidirectional, are loadshared among the available
+   ASPs.  Any scheme permitting a fair load distribution among the ASPs
+   is allowed (e.g., round robin).
+
+   When a destination TID is present, the SG extracts the label and
+   selects the ASP that corresponds with it.
+
+   If an ASP is not available, the SG may generate (X)UDTS "routing
+   failure", if the return option is used.
+
+4.7.3.2.  SCCP Connection Oriented traffic
+
+   Messages not containing a destination reference number (DRN), i.e., a
+   Connection Request, MAY be loadshared among the available ASPs.  The
+   load distribution mechanism is an implementation issue.  When a DRN
+   is present, the SG extracts the label and selects the ASP that
+   corresponds with it.  If an ASP is not available, the SG discards the
+   message.
+
+4.7.4.  Multiple SGs, SUA Relay Function
+
+   It is important that each ASP send its unique label (within the AS)
+   to each SGP.  For a better robustness against association failures,
+   the SGs MAY cooperate to provide alternative routes toward an ASP.
+   Mechanisms for SG cooperation/coordination are outside of the scope
+   of this document.
+
+5.  Examples of SUA Procedures
+
+   The following sequence charts overview the procedures of SUA.  These
+   are meant as examples, they do not, in and of themselves, impose
+   additional requirements upon an instance of SUA.
+
+5.1.  SG Architecture
+
+   The sequences below outline logical steps for a variety of scenarios
+   within a SG architecture.  Please note that these scenarios cover a
+   Primary/Backup configuration.  Where there is a load-sharing
+   configuration then the SGP can declare availability when 1 ASP issues
+   ASPAC but can only declare unavailability when all ASPs have issued
+   ASPIA.
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 117]
+

+RFC 3868                          SUA                       October 2004
+
+
+5.1.1.  Establishment of SUA connectivity
+
+   The following is established before traffic can flow.
+
+   Each node is configured (via MIB, for example) with the connections
+   that need to be setup.
+
+    ASP-a1            ASP-a2                SG                  SEP
+   (Primary)           (Backup)
+      |------Establish SCTP Association------|
+                         |--Estab. SCTP Ass--|
+                                             |--Align SS7 link---|
+      +----------------ASP Up---------------->
+      <--------------ASP Up Ack--------------+
+                         +------ASP Up------->
+                         <---ASP Up Ack------+
+      +-------------ASP Active--------------->
+      <----------ASP Active Ack--------------+
+      <----------NTFY (ASP Active)-----------+
+                         <-NTFY (ASP Active)-+
+                                             +--------SSA-------->
+                                             <--------SSA--------+
+      <-----------------DAVA-----------------+
+      +-----------------CLDT----------------->
+                                             +--------UDT-------->
+
+5.1.2.  Fail-over scenarios
+
+   The following sequences address fail-over of SEP and ASP.
+
+5.1.2.1.  SEP Fail-over
+
+   The SEP knows that the SGP is 'concerned' about its availability.
+   Similarly, the SGP knows that ASP-a1 is concerned about the SEPs
+   availability.
+
+     ASP-a1            ASP-a2                SG                  SEP
+   (Primary)           (Backup)
+                                              <--------SSP--------+
+       <-----------------DUNA-----------------+
+       +-----------------DAUD----------------->
+                                              +--------SST-------->
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 118]
+

+RFC 3868                          SUA                       October 2004
+
+
+5.1.2.2.  Successful ASP Fail-over scenario
+
+   The following is an example of a successful fail-over scenario, where
+   there is a fail-over from ASP-a1 to ASP-a2, i.e., Primary to Backup.
+   During the fail-over, the SGP buffers any incoming data messages from
+   the SEP, forwarding them when the Backup becomes available.
+
+     ASP-a1            ASP-a2                SG                  SEP
+   (Primary)           (Backup)
+       +-------------ASP Inactive------------->
+       <-----------ASP Inactive ACK-----------+
+       <--------------------NTFY (AS Pending)-+
+                          <-NTFY (AS Pending)-+
+                          +----ASP Active----->
+                          <--ASP Active Ack---+
+                          <-NTFY (AS Active)--+
+       <----------NTFY (AS Active)------------+
+
+5.1.2.3.  Unsuccessful ASP Fail-over scenario
+
+     ASP-a1            ASP-a2                SG                  SEP
+   (Primary)           (Backup)
+       +-------------ASP Inactive------------->
+       <-----------ASP Inactive ACK-----------+
+       <--------------------NTFY (AS Pending)-+
+                         <--NTFY (AS Pending)-+
+             After some time elapses (i.e., timeout).
+                                              +--------SSP-------->
+                                              <--------SST--------+
+       <-------------------NTFY (AS Inactive)-+
+                         <-NTFY (AS Inactive)-+
+
+5.2.  IPSP Examples
+
+   The sequences below outline logical steps for a variety of scenarios
+   within an IP-IP architecture.  Please note that these scenarios cover
+   a Primary/Backup configuration.  Where there is a load-sharing
+   configuration then the AS can declare availability when 1 ASP issues
+   ASPAC but can only declare unavailability when all ASPs have issued
+   ASPIA.
+
+5.2.1.  Establishment of SUA connectivity
+
+   The following shows an example establishment of SUA connectivity. In
+   this example, each IPSP consists of an Application Server and two
+   ASPs.  The following is established before SUA traffic can flow.  A
+   connectionless flow is shown for simplicity.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 119]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Establish SCTP Connectivity - as per RFC 2960.  Note that SCTP
+   connections are bidirectional.  The endpoint that establishes SCTP
+   connectivity MUST also establish UA connectivity (see RFC 2960,
+   section 5.2.1 for handling collisions) [2960].
+
+   IP SEP A                                                  IP SEP B
+   AS A                                                          AS B
+   ASP-a1     ASP-a2                                 ASP-b2    ASP-b1
+
+   [All ASPs are in the ASP-DOWN state]
+
+   +-------------------------------ASP Up-------------------------->
+   <-----------------------------ASP Up Ack------------------------+
+
+                 +--------------ASP Up--------------->
+                 <------------ASP Up Ack-------------+
+
+   +---------------------------ACTIVE------------------------------->
+   <-------------------------ACTIVE Ack-----------------------------+
+
+   [Traffic can now flow directly between ASPs]
+
+   +-----------------------------CLDT------------------------------->
+
+5.2.2.  Fail-over scenarios
+
+   The following sequences address fail-over of ASP.
+
+5.2.2.1.  Successful ASP Fail-over scenario
+
+   The following is an example of a successful fail-over scenario, where
+   there is a fail-over from ASP-a1 to ASP-a2, i.e., Primary to Backup.
+   Since data transfer passes directly between peer ASPs, ASP-b1 is
+   notified of the fail-over of ASP-a1 and buffers outgoing data
+   messages until ASP-a2 becomes available.
+
+   IP SEP A                                                  IP SEP B
+   ASP-a1     ASP-a2                                 ASP-b2    ASP-b1
+
+   +-----------------------------ASP Inact------------------------>
+   <---------------------------ASP Inact Ack----------------------+
+              <---------------NTFY (ASP-a1 Inactive)--------------+
+              +---------------------ASP Act----------------------->
+              <-------------------ASP Act Ack---------------------+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 120]
+

+RFC 3868                          SUA                       October 2004
+
+
+5.2.2.2.  Unsuccessful ASP Fail-over scenario
+
+   The sequence is the same as 5.2.2.1 except that, since the backup
+   fails to come in then, the Notify messages declaring the availability
+   of the backup are not sent.
+
+6.  Security Considerations
+
+   The security considerations discussed for the 'Security
+   Considerations for SIGTRAN Protocols' [3788] document apply to this
+   document.
+
+7.  IANA Considerations
+
+7.1.  SCTP Payload Protocol ID
+
+   IANA has assigned a SUA value for the Payload Protocol Identifier in
+   the SCTP DATA chunk.  The following SCTP Payload Protocol Identifier
+   is registered:
+
+      SUA    "4"
+
+   The SCTP Payload Protocol Identifier value "4" SHOULD be included in
+   each SCTP DATA chunk, to indicate that the SCTP is carrying the SUA
+   protocol.  The value "0" (unspecified) is also allowed but any other
+   values MUST not be used.  This Payload Protocol Identifier is not
+   directly used by SCTP but MAY be used by certain network entities to
+   identify the type of information being carried in a DATA chunk.
+
+   The User Adaptation peer MAY use the Payload Protocol Identifier, as
+   a way of determining additional information about the data being
+   presented to it by SCTP.
+
+7.2.  Port Number
+
+   IANA has registered SCTP Port Number 14001 for SUA.  It is
+   recommended that SGPs use this SCTP port number for listening for new
+   connections.  SGPs MAY also use statically configured SCTP port
+   numbers instead.
+
+7.3.  Protocol Extensions
+
+   This protocol may also be extended through IANA in three ways:
+
+   -  Through definition of additional message classes.
+   -  Through definition of additional message types.
+   -  Through definition of additional message parameters.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 121]
+

+RFC 3868                          SUA                       October 2004
+
+
+   The definition and use of new message classes, types and parameters
+   is an integral part of SIGTRAN adaptation layers.  Thus, these
+   extensions are assigned by IANA through an IETF Consensus action as
+   defined in [2434].
+
+   The proposed extension MUST in no way adversely affect the general
+   working of the protocol.
+
+   A new registry has been created by IANA to allow the protocol to be
+   extended.
+
+7.3.1.  IETF Defined Message Classes
+
+   The documentation for a new message class MUST include the following
+   information:
+
+   (a) A long and short name for the message class;
+   (b) A detailed description of the purpose of the message class.
+
+7.3.2.  IETF Defined Message Types
+
+   Documentation of the message type MUST contain the following
+   information:
+
+   (a) A long and short name for the new message type;
+   (b) A detailed description of the structure of the message.
+   (c) A detailed definition and description of intended use of each
+       field within the message.
+   (d) A detailed procedural description of the use of the new message
+       type within the operation of the protocol.
+   (e) A detailed description of error conditions when receiving this
+       message type.
+
+   When an implementation receives a message type which it does not
+   support, it MUST respond with an Error (ERR) message, with an Error
+   Code = Unsupported Message Type.
+
+7.3.4.  IETF-defined TLV Parameter Extension
+
+   Documentation of the message parameter MUST contain the following
+   information:
+
+   (a) Name of the parameter type.
+   (b) Detailed description of the structure of the parameter field.
+       This structure MUST conform to the general type-length-value
+       format described earlier in the document.
+   (c) Detailed definition of each component of the parameter value.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 122]
+

+RFC 3868                          SUA                       October 2004
+
+
+   (d) Detailed description of the intended use of this parameter type,
+       and an indication of whether and under what circumstances
+       multiple instances of this parameter type may be found within the
+       same message type.
+
+8.  Timer Values
+
+   Ta                                      2 seconds
+   Tr                                      2 seconds
+   T(ack)                                  2 seconds
+   T(ias)    Inactivity Send timer         7 minutes
+   T(iar)    Inactivity Receive timer      15 minutes
+   T(beat)   Heartbeat Timer               30 seconds
+
+9.  Acknowledgements
+
+   The authors would like to thank (in alphabetical order) Richard
+   Adams, Javier Pastor-Balbas, Andrew Booth, Martin Booyens, F.
+   Escobar, S. Furniss Klaus Gradischnig, Miguel A. Garcia, Marja-Liisa
+   Hamalainen, Sherry Karl, S. Lorusso, Markus Maanoja, Sandeep Mahajan,
+   Ken Morneault, Guy Mousseau, Chirayu Patel, Michael Purcell, W.
+   Sully, Michael Tuexen, Al Varney, Tim Vetter, Antonio Villena, Ben
+   Wilson, Michael Wright and James Yu for their insightful comments and
+   suggestions.
+
+10.  References
+
+10.1.  Normative References
+
+   [1123]         Braden, R., Ed., "Requirements for Internet Hosts -
+                  Application and Support", STD 3, RFC 1123, October
+                  1989.
+
+   [2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [2960]         Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+                  Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
+                  Zhang, L., and V. Paxson, "Stream Control Transmission
+                  Protocol", RFC 2960, October 2000.
+
+   [3629]         Yergeau, F., "UTF-8, a transformation format of ISO
+                  10646", STD 63, RFC 3629, November 2003.
+
+   [3788]         Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas,
+                  "Security Considerations for Signaling Transport
+                  (SIGTRAN) Protocols", RFC 3788, June 2004.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 123]
+

+RFC 3868                          SUA                       October 2004
+
+
+   [ANSI SCCP]    ANSI T1.112 "Signalling System Number 7 - Signalling
+                  Connection Control Part".
+
+   [ITU SCCP]     ITU-T Recommendations Q.711-714, "Signalling System
+                  No. 7 (SS7) - Signalling Connection Control Part
+                  (SCCP)."  ITU-T Telecommunication Standardization
+                  Sector of ITU, formerly CCITT, Geneva (July 1996).
+
+10.2.  Informative References
+
+   [2434]         Narten, T. and H. Alvestrand, "Guidelines for Writing
+                  an IANA Considerations Section in RFCs", BCP 26, RFC
+                  2434, October 1998.
+
+   [2719]         Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H.,
+                  Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C.
+                  Sharp, "Framework Architecture for Signalling
+                  Transport", RFC 2719, October 1999.
+
+   [3761]         Falstrom, P. and M. Mealling, "The E.164 to Uniform
+                  Resource Identifiers (URI) Dynamic Delegation
+                  Discovery System (DDDS) Application (ENUM)", RFC 3761,
+                  April 2004.
+
+   [ANSI TCAP]    ANSI T1.114 'Signalling System Number 7 - Transaction
+                  Capabilities Application Part'
+
+   [ITU TCAP]     ITU-T Recommendation Q.771-775 'Signalling System No.
+                  7 SS7) - Transaction Capabilities (TCAP).'
+
+   [RANAP]        3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification
+                  3rd Generation Partnership Project; Technical
+                  Specification Group Radio Access Network; UTRAN Iu
+                  Interface RANAP Signalling'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 124]
+

+RFC 3868                          SUA                       October 2004
+
+
+Appendix A.  Signalling Network Architecture
+
+A.1.  Generalized Peer-to-Peer Network Architecture
+
+   Figure 3 shows an example network architecture that can support
+   robust operation and fail-over.  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 3: 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.  This is out of
+   scope of this protocol.  Additionally, in a distributed system, one
+   ASP could be registered to more than one AS.  This document should
+   not restrict such systems - though such a case in not specified.
+
+
+
+Loughney, et al.            Standards Track                   [Page 125]
+

+RFC 3868                          SUA                       October 2004
+
+
+A.2.  Signalling Gateway Network Architecture
+
+   When interworking between SS7 and IP domains is needed, the SGP acts
+   as the gateway node between the SS7 network and the IP network.  The
+   SGP will transport SCCP-user signalling traffic from the SS7 network
+   to the IP-based signalling nodes (for example IP-resident Databases).
+   The Signalling Gateway can be considered as a group of Application
+   Servers with additional functionality to interface toward 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.
+
+   An ASP may be connected to multiple SGPs (see figure 4).  In such a
+   case, a particular SS7 destination may be reachable via more than SG,
+   therefore, more than one route.  Given that proper SLS selection,
+   loadsharing, and SG selection based on point code availability is
+   performed at the ASP, it will be necessary for the ASP to maintain
+   the status of each distant SGPs to which it communicates on the basis
+   of the SG through which it may route.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 126]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Signalling Gateway
+                            SCTP Associations
+      +----------+                                       **************
+      | SG1      |                                       *  AS3       *
+      | ******** |                                       *  ********  *
+      | * SGP11+--------------------------------------------+ ASP1 *  *
+      | ******** |                                 /     *  ********  *
+      | ******** |                                 |     *  ********  *
+      | * SGP12+--------------------------------------------+ ASP2 *  *
+      | ******** |                   \           / |     *  ********  *
+      +----------+                    \          | |     *      .     *
+                                       \         | |     *      .     *
+      +----------                       \        | |     *      .     *
+      | SG2      |                       \       | |     *      .     *
+      | ******** |                        \      | |     *  ********  *
+      | * SGP21+---------------------------------+-+     *  * ASPN *  *
+      | ******** |                          \            *  ********  *
+      | ******** |                           \           **************
+      | * SGP22+---+--+                       \
+      | ******** | |  |                        \         **************
+      +----------+ |  |                         \        *  AS4       *
+                   |  |                          \       *  ********  *
+                   |  +-------------------------------------+ ASP1 *  *
+                   |                                     *  ********  *
+                   |                                     *      .     *
+                   |                                     *      .     *
+                   |                                     *            *
+                   |                                     *  ********  *
+                   +----------------------------------------+ ASPn *  *
+                                                         *  ********  *
+                                                         **************
+
+                Figure 4: Signalling Gateway Architecture
+
+   The pair of SGs can either operate as replicated endpoints or as
+   replicated relay points from the SS7 network point of view.
+
+   Replicated endpoints: the coupling between the SGs and the ASPs when
+   the SGs act as replicated endpoints is an implementation issue.
+
+   Replicated relay points: in normal circumstances, the path from SEP
+   to ASP will always go via the same SGP when in-sequence-delivery is
+   requested.  However, linkset failures may cause MTP to reroute to the
+   other SG.
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 127]
+

+RFC 3868                          SUA                       October 2004
+
+
+A.3.  Signalling Gateway Message Distribution Recommendations
+
+A.3.1.  Connectionless Transport
+
+   By means of configuration, the SG knows the local SCCP-user is
+   actually represented by an AS, and serviced by a set of ASPs working
+   in n+k redundancy mode.  An ASP is selected and a CLDT message is
+   sent on the appropriate SCTP association/stream.
+
+   The selection criterion can be based on a round robin mechanism, or
+   any other method that guarantees a balanced loadsharing over the
+   active ASPs.  However, when TCAP messages are transported, load
+   sharing is only possible for the first message in a TCAP dialogue
+   (TC_Begin, TC_Query, TC_Unidirectional).  All other TCAP messages in
+   the same dialogue are sent to the same ASP that was selected for the
+   first message, unless the ASPs are able to share state and maintain
+   sequenced delivery.  To this end, the SGP needs to know the TID
+   allocation policy of the ASPs in a single AS:
+
+   -  State sharing
+   -  Fixed range of TIDs per ASP in the AS
+
+   This information may be provisioned in the SG, or may be dynamically
+   exchanged via the ASP_Active message.
+
+   An example for an INAP/TCAP message exchange between SEP and ASP is
+   given below.
+
+   Address information in CLDT message (e.g., TC_Query) from SGP to ASP,
+   with association ID = SG-ASP, Stream ID based on sequence control and
+   possibly other parameters, e.g., OPC:
+
+   -  Routing Context: based on SS7 Network ID and AS membership, so
+      that the message can be transported to the correct ASP.
+   -  Source address: valid combination of SSN, PC and GT, as needed for
+      back routing to the SEP.
+   -  Destination address: at least SSN, to select the SCCP/SUA-user at
+      the ASP.
+
+   Address information in CLDT message (e.g., TC_Response) from ASP to
+   SG, with association ID = ASP-SG, stream ID selected by
+   implementation dependent means with regards to in-sequence-delivery:
+
+   -  Routing Context: as received in previous message.
+   -  Source address: unique address provided so that when used as the
+      SCCP called party address in the SEP, it must yield the same AS,
+      the SSN might be sufficient.
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 128]
+

+RFC 3868                          SUA                       October 2004
+
+
+   -  Destination address: copied from source address in received CLDT
+      message.
+
+   Further messages from the SEP belonging to the same TCAP transaction
+   will now reach the same ASP.
+
+A.3.2.  Connection-Oriented Transport
+
+   Further messages for this connection are routed on DPC in the SS7
+   connection section (MTP routing label), and on IP address in the IP
+   connection section (SCTP header).  No other routing information is
+   present in the SCCP or SUA messages themselves.  Resources are kept
+   within the SG to forward messages from one section to another and to
+   populate the MTP routing label or SCTP header, based on the
+   destination local reference of these messages (Connect Confirm, Data
+   Transfer, etc.)
+
+   This means that in the SG, two local references are allocated, one
+   3-byte value used for the SS7 section and one 4-byte value for the IP
+   section.  Also a resource containing the connection data for both
+   sections is allocated, and either of the two local references can be
+   used to retrieve this data e.g., for an incoming DT1 or CODT, for
+   example.
+
+Authors' Addresses
+
+   John Loughney
+   Nokia Research Center
+   PO Box 407
+   FIN-00045 Nokia Group
+   Finland
+
+   EMail: john.Loughney@nokia.com
+
+
+   Greg Sidebottom
+   Signatus Technologies
+   Kanata, Ontario
+   Canada
+
+   EMail: greg@signatustechnologies.com
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 129]
+

+RFC 3868                          SUA                       October 2004
+
+
+   Lode Coene
+   Siemens n.v.
+   Atealaan 34
+   B-2200 Herentals
+   Belgium
+
+   Phone: +32-14-252081
+   EMail: lode.coene@siemens.com
+
+
+   Gery Verwimp
+   Siemens n.v.
+   34 Atealaan
+   PO 2200
+   Herentals
+   Belgium
+
+   Phone: +32 14 25 3424
+   EMail: gery.verwimp@siemens.com
+
+
+   Joe Keller
+   Tekelec
+   5200 Paramount Parkway
+   Morrisville, NC 27560
+   USA
+
+   EMail: joe.keller@tekelec.com
+
+
+   Brian Bidulock
+   OpenSS7 Corporation
+   1469 Jeffreys Crescent
+   Edmonton, AB  T6L 6T1
+   Canada
+
+   Phone: +1 780 490 1141
+   EMail: bidulock@openss7.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 130]
+

+RFC 3868                          SUA                       October 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Loughney, et al.            Standards Track                   [Page 131]
+
+

+ Html markup produced by rfcmarkup 1.116, available from + https://tools.ietf.org/tools/rfcmarkup/ + +
+ + -- cgit v1.2.3