7536 lines
354 KiB
HTML
7536 lines
354 KiB
HTML
<!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'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </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&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=""Framework Architecture for Signalling Transport"">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=""Stream Control Transmission Protocol"">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 & 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=""Framework Architecture for Signalling Transport"">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=""Framework Architecture for Signalling Transport"">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=""The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)"">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 -> SUA
|
|
Purpose: LM requests ASP to establish an SCTP association with its
|
|
peer.
|
|
|
|
M-SCTP_ESTABLISH confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP confirms to LM that it has established an SCTP
|
|
association with its peer.
|
|
|
|
|
|
|
|
<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 -> LM
|
|
Purpose: SUA informs LM that a remote ASP has established an SCTP
|
|
association.
|
|
|
|
M-SCTP_RELEASE request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests ASP to release an SCTP association with its
|
|
peer.
|
|
|
|
M-SCTP_RELEASE confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP confirms to LM that it has released SCTP association
|
|
with its peer.
|
|
|
|
M-SCTP_RELEASE indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA informs LM that a remote ASP has released an SCTP
|
|
Association or the SCTP association has failed.
|
|
|
|
M-SCTP RESTART indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA informs LM that an SCTP restart indication has been
|
|
received.
|
|
|
|
M-SCTP_STATUS request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests SUA to report the status of an SCTP
|
|
association.
|
|
|
|
M-SCTP_STATUS confirm
|
|
Direction: SUA -> LM
|
|
Purpose: SUA responds with the status of an SCTP association.
|
|
|
|
M-SCTP STATUS indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports the status of an SCTP association.
|
|
|
|
M-ASP_STATUS request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests SUA to report the status of a local or remote
|
|
ASP.
|
|
|
|
M-ASP_STATUS confirm
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports status of local or remote ASP.
|
|
|
|
|
|
|
|
|
|
<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 -> SUA
|
|
Purpose: LM requests SUA to report the status of an AS.
|
|
|
|
M-AS_STATUS confirm
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports the status of an AS.
|
|
|
|
M-NOTIFY indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports that it has received a Notify message from its
|
|
peer.
|
|
|
|
M-ERROR indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports that it has received an Error message from its
|
|
peer or that a local operation has been unsuccessful.
|
|
|
|
M-ASP_UP request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests ASP to start its operation and send an ASP Up
|
|
message to its peer.
|
|
|
|
M-ASP_UP confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP reports that is has received an ASP UP Ack message
|
|
from its peer.
|
|
|
|
M-ASP_UP indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports it has successfully processed an incoming ASP
|
|
Up message from its peer.
|
|
|
|
M-ASP_DOWN request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests ASP to stop its operation and send an ASP Down
|
|
message to its peer.
|
|
|
|
M-ASP_DOWN confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP reports that is has received an ASP Down Ack message
|
|
from its peer.
|
|
|
|
M-ASP_DOWN indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports it has successfully processed an incoming ASP
|
|
Down message from its peer, or the SCTP association has
|
|
been lost/reset.
|
|
|
|
|
|
|
|
<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 -> SUA
|
|
Purpose: LM requests ASP to send an ASP Active message to its peer.
|
|
|
|
M-ASP_ACTIVE confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP reports that is has received an ASP Active Ack message
|
|
from its peer.
|
|
|
|
M-ASP_ACTIVE indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports it has successfully processed an incoming ASP
|
|
Active message from its peer.
|
|
|
|
M-ASP_INACTIVE request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests ASP to send an ASP Inactive message to its
|
|
peer.
|
|
|
|
M-ASP_INACTIVE confirm
|
|
Direction: LM -> SUA
|
|
Purpose: ASP reports that is has received an ASP Inactive
|
|
Ack message from its peer.
|
|
|
|
M-ASP_INACTIVE indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports it has successfully processed an incoming ASP
|
|
Inactive message from its peer.
|
|
|
|
M-AS_ACTIVE indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports that an AS has moved to the AS-ACTIVE state.
|
|
|
|
M-AS_INACTIVE indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports that an AS has moved to the AS-INACTIVE state.
|
|
|
|
M-AS_DOWN indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA reports that an AS has moved to the AS-DOWN state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<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 -> SUA
|
|
Purpose: LM requests ASP to register RK(s) with its peer by sending
|
|
REG REQ message.
|
|
|
|
M-RK_REG confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP reports that it has received REG RSP message with
|
|
registration status as successful from its peer.
|
|
|
|
M-RK_REG indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA informs LM that it has successfully processed an
|
|
incoming REG REQ message.
|
|
|
|
M-RK_DEREG request
|
|
Direction: LM -> SUA
|
|
Purpose: LM requests ASP to deregister RK(s) with its peer by
|
|
sending DEREG REQ message.
|
|
|
|
M-RK_DEREG confirm
|
|
Direction: SUA -> LM
|
|
Purpose: ASP reports that it has received DEREG RESP message with
|
|
deregistration status as successful from its peer.
|
|
|
|
M-RK_DEREG indication
|
|
Direction: SUA -> LM
|
|
Purpose: SUA informs LM that it has successfully processed an
|
|
incoming DEREG REQ from its peer.
|
|
|
|
<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=""Key words for use in RFCs to Indicate Requirement Levels"">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=""UTF-8, a transformation format of ISO 10646"">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-->
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Mask | Network | Cluster | Member |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|MSB-----------------------------------------LSB|
|
|
|
|
ITU 14-bit Point Code:
|
|
|
|
0 1 2 3-->
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|MSB--------------------LSB|
|
|
|
|
It is OPTIONAL for an implementation to generate an Affected Point
|
|
Code parameter with more than on Affected PC but the implementation
|
|
MUST accept and process an Affected Point Code parameter with more
|
|
than one Affected PC.
|
|
|
|
Mask: 8-bits
|
|
|
|
The Mask parameter can be used to identify a contiguous range of
|
|
Affected Destination Point Codes, independent of the point code
|
|
format. Identifying a contiguous range of Affected PCs may be useful
|
|
when reception of an MTP3 management message or a linkset event
|
|
simultaneously affects the availability status of a series of
|
|
destinations at an SG.
|
|
|
|
The Mask parameter is an integer representing a bit mask that can be
|
|
applied to the related Affected PC field. The bit mask identifies
|
|
how many bits of the Affected PC field are significant and which are
|
|
effectively "wild-carded". For example, a mask of "8" indicates that
|
|
the last eight bits of the PC is "wild-carded". For an ANSI 24-bit
|
|
Affected PC, this is equivalent to signalling that all PCs in an ANSI
|
|
Cluster are unavailable. A mask of "3" indicates that the last three
|
|
bits of the PC is "wild-carded". For a 14-bit ITU Affected PC, this
|
|
is equivalent to signalling that an ITU Region is unavailable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<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->SG, but bit 2 is set to "0" meaning "do not populate this in the
|
|
SCCP called party address". The effect is that the SG only uses the
|
|
PC to populate the MTP routing label DPC field, but does not include
|
|
it in the SCCP called party address.
|
|
|
|
In the SG->ASP direction, the source address PC parameter is present
|
|
(PC of SS7 SEP). However, this may have been populated from the OPC
|
|
in the received MTP routing label, not from the PC field in the SCCP
|
|
calling party address. In this case, bit 2 = "0" denotes that. The
|
|
AI gives further instructions to the SG how and when to populate the
|
|
SCCP addresses; in the SG->ASP direction, the AI gives information to
|
|
the ASP as to what was actually present in the received SCCP
|
|
addresses.
|
|
|
|
The address indicator is coded as follows:
|
|
|
|
Bit 1 is used to indicate inclusion of the SSN
|
|
|
|
0 Do not include SSN when optional
|
|
1 Include SSN
|
|
|
|
Bit 2 is used to indicate inclusion of the PC
|
|
|
|
0 Do not include PC, regardless of the routing indicator
|
|
value
|
|
1 Include PC
|
|
|
|
|
|
|
|
<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 2.1</a> [<a href="#ref-1123" title=""Requirements for Internet Hosts - Application and Support"">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=""Stream Control Transmission Protocol"">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
|
|
| | +--------------+
|
|
| | | |
|
|
| +------>| ASP-INACTIVE |
|
|
| | |
|
|
| +--------------+
|
|
| ^ |
|
|
ASPDN/ | | | ASPDN /
|
|
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
|
|
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
|
|
SCTP RI | | | SCTP RI
|
|
| | v
|
|
| +--------------+
|
|
| | |
|
|
+--------------------->| ASP-DOWN |
|
|
| |
|
|
+--------------+
|
|
|
|
|
|
The transitions in brackets are just valid for the IPSP SE model
|
|
communication while the rest are valid for both ASPs and IPSPs.
|
|
|
|
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
|
|
Down Indication to the Upper Layer Protocol (SUA) on an SGP. The
|
|
local SCTP layer will send this indication when it detects the loss
|
|
of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood
|
|
as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
|
|
notification from the SCTP layer.
|
|
|
|
SCTP RI: The local SCTP layer's Restart indication to the upper layer
|
|
protocol (SUA) on an SG. The local SCTP will send this indication
|
|
when it detects a restart from the ASP's peer SCTP layer.
|
|
|
|
<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- |---------------------------->| AS- |
|
|
| INACTIVE | | ACTIVE |
|
|
| |<--- | |
|
|
+----------+ \ +-------------+
|
|
^ | \ Tr Expiry, ^ |
|
|
| | \ at least one | |
|
|
| | \ ASP in ASP-INACTIVE | |
|
|
| | \ | |
|
|
| | \ | |
|
|
| | \ | |
|
|
one ASP | | all ASP \ one ASP | | Last ACTIVE
|
|
trans | | trans to \ trans to | | ASP trans to
|
|
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
|
|
ASP- | | \ ACTIVE | | or ASP-DOWN
|
|
INACTIVE| | \ | | (start Tr)
|
|
| | \ | |
|
|
| | \ | |
|
|
| v \ | v
|
|
+----------+ \ +-------------+
|
|
| | --| |
|
|
| AS-DOWN | | AS-PENDING |
|
|
| | | (queueing) |
|
|
| |<----------------------------| |
|
|
+----------+ Tr Expiry and no ASP +-------------+
|
|
in ASP-INACTIVE state
|
|
|
|
Tr = Recovery Timer
|
|
|
|
<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 < (Start - End + 1) <= 16 (label length maximum 16-bit)
|
|
- Start values are the same for each ASP within a RC
|
|
- End values are the same for each ASP within a RC
|
|
- TID and DRN Label values must be unique across the RC
|
|
|
|
If any of these checks fail, the SG refuses the ASPAC request, with
|
|
an error, "Invalid loadsharing label."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<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---------------->
|
|
<--------------ASP Up Ack--------------+
|
|
+------ASP Up------->
|
|
<---ASP Up Ack------+
|
|
+-------------ASP Active--------------->
|
|
<----------ASP Active Ack--------------+
|
|
<----------NTFY (ASP Active)-----------+
|
|
<-NTFY (ASP Active)-+
|
|
+--------SSA-------->
|
|
<--------SSA--------+
|
|
<-----------------DAVA-----------------+
|
|
+-----------------CLDT----------------->
|
|
+--------UDT-------->
|
|
|
|
<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)
|
|
<--------SSP--------+
|
|
<-----------------DUNA-----------------+
|
|
+-----------------DAUD----------------->
|
|
+--------SST-------->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<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------------->
|
|
<-----------ASP Inactive ACK-----------+
|
|
<--------------------NTFY (AS Pending)-+
|
|
<-NTFY (AS Pending)-+
|
|
+----ASP Active----->
|
|
<--ASP Active Ack---+
|
|
<-NTFY (AS Active)--+
|
|
<----------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------------->
|
|
<-----------ASP Inactive ACK-----------+
|
|
<--------------------NTFY (AS Pending)-+
|
|
<--NTFY (AS Pending)-+
|
|
After some time elapses (i.e., timeout).
|
|
+--------SSP-------->
|
|
<--------SST--------+
|
|
<-------------------NTFY (AS Inactive)-+
|
|
<-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 5.2.1</a> for handling collisions) [<a href="#ref-2960" title=""Stream Control Transmission Protocol"">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-------------------------->
|
|
<-----------------------------ASP Up Ack------------------------+
|
|
|
|
+--------------ASP Up--------------->
|
|
<------------ASP Up Ack-------------+
|
|
|
|
+---------------------------ACTIVE------------------------------->
|
|
<-------------------------ACTIVE Ack-----------------------------+
|
|
|
|
[Traffic can now flow directly between ASPs]
|
|
|
|
+-----------------------------CLDT------------------------------->
|
|
|
|
<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------------------------>
|
|
<---------------------------ASP Inact Ack----------------------+
|
|
<---------------NTFY (ASP-a1 Inactive)--------------+
|
|
+---------------------ASP Act----------------------->
|
|
<-------------------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=""Security Considerations for Signaling Transport (SIGTRAN) Protocols"">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=""Guidelines for Writing an IANA Considerations Section in RFCs"">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>
|