summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNeels Hofmeyr <nhofmeyr@sysmocom.de>2016-03-07 14:35:42 +0100
committerHarald Welte <laforge@gnumonks.org>2017-01-27 09:59:30 +0100
commit189a776183f682798997c4b1fba34ec1fb1d2cd3 (patch)
tree6ab6c5e5911ade98cc5109137ecff91f6da8d964
parent04694923b25cbe8e455d25642e1e0ba9eb0c6857 (diff)
add RFC 3868 (SUA) spec in HTML
-rw-r--r--specs/RFC_3868__Signalling_Connection_Control_Part_User_Adaptation_Layer_SUA.html7535
1 files changed, 7535 insertions, 0 deletions
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 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <meta name="robots" content="index,follow" />
+ <meta name="creator" content="rfcmarkup version 1.116" />
+ <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
+<meta name="DC.Relation.Replaces" content="draft-loughney-sigtran-sua" />
+<meta name="DC.Identifier" content="urn:ietf:rfc:3868" />
+<meta name="DC.Date.Issued" content="October, 2004" />
+<meta name="DC.Creator" content="Coene, Lode" />
+<meta name="DC.Creator" content="Keller, Joe" />
+<meta name="DC.Creator" content="Sidebottom, Greg" />
+<meta name="DC.Creator" content="Bidulock, Brian" />
+<meta name="DC.Creator" content="Loughney, John" />
+<meta name="DC.Description.Abstract" content="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. [STANDARDS-TRACK]" />
+<meta name="DC.Title" content="Signalling Connection Control Part User Adaptation Layer (SUA)" />
+
+ <link rel="icon" href="/images/rfc.png" type="image/png" />
+ <link rel="shortcut icon" href="/images/rfc.png" type="image/png" />
+ <title>RFC 3868 - Signalling Connection Control Part User Adaptation Layer (SUA)</title>
+
+
+ <style type="text/css">
+ @media only screen
+ and (min-width: 992px)
+ and (max-width: 1199px) {
+ body { font-size: 14pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-width: 768px)
+ and (max-width: 991px) {
+ body { font-size: 14pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-width: 480px)
+ and (max-width: 767px) {
+ body { font-size: 11pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (max-width: 479px) {
+ body { font-size: 8pt; }
+ div.content { width: 96ex; margin: 0 auto; }
+ }
+ @media only screen
+ and (min-device-width : 375px)
+ and (max-device-width : 667px) {
+ body { font-size: 9.5pt; }
+ div.content { width: 96ex; margin: 0 1px; }
+ }
+ @media only screen
+ and (min-device-width: 1200px) {
+ body { font-size: 10pt; margin: 0 4em; }
+ div.content { width: 96ex; margin: 0; }
+ }
+ h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
+ font-weight: bold;
+ line-height: 0pt;
+ display: inline;
+ white-space: pre;
+ font-family: monospace;
+ font-size: 1em;
+ font-weight: bold;
+ }
+ pre {
+ font-size: 1em;
+ margin-top: 0px;
+ margin-bottom: 0px;
+ }
+ .pre {
+ white-space: pre;
+ font-family: monospace;
+ }
+ .header{
+ font-weight: bold;
+ }
+ .newpage {
+ page-break-before: always;
+ }
+ .invisible {
+ text-decoration: none;
+ color: white;
+ }
+ a.selflink {
+ color: black;
+ text-decoration: none;
+ }
+ @media print {
+ body {
+ font-family: monospace;
+ font-size: 10.5pt;
+ }
+ h1, h2, h3, h4, h5, h6 {
+ font-size: 1em;
+ }
+
+ a:link, a:visited {
+ color: inherit;
+ text-decoration: none;
+ }
+ .noprint {
+ display: none;
+ }
+ }
+ @media screen {
+ .grey, .grey a:link, .grey a:visited {
+ color: #777;
+ }
+ .docinfo {
+ background-color: #EEE;
+ }
+ .top {
+ border-top: 7px solid #EEE;
+ }
+ .bgwhite { background-color: white; }
+ .bgred { background-color: #F44; }
+ .bggrey { background-color: #666; }
+ .bgbrown { background-color: #840; }
+ .bgorange { background-color: #FA0; }
+ .bgyellow { background-color: #EE0; }
+ .bgmagenta{ background-color: #F4F; }
+ .bgblue { background-color: #66F; }
+ .bgcyan { background-color: #4DD; }
+ .bggreen { background-color: #4F4; }
+
+ .legend { font-size: 90%; }
+ .cplate { font-size: 70%; border: solid grey 1px; }
+ }
+ </style>
+ <!--[if IE]>
+ <style>
+ body {
+ font-size: 13px;
+ margin: 10px 10px;
+ }
+ </style>
+ <![endif]-->
+
+ <script type="text/javascript"><!--
+ function addHeaderTags() {
+ var spans = document.getElementsByTagName("span");
+ for (var i=0; i < spans.length; i++) {
+ var elem = spans[i];
+ if (elem) {
+ var level = elem.getAttribute("class");
+ if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
+ elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
+ }
+ }
+ }
+ }
+ var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> </table>";
+ function showElem(id) {
+ var elem = document.getElementById(id);
+ elem.innerHTML = eval(id+"_html");
+ elem.style.visibility='visible';
+ }
+ function hideElem(id) {
+ var elem = document.getElementById(id);
+ elem.style.visibility='hidden';
+ elem.innerHTML = "";
+ }
+ // -->
+ </script>
+</head>
+<body onload="addHeaderTags()">
+ <div class="content">
+ <div style="height: 13px;">
+ <div onmouseover="this.style.cursor='pointer';"
+ onclick="showElem('legend');"
+ onmouseout="hideElem('legend')"
+ style="height: 6px; position: absolute;"
+ class="pre noprint docinfo bgblue"
+ title="Click for colour legend." > </div>
+ <div id="legend"
+ class="docinfo noprint pre legend"
+ style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
+ onmouseover="showElem('legend');"
+ onmouseout="hideElem('legend');">
+ </div>
+ </div>
+<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc3868.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc3868" title="PDF version of this document">pdf</a>] [<a href="https://tools.ietf.org/html/draft-ietf-sigtran-sua" title="draft-ietf-sigtran-sua">draft-ietf-sigtra...</a>] [<a href="https://tools.ietf.org/rfcdiff?difftype=--hwdiff&amp;url2=rfc3868" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://tools.ietf.org/rfcdiff?url2=rfc3868" title="Side-by-side diff">Diff2</a>] [<a href="https://datatracker.ietf.org/ipr/search/?rfc=3868&submit=rfc" title="IPR disclosures related to this document">IPR</a>] </span><br />
+<span class="pre noprint docinfo"> </span><br />
+<span class="pre noprint docinfo"> PROPOSED STANDARD</span><br />
+<span class="pre noprint docinfo"> </span><br />
+<pre>
+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
+
+
+ <span class="h1">Signalling Connection Control Part User Adaptation Layer (SUA)</span>
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 1]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+Table of Contents
+
+ <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
+ <a href="#section-1.1">1.1</a>. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
+ <a href="#section-1.2">1.2</a>. Abbreviations and Terminology. . . . . . . . . . . . . . <a href="#page-4">4</a>
+ <a href="#section-1.3">1.3</a>. Signalling Transport Architecture. . . . . . . . . . . . <a href="#page-6">6</a>
+ <a href="#section-1.4">1.4</a>. Services Provided by the SUA Layer . . . . . . . . . . . <a href="#page-9">9</a>
+ <a href="#section-1.5">1.5</a>. Internal Functions Provided in the SUA Layer . . . . . . <a href="#page-11">11</a>
+ <a href="#section-1.6">1.6</a>. Definition of SUA Boundaries . . . . . . . . . . . . . . <a href="#page-14">14</a>
+ <a href="#section-2">2</a>. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
+ <a href="#section-3">3</a>. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
+ <a href="#section-3.1">3.1</a>. Common Message Header. . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
+ <a href="#section-3.2">3.2</a>. SUA Connectionless Messages. . . . . . . . . . . . . . . <a href="#page-24">24</a>
+ <a href="#section-3.3">3.3</a>. Connection Oriented Messages . . . . . . . . . . . . . . <a href="#page-27">27</a>
+ <a href="#section-3.4">3.4</a>. Signalling Network Management (SNM) Messages . . . . . . <a href="#page-42">42</a>
+ <a href="#section-3.5">3.5</a>. Application Server Process State Maintenance Messages. . <a href="#page-49">49</a>
+ <a href="#section-3.6">3.6</a>. ASP Traffic Maintenance Messages . . . . . . . . . . . . <a href="#page-53">53</a>
+ <a href="#section-3.7">3.7</a>. SUA Management Messages. . . . . . . . . . . . . . . . . <a href="#page-56">56</a>
+ <a href="#section-3.8">3.8</a>. Routing Key Management (RKM) Messages. . . . . . . . . . <a href="#page-58">58</a>
+ <a href="#section-3.9">3.9</a>. Common Parameters. . . . . . . . . . . . . . . . . . . . <a href="#page-61">61</a>
+ <a href="#section-3.10">3.10</a>. SUA-Specific parameters. . . . . . . . . . . . . . . . . <a href="#page-74">74</a>
+ <a href="#section-4">4</a>. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-92">92</a>
+ <a href="#section-4.1">4.1</a>. Procedures to Support the SUA-User Layer . . . . . . . . <a href="#page-92">92</a>
+ <a href="#section-4.2">4.2</a>. Receipt of Primitives from the Layer Management. . . . . <a href="#page-93">93</a>
+ <a href="#section-4.3">4.3</a>. AS and ASP State Maintenance . . . . . . . . . . . . . . <a href="#page-95">95</a>
+ <a href="#section-4.4">4.4</a>. Routing Key Management Procedures. . . . . . . . . . . .<a href="#page-109">109</a>
+ 4.5. Availability and/or Congestion Status of SS7
+ Destination Support101 . . . . . . . . . . . . . . . . .<a href="#page-112">112</a>
+ <a href="#section-4.6">4.6</a>. MTP3 Restart . . . . . . . . . . . . . . . . . . . . . .<a href="#page-115">115</a>
+ <a href="#section-4.7">4.7</a>. SCCP - SUA Interworking at the SG. . . . . . . . . . . .<a href="#page-115">115</a>
+ <a href="#section-5">5</a>. Examples of SUA Procedures . . . . . . . . . . . . . . . . . .<a href="#page-117">117</a>
+ <a href="#section-5.1">5.1</a>. SG Architecture. . . . . . . . . . . . . . . . . . . . .<a href="#page-117">117</a>
+ <a href="#section-5.2">5.2</a> IPSP Examples. . . . . . . . . . . . . . . . . . . . . .<a href="#page-119">119</a>
+ <a href="#section-6">6</a>. Security Considerations. . . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a>
+ <a href="#section-7">7</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a>
+ <a href="#section-7.1">7.1</a>. SCTP Payload Protocol ID . . . . . . . . . . . . . . . .<a href="#page-121">121</a>
+ <a href="#section-7.2">7.2</a>. Port Number. . . . . . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a>
+ <a href="#section-7.3">7.3</a>. Protocol Extensions. . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a>
+ <a href="#section-8">8</a>. Timer Values . . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-123">123</a>
+ <a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-123">123</a>
+ <a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-123">123</a>
+ <a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . .<a href="#page-123">123</a>
+ <a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . .<a href="#page-124">124</a>
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 2]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ <a href="#appendix-A">Appendix A</a>. Signalling Network Architecture . . . . . . . . . . .<a href="#page-125">125</a>
+ <a href="#appendix-A.1">A.1</a>. Generalized Peer-to-Peer Network Architecture. . . . . .<a href="#page-125">125</a>
+ <a href="#appendix-A.2">A.2</a>. Signalling Gateway Network Architecture. . . . . . . . .<a href="#page-126">126</a>
+ A.3. Signalling Gateway Message Distribution
+ Recommendations. . . . . . . . . . . . . . . . . . . . .<a href="#page-128">128</a>
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-129">129</a>
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .<a href="#page-131">131</a>
+
+<span class="h2"><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</span>
+
+ 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 [<a href="#ref-2719" title="&quot;Framework Architecture for Signalling Transport&quot;">2719</a>].
+
+ 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) [<a href="#ref-2960" title="&quot;Stream Control Transmission Protocol&quot;">2960</a>].
+
+<span class="h3"><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Scope</span>
+
+ This document details the delivery of SCCP-user messages (MAP &amp; CAP
+ over TCAP [ANSI TCAP] [ITU TCAP], RANAP [<a href="#ref-RANAP">RANAP</a>], 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 [<a href="#ref-2719" title="&quot;Framework Architecture for Signalling Transport&quot;">2719</a>]. 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.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 3]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-1.2" href="#section-1.2">1.2</a>. Abbreviations and Terminology</span>
+
+<span class="h4"><a class="selflink" name="section-1.2.1" href="#section-1.2.1">1.2.1</a>. Abbreviations</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.2.2" href="#section-1.2.2">1.2.2</a>. Terminology</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 4]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 5]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-1.3" href="#section-1.3">1.3</a>. Signalling Transport Architecture</span>
+
+ The framework architecture that has been defined for switched circuit
+ networks signalling transport over IP [<a href="#ref-2719" title="&quot;Framework Architecture for Signalling Transport&quot;">2719</a>] 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.
+
+<span class="h4"><a class="selflink" name="section-1.3.1" href="#section-1.3.1">1.3.1</a>. Protocol Architecture for Connectionless Transport</span>
+
+ 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.
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 6]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ ******** 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 <a href="#appendix-A.3.1">Appendix A.3.1</a> for operation recommendations.
+
+<span class="h5"><a class="selflink" name="section-1.3.1.1" href="#section-1.3.1.1">1.3.1.1</a>. SG as endpoint</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-1.3.1.2" href="#section-1.3.1.2">1.3.1.2</a>. Signalling Gateway as relay-point</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 7]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-1.3.2" href="#section-1.3.2">1.3.2</a>. Protocol Architecture for Connection-Oriented Transport</span>
+
+ 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 <a href="#appendix-A.3.2">Appendix A.3.2</a> for operation recommendations.
+
+<span class="h4"><a class="selflink" name="section-1.3.3" href="#section-1.3.3">1.3.3</a>. All IP Architecture</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 8]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ ******** IP ********
+ * IPSP *--------* IPSP *
+ ******** ********
+
+ +------+ +------+
+ | SUAP | | SUAP |
+ +------+ +------+
+ | SUA | | SUA |
+ +------+ +------+
+ | SCTP | | SCTP |
+ +------+ +------+
+ | IP | | IP |
+ +------+ +------+
+ | |
+ +----------------+
+
+ SUAP - SCCP/SUA Application Protocol (e.g., - RANAP/RNSAP)
+
+<span class="h4"><a class="selflink" name="section-1.3.4" href="#section-1.3.4">1.3.4</a>. ASP Fail-over Model and Terminology</span>
+
+ 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 <a href="#appendix-A">Appendix A</a>.
+
+<span class="h3"><a class="selflink" name="section-1.4" href="#section-1.4">1.4</a>. Services Provided by the SUA Layer</span>
+
+<span class="h4"><a class="selflink" name="section-1.4.1" href="#section-1.4.1">1.4.1</a>. Support for the transport of SCCP-User Messages</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.4.2" href="#section-1.4.2">1.4.2</a>. SCCP Protocol Class Support</span>
+
+ Depending upon the SCCP-users supported, the SUA supports the 4
+ possible SCCP protocol classes transparently. The SCCP protocol
+ classes are defined as follows:
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 9]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ * 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.
+
+<span class="h4"><a class="selflink" name="section-1.4.3" href="#section-1.4.3">1.4.3</a>. Native Management Functions</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.4.4" href="#section-1.4.4">1.4.4</a>. Interworking with SCCP Network Management Functions</span>
+
+ 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 <a href="#section-3">section 3</a>)
+ 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 |
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 10]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-1.4.5" href="#section-1.4.5">1.4.5</a>. Support for the management between the SGP and ASP.</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.4.6" href="#section-1.4.6">1.4.6</a>. Relay function</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-1.5" href="#section-1.5">1.5</a>. Internal Functions Provided in the SUA Layer</span>
+
+ 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 [<a href="#ref-3761" title="&quot;The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)&quot;">3761</a>],
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 11]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.5.1" href="#section-1.5.1">1.5.1</a>. Address Mapping at the SG</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.5.2" href="#section-1.5.2">1.5.2</a>. Address Mapping at the ASP</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.5.3" href="#section-1.5.3">1.5.3</a>. Address Mapping Function at a Relay Node</span>
+
+ The relay function is invoked when:
+
+ - Routing is on Global Title
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 12]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ - 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".
+
+<span class="h4"><a class="selflink" name="section-1.5.4" href="#section-1.5.4">1.5.4</a>. SCTP Stream Mapping</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 13]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-1.5.5" href="#section-1.5.5">1.5.5</a>. Flow Control</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-1.5.6" href="#section-1.5.6">1.5.6</a>. Congestion Management</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-1.6" href="#section-1.6">1.6</a>. Definition of SUA Boundaries</span>
+
+<span class="h4"><a class="selflink" name="section-1.6.1" href="#section-1.6.1">1.6.1</a>. Definition of the upper boundary</span>
+
+ 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)
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 14]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ ------------+----------+-------------------------------------------
+ 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 |
+
+<span class="h4"><a class="selflink" name="section-1.6.2" href="#section-1.6.2">1.6.2</a>. Definition of the lower boundary</span>
+
+ The upper layer primitives provided by the SCTP are provided in
+ [SCTP].
+
+<span class="h4"><a class="selflink" name="section-1.6.3" href="#section-1.6.3">1.6.3</a>. Definition of the Boundary between SUA and Layer Management</span>
+
+ M-SCTP_ESTABLISH request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to establish an SCTP association with its
+ peer.
+
+ M-SCTP_ESTABLISH confirm
+ Direction: SUA -&gt; LM
+ Purpose: ASP confirms to LM that it has established an SCTP
+ association with its peer.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 15]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+
+ M-SCTP_ESTABLISH indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA informs LM that a remote ASP has established an SCTP
+ association.
+
+ M-SCTP_RELEASE request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to release an SCTP association with its
+ peer.
+
+ M-SCTP_RELEASE confirm
+ Direction: SUA -&gt; LM
+ Purpose: ASP confirms to LM that it has released SCTP association
+ with its peer.
+
+ M-SCTP_RELEASE indication
+ Direction: SUA -&gt; 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 -&gt; LM
+ Purpose: SUA informs LM that an SCTP restart indication has been
+ received.
+
+ M-SCTP_STATUS request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests SUA to report the status of an SCTP
+ association.
+
+ M-SCTP_STATUS confirm
+ Direction: SUA -&gt; LM
+ Purpose: SUA responds with the status of an SCTP association.
+
+ M-SCTP STATUS indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports the status of an SCTP association.
+
+ M-ASP_STATUS request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests SUA to report the status of a local or remote
+ ASP.
+
+ M-ASP_STATUS confirm
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports status of local or remote ASP.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 16]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ M-AS_STATUS request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests SUA to report the status of an AS.
+
+ M-AS_STATUS confirm
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports the status of an AS.
+
+ M-NOTIFY indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports that it has received a Notify message from its
+ peer.
+
+ M-ERROR indication
+ Direction: SUA -&gt; 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 -&gt; SUA
+ Purpose: LM requests ASP to start its operation and send an ASP Up
+ message to its peer.
+
+ M-ASP_UP confirm
+ Direction: SUA -&gt; LM
+ Purpose: ASP reports that is has received an ASP UP Ack message
+ from its peer.
+
+ M-ASP_UP indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports it has successfully processed an incoming ASP
+ Up message from its peer.
+
+ M-ASP_DOWN request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to stop its operation and send an ASP Down
+ message to its peer.
+
+ M-ASP_DOWN confirm
+ Direction: SUA -&gt; LM
+ Purpose: ASP reports that is has received an ASP Down Ack message
+ from its peer.
+
+ M-ASP_DOWN indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports it has successfully processed an incoming ASP
+ Down message from its peer, or the SCTP association has
+ been lost/reset.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 17]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+
+ M-ASP_ACTIVE request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to send an ASP Active message to its peer.
+
+ M-ASP_ACTIVE confirm
+ Direction: SUA -&gt; LM
+ Purpose: ASP reports that is has received an ASP Active Ack message
+ from its peer.
+
+ M-ASP_ACTIVE indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports it has successfully processed an incoming ASP
+ Active message from its peer.
+
+ M-ASP_INACTIVE request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to send an ASP Inactive message to its
+ peer.
+
+ M-ASP_INACTIVE confirm
+ Direction: LM -&gt; SUA
+ Purpose: ASP reports that is has received an ASP Inactive
+ Ack message from its peer.
+
+ M-ASP_INACTIVE indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports it has successfully processed an incoming ASP
+ Inactive message from its peer.
+
+ M-AS_ACTIVE indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports that an AS has moved to the AS-ACTIVE state.
+
+ M-AS_INACTIVE indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports that an AS has moved to the AS-INACTIVE state.
+
+ M-AS_DOWN indication
+ Direction: SUA -&gt; LM
+ Purpose: SUA reports that an AS has moved to the AS-DOWN state.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 18]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ If the SUA layer supports dynamic registration of Routing Key, the
+ layer MAY support the following additional primitives:
+
+ M-RK_REG request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to register RK(s) with its peer by sending
+ REG REQ message.
+
+ M-RK_REG confirm
+ Direction: SUA -&gt; 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 -&gt; LM
+ Purpose: SUA informs LM that it has successfully processed an
+ incoming REG REQ message.
+
+ M-RK_DEREG request
+ Direction: LM -&gt; SUA
+ Purpose: LM requests ASP to deregister RK(s) with its peer by
+ sending DEREG REQ message.
+
+ M-RK_DEREG confirm
+ Direction: SUA -&gt; 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 -&gt; LM
+ Purpose: SUA informs LM that it has successfully processed an
+ incoming DEREG REQ from its peer.
+
+<span class="h2"><a class="selflink" name="section-2" href="#section-2">2</a>. Conventions</span>
+
+ 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
+ <a href="https://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a> [<a href="#ref-2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">2119</a>].
+
+<span class="h2"><a class="selflink" name="section-3" href="#section-3">3</a>. Protocol Elements</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 19]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ The Reserved field is set to 0 in messages sent and is not to be
+ examined in messages received.
+
+<span class="h3"><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Common Message Header</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.1.1" href="#section-3.1.1">3.1.1</a>. SUA Protocol Version</span>
+
+ The version field (ver) contains the version of the SUA adaptation
+ layer. The supported versions are:
+
+ 1 SUA version 1.0
+
+<span class="h4"><a class="selflink" name="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Message Classes</span>
+
+ 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
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 20]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Message Types</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 21]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.1.4" href="#section-3.1.4">3.1.4</a>. Message Length</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.1.5" href="#section-3.1.5">3.1.5</a>. Tag-Length-Value Format</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 22]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 23]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ - The receiver SHOULD accept parameters in any order, except where
+ explicitly mandated.
+
+<span class="h3"><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. SUA Connectionless Messages</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Connectionless Data Transfer (CLDT)</span>
+
+ 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 |
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 24]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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).
+
+<span class="h4"><a class="selflink" name="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Connectionless Data Response (CLDR)</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 25]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 26]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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).
+
+<span class="h3"><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Connection Oriented Messages</span>
+
+<span class="h4"><a class="selflink" name="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Connection Oriented Data Transfer (CODT)</span>
+
+ This message transfers data between one SUA to another for
+ connection-oriented service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 27]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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).
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 28]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Connection Oriented Data Acknowledge (CODA)</span>
+
+ 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)
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 29]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ EA is represented by a CODA when:
+ Receive Sequence Number parameter is not present
+
+<span class="h4"><a class="selflink" name="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Connection Request (CORE)</span>
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 30]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ | 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 31]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Connection Acknowledge (COAK)</span>
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 32]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ / 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 33]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.5" href="#section-3.3.5">3.3.5</a>. Connection Refused (COREF)</span>
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 34]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 35]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.6" href="#section-3.3.6">3.3.6</a>. Release Request (RELRE)</span>
+
+ 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).
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 36]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.7" href="#section-3.3.7">3.3.7</a>. Release Complete (RELCO)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 37]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.8" href="#section-3.3.8">3.3.8</a>. Reset Request (RESRE)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 38]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.9" href="#section-3.3.9">3.3.9</a>. Reset Confirm (RESCO)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 39]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.10" href="#section-3.3.10">3.3.10</a>. Connection Oriented Error (COERR)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 40]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.3.11" href="#section-3.3.11">3.3.11</a>. Connection Oriented Inactivity Test (COIT)</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 41]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Implementation note: This message covers the following SCCP message:
+ Inactivity Test (IT).
+
+<span class="h3"><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Signalling Network Management (SNM) Messages</span>
+
+<span class="h4"><a class="selflink" name="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Destination Unavailable (DUNA)</span>
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 42]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Destination Available (DAVA)</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 43]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.4.3" href="#section-3.4.3">3.4.3</a>. Destination State Audit (DAUD)</span>
+
+ 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).
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 44]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 45]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.4.4" href="#section-3.4.4">3.4.4</a>. Signalling Congestion (SCON)</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 46]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ N-PCSTATE primitive reporting signalling point or network
+ congestion status.
+
+<span class="h4"><a class="selflink" name="section-3.4.5" href="#section-3.4.5">3.4.5</a>. Destination User Part Unavailable (DUPU)</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.4.6" href="#section-3.4.6">3.4.6</a>. Destination Restricted (DRST)</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 47]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 48]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Application Server Process State Maintenance Messages</span>
+
+<span class="h4"><a class="selflink" name="section-3.5.1" href="#section-3.5.1">3.5.1</a>. ASP Up (UP)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 49]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.5.2" href="#section-3.5.2">3.5.2</a>. ASP Up Ack (UP ACK)</span>
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.5.3" href="#section-3.5.3">3.5.3</a>. ASP Down (DOWN)</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 50]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.5.4" href="#section-3.5.4">3.5.4</a>. ASP Down Ack (DOWN ACK)</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.5.5" href="#section-3.5.5">3.5.5</a>. Heartbeat (BEAT)</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 51]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.5.6" href="#section-3.5.6">3.5.6</a>. Heartbeat Ack (BEAT ACK)</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 52]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a>. ASP Traffic Maintenance Messages</span>
+
+<span class="h4"><a class="selflink" name="section-3.6.1" href="#section-3.6.1">3.6.1</a>. ASP Active (ACTIVE)</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 53]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.6.2" href="#section-3.6.2">3.6.2</a>. ASP Active Ack (ACTIVE ACK)</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 54]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.6.3" href="#section-3.6.3">3.6.3</a>. ASP Inactive (INACTIVE)</span>
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.6.4" href="#section-3.6.4">3.6.4</a>. ASP Inactive Ack (INACTIVE ACK)</span>
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 55]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Parameters
+ Routing Context Optional
+ INFO String Optional
+
+<span class="h3"><a class="selflink" name="section-3.7" href="#section-3.7">3.7</a>. SUA Management Messages</span>
+
+ These messages are used for managing SUA and the representations of
+ the SCCP subsystems in the SUA layer.
+
+<span class="h4"><a class="selflink" name="section-3.7.1" href="#section-3.7.1">3.7.1</a>. Error (ERR)</span>
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 56]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.7.2" href="#section-3.7.2">3.7.2</a>. Notify (NTFY)</span>
+
+ 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).
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 57]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-3.8" href="#section-3.8">3.8</a>. Routing Key Management (RKM) Messages</span>
+
+<span class="h4"><a class="selflink" name="section-3.8.1" href="#section-3.8.1">3.8.1</a>. Registration Request (REG REQ)</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 58]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.8.2" href="#section-3.8.2">3.8.2</a>. Registration Response (REG RSP)</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.8.3" href="#section-3.8.3">3.8.3</a>. Deregistration Request (DEREG REQ)</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 59]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.8.4" href="#section-3.8.4">3.8.4</a>. Deregistration Response (DEREG RSP)</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 60]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-3.9" href="#section-3.9">3.9</a>. Common Parameters</span>
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.9.1" href="#section-3.9.1">3.9.1</a>. Not Used</span>
+
+ Use of Parameter ID 0x0001 in SUA messages is not supported.
+
+<span class="h4"><a class="selflink" name="section-3.9.2" href="#section-3.9.2">3.9.2</a>. Not Used</span>
+
+ Use of Parameter ID 0x0002 in SUA messages is not supported.
+
+<span class="h4"><a class="selflink" name="section-3.9.3" href="#section-3.9.3">3.9.3</a>. Not Used</span>
+
+ Use of Parameter ID 0x0003 in SUA messages is not supported.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 61]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.9.4" href="#section-3.9.4">3.9.4</a>. Info String</span>
+
+ The optional INFO String parameter can carry any meaningful UTF-8
+ [<a href="#ref-3629" title="&quot;UTF-8, a transformation format of ISO 10646&quot;">3629</a>] 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 /
+
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+<span class="h4"><a class="selflink" name="section-3.9.5" href="#section-3.9.5">3.9.5</a>. Not Used in SUA</span>
+
+ Use of Parameter ID 0x0005 in SUA messages is not supported.
+
+<span class="h4"><a class="selflink" name="section-3.9.6" href="#section-3.9.6">3.9.6</a>. Routing Context</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 62]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.9.7" href="#section-3.9.7">3.9.7</a>. Diagnostic Information</span>
+
+ 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 /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+<span class="h4"><a class="selflink" name="section-3.9.8" href="#section-3.9.8">3.9.8</a>. Not Used</span>
+
+ Parameter ID 0x0008 is not used in SUA.
+
+<span class="h4"><a class="selflink" name="section-3.9.9" href="#section-3.9.9">3.9.9</a>. Heartbeat Data</span>
+
+ 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.
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 63]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.).
+
+<span class="h4"><a class="selflink" name="section-3.9.10" href="#section-3.9.10">3.9.10</a>. Not Used</span>
+
+ Parameter ID 0x000A is not used in SUA.
+
+<span class="h4"><a class="selflink" name="section-3.9.11" href="#section-3.9.11">3.9.11</a>. Traffic Mode Type</span>
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 64]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.9.12" href="#section-3.9.12">3.9.12</a>. Error Code</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 65]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 66]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.9.13" href="#section-3.9.13">3.9.13</a>. Status</span>
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 67]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.9.14" href="#section-3.9.14">3.9.14</a>. Not Used in SUA</span>
+
+ Parameter ID 0x000E is not used in SUA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 68]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.9.15" href="#section-3.9.15">3.9.15</a>. Not Used in SUA</span>
+
+ Parameter ID 0x000F is not used in SUA.
+
+<span class="h4"><a class="selflink" name="section-3.9.16" href="#section-3.9.16">3.9.16</a>. Not Used in SUA</span>
+
+ Parameter ID 0x0010 is not used in SUA.
+
+<span class="h4"><a class="selflink" name="section-3.9.17" href="#section-3.9.17">3.9.17</a>. ASP Identifier</span>
+
+ 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 <a href="#section-3.7.2">Section 3.7.2</a>).
+
+<span class="h4"><a class="selflink" name="section-3.9.18" href="#section-3.9.18">3.9.18</a>. Affected Point Code</span>
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 69]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ ANSI 24-bit Point Code:
+
+ 0 1 2 3--&gt;
+ 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--&gt;
+ 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 70]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.9.19" href="#section-3.9.19">3.9.19</a>. Correlation ID</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.9.20" href="#section-3.9.20">3.9.20</a>. Registration Result</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 71]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.9.21" href="#section-3.9.21">3.9.21</a>. Deregistration Result</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.9.22" href="#section-3.9.22">3.9.22</a>. Registration Status</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 72]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 8 Error - Insufficient Resources
+ 9 Error - Unsupported RK parameter Field
+ 10 Error - Unsupported/Invalid Traffic Mode Type
+ 11 Error - Routing Key Change Refused
+
+<span class="h4"><a class="selflink" name="section-3.9.23" href="#section-3.9.23">3.9.23</a>. Deregistration Status</span>
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.9.24" href="#section-3.9.24">3.9.24</a>. Local Routing Key Identifier</span>
+
+ 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.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 73]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-3.10" href="#section-3.10">3.10</a>. SUA-Specific parameters</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 74]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.1" href="#section-3.10.1">3.10.1</a>. SS7 Hop counter</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.2" href="#section-3.10.2">3.10.2</a>. Source Address</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 75]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h5"><a class="selflink" name="section-3.10.2.1" href="#section-3.10.2.1">3.10.2.1</a>. Routing Indicator</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-3.10.2.2" href="#section-3.10.2.2">3.10.2.2</a>. Address Indicator</span>
+
+ 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-&gt;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-&gt;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-&gt;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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 76]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-3.10.2.3" href="#section-3.10.2.3">3.10.2.3</a>. Global Title</span>
+
+ 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.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 77]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 78]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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 <a href="#section-3.4.2.3.1">Section</a>
+ <a href="#section-3.4.2.3.1">3.4.2.3.1</a>.
+
+<span class="h5"><a class="selflink" name="section-3.10.2.4" href="#section-3.10.2.4">3.10.2.4</a>. Point Code</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-3.10.2.5" href="#section-3.10.2.5">3.10.2.5</a>. Subsystem Number</span>
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 79]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-80" id="page-80" href="#page-80" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h5"><a class="selflink" name="section-3.10.2.6" href="#section-3.10.2.6">3.10.2.6</a>. IP Addresses</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-3.10.2.7" href="#section-3.10.2.7">3.10.2.7</a>. Hostname</span>
+
+ 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 <a href="https://tools.ietf.org/html/rfc1123#section-2.1">RFC 1123
+ Section&nbsp;2.1</a> [<a href="#ref-1123" title="&quot;Requirements for Internet Hosts - Application and Support&quot;">1123</a>]. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 80]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-81" id="page-81" href="#page-81" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.3" href="#section-3.10.3">3.10.3</a>. Destination Address</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.4" href="#section-3.10.4">3.10.4</a>. Source Reference Number</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.5" href="#section-3.10.5">3.10.5</a>. Destination Reference Number</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 81]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-82" id="page-82" href="#page-82" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.6" href="#section-3.10.6">3.10.6</a>. SCCP Cause</span>
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.10.7" href="#section-3.10.7">3.10.7</a>. Sequence Number</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 82]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-83" id="page-83" href="#page-83" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+<span class="h4"><a class="selflink" name="section-3.10.8" href="#section-3.10.8">3.10.8</a>. Receive Sequence Number</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 83]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-84" id="page-84" href="#page-84" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.9" href="#section-3.10.9">3.10.9</a>. ASP Capabilities</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.10" href="#section-3.10.10">3.10.10</a>. Credit</span>
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 84]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-85" id="page-85" href="#page-85" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.11" href="#section-3.10.11">3.10.11</a>. Data</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.12" href="#section-3.10.12">3.10.12</a>. User/Cause</span>
+
+ 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;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 85]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-86" id="page-86" href="#page-86" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.13" href="#section-3.10.13">3.10.13</a>. Network Appearance</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.14" href="#section-3.10.14">3.10.14</a>. Routing Key</span>
+
+ 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
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 86]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-87" id="page-87" href="#page-87" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.15" href="#section-3.10.15">3.10.15</a>. DRN Label</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.16" href="#section-3.10.16">3.10.16</a>. TID Label</span>
+
+ 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).
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 87]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-88" id="page-88" href="#page-88" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Label value is a 16-bit integer, which is unique across an AS.
+
+<span class="h4"><a class="selflink" name="section-3.10.17" href="#section-3.10.17">3.10.17</a>. Address Range</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.18" href="#section-3.10.18">3.10.18</a>. SMI</span>
+
+ 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
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 88]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-89" id="page-89" href="#page-89" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.19" href="#section-3.10.19">3.10.19</a>. Importance</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.20" href="#section-3.10.20">3.10.20</a>. Message Priority (or Priority)</span>
+
+ 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 89]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-90" id="page-90" href="#page-90" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.21" href="#section-3.10.21">3.10.21</a>. Protocol Class</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.22" href="#section-3.10.22">3.10.22</a>. Sequence Control</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 90]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-91" id="page-91" href="#page-91" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-3.10.23" href="#section-3.10.23">3.10.23</a>. Segmentation</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-3.10.24" href="#section-3.10.24">3.10.24</a>. Congestion Level</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 91]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-92" id="page-92" href="#page-92" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h2"><a class="selflink" name="section-4" href="#section-4">4</a>. Procedures</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Procedures to Support the SUA-User Layer</span>
+
+<span class="h4"><a class="selflink" name="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Receipt of Primitives from SCCP</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 92]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-93" id="page-93" href="#page-93" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Receipt of Primitives from the Layer Management</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 93]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-94" id="page-94" href="#page-94" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+ <a href="https://tools.ietf.org/html/rfc2960">RFC 2960</a> [<a href="#ref-2960" title="&quot;Stream Control Transmission Protocol&quot;">2960</a>] 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 94]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-95" id="page-95" href="#page-95" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Receipt of SUA Peer Management Messages</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. AS and ASP State Maintenance</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 95]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-96" id="page-96" href="#page-96" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ In <a href="#section-4.3.1">section 4.3.1</a>: 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 <a href="#section-4.3.2">section 4.3.2</a>, 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 <a href="#section-4.3.3">section 4.3.3</a>, 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.
+
+<span class="h4"><a class="selflink" name="section-4.3.1" href="#section-4.3.1">4.3.1</a>. ASP States</span>
+
+ 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).
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 96]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-97" id="page-97" href="#page-97" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Figure 1: ASP/IPSP State Transition Diagram, per AS
+
+ +--------------+
+ | |
+ +----------------------| ASP-ACTIVE |
+ | Other ASP/ +-------| |
+ | IPSP in AS | +--------------+
+ | Overrides | ^ |
+ | | ASPAC/ | | ASPIA/
+ | |[ASPAC-Ack]| | [ASPIA-Ack]
+ | | | v
+ | | +--------------+
+ | | | |
+ | +------&gt;| ASP-INACTIVE |
+ | | |
+ | +--------------+
+ | ^ |
+ ASPDN/ | | | ASPDN /
+ [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
+ SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
+ SCTP RI | | | SCTP RI
+ | | v
+ | +--------------+
+ | | |
+ +---------------------&gt;| 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.
+
+<span class="h4"><a class="selflink" name="section-4.3.2" href="#section-4.3.2">4.3.2</a>. AS States</span>
+
+ 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:
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 97]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-98" id="page-98" href="#page-98" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ * 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.
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 98]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-99" id="page-99" href="#page-99" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Figure 2: AS State Transition Diagram
+
+ +----------+ one ASP trans to ACTIVE +-------------+
+ | AS- |----------------------------&gt;| AS- |
+ | INACTIVE | | ACTIVE |
+ | |&lt;--- | |
+ +----------+ \ +-------------+
+ ^ | \ 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) |
+ | |&lt;----------------------------| |
+ +----------+ Tr Expiry and no ASP +-------------+
+ in ASP-INACTIVE state
+
+ Tr = Recovery Timer
+
+<span class="h5"><a class="selflink" name="section-4.3.2.1" href="#section-4.3.2.1">4.3.2.1</a>. IPSP Considerations</span>
+
+ The AS state diagram for the AS-SG case is applicable for IPSP
+ communication.
+
+<span class="h4"><a class="selflink" name="section-4.3.3" href="#section-4.3.3">4.3.3</a>. SUA Management Procedures for Primitives</span>
+
+ 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 <a href="#section-4.2.1">Section 4.2.1</a>) 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 <a href="#section-4.3.4">Section 4.3.4</a>).
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 99]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-100" id="page-100" href="#page-100" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.3.4" href="#section-4.3.4">4.3.4</a>. ASPM Procedures for Peer-to-Peer Messages</span>
+
+<span class="h5"><a class="selflink" name="section-4.3.4.1" href="#section-4.3.4.1">4.3.4.1</a>. ASP Up Procedures</span>
+
+ 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".
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 100]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-101" id="page-101" href="#page-101" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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 <a href="#section-4.3.4.2">section 4.3.4.2</a>), 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.
+
+<span class="h6"><a class="selflink" name="section-4.3.4.1.1" href="#section-4.3.4.1.1">4.3.4.1.1</a>. SUA Version Control</span>
+
+ 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.
+
+<span class="h6"><a class="selflink" name="section-4.3.4.1.2" href="#section-4.3.4.1.2">4.3.4.1.2</a>. IPSP Considerations</span>
+
+ 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.
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 101]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-102" id="page-102" href="#page-102" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.3.4.2" href="#section-4.3.4.2">4.3.4.2</a>. ASP Down Procedures</span>
+
+ 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 <a href="#section-4.4.1">Section 4.4.1</a>) 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
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 102]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-103" id="page-103" href="#page-103" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.3.4.3" href="#section-4.3.4.3">4.3.4.3</a>. ASP Active Procedures</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 103]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-104" id="page-104" href="#page-104" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 104]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-105" id="page-105" href="#page-105" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 105]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-106" id="page-106" href="#page-106" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h6"><a class="selflink" name="section-4.3.4.3.1" href="#section-4.3.4.3.1">4.3.4.3.1</a>. IPSP Considerations</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.3.4.4" href="#section-4.3.4.4">4.3.4.4</a>. ASP Inactive Procedures</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 106]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-107" id="page-107" href="#page-107" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 107]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-108" id="page-108" href="#page-108" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h6"><a class="selflink" name="section-4.3.4.4.1" href="#section-4.3.4.4.1">4.3.4.4.1</a>. IPSP Considerations</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.3.4.5" href="#section-4.3.4.5">4.3.4.5</a>. Notify Procedures</span>
+
+ 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.
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 108]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-109" id="page-109" href="#page-109" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h6"><a class="selflink" name="section-4.3.4.5.1" href="#section-4.3.4.5.1">4.3.4.5.1</a>. IPSP Considerations (NTFY)</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.3.4.6" href="#section-4.3.4.6">4.3.4.6</a>. Heartbeat Procedures</span>
+
+ 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".
+
+<span class="h3"><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a>. Routing Key Management Procedures</span>
+
+<span class="h4"><a class="selflink" name="section-4.4.1" href="#section-4.4.1">4.4.1</a>. Registration</span>
+
+ 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
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 109]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-110" id="page-110" href="#page-110" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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,
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 110]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-111" id="page-111" href="#page-111" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Deregistration</span>
+
+ 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.
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 111]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-112" id="page-112" href="#page-112" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.4.3" href="#section-4.4.3">4.4.3</a>. IPSP Considerations (REG/DEREG)</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-4.5" href="#section-4.5">4.5</a>. Availability and/or Congestion Status of SS7 Destination Support</span>
+
+<span class="h4"><a class="selflink" name="section-4.5.1" href="#section-4.5.1">4.5.1</a>. At an SGP</span>
+
+ 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 <a href="#section-3.4">Section 3.4</a>) 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 112]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-113" id="page-113" href="#page-113" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.5.2" href="#section-4.5.2">4.5.2</a>. At an ASP</span>
+
+<span class="h5"><a class="selflink" name="section-4.5.2.1" href="#section-4.5.2.1">4.5.2.1</a>. Single SG Configurations</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.5.2.2" href="#section-4.5.2.2">4.5.2.2</a>. Multiple SG Configurations</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.5.3" href="#section-4.5.3">4.5.3</a>. ASP Auditing</span>
+
+ 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:
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 113]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-114" id="page-114" href="#page-114" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ - 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").
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 114]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-115" id="page-115" href="#page-115" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="section-4.6" href="#section-4.6">4.6</a>. MTP3 Restart</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-4.7" href="#section-4.7">4.7</a>. SCCP - SUA Interworking at the SG</span>
+
+<span class="h4"><a class="selflink" name="section-4.7.1" href="#section-4.7.1">4.7.1</a>. Segmenting / Reassembly</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.7.2" href="#section-4.7.2">4.7.2</a>. Support for Loadsharing</span>
+
+ Within an AS (identified by RK/RC parameters) several loadsharing
+ ASPs may be active.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 115]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-116" id="page-116" href="#page-116" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.7.2.1" href="#section-4.7.2.1">4.7.2.1</a>. Association Setup, ASP going active</span>
+
+ 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 &lt; (Start - End + 1) &lt;= 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."
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 116]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-117" id="page-117" href="#page-117" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-4.7.3" href="#section-4.7.3">4.7.3</a>. Routing and message distribution at the SG</span>
+
+<span class="h5"><a class="selflink" name="section-4.7.3.1" href="#section-4.7.3.1">4.7.3.1</a>. TCAP traffic</span>
+
+ 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.
+
+<span class="h5"><a class="selflink" name="section-4.7.3.2" href="#section-4.7.3.2">4.7.3.2</a>. SCCP Connection Oriented traffic</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-4.7.4" href="#section-4.7.4">4.7.4</a>. Multiple SGs, SUA Relay Function</span>
+
+ 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.
+
+<span class="h2"><a class="selflink" name="section-5" href="#section-5">5</a>. Examples of SUA Procedures</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. SG Architecture</span>
+
+ 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.
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 117]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-118" id="page-118" href="#page-118" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h4"><a class="selflink" name="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Establishment of SUA connectivity</span>
+
+ 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----------------&gt;
+ &lt;--------------ASP Up Ack--------------+
+ +------ASP Up-------&gt;
+ &lt;---ASP Up Ack------+
+ +-------------ASP Active---------------&gt;
+ &lt;----------ASP Active Ack--------------+
+ &lt;----------NTFY (ASP Active)-----------+
+ &lt;-NTFY (ASP Active)-+
+ +--------SSA--------&gt;
+ &lt;--------SSA--------+
+ &lt;-----------------DAVA-----------------+
+ +-----------------CLDT-----------------&gt;
+ +--------UDT--------&gt;
+
+<span class="h4"><a class="selflink" name="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Fail-over scenarios</span>
+
+ The following sequences address fail-over of SEP and ASP.
+
+<span class="h5"><a class="selflink" name="section-5.1.2.1" href="#section-5.1.2.1">5.1.2.1</a>. SEP Fail-over</span>
+
+ 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)
+ &lt;--------SSP--------+
+ &lt;-----------------DUNA-----------------+
+ +-----------------DAUD-----------------&gt;
+ +--------SST--------&gt;
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 118]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-119" id="page-119" href="#page-119" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h5"><a class="selflink" name="section-5.1.2.2" href="#section-5.1.2.2">5.1.2.2</a>. Successful ASP Fail-over scenario</span>
+
+ 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-------------&gt;
+ &lt;-----------ASP Inactive ACK-----------+
+ &lt;--------------------NTFY (AS Pending)-+
+ &lt;-NTFY (AS Pending)-+
+ +----ASP Active-----&gt;
+ &lt;--ASP Active Ack---+
+ &lt;-NTFY (AS Active)--+
+ &lt;----------NTFY (AS Active)------------+
+
+<span class="h5"><a class="selflink" name="section-5.1.2.3" href="#section-5.1.2.3">5.1.2.3</a>. Unsuccessful ASP Fail-over scenario</span>
+
+ ASP-a1 ASP-a2 SG SEP
+ (Primary) (Backup)
+ +-------------ASP Inactive-------------&gt;
+ &lt;-----------ASP Inactive ACK-----------+
+ &lt;--------------------NTFY (AS Pending)-+
+ &lt;--NTFY (AS Pending)-+
+ After some time elapses (i.e., timeout).
+ +--------SSP--------&gt;
+ &lt;--------SST--------+
+ &lt;-------------------NTFY (AS Inactive)-+
+ &lt;-NTFY (AS Inactive)-+
+
+<span class="h3"><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. IPSP Examples</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Establishment of SUA connectivity</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 119]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-120" id="page-120" href="#page-120" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ Establish SCTP Connectivity - as per <a href="https://tools.ietf.org/html/rfc2960">RFC 2960</a>. Note that SCTP
+ connections are bidirectional. The endpoint that establishes SCTP
+ connectivity MUST also establish UA connectivity (see <a href="https://tools.ietf.org/html/rfc2960#section-5.2.1">RFC 2960,
+ section&nbsp;5.2.1</a> for handling collisions) [<a href="#ref-2960" title="&quot;Stream Control Transmission Protocol&quot;">2960</a>].
+
+ 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--------------------------&gt;
+ &lt;-----------------------------ASP Up Ack------------------------+
+
+ +--------------ASP Up---------------&gt;
+ &lt;------------ASP Up Ack-------------+
+
+ +---------------------------ACTIVE-------------------------------&gt;
+ &lt;-------------------------ACTIVE Ack-----------------------------+
+
+ [Traffic can now flow directly between ASPs]
+
+ +-----------------------------CLDT-------------------------------&gt;
+
+<span class="h4"><a class="selflink" name="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Fail-over scenarios</span>
+
+ The following sequences address fail-over of ASP.
+
+<span class="h5"><a class="selflink" name="section-5.2.2.1" href="#section-5.2.2.1">5.2.2.1</a>. Successful ASP Fail-over scenario</span>
+
+ 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------------------------&gt;
+ &lt;---------------------------ASP Inact Ack----------------------+
+ &lt;---------------NTFY (ASP-a1 Inactive)--------------+
+ +---------------------ASP Act-----------------------&gt;
+ &lt;-------------------ASP Act Ack---------------------+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 120]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-121" id="page-121" href="#page-121" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h5"><a class="selflink" name="section-5.2.2.2" href="#section-5.2.2.2">5.2.2.2</a>. Unsuccessful ASP Fail-over scenario</span>
+
+ 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.
+
+<span class="h2"><a class="selflink" name="section-6" href="#section-6">6</a>. Security Considerations</span>
+
+ The security considerations discussed for the 'Security
+ Considerations for SIGTRAN Protocols' [<a href="#ref-3788" title="&quot;Security Considerations for Signaling Transport (SIGTRAN) Protocols&quot;">3788</a>] document apply to this
+ document.
+
+<span class="h2"><a class="selflink" name="section-7" href="#section-7">7</a>. IANA Considerations</span>
+
+<span class="h3"><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. SCTP Payload Protocol ID</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. Port Number</span>
+
+ 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.
+
+<span class="h3"><a class="selflink" name="section-7.3" href="#section-7.3">7.3</a>. Protocol Extensions</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 121]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-122" id="page-122" href="#page-122" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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 [<a href="#ref-2434" title="&quot;Guidelines for Writing an IANA Considerations Section in RFCs&quot;">2434</a>].
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-7.3.1" href="#section-7.3.1">7.3.1</a>. IETF Defined Message Classes</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-7.3.2" href="#section-7.3.2">7.3.2</a>. IETF Defined Message Types</span>
+
+ 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.
+
+<span class="h4"><a class="selflink" name="section-7.3.4" href="#section-7.3.4">7.3.4</a>. IETF-defined TLV Parameter Extension</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 122]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-123" id="page-123" href="#page-123" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ (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.
+
+<span class="h2"><a class="selflink" name="section-8" href="#section-8">8</a>. Timer Values</span>
+
+ 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
+
+<span class="h2"><a class="selflink" name="section-9" href="#section-9">9</a>. Acknowledgements</span>
+
+ 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.
+
+<span class="h2"><a class="selflink" name="section-10" href="#section-10">10</a>. References</span>
+
+<span class="h3"><a class="selflink" name="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
+
+ [<a name="ref-1123" id="ref-1123">1123</a>] Braden, R., Ed., "Requirements for Internet Hosts -
+ Application and Support", STD 3, <a href="https://tools.ietf.org/html/rfc1123">RFC 1123</a>, October
+ 1989.
+
+ [<a name="ref-2119" id="ref-2119">2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", <a href="https://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997.
+
+ [<a name="ref-2960" id="ref-2960">2960</a>] 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", <a href="https://tools.ietf.org/html/rfc2960">RFC 2960</a>, October 2000.
+
+ [<a name="ref-3629" id="ref-3629">3629</a>] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, <a href="https://tools.ietf.org/html/rfc3629">RFC 3629</a>, November 2003.
+
+ [<a name="ref-3788" id="ref-3788">3788</a>] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas,
+ "Security Considerations for Signaling Transport
+ (SIGTRAN) Protocols", <a href="https://tools.ietf.org/html/rfc3788">RFC 3788</a>, June 2004.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 123]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-124" id="page-124" href="#page-124" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ [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).
+
+<span class="h3"><a class="selflink" name="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
+
+ [<a name="ref-2434" id="ref-2434">2434</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", <a href="https://tools.ietf.org/html/bcp26">BCP 26</a>, <a href="https://tools.ietf.org/html/rfc2434">RFC</a>
+ <a href="https://tools.ietf.org/html/rfc2434">2434</a>, October 1998.
+
+ [<a name="ref-2719" id="ref-2719">2719</a>] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H.,
+ Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C.
+ Sharp, "Framework Architecture for Signalling
+ Transport", <a href="https://tools.ietf.org/html/rfc2719">RFC 2719</a>, October 1999.
+
+ [<a name="ref-3761" id="ref-3761">3761</a>] Falstrom, P. and M. Mealling, "The E.164 to Uniform
+ Resource Identifiers (URI) Dynamic Delegation
+ Discovery System (DDDS) Application (ENUM)", <a href="https://tools.ietf.org/html/rfc3761">RFC 3761</a>,
+ 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).'
+
+ [<a name="ref-RANAP" id="ref-RANAP">RANAP</a>] 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'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 124]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-125" id="page-125" href="#page-125" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h2"><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>. Signalling Network Architecture</span>
+
+<span class="h3"><a class="selflink" name="appendix-A.1" href="#appendix-A.1">A.1</a>. Generalized Peer-to-Peer Network Architecture</span>
+
+ 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.
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 125]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-126" id="page-126" href="#page-126" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="appendix-A.2" href="#appendix-A.2">A.2</a>. Signalling Gateway Network Architecture</span>
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 126]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-127" id="page-127" href="#page-127" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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.
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 127]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-128" id="page-128" href="#page-128" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+<span class="h3"><a class="selflink" name="appendix-A.3" href="#appendix-A.3">A.3</a>. Signalling Gateway Message Distribution Recommendations</span>
+
+<span class="h4"><a class="selflink" name="appendix-A.3.1" href="#appendix-A.3.1">A.3.1</a>. Connectionless Transport</span>
+
+ 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.
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 128]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-129" id="page-129" href="#page-129" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ - 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.
+
+<span class="h4"><a class="selflink" name="appendix-A.3.2" href="#appendix-A.3.2">A.3.2</a>. Connection-Oriented Transport</span>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 129]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-130" id="page-130" href="#page-130" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+<span class="grey">Loughney, et al. Standards Track [Page 130]</span></pre>
+<hr class='noprint' style='width: 96ex;' align='left'/><!--NewPage--><pre class='newpage'><a name="page-131" id="page-131" href="#page-131" class="invisible"> </a>
+<span class="grey"><a href="https://tools.ietf.org/html/rfc3868">RFC 3868</a> SUA October 2004</span>
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in <a href="https://tools.ietf.org/html/bcp78">BCP 78</a>, 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 <a href="https://tools.ietf.org/html/bcp78">BCP 78</a> and <a href="https://tools.ietf.org/html/bcp79">BCP 79</a>.
+
+ 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
+ <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
+
+ 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]
+
+</pre><br />
+ <span class="noprint"><small><small>Html markup produced by rfcmarkup 1.116, available from
+ <a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a>
+ </small></small></span>
+ </div>
+</body>
+</html>