idnits 2.17.1 draft-loughney-sigtran-sua-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 45 longer pages, the longest (page 2) being 117 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 161: '...Signaling Transport [1]. The delivery mechanism SHOULD meet the...' RFC 2119 keyword, line 497: '...The SUA layer MUST provide interworkin...' RFC 2119 keyword, line 530: '...SUA MUST use stream 0 for SUA manageme...' RFC 2119 keyword, line 789: '...Reason code MUST be included. See sec...' RFC 2119 keyword, line 854: '...flag is not used, it MUST be set to 0....' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1090 has weird spacing: '... may be sent ...' == Line 2083 has weird spacing: '...ges and disca...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This is to allow vendors to support their own extended message not defined by the IETF. It MUST not affect the operation of the SUA. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 2490, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2493, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2496, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2506, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2401 (ref. '9') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '11') Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Loughney Internet 2 Engineering Task Force Nokia 3 G. Sidebottom, Guy Mousseau 4 Issued: 8 March 2000 Nortel Networks 5 Expires: 8 September 2000 S. Lorusso 6 Unisphere Solutions 8 SS7 SCCP-User Adaptation Layer (SUA) 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as 'work in progress.' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To learn the current status of any Internet-Draft, please check the 31 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 This Internet Draft defines a protocol for the transport of any SS7 39 SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the Simple 40 Control Transport Protocol. Protocol elements are added to enable a 41 seamless operation of the SCCP-User peers in the SS7 and IP domains. 42 This protocol could be used between a Signaling Gateway (SG) and an IP- 43 based signaling node (or an IP-resident Database). It is assumed that 44 the SG receives SS7 signaling over a standard SS7 interface using the 45 SS7 Signaling Connection Control Part (SCCP) to provide transport from 46 the SS7 network to the SG. 48 1. Introduction.......................................................4 49 1.1 Scope ............................................................4 50 1.2 Terminology ......................................................4 51 1.3 Signaling Transport Architecture .................................6 52 1.3.1 Protocol Architecture for TCAP Transport ......................6 53 1.3.2 Protocol Architecture for RANAP Transport .....................6 54 1.3.3 IP-Based Signaling Network Architecture .......................7 55 1.3.4 ASP Fail-over Model and Terminology ...........................8 56 1.4 Services Provided by the SUA Layer ...............................9 57 1.4.1 Support for the transport of SCCP-User Messages ...............9 58 1.4.2 SCCP Protocol Class Support ...................................9 59 1.4.3 Native Management Functions ...................................9 60 1.4.4 Interworking with SCCP Network Management Functions ..........10 61 1.4.5 Support for the management between the SG and ASP. ...........10 62 1.5 Internal Functions Provided in the SUA Layer ....................10 63 1.5.1 Address Translation and Mapping at the SG ....................10 64 1.5.2 SCTP Stream Mapping ..........................................10 65 1.5.3 Congestion Control ...........................................10 66 1.6 Definition of SUA Boundaries ....................................10 67 1.6.1 Definition of the upper boundary .............................10 68 1.6.2 Definition of the lower boundary .............................11 69 1.6.3 SUA Peer Messages ............................................11 70 2 Protocol Elements...................................................11 71 2.1 Common Message Header ...........................................11 72 2.1.1 SUA Protocol Version .........................................12 73 2.1.2 Message Types ................................................12 74 2.1.3 Message Length ...............................................13 75 2.2 SUA Transfer Messages ...........................................13 76 2.2.1 Data Transfer ................................................13 77 2.2.2 Data Acknowledge .............................................14 78 2.3 Connection Messages .............................................15 79 2.3.1 Connection Request ...........................................15 80 2.3.2 Connection Acknowledge .......................................16 81 2.3.3 Release Request ..............................................17 82 2.3.4 Release Complete .............................................18 83 2.3.5 Reset Confirm ................................................18 84 2.3.6 Reset Request ................................................18 85 2.4 SS7 Signaling Network Management Messages .......................19 86 2.4.1 Destination Unavailable ......................................19 87 2.4.2 Destination Available ........................................19 88 2.4.3 Destination State Audit ......................................20 89 2.4.4 SS7 Network Congestion .......................................20 90 2.4.5 Destination User Part Unavailable ............................21 91 2.5 Application Server Process Maintenance Messages .................22 92 2.5.1 ASP Up (ASPUP) ...............................................22 93 2.5.2 ASP Down (ASPDN) .............................................22 94 2.5.3 ASP Active (ASPAC) ...........................................23 95 2.5.4 ASP Inactive (ASPIA) .........................................24 96 2.5.5 ASP Inactive Ack (ASPIAK) ....................................24 97 2.5.6 ASP Takeover (ASPTO) .........................................25 98 2.5.7 Notify (NTFY) ................................................26 99 2.5.8 No Active ASP (NAASP) ........................................27 100 2.6 Management Messages ............................................28 101 2.6.1 Error (ERR) ..................................................28 102 2.6.2 Audit ........................................................28 103 2.6.3 Stream Configuration .........................................29 104 2.6.4 Stream Configuration Ack .....................................30 105 2.7 Vendor Specific Message .........................................30 106 2.8 Paramters .......................................................32 107 2.8.1 Data .........................................................32 108 2.8.2 Sequence Number ..............................................32 109 2.8.3 Source Reference Number ......................................32 110 2.8.4 Destination Reference Number .................................33 111 2.8.5 Sending Address ..............................................33 112 2.8.6 Destination Address ..........................................33 113 2.8.7 Cause ........................................................33 114 2.8.8 Protocol Identifier ..........................................33 115 2.8.9 Network Appearance ...........................................34 116 2.8.10 Affected Destination Point Code .............................34 117 2.8.11 Info String .................................................34 118 2.8.12 Congestion Level ............................................35 119 2.8.13 Adaptation Layer Identifier .................................35 120 3 Procedures..........................................................35 121 3.1 Procedures to support the SUA Services ..........................35 122 3.1.1 Receipt of Local primitives ..................................36 123 3.2 Procedures to support the SUA Layer Management Services .........36 124 3.2.1 Layer Management primitives procedures .......................36 125 3.2.2 Receipt of Peer Management messages ..........................36 126 3.3 Procedures to support the SUA SCTP Management Services ..........36 127 3.3.1 State Maintenance ............................................36 128 3.3.2 ASPM procedures for primitives ...............................39 129 3.3.3 ASPM procedures for peer-to-peer messages ....................39 130 3.4 Procedures to support the SUA Services ..........................40 131 3.4.1 At an SG .....................................................40 132 3.4.2 At an ASP ....................................................41 133 4 Examples of SUA Procedures..........................................41 134 4.1 Establishment of Association ....................................41 135 4.2 ASP fail-over Procedures ........................................41 136 4.2.1 For Primary/Backup model .....................................41 137 4.3.2 ASP administrative switch-over for Primary/Backup model ......42 138 4.3 SUA/SCCP-User Boundary Examples .................................43 139 4.3.1 Data Tranfer .................................................43 140 5 Security............................................................43 141 5.1 Introduction ....................................................43 142 5.2 Threats .........................................................43 143 5.3 Protecting Confidentiality ......................................44 144 6 IANA Considerations.................................................44 145 6.1 SCTP Protocol ID ................................................44 146 6.2 Port Number .....................................................44 147 7 Acknowledgements....................................................44 148 8 Author's Addresses..................................................44 149 9 References..........................................................45 150 ANNEX A: IP-Endpoint to IP-Endpoint Architecture.....................45 151 1. Introduction 153 1.1 Scope 155 There is on-going integration of SCN networks and IP networks. IP 156 provides an effective way to transport user data, as well as for 157 operators to expand their networks. This document details the delivery 158 of SCCP-user messages (MAP & CAP over TCAP, RANAP, etc.) over IP, from 159 an SS7 Signaling Gateway (SG) to an IP-based signaling node (such as an 160 IP-resident Database) as described in the Framework Architecture for 161 Signaling Transport [1]. The delivery mechanism SHOULD meet the 162 following criteria: 164 * Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, 165 RANAP, etc.) 166 * Support for SCCP connectionless service. 167 * Support for SCCP connection oriented service. 168 * Support for the seamless operation of SCCP-User protocol peers 169 * Support for the management of SCTP transport associations between an 170 SG and one or more IP-based signaling nodes). 171 * Support for distributed IP-based signaling nodes. 172 * Support for the asynchronous reporting of status changes to 173 management 175 In other words, the SG will terminate SS7 MTP layers and SCCP layer and 176 deliver TCAP, RANAP and/or any other SCCP-User protocol messages over 177 SCTP associations to SCCP-User peers in distributed IP-Based signaling 178 nodes. Depending upon the SCCP-users supported, the SUA will need to 179 support SCCP connectionless service, SCCP connect-orient service or both 180 services. 182 1.2 Terminology 184 Application Server (AS) - A logical entity serving a specific Routing 185 Key. An example of an Application Server is a virtual switch element 186 handling all call processing for a unique range of PSTN trunks, 187 identified by an SS7 DPC/OPC/SSN. The AS contains a set of one or more 188 unique Application Server Processes, of which one or more is normally 189 actively processing traffic. 191 Application Server Process (ASP) - An Application Server Process serves 192 as an active or standby process of an Application Server (e.g., part of 193 a distributed virtual switch or database element). Examples of ASPs are 194 MGCs, IP SCPs, or IP-based HLRs. An ASP contains an SCTP end-point and 195 may be configured to process traffic within more than one Application 196 Server. 198 Association - An association refers to an SCTP association. The 199 association provides the transport for the delivery of MTP3-User 200 protocol data units and M3UA adaptation layer peer messages. 202 Routing Key - At the SG, the Routing Key describes a set of SS7 203 parameter/parameter-ranges that uniquely defines the range of signaling 204 traffic configured to be handled by a particular Application Server. An 205 example would be where a Routing Key consists of a particular DPC and 206 SSN to which all traffic would be directed to a articular Application 207 Server. Routing Keys are mutually exclusive in the sense that a 208 received SS7 signaling message cannot be directed to more than one 209 Routing Key. A Routing Key cannot extend across more than a single SS7 210 DPC, in order to more easily support SS7 Management procedures. It is 211 not necessary for the parameter ranges within a particular Routing Key 212 to be contiguous. 214 Routing Context - An Application Server Process may be configured to 215 process traffic within more than one Application Server. In this case, 216 the Routing Context parameter is exchanged between the SG and the ASP, 217 identifying the relevant Application Server. From the perspective of an 218 ASP, the Routing Context uniquely identifies the range of traffic 219 associated with a particular Application Server, which the ASP is 220 configured to receive from the SG. There is a 1:1 relationship between 221 a Routing Context value and a Routing Key at an SG. Therefore the 222 Routing Context can be viewed as an index into an SG Table containing 223 the SG Routing Keys. 225 Fail-over - The capability to re-route signaling traffic as required to 226 an alternate Application Server Process, or group of ASPs, within an 227 Application Server in the event of failure or unavailability of a 228 currently used Application Server Process. Fail-back may apply upon the 229 return to service of a previously unavailable Application Server 230 Process. 232 Signaling Point Management Cluster (SPMC) - A complete set of 233 Application Servers represented to the SS7 network under the same SS7 234 Point Code. SPMCs are used to sum the availability/congestion/User_Part 235 status of an SS7 destination point code that is distributed in the IP 236 domain, for the purpose of supporting MTP Level 3 management procedures 237 at an SG. 239 Network Appearance - The Network Appearance identifies an SS7 network 240 context for the purposes of logically separating the signaling traffic 241 between the SG and the Application Server Processes over a common SCTP 242 Association. An example is where an SG is logically partitioned to 243 appear as an element in four separate national SS7 networks. A Network 244 Appearance implicitly defines the SS7 Point Code(s), Network Indicator 245 and MTP3 protocol type/variant/version used within a specific SS7 246 network partition. An physical SS7 route-set or link-set at an SG can 247 appear in only one network appearance. The Network Appearance is not 248 globally significant and requires coordination only between the SG and 249 the ASP. 251 Network Byte Order - Most significant byte first, a.k.a. Big Endian. 253 Layer Management - Layer Management is a nodal function in an SG or ASP 254 that handles the inputs and outputs between the M3UA layer and a local 255 management entity. 257 Host - The computing platform that the ASP process is running on. 259 Stream - A stream refers to an SCTP stream; a uni-directional logical 260 channel established from one SCTP endpoint to another associated SCTP 261 endpoint, within which all user messages are delivered in-sequence 262 except for those submitted to the un-ordered delivery service. 264 Transport address - an address which serves as a source or destination 265 for the unreliable packet transport service used by SCTP. In IP 266 networks, a transport address is defined by the combination of an IP 267 address and an SCTP port number. Note, only one SCTP port may be 268 defined for each endpoint, but each SCTP endpoint may have multiple IP 269 addresses. 271 1.3 Signaling Transport Architecture 273 The framework architecture that has been defined for SCN signaling 274 transport over IP [1] uses multiple components, including an IP 275 transport protocol, a signaling common transport protocol and an 276 adaptation module to support the services expected by a particular SCN 277 signaling protocol from its underlying protocol layer. 279 In general terms, the architecture can be modeled as a client-server 280 architecture, where SG acts as the server and the ASP acts as the 281 client. 283 1.3.1 Protocol Architecture for TCAP Transport 285 In this architecture, the SCCP and SUA layers interface in the SG. There 286 needs to be interworking between these layers to provide for the 287 seamless transfer of the user messages as well as the management 288 messages. The SUA handles the SS7 address to IP address mapping. 290 ******** SS7 *************** IP ******** 291 * SEP *---------* *--------* * 292 * or * * SG * * ASP * 293 * STP * * * * * 294 ******** *************** ******** 296 +------+ +------+ 297 | TCAP | | TCAP | 298 +------+ +------+------+ +------+ 299 | SCCP | | SCCP | SUA | | SUA | 300 +------+ +------+------+ +------+ 301 | MTP3 | | MTP3 | | | | 302 +------| +------+ SCTP | | SCTP | 303 | MTP2 | | MTP2 | | | | 304 +------+ +------+------+ +------+ 305 | L1 | | L1 | IP | | IP | 306 +------+ +------+------+ +------+ 307 |_______________| |____________| 309 TCAP - Transaction Capability Application Protocol 310 STP - SS7 Signaling Transfer Point 312 1.3.2 Protocol Architecture for RANAP Transport 314 In this architecture, the SS7 application protocol is invoked at the SG. 315 For messages destined for an ASP, the SUA handles address translation, 316 for example by way of Global Title Translation or via mapping table, 317 resolving the destination specified by SS7 Application to a SCTP 318 association / IP address. 320 ******** SS7 *************** IP ******** 321 * SEP *---------* *--------* * 322 * or * * SG * * ASP * 323 * STP * * * * * 324 ******** *************** ******** 326 +------+ +-------------+ +------+ 327 | S7AP | | S7AP | | S7AP | 328 +------+ +------+------+ +------+ 329 | SCCP | | SCCP | SUA | | SUA | 330 +------+ +------+------+ +------+ 331 | MTP3 | | MTP3 | | | | 332 +------| +------+ SCTP | | SCTP | 333 | MTP2 | | MTP2 | | | | 334 +------+ +------+------+ +------+ 335 | L1 | | L1 | IP | | IP | 336 +------+ +------+------+ +------+ 337 |_______________| |____________| 339 S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP) 340 STP - SS7 Signaling Transfer Point 342 This architecture may simplify, in some cases, to carrying an SS7 343 application protocol between two IP based endpoints. In this scenario, 344 full SG functionality may not be needed. This architecture is 345 considered in Annex A. 347 1.3.3 IP-Based Signaling Network Architecture 349 The Signaling Gateway (SG) is the gateway node between the SS7 network 350 and the IP network. The SG will transport SCCP-user signaling traffic 351 from the SS7 network to the IP-based signaling nodes (for example IP- 352 resident Databases). The SUA protocol does not specify the performance 353 and reliability requirements needed for the transport of user signaling, 354 but relies on SCTP and the layers below to provide it. The SUA protocol 355 should be flexible enough to allow different configurations and 356 transport technology to allow the network operators to meet their 357 operation, management and performance requirements. 359 It is recommended that when realizing this protocol, the network 360 architecture allows for multiple hosts, to be attached to the SG(s). 361 Multiple associations can be used between the SGs and hosts to provide 362 failover scenarios. Also, it is advisable for several ASPs to be 363 located within the hosts, again for failover use. 365 Figure 1 shows an example network architecture which can support robust 366 operation and failover support. 368 ******** ************** 369 * *__________________________________________* ******** * HOST1 370 * * * * ASP1 * * 371 * SG1 * SCTP Associations * ******** * 372 * *__________________________________________* ******** * 373 * * * * ASP2 * * 374 * * * ******** * 375 * *_______________________ * ******** * 376 * * | * * ASP3 * * 377 ******** | * ******** * 378 | * . * 379 ******** | * . * 380 * *------------------------------------------* * 381 * * | * ******** * 382 * SG2 * SCTP Associations | * * ASPn * * 383 * *____________ | * ******** * 384 * * | | ************** 385 * *________ | | ************** 386 * * | | |__________________* ******** * HOST2 387 * * | | * * ASP1 * * 388 ******** | | * ******** * 389 | |_____________________________* ******** * 390 | * * ASP2 * * 391 | * ******** * 392 |_________________________________* ******** * 393 * * ASP3 * * 394 * ******** * 395 * . * 396 * . * 397 * * 398 * ******** * 399 * * ASPn * * 400 * ******** * 401 ************** 402 . 403 . 404 . 406 Figure 1 - Physical Model 408 1.3.4 ASP Fail-over Model and Terminology 410 The network address translation and mapping function of the SUA supports 411 ASP fail-over functions in order to support a high availability of 412 transaction processing capability. The SUA at the SG assign a unique 413 Application Server to all SCCP-user messages incoming from the SS7 414 network based on some information in the SCCP-user message. The SUA at 415 the SG may use a combination of the following information to make the 416 AS/ASP assignment: 418 Destination Point Code (DPC) 419 Originating Point Code (OPC) 420 Sub-System Number (SSN) 421 Global Title (GT) 423 An Application Server can be considered as a list of all ASPs 424 configured/registered to handle SCCP-user messages within a certain 425 range of routing information, known as a Routing Key. One or more ASPs 426 in the list may normally be active to handle traffic, while others may 427 while any others are inactive but available in the event of failure or 428 unavailability of the active ASP(s). 430 The fail-over model supports an "n+k" redundancy model, where "n" ASPs 431 is the minimum number of redundant ASPs required to handle traffic and 432 "k" ASPs are available to take over for a failed or unavailable ASP. 433 Note that "1+1" active/standby redundancy is a subset of this model. A 434 simplex "1+0" model is also supported as a subset, with no ASP 435 redundancy. 437 To avoid a single point of failure, it is recommended that a minimum of 438 two ASPs be resident in the list, resident in separate physical hosts 439 and therefore available over different SCTP Associations. 441 1.4 Services Provided by the SUA Layer 443 1.4.1 Support for the transport of SCCP-User Messages 445 The SUA needs to support the transfer of SCCP-user messages. The SUA 446 layer at the SG needs to seamlessly transport the SCCP-user messages. 448 1.4.2 SCCP Protocol Class Support 450 Depending upon the SCCP-users supported, the SUA shall support the 4 451 possible SCCP protocol classes transparently. The SCCP protocol classes 452 are defined as follows: 454 * Protocol class 0 provides unordered transfer of SCCP-user 455 messages in a connectionless manner. 457 * Protocol class 1 allows the SCCP-user to select the in- 458 sequence delivery of SCCP-user messages in a connectionless 459 manner. 461 * Protocol class 2 allows the bi-directional transfer of SCCP- 462 user messages by setting up a temporary or permanent signaling 463 connection. 465 * Protocol class 3 allows the features of protocol class 2 with 466 the inclusion of flow control. Detection of message loss or 467 mis-sequencing is included. 469 Protocol classes 0 and 1 make up the SCCP connectionless service. 470 Protocol classes 2 and 3 make up the SCCP connection-oriented service. 472 1.4.3 Native Management Functions 474 The SUA layer may provide management of the underlying SCTP layer to 475 ensure that SG-ASP transport is available according to the degree 476 specified by the SCCP-user application. 478 The SUA layer provides the capability to indicate errors associated with 479 the SUA-protocol messages and to provide notification to local 480 management and the remote peer as is necessary. 482 1.4.4 Interworking with SCCP Network Management Functions 484 The SUA layer needs to support the following SCCP network management 485 functions: 487 Coord Request 488 Coord Indication 489 Coord Response 490 Coord Confirm 491 State Request 492 State Indication 493 Pcstate Indication 495 1.4.5 Support for the management between the SG and ASP. 497 The SUA layer MUST provide interworking with SCCP management functions 498 at the SG for seamless inter-operation between the SCN network and the 499 IP network. It SHOULD: 501 * Provide an indication to the SCCP-user at an ASP that a remote SS7 502 endpoint/peer is unreachable. 503 * Provide an indication to the SCCP-user at an ASP that a remote SS7 504 endpoint/peer is reachable. 505 * Provide congestion indication to SCCP-user at an ASP. 506 * Provide the initiation of an audit of remote SS7 endpoints at the 507 SG. 509 1.5 Internal Functions Provided in the SUA Layer 511 1.5.1 Address Translation and Mapping at the SG 513 SCCP users may present the following options to address their peer 514 endpoints: 516 Global Title 517 DPC + SSN 518 OPC + SSN 520 If Global Titles are used, the rules detailed in Annex B of ITU Q.713 521 [2] should be consulted. 523 1.5.2 SCTP Stream Mapping 525 The SUA supports SCTP streams. The SG needs to maintain a list of SCTP 526 and SUA-users for mapping purposes. SCCP-users requiring sequenced 527 message transfer need to be sent over a stream supporting sequenced 528 delivery. 530 SUA MUST use stream 0 for SUA management messages. Stream 0 MUST 531 support sequenced delivery, in order to preserve the order of management 532 message delivery. 534 1.5.3 Congestion Control 536 1.6 Definition of SUA Boundaries 538 1.6.1 Definition of the upper boundary 539 The following primitives are supported between the SUA and an SCCP-user. 541 Connect Request 542 Connect Indication 543 Connect Responding 544 Connect Confirm 545 Data Request 546 Data Indication 547 Expedited Data Request 548 Expedited Data Indication 549 Disconnect Request 550 Disconnect Indication 551 Reset Request 552 Reset Indication 553 Reset Response 554 Reset Confirm 556 1.6.2 Definition of the lower boundary 558 The upper layer primitives provided by the SCTP are provided in [7]. 560 1.6.3 SUA Peer Messages 562 data transfer 563 data acknowledge 564 connection request 565 connection acknowledge 566 release request 567 release complete 568 reset confirm 569 reset request 570 ASP Up 571 ASP Down 572 ASP Active 573 ASP Inactive 574 ASP Takeover 575 Notify 576 No Active ASP 577 Error 578 Audit 579 Stream Configuration 580 Stream Configuration Acknowledge 581 Destination Unavailable 582 Destination Available 583 Destination State Audit 584 SS7 Network Congestion State 585 Destination User Part Unavailable 586 Vendor-Specific Message 588 2 Protocol Elements 590 The general message format includes a Common Message Header together 591 with a list of zero or more parameters as defined by the Message Type. 592 For forward compatibility, all Message Types may have attached 593 parameters even if none are specified in this version. 595 2.1 Common Message Header 597 The protocol messages for SCCP-User Adaptation require a message 598 structure which contains a version, message type, message length, and 599 message contents. This message header is common among all signaling 600 protocol adaptation layers: 602 0 1 2 3 603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | ver | spare | msg type | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | message length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 2.1.1 SUA Protocol Version 612 The version field (ver) contains the version of the SUA adaptation 613 layer. The supported versions are: 615 01 SUA version 1.0 617 2.1.2 Message Types 619 Data Transfer Messages 621 Data Transfer (DATR) 0x0501 622 Data Acknowledge (DAAC) 0x0502 624 Connection Messages 626 connection request (CORE) 0x0601 627 connection acknowledge (COAK) 0x0602 628 release request (RELRE) 0x0603 629 release complete (RELCO) 0x0604 630 reset confirm (RESCO) 0x0605 631 reset request (RESRE) 0x0606 633 Application Server Process Maintenance (ASPM) Messages 635 ASP Up (ASPUP) 0x0301 636 ASP Down (ASPDN) 0x0302 637 ASP Active (ASPAC) 0x0401 638 ASP Inactive (ASPIA) 0x0402 639 ASP Takeover (ASPTO) 0x0403 640 Notify (NTFY) 0x0404 641 No Active ASP (NAASP) 0x0405 643 SUA Management Messages 645 Error (ERR) 0x0001 646 Audit (AUD) 0x0002 647 Stream Configuration (SCO) 0x0003 648 Stream Configuration Acknowledge (SCA) 0x0004 650 SS7 Signaling Network Management (SSNM) Messages 652 Destination Unavailable (DUNA) 0x0201 653 Destination Available (DAVA) 0x0202 654 Destination State Audit (DAUD) 0x0203 655 SS7 Network Congestion State (SCON) 0x0204 656 Destination User Part Unavailable (DUPU) 0x0205 658 Other 660 Vendor-Specific Message (VEN) 0xFFFE 662 2.1.3 Message Length 664 The Message Length defines the length of the message in octets, 665 including the header. 667 2.2 SUA Transfer Messages 669 The following section describes the SUA Transfer messages and parameter 670 contents. The general message format includes a Common Message Header 671 together with a list of zero or more parameters as defined by the 672 Message Type. All Message Types can have attached parameters. 674 2.2.1 Data Transfer 676 This message transfers data between one SUA to another. 678 0 1 2 3 679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | a |b| c | d | spare | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 / optional parameters / 684 \ \ 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| Length | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 / data / 689 \ \ 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Flags 694 A class 695 B priority 696 C ack 697 D segmentation 699 The class flag indicates which SCCP class this data transfer is 700 supporting. The valid values for class are shown in the following table. 702 Value Description 703 0x0 Class 0 (connectionless service) 704 0x1 Class 1 (connectionless service) 705 0x2 Class 2 (connection-oriented service) 706 0x3 Class 3 (connection-oriented service) 708 The priority parameter indicates if the data expects expedited services. 709 The valid values are: 711 Value Description 712 0x0 Normal priority 713 0x1 Expedited priority 715 The acknowledge flag indicates the receiving end should send an 716 acknowledgement on receiving the data message. The valid values are: 718 Value Description 719 0x0 No acknowledgement 720 0x1 Acknowledge on error 721 0x2 Acknowledgement required 723 The segmentation flag indicates if message segmentation is present. The 724 valid values for segmentation are: 726 Value Description 727 0x0 No segmentation 728 0x1 First piece of segmented data 729 0x2 middle piece of segmented data 730 0x3 final piece of segmented data 732 Optional parameters include: 734 Sequence number 735 source reference number 736 destination reference number 737 sending address 738 destination address 740 Section 2.8 defines the format (in TLV format) for the optional 741 paramters. 743 Implementation note: 745 This message covers the following SCCP messages: unitdata (UDT), 746 extended unitdata (XUDT), data form 1 (DT1), data form 2 (DT2), 747 expedited data (ED), long unitdata (LUDT). 749 2.2.2 Data Acknowledge 751 0 1 2 3 752 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | a |b| c | d | spare | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 / optional parameters / 759 \ \ 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Flags 764 A class 765 B priority 766 C ack 767 D segmentation 769 The class flag indicates which SCCP class this data transfer is 770 supporting. The valid values for class are shown in the following table. 772 Value Description 773 0x0 Class 0 (connectionless service) 774 0x1 Class 1 (connectionless service) 775 0x2 Class 2 (connection-oriented service) 776 0x3 Class 3 (connection-oriented service) 778 The priority parameter indicates if the data expects expedited services. 779 The valid values are: 781 Value Description 782 0x0 Normal priority 783 0x1 Expedited priority 785 The acknowledge flag is set to 0 787 The segment parameter is set to 0. 789 Reason code MUST be included. See section 2.8 for additional 790 details. 792 Optional parameters include: 794 data 795 cause 796 sequence number 797 destination reference number 798 sending address 799 destination address 801 Implementation note: 803 This message covers the following SCCP messages: protocol data unit 804 error (ERR), long unitdata service (LUDTS), unitdata service (UDTS), 805 extended unitdata service (XUDTS), data acknowledgement (AK), expedited 806 data acknowledgement (EA). 808 2.3 Connection Messages 810 The connection messages are used in the connection-oriented services 811 provided by the SUA, indicated by protocol class 2 or 3. The release 812 messages are used only for SCCP-users requesting protocol class 3. 814 2.3.1 Connection Request 816 0 1 2 3 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | a |b| c | d | spare | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | source reference number | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| Parameter Length | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 / destination address / 828 \ \ 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 / optional paramters / 831 \ \ 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Flags 835 A class 836 B priority 837 C ack 838 D segmentation 840 The class flag indicates which SCCP class this data transfer is 841 supporting. The valid values for class are shown in the following table. 843 Value Description 844 0x2 Class 2 (connection-oriented service) 845 0x3 Class 3 (connection-oriented service) 847 The priority flag indicates if the data expects expedited services. The 848 valid values are: 850 Value Description 851 0x0 Normal priority 852 0x1 Expedited priority 854 The acknowledge flag is not used, it MUST be set to 0. 856 The segmentation flag is not used, it MUST be set to 0. 858 Optional parameters include: 860 Data 861 Sending Address 863 2.3.2 Connection Acknowledge 865 0 1 2 3 866 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | a |b| c | d | spare | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | destination reference number | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Flags 877 A class 878 B priority 879 C ack 880 D segmentation 882 The class flag indicates which SCCP class this data transfer is 883 supporting. The valid values for class are shown in the following table. 885 Value Description 886 0x2 Class 2 (connection-oriented service) 887 0x3 Class 3 (connection-oriented service) 889 The priority flag indicates if the data expects expedited services. The 890 valid values are: 892 Value Description 893 0x0 Normal priority 894 0x1 Expedited priority 896 The acknowledge flag is not used, it MUST be set to 0. 898 The segmentation flag is not used, it MUST be set to 0. 900 Optional parameters include: 902 Data 903 cause 904 Source reference number 905 destination reference number 906 destination address 908 Implementation note: 910 This message covers the following SCCP messages: connection confirm 911 (CC), connection refused (CREF). 913 2.3.3 Release Request 915 0 1 2 3 916 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | a |b| c | d | spare | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | source reference number | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | destination reference number | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | reason code | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 / optional parameters / 933 \ \ 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Flags 938 A class 939 B priority 940 C ack 941 D segmentation 943 The class flag indicates which SCCP class this data transfer is 944 supporting. The valid values for class are shown in the following table. 946 Value Description 947 0x2 Class 2 (connection-oriented service) 948 0x3 Class 3 (connection-oriented service) 950 The priority parameter indicates if the data expects expedited services. 951 The valid values are: 953 Value Description 954 0x0 Normal priority 955 0x1 Expedited priority 957 The acknowledge flag is not used, it MUST be set to 0. 959 The segmentation flag is not used, it MUST be set to 0. 961 Optional parameters include: 963 data 964 result 966 Section 2.8 defines the format (in TLV format) for the optional 967 paramters. 969 2.3.4 Release Complete 971 0 1 2 3 972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | a |b| c | d | spare | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | source reference number | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | destination reference number | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 All flags MUST be set to 0. 987 2.3.5 Reset Confirm 989 0 1 2 3 990 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | a |b| c | d | spare | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | source reference number | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | destination reference number | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 All flags MUST be set to 0. 1005 2.3.6 Reset Request 1006 0 1 2 3 1007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | a |b| c | d | spare | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | source reference number | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | destination reference number | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | reason code | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 All flags MUST be set to 0. 1026 2.4 SS7 Signaling Network Management Messages 1028 2.4.1 Destination Unavailable 1030 The DUNA message is sent from the SG to all concerned ASPs to indicate 1031 that the SG has determined that an SS7 destination is unreachable. The 1032 MTP3-User at the ASP is expected to stop traffic to the affected 1033 destination through the SG initiating the DUNA. 1035 The format for DUNA Message parameters is as follows: 1037 0 1 2 3 1038 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Affected DPC | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 / optional parameters / 1045 \ \ 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 The DUNA message contains the following parameters: 1050 Affected Destination Point Code 1052 Optional parameters include: 1054 Protocol Identifier 1055 Network Appearance 1056 Info String 1058 2.4.2 Destination Available 1060 The DAVA message is sent from the SG to all concerned ASPs to indicate 1061 that the SG has determined that an SS7 destination is now reachable. The 1062 ASP MTP3-User protocol is expected to resume traffic to the affected 1063 destination through the SG initiating the DUNA. 1065 0 1 2 3 1066 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Affected DPC | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 / optional parameters / 1073 \ \ 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 The DUNA message contains the following parameters: 1078 Affected Destination Point Code 1080 Optional parameters include: 1082 Protocol Identifier 1083 Network Appearance 1084 Info String 1086 2.4.3 Destination State Audit 1088 The DAUD message can be sent from the ASP to the SG to query the 1089 availability state of the SS7 routes to an affected destination. A 1090 DAUD may be sent periodically after the ASP has received a DUNA, until 1091 a DAVA is received. The DAUD can also be sent when an ASP recovers 1092 from isolation from the SG. 1094 0 1 2 3 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Affected DPC | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 / optional parameters / 1102 \ \ 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 The DUNA message contains the following parameters: 1107 Affected Destination Point Code 1109 Optional parameters include: 1111 Protocol Identifier 1112 Network Appearance 1113 Info String 1115 2.4.4 SS7 Network Congestion 1117 The SCON message can be sent from the SG to all concerned ASPs to 1118 indicate that the congestion level in the SS7 network to a specified 1119 destination has changed. 1121 0 1 2 3 1122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Affected DPC | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 / optional parameters / 1129 \ \ 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 The DUNA message contains the following parameters: 1134 Affected Destination Point Code 1136 Optional parameters include: 1138 Protocol Identifier 1139 Network Appearance 1140 Info String 1141 Congestion Level 1143 Implementation note: 1145 This message covers the following SCCP message: subsystem congested 1146 (SSC). 1148 2.4.5 Destination User Part Unavailable 1150 The DUPU message is used by a SG to inform an ASP that a remote peer 1151 at an SS7 node is unavailable. 1153 0 1 2 3 1154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Affected DPC | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | reason code | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 / optional parameters / 1165 \ \ 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 The DUPU message contains the following parameters: 1170 Affected Destination Point Code 1171 Reason 1173 Optional parameters include: 1175 Protocol Identifier 1176 Network Appearance 1177 Info String 1179 2.5 Application Server Process Maintenance Messages 1181 2.5.1 ASP Up (ASPUP) 1183 The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer 1184 that the Adaptation layer is ready to receive traffic or maintenance 1185 messages. 1187 The ASPUP message contains the following parameters: 1189 Adaptation Layer Identifier (optional) 1190 INFO String (optional) 1192 The format for ASPUP Message parameters is as follows: 1194 0 1 2 3 1195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Tag (0x2) | Length | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Adaptation Layer Identifier* | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Tag (0x3) | Length | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | INFO String* | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 The optional Adaptation Layer Identifier (ALI) is a string that 1207 identifies the adaptation layer. This string MUST be set to "SUA" which 1208 results in a length of 4. The ALI would normally only be used in the 1209 initial ASP Up message across a new SCTP association to ensure both 1210 peers are assuming the same adaptation layer protocol. 1212 Note: Strings are padded to 32-bit boundaries. The length field 1213 indicates the end of the string. 1215 2.5.2 ASP Down (ASPDN) 1217 The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer 1218 that the adaptation layer is not ready to receive traffic or maintenance 1219 messages. 1221 The ASPDN message contains the following parameters: 1223 Reason 1224 INFO String (Optional) 1226 The format for the ASPDN message parameters is as follows: 1228 0 1 2 3 1229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Reason | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Tag (0x4) | Length | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | INFO String* | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 The format and description of the optional Info String parameter is the 1239 same as for the DUNA message (See Section 2.3.2.1.) 1241 The Reason parameter indicates the reason that the remote SUA adaptation 1242 layer is unavailable. The valid values for Reason are shown in the 1243 following table. 1245 Value Description 1246 0x1 Processor Outage 1247 0x2 Management Inhibit 1249 Implementation note: 1251 This message covers the following SCCP message: subsystem-prohibited 1252 (SSP). 1254 2.5.3 ASP Active (ASPAC) 1256 The ASPAC message is sent by an ASP to indicate to an SG that it is 1257 Active and ready to be used. 1259 The ASPAC message contains the following parameters: 1261 Routing Context (Optional) 1262 INFO String (Optional) 1264 The format for the ASPAC message is as follows: 1266 0 1 2 3 1267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Tag (0xx) | Length | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Type | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Routing Context* | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Tag (0x4) | Length | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | INFO String* | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 The Type parameter identifies the ASPAC as an Over-ride or Load-share 1281 Active message. The valid values for Type are shown in the following 1282 table. 1284 Value Description 1285 0x1 Over-ride 1286 0x2 Load-share 1288 Within a particular Routing Context, only one Type can be used. An SG 1289 that receives an ASPAC with an incorrect type for a particular Routing 1290 Context will respond with an Error Message. 1292 The optional Routing Context parameter contains (a list of) integers 1293 indexing the Application Server traffic that the sending ASP is 1294 configured to receive. There is one-to-one relationship between an 1295 index entry and an AS Name. Because an AS can only appear in one 1296 Network Appearance, the Network Appearance parameter is not required in 1297 the ASPAC message 1299 An Application Server Process may be configured to process traffic for 1300 more than one logical Application Server. From the perspective of an 1301 ASP, a Routing Context defines a range of signaling traffic that the ASP 1302 is currently configured to receive from the SG. For example, an ASP 1303 could be configured to support call processing for multiple ranges of 1304 PSTN trunks and therefore receive related signaling traffic, identified 1305 by separate SS7 DPC/OPC. 1307 The format and description of the optional Info String parameter is the 1308 same as for the DUNA message. 1310 Implementation note: 1312 This message covers the following SCCP message: subsystem-allowed (SSA). 1314 2.5.4 ASP Inactive (ASPIA) 1316 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1317 longer an active ASP to be used from within a list of ASPs. The SG will 1318 respond with an ASPIA message and either discard incoming messages or 1319 buffer for a timed period and then discard. 1321 The contains the following parameters: 1323 Routing Context (Optional) 1324 INFO String (Optional) 1326 The format for the ASPIA message parameters is as follows: 1328 0 1 2 3 1329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Tag (0xx) | Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Routing Context | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Tag (04) | Length | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | INFO String* | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 The format and description of the optional Routing Context and Info 1341 String parameters is the same as for the ASPAC message. 1343 Implementation note: 1345 This message covers the following SCCP message: subsystem-out-of- 1346 service-request (SOR). 1348 2.5.5 ASP Inactive Ack (ASPIAK) 1350 The ASPIAK message is sent by the SG in response to an ASPIA to the 1351 sending ASP that it acknowledges the ASPIA. 1353 The contains the following parameters: 1355 Routing Context (Optional) 1356 INFO String (Optional) 1358 The format for the ASPIAK message parameters is as follows: 1360 0 1 2 3 1361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Tag (0xx) | Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Routing Context | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Tag (04) | Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | INFO String* | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 Implementation note: 1374 This message covers the following SCCP message: subsystem-out-of- 1375 service-grant (SOG). 1377 2.5.6 ASP Takeover (ASPTO) 1379 The ASPTO message is sent by an ASP to indicate to an SG that it will be 1380 replacing an active ASP, in a controlled manner. 1382 The ASPTO message contains the following parameters: 1384 Routing Context (Optional) 1385 ASP id (Optional) 1386 INFO String (Optional) 1388 The format for the ASPAC message is as follows: 1390 0 1 2 3 1391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Tag (0xx) | Length | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 / ASP id* / 1396 \ \ 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 / Routing Context* / 1399 \ \ 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Tag (0x4) | Length | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 / INFO String* / 1404 \ \ 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 The optional ASP id parameter identifies an ASP, that will be taken over 1408 by the ASP that is sending this message. SG would keep sending traffic 1409 to both the ASPs for some time. Either because of a timer or an explicit 1410 ASPIA message from the taken over ASP, the SG would remove that ASP from 1411 the active ASPs list. During the time when both ASPs receive traffic, 1412 all messages/traffic corresponding to new transactions/calls will be 1413 sent to the new ASP and traffic corresponding to the continued work 1414 would be sent to the old ASP. 1416 The optional Routing Context parameter contains (a list of) integers 1417 indexing the Application Server traffic that the sending ASP is 1418 configured to receive. There is one-to-one relationship between an 1419 index entry and an AS Name. Because an AS can only appear in one 1420 Network Appearance, the Network Appearance parameter is not required in 1421 the ASPAC message 1423 An Application Server Process may be configured to process traffic for 1424 more than one logical Application Server. From the perspective of an 1425 ASP, a Routing Context defines a range of signaling traffic that the 1426 ASP is currently configured to receive from the SG. For example, an 1427 ASP could be configured to support call processing for multiple ranges 1428 of PSTN trunks and therefore receive related signaling traffic, 1429 identified by separate SS7 DPC/OPC_ranges. 1431 The format and description of the optional Info String parameter is the 1432 same as for the DUNA message. 1434 2.5.7 Notify (NTFY) 1436 The NTFY message is sent by an SG to indicate any change of status in 1437 the AS or ASP to an ASP. SG sends this message to all concerned ASPs in 1438 an AS. 1440 The NTFY message contains the following parameters: 1442 Status Type 1443 Status Id 1444 INFO String (Optional) 1446 The format for the NTFY message parameters is as follows: 1448 0 1 2 3 1449 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Tag (0xx) | Length | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Status Type | Status Id | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 / Routing Context* / 1456 \ \ 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Tag (0x4) | Length | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 / INFO String* / 1461 \ \ 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 The Status Type parameter identifies the type of the status that is 1465 being notified. The valid values are shown in the following table. 1467 Value Description 1468 0x1 AS_STATE_CHANGE 1469 0x2 ASP_STATE_CHANGE 1471 The Status Id parameter identifies the status that is being notified. 1472 The valid values are shown in the following table. 1474 If the Status Type is AS_STATE_CHANGE 1476 Value Description 1477 0x1 AS_DOWN 1478 0x2 AS_UP 1479 0x3 AS_PART_ACTIVE 1480 0x4 AS_ACTIVE 1481 0x5 AS_PENDING 1483 If the Status Type is ASP_STATE_CHANGE 1485 Value Description 1486 0x1 ASP_DOWN 1487 0x2 ASP_UP 1488 0x3 ASP_ACT_NEW 1489 0x4 ASP_ACT_OLD 1490 0x5 AS_ACTIVE 1492 The format and description of the optional Routing Context and Info 1493 String parameters is the same as for the ASPAC message. 1495 2.5.8 No Active ASP (NAASP) 1497 The NAASP message is sent by the SG when there are no active ASPs within 1498 an AS. The determination on whether to send a NAASP message occurs when 1499 an ASP moves from Active to Inactive. When this occurs, if there are no 1500 other ASPs in the active state, then the NAASP message is sent to every 1501 ASP defined within the AS. 1503 The NAASP message contains the following parameters: 1505 AS Definition (Mandatory) 1506 INFO String (Optional) 1508 The format for the NAASP message parameters is as follows: 1510 0 1 2 3 1511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Tag (0xx) | Length | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 / AS Definition / 1516 \ \ 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Tag (0x4) | Length | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 / INFO String* / 1521 \ \ 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 The format of the AS Definition field is implementation-dependent, and 1525 therefore is specific to individual configurations. This field is an 1526 unstructured text string that carries the AS name and its associated 1527 ASPs. 1529 The following is an example. 1531 AS Definition string 1532 { 1533 AS: boston_region 1534 { 1535 ASP1: primary segment1 1536 ASP2: backup segment1 1537 ASP3: primary segment2 1538 ASP4: backup segment2 1539 ... 1540 } 1541 } 1543 2.6 Management Messages 1545 These messages are used for managing SUA and the representations of the 1546 SCCP subsystems in the SUA layer. 1548 2.6.1 Error (ERR) 1550 The ERR message is sent when an invalid value is found in an incoming 1551 message. 1553 The ERR message contains the following parameters: 1555 Error Code 1557 The format for the ERR message is as follows: 1559 0 1 2 3 1560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Message Type = | length | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Error Code | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 The Error Code can be one of the following values: 1569 Invalid Version 0x1 1570 Invalid Network Appearance 0x2 1571 Invalid SCN Version 0x3 1572 Invalid Adaptation Layer Identifier 0x4 1573 Invalid Stream Identifier 0x5 1574 Invalid Message Type 0x6 1576 2.6.2 Audit 1577 0 1 2 3 1578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | a |b| c | d | spare | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 / Optional Parameters / 1583 \ \ 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 Flags 1588 A class 1589 B priority 1590 C ack 1591 D segmentation 1593 The class flag indicates which SCCP class this data transfer is 1594 supporting. The valid values for class are shown in the following table. 1596 Value Description 1597 0x0 Class 0 (connectionless service) 1598 0x1 Class 1 (connectionless service) 1599 0x2 Class 2 (connection-oriented service) 1600 0x3 Class 3 (connection-oriented service) 1602 The priority flag MUST be set to 0. 1604 The acknowledge flag MUST be set to 0. 1606 The segmentation flag MUST be set to 0. 1608 Optional parameters include: 1610 sending address 1611 destination address 1613 Implementation note: 1615 This message covers the following SCCP messages: inactivity test (IT), 1616 subsystem-status-test (SST). 1618 2.6.3 Stream Configuration 1620 The Stream Configuration message allows for an ASP to indicate what 1621 which streams are supported and what range of traffic they can handle. 1622 Traffic ID is a locally configured variable, it has only local 1623 significance. It must be configured in the ASP and in the SG. A value 1624 of 0 indicates that any traffic may be supported on the stream. 1626 The SCO message contains the following parameters: 1628 Number of Streams 1629 Stream ID 1630 Traffic ID 1632 The format for the SCO message is as follows: 1634 0 1 2 3 1635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Message Type = | length | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | number of streams | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | stream id | Traffic ID | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 / . . . / 1644 \ \ 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 2.6.4 Stream Configuration Ack 1649 The Stream Configuration Ack message acknowledges the Stream 1650 Configuration message. 1652 The SCA message contains the following parameters: 1654 Number of Streams 1655 Stream ID 1656 Traffic ID 1658 The format for the SCO message is as follows: 1660 Result 1661 Data (optional) 1663 0 1 2 3 1664 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | Message Type = | length | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | result | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 / DATA / 1671 \ \ 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 The Result parameter can be one of the following values: 1676 Success 0x0 1677 Failure 0x1 1679 The Data parameter contains a list of stream IDs and Traffic IDs that 1680 the SG can support. 1682 2.7 Vendor Specific Message 1684 This is to allow vendors to support their own extended message not 1685 defined by the IETF. It MUST not affect the operation of the SUA. 1687 Endpoints not equipped to interpret the vendor-specific messages sent by 1688 a remote endpoint MUST ignore it (although it may be reported). 1689 Endpoints that do not receive desired vendor-specific information SHOULD 1690 make an attempt to operate without it, although they may do so (and 1691 report they are doing so) in a degraded mode. 1693 A summary of the Vendor-specific extension format is shown below. The 1694 fields are transmitted from left to right. 1696 0 1 2 3 1697 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Message Type = 0xFFFE | Parameter Length | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | Vendor-Id | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 \ \ 1704 / Parameter Value / 1705 \ \ 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 Type: 16 bit u_int 1710 0xFFFE for all Vendor-Specific parameters. 1712 Length: 16 bit u_int 1714 Indicate the size of the parameter in octets, including the 1715 Type, Length, Vendor-Id, and Value fields. 1717 Vendor-Id: 32 bit u_int 1719 The high-order octet is 0 and the low-order 3 octets are the 1720 SMI Network Management Private Enterprise Code of the Vendor 1721 in network byte order, as defined in the Assigned Numbers (RFC 1722 1700). 1724 Value: variable length 1726 The Value field is one or more octets. The actual format of the 1727 information is site or application specific, and a robust 1728 implementation SHOULD support the field as undistinguished 1729 octets. 1731 The codification of the range of allowed usage of this field is 1732 outside the scope of this specification. 1734 It SHOULD be encoded as a sequence of vendor type / vendor length 1735 / value fields, as follows. The parameter field is dependent on 1736 the vendor's definition of that attribute. An example encoding 1737 of the Vendor-Specific attribute using this method follows: 1739 0 1 2 3 1740 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Parameter Type = 0xFFFE | Parameter Length | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Vendor-Id | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | VS-Type | VS-Length | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 / VS-Value / 1749 \ \ 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 VS-Type: 16 bit u_int 1753 This field identifies the parameter included in the VS-Value 1754 field. It is assigned by the vendor. 1756 VS-Length: 16 bit u_int 1758 This field is the length of the vendor-specific parameter and 1759 Includes the VS-Type, VS-Length and VS-Value (if included) fields. 1761 VS-Value: Variable Length 1763 This field contains the parameter identified by the VS-Type field. 1764 It's meaning is identified by the vendor. 1766 2.8 Paramters 1768 Parameter Name Parameter ID 1769 ============== ============ 1770 Data 0x0001 1771 Sequence Number 0x0002 1772 Source Reference Number 0x0003 1773 Destination Reference Number 0x0004 1774 Source Address 0x0005 1775 Destination Address 0x0006 1776 Cause 0x0007 1778 2.8.1 Data 1780 0 1 2 3 1781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| length | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 / data / 1786 \ \ 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 2.8.2 Sequence Number 1791 0 1 2 3 1792 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Sequence number | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 2.8.3 Source Reference Number 1801 0 1 2 3 1802 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | source reference number | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 2.8.4 Destination Reference Number 1811 0 1 2 3 1812 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | destination reference number | 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 2.8.5 Sending Address 1821 0 1 2 3 1822 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| Parameter Length | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 / sending address / 1827 \ \ 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 2.8.6 Destination Address 1832 0 1 2 3 1833 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| Parameter Length | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 / destination address / 1838 \ \ 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 2.8.7 Cause 1843 0 1 2 3 1844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | reason code | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 Reason code may be one of the following reasons: 1853 Invalid Version 0x1 1854 Invalid Network Appearance 0x2 1855 Invalid SCN Version 0x3 1856 Invalid Adaptation Layer Identifier 0x4 1857 Invalid Stream Identifier 0x5 1858 Invalid Message Type 0x6 1860 2.8.8 Protocol Identifier 1862 The Protocol Identifier parameter identifies the SCCP version/variant. 1864 0 1 2 3 1865 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | protocol id | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 2.8.9 Network Appearance 1874 The Network Appearance parameter identifies the SS7 network 1875 context for the message, for the purposes of logically separating 1876 the signaling traffic between the SG and the Application Server 1877 Processes over common SCTP Associations. An example is where an 1878 SG is logically partitioned to appear as an element in four 1879 different national SS7 networks. A Network Appearance implicitly 1880 defines the SS7 Destination Point Code used, the SS7 Network 1881 Indicator value and SCCP/SCCP-User protocol type/variant/version 1882 used within the SS7 network partition. Where an SG operates in 1883 the context of a single SS7 network, or individual SCTP 1884 associations are dedicated to each SS7 network appearance, the 1885 Network Appearance parameter is not required. 1887 0 1 2 3 1888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | network appearance | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 2.8.10 Affected Destination Point Code 1897 The Affected DPC is provisionally a three-octet parameter to allow 14-, 1898 16- and 24-bit binary formatted SS7 Point Codes. Where the Affected 1899 Point Code is less than 24-bits, it is padded on the left to the 24-bit 1900 boundary. 1902 0 1 2 3 1903 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Affected DPC | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 2.8.11 Info String 1912 The INFO String parameter can carry any meaningful 8-BIT ASCII character 1913 string along with the message. Length of the INFO String parameter is 1914 from 0 to 255 characters. No procedures are presently identified for 1915 its use but the INFO String may be used by Operators for debugging 1916 purposes. 1918 0 1 2 3 1919 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1| length | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 / info string / 1924 \ \ 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 2.8.12 Congestion Level 1929 0 1 2 3 1930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | congestion level | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 The valid values for the optional Congestion Level parameter are shown 1938 in the following table. 1940 Value Description 1941 00 No Congestion or Undefined 1942 01 Congestion Level 1 1943 02 Congestion Level 2 1944 03 Congestion Level 3 1946 2.8.13 Adaptation Layer Identifier 1948 0 1 2 3 1949 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1| 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | ALI | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 The optional Adaptation Layer Identifier (ALI) is a string that 1957 identifies the adaptation layer. This string MUST be set to "SUA" which 1958 results in a length of 3. The ALI would normally only be used in the 1959 initial ASP Up message across a new SCTP association to ensure both 1960 peers are assuming the same adaptation layer protocol. 1962 3 Procedures 1964 The SUA layer needs to respond to various local primitives it receives 1965 from other layers as well as the messages that it receives from the peer 1966 SUA layers. This section describes the SCU procedures in response to 1967 these events. 1969 3.1 Procedures to support the SUA Services 1971 These procedures support the SUA transport of SCCP-User/SCCP boundary 1972 primitives. 1974 3.1.1 Receipt of Local primitives 1976 3.2 Procedures to support the SUA Layer Management Services 1978 3.2.1 Layer Management primitives procedures 1980 3.2.2 Receipt of Peer Management messages 1982 3.3 Procedures to support the SUA SCTP Management Services 1984 These procedures support the SUA management of SCTP Associations and ASP 1985 Paths between SGs and ASPs 1987 3.3.1 State Maintenance 1989 The M3UA layer on the SG needs to maintain the state of each ASP as 1990 input to the SGs address translation and mapping function. 1992 3.3.1.1 ASP States 1994 The state of each ASP is maintained in the M3UA layer in the SG. The 1995 state of an ASP changes due to events. The events include: 1997 * Reception of messages from that ASP's M3UA layer 1998 * Reception of messages from a different ASP's M3UA layer 1999 * Reception of indications from the SCTP layer 2000 * Switch over timer triggers 2002 The ASP state transition diagram is shown in Figure 4. The possible 2003 states of an ASP are: 2005 ASP-DOWN: The Application Server Process is unavailable. Initially all 2006 ASPs will be in this state. 2008 ASP-UP: The Application Server Process is available but application 2009 traffic is stopped. 2011 ASP-ACTIVE: The Application Server Process is available and application 2012 traffic is active. 2014 ASP-ACT-OLD: The Application Server Process is available and application 2015 traffic is active for continued work only. 2017 ASP-ACT-NEW: The Application Server Process is available and application 2018 traffic is active for new work only. 2020 Figure 4: ASP State Transition Diagram 2022 +-------------+ 2023 +----------------------| | 2024 | Some other /| ASP-ACTIVE |<--------+ 2025 | ASP / +-------------+ | 2026 | Takeover / ^ | | Ts 2027 | / ASP | | ASP | 2028 | / Active | | Inactive | 2029 | v | v | 2030 | +-------------+ +-------------+ +-------------+ 2031 | | | | | | | 2032 | | ASP-ACT-OLD |----->| ASP-UP |------>| ASP-ACT-NEW | 2033 | +-------------+ Ts / +-------------+ ASP +-------------+ 2034 | | ASP Inactive ^ | Takeover | 2035 |<---| | | | 2036 | | | | 2037 ASP Down/ | ASP | | ASP Down / | ASP 2038 SCTP CDI | Up | | SCTP CDI | Down/ 2039 | | v | SCTP 2040 | +-------------+ | CDI 2041 | | | | 2042 +------------------>| |<-------------+ 2043 | ASP-DOWN | 2044 +-------------+ 2046 SCTP CDI: The local SCTP layer's Communication Down Indication to the 2047 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 2048 indication when it detects the loss of connectivity to the ASP's SCTP 2049 layer. 2051 Ts: Switch over Timer Triggers 2053 3.3.1.2 AS States 2055 The state of the AS is maintained in the M3UA layer on the SG. 2057 The state of an AS changes due to events. These events include: 2059 * ASP state transitions 2060 * Recovery timer triggers 2062 The possible states of an AS are: 2064 AS-DOWN: The Application Server is unavailable. This state implies 2065 that all related ASPs are in the ASP-DOWN state for this AS. Initially 2066 the AS will be in this state. 2068 AS-UP: The Application Server is available but no application traffic 2069 is active (i.e., one or more related ASPs are in the ASP-UP state, but 2070 none in the ASP-Active state). 2072 AS-ACTIVE: The Application Server is available and application traffic 2073 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2075 AS-PENDING: An active ASP has transitioned from active to inactive or 2076 down and it was the last remaining active ASP in the AS. A recovery 2077 timer T(r) will be started and all incoming SCN messages will be queued 2078 by the SG. If an ASP becomes active before T(r) expires, the AS will 2079 move to AS-ACTIVE state and all the queued messages will be sent to the 2080 active ASP. 2082 If T(r) expires before an ASP becomes active, the SG stops queuing 2083 messages and discards all previously queued messages. The AS will move 2084 to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move 2085 to AS-DOWN state. 2087 Figure 5: AS State Transition Diagram 2089 +--------------------------------------+ 2090 | | 2091 V | 2092 +-------------+ | 2093 | | | 2094 | AS-PART-ACT |----------------------------+ | 2095 ->| | Last ACTIVE ASP | | 2096 N <> 1 and / | | trans to UP or DOWN | | 2097 an ASP trans/ +-------------+ | | 2098 ACTIVE / \ ^ | | 2099 / Nth ASP \ \ N <> 1 and | | 2100 / trans ACTIVE \ \ Nth ACTIVE ASP | | 2101 / \ \ trans to UP | | 2102 / \ \ or DOWN | | 2103 / N = 1 and V \ | | 2104 +----------+ one ASP trans ACTIVE +-------------+ | | 2105 | |------------------------>| | | | 2106 | AS-UP | | AS-ACTIVE | | | 2107 | | | | | | 2108 | |< -| | | | 2109 +----------+ \ / +-------------+ | | 2110 ^ | \ Tr Trigger / ^ | | | 2111 | | \ at least one / | | | | 2112 | | \ ASP in UP / | | | | 2113 | | \ / | | | | 2114 | | \ / | | | | 2115 | | \ /---/ N=1 and | | Last | | 2116 one ASP | | \ / one ASP | | ACTIVE ASP | | 2117 trans | | all ASP \-/----\ trans to | | trans to | | 2118 to UP | | trans to / \ ACTIVE | | UP or DOWN | | 2119 | | DOWN / \ | | | | 2120 | | / \ | | | | 2121 | | / \ | | | | 2122 | | /all ASP \ | | | | 2123 | v / trans to \ | v | | 2124 +----------+ / DOWN \ +-------------+ | | 2125 | |<--/ -| | | | 2126 | AS-DOWN | | AS-PENDING |<-------+ | 2127 | | | (queuing) | | 2128 | |<------------------------| |----------+ 2129 +----------+ Tr Trigger no ASP +-------------+ N <> 1 and 2130 in UP state an ASP trans ACTIVE 2132 Tr = Recovery Timer 2134 3.3.2 ASPM procedures for primitives 2136 Before the establishment of an SCTP association the ASP state at both 2137 the SG and ASP is assumed to be "Down". 2139 When the SUA layer receives an M-SCTP ESTABLISH request primitive from 2140 the Layer Management, the SUA layer will try to establish an SCTP 2141 association with the remote SUA peer. Upon reception of an eventual 2142 SCTP-Communication Up confirm primitive from the SCTP, the SUA layer 2143 will invoke the primitive M-SCTP ESTABLISH confirm to the Layer 2144 Management. 2146 Alternatively, if the remote SUA-peer establishes the SCTP association 2147 first, the SUA layer will receive an SCTP Communication Up indication 2148 primitive from the SCTP. The SUA layer will then invoke the primitive M- 2149 SCTP ESTABLISH indication to the Layer Management. 2151 Once the SCTP association is established, The SUA layer at an ASP will 2152 then find out the state of its local SUA-user from the Layer Management 2153 using the primitive M-ASP STATUS. Based on the status of the local SUA- 2154 User, the local ASP SUA Application Server Process Maintenance (ASPM) 2155 function will initiate the ASPM procedures, using the ASP-Up/-Down/- 2156 Active/-Inactive messages to convey the ASP-state to the SG - see 2157 Section 3.3.3. 2159 If the SUA layer subsequently receives an SCTP-Communication Down 2160 indication from the underlying SCTP layer, it will inform the Layer 2161 Management by invoking the M-SCTP STATUS indication primitive. The state 2162 of the ASP will be moved to "Down" at both the SG and ASP. 2164 At an ASP, the Layer Management may try to reestablish the SCTP 2165 association using M-SCTP ESTABLISH request primitive. 2167 3.3.3 ASPM procedures for peer-to-peer messages 2169 3.3.3.1 ASP-Up 2171 The SG will mark the path as up if an explicit ASP UP (ASPUP) message is 2172 received and internally the path is allowed to come up (i.e., not in a 2173 locked local maintenance state). An ASP UP (ASPUP) message will be sent 2174 to acknowledge the received ASPUP. The SG will respond to a ASPUP with a 2175 ASPDN message if the path is in a locked maintenance state. 2177 The SG will send a ASPUP message in response to a received ASPUP message 2178 from the ASP even if that path was already marked as UP at the SG. 2180 The paths are controlled by the ASP. The SG will only send ASPUP in 2181 response to the reception of a ASPUP message. 2183 The ASP will send ASPUP messages every 2 (add text regarding this being 2184 a configurable timer) seconds until the path comes up (i.e. until it 2185 receives a ASPUP message from the SG for that path). The ASP may decide 2186 to reduce the frequency (say to every 5 seconds) if the an 2187 acknowledgement is not received after a few tries. 2189 The ASP should wait for the ASPUP message from the SG before 2190 transmitting ASP maintenance messages (ASPIA or ASPAC) or SUA messages 2191 or it will risk message loss. The ASPUP message received from the SG is 2192 not acknowledged by the ASP. 2194 3.3.3.2 ASP Down 2196 The SG will mark the ASP as down and send a ASPDN message to the ASP if 2197 one of the following events occur: 2199 - an ASP Down(ASPDN) message is received from the ASP, 2200 - the ASP is locked by local maintenance. 2202 The SG will also send a ASPDN message when the ASP is already down and a 2203 ASPDN) message is received from the ASP. 2205 The ASP will send ASPDN whenever it wants to take down a ASP. Since the 2206 ASPDN messages to the SG or the ASPDN responses from the SG can be lost 2207 (for example, during a node failover), the ASP can send ASPDN messages 2208 every 2 seconds until the path comes down (i.e. until it receives a 2209 ASPDN message from the SG for that path). 2211 3.3.3.3 ASP Version Control 2213 If a ASP Up message with an unknown version is received, the receiving 2214 end will respond with an Error message. This will indicate to the 2215 sender which version the receiving node supports. 2217 This is useful when protocol version upgrades are being performed. A 2218 node with the newer version should support the older versions used on 2219 other nodes it is communicating with. 2221 The version field in the Error message header associated will indicate 2222 the version supported by the node. 2224 3.3.3.4 ASP Active 2226 When an ASP Active (ASPAC) message is received, the SG will start 2227 routing to that ASP. Reception of a ASPAC message overrides any 2228 previous ASPAC messages and results in the ASP associated with the ASPAC 2229 message to become the newly active ASP. 2231 3.3.3.5 ASP Inactive 2233 When a ASPIA message is received, message transmission to that ASP 2234 ceases. The SG will either discard all incoming messages or start 2235 buffering the incoming messages for T(r)seconds after which messages 2236 will be discarded. 2238 If the ASP is down, all of the Paths that were supported by that ASP 2239 are, by default, down. 2241 3.4 Procedures to support the SUA Services 2243 3.4.1 At an SG 2245 Details to be provided. 2247 3.4.2 At an ASP 2249 Details to be provided. 2251 4 Examples of SUA Procedures 2253 4.1 Establishment of Association 2255 SG ASP1 ASP2 2256 (Primary) (Backup) 2257 | | | 2258 <----ASP Up--------+ | 2259 +----ASP Up (Ack)--> | 2260 | | | 2261 <-----------------------ASP Up---------+ 2262 +-----------------------ASP Up (Ack)---> 2263 | | | 2264 <----ASP Active----+ | 2265 +-ASP Active Ack---> | 2266 | | | 2268 4.2 ASP fail-over Procedures 2270 4.2.1 For Primary/Backup model 2272 SG ASP1 ASP2 2273 (Primary) (Backup) 2274 | | | 2275 <----ASP Up--------+ | 2276 +----ASP Up (Ack)--> | 2277 | | | 2278 <-----------------------ASP Up---------+ 2279 +-----------------------ASP Up (Ack)---> 2280 | | | 2281 <----ASP Active----+ | 2282 +-ASP Active Ack---> | 2283 | | | 2284 +-Stream1 Proceed--> | 2285 +-Stream2 Proceed--> | 2286 | ... | | 2287 +-StreamN Proceed--> | 2288 | | | 2289 | Backhaul | | 2290 <=== Flow ======> | 2291 | Begins | | 2292 | | | 2293 | ********* | 2294 | *Failure* | 2295 | *Occurs * | 2296 | SCTP ********* ASP1 | 2297 <--Communication | Failure ---> 2298 | Down | Detection | 2299 | | | 2300 SG locally | | 2301 changes ASP1 | | 2302 to Inactive/Down | | 2303 | | | 2304 +----+ *************** | 2305 | Queue *Backhaul Flow* | 2306 | Msgs *Suspended * | 2307 <----+ *************** | 2308 | | | 2309 +--No Active ASP---> | 2310 +--------------------No Active ASP-----> 2311 | | | 2312 <---------------------ASP Active-------+ 2313 +---------------------ASP Active (Ack)-> 2314 | | | 2315 +-Stream1 Proceed----------------------> 2316 +-Stream2 Proceed----------------------> 2317 | ... | | 2318 +-StreamN Proceed----------------------> 2319 | | | 2320 <=====================Backhaul Flow====> 2321 | | Resumes | 2323 4.3.2 ASP administrative switch-over for Primary/Backup model 2325 SG ASP1 ASP2 2326 (Primary) (Backup) 2327 | | | 2328 <----ASP Up--------+ | 2329 +----ASP Up (Ack)--> | 2330 | | | 2331 <-----------------------ASP Up---------+ 2332 +-----------------------ASP Up (Ack)---> 2333 | | | 2334 <----ASP Active----+ | 2335 +-ASP Active Ack---> | 2336 | | | 2337 | ********** | | 2338 | *Backhaul* | | 2339 <==* Flow *======> | 2340 | * Begins * | | 2341 | ********** | | 2342 | | | 2343 <--ASP Inactive----+ | 2344 | | | 2345 +-Stream1 Inhibit--> | 2346 +-Stream2 Inhibit--> | 2347 | ... | | 2348 +-StreamN Inhibit--> | 2349 | | | 2350 +-ASP Inactive Ack-> | 2351 | | | 2352 | | ASP1 to ASP2 | 2353 | +--State Transfer---> 2354 | | | 2355 +----+ *************** | 2356 | Queue *Backhaul Flow* | 2357 | Msgs *Suspended * | 2358 <----+ *************** | 2359 | | | 2360 +--No Active ASP---> | 2361 +------------------+-No Active ASP-----> 2362 | | | 2363 <---------------------ASP Active-------+ 2364 +---------------------ASP Active (Ack)-> 2365 | | | 2366 +-Stream1 Proceed----------------------> 2367 +-Stream2 Proceed----------------------> 2368 | ... | | 2369 +-StreamN Proceed----------------------> 2370 | | | 2371 <=====================Backhaul Flow====> 2372 | | Resumes | 2374 4.3 SUA/SCCP-User Boundary Examples 2376 4.3.1 Data Tranfer 2378 This is an example of data tranfer, assuming associations are already 2379 established. 2381 SEP SG ASP 2382 | | | 2383 +--------UDT-------> | 2384 | +-------DATR--------> 2385 | | | 2387 5 Security 2389 5.1 Introduction 2391 SUA is designed to carry signaling messages for telephony services. As 2392 such, SUA must involve the security needs of several parties: the end 2393 users of the services; the network providers and the applications 2394 involved. Additional security requirements may come from local 2395 regulation. While having some overlapping security needs, any security 2396 solution should fulfill all of the different parties' needs. 2398 5.2 Threats 2400 There is no quick fix, one-size-fits-all solution for security. As a 2401 transport protocol, SUA has the following security objectives: 2403 * Availability of reliable and timely user data transport. 2404 * Integrity of user data transport. 2405 * Confidentiality of user data. 2407 SUA runs on top of SCTP. SCTP [6] provides certain transport related 2408 security features, such as: 2410 * Blind Denial of Service Attacks 2411 * Flooding 2412 * Masquerade 2413 * Improper Monopolization of Services 2415 When SUA is running in professionally managed corporate or service 2416 provider network, it is reasonable to expect that this network includes 2417 an appropriate security policy framework. The "Site Security Handbook" 2418 [11] should be consulted for guidance. 2420 When the network in which SUA runs in involves more than one party, it 2421 may not be reasonable to expect that all parties have implemented 2422 security in a sufficient manner. In such a case, it is recommended that 2423 IPSEC is used to ensure confidentiality of user payload. Consult [9] 2424 for more information on configuring IPSEC services. 2426 5.3 Protecting Confidentiality 2428 Particularly for mobile users, the requirement for confidentiality may 2429 include the masking of IP addresses and ports. In this case application 2430 level encryption is not sufficient; IPSEC ESP should be used instead. 2431 Regardless of which level performs the encryption, the IPSEC ISAKMP 2432 service should be used for key management. 2434 6 IANA Considerations 2436 6.1 SCTP Protocol ID 2438 A request will be made to IANA to assign protocol IDs. A protocol ID 2439 for the SUA will be registered. 2441 The protocol ID is included in each SCTP data chunk, to indicate which 2442 protocol SCTP is carrying. This protocol ID is not directly used by SCTP 2443 but may be used by certain network entities to identify the type of 2444 information being carried in this DATA chunk. 2446 6.2 Port Number 2448 A request will be made to IANA to assign an SUA Port Number. This Port 2449 Number is the port which the SG listen to when receiving SCTP datagrams. 2451 7 Acknowledgements 2453 The authors would like to thank Marja-Liisa Hamalainen and Markus 2454 Maanoja for their insightful comments and suggestions. 2456 8 Author's Addresses 2458 John Loughney 2459 Nokia Research Center 2460 PO Box 407 2461 FIN-00045 Nokia Group 2462 Finland 2463 john.loughney@nokia.com 2465 Greg Sidebottom 2466 Nortel Networks 2467 3685 Richmond Rd, 2468 Nepean, Ontario, Canada K2H 5B7 2469 gregside@nortelnetworks.com 2471 Guy Mousseau 2472 Nortel Networks 2473 3685 Richmond Rd 2474 Nepean, Ontario, Canada K2H 5B7 2476 Stephen Lorusso 2477 Unisphere Solutions 2478 200 Wheeler Road 2479 Burlington, MA 01803 2480 USA 2481 SLorusso@unispheresolutions.com 2483 9 References 2485 [1] RFC 2719, "Framework Architecture for Signaling Transport" 2487 [2] ITU-T Recommendations Q.711-714, 'Signaling System No. 7 (SS7) - 2488 Signaling Connection Control Part (SCCP)' 2490 [3] ANSI T1.112 'Signaling System Number 7 - Signaling Connection 2491 Control Part' 2493 [4] ITU-T Recommendation Q.771-775 'Signaling System No. 7 SS7) - 2494 Transaction Capabilities (TCAP) 2496 [5] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities 2497 Application Part' 2499 [6] 3G TS 25.413 V3.0.0 (2000-01) 'Technical Specification 3rd 2500 Generation Partnership Project; Technical Specification Group Radio 2501 Access Network; UTRAN Iu Interface RANAP Signalling' 2503 [7] Simple Control Transport Protocol , 2504 Dec. 1999, Work in Progress 2506 [8] MTP3-User Adaptation Layer , Dec. 2507 1999, Work in Progress 2509 [9] RFC 2401, "Security Architecture for the Internet Protocol", S. 2510 Kent, R. Atkinson, November 1998. 2512 [10]3G TS 25.420 V3.0.0 (2000-01) "Technical Specification 3rd 2513 Generation Partnership Project; Technical Specification Group Radio 2514 Access Network; UTRAN Iur Interface General Aspects and Principles" 2516 [11] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 2518 ANNEX A: IP-Endpoint to IP-Endpoint Architecture 2520 It is possible for the SUA protocol to be used between two endpoints 2521 located with an IP endpoint. In this architecture, only IP transport 2522 would be considered. This may be a likely scenario in an all IP 2523 wireless mobile network. In this architecture, the model would simplify 2524 to the figure below. 2526 ******** ******** 2527 * * * IPEP * 2528 * IPEP *---------* or * 2529 * * *IPSTP * 2530 ******** ******** 2532 +------+ +------+ 2533 | S7AP | | S7AP | 2534 +------+ +------+ 2535 | SUA | | SUA | 2536 +------+ +------+ 2537 | SCTP | | SCTP | 2538 +------+ +------+ 2539 | IP | | IP | 2540 +------+ +------+ 2541 |_______________ | 2542 +----------------+ 2544 S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP) 2546 It is possible that the IP endpoints would have connections to other 2547 hosts, for signaling transport purposes. This annex will consider 2548 possible modifications to the SUA protocol. 2550 Details to be provided. 2552 This draft expires September 8, 2000.