idnits 2.17.1 draft-ietf-sigtran-m3ua-10.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 95) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 108 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. ** There are 18 instances of too long lines in the document, the longest one being 380 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1744 has weird spacing: '...nt Code using...' == Line 2709 has weird spacing: '...nt Code n ...' == Line 3867 has weird spacing: '...uditing proce...' == Line 4134 has weird spacing: '...g). The sendi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a DATA chunk. -- The 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.) -- The document date (Nov 2001) is 8197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 1091 == Unused Reference: '19' is defined on line 4710, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 4729, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2960 (ref. '13') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '21') ** Obsolete normative reference: RFC 2401 (ref. '22') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '23') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2408 (ref. '24') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '25') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Sidebottom 2 INTERNET-DRAFT gregside consulting 3 Javier Pastor-Balb�s, Ian Rytina 4 Ericsson 5 Guy Mousseau 6 Nortel Networks 7 Lyndon Ong 8 Ciena 9 Hanns Juergen Schwarzbauer 10 Siemens 11 Klaus Gradischnig 12 NeuStar 13 Ken Morneault 14 Cisco 15 Mallesh Kalla 16 Telcordia 17 Normand Glaude 18 Performance Technologies 19 Brian Bidulock 20 OpenSS7 21 John Loughney 22 Nokia 24 Expires in six months Nov 2001 26 SS7 MTP3-User Adaptation Layer (M3UA) 27 29 Status of This Memo 31 This document is an Internet-Draft and is in full conformance with all 32 provisions of Section 10 of RFC 2026. Internet-Drafts are working 33 documents of the Internet Engineering Task Force (IETF), its areas, and 34 its working groups. Note that other groups may also distribute working 35 documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference material 40 or to cite them other than as 'work in progress.' 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 To learn the current status of any Internet-Draft, please check the 49 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 50 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 51 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 52 ftp.isi.edu (US West Coast). 54 Abstract 56 This Internet Draft defines a protocol for supporting the transport of 57 any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP 58 using the services of the Stream Control Transmission Protocol. Also, 59 provision is made for protocol elements that enable a seamless 60 operation of the MTP3-User peers in the SS7 and IP domains. This 61 protocol would be used between a Signalling Gateway (SG) and a Media 62 Gateway Controller (MGC) or IP-resident Database. It is assumed that 63 the SG receives SS7 signalling over a standard SS7 interface using the 64 SS7 Message Transfer Part (MTP) to provide transport. 66 TABLE OF CONTENTS 68 1. Introduction.......................................................4 69 1.1 Scope.........................................................4 70 1.2 Terminology...................................................4 71 1.3 M3UA Overview.................................................6 72 1.4 Functional Areas.............................................10 73 1.5 Sample Configurations........................................16 74 1.6 Definition of M3UA Boundaries................................19 75 2. Conventions.......................................................24 76 3. M3UA Protocol Elements............................................24 77 3.1 Common Message Header........................................24 78 3.2 Variable Length Parameter....................................26 79 3.3 Transfer Messages............................................29 80 3.4 SS7 Signalling Network management (SSNM) Messages............32 81 3.5 ASP State Maintenance (ASPM) Messages........................41 82 3.6 Routing Key Management (RKM) Messages........................44 83 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................54 84 3.8 Management(MGMT) Messages....................................58 85 4. Procedures........................................................63 86 4.1 Procedures to Support the M3UA-User .........................63 87 4.2 Procedures to Support the Management of SCTP Associations ...66 88 4.3 AS and ASP State Maintenance.................................66 89 4.4 Routing Key Management Procedures............................79 90 4.5 Procedures to Support the Availability or Congestion Status 91 of SS7 Destination...........................................81 92 4.6 MTP3 Restart.................................................84 93 5. Examples of M3UA Procedures.......................................85 94 5.1 Establishment of Association and Traffic 95 Between SGs and ASPs.........................................85 96 5.2 ASP traffic Failover Examples................................89 97 5.3 Normal Withdrawal of an ASP from an Application Server 98 and Teardown of an Association...............................91 99 5.4.M3UA/MTP3-User Boundary Examples.............................91 100 5.5.Examples for IPSP Communication..............................95 101 6. Security..........................................................97 102 6.1 Introduction.................................................97 103 6.2 Threats......................................................97 104 6.3 Protecting Confidentiality...................................97 105 7. IANA Considerations...............................................98 106 7.1 SCTP Payload Protocol Identifier.............................98 107 7.2 M3UA Port Number.............................................98 108 7.3 M3UA Protocol Extensions.....................................99 109 8. Acknowledgements..................................................99 110 9. References........................................................99 111 11. Author's Addresses.............................................101 112 Appendix A..........................................................104 113 1. Introduction 115 This draft defines a protocol for supporting the transport of 116 any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP 117 using the services of the Stream Control Transmission Protocol [13]. Also, provision is made for protocol elements that enable a seamless 118 operation of the MTP3-User peers in the SS7 and IP domains. This 119 protocol would be used between a Signalling Gateway (SG) and a Media 120 Gateway Controller (MGC) or IP-resident Database [1]. 122 1.1 Scope 124 There is a need for Switched Circuit Network (SCN) signalling protocol 125 delivery from an SS7 Signalling Gateway (SG) to a Media Gateway 126 Controller (MGC) or IP-resident Database as described in the Framework 127 Architecture for Signalling Transport [1]. The delivery mechanism 128 should meet the following criteria: 130 * Support for the transfer of all SS7 MTP3-User Part messages (e.g., 131 ISUP [2,3,4], SCCP [5,6,7], TUP [8] , etc.) 132 * Support for the seamless operation of MTP3-User protocol peers 133 * Support for the management of SCTP transport associations and 134 traffic between an SG and one or more MGCs or IP-resident Databases 135 * Support for MGC or IP-resident Database process failover and load 136 sharing 137 * Support for the asynchronous reporting of status changes to 138 management 140 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 141 protocol layers [14,15,16] and deliver ISUP, SCCP and/or any other 142 MTP3-User protocol messages, as well as certain MTP network management 143 events, over SCTP transport associations to MTP3-User peers in MGCs or 144 IP-resident Databases. 146 1.2 Terminology 148 Application Server (AS) - A logical entity serving a specific Routing 149 Key. An example of an Application Server is a virtual switch element 150 handling all call processing for a unique range of PSTN trunks, 151 identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a 152 virtual database element, handling all HLR transactions for a 153 particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of 154 one or more unique Application Server Processes, of which one or more 155 is normally actively processing traffic. Note that there is a 1:1 156 relationship between an AS and a Routing Key. 158 Application Server Process (ASP) - A process instance of an Application 159 Server. An Application Server Process serves as an active or backup 160 process of an Application Server (e.g., part of a distributed virtual 161 switch or database). Examples of ASPs are processes (or process 162 instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP 163 endpoint and may be configured to process signalling traffic within 164 more than one Application Server. 166 Association - An association refers to an SCTP association. The 167 association provides the transport for the delivery of MTP3-User 168 protocol data units and M3UA adaptation layer peer messages. 170 IP Server Process (IPSP) - A process instance of an IP-based 171 application. An IPSP is essentially the same as an ASP, except that it 172 uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not 173 use the services of a Signalling Gateway node. 175 Failover - The capability to reroute signalling traffic as required 176 to an alternate Application Server Process, or group of ASPs, within an 177 Application Server in the event of failure or unavailability of a 178 currently used Application Server Process. Failover also applies upon 179 the return to service of a previously unavailable Application Server 180 Process. 182 Host - The computing platform that the process (SGP, ASP or IPSP) is 183 running on. 185 Layer Management - Layer Management is a nodal function that handles 186 the inputs and outputs between the M3UA layer and a local management 187 entity. 189 Linkset - A number of signalling links that directly interconnect two 190 signalling points, which are used as a module. 192 MTP - The Message Transfer Part of the SS7 protocol. 194 MTP3 - MTP Level 3, the signalling network layer of SS7 196 MTP3-User - Any protocol normally using the services of the SS7 MTP3 197 (e.g., ISUP, SCCP, TUP, etc.). 199 Network Appearance - The Network Appearance is a M3UA local reference 200 shared by SG and AS (typically an integer) that together with an 201 Signaling Point Code uniquely identifies an SS7 node by indicating 202 the specific SS7 network it belongs to. It can be used to distinguish 203 between signalling traffic associated with different networks being 204 sent between the SG and the ASP over a common SCTP association. An 205 example scenario is where an SG appears as an element in multiple 206 separate national SS7 networks and the same Signaling Point Code 207 value may be reused in different networks. 209 Network Byte Order: Most significant byte first, a.k.a Big Endian. 211 Routing Key: A Routing Key describes a set of SS7 parameters and 212 parameter values that uniquely define the range of signalling traffic 213 to be handled by a particular Application Server. Parameters within the 214 Routing Key cannot extend across more than a single Signalling Point 215 Management Cluster. 217 Routing Context - A value that uniquely identifies a Routing Key. 218 Routing Context values are either configured using a configuration 219 management interface, or by using the routing key management procedures 220 defined in this document. 222 Signalling Gateway Process (SGP) - A process instance of a Signalling 223 Gateway. It serves as an active, backup, loadsharing or broadcast 224 process of a Signalling Gateway. 226 Signalling Gateway - An SG is a signaling agent that receives/sends SCN 227 native signaling at the edge of the IP network [1]. An SG appears to 228 the SS7 network as an SS7 Signalling Point. An SG contains a set of 229 one or more unique Signalling Gateway Processes, of which one or more 230 is normally actively processing traffic. Where an SG contains more 231 than one SGP, the SG is a logical entity and the contained SGPs are 232 assumed to be coordinated into a single management view to the SS7 233 network and to the supported Application Servers. 235 Signalling Process - A process instance that uses M3UA to communicate 236 with other signalling processes. An ASP, an SGP and an IPSP are all 237 signalling processes. 239 Signalling Point Management Cluster (SPMC) - The complete set of 240 Application Servers represented to the SS7 network under a single MTP 241 entity (Signalling Point) in one specific Network Appearance. SPMCs 242 are used to aggregate the availability, congestion, and user part status 243 of an MTP entity (Signalling Point) that is distributed in the IP domain, 244 for the purpose of supporting MTP3 management procedures 245 towards the SS7 network. In some cases, the SG itself may also be a 246 member of the SPMC. In this case, the SG availability /congestion 247 /User_Part status should also be taken into account when considering any 248 supporting MTP3 management actions. 250 Stream - A stream refers to an SCTP stream; a unidirectional logical 251 channel established from one SCTP endpoint to another associated SCTP 252 endpoint, within which all user messages are delivered in-sequence 253 except for those submitted to the unordered delivery service. 255 1.3 M3UA Overview 257 1.3.1 Protocol Architecture. 259 The framework architecture that has been defined for SCN signalling 260 transport over IP [1] uses multiple components, including a common 261 signalling transport protocol and an adaptation module to support the 262 services expected by a particular SCN signalling protocol from its 263 underlying protocol layer. 265 Within the framework architecture, this document defines an MTP3-User 266 adaptation module suitable for supporting the transfer of messages of 267 any protocol layer that is identified to the MTP Level 3 as an MTP 268 User. The list of these protocol layers includes, but is not limited 270 to, ISDN User Part (ISUP) [2,3,4], Signalling Connection Control Part 271 (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP [9,10,11] or 272 RANAP [12] messages are transferred transparently by the M3UA protocol 273 as SCCP payload, as they are SCCP-User protocols. 275 It is recommended that M3UA use the services of the Stream Control 276 Transmission Protocol (SCTP) [13] as the underlying reliable common 277 signalling transport protocol. This is to take advantage of various 278 SCTP features such as: 280 - Explicit packet-oriented delivery (not stream-oriented), 281 - Sequenced delivery of user messages within multiple streams, 282 with an option for order-of-arrival delivery of individual 283 user messages, 284 - Optional multiplexing of user messages into SCTP datagrams, 285 - Network-level fault tolerance through support of multi-homing 286 at either or both ends of an association, 287 - Resistance to flooding and masquerade attacks, and 288 - Data segmentation to conform to discovered path MTU size. 290 Under certain scenarios, such as back-to-back connections without 291 redundancy requirements, the SCTP functions above might not be a 292 requirement and TCP MAY be used as the underlying common transport 293 protocol. 295 1.3.2 Services Provided by the M3UA Layer 297 The M3UA Layer at an ASP or IPSP provides the equivalent set of 298 primitives at its upper layer to the MTP3-Users as provided by the MTP 299 Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP 300 and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 301 services are offered remotely from an MTP3 Layer at an SGP, and not by 302 a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that 303 its local users are actually remote user parts over M3UA. In effect, 304 the M3UA extends access to the MTP3 layer services to a remote IP-based 305 application. The M3UA layer does not itself provide the MTP3 services. 306 However, in the case where an ASP is connected to more than one SG, 307 the M3UA layer at an ASP should maintain the status of configured SS7 308 destinations and route messages according to the availability and 309 congestion status of the routes to these destinations via each SG. 311 The M3UA layer may also be used for point-to-point signalling between 312 two IP Server Processes (IPSPs). In this case, the M3UA layer provides 313 the same set of primitives and services at its upper layer as the MTP3. 314 However, in this case the expected MTP3 services are not offered 315 remotely from an SGP. The MTP3 services are provided but the 316 procedures to support these services are a subset of the MTP3 317 procedures due to the simplified point-to-point nature of the IPSP to 318 IPSP relationship. 320 1.3.2.1 Support for the Transport of MTP3-User Messages 322 The M3UA layer provides the transport of MTP-TRANSFER primitives across 323 an established SCTP association between an SGP and an ASP or between 324 IPSPs. 326 At an ASP, in the case where a destination is reachable via multiple 327 SGPs, the M3UA layer must also choose via which SGP the message is to 328 be routed or support load balancing across the SGPs, minimizing 329 missequencing. 331 The M3UA layer does not impose a 272-octet signalling information field 332 (SIF) length limit as specified by the SS7 MTP Level 2 protocol [14] 333 [15] [16]. Larger information blocks can be accommodated directly by 334 M3UA/SCTP, without the need for an upper layer segmentation/reassembly 335 procedure as specified in recent SCCP or ISUP versions. However, in 336 the context of an SG, the maximum 272-octet block size must be followed 337 when interworking to a SS7 network that does not support the transfer 338 of larger information blocks to the final destination. This avoids 339 potential ISUP or SCCP fragmentation requirements at the SGPs. The 340 provisioning and configuration of the SS7 network determines the 341 restriction placed on the maximum block size. Some configurations 342 (e.g., Broadband MTP [20]) may permit larger block sizes. 344 1.3.2.2 Native Management Functions 346 The M3UA layer provides the capability to indicate errors associated 347 with received M3UA messages and to notify, as appropriate, local 348 management and/or the peer M3UA. 350 1.3.2.3 Interworking with MTP3 Network Management Functions 352 At the SGP, the M3UA layer provides interworking with MTP3 353 management functions to support seamless operation of the user SCN 354 signalling applications in the SS7 and IP domains. This includes: 356 - Providing an indication to MTP3-Users at an ASP that a destination 357 in the SS7 network is not reachable. 359 - Providing an indication to MTP3-Users at an ASP that a destination 360 in the SS7 network is now reachable. 362 - Providing an indication to MTP3-Users at an ASP that messages to a 363 destination in the SS7 network are experiencing SS7 congestion. 365 - Providing an indication to the M3UA layer at an ASP that the routes 366 to a destination in the SS7 network are restricted. 368 - Providing an indication to MTP3-Users at an ASP that a MTP3-User 369 peer is unavailable. 371 The M3UA layer at an ASP keeps the state of the routes to remote SS7 372 destinations and may initiate an audit of the availability, the 373 restricted or the congested state of remote SS7 destinations. This 374 information is requested from the M3UA layer at the SGP. 376 The M3UA layer at an ASP may also indicate to the SG that the M3UA 377 layer itself or the ASP or the ASP's Host is congested. 379 1.3.2.4 Support for the Management of SCTP Associations between the SGP 380 and ASPs. 382 The M3UA layer at the SGP maintains the availability state of all 383 configured remote ASPs, to manage the SCTP Associations and 384 the traffic between the M3UA peers. As well, the active/inactive and 385 congestion state of remote ASPs is maintained. 387 The M3UA layer MAY be instructed by local management to establish an 388 SCTP association to a peer M3UA node. This can be achieved using the 389 M-SCTP_ESTABLISH primitives (See Section 1.6.3 for a description of 390 management primitives) to request, indicate and confirm the 391 establishment of an SCTP association with a peer M3UA node. In order 392 to avoid redundant SCTP associations between two M3UA peers, one side 393 (client) SHOULD be designated to establish the SCTP association, or 394 M3UA configuration information maintained to detect redundant 395 associations (e.g., via knowledge of the expected local and remote SCTP 396 endpoint addresses). 398 Local management MAY request from the M3UA layer the status of the 399 underlying SCTP associations using the M-SCTP_STATUS request and 400 confirm primitives. Also, the M3UA MAY autonomously inform local 401 management of the reason for the release of an SCTP association, 402 determined either locally within the M3UA layer or by a primitive from 403 the SCTP. 405 Also the M3UA layer MAY inform the local management of the change in 406 status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS 407 request or M-AS_STATUS request primitives. 409 1.3.2.5 Support for the Management of Connections to Multiple SGPs 411 As shown in Figure 1 an ASP may be connected to multiple SGPs. In such 412 a case a particular SS7 destination may be reachable via more than one 413 SGP and/or SG, i.e., via more than one route. As MTP3 users only 414 maintain status on a destination and not on a route basis, the M3UA 415 layer must maintain the status (availability, restriction, and/or 416 congestion of route to destination) of the individual routes, derive 417 the overall availability or congestion status of the destination 419 from the status of the individual routes, and inform the MTP3 users 420 of this derived status whenever it changes. 422 1.4 Functional Areas 424 1.4.1 Signalling Point Code Representation 426 For example, within an SS7 network, a Signalling Gateway might be 427 charged with representing a set of nodes in the IP domain into the SS7 428 network for routing purposes. The SG itself, as a signalling point in 429 the SS7 network, might also be addressable with an SS7 Point Code for 430 MTP3 Management purposes. The SG Point Code might also be used for 431 addressing any local MTP3-Users at the SG such as a local SCCP layer. 433 An SG may be logically partitioned to operate in multiple SS7 network 434 appearances. In such a case, the SG could be addressable with a Point 435 Code in each network appearance, and represents a set of nodes in the 436 IP domain into each SS7 network. Alias Point Codes [15] may also be 437 used within an SG network appearance. 439 Where an SG contains more than one SGP, the MTP3 routeset, SPMC and 440 remote AS/ASP states of each SGP SHOULD be coordinated across all the 441 SGPs. Rerouting of traffic between the SGPs MAY also be supported. 443 Application Servers can be represented under the same Point 444 Code of the SG, their own individual Point Codes or grouped with other 445 Application Servers for Point Code preservation purposes. A single 446 Point Code may be used to represent the SG and all the Application 447 Servers together, if desired. 449 If an ASP or group of ASPs is available to the SS7 network via more 450 than one SG, each with its own Point Code, the ASP(s) will typically be 451 represented by a Point Code that is separate from any SG Point Code. 452 This allows, for example, these SGs to be viewed from the SS7 network 453 as "STPs", each 454 having an ongoing "route" to the same ASP(s). Under failure conditions 455 where the ASP(s) become(s) unavailable from one of the SGs, this 456 approach enables MTP3 route management messaging between the SG and SS7 457 network, allowing simple SS7 rerouting through an alternate SG without 458 changing the Destination Point Code Address of SS7 traffic to the 459 ASP(s). 461 Where a particular AS can be reached via more than one SGP, the 462 corresponding Routing Keys in the SGPs should be identical. (Note: 463 It is possible for the SGP Routing Key configuration data to be 464 temporarily out-of-sync during configuration updates). 466 +--------+ 467 | | 468 +------------+ SG 1 +--------------+ 469 +-------+ | SS7 links | "STP" | IP network | ---- 470 | SEP +---+ +--------+ +---/ \ 471 | or | |* | ASPs | 472 | STP +---+ +--------+ +---\ / 473 +-------+ | | | | ---- 474 +------------+ SG 2 +--------------+ 475 | "STP" | 476 +--------+ 478 * Note:. SG-to-SG communication (i.e., "C-links") is recommended for 479 carrier grade networks, using an MTP3 linkset or an equivalent, to 480 allow rerouting between the SGs in the event of route failures. 481 Where SGPs are used, inter-SGP communication might be used. 482 Inter-SGP protocol is outside of the scope of this document. 484 The following example shows a signalling gateway partitioned into two 485 network appearances. 487 SG 488 +-------+ +---------------+ 489 | SEP +--------------| SS7 Ntwk |M3UA| ---- 490 +-------+ SS7 links | "A" | | / \ 491 |__________| +-----------+ ASPs | 492 | | | \ / 493 +-------+ | SS7 Ntwk | | ---- 494 | SEP +--------------+ "B" | | 495 +-------+ +---------------+ 497 1.4.2 Routing Contexts and Routing Keys 499 1.4.2.1 Overview 501 The distribution of SS7 messages between the SGP and the Application 502 Servers is determined by the Routing Keys and their associated Routing 503 Contexts. A Routing Key is essentially a set of SS7 parameters used to 504 filter SS7 messages, whereas the Routing Context parameter is a 4-byte 505 value (integer) that is associated to that Routing Key in a 1:1 506 relationship. The Routing Context therefore can be viewed as an index 507 into a sending node's Message Distribution Table containing the Routing 508 Key entries. 510 Possible SS7 address/routing information that comprise a Routing Key 511 entry includes, for example, the OPC, DPC, SIO found in the MTP3 512 routing label, or MTP3-User specific fields (such as the ISUP CIC, SCCP 513 subsystem number). Some example Routing Keys are: the DPC alone, the 514 DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN 515 combination. The particular information used to define an M3UA 516 Routing Key is application and network dependent, and none of the 517 above examples are mandated. 519 An Application Server Process may be configured to process signalling 520 traffic related to more than one Application Server, over a single SCTP 521 Association. In ASP Active and ASP Inactive management messages, the 522 signalling traffic to be started or stopped is discriminated by the 523 Routing Context parameter. At an ASP, the Routing Context parameter 524 uniquely identifies the range of signalling traffic associated with 525 each Application Server that the ASP is configured to receive. 527 1.4.2.2 Routing Key Limitations 529 Routing Keys SHOULD be unique in the sense that each received SS7 530 signalling message SHOULD have a full or partial match to a single 531 routing result. It is not necessary for the parameter range values 532 within a particular Routing Key to be contiguous. For example, an 533 AS could be configured to support call processing for multiple ranges 534 of PSTN trunks that are not represented by contiguous CIC values. 536 1.4.2.3 Managing Routing Contexts and Routing Keys 538 There are two ways to provision a Routing Key at an SGP. A Routing Key 539 may be configured statically using an implementation dependent 540 management interface, or dynamically using the M3UA Routing Key 541 registration procedure. 543 When using a management interface to configure Routing Keys, the 544 message distribution function within the SGP is not limited to the set 545 of parameters defined in this document. Other implementation dependent 546 distribution algorithms may be used. 548 1.4.2.4 Message Distribution at the SGP 550 To direct messages received from the SS7 MTP3 network to the 551 appropriate IP destination, the SGP must perform a message distribution 552 function using information from the received MTP3-User message. 554 To support this message distribution, the SGP might, for example, 555 maintain the equivalent of a network address translation table, mapping 556 incoming SS7 message information to an Application Server for a 557 particular application and range of traffic. This could be accomplished 558 by comparing elements of the incoming SS7 message to currently defined 559 Routing Keys in the SGP. These Routing Keys could in turn map directly 560 to an Application Server that is enabled by one or more ASPs. These 561 ASPs provide dynamic status information regarding their availability, 562 traffic handling capability and congestion to the SGP using various 563 management messages defined in the M3UA protocol. 565 The list of ASPs in an AS is assumed to be dynamic, taking into account 566 the availability, traffic handling capability and congestion status of 567 the individual ASPs in the list, as well as configuration changes and 568 possible failover mechanisms. 570 Normally, one or more ASPs are active (i.e., currently processing 571 traffic) in the AS but in certain failure and transition cases it is 572 possible that there may be no active ASP available. Broadcast, 573 loadsharing and backup scenarios are supported. 575 When there is no matching Routing Key entry for an incoming SS7 576 message, a default treatment MAY be specified. Possible solutions are 577 to provide a default Application Server at the SGP that directs all 578 unallocated traffic to a (set of) default ASP(s), or to drop the 579 message and provide a notification to layer management. The treatment 580 of unallocated traffic is implementation dependent. 582 1.4.2.5 Message Distribution at the ASP 584 The ASP must choose an SGP to direct a message to the SS7 network. 585 This is accomplished by observing the Destination Point Code (and 586 possibly other elements of the outgoing message such as the SLS value). 588 Implementation Note: Where more than one route (or SGP) is 589 possible for routing to the SS7 network, the ASP could, for example, 590 maintain a dynamic table of available SGP routes for the SS7 591 destinations, taking into account the SS7 destination 592 availability/restricted/congestion status received from the SGP(s), the 593 availability status of the individual SGPs and configuration changes 594 and failover mechanisms. There is, however, no M3UA messaging to manage 595 the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging). 597 Whenever an SCTP association to an SGP exists, the SGP is assumed to 598 be ready for the purposes of responding to M3UA ASPSM messages 599 (Refer to Section 3). 601 1.4.3 SS7 and M3UA Interworking 603 In the case of SS7 and M3UA interworking, the M3UA adaptation layer is 604 designed to provide an extension of the MTP3 defined user primitives. 606 1.4.3.1 Signalling Gateway SS7 Layers 608 The SG is responsible for terminating MTP Level 3 of the SS7 protocol, 609 and offering an IP-based extension to its users. 611 >From an SS7 perspective, it is expected that the Signalling Gateway 612 transmits and receives SS7 Message Signalling Units (MSUs) to and 613 from the PSTN over a standard SS7 network interface, using the SS7 614 Message Transfer Part (MTP) [14,15,16] to provide reliable transport of 615 the messages. 617 As a standard SS7 network interface, the use of MTP Level 2 signalling 618 links is not the only possibility. ATM-based High Speed Links can also 619 be used with the services of the Signalling ATM Adaptation Layer (SAAL) 620 [17,18]. 622 Note: It is also possible for IP-based interfaces to be present, using 623 the services of the MTP2-User Adaptation Layer (M2UA) [26] or M2PA [27]. 625 These could be terminated at a Signalling Transfer Point (STP) or 626 Signalling End Point (SEP). Using the services of MTP3, the SG could 627 be capable of communicating with remote SS7 SEPs in a quasi-associated 628 fashion, where STPs may be present in the SS7 path between the SEP and 629 the SG. 631 1.4.3.2 SS7 and M3UA Interworking at the SG 633 The SGP provides a functional interworking of transport functions 634 between the SS7 network and the IP network by also supporting the M3UA 635 adaptation layer. It allows the transfer of MTP3-User signalling 636 messages to and from an IP-based Application Server Process where the 637 peer MTP3-User protocol layer exists. 639 For SS7 user part management, it is required that the MTP3-User 640 protocols at ASPs receive indications of SS7 signalling point 641 availability, SS7 network congestion, and remote User Part 642 unavailability as would be expected in an SS7 SEP node. To accomplish 643 this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives 644 received at the MTP3 upper layer interface at the SG need to be 645 propagated to the remote MTP3-User lower layer interface at the ASP. 647 MTP3 management messages (such as TFPs or TFAs received from the SS7 648 network) MUST NOT be encapsulated as Data message Payload Data and sent 649 either from SG to ASP or from ASP to SG. The SG MUST terminate these 650 messages and generate M3UA messages as appropriate. 652 1.4.3.3 Application Server 654 A cluster of application servers is responsible for providing the 655 overall support for one or more SS7 upper layers. From an SS7 656 standpoint, a Signalling Point Management Cluster (SPMC) provides 657 complete support for the upper layer service for a given point code. 658 As an example, an SPMC providing MGC capabilities could provide 659 complete support for ISUP (and any other MTP3 user located at the 660 point code of the SPMC) for a given point code. 662 In the case where an ASP is connected to more than one SGP, the M3UA 663 layer must maintain the status of configured SS7 destinations and route 664 messages according to availability/congestion/restricted status of the 665 routes to these SS7 destinations. 667 1.4.3.4 IPSP Considerations 669 Since IPSPs use M3UA in a point-to-point fashion, there is no concept 670 of routing of messages beyond the remote end. Therefore, SS7 and M3UA 671 interworking is not necessary for this model. 673 1.4.4 Redundancy Models 675 1.4.4.1 Application Server Redundancy 677 All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned 678 Routing Key at an SGP are mapped to an Application Server. 680 The Application Server is the set of all ASPs associated with a 681 specific Routing Key. Each ASP in this set may be active, inactive or 682 unavailable. Active ASPs handle traffic; inactive ASPs might be used 683 when active ASPs become unavailable. 685 The failover model supports an "n+k" redundancy model, where "n" ASPs 686 is the minimum number of redundant ASPs required to handle traffic and 687 "k" ASPs are available to take over for a failed or unavailable ASP. A 688 "1+1" active/backup redundancy is a subset of this model. A simplex 689 "1+0" model is also supported as a subset, with no ASP redundancy. 691 1.4.5 Flow Control 693 Local Management at an ASP may wish to stop traffic across an SCTP 694 association to temporarily remove the association from service 695 or to perform testing and maintenance activity. The function could 696 optionally be used to control the start of traffic on to a newly 697 available SCTP association. 699 1.4.6 Congestion Management 701 The M3UA layer is informed of local and IP network congestion by means 702 of an implementation-dependent function (e.g., an implementation- 703 dependent indication from the SCTP of IP network congestion). 705 At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3- 706 Users by means of an MTP-STATUS primitive, as per current MTP3 707 procedures, to invoke appropriate upper layer responses. 709 When an SG determines that the transport of SS7 messages to a 710 Signalling Point Management Cluster (SPMC) is encountering congestion, 711 the SG MAY trigger SS7 MTP3 Transfer Controlled management messages 712 to originating SS7 nodes, per the congestion procedures of the relevant 713 MTP3 standard. The triggering of SS7 MTP3 Management messages from an 714 SG is an implementation-dependent function. 716 The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 717 M3UA peer with an SCON message. When an SG receives a congestion 718 message (SCON) from an ASP, and the SG determines that an SPMC is now 719 encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled 720 management messages to concerned SS7 destinations according to 721 congestion procedures of the relevant MTP3 standard. 723 1.4.7 SCTP Stream Mapping. 725 The M3UA layer at both the SGP and ASP also supports the assignment of 726 signalling traffic into streams within an SCTP association. Traffic 727 that requires sequencing SHOULD be assigned to the same stream. To 728 accomplish this, MTP3-User traffic may be assigned to individual 729 streams based on, for example, the SLS value in the MTP3 Routing Label 730 or the ISUP CIC assignment, subject of course to the maximum number of 731 streams supported by the underlying SCTP association. 733 1.4.8 Client/Server Model 735 It is recommended that the SGP and ASP be able to support both client 736 and server operation. The peer endpoints using M3UA SHOULD be 737 configured so that one always takes on the role of client and the 738 other the role of server for initiating SCTP associations. The default 739 orientation would be for the SGP to take on the role of server while 740 the ASP is the client. In this case, ASPs SHOULD initiate the 741 SCTP association to the SGP. 743 In the case of IPSP to IPSP communication, the peer endpoints using 744 M3UA SHOULD be configured so that one always takes on the role of 745 client and the other the role of server for initiating SCTP 746 associations. 748 The SCTP and TCP Registered User Port Number Assignment for M3UA is 749 2905. 751 1.5 Sample Configurations 752 1.5.1 Example 1: ISUP Message Transport 754 ******** SS7 ***************** IP ******** 755 * SEP *---------* SGP *--------* ASP * 756 ******** ***************** ******** 758 +------+ +---------------+ +------+ 759 | ISUP | | (NIF) | | ISUP | 760 +------+ +------+ +------+ +------+ 761 | MTP3 | | MTP3 | | M3UA | | M3UA | 762 +------| +------+-+------+ +------+ 763 | MTP2 | | MTP2 | | SCTP | | SCTP | 764 +------+ +------+ +------+ +------+ 765 | L1 | | L1 | | IP | | IP | 766 +------+ +------+ +------+ +------+ 767 |_______________| |______________| 769 SEP - SS7 Signalling End Point 770 SCTP - Stream Control Transmission Protocol 771 NIF - Nodal Interworking Function 773 In this example, the SGP provides an implementation-dependent nodal 774 interworking function (NIF) that allows the MGC to exchange SS7 775 signalling messages with the SS7-based SEP. The NIF within the SGP 776 serves as the interface within the SGP between the MTP3 and M3UA. This 777 nodal interworking function has no visible peer protocol with either 778 the MGC or SEP. It also provides network status information to one or 779 both sides of the network. 781 For internal SGP modeling purposes, at the NIF level, SS7 signalling 782 messages that are destined to the MGC are received as MTP-TRANSFER 783 indication primitives from the MTP Level 3 upper layer interface, 784 translated to MTP-TRANSFER request primitives, and sent to the local 785 M3UA-resident message distribution function for ongoing routing to the 786 final IP destination. Messages received from the local M3UA network 787 address translation and mapping function as MTP-TRANSFER indication 788 primitives are sent to the MTP Level 3 upper layer interface as MTP- 789 TRANSFER request primitives for ongoing MTP Level 3 routing to an SS7 790 SEP. For the purposes of providing SS7 network status information the 791 NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 792 primitives received from the MTP Level 3 upper layer interface to the 793 local M3UA-resident management function. In addition, as an 794 implementation and network option, restricted destinations are 795 communicated from MTP network management to the local M3UA-resident 796 management function. 798 1.5.2 Example 2: SCCP Transport between IPSPs 799 ******** IP ******** 800 * IPSP * * IPSP * 801 ******** ******** 803 +------+ +------+ 804 |SCCP- | |SCCP- | 805 | User | | User | 806 +------+ +------+ 807 | SCCP | | SCCP | 808 +------+ +------+ 809 | M3UA | | M3UA | 810 +------+ +------+ 811 | SCTP | | SCTP | 812 +------+ +------+ 813 | IP | | IP | 814 +------+ +------+ 815 |________________| 817 This example shows an architecture where no Signalling Gateway is used. 818 In this example, SCCP messages are exchanged directly between two IP- 819 resident IPSPs with resident SCCP-User protocol instances, such as 820 RANAP or TCAP. SS7 network interworking is not required, therefore 821 there is no MTP3 network management status information for the SCCP and 822 SCCP-User protocols to consider. Any MTP-PAUSE, MTP-RESUME or MTP- 823 STATUS indications from the M3UA layer to the SCCP layer should 824 consider the status of the SCTP Association and underlying IP network 825 and any congestion information received from the remote site. 827 1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP 829 ******** SS7 ***************** IP ******** 830 * SEP *---------* *--------* * 831 * or * * SGP * * ASP * 832 * STP * * * * * 833 ******** ***************** ******** 835 +------+ +---------------+ +------+ 836 | SCCP-| | SCCP | | SCCP-| 837 | User | +---------------+ | User | 838 +------+ | _____ | +------+ 839 | SCCP | | | | | | SCCP | 840 +------+ +------+-+------+ +------+ 841 | MTP3 | | MTP3 | | M3UA | | M3UA | 842 +------| +------+ +------+ +------+ 843 | MTP2 | | MTP2 | | SCTP | | SCTP | 844 +------+ +------+ +------+ +------+ 845 | L1 | | L1 | | IP | | IP | 846 +------+ +------+ +------+ +------+ 847 |_______________| |______________| 849 STP - SS7 Signalling Transfer Point 851 In this example, the SGP contains an instance of the SS7 SCCP protocol 852 layer that may, for example, perform the SCCP Global Title Translation 853 (GTT) function for messages logically addressed to the SG SCCP. If the 854 result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN 855 address of an SCCP peer located in the IP domain, the resulting MTP- 856 TRANSFER request primitive is sent to the local M3UA-resident network 857 address translation and mapping function for ongoing routing to the 858 final IP destination. 860 Similarly, the SCCP instance in an SGP can perform the SCCP GTT service 861 for messages logically addressed to it from SCCP peers in the IP 862 domain. In this case, MTP-TRANSFER indication primitives are sent from 863 the local M3UA-resident network address translation and mapping 864 function to the SCCP for GTT. If the result of the GTT yields the 865 address of an SCCP peer in the SS7 network then the resulting MTP- 866 TRANSFER request primitive is given to the MTP3 for delivery to an SS7- 867 resident node. 869 It is possible that the above SCCP GTT at the SGP could yield the 870 address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER 871 request primitive would be sent back to the M3UA layer for delivery to 872 an IP destination. 874 For internal SGP modeling purposes, this may be accomplished with the 875 use of an implementation-dependent nodal interworking function within 876 the SGP that effectively sits below the SCCP and routes MTP-TRANSFER 877 request/indication messages to/from both the MTP3 and the M3UA layer, 878 based on the SS7 DPC or DPC/SSN address information. This nodal 879 interworking function has no visible peer protocol with either the 880 ASP or SEP. 882 Note that the services and interface provided by the M3UA layer are the 883 same as in Example 1 and the functions taking place in the SCCP entity 884 are transparent to the M3UA layer. The SCCP protocol functions are not 885 reproduced in the M3UA protocol. 887 1.6 Definition of M3UA Boundaries 889 1.6.1 Definition of the Boundary between M3UA and an MTP3-User. 891 >From ITU Q.701 [14]: 893 MTP-TRANSFER request 894 MTP-TRANSFER indication 895 MTP-PAUSE indication 896 MTP-RESUME indication 897 MTP-STATUS indication 899 1.6.2 Definition of the Boundary between M3UA and SCTP 901 An example of the upper layer primitives provided by the SCTP are 902 provided in Reference [13] Section 10. 904 1.6.3 Definition of the Boundary between M3UA and Layer Management 906 M-SCTP_ESTABLISH request 907 Direction: LM -> M3UA 908 Purpose: LM requests ASP to establish an SCTP association with its 909 peer. 911 M-STCP_ESTABLISH confirm 912 Direction: M3UA -> LM 913 Purpose: ASP confirms to LM that it has established an SCTP 914 association with its peer. 916 M-SCTP_ESTABLISH indication 917 Direction: M3UA -> LM 918 Purpose: M3UA informs LM that a remote ASP has established an SCTP 919 association. 921 M-SCTP_RELEASE request 922 Direction: LM -> M3UA 923 Purpose: LM requests ASP to release an SCTP association with its 924 peer. 926 M-SCTP_RELEASE confirm 927 Direction: M3UA -> LM 928 Purpose: ASP confirms to LM that it has released SCTP association 929 with its peer. 931 M-SCTP_RELEASE indication 932 Direction: M3UA -> LM 933 Purpose: M3UA informs LM that a remote ASP has released an SCTP 934 Association or the SCTP association has failed. 936 M-SCTP RESTART indication 937 Direction: M3UA -> LM 938 Purpose: M3UA informs LM that an SCTP restart indication has been 939 received. 941 M-SCTP_STATUS request 942 Direction: LM -> M3UA 943 Purpose: LM requests M3UA to report the status of an SCTP 944 association. 946 M-SCTP_STATUS confirm 947 Direction: M3UA -> LM 948 Purpose: M3UA responds with the status of an SCTP association. 950 M-SCTP STATUS indication 951 Direction: M3UA -> LM 952 Purpose: M3UA reports the status of an SCTP association. 954 M-ASP_STATUS request 955 Direction: LM -> M3UA 956 Purpose: LM requests M3UA to report the status of a local or remote 957 ASP. 959 M-ASP_STATUS confirm 960 Direction: M3UA -> LM 961 Purpose: M3UA reports status of local or remote ASP. 963 M-AS_STATUS request 964 Direction: LM -> M3UA 965 Purpose: LM requests M3UA to report the status of an AS. 967 M-AS_STATUS confirm 968 Direction: M3UA -> LM 969 Purpose: M3UA reports the status of an AS. 971 M-NOTIFY indication 972 Direction: M3UA -> LM 973 Purpose: M3UA reports that it has received a Notify message 974 from its peer. 976 M-ERROR indication 977 Direction: M3UA -> LM 978 Purpose: M3UA reports that it has received an Error message from 979 its peer or that a local operation has been unsuccessful. 981 M-ASP_UP request 982 Direction: LM -> M3UA 983 Purpose: LM requests ASP to start its operation and send an ASP Up 984 message to its peer. 986 M-ASP_UP confirm 987 Direction: M3UA -> LM 988 Purpose: ASP reports that is has received an ASP UP Ack message from 989 its peer. 991 M-ASP_UP indication 992 Direction: M3UA -> LM 993 Purpose: M3UA reports it has successfully processed an incoming ASP 994 Up message from its peer. 996 M-ASP_DOWN request 997 Direction: LM -> M3UA 998 Purpose: LM requests ASP to stop its operation and send an ASP Down 999 message to its peer. 1001 M-ASP_DOWN confirm 1002 Direction: M3UA -> LM 1003 Purpose: ASP reports that is has received an ASP Down Ack message 1004 from its peer. 1006 M-ASP_DOWN indication 1007 Direction: M3UA -> LM 1008 Purpose: M3UA reports it has successfully processed an incoming ASP 1009 Down message from its peer, or the SCTP association has 1010 been lost/reset. 1012 M-ASP_ACTIVE request 1013 Direction: LM -> M3UA 1014 Purpose: LM requests ASP to send an ASP Active message to its peer. 1016 M-ASP_ACTIVE confirm 1017 Direction: M3UA -> LM 1018 Purpose: ASP reports that is has received an ASP Active 1019 Ack message from its peer. 1021 M-ASP_ACTIVE indication 1022 Direction: M3UA -> LM 1023 Purpose: M3UA reports it has successfully processed an incoming ASP 1024 Active message from its peer. 1026 M-ASP_INACTIVE request 1027 Direction: LM -> M3UA 1028 Purpose: LM requests ASP to send an ASP Inactive message to its 1029 peer. 1031 M-ASP_INACTIVE confirm 1032 Direction: LM -> M3UA 1033 Purpose: ASP reports that is has received an ASP Inactive 1034 Ack message from its peer. 1036 M-ASP_INACTIVE indication 1037 Direction: M3UA -> LM 1038 Purpose: M3UA reports it has successfully processed an incoming ASP 1039 Inactive message from its peer. 1041 M-AS_ACTIVE indication 1042 Direction: M3UA -> LM 1043 Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state. 1045 M-AS_INACTIVE indication 1046 Direction: M3UA -> LM 1047 Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state. 1049 M-AS_DOWN indication 1050 Direction: M3UA -> LM 1051 Purpose: M3UA reports that an AS has moved to the AS-DOWN state. 1053 If dynamic registration of RK is supported by the M3UA layer, the layer 1054 MAY support the following additional primitives: 1056 M-RK_REG request 1057 Direction: LM -> M3UA 1058 Purpose: LM requests ASP to register RK(s) with its peer by sending 1059 REG REQ message 1061 M-RK_REG confirm 1062 Direction: M3UA -> LM 1063 Purpose: ASP reports that it has received REG RSP message with 1064 registration status as successful from its peer. 1066 M-RK_REG indication 1067 Direction: M3UA -> LM 1068 Purpose: M3UA informs LM that it has successfully processed an 1069 incoming REG REQ message. 1071 M-RK_DEREG request 1072 Direction: LM -> M3UA 1073 Purpose: LM requests ASP to deregister RK(s) with its peer by 1074 sending DEREG REQ message. 1076 M-RK_DEREG confirm 1077 Direction: M3UA -> LM 1078 Purpose: ASP reports that it has received DEREG REQ message with 1079 deregistration status as successful from its peer. 1081 M-RK_DEREG indication 1082 Direction: M3UA -> LM 1083 Purpose: M3UA informs LM that it has successfully processed an 1084 incoming DEREG REQ from its peer. 1086 2. Conventions 1088 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 1089 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 1090 in this document, are to be interpreted as described in [RFC2119]. 1092 3. M3UA Protocol Elements 1094 The general M3UA message format includes a Common Message Header 1095 followed by zero or more parameters as defined by the Message Type. 1096 For forward compatibility, all Message Types may have attached 1097 parameters even if none are specified in this version. 1099 3.1 Common Message Header 1101 The protocol messages for MTP3-User Adaptation require a message header 1102 which contains the adaptation layer version, the message type, and 1103 message length. 1105 0 1 2 3 1106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Version | Reserved | Message Class | Message Type | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Message Length | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 \ \ 1113 / / 1115 All fields in an M3UA message MUST be transmitted in the network byte 1116 order, unless otherwise stated. 1118 3.1.1 M3UA Protocol Version: 8 bits (unsigned integer) 1120 The version field contains the version of the M3UA adaptation layer. 1122 The supported versions are the following: 1124 1 Release 1.0 1126 3.1.2 Message Classes and Types 1128 The following list contains the valid Message Classes: 1130 Message Class: 8 bits (unsigned integer) 1132 The following list contains the valid Message Type Classes: 1134 0 Management (MGMT) Message 1135 1 Transfer Messages 1136 2 SS7 Signalling Network Management (SSNM) Messages 1137 3 ASP State Maintenance (ASPSM) Messages 1138 4 ASP Traffic Maintenance (ASPTM) Messages 1139 5 Reserved for Other Sigtran Adaptation Layers 1140 6 Reserved for Other Sigtran Adaptation Layers 1141 7 Reserved for Other Sigtran Adaptation Layers 1142 8 Reserved for Other Sigtran Adaptation Layers 1143 9 Routing Key Management (RKM) Messages 1144 10 to 127 Reserved by the IETF 1145 128 to 255 Reserved for IETF-Defined Message Class extensions 1147 Message Type: 8 bits (unsigned integer) 1149 The following list contains the message types for the defined 1150 messages. 1152 Management (MGMT) Messages (See Section 3.6) 1154 0 Error (ERR) 1155 1 Notify (NTFY) 1156 2 to 127 Reserved by the IETF 1157 128 to 255 Reserved for IETF-Defined MGMT extensions 1159 Transfer Messages (See Section 3.3) 1161 0 Reserved 1162 1 Payload Data (DATA) 1163 2 to 127 Reserved by the IETF 1164 128 to 255 Reserved for IETF-Defined Transfer extensions 1166 SS7 Signalling Network Management (SSNM) Messages (See Section 1167 3.4) 1169 0 Reserved 1170 1 Destination Unavailable (DUNA) 1171 2 Destination Available (DAVA) 1172 3 Destination State Audit (DAUD) 1173 4 Signalling Congestion (SCON) 1174 5 Destination User Part Unavailable (DUPU) 1175 6 Destination Restricted (DRST) 1176 7 to 127 Reserved by the IETF 1177 128 to 255 Reserved for IETF-Defined SSNM extensions 1179 ASP State Maintenance (ASPSM) Messages (See Section 3.5) 1181 0 Reserved 1182 1 ASP Up (ASPUP) 1183 2 ASP Down (ASPDN) 1184 3 Heartbeat (BEAT) 1185 4 ASP Up Acknowledgement (ASPUP ACK) 1186 5 ASP Down Acknowledgement (ASPDN ACK) 1187 6 Heartbeat Acknowledgement (BEAT ACK) 1188 7 to 127 Reserved by the IETF 1189 128 to 255 Reserved for IETF-Defined ASPSM extensions 1191 ASP Traffic Maintenance (ASPTM) Messages (See Section 3.5) 1193 0 Reserved 1194 1 ASP Active (ASPAC) 1195 2 ASP Inactive (ASPIA) 1196 3 ASP Active Acknowledgement (ASPAC ACK) 1197 4 ASP Inactive Acknowledgement (ASPIA ACK) 1198 5 to 127 Reserved by the IETF 1199 128 to 255 Reserved for IETF-Defined ASPTM extensions 1201 Routing Key Management (RKM) Messages (See Section 3.7) 1203 0 Reserved 1204 1 Registration Request (REG REQ) 1205 2 Registration Response (REG RSP) 1206 3 Deregistration Request (DEREG REQ) 1207 4 Deregistration Response (DEREG RSP) 1208 5 to 127 Reserved by the IETF 1209 128 to 255 Reserved for IETF-Defined RKM extensions 1211 3.1.3 Reserved: 8 bits 1213 The Reserved field SHOULD be set to all '0's and ignored by the 1214 receiver. 1216 3.1.4 Message Length: 32-bits (unsigned integer) 1218 The Message Length defines the length of the message in octets, 1219 including the Common Header. For messages with a final parameter 1220 containing padding, the parameter padding MUST be included in the 1221 Message Length. 1223 Note: A receiver SHOULD accept the message whether or not the final 1224 parameter padding is included in the message length. 1226 3.2 Variable Length Parameter Format 1228 M3UA messages consist of a Common Header followed by zero or more 1229 variable length parameters, as defined by the message type. All the 1230 parameters contained in a message are defined in a Tag Length-Value 1231 format as shown below. 1233 0 1 2 3 1234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Parameter Tag | Parameter Length | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 \ \ 1239 / Parameter Value / 1240 \ \ 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Where more than one parameter is included in a message, the parameters 1244 may be in any order, except where explicitly mandated. A receiver 1245 SHOULD accept the parameters in any order. 1247 Parameter Tag: 16 bits (unsigned integer) 1249 The Tag field is a 16-bit identifier of the type of parameter. It 1250 takes a value of 0 to 65534. Common parameters used by adaptation 1251 layers are in the range of 0x00 to 0x3f. M3UA-specific parameters 1252 have Tags in the range 0x0200 to 0x02ff. The parameter Tags defined 1253 are as follows: 1255 Common Parameters. These TLV parameters are common across the 1256 different adaptation layers: 1258 Parameter Name Parameter ID 1259 ============== ============ 1260 Reserved 0x0000 1261 Not Used in M3UA 0x0001 1262 Not Used in M3UA 0x0002 1263 Not Used in M3UA 0x0003 1264 INFO String 0x0004 1265 Not Used in M3UA 0x0005 1266 Routing Context 0x0006 1267 Diagnostic Information 0x0007 1268 Not Used in M3UA 0x0008 1269 Heartbeat Data 0x0009 1270 Not Used in M3UA 0x000a 1271 Traffic Mode Type 0x000b 1272 Error Code 0x000c 1273 Status 0x000d 1274 Not Used in M3UA 0x000e 1275 Not Used in M3UA 0x000f 1276 Not Used in M3UA 0x0010 1277 ASP Identifier 0x0011 1278 Affected Point Code 0x0012 1279 M3UA-Specific parameters. These TLV parameters are specific to the 1280 M3UA protocol: 1282 Network Appearance 0x0200 1283 Reserved 0x0201 1284 Reserved 0x0202 1285 Reserved 0x0203 1286 User/Cause 0x0204 1287 Congestion Indications 0x0205 1288 Concerned Destination 0x0206 1289 Routing Key 0x0207 1290 Registration Result 0x0208 1291 Deregistration Result 0x0209 1292 Local_Routing Key Identifier 0x020a 1293 Destination Point Code 0x020b 1294 Service Indicators 0x020c 1295 Subsystem Numbers 0x020d 1296 Originating Point Code List 0x020e 1297 Circuit Range 0x020f 1298 Protocol Data 0x0210 1299 Correlation Id 0x0211 1300 Registration Status 0x0212 1301 Deregistration Status 0x0213 1303 Reserved by the IETF 0x0214 to 0xffff 1305 The value of 65535 is reserved for IETF-defined extensions. Values 1306 other than those defined in specific parameter description are 1307 reserved for use by the IETF. 1309 Parameter Length: 16 bits (unsigned integer) 1311 The Parameter Length field contains the size of the parameter in 1312 bytes, including the Parameter Tag, Parameter Length, and Parameter 1313 Value fields. Thus, a parameter with a zero-length Parameter Value 1314 field would have a Length field of 4. The Parameter Length does 1315 not include any padding bytes. 1317 Parameter Value: variable length. 1319 The Parameter Value field contains the actual information to be 1320 transferred in the parameter. 1322 The total length of a parameter (including Tag, Parameter Length and 1323 Value fields) MUST be a multiple of 4 bytes. If the length of the 1324 parameter is not a multiple of 4 bytes, the sender pads the 1325 Parameter at the end (i.e., after the Parameter Value field) with 1326 all zero bytes. The length of the padding is NOT included in the 1327 parameter length field. A sender SHOULD NOT pad with more than 3 1328 bytes. The receiver MUST ignore the padding bytes. 1330 3.3 Transfer Messages 1332 The following section describes the Transfer messages and parameter 1333 contents. 1335 3.3.1 Payload Data Message (DATA) 1337 The DATA message contains the SS7 MTP3-User protocol data, which is an 1338 MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 1339 DATA message contains the following variable length parameters: 1341 Network Appearance Optional 1342 Routing Context Optional 1343 Protocol Data Mandatory 1344 Correlation Id Optional 1346 The following format MUST be used for the Data Message: 1348 0 1 2 3 1349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Tag = 0x0200 | Length = 8 | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Network Appearance | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Tag = 0x0006 | Length = 8 | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Routing Context | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Tag = 0x0210 | Length | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 \ \ 1362 / Protocol Data / 1363 \ \ 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Tag = 0x0211 | Length = 8 | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Correlation Id | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 Network Appearance: 32-bits (unsigned integer) 1372 The Network Appearance parameter identifies the SS7 network 1373 context for the message and implicitly identifies the SS7 1374 Point Code format used, the SS7 Network Indicator value, and the 1375 MTP3 and possibly the MTP3-User protocol type/variant/version used 1376 within the specific SS7 network. Where an SG operates in the 1377 context of a single SS7 network, or individual SCTP associations 1378 are dedicated to each SS7 network context, the Network Appearance 1379 parameter is not required. In other cases the parameter may be 1380 configured to be present for the use of the receiver. 1382 The Network Appearance parameter value is of local significance 1383 only, coordinated between the SGP and ASP. Therefore, in the case 1384 where an ASP is connected to more than one SGP, the same SS7 network 1385 context may be identified by different Network Appearance values 1386 depending over which SGP a message is being transmitted/received. 1388 Where the optional Network Appearance parameter is present, it must 1389 be the first parameter in the message as it defines the format of 1390 the Protocol Data field. 1392 IMPLEMENTATION NOTE: For simplicity of configuration it may be 1393 desirable to use the same NA value across all nodes sharing a 1394 particular network context. 1396 Routing Context: 32-bits (unsigned integer) 1398 The Routing Context parameter contains the Routing Context 1399 value associated with the DATA message. Where a Routing Key has 1400 not been coordinated between the SGP and ASP, sending of Routing 1401 Context is not required. Where multiple Routing 1402 Keys and Routing Contexts are used across a common association, the 1403 Routing Context MUST be sent to identify the traffic flow, 1404 assisting in the internal distribution of Data messages. 1406 Protocol Data 1 or 2: variable length 1408 The Protocol Data parameter contains the original SS7 MTP3 1409 message, including the Service Information Octet and Routing Label. 1411 The Protocol Data parameter contains the following fields: 1413 Service Indicator, 1414 Network Indicator, 1415 Message Priority. 1417 Destination Point Code, 1418 Originating Point Code, 1419 Signalling Link Selection Code (SLS). 1421 User Protocol Data. Includes: 1422 MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP 1423 parameters). 1425 The Protocol Data parameter is encoded as follows: 1427 0 1 2 3 1428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Originating Point Code | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Destination Point Code | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | SI | NI | MP | SLS | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 \ \ 1437 / Protocol Data / 1438 \ \ 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 Originating Point Code: 32 bits (unsigned integer) 1442 Destination Point Code: 32 bits (unsigned integer) 1444 The Originating and Destination Point Code fields contains the OPC 1445 and DPC from the routing label of the original SS7 message in 1446 Network Byte Order, justified to the least significant bit. Unused 1447 bits are coded `0'. 1449 Service Indicator: 8 bits (unsigned integer) 1451 The Service Indicator field contains the SI field from the original 1452 SS7 message justified to the least significant bit. Unused bits 1453 are coded `0'. 1455 Network Indicator: 8-bits (unsigned integer) 1457 The Network Indicator contains the NI field from the original SS7 1458 message justified to the least significant bit. Unused bits are 1459 coded `0'. 1461 Message Priority: 8 bits (unsigned integer) 1463 The Message Priority field contains the MP bits (if any) from the 1464 original SS7 message, both for ANSI-style and TTC-style message 1465 priority bits. The MP bits are aligned to the least significant 1466 bit. Unused bits are coded `0'. 1468 Signalling Link Selection: 8 bits (unsigned integer) 1470 The Signalling Link Selection field contains the SLS bits from 1471 the routing label of the original SS7 message justified to the 1472 least significant bit and in Network Byte Order. Unused bits are 1473 coded `0'. 1475 Protocol Data: (variable) 1477 The Protocol Data field contains a byte string of MTP-User 1478 information from the original SS7 message starting with the 1479 first byte of the original SS7 message following the Routing Label. 1481 Correlation Id: 32-bits (unsigned integer) 1483 The Correlation Id parameter uniquely identifies the MSU carried in 1484 the Protocol Data within an AS. This Correlation Id parameter is 1485 assigned by the sending M3UA. 1487 3.4 SS7 Signalling Network Management (SSNM) Messages 1489 3.4.1 Destination Unavailable (DUNA) 1491 The DUNA message is sent from an SGP in an SG to all concerned ASPs 1492 to indicate that the SG has determined that one or more SS7 1493 destinations are unreachable. It is also sent by an SGP in response 1494 to a message from the ASP to an unreachable SS7 destination. As an 1495 implementation option the SG may suppress the sending of subsequent 1496 "response" DUNA messages regarding a certain unreachable SS7 1497 destination for a certain period to give the remote side time 1498 to react. If there is no alternate route via another SG, the 1499 MTP3-User at the ASP is expected to stop traffic to the 1500 affected destination via the SG as per the defined MTP3-User 1501 procedures. 1503 The DUNA message contains the following parameters: 1505 Network Appearance Optional 1506 Routing Context Optional 1507 Affected Point Code Mandatory 1508 INFO String Optional 1510 The format for DUNA Message parameters is as follows: 1512 0 1 2 3 1513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Tag = 0x0200 | Length = 8 | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Network Appearance | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Tag = 0x0006 | Length | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 \ \ 1522 / Routing Context / 1523 \ \ 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Tag = 0x0012 | Length | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Mask | Affected PC 1 | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 \ \ 1530 / ... / 1531 \ \ 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Mask | Affected PC n | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Tag = 0x0004 | Length | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 \ \ 1538 / INFO String / 1539 \ \ 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 Network Appearance: 32-bit unsigned integer 1544 See Section 3.3.1 1546 Routing Context: n x 32-bits (unsigned integer) 1548 The optional Routing Context parameter contains the Routing Context 1549 values associated with the DUNA message. Where a Routing Key has 1550 not been coordinated between the SGP and ASP, sending of Routing 1551 Context is not required. Where multiple Routing Keys and Routing 1552 Contexts are used across a common association, the Routing 1553 Context(s) MUST be sent to identify the concerned traffic flows 1554 for which the DUNA message applies, assisting in outgoing traffic 1555 management and internal distribution of MTP-PAUSE indications to 1556 MTP3-Users at the receiver. 1558 Affected Point Code: n x 32-bits 1560 The Affected Point Code parameter contains up to sixteen Affected 1561 Destination Point Code fields, each a three-octet parameter to allow 1562 for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected 1563 Point Codes that are less than 24-bits, are padded on the left to 1564 the 24-bit boundary. The encoding is shown below for ANSI and ITU 1565 Point Code examples. 1567 ANSI 24-bit Point Code: 1569 0 1 2 3 1570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Mask | Network | Cluster | Member | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 |MSB-----------------------------------------LSB| 1577 ITU 14-bit Point Code: 1579 0 1 2 3 1580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 |MSB--------------------LSB| 1587 It is optional to send an Affected Point Code parameter with more 1588 than one Affected PC but it is mandatory to receive it. All the 1589 Affected PCs included must be within the same Network Appearance 1590 and/or (set of) Routing Context values included in a Routing Context 1591 parameter. Including multiple Affected PCs may be useful when 1592 reception of an MTP3 management message or a linkset event 1593 simultaneously affects the availability status of a list of 1594 destinations at an SG. 1596 Mask: 8-bits (unsigned integer) 1598 The Mask field can be used to identify a contiguous range of 1599 Affected Destination Point Codes, independent of the point code 1600 format. Identifying a contiguous range of Affected DPCs may be 1601 useful when reception of an MTP3 management message or a linkset 1602 event simultaneously affects the availability status of a series of 1603 destinations at an SG. 1605 The Mask parameter is an integer representing a bit mask that can be 1606 applied to the related Affected PC field. The bit mask identifies 1607 how many bits of the Affected PC field are significant and which are 1608 effectively "wildcarded". For example, a mask of "8" indicates that 1609 the last eight bits of the PC is "wildcarded". For an ANSI 24- 1610 bit Affected PC, this is equivalent to signalling that all PCs in 1611 an ANSI Cluster are unavailable. A mask of "3" indicates that the 1612 last three bits of the PC is "wildcarded". For a 14-bit ITU 1613 Affected PC, this is equivalent to signaling that an ITU 1615 Region is unavailable. A mask value equal (or greater than) the 1616 number of bits in the PC indicates that the entire network 1617 appearance is affected - this is used to indicate network isolation 1618 to the ASP. 1620 INFO String: variable length 1622 The optional INFO String parameter can carry any 8-bit ASCII 1623 character string along with the message. Length of the INFO 1624 String parameter is from 0 to 255 characters. No procedures are 1625 presently identified for its use but the INFO String MAY be used by 1626 Operators to identify in text form the location reflected by the 1627 Affected DPC for debugging purposes. 1629 3.4.2 Destination Available (DAVA) 1631 The DAVA message is sent from an SGP to all concerned ASPs to indicate 1632 that the SG has determined that one or more SS7 destinations are now 1633 reachable (and not restricted), or in response to a DAUD message if 1634 appropriate. If the ASP M3UA layer previously had no routes to the 1635 affected destinations the ASP MTP3-User protocol is informed and may 1636 now resume traffic to the affected destination. The ASP M3UA layer 1637 now routes the MTP3-user traffic through the SG initiating the DAVA 1638 message. 1640 The DAVA message contains the following parameters: 1642 Network Appearance Optional 1643 Routing Context Optional 1644 Affected Point Code Mandatory 1645 INFO String Optional 1647 The format and description of the Network Appearance, Routing Context, 1648 Affected Point Code and INFO String parameters is the same as for the 1649 DUNA message (See Section 3.4.1). 1651 3.4.3 Destination State Audit (DAUD) 1653 The DAUD message MAY be sent from the ASP to the SGP to audit the 1654 availability/congestion state of SS7 routes from the SG to one 1655 or more affected destinations. 1657 The DAUD message contains the following parameters: 1659 Network Appearance Optional 1660 Routing Context Optional 1661 Affected Point Code Mandatory 1662 INFO String Optional 1664 The format and description of DAUD Message parameters is the same as 1665 for the DUNA message (See Section 3.4.1). 1667 3.4.4 Signalling Congestion (SCON) 1669 The SCON message can be sent from an SGP to all concerned ASPs to 1670 indicate that an SG has determined that there is congestion in the 1671 SS7 network to one or more destinations, or to an ASP in response to 1672 a DATA or DAUD message as appropriate. For 1673 some MTP protocol variants (e.g., ANSI MTP) the SCON message may be 1674 sent when the SS7 congestion level changes. The SCON message MAY also 1675 be sent from the M3UA layer of an ASP to an M3UA peer indicating that 1676 the M3UA layer or the ASP is congested. 1678 The SCON message contains the following parameters: 1680 Network Appearance Optional 1681 Routing Context Optional 1682 Affected Point Code Mandatory 1683 Concerned Destination Optional 1684 Congestion Indications Optional 1685 INFO String Optional 1687 The format for SCON Message parameters is as follows: 1689 0 1 2 3 1690 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Tag = 0x0200 | Length =8 | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Network Appearance | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Tag = 0x0006 | Length | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 \ \ 1699 / Routing Context / 1700 \ \ 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Tag = 0x0012 | Length | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Mask | Affected PC 1 | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 \ \ 1707 / ... / 1708 \ \ 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Mask | Affected PC n | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Tag = 0x0206 | Length | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | reserved | Concerned DPC | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Tag = 0x0205 | Length | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Reserved | Cong. Level | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Tag = 0x0004 | Length | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 \ \ 1723 / INFO String / 1724 \ \ 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 The format and description of the Network Appearance, Routing 1728 Context, Affected Point Code, and INFO String parameters is the same 1729 as for the DUNA message (See Section 3.4.1). 1731 The Affected Point Code parameter can be used to indicate congestion 1732 of multiple destinations or ranges of destinations. 1734 Concerned Destination: 32-bits 1736 The optional Concerned Destination parameter is only used if the 1737 SCON message is sent from an ASP to the SGP. It contains the point 1738 code of the originator of the message that triggered the SCON 1739 message. The Concerned Destination parameter contains one Concerned 1740 Destination Point Code field, a three-octet parameter to allow for 1741 14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned 1742 Point Code that is less than 24-bits is padded on the left to the 1743 24-bit boundary. Any resulting Transfer Controlled (TFC) message 1744 from the SG is sent to the Concerned Point Code using the single 1745 Affected DPC contained in the SCON message to populate the 1746 (affected) Destination field of the TFC message 1748 Congested Indications: 32-bits 1750 The optional Congestion Indications parameter contains a Congestion 1751 Level field. This optional parameter is used to communicate 1752 congestion levels in national MTP networks with multiple congestion 1753 thresholds, such as in ANSI MTP3. For MTP congestion methods 1754 without multiple congestion levels (e.g., the ITU international 1755 method) the parameter is not included. 1757 Congestion Level field: 8-bits (unsigned integer) 1759 The Congestion Level field, associated with all of the Affected 1760 DPC(s) in the Affected Destinations parameter, contains one of the 1761 Following values: 1763 0 No Congestion or Undefined 1764 1 Congestion Level 1 1765 2 Congestion Level 2 1766 3 Congestion Level 3 1768 The congestion levels are defined in the congestion method in the 1769 appropriate national MTP recommendations [14,15]. 1771 3.4.5 Destination User Part Unavailable (DUPU) 1773 The DUPU message is used by an SGP to inform concerned ASPs that a 1774 remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is 1775 unavailable. 1777 The DUPU message contains the following parameters: 1779 Network Appearance Optional 1780 Routing Context Optional 1781 Affected Point Code Mandatory 1782 User/Cause Mandatory 1783 INFO String Optional 1785 The format for DUPU message parameters is as follows: 1787 0 1 2 3 1788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Tag = 0x0200 | Length | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Network Appearance | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Tag = 0x0006 | Length | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 \ \ 1797 / Routing Context / 1798 \ \ 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Tag = 0x0012 | Length = 8 | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Mask = 0 | Affected PC | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Tag = 0x0204 | Length = 8 | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Cause | User | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Tag = 0x0004 | Length | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 \ \ 1811 / INFO String / 1812 \ \ 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 User/Cause: 32-bits 1817 The Unavailability Cause and MTP3-User Identity fields, associated 1818 with the Affected PC in the Affected Point Code parameter, are 1819 encoded as follows: 1821 Unavailability Cause field: 16-bits (unsigned integer) 1823 The Unavailability Cause parameter provides the reason for the 1824 unavailability of the MTP3-User. The valid values for the 1825 Unavailability Cause parameter are shown in the following table. 1826 The values agree with those provided in the SS7 MTP3 User Part 1827 Unavailable message. Depending on the MTP3 protocol used in the 1828 Network Appearance, additional values may be used - the 1829 specification of the relevant MTP3 protocol variant/version 1830 recommendation is definitive. 1832 0 Unknown 1833 1 Unequipped Remote User 1834 2 Inaccessible Remote User 1836 MTP3-User Identity field: 16-bits (unsigned integer) 1838 The MTP3-User Identity describes the specific MTP3-User that is 1839 unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for 1840 the MTP3-User Identity are shown below. The values align with those 1841 provided in the SS7 MTP3 User Part Unavailable message and Service 1842 Indicator. Depending on the MTP3 protocol variant/version used in 1843 the network appearance, additional values may be used. The relevant 1844 MTP3 protocol variant/version recommendation is definitive. 1846 0 to 2 Reserved 1847 3 SCCP 1848 4 TUP 1849 5 ISUP 1850 6 to 8 Reserved 1851 9 Broadband ISUP 1852 10 Satellite ISUP 1853 11 Reserved 1854 12 AAL type 2 Signalling 1855 13 Bearer Independent Call Control (BICC) 1856 14 Gateway Control Protocol 1857 15 Reserved 1859 The format and description of the Affected Point Code parameter is 1860 the same as for the DUNA message (See Section 3.4.1.) except that 1861 the Mask field is not used and only a single Affected DPC is 1862 included. Ranges and lists of Affected DPCs cannot be signalled in 1863 a DUPU message, but this is consistent with UPU operation in the 1864 SS7 network. The Affected Destinations parameter in an MTP3 User 1865 Part Unavailable message (UPU) received by an SGP from the SS7 1866 network contains only one destination. 1868 The format and description of the Network Appearance, Routing 1869 Context, and INFO String parameters is the same as for the DUNA 1870 message (See Section 3.4.1). 1872 3.4.6 Destination Restricted (DRST) 1874 The DRST message is optionally sent from the SGP to all concerned ASPs 1875 to indicate that the SG has determined that one or more SS7 1876 destinations are now restricted from the point of view of the SG, or 1877 in response to a DAUD message if appropriate. The M3UA layer at the ASP 1878 is expected to send traffic to the affected destination via an 1879 alternate SG with route(s) of equal priority, but only if such an 1880 alternate route exists and is available. If the affected destination 1881 is currently considered unavailable by the ASP, The MTP3-User should 1882 be informed that traffic to the affected destination can be resumed. 1883 In this case, the M3UA layer should route the traffic through the SG 1884 initiating the DRST message. 1886 This message is optional for the SG to send and it is optional for the 1887 ASP to act on any information received in the message. It is for use in 1888 the "STP" case described in Section 1.4.1. 1890 The DRST message contains the following parameters: 1892 Network Appearance Optional 1893 Routing Context Optional 1894 Affected Point Code Mandatory 1895 INFO String Optional 1897 The format and description of the Network Appearance, Routing Context, 1898 Affected Point Code and INFO String parameters is the same as for the 1899 DUNA message (See Section 3.4.1). 1901 3.5 ASP State Maintenance (ASPSM) Messages 1903 3.5.1 ASP Up 1905 The ASP Up message is used to indicate to a remote M3UA peer that the 1906 adaptation layer is ready to receive any SSNM or ASPSM/ASPTM messages 1907 for all Routing Keys that the ASP is configured to serve. 1909 The ASP Up message contains the following parameters: 1911 ASP Identifier Optional 1912 INFO String Optional 1914 The format for ASP Up message parameters is as follows: 1916 0 1 2 3 1917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Tag = 0x0011 | Length | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | ASP Identifier | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Tag = 0x0004 | Length | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 \ \ 1926 / INFO String / 1927 \ \ 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 The optional ASP Identifier parameter contains a unique value that is 1931 locally significant among the ASPs that support an AS. The SGP should 1932 save the ASP Identifier to be used, if necessary, with the Notify 1933 message (see Section 3.8.2). 1935 The format and description of the optional INFO String parameter is the 1936 same as for the DUNA message (See Section 3.4.1). 1938 3.5.2 ASP Up Acknowledgement (ASP Up Ack) 1940 The ASP UP Ack message is used to acknowledge an ASP Up message 1941 received from a remote M3UA peer. 1943 The ASP Up Ack message contains the following parameters: 1945 INFO String (optional) 1947 The format for ASP Up Ack message parameters is as follows: 1949 0 1 2 3 1950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | Tag =0x0004 | Length | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 \ \ 1955 / INFO String / 1956 \ \ 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 The format and description of the optional INFO String parameter is the 1960 same as for the DUNA message (See Section 3.4.1). The INFO String in 1961 an ASP Up Ack message is independent from the INFO String in the ASP Up 1962 message (i.e., it does not have to echo back the INFO String received). 1964 3.5.3 ASP Down 1966 The ASP Down message is used to indicate to a remote M3UA peer that the 1967 adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM 1968 messages. 1970 The ASP Down message contains the following parameters: 1972 INFO String Optional 1974 The format for the ASP Down message parameters is as follows: 1976 0 1 2 3 1977 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Tag =0x0004 | Length | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 \ \ 1982 / INFO String / 1983 \ \ 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 The format and description of the optional INFO String parameter is the 1987 same as for the DUNA message (See Section 3.4.1). 1989 3.5.4 ASP Down Acknowledgement (ASP Down Ack) 1991 The ASP Down Ack message is used to acknowledge an ASP Down message 1992 received from a remote M3UA peer. 1994 The ASP Down Ack message contains the following parameters: 1996 INFO String Optional 1998 The format for the ASP Down Ack message parameters is as follows: 2000 0 1 2 3 2001 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Tag = 0x0004 | Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 \ \ 2006 / INFO String / 2007 \ \ 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 The format and description of the optional INFO String parameter is the 2011 same as for the DUNA message (See Section 3.4.1). 2013 The INFO String in an ASP Down Ack message is independent from the INFO 2014 String in the ASP Down message (i.e., it does not have to echo back the 2015 INFO String received). 2017 3.5.5 Heartbeat (BEAT) 2019 The BEAT message is optionally used to ensure that the M3UA peers 2020 are still available to each other. It is recommended for use when the 2021 M3UA runs over a transport layer other than the SCTP, which has its own 2022 heartbeat. 2024 The BEAT message contains the following parameters: 2026 Heartbeat Data Optional 2028 The format for the BEAT message is as follows: 2030 0 1 2 3 2031 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | Tag = 0x0009 | Length | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 \ \ 2036 / Heartbeat Data / 2037 \ \ 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 The Heartbeat Data parameter contents are defined by the sending node. 2041 The Heartbeat Data could include, for example, a Heartbeat Sequence 2042 Number and/or Timestamp. The receiver of a BEAT message does not 2043 process this field as it is only of significance to the sender. The 2044 receiver MUST respond with a BEAT Ack message. 2046 3.5.6 Heartbeat Acknowledgement (BEAT Ack) 2048 The BEAT Ack message is sent in response to a received BEAT 2049 message. It includes all the parameters of the received BEAT 2050 message, without any change. 2052 3.6 Routing Key Management (RKM) Messages 2054 3.6.1 Registration Request (REG REQ) 2056 The REG REQ message is sent by an ASP to indicate to a remote M3UA peer 2057 that it wishes to register one or more given Routing Keys with the 2058 remote peer. Typically, an ASP would send this message to an SGP, and 2059 expects to receive a REG RSP message in return with an associated 2060 Routing Context value. 2062 The REG REQ message contains the following parameters: 2064 Routing Key Mandatory 2066 One or more Routing Key parameters MAY be included. The format for the 2067 REG REQ message is as follows: 2069 0 1 2 3 2070 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Tag = 0x0207 | Length | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 \ \ 2075 / Routing Key 1 / 2076 \ \ 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 \ \ 2079 / ... / 2080 \ \ 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Tag = 0x0207 | Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 \ \ 2085 / Routing Key n / 2086 \ \ 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 Routing Key: variable length 2091 The Routing Key parameter is mandatory. The sender of this message 2092 expects that the receiver of this message will create a Routing 2093 Key entry and assign a unique Routing Context value to it, if the 2094 Routing Key entry does not already exist. 2096 The Routing Key parameter may be present multiple times in the same 2097 message. This is used to allow the registration of multiple Routing 2098 Keys in a single message. 2100 The format of the Routing Key parameter is as follows. 2102 0 1 2 3 2103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Local-RK-Identifier | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Traffic Mode Type (optional) | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Destination Point Code | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Network Appearance (optional) | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Service Indicators (optional) | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | Originating Point Code List (optional) | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Circuit Range List (optional) | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 \ \ 2120 / ... / 2121 \ \ 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Destination Point Code | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | Service Indicators (optional) | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Originating Point Code List (optional) | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Circuit Range List (optional) | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 Local-RK-Identifier: 32-bit integer 2134 The mandatory Local-RK-Identifier field is used to uniquely identify 2135 the registration request. The Identifier value is assigned by the 2136 ASP, and is used to correlate the response in an REG RSP message 2137 with the original registration request. The Identifier value must 2138 remain unique until the REG RSP message is received. 2140 The format of the Local-RK-Identifier field is as follows: 2142 0 1 2 3 2143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Tag = 0x020a | Length = 8 | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Local-RK-Identifier value | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 Traffic Mode Type: 32-bit (unsigned integer) 2152 The optional Traffic Mode Type parameter identifies the traffic mode 2153 of operation of the ASP(s) within an Application Server. The format 2154 of the Traffic Mode Type Identifier is as follows: 2156 0 1 2 3 2157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 | Tag = 0x000b | Length = 8 | 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 | Traffic Mode Type | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 The valid values for Traffic Mode Type are shown in the 2165 following table: 2167 1 Override 2168 2 Loadshare 2169 3 Broadcast 2171 If the receiver of the REG REQ creates a new Routing Key entry, then 2172 the Traffic Mode Type sets the traffic mode for the new Application 2173 Server. If the receiver of the REG REQ determines that a matching 2174 Routing Key already exists, and the traffic mode was specified in the Routing Key, the Traffic Mode Type MUST match the 2175 existing traffic mode for the AS. 2177 Destination Point Code: 2179 The Destination Point Code parameter is mandatory, and identifies 2180 the Destination Point Code of incoming SS7 traffic for which the ASP 2181 is registering. The format is the same as described for the 2182 Affected Destination parameter in the DUNA message (See Section 2183 3.4.1). Its format is: 2185 0 1 2 3 2186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | Tag = 0x020b | Length = 8 | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | Mask = 0 | Destination Point Code | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 Network Appearance: 2195 The optional Network Appearance parameter field identifies the SS7 2196 network context for the Routing Key, and has the same format as in 2197 the DATA message (See Section 3.3.1). The absence of the Network 2198 Appearance parameter in the Routing Key indicates the use 2199 of any Network Appearance value, Its format is: 2201 0 1 2 3 2202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Tag = 0x0200 | Length = 8 | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Network Appearance | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 Service Indicators (SI): n X 8-bit integers 2211 The optional SI field contains one or more Service Indicators from 2212 the values as described in the MTP3-User Identity field of the DUPU 2213 message. The absence of the SI parameter in the Routing Key 2214 indicates the use of any SI value, excluding of course MTP 2215 management. Where an SI parameter does not contain a multiple of 2216 four SIs, the parameter is padded out to 32-byte alignment. 2218 The SI format is: 2220 0 1 2 3 2221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Tag = 0x020c | Length | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | SI #1 | SI #2 | SI #3 | SI #4 | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 / ... / 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | SI #n | 0 Padding, if necessary | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 OPC List: 2234 The Originating Point Code List parameter contains one or more SS7 2235 OPC entries, and its format is the same as the Destination Point 2236 Code parameter. The absence of the OPC List parameter in the 2237 Routing Key indicates the use of any OPC value, 2238 0 1 2 3 2239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Tag = 0x020e | Length | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Mask = 0 | Origination Point Code #1 | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Mask = 0 | Origination Point Code #2 | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 / ... / 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Mask = 0 | Origination Point Code #n | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 Circuit Range: 2254 An ISUP controlled circuit is uniquely identified by the SS7 OPC, 2255 DPC and CIC value. For the purposes of identifying Circuit Ranges 2256 in an M3UA Routing Key, the optional Circuit Range parameter 2257 includes one or more circuit ranges, each identified by an OPC and 2258 Upper/Lower CIC value. The DPC is implicit as it is mandatory and 2259 already included in the DPC parameter of the Routing Key. The 2260 absence of the Circuit Range parameter in the Routing Key indicates 2261 the use of any Circuit Range values, in the case of ISUP/TUP 2262 traffic. The Origination Point Code is encoded the same as the 2263 Destination Point Code parameter, while the CIC values are 16-bit 2264 integers. 2266 The Circuit Range format is as follows: 2268 0 1 2 3 2269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Tag = 0x020f | Length | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Mask = 0 | Origination Point Code #1 | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Lower CIC Value #1 | Upper CIC Value #1 | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | Mask = 0 | Origination Point Code #2 | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Lower CIC Value #2 | Upper CIC Value #2 | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 / ... / 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Mask = 0 | Origination Point Code #n | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | Lower CIC Value #n | Upper CIC Value #n | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 3.6 2 Registration Response (REG RSP) 2290 The REG RSP message is used as a response to the REG REQ message from a 2291 remote M3UA peer. It contains indications of success/failure for 2292 registration requests and returns a unique Routing Context value for 2293 successful registration requests, to be used in subsequent M3UA Traffic 2294 Management protocol. 2296 The REG RSP message contains the following parameters: 2298 Registration Result Mandatory 2300 One or more Registration Result parameters MUST be included. The format 2301 for the REG RSP message is as follows: 2303 0 1 2 3 2304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | Tag = 0x0208 | Length | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Registration Result 1 | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 \ \ 2311 / ... / 2312 \ \ 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 | Tag = 0x0208 | Length | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | Registration Result n | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 Registration Results: 2321 The Registration Result parameter contains the registration result 2322 for a single Routing Key in an REG REQ message. The number of 2323 results in a single REG RSP message MAY MUST be anywhere from one to the 2324 total number of number of Routing Key parameters found in the 2325 corresponding REG REQ message. Where multiple REG RSP messages are 2326 used in reply to REG REQ message, a specific result SHOULD be in 2327 only one REG RSP message. The format of each result is as follows: 2329 0 1 2 3 2330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | Tag = 0x020a | Length = 8 | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Local-RK-Identifier value | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Tag = 0x0212 | Length = 8 | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Registration Status | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Tag = 0x0006 | Length = 8 | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Routing Context | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 Local-RK-Identifier: 32-bit integer 2347 The Local-RK-Identifier contains the same value as found in the 2348 matching Routing Key parameter found in the REG REQ message (See 2349 Section 3.5.5.1). 2351 Registration Status: 32-bit integer 2353 The Registration Result Status field indicates the success or the 2354 reason for failure of a registration request. 2356 Its values may be: 2358 0 Successfully Registered 2359 1 Error - Unknown 2360 2 Error - Invalid DPC 2361 3 Error - Invalid Network Appearance 2362 4 Error - Invalid Routing Key 2363 5 Error - Permission Denied 2364 6 Error - Cannot Support Unique Routing 2365 7 Error - Routing Key not Currently Provisioned 2366 8 Error - Insufficient Resources 2367 9 Error - Unsupported RK parameter Field 2368 10 Error - Unsupported/Invalid Traffic Handling Mode 2370 Routing Context: 32-bit integer 2372 The Routing Context field contains the Routing Context value for the 2373 associated Routing Key if the registration was successful. It is set 2374 to "0" if the registration was not successful. 2376 3.6.3 Deregistration Request (DEREG REQ) 2378 The DEREG REQ message is sent by an ASP to indicate to a remote M3UA 2379 peer that it wishes to deregister a given Routing Key. Typically, an 2380 ASP would send this message to an SGP, and expects to receive a DEREG 2381 RSP message in return with the associated Routing Context value. 2383 The DEREG REQ message contains the following parameters: 2385 Routing Context Mandatory 2387 The format for the DEREG REQ message is as follows: 2389 0 1 2 3 2390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Tag = 0x0006 | Length | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 \ \ 2395 / Routing Context / 2396 \ \ 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 Routing Context: n X 32-bit integers 2401 The Routing Context parameter contains (a list of) integers indexing 2402 the Application Server traffic that the sending ASP is currently 2403 registered to receive from the SGP but now wishes to deregister. 2405 3.6.4 Deregistration Response (DEREG RSP) 2407 The DEREG RSP message is used as a response to the DEREG REQ message 2408 from a remote M3UA peer. 2410 The DEREG RSP message contains the following parameters: 2412 Deregistration Result Mandatory 2414 One or more Deregistration Result parameters MUST be included. The 2415 format for the DEREG RSP message is as follows: 2417 0 1 2 3 2418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | Tag = 0x0209 | Length | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Deregistration Result 1 | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 \ \ 2425 / ... / 2426 \ \ 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Tag = 0x0209 | Length | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Deregistration Result n | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 Deregistration Results: 2435 The Deregistration Result parameter contains the deregistration 2436 status for a single Routing Context in a DEREG REQ message. The 2437 number of results in a single DEREG RSP message MAY be anywhere from 2438 one to the total number of number of Routing Context values found in 2439 the corresponding REG REQ message. Where multiple DEREG RSP messages 2440 are used in reply to DEREG REQ message, a specific result SHOULD be 2441 in only one DEREG RSP message. The format of each result is as 2442 follows: 2444 0 1 2 3 2445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Tag = 0x0006 | Length = 8 | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | Routing Context | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Tag = 0x0213 | Length = 8 | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | Deregistration Status | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 Routing Context: 32-bit integer 2458 The Routing Context field contains the Routing Context value of the 2459 matching Routing Key to deregister, as found in the DEREG REQ 2460 message. 2462 Deregistration Status: 32-bit integer 2464 The Deregistration Result Status field indicates the success or the 2465 reason for failure of the deregistration. 2467 Its values may be: 2468 0 Successfully Deregistered 2469 1 Error - Unknown 2470 2 Error - Invalid Routing Context 2471 3 Error - Permission Denied 2472 4 Error - Not Registered 2473 5 Error - ASP Currently Active for Routing Context 2475 3.7 ASP Traffic Maintenance (ASPTM) Messages 2477 3.7.1 ASP Active 2479 The ASP Active message is sent by an ASP to indicate to a remote M3UA 2480 peer that it is ready to process signalling traffic for a particular 2481 Application Server. The ASP Active message affects only the ASP state 2482 for the Routing Keys identified by the Routing Contexts, if present. 2484 The ASP Active message contains the following parameters: 2486 Traffic Mode Type Optional 2487 Routing Context Optional 2488 INFO String Optional 2490 The format for the ASP Active message is as follows: 2492 0 1 2 3 2493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | Tag = 0x000b | Length = 8 | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | Traffic Mode Type | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | Tag = 0x0006 | Length | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 \ \ 2502 / Routing Context / 2503 \ \ 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Tag = 0x0004 | Length | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 \ \ 2508 / INFO String / 2509 \ \ 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 Traffic Mode Type: 32-bit (unsigned integer) 2514 The Traffic Mode Type parameter identifies the traffic mode of 2515 operation of the ASP within an AS. The valid values for Traffic Mode 2516 Type are shown in the following table: 2518 1 Override 2519 2 Loadshare 2520 3 Broadcast 2522 Within a particular Routing Context, Override, Loadshare and 2523 Broadcast SHOULD NOT be mixed. The Override value indicates that the 2524 ASP is operating in Override mode, and the ASP takes over all 2525 traffic in an Application Server (i.e., primary/backup operation), 2526 overriding any currently active ASPs in the AS. In Loadshare mode, 2527 the ASP will share in the traffic distribution with any other 2528 currently active ASPs. In Broadcast mode, the ASP will receive the 2529 same messages as any other currently active ASP. 2531 Routing Context: n X 32-bit integers 2533 The optional Routing Context parameter contains (a list of) integers 2534 indexing the Application Server traffic that the sending ASP is 2535 configured/registered to receive. 2537 There is one-to-one relationship between an index entry and an SGP 2538 Routing Key or AS Name. Because an AS can only appear in one 2539 Network Appearance, the Network Appearance parameter is not required 2540 in the ASP Active message. 2542 An Application Server Process may be configured to process traffic 2543 for more than one logical Application Server. From the perspective 2544 of an ASP, a Routing Context defines a range of signalling traffic 2545 that the ASP is currently configured to receive from the SGP. For 2546 example, an ASP could be configured to support call processing for 2547 multiple ranges of PSTN trunks and therefore receive related 2548 signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges. 2550 The format and description of the optional INFO String parameter is the 2551 same as for the DUNA message (See Section 3.4.1). 2553 3.7.2 ASP Active Acknowledgement (ASP Active Ack) 2555 The ASP Active Ack message is used to acknowledge an ASP Active message 2556 received from a remote M3UA peer. 2558 The ASP Active Ack message contains the following parameters: 2560 Traffic Mode Type Optional 2561 Routing Context Optional 2562 INFO String Optional 2564 The format for the ASP Active Ack message is as follows: 2566 0 1 2 3 2567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | Tag = 0x000b | Length = 8 | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 | Traffic Mode Type | 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 | Tag = 0x0006 | Length | 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 \ \ 2576 / Routing Context / 2577 \ \ 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | Tag = 0x0004 | Length | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 \ \ 2582 / INFO String / 2583 \ \ 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 The format and description of the optional INFO String parameter is the 2587 same as for the DUNA message (See Section 3.4.1). 2589 The INFO String in an ASP Active Ack message is independent from the 2590 INFO String in the ASP Active message (i.e., it does not have to echo 2591 back the INFO String received). 2593 The format of the Traffic Mode Type and Routing Context parameters is 2594 the same as for the ASP Active message. (See Section 3.5.5). 2596 3.7.3 ASP Inactive 2598 The ASP Inactive message is sent by an ASP to indicate to a remote M3UA 2599 peer that it is no longer an active ASP to be used from within a list of 2600 ASPs. The ASP Inactive message affects only the ASP state in the 2601 Routing Keys identified by the Routing Contexts, if present. 2603 The ASP Inactive message contains the following parameters: 2605 Routing Context Optional 2606 INFO String Optional 2608 The format for the ASP Inactive message parameters is as follows: 2610 0 1 2 3 2611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | Tag = 0x0006 | Length | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 \ \ 2616 / Routing Context / 2617 \ \ 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | Tag = 0x0004 | Length | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 \ \ 2622 / INFO String / 2623 \ \ 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 The format and description of the optional Routing Context and INFO 2627 String parameters is the same as for the ASP Active message (See 2628 Section 3.5.5.) 2630 3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack) 2632 The ASP Inactive Ack message is used to acknowledge an ASP Inactive 2633 message received from a remote M3UA peer. 2635 The ASP Inactive Ack message contains the following parameters: 2637 Routing Context Optional 2638 INFO String Optional 2640 The format for the ASP Inactive Ack message is as follows: 2642 0 1 2 3 2643 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Tag = 0x0006 | Length | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 \ \ 2648 / Routing Context / 2649 \ \ 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | Tag = 0x0004 | Length | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 \ \ 2654 / INFO String / 2655 \ \ 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 The format and description of the optional INFO String parameter is the 2659 same as for the DUNA message (See Section 3.4.1.) 2661 The INFO String in an ASP Inactive Ack message is independent from the 2662 INFO String in the ASP Inactive message (i.e., it does not have to echo 2663 back the INFO String received). 2665 The format of the Routing Context parameter is the same as for the ASP 2666 Inactive message. (See Section 3.5.7). 2668 3.8 Management (MGMT) Messages 2670 3.8.1 Error 2672 The Error message is used to notify a peer of an error event associated 2673 with an incoming message. For example, the message type might be 2674 unexpected given the current state, or a parameter value might be 2675 invalid. 2677 The Error message contains the following parameters: 2679 Error Code Mandatory 2680 Routing Context Mandatory* 2681 Network Appearance Mandatory* 2682 Affected Point Code Mandatory* 2683 Diagnostic Information Optional 2685 (*) Only mandatory for specific Error Codes 2686 The format for the Error message is as follows: 2688 0 1 2 3 2689 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | Tag = 0x000c | Length = 8 | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Error Code | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Tag = 0x0006 | Length | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 \ \ 2698 / Routing Context / 2699 \ \ 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | Tag - 0x0012 | Length | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Mask | Affected Point Code 1 | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 \ \ 2706 / ... / 2707 \ \ 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | Mask | Affected Point Code n | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Tag = 0x0200 | Length = 8 | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | Network Appearance | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | Tag = 0x0007 | Length | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 \ \ 2718 / Diagnostic Information / 2719 \ \ 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 Error Code: 32-bits (unsigned integer) 2724 The Error Code parameter indicates the reason for the Error Message. 2725 The Error parameter value can be one of the following values: 2727 0x01 Invalid Version 2728 0x02 Not Used in M3UA 2729 0x03 Unsupported Message Class 2730 0x04 Unsupported Message Type 2731 0x05 Unsupported Traffic Handling Mode 2732 0x06 Unexpected Message 2733 0x07 Protocol Error 2734 0x08 Not used in M3UA 2735 0x09 Invalid Stream Identifier 2736 0x0a Not used in M3UA 2737 0x0b Not used in M3UA 2738 0x0c Not used in M3UA 2739 0x0d Refused - Management Blocking 2740 0x0e ASP Identifier Required 2741 0x0f Invalid ASP Identifier 2742 0x10 Invalid Routing Context 2743 0x11 Invalid Parameter Value 2744 0x12 Parameter Field Error 2745 0x13 Unexpected Parameter 2746 0x14 Destination Status Unknown 2747 0x15 Invalid Network Appearance 2748 0x16 No configured AS for ASP 2750 The "Invalid Version" error is sent if a message was received with an 2751 invalid or unsupported version. The Error message contains the 2752 supported version in the Common header. The Error message could 2753 optionally provide the supported version in the Diagnostic Information 2754 area. 2756 The "Invalid Network Appearance" error is sent by a SGP if an ASP sends 2757 a message with an invalid (unconfigured) Network Appearance value. 2758 For this error, the invalid (unconfigured) Network Appearance MUST be 2759 included in the Network Appearance parameter. 2761 The "Unsupported Message Class" error is sent if a message with an 2762 unexpected or unsupported Message Class is received. 2764 The "Unsupported Message Type" error is sent if a message with an 2765 unexpected or unsupported Message Type is received. 2767 The "Unsupported Traffic Handling Mode" error is sent by a SGP 2768 if an ASP sends an ASP Active message with an unsupported Traffic Mode 2769 Type or a Traffic Mode Type that is inconsistent with the presently 2770 configured mode for the Application Server. An example would be a case 2771 in which the SGP did not support loadsharing. 2773 The "Unexpected Message" error MAY be sent if a defined and recognized 2774 message is received that is not expected in the current state (in some 2775 cases the ASP may optionally silently discard the message and not send 2776 an Error message). For example, silent discard is used by an ASP if it 2777 received a DATA message from an SGP while it was in the ASP-INACTIVE 2778 state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message. 2780 The "Protocol Error" error is sent for any protocol anomaly (i.e., 2781 reception of a parameter that is syntactically correct but unexpected 2782 in the current situation. 2784 The "Invalid Routing Context" error is sent if a message is received 2785 from a peer with an invalid (unconfigured) Routing Context value, or 2786 if a message is received from a peer without a Routing Context 2787 parameter and it is not known by configuration data which 2788 Application Servers are referenced. For this error, the invalid Routing Context(s) MUST be included in the Error message. 2790 The "No Configured AS for ASP" error is sent if a message is received 2791 from a peer without a Routing Context parameter and it is not known by 2792 configuration data which Application Servers are referenced. 2794 The "Invalid Stream Identifier" error is sent if a message is received 2795 on an unexpected SCTP stream (e.g., a Management message was received 2796 on a stream other than "0"). 2798 The " Invalid Parameter Value " error is sent if a message is received 2799 with an invalid parameter value (e.g., a DUPU message was received with 2800 a Mask value other than "0" or a Data message was received on stream 2801 "0"). 2803 The "Refused - Management Blocking" error is sent when an ASP Up or 2804 ASP Active message is received and the request is refused for 2805 management reasons (e.g., management lockout"). If this error is in 2806 response to an ASP Active message, the Routing Context(s) in the ASP 2807 Active message SHOULD be included in the Error message. 2809 The "ASP Identifier Required" is sent by a SGP in response 2810 to an ASP Up message which does not contain an ASP Identifier 2811 parameter when the SGP requires one. The ASP SHOULD resend the 2812 ASP Up message with an ASP Identifier. 2814 The "Invalid ASP Identifier" is send by a SGP in response 2815 to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. 2817 The "Parameter Field Error" would be sent if a message is received 2818 with a parameter having a wrong length field. 2820 The "Unexpected Parameter" error would be sent if a message contains 2821 an invalid parameter. 2823 The "Destination Status Unknown" Error MAY be sent if a DAUD is 2824 received at an SG enquiring of the availability/congestion status of 2825 a destination, and the SG does not wish to provide the status (e.g., 2826 the sender is not authorized to know the status). For this error, the 2827 invalid or unauthorized Point Code(s) MUST be included along with the 2828 Network Appearance and/or Routing Context associated with the Point 2829 Code(s). 2831 Diagnostic Information: variable length 2833 When included, the optional Diagnostic information can be any 2834 information germane to the error condition, to assist in 2835 identification of the error condition. The Diagnostic information 2836 SHOULD contain the offending message. 2838 Error messages MUST NOT be generated in response to other Error 2839 messages. 2841 3.8.2 Notify 2843 The Notify message used to provide an autonomous indication of M3UA 2844 events to an M3UA peer. 2846 The Notify message contains the following parameters: 2848 Status Mandatory 2849 ASP Identifier Optional 2850 Routing Context Optional 2851 INFO String Optional 2853 The format for the Notify message is as follows: 2855 0 1 2 3 2856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Tag = 0x000d | Length = 8 | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | Status Type | Status Information | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | Tag = 0x0011 | Length | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | ASP Identifier | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | Tag = 0x0006 | Length | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 \ \ 2869 / Routing Context / 2870 \ \ 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 | Tag = 0x0004 | Length | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 \ \ 2875 / INFO String / 2876 \ \ 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2879 Status Type: 16-bits (unsigned integer) 2881 The Status Type parameter identifies the type of the Notify message. 2882 The following are the valid Status Type values: 2884 1 Application Server State Change (AS-State_Change) 2885 2 Other 2887 Status Information: 16-bits (unsigned integer) 2889 The Status Information parameter contains more detailed information 2890 for the notification, based on the value of the Status Type. 2891 If the Status Type is AS-State_Change the following Status 2892 Information values are used: 2894 1 reserved 2895 2 Application Server Inactive (AS-INACTIVE) 2896 3 Application Server Active (AS-ACTIVE) 2897 4 Application Server Pending (AS-PENDING) 2899 These notifications are sent from an SGP to an ASP upon a change in 2900 status of a particular Application Server. The value reflects the 2901 new state of the Application Server. 2903 If the Status Type is Other, then the following Status Information 2904 values are defined: 2906 1 Insufficient ASP Resources Active in AS 2907 2 Alternate ASP Active 2908 3 ASP Failure 2910 These notifications are not based on the SGP reporting the state change 2911 of an ASP or AS. In the Insufficent ASP Resources case, the SGP is 2912 indicating to an ASP_INACTIVE ASP in the AS that another ASP is 2913 required to handle the load of the AS (Loadsharing or Broadcast mode). 2914 For the Alternate ASP Active case, an ASP is informed when an alternate 2915 ASP transitions to the ASP-ACTIVE state in Override mode. 2917 The format and description of the optional ASP Identifier, Routing 2918 Context and Info String parameters is the same as for the ASP Active 2919 message (See Section 3.5.1) 2921 4. Procedures 2923 The M3UA layer needs to respond to various local primitives it receives 2924 from other layers as well as the messages that it receives from the 2925 peer M3UA layer. This section describes the M3UA procedures in 2926 response to these events. 2928 4.1 Procedures to Support the M3UA-User 2930 4.1.1 Receipt of Primitives from the M3UA-User 2932 On receiving an MTP-TRANSFER request primitive from an upper layer at 2933 an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA 2934 layer sends a corresponding DATA message (see Section 3) to its M3UA 2935 peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER 2936 indication primitive to the upper layer. 2938 The M3UA message distribution function (see Section 1.4.2.1) determines 2939 the Application Server (AS) based on comparing the information in the 2940 MTP-TRANSFER request primitive with a provisioned Routing Key. 2942 >From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 2943 state is selected and a DATA message is constructed and issued on the 2944 corresponding SCTP association. If more than one ASP is in the ASP- 2945 ACTIVE state (i.e., traffic is to be loadshared across more than one 2946 ASP), one of the ASPs in the ASP_ACTIVE state is selected from the 2947 list. If the ASPs are in Broadcast Mode, all active ASPs will be 2948 selected and the message sent to each of the active ASPs. The 2949 selection algorithm is implementation dependent but could, for 2950 example, be round robin or based on the SLS or ISUP CIC. The a 2951 appropriate selection algorithm must be chosen carefully as it is 2952 dependent on application assumptions and understanding of the 2953 degree of state coordination between the ASP_ACTIVE ASPs in the AS. 2955 In addition, the message needs to be sent on the appropriate SCTP 2956 stream, again taking care to meet the message sequencing needs of the 2957 signalling application. DATA messages MUST be sent on an SCTP stream 2958 other than stream '0'. 2960 When there is no Routing Key match, or only a partial match, for an 2961 incoming SS7 message, a default treatment MAY be specified. Possible 2962 solutions are to provide a default Application Server at the SGP that 2963 directs all unallocated traffic to a (set of) default ASP(s), or to 2964 drop the message and provide a notification to Layer Management in an 2965 M-ERROR indication primitive. The treatment of unallocated traffic is 2966 implementation dependent. 2968 4.1.2 Receipt of Primitives from the Layer Management 2970 On receiving primitives from the local Layer Management, the M3UA layer 2971 will take the requested action and provide an appropriate response 2972 primitive to Layer Management. 2974 An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP 2975 or IPSP will initiate the establishment of an SCTP association. The 2976 M3UA layer will attempt to establish an SCTP association with the 2977 remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local 2978 SCTP layer. 2980 When an SCTP association has been successfully established, the SCTP 2981 will send an SCTP-COMMUNICATION_UP notification primitive to the local 2982 M3UA layer. At the SGP or IPSP that initiated the request, the M3UA 2983 layer will send an M-SCTP_ESTABLISH confirm primitive to Layer 2984 Management when the association setup is complete. At the peer M3UA 2985 layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer 2986 Management upon successful completion of an incoming SCTP association 2987 setup. 2989 An M-SCTP_RELEASE request primitive from Layer Management initiates the 2990 teardown of an SCTP association. The M3UA layer accomplishes a 2991 graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN 2992 primitive to the SCTP layer. 2994 When the graceful shutdown of the SCTP association has been 2995 accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE 2996 notification primitive to the local M3UA layer. At the M3UA Layer that 2997 initiated the request, the M3UA layer will send an M-SCTP_RELEASE 2998 confirm primitive to Layer Management when the association shutdown 2999 is complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication 3000 primitive is sent to Layer Management upon abort or successful 3001 shutdown of an SCTP association. 3003 An M-SCTP_STATUS request primitive supports a Layer Management query of 3004 the local status of a particular SCTP association. The M3UA layer 3005 simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS 3007 primitive to the SCTP layer. When the SCTP responds, the M3UA layer 3008 maps the association status information to an M-SCTP_STATUS confirm 3009 primitive. No peer protocol is invoked. 3011 Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings 3012 can be described for the various other SCTP Upper Layer primitives in 3013 RFC2960 [13] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, 3014 REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL 3015 PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS 3016 CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status 3017 as well) can be considered for modeling purposes as a Layer Management 3018 interaction directly with the SCTP Layer. 3020 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 3021 Management the notification or error information contained in a 3022 received M3UA Notify or Error message respectively. These indications 3023 can also be generated based on local M3UA events. 3025 An M-ASP_STATUS request primitive supports a Layer Management query of 3026 the status of a particular local or remote ASP. The M3UA layer 3027 responds with the status in an M-ASP_STATUS confirm primitive. No M3UA 3028 peer protocol is invoked. 3030 An M-AS_STATUS request supports a Layer Management query of the status 3031 of a particular AS. The M3UA responds with an M-AS_STATUS confirm 3032 primitive. No M3UA peer protocol is invoked. 3034 M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_ 3035 INACTIVE request primitives allow Layer Management at an ASP to 3036 initiate state changes. Upon successful completion, a corresponding 3037 confirm primitive is provided by the M3UA layer to Layer Management. 3038 If an invocation is unsuccessful, an Error indication primitive is 3039 provided in the primitive. These requests result in outgoing ASP Up, 3040 ASP Down, ASP Active and ASP Inactive messages to the remote M3UA 3041 peer at an SGP or IPSP. 3043 4.2 Procedures to Support the Management of SCTP Associations 3045 4.2.1 Receipt of M3UA Peer Management Messages 3047 Upon successful state changes resulting from reception of ASP Up, 3048 ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the 3049 M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M- 3050 ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M- 3051 AS_DOWN indication primitives to the local Layer Management. 3053 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 3054 Management the notification or error information contained in a 3055 received M3UA Notify or Error message. These indications can also be 3056 generated based on local M3UA events. 3058 All Non-Transfer messages, except BEAT and BEAT Ack, SHOULD be sent 3059 with sequenced delivery to ensure ordering. All Non-Transfer 3060 messages, with the exception of ASPTM, BEAT and BEAT Ack messages, 3061 SHOULD be sent on SCTP stream '0'. ASPTM messages MAY be sent on 3062 one of the streams used to carry the data traffic related to the 3063 Routing Context(s), to minimize possible message loss. BEAT and 3064 BEAT Ack messages MAY be sent using out-of-order delivery, and MAY 3065 be sent on any stream. 3067 4.3 AS and ASP State Maintenance 3069 The M3UA layer on the SGP maintains the state of each remote ASP, in 3070 each Application Server that the ASP is configured to receive traffic, 3071 as input to the M3UA message distribution function. Similarly, where 3072 IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP 3073 maintains the state of remote IPSPs. For the purposes of the following 3074 procedures, only the SGP/ASP case is described but the SGP side of the 3075 procedures also apply to an IPSP sending traffic to an AS consisting of 3076 a set of remote IPSPs. 3078 4.3.1 ASP States 3080 The state of each remote ASP, in each AS that it is configured to 3081 operate, is maintained in the M3UA layer in the SGP. The state of a 3082 particular ASP in a particular AS changes due to events. The events 3083 include: 3085 * Reception of messages from the peer M3UA layer at the ASP; 3086 * Reception of some messages from the peer M3UA layer at other ASPs 3087 in the AS (e.g., ASP Active message indicating "Override"); 3088 * Reception of indications from the SCTP layer; or 3089 * Local Management intervention. 3091 The ASP state transition diagram is shown in Figure 4. The possible 3092 states of an ASP are: 3094 ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the 3095 related SCTP association is down. Initially all ASPs will be in this 3096 state. An ASP in this state SHOULD NOT be sent any M3UA messages, 3097 with the exception of Heartbeat, ASP Down Ack and Error messages. 3099 ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the 3100 related SCTP association is up) but application traffic is stopped. In 3101 this state the ASP SHOULD NOT be sent any DATA or SNMM messages for the 3102 AS for which the ASP is inactive. 3104 ASP-ACTIVE: The remote M3UA peer at the ASP is available and 3105 application traffic is active (for a particular Routing Context or set 3106 of Routing Contexts). 3108 SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication 3109 Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local 3110 SCTP layer will send this indication when it detects the loss of 3111 connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as 3112 either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 3113 notification from the SCTP layer. 3115 SCTP RI: The local SCTP layer's Restart indication to the upper layer 3116 protocol (M3UA) on an SG. The local SCTP will send this indication 3117 when it detects a restart from the ASP's peer SCTP layer. 3119 Figure 4: ASP State Transition Diagram, per AS 3121 +--------------+ 3122 | | 3123 +----------------------| ASP-ACTIVE | 3124 | Other +-------| | 3125 | ASP in AS | +--------------+ 3126 | Overrides | ^ | 3127 | | ASP | | ASP 3128 | | Active | | Inactive 3129 | | | v 3130 | | +--------------+ 3131 | | | | 3132 | +------>| ASP-INACTIVE | 3133 | +--------------+ 3134 | ^ | 3135 ASP Down/ | ASP | | ASP Down / 3136 SCTP CDI/ | Up | | SCTP CDI/ 3137 SCTP RI | | v SCTP RI 3138 | +--------------+ 3139 | | | 3140 +--------------------->| ASP-DOWN | 3141 | | 3142 +--------------+ 3144 4.3.2 AS States 3146 The state of the AS is maintained in the M3UA layer on the SGPs. The 3147 state of an AS changes due to events. These events include: 3149 * ASP state transitions 3150 * Recovery timer triggers 3152 The possible states of an AS are: 3154 AS-DOWN: The Application Server is unavailable. This state implies 3155 that all related ASPs are in the ASP-DOWN state for this AS. Initially 3156 the AS will be in this state. An Application Server is in the AS-DOWN 3157 state when it is removed from a configuration. 3159 AS-INACTIVE: The Application Server is available but no application 3160 traffic is active (i.e., one or more related ASPs are in the ASP- 3161 INACTIVE state, but none in the ASP-ACTIVE state). The recovery 3162 timer T(r) is not running or has expired. 3164 AS-ACTIVE: The Application Server is available and application traffic 3165 is active. This state implies that at least one ASP is in the ASP- 3166 ACTIVE state. 3168 AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN 3169 and it was the last remaining active ASP in the AS. A recovery timer 3170 T(r) SHOULD be started and all incoming signalling messages SHOULD be 3171 queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, 3172 the AS is moved to the AS-ACTIVE state and all the queued messages 3173 will be sent to the ASP. 3175 If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no 3176 alternative, the SGP may stops queuing messages and discards all 3177 previously queued messages. The AS will move to the AS-INACTIVE state 3178 if at least one ASP is in ASP-INACTIVE state, otherwise it will move 3179 to AS-DOWN state. 3181 Figure 5 shows an example AS state machine for the case where the 3182 AS/ASP data is preconfigured. For other cases where the AS/ASP 3183 configuration data is created dynamically, there would be differences 3184 in the state machine, especially at creation of the AS. 3186 Figure 5: AS State Transition Diagram 3188 +----------+ one ASP trans to ACTIVE +-------------+ 3189 | AS- |---------------------------->| AS- | 3190 | INACTIVE | | ACTIVE | 3191 | |<--- | | 3192 +----------+ \ +-------------+ 3193 ^ | \ Tr Expiry, ^ | 3194 | | \ at least one | | 3195 | | \ ASP in ASP-INACTIVE | | 3196 | | \ | | 3197 | | \ | | 3198 | | \ | | 3199 one ASP | | all ASP \ one ASP | | Last ACTIVE 3200 trans | | trans to \ trans to | | ASP trans to 3201 to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE 3202 ASP- | | \ ACTIVE | | or ASP-DOWN 3203 INACTIVE| | \ | | (start Tr) 3204 | | \ | | 3205 | | \ | | 3206 | v \ | v 3207 +----------+ \ +-------------+ 3208 | | --| | 3209 | AS-DOWN | | AS-PENDING | 3210 | | | (queueing) | 3211 | |<----------------------------| | 3212 +----------+ Tr Expiry and no ASP +-------------+ 3213 in ASP-INACTIVE state) 3215 Tr = Recovery Timer 3217 For example, where the AS/ASP configuration data is not created until 3218 Registration of the first ASP, the AS-INACTIVE state is entered 3219 directly upon the first successful REG REQ from an ASP. Another 3220 example is where the AS/ASP configuration data is not created until the 3221 first ASP successfully enters the ASP-ACTIVE state. In this case the 3222 AS-ACTIVE state is entered directly. 3224 4.3.3 M3UA Management Procedures for Primitives 3226 Before the establishment of an SCTP association the ASP state at both 3227 the SGP and ASP is assumed to be in the state ASP-DOWN. 3229 Once the SCTP association is established (see Section 4.2.1) and 3230 assuming that the local M3UA-User is ready, the local M3UA ASP 3231 Maintenance (ASPM) function will initiate the relevant procedures, 3232 using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey 3233 the ASP state to the SGP (see Section 4.4.3). 3235 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN 3236 or SCTP-RESTART indication primitive from the underlying SCTP layer, it 3237 will inform the Layer Management by invoking the M-SCTP_STATUS 3238 indication primitive. The state of the ASP will be moved to ASP-DOWN. 3239 At an ASP, the MTP3-User will be informed of the unavailability of any 3240 affected SS7 destinations through the use of MTP-PAUSE indication 3241 primitives. In the case 3242 of SS7 network isolation, the local MTP3-Users MAY be informed by 3243 implementation-dependent means, as there is currently no primitive 3244 defined for conveying this information. 3246 In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re- 3247 establish the SCTP Association. This MAY be done by the M3UA layer 3248 automatically, or Layer Management MAY reestablish using the 3249 M-SCTP_ESTABLISH request primitive. 3251 In the case of an SCTP-RESTART indication at an ASP, the ASP is now 3252 considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if 3253 it is to recover, must begin any recovery with the ASP-Up procedure. 3255 4.3.4 ASPM Procedures for Peer-to-Peer Messages 3257 4.3.4.1 ASP Up Procedures 3259 After an ASP has successfully established an SCTP association to an 3260 SGP, the SGP waits for the ASP to send an ASP Up message, indicating 3261 that the ASP M3UA peer is available. The ASP is always the initiator 3262 of the ASP Up message. This action MAY be initiated at the ASP by an 3263 M-ASP_UP request primitive from Layer Management or MAY be initiated 3264 automatically by an M3UA management function. 3266 When an ASP Up message is received at an SGP and internally the remote 3267 ASP is in the ASP-DOWN state and not considered locked out for local 3268 management reasons, the SGP marks the remote ASP in the state ASP- 3269 INACTIVE and informs Layer Management with an M-ASP_Up indication 3270 primitive. If the SGP is aware, via current configuration data, which 3271 Application Servers the ASP is configured to operate in, the SGP 3272 updates the ASP state to ASP-INACTIVE in each AS that it is a member. 3274 Alternatively, the SGP may move the ASP into a pool of Inactive ASPs 3275 available for future configuration within Application Server(s), 3276 determined in a subsequent Registration Request or ASP Active 3277 procedure. If the ASP Up message contains an ASP Identifier, the SGP 3278 should save the ASP Identifier for that ASP. The SGP MUST send an 3279 ASP Up Ack message in response to a received ASP Up message even if 3280 the ASP is already marked as ASP-INACTIVE at the SGP. 3282 If for any local reason (e.g., management lockout) the SGP cannot 3283 respond with an ASP Up Ack message, the SGP responds to an ASP Up 3284 message with an Error message with reason "Refused - Management 3285 Blocking". 3287 At the ASP, the ASP Up Ack message received is not acknowledged. Layer 3288 Management is informed with an M-ASP_UP confirm primitive. 3290 When the ASP sends an ASP Up message it starts timer T(ack). If the 3291 ASP does not receive a response to an ASP Up message within T(ack), the 3292 ASP MAY restart T(ack) and resend ASP Up messages until it receives an 3293 ASP Up Ack message. T(ack) is provisionable, with a default of 2 3294 seconds. Alternatively, retransmission of ASP Up messages MAY be put 3295 under control of Layer Management. In this method, expiry of T(ack) 3296 results in an M-ASP_UP confirm primitive carrying a negative 3297 indication. 3299 The ASP must wait for the ASP Up Ack message before sending any other 3300 M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any 3301 other M3UA messages before an ASP Up message is received (other than 3302 ASP Down - see Section 4.3.4.2), the SGP MAY discard them. 3304 If an ASP Up message is received and internally the remote ASP is in 3305 the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an 3306 Error message ("Unexpected Message), and the remote ASP state is 3307 changed to ASP-INACTIVE in all relevant Application Servers. 3309 If an ASP Up message is received and internally the remote ASP is 3310 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 3311 and no further action is taken. 3313 4.3.4.1.1 M3UA Version Control 3315 If an ASP Up message with an unsupported version is received, the 3316 receiving end responds with an Error message, indicating the version 3317 the receiving node supports and notifies Layer Management. 3319 This is useful when protocol version upgrades are being performed in a 3320 network. A node upgraded to a newer version should support the older 3321 versions used on other nodes it is communicating with. Because ASPs 3322 initiate the ASP Up procedure it is assumed that the Error message 3323 would normally come from the SGP. 3325 4.3.4.1.2 IPSP Considerations (ASP Up) 3327 An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. An IPSP can be considered in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives. 3329 Alternatively, an interchange of ASP Up messages from each end can be performed. This option follows the ASP state transition diagram. It would need four messages for completion. 3331 If for any local reason (e.g., management lockout) an IPSP cannot 3332 respond to an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message with an Error message with reason "Refused - 3333 Management Blocking" and leaves the remote IPSP in the ASP-DOWN state. 3335 4.3.4.2 ASP-Down Procedures 3337 The ASP will send an ASP Down message to an SGP when the ASP wishes to 3338 be removed from service in all Application Servers that it is a 3339 member and no longer receive any DATA, SSNM or ASPTM messages. 3340 This action MAY be initiated at the ASP by an M-ASP_DOWN request 3341 primitive from Layer Management or MAY be initiated automatically 3342 by an M3UA management function. 3344 Whether the ASP is permanently removed from any AS is a function of 3345 configuration management. In the case where the ASP previously used 3346 the Registration procedures (see Section 4.3.5) to register within 3347 Application Servers but has not deregistered from all of them prior to 3348 sending the ASP Down message, the SGP MUST consider the ASP as 3349 Deregistered in all Application Servers that it is still a member. 3351 The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M- 3352 ASP_Down indication primitive, and returns an ASP Down Ack message to 3353 the ASP. 3355 The SGP MUST send an ASP Down Ack message in response to a received 3356 ASP Down message from the ASP even if the ASP is already marked as 3357 ASP-DOWN at the SGP. 3359 At the ASP, the ASP Down Ack message received is not acknowledged. 3360 Layer Management is informed with an M-ASP_DOWN confirm primitive. If 3361 the ASP receives an ASP Down Ack without having sent an ASP Down 3362 message, the ASP should now consider itself as in the ASP-DOWN state. 3363 If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the 3364 ASP should then initiate procedures to return itself to its previous 3365 state. 3367 When the ASP sends an ASP Down message it starts timer T(ack). If the 3368 ASP does not receive a response to an ASP Down message within T(ack), 3369 the ASP MAY restart T(ack) and resend ASP Down messages until it 3370 receives an ASP Down Ack message. T(ack) is provisionable, with a 3371 default of 2 seconds. Alternatively, retransmission of ASP Down 3372 messages MAY be put under control of Layer Management. In this method, 3373 expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a 3374 negative indication. 3376 4.3.4.3 ASP Active Procedures 3378 Anytime after the ASP has received an ASP Up Ack message from the SGP 3379 or IPSP, the ASP MAY send an ASP Active message to the SGP indicating 3381 that the ASP is ready to start processing traffic. This action MAY be 3382 initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer 3383 Management or MAY be initiated automatically by an M3UA management 3384 function. In the case where an ASP wishes to process the traffic for 3385 more than one Application Server across a common SCTP association, the 3386 ASP Active message(s) SHOULD contain a list of one or more Routing 3387 Contexts to indicate for which Application Servers the ASP Active 3388 message applies. It is not necessary for the ASP to include all Routing 3389 Contexts of interest in a single ASP Active message, thus requesting to 3390 become active in all Routing Contexts at the same time. Multiple ASP 3391 Active messages MAY be used to activate within the Application Servers 3392 independently, or in sets. In the case where an ASP Active message 3393 does not contain a Routing Context parameter, the receiver must know, 3394 via configuration data, which Application Server(s) the ASP is a 3395 member. 3397 For the Application Servers that the ASP can be successfully activated, 3398 the SGP or IPSP responds with one or more ASP Active Ack messages, 3399 including the associated Routing Context(s) and reflecting any 3400 Traffic Mode Type value present in the related ASP Active message. 3401 The Routing Context parameter MUST be included in the ASP Active 3402 Ack message(s) if the received ASP Active message contained any 3403 Routing Contexts. Depending on any Traffic Mode Type request in 3404 the ASP Active message, or local configuration data if there is no 3405 request, the SGP moves the ASP to the correct ASP traffic state 3406 within the associated Application Server(s). Layer Management is 3407 informed with an M-ASP_Active indication. If the SGP or IPSP 3408 receives any Data messages before an ASP Active message is 3409 received, the SGP or IPSP MAY discard them. By sending an ASP 3410 Active Ack message, the SGP or IPSP is now ready to receive and 3411 send traffic for the related Routing Context(s). The ASP SHOULD 3412 NOT send Data or SNMM messages for the related Routing Context(s) before 3413 receiving an ASP Active Ack message, or it will risk message loss. 3415 Multiple ASP Active Ack messages MAY be used in response to an ASP 3416 Active message containing multiple Routing Contexts, allowing the SGP 3417 or IPSP to independently acknowledge the ASP Active message for 3418 different (sets of) Routing Contexts. The SGP or IPSP MUST send an 3419 Error message ("Invalid Routing Context") for each Routing Context 3420 value that the ASP cannot be successfully activated . 3422 In the case where an "out-of-the-blue" ASP Active message is received 3423 (i.e., the ASP has not registered with the SG or the SG has no static 3424 configuration data for the ASP), the message MAY be silently discarded. 3426 The SGP MUST send an ASP Active Ack message in response to a received 3427 ASP Active message from the ASP, if the ASP is already marked in the 3428 ASP-ACTIVE state at the SGP. 3430 At the ASP, the ASP Active Ack message received is not acknowledged. 3431 Layer Management is informed with an M-ASP_ACTIVE confirm primitive. 3432 It is possible for the ASP to receive Data message(s) before the ASP 3433 Active Ack message as the ASP Active Ack and Data messages from an SG 3434 or IPSP may be sent on different SCTP streams. Message loss is 3435 possible as the ASP does not consider itself in the ASP-ACTIVE state 3436 until reception of the ASP Active Ack message. 3438 When the ASP sends an ASP Active message it starts timer T(ack). If 3439 the ASP does not receive a response to an ASP Active message within 3440 T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until 3441 it receives an ASP Active Ack message. T(ack) is provisionable, with a 3442 default of 2 seconds. Alternatively, retransmission of ASP Active 3443 messages MAY be put under control of Layer Management. In this method, 3444 expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying 3445 a negative indication. 3447 There are three modes of Application Server traffic handling in the SGP 3448 M3UA layer: Override, Loadshare and Broadcast. When included, the 3449 Traffic Mode Type parameter in the ASP Active message indicates the 3450 traffic handling mode to be used in a particular Application Server. 3451 If the SGP determines that the mode indicated in an ASP Active 3452 message is unsupported or incompatible with the mode currently 3453 configured for the AS, the SGP responds with an Error message 3454 ("Unsupported / Invalid Traffic Handling Mode"). If the traffic 3455 handling mode of the Application Server is not already known via 3456 configuration data, then the traffic handling mode indicated in the 3457 first ASP Active message causing the transition of the Application 3458 Server state to AS-ACTIVE MAY be used to set the mode. 3460 In the case of an Override mode AS, reception of an ASP Active message 3461 at an SGP causes the (re)direction of all traffic for the AS to the ASP 3462 that sent the ASP Active message. Any previously active ASP in the AS 3463 is now considered to be in state ASP-INACTIVE and SHOULD no longer 3464 receive traffic from the SGP within the AS. The SGP or IPSP then MUST 3465 send a Notify message ("Alternate ASP_Active") to the previously active 3466 ASP in the AS, and SHOULD stop traffic to/from that ASP. The ASP 3467 receiving this Notify MUST consider itself now in the ASP-INACTIVE 3468 state, if it is not already aware of this via inter-ASP communication 3469 with the Overriding ASP. 3471 In the case of a Loadshare mode AS, reception of an ASP Active message 3472 at an SGP or IPSP causes the direction of traffic to the ASP sending 3473 the ASP Active message, in addition to all the other ASPs that are 3474 currently active in the AS. The algorithm at the SGP for loadsharing 3475 traffic within an AS to all the active ASPs is implementation 3476 dependent. The algorithm could, for example, be round-robin or based 3477 on information in the Data message (e.g., the SLS, SCCP SSN, ISUP CIC 3478 value). 3480 An SGP or IPSP, upon reception of an ASP Active message for the first 3481 ASP in a Loadshare AS, MAY choose not to direct traffic to a newly 3482 active ASP until it determines that there are sufficient resources to 3483 handle the expected load (e.g., until there are "n" ASPs in state ASP- 3484 ACTIVE in the AS). 3486 All ASPs within a loadsharing mode AS must be able to process any 3487 Data message received for the AS, to accommodate any potential 3488 failover or rebalancing of the offered load. 3490 In the case of a Broadcast mode AS, reception of an ASP Active message 3491 at an SGP or IPSP causes the direction of traffic to the ASP sending 3492 the ASP Active message, in addition to all the other ASPs that are 3493 currently active in the AS. The algorithm at the SGP for broadcasting 3494 traffic within an AS to all the active ASPs is a simple broadcast 3495 algorithm, where every message is sent to each of the active ASPs. 3497 An SGP or IPSP, upon reception of an ASP Active message for the first 3498 ASP in a Broadcast AS, MAY choose not to direct traffic to a newly 3499 active ASP until it determines that there are sufficient resources to 3500 handle the expected load (e.g., until there are "n" ASPs in state 3501 ASP-ACTIVE in the AS). 3503 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP 3504 MUST tag the first DATA message broadcast in each SCTP stream with 3505 a unique Correlation Id parameter. The purpose of this 3506 Id is to permit the newly active ASP to synchronize its processing 3507 of traffic in each ordered stream with the other ASPs in the 3508 broadcast group. 3510 4.3.4.3.1 IPSP Considerations (ASP Active) 3512 Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state. 3514 Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. 3516 4.3.4.4 ASP Inactive Procedures 3518 When an ASP wishes to withdraw from receiving traffic within an AS, the 3519 ASP sends an ASP Inactive message to the SGP or IPSP. This action MAY 3520 be initiated at the ASP by an M-ASP_INACTIVE request primitive from 3521 Layer Management or MAY be initiated automatically by an M3UA 3522 management function. In the case where an ASP is processing the 3523 traffic for more than one Application Server across a common SCTP 3524 association, the ASP Inactive message contains one or more Routing 3525 Contexts to indicate for which Application Servers the ASP Inactive 3526 message applies. In the case where an ASP Inactive message does not 3527 contain a Routing Context parameter, the receiver must know, via 3529 configuration data, which Application Servers the ASP is a member and 3530 move the ASP to the ASP-INACTIVE state in all Application Servers. 3531 In the case of an Override mode AS, where another ASP has already 3532 taken over the traffic within the AS with an ASP Active ("Override") 3533 message, the ASP that sends the ASP Inactive message is already 3534 considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive Ack 3535 message is sent to the ASP, after ensuring that all traffic is stopped 3536 to the ASP. 3538 In the case of a Loadshare mode AS, the SGP moves the ASP to the ASP- 3539 INACTIVE state and the AS traffic is reallocated across the remaining 3540 ASPs in the state ASP-ACTIVE, as per the loadsharing algorithm 3541 currently used within the AS. A Notify message ("Insufficient ASP 3542 resources active in AS") MAY be sent to all inactive ASPs, if required. 3543 An ASP Inactive Ack message is sent to the ASP after all traffic 3544 is halted and Layer Management is informed with an M-ASP_INACTIVE 3545 indication primitive. 3547 In the case of a Broadcast mode AS, the SGP moves the ASP to the 3548 ASP-INACTIVE state and the AS traffic is broadcast only to the 3549 remaining ASPs in the state ASP-ACTIVE. A Notify message 3550 ("Insufficient ASP resources active in AS") MAY be sent to all 3551 inactive ASPs, if required. An ASP Inactive Ack message 3552 is sent to the ASP after all traffic is halted and Layer Management is 3553 informed with an M-ASP_INACTIVE indication primitive. 3555 Multiple ASP Inactive Ack messages MAY be used in response to an ASP 3556 Inactive message containing multiple Routing Contexts, allowing the SGP 3557 or IPSP to independently acknowledge for different (sets of) Routing 3558 Contexts. The SGP or IPSP sends an Error message ("Invalid Routing 3559 Context") message for each invalid or unconfigured Routing Context 3560 value in a received ASP Inactive message. 3562 The SGP MUST send an ASP Inactive Ack message in response to a received 3563 ASP Inactive message from the ASP and the ASP is already marked as ASP- 3564 INACTIVE at the SGP. 3566 At the ASP, the ASP Inactive Ack message received is not acknowledged. 3567 Layer Management is informed with an M-ASP_INACTIVE confirm primitive. 3568 If the ASP receives an ASP Inactive Ack without having sent an ASP 3569 Inactive message, the ASP should now consider itself as in the 3570 ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE 3571 state, the ASP should then initiate procedures to return itself to 3572 its previous state. 3574 When the ASP sends an ASP Inactive message it starts timer T(ack). If 3575 the ASP does not receive a response to an ASP Inactive message within 3576 T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages 3577 until it receives an ASP Inactive Ack message. T(ack) is 3578 provisionable, with a default of 2 seconds. Alternatively, 3579 retransmission of ASP Inactive messages MAY be put under control of 3580 Layer Management. In this method, expiry of T(ack) results in a M- 3581 ASP_Inactive confirm primitive carrying a negative indication. 3583 If no other ASPs in the Application Server are in the state 3584 ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to 3585 all of the ASPs in the AS which are in the state ASP-INACTIVE. 3586 The SGP SHOULD start buffering the incoming messages for T(r) 3587 seconds, after which messages MAY be discarded. T(r) is 3588 configurable by the network operator. If the SGP receives an ASP 3589 Active message from an ASP in the AS before expiry of T(r), the 3590 buffered traffic is directed to that ASP and the timer is cancelled. 3591 If T(r) expires, the AS is moved to the AS-INACTIVE state. 3593 4.3.4.4.1 IPSP Considerations (ASP Inactive) 3595 An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it. 3597 Alternatively, an interchange of ASP Inactive messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be deactivated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. 3599 4.3.4.5 Notify Procedures 3601 A Notify message reflecting a change in the AS state MUST be sent to 3602 all ASPs in the AS, except those in the ASP-DOWN state, with 3603 appropriate Status Information and any ASP Identifier of the failed 3604 ASP. At the ASP, Layer Management is informed with an M-NOTIFY 3605 indication primitive. The Notify message must be sent whether the 3606 AS state change was a result of an ASP failure or reception of an 3607 ASP State management (ASPSM) / ASP Traffic Management (ASPTM) 3608 message. In the second case, the Notify message MUST be sent after 3609 any related acknowledgement messages (e.g., ASP Up Ack, ASP Down 3610 Ack, ASP Active Ack, or ASP Inactive Ack). 3612 In the case where a Notify message("AS-PENDING") message is sent by 3613 an SGP that now has no ASPs active to service the traffic, or where a 3614 Notify ("Insufficient ASP resources active in AS") message MUST be 3615 sent in the Loadshare or Broadcast mode, the Notify message does not 3616 explicitly compel the ASP(s) receiving the message to become 3617 active. The ASPs remain in control of what (and when) traffic action 3618 is taken. 3620 In the case where a Notify message does not contain a Routing Context 3621 parameter, the receiver must know, via configuration data, of which 3622 Application Servers the ASP is a member and take the appropriate 3623 action in each AS. 3625 4.3.4.5.1 IPSP Considerations (NTFY) 3627 Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state. 3629 4.3.4.76 Heartbeat Procedures 3631 The optional Heartbeat procedures MAY be used when operating over 3632 transport layers that do not have their own heartbeat mechanism for 3633 detecting loss of the transport association (i.e., other than SCTP). 3635 Either M3UA peer may optionally send Heartbeat messages periodically, 3636 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 3637 message, the M3UA peer MUST respond with a Heartbeat Ack message. 3639 If no Heartbeat Ack message (or any other M3UA message) is received 3640 from the M3UA peer within 2*T(beat), the remote M3UA peer is 3641 considered unavailable. Transmission of Heartbeat messages is 3642 stopped and the signalling process SHOULD attempt to reestablish 3643 communication if it is configured as the client for the 3644 disconnected M3UA peer. 3646 The Heartbeat message may optionally contain an opaque Heartbeat Data 3647 parameter that MUST be echoed back unchanged in the related Heartbeat 3648 Ack message. The sender, upon examining the contents of the returned 3649 Heartbeat Ack message, MAY choose to consider the remote M3UA peer as 3650 unavailable. The contents/format of the Heartbeat Data parameter is 3651 implementation-dependent and only of local interest to the original 3652 sender. The contents may be used, for example, to support a Heartbeat 3653 sequence algorithm (to detect missing Heartbeats), and/or a timestamp 3654 mechanism (to evaluate delays). 3656 Note: Heartbeat related events are not shown in Figure 4 "ASP state 3657 transition diagram". 3659 4.4 Routing Key Management Procedures 3661 4.4.1 Registration 3663 An ASP MAY dynamically register with an SGP as an ASP within an 3664 Application Server using the REG REQ message. A Routing Key parameter 3665 in the REG REQ message specifies the parameters associated with the 3666 Routing Key. 3668 The SGP examines the contents of the received Routing Key parameter and 3669 compares it with the currently provisioned Routing Keys. If the 3670 received Routing Key matches an existing SGP Routing Key entry, and the 3671 ASP is not currently included in the list of ASPs for the related 3672 Application Server, the SGP MAY authorize the ASP to be added to the 3673 AS. Or, if the Routing Key does not currently exist and the received 3674 Routing Key data is valid and unique, an SGP supporting dynamic 3675 configuration MAY authorize the creation of a new Routing Key and 3676 related Application Server and add the ASP to the new AS. In either 3677 case, the SGP returns a Registration Response message to the ASP, 3678 containing the same Local-RK-Identifier as provided in the initial 3679 request, and a Registration Result "Successfully Registered". A unique 3680 Routing Context value assigned to the SGP Routing Key is included. The 3681 method of Routing Context value assignment at the SGP is 3682 implementation dependent but must be guaranteed to be unique for each 3683 Application Server or Routing Key supported by the SGP. 3685 If the SGP does not support the registration procedure, the SGP returns 3686 an Error message to the ASP, with an error code of "Unsupported Message 3687 Type". 3689 If the SGP determines that the received Routing Key data is invalid, or 3690 contains invalid parameter values, the SGP returns a Registration 3691 Response message to the ASP, containing a Registration Result "Error - 3692 Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network 3693 Appearance" as appropriate. 3695 If the SGP determines that a unique Routing Key cannot be created, the 3696 SGP returns a Registration Response message to the ASP, with a 3697 Registration Status of "Error - "Cannot Support Unique Routing" An 3698 incoming signalling message received at an SGP should not match against 3699 more than one Routing Key. 3701 If the SGP does not authorize an otherwise valid registration 3702 request, the SGP returns a REG RSP message to the ASP containing the 3703 Registration Result "Error - Permission Denied". 3705 If an SGP determines that a received Routing Key does not currently 3706 exist and the SGP does not support dynamic configuration, the SGP 3707 returns a Registration Response message to the ASP, containing a 3708 Registration Result "Error - Routing Key not Currently Provisioned". 3710 If an SGP determines that a received Routing Key does not currently 3711 exist and the SGP supports dynamic configuration but does not have the 3712 capacity to add new Routing Key and Application Server entries, the SGP 3713 returns a Registration Response message to the ASP, containing a 3714 Registration Result "Error - Insufficient Resources". 3716 If an SGP determines that one or more of the Routing Key parameters are 3717 not supported for the purpose of creating new Routing Key entries, the 3718 SGP returns a Registration Response message to the ASP, containing a 3719 Registration Result "Error - Unsupported RK parameter field". This 3720 result MAY be used if, for example, the SGP does not support RK Circuit 3721 Range Lists in a Routing Key because the SGP does not support ISUP 3722 traffic, or does not provide CIC range granularity. 3724 A Registration Response "Error - Unsupported Traffic Handling Mode" is 3725 returned if the Routing Key in the REG REQ contains an Traffic Handling 3726 Mode that is inconsistent with the presently configured mode for the 3727 matching Application Server. 3729 An ASP MAY register multiple Routing Keys at once by including a number 3730 of Routing Key parameters in a single REG REQ message. The SGP MAY 3731 respond to each registration request in a single REG RSP message, 3732 indicating the success or failure result for each Routing Key in a 3733 separate Registration Result parameter. Alternatively the SGP MAY 3734 respond with multiple REG RSP messages, each with one or more 3735 Registration Result parameters. The ASP uses the Local-RK-Identifier 3736 parameter to correlate the requests with the responses. 3738 Upon successful registration of an ASP in an AS, the SGP can now send 3739 related SS7 Signalling Network Management messaging, if this did not 3740 previously start upon the ASP transitioning to state ASP-INACTIVE 3742 4.4.2 Deregistration 3744 An ASP MAY dynamically deregister with an SGP as an ASP within an 3745 Application Server using the DEREG REQ message. A Routing Context 3746 parameter in the DEREG REQ message specifies which Routing Keys to 3747 deregister. An ASP SHOULD move to the ASP-INACTIVE state for an 3748 Application Server before attempting to deregister the Routing Key 3749 (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP 3750 SHOULD deregister from all Application Servers that it is a member 3751 before attempting to move to the ASP-Down state. 3753 The SGP examines the contents of the received Routing Context parameter 3754 and validates that the ASP is currently registered in the Application 3755 Server(s) related to the included Routing Context(s). If validated, 3756 the ASP is deregistered as an ASP in the related Application Server. 3758 The deregistration procedure does not necessarily imply the deletion of 3759 Routing Key and Application Server configuration data at the SG. Other 3760 ASPs may continue to be associated with the Application Server, in 3761 which case the Routing Key data MUST NOT be deleted. If a 3762 Deregistration results in no more ASPs in an Application Server, an SG 3763 MAY delete the Routing Key data. 3765 The SGP acknowledges the deregistration request by returning a DEREG 3766 RSP message to the requesting ASP. The result of the deregistration is 3767 found in the Deregistration Result parameter, indicating success or 3768 failure with cause. 3770 An ASP MAY deregister multiple Routing Contexts at once by including a 3771 number of Routing Contexts in a single DEREG REQ message. The SGP MAY 3772 respond to each deregistration request in a single DEREG RSP message, 3773 indicating the success or failure result for each Routing Context in a 3774 separate Deregistration Result parameter. 3776 4.4.3 IPSP Considerations (REG/DEREG) 3778 The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered. 3780 4.5 Procedures to Support the Availability or Congestion Status of SS7 3781 Destination 3783 4.5.1 At an SGP 3785 On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication 3786 primitive from the nodal interworking function at an SGP, the SGP M3UA 3787 layer will send a corresponding SS7 Signalling Network Management 3788 (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA 3789 peers at concerned ASPs. The M3UA layer must fill in various fields of 3790 the SSNM messages consistently with the information received in the 3791 primitives. 3793 The SGP M3UA layer determines the set of concerned ASPs to be informed 3794 based on the specific SS7 network for which the primitive indication 3795 is relevant. In this way, all ASPs configured to send/receive traffic 3796 within a particular network appearance are informed. If the SGP 3797 operates within a single SS7 network appearance, then all ASPs are 3798 informed. 3800 DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and 3801 processed at the receiver in the order sent. SCTP stream "0" is 3802 used to provide the sequencing. The only exception to this is if the 3803 international congestion method (see Q.704) is used. If so, the 3804 Unordered bit in the SCTP DATA chunk MAY be used for the SCON message. 3806 Sequencing is not required for the DUPU or DAUD messages, which MAY 3807 be sent unsequenced. Again, SCTP stream 0 is used, with optional use 3808 of the Unordered bit in the SCTP DATA chunk. 3810 4.5.2 At an ASP 3812 4.5.2.1 Single SGP Configurations 3814 At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) 3815 message from the remote M3UA Peer, the M3UA layer invokes the 3816 appropriate primitive indications to the resident M3UA-Users. Local 3817 management is informed. 3819 In the case where a local event has caused the unavailability or 3820 congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD 3821 pass up appropriate indications in the primitives to the M3UA User, as 3822 though equivalent SSNM messages were received. For example, the loss 3823 of an SCTP association to an SGP may cause the unavailability of a set 3824 of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User 3825 are appropriate. 3827 Implementation Note: To accomplish this, the M3UA layer at an ASP 3828 maintains the status of routes via the SG(P), much like an MTP3 layer 3829 maintains route-set status. 3831 4.5.2.2 Multiple SGP Configurations 3833 At an ASP, upon receiving a Signalling Network Management message from 3834 the remote M3UA Peer, the M3UA layer updates the status of the affected 3835 route(s) via the originating SG and determines, whether or not the 3836 overall availability or congestion status of the effected 3837 destination(s) has changed. If so, the M3UA layer invokes the 3838 appropriate primitive indications to the resident M3UA-Users. Local 3839 management is informed. 3841 4.5.3 ASP Auditing 3842 An ASP may optionally initiate an audit procedure to enquire 3843 of an SGP the availability and, if the national congestion method with 3844 multiple congestion levels and message priorities is used, congestion 3845 status of an SS7 destination or set of destinations. A Destination 3846 Audit (DAUD) message is sent from the ASP to the SGP requesting the 3847 current availability and congestion status of one or more SS7 3848 Destination Point Codes. 3850 The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the 3851 ASP in the following cases: 3853 - Periodic. A Timer originally set upon reception of a DUNA, SCON 3854 or DRST message has expired without a subsequent DAVA, 3855 DUNA, SCON or DRST message updating the 3856 availability/congestion status of the affected 3857 Destination Point Codes. The Timer is reset upon 3858 issuing a DAUD. In this case the DAUD is sent to the 3859 SGP that originally sent the SSNM message. 3861 - Isolation. The ASP is newly ASP-INACTIVE or ASP-ACTIVE or has been 3862 isolated from an SGP for an extended period. The ASP 3863 MAY request the availability/congestion status of one 3864 or more SS7 destinations to which it expects to 3865 communicate. 3867 In the first of the cases above, the auditing procedure must not be 3868 invoked for the case of a received SCON message containing a congestion 3869 level value of "no congestion" or undefined" (i.e., congestion Level = 3870 "0"). This is because the value indicates either congestion abatement 3871 or that the ITU MTP3 international congestion method is being used. In 3872 the international congestion method, the MTP3 layer at the SGP does not 3873 maintain the congestion status of any destinations and therefore the 3874 SGP cannot provide any congestion information in response to the DAUD. 3875 For the same reason, in the second of the cases above a DAUD message 3876 cannot reveal any congested destination(s). 3878 The SGP SHOULD respond to a DAUD message with the MTP3 3879 availability/congested status of the routeset associated with each 3880 Destination Point Code(s) in the DAUD message. The status of each SS7 3881 destination requested is indicated in a DUNA message (if unavailable), 3882 a DAVA message (if available), or a DRST (if restricted and the SGP 3883 supports this feature). Where the SGP maintains the congestion status 3884 of the SS7 destination, and the SS7 destination is congested, the SGP 3885 MUST additionally respond with an SCON message before the DAVA or DRST 3886 message. If the SS7 destination is available and congested, the SGP 3887 MUST respond with an SCON message and then a DAVA message. If the SS7 3888 destination is restricted and congested, the SGP MUST respond with 3889 an SCON message immediately followed by a DRST message. If the SGP 3890 has no information on the availability status of the SS7 destination, 3891 the SGP responds with a DUNA message, as it has no routing 3892 information to allow it to route traffic to this destination. 3894 Any DUNA or DAVA message in response to a DAUD message MAY contain a 3895 list of up to sixteen Affected Point Codes. 3897 An SG MAY refuse to provide the availability or congestion status of 3898 a destination if, for example, the ASP is not authorized to know the 3899 status of the destination. The SG MAY respond with an Error Message 3900 (Error Code = "Destination Status Unknown") 3902 4.6 MTP3 Restart 3904 In the case where the MTP3 in the SG undergoes an MTP restart, event 3905 communication SHOULD be handled as follows: 3907 When the SG discovers SS7 network isolation, the SGPs send an 3908 indication to all concerned available ASPs (i.e., ASPs in the ASP- 3909 ACTIVE state) using DUNA messages for the concerned destinations. 3911 When the SG has completed the MTP Restart procedure, the M3UA 3912 layers at the SGPs inform all concerned ASPs in the ASP-ACTIVE state 3913 of any available/restricted SS7 destinations using the DAVA/DRST 3914 messages. No message is necessary for those destinations still 3915 unavailable after the restart procedure. 3917 When the M3UA layer at an ASP receives a DUNA message indicating SS7 3918 destination unavailability at an SG, MTP Users will receive an 3919 MTP-PAUSE indication and will stop any affected traffic to this 3920 destination. When the M3UA receives a DAVA/DRST message, MTP Users 3921 will receive an MTP-RESUME indication and can resume traffic to the 3922 newly available SS7 destination, provided the ASP is in the 3923 ASP-ACTIVE state towards this SGP. 3925 The ASP MAY choose to audit the availability of unavailable 3926 destinations by sending DAUD messages. This would be for example the 3927 case when an AS becomes active at an ASP and does not have current 3928 destination statuses. If MTP restart is in progress at the 3929 SG, the SGP returns a DUNA message for that destination, even if it 3930 received an indication that the destination became available or 3931 restricted. 3933 In the IPSP case, MTP restart could be considered if the IPSP also has 3934 connection to an SS7 network. In that case, the same behavior as 3935 described above for the SGP would apply to the restarting IPSP. This 3936 would also be the case if the IPSPs were perceived as exchanging MTP 3937 Peer PDUs, instead of MTP primitives between MTP User and MTP 3938 Provider. In other words, M3UA does not provide the equivalent to 3939 Traffic Restart Allowed messages indicating the end of the restart 3940 procedure between peer IPSPs that would also be connected to an SS7 3941 network. 3943 5. Examples of M3UA Procedures 3945 5.1 Establishment of Association and Traffic between SGPs and ASPs 3947 These scenarios show the example M3UA message flows for the 3948 establishment of traffic between an SGP and an ASP or between two 3949 IPSPs. In all cases it is assumed that the SCTP association is 3950 already set up. 3952 5.1.1 Single ASP in an Application Server ("1+0" sparing), 3954 These scenarios show the example M3UA message flows for the 3955 establishment of traffic between an SGP and an ASP where only one ASP 3956 is configured within an AS (no backup). 3958 5.1.1.1 Single ASP/IPSP in an Application Server ("1+0" sparing), 3959 No Registration 3961 The sending of any DUNA/SCON messages by the SGP is not shown but is similar to the case described in Section 5.1.2. 3963 SGP ASP1 3964 | | 3965 |<-------------ASP Up------------| 3966 |-----------ASP Up Ack---------->| 3967 | | 3968 |<------- ASP Active(RCn)--------| RC: Routing Context 3969 |-----ASP Active Ack (RCn)------>| (optional) 3970 | | 3972 Note: If the ASP Active message contains an optional Routing Context 3973 parameter, The ASP Active message only applies for the specified RC 3974 value(s). For an unknown RC value, the SGP responds with an Error 3975 message. 3977 5.1.1.2 Single ASP in Application Server ("1+0" sparing), 3978 Dynamic Registration 3980 This scenario is the same as for 5.1.1.1 but with the optional exchange 3981 of registration information. In this case the Registration is accepted 3982 by the SGP. 3984 SGP ASP1 3985 | | 3986 |<------------ASP Up-------------| 3987 |----------ASP Up Ack----------->| 3988 | | 3989 |<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing 3990 | | Context 3991 |----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key 3992 | | RC: Routing Context 3993 | | 3994 |<------- ASP Active(RCn)--------| 3995 |-----ASP Active Ack (RCn)------>| 3996 | | 3998 Note: In the case of an unsuccessful registration attempt (e.g., 3999 invalid RKn), the Register Response message will contain an 4000 unsuccessful indication and the ASP will not subsequently send 4001 an ASP Active message. 4003 5.1.1.3 Single ASP in Multiple Application Servers (each 4004 with "1+0" sparing), Dynamic Registration (Case 1 - Multiple 4005 Registration Requests) 4007 SGP ASP1 4008 | | 4009 |<------------ASP Up-------------| 4010 |----------ASP Up Ack----------->| 4011 | | 4012 |<----REGISTER REQ(LRC1,RK1)-----| LRC: Local Routing 4013 | | Context 4014 |----REGISTER RESP(LRC1,RC1)---->| RK: Routing Key 4015 | | RC: Routing Context 4016 | | 4017 |<------- ASP Active(RC1)--------| 4018 |-----ASP Active Ack (RC1)------>| 4019 | | 4020 | | 4021 |<----REGISTER REQ(LRCn,RKn)-----| 4022 | | 4023 |----REGISTER RESP(LRCn,RCn)---->| 4024 | | 4025 | | 4026 |<------- ASP Active(RCn)--------| 4027 |-----ASP Active Ack (RCn)------>| 4028 | | 4030 Note: In the case of an unsuccessful registration attempt (e.g., 4031 invalid RKn), the Register Response message will contain an 4032 unsuccessful indication and the ASP will not subsequently send 4033 an ASP Active message. Each LRC/RK pair registration is considered 4034 independently. 4036 It is not necessary to follow a Registration Request/Response message 4037 pair with an ASP Active message before sending the next Registration 4038 Request. The ASP Active message can be sent at any time after the 4039 related successful registration. 4041 5.1.1.4 Single ASP in Multiple Application Servers (each 4042 with "1+0" sparing), Dynamic Registration (Case 2 - Single 4043 Registration Request) 4045 SGP ASP1 4046 | | 4047 |<------------ASP Up-------------| 4048 |----------ASP Up Ack----------->| 4049 | | 4050 |<---REGISTER REQ({LRC1,RK1},----| 4051 | ..., | 4052 | {LRCn,RKn}),----| 4053 | | 4054 |---REGISTER RESP({LRC1,RC1},--->| 4055 | ..., | 4056 | (LRCn,RCn}) | 4057 | | 4058 |<------- ASP Active(RC1)--------| 4059 |-----ASP Active Ack (RC1)------>| 4060 | | 4061 : : 4062 : : 4063 | | 4064 |<------- ASP Active(RCn)--------| 4065 |-----ASP Active Ack (RCn)------>| 4066 | | 4068 Note: In the case of an unsuccessful registration attempt (e.g., 4069 Invalid RKn), the Register Response message will contain an 4070 unsuccessful indication and the ASP will not subsequently 4071 send an ASP Active message. Each LRC/RK pair registration is 4072 considered independently. 4074 The ASP Active message can be sent at any time after the related 4075 successful registration, and may have more than one RC. 4077 5.1.2 Two ASPs in Application Server ("1+1" sparing) 4079 This scenario shows the example M3UA message flows for the 4080 establishment of traffic between an SGP and two ASPs in the same 4081 Application Server, where ASP1 is configured to be in the ASP-ACTIVE 4082 state and ASP2 is to be a "backup" in the event of communication failure or the withdrawal from service of ASP1. ASP2 may act as a hot, warm, or cold backup depending on the extent to which ASP1 and ASP2 share call/transaction state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP Active messages indicate "Override", "Loadshare" or "Broadcast" mode, although typically this example 4083 would use an Override mode. 4085 SGP ASP1 ASP2 4086 | | | 4087 |<--------ASP Up----------| | 4088 |-------ASP Up Ack------->| | 4089 | | | 4090 |<-----------------------------ASP Up----------------| 4091 |-----------------------------ASP Up Ack------------>| 4092 | | | 4093 | | | 4094 |<-------ASP Active-------| | 4095 |------ASP Active Ack---->| | 4096 | | | 4098 5.1.3 Two ASPs in an Application Server ("1+1" sparing, 4099 loadsharing case) 4101 This scenario shows a similar case to Section 5.1.2 but where the 4102 two ASPs are brought to the state ASP-ACTIVE and subsequently 4103 loadshare the traffic. In this case, one ASP is sufficient 4104 to handle the total traffic load. The sending of DUNA, DRST and 4105 SCON messages by the SGP is not shown but is similar to the case 4106 described in Section 5.1.2. 4108 SGP ASP1 ASP2 4109 | | | 4110 |<---------ASP Up---------| | 4111 |--------ASP Up Ack------>| | 4112 | | | 4113 |<------------------------------ASP Up---------------| 4114 |-----------------------------ASP Up Ack------------>| 4115 | | | 4116 | | | 4117 |<--ASP Active (Ldshr)----| | 4118 |-----ASP-Active Ack----->| | 4119 | | | 4120 |----------------------------NOTIFY (AS-ACTIVE------>| 4121 | | | 4122 |<----------------------------ASP Active (Ldshr)-----| 4123 |-------------------------------ASP Active Ack------>| 4124 | | | 4126 5.1.4 Three ASPs in an Application Server ("n+k" sparing, 4127 loadsharing case) 4129 This scenario shows the example M3UA message flows for the 4130 establishment of traffic between an SGP and three ASPs in the same 4131 Application Server, where two of the ASPs are brought to the state 4132 ASP-ACTIVE and subsequently share the load. In this case, a minimum 4133 of two ASPs are required to handle the total traffic load 4134 (2+1 sparing). The sending of DUNA, DRST and SCON messages by the 4135 SGP is not shown but is similar to the case described in Section 5.1.2. 4137 SGP ASP1 ASP2 ASP3 4138 | | | | 4139 |<------ASP Up-------| | | 4140 |-----ASP Up Ack---->| | | 4141 | | | | 4142 |<--------------------------ASP Up-------| | 4143 |-------------------------ASP Up Ack---->| | 4144 | | | | 4145 |<---------------------------------------------ASP Up--------| 4146 |---------------------------------------------ASP Up Ack---->| 4147 | | | | 4148 | | | | 4149 |<--ASP Act (Ldshr)--| | | 4150 |----ASP Act Ack---->| | | 4151 | | | | 4152 -----------Notify (AS-ACTIVE)----------->| | 4153 |-----------------------Notify (AS-ACTIVE)------------------>| 4154 | | | | 4155 |<--------------------ASP Act. (Ldshr)---| | 4156 |-----------------------ASP Act Ack----->| | 4157 | | | | 4159 5.2 ASP/IPSP Traffic Failover Examples 4161 5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Backup Override) 4163 Following on from the example in Section 5.1.2, and ASP1 4164 withdraws from service: 4166 SGP ASP1 ASP2 4167 | | | 4168 |<-----ASP Inactive-------| | 4169 |----ASP Inactive Ack---->| | 4170 |------------------------NTFY(AS-Pending)----------->| 4171 | | | 4172 |<------------------------------ ASP Active----------| 4173 |------------------------------ASP Active Ack------->| 4174 | | 4176 Note: If the SGP M3UA layer detects the loss of the M3UA peer 4177 (e.g., M3UA heartbeat loss or detection of SCTP failure), the 4178 initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. 4180 5.2.2 (1+1 Sparing, Backup Override) 4182 Following on from the example in Section 5.1.2, ASP2 wishes to 4183 Override ASP1 and take over the traffic: 4185 SGP ASP1 ASP2 4186 | | | 4187 |<------------------------------ ASP Active----------| 4188 |-------------------------------ASP Active Ack------>| 4189 |----NTFY(Alt ASP-Act)--->| 4190 | | | 4192 5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP) 4194 Following on from the example in Section 5.1.4, and ASP1 4195 withdraws from service: 4197 SGP ASP1 ASP2 ASP3 4198 | | | | 4199 |<----ASP Inact.-----| | | 4200 |---ASP Inact Ack--->| | | 4201 | | | | 4202 |---------------------------------NTFY(Ins. ASPs)----------->| 4203 | | | | 4204 |<-----------------------------------------ASP Act (Ldshr)---| 4205 |-------------------------------------------ASP Act (Ack)--->| 4206 | | | | 4208 For the Notify message to be sent, the SG maintains knowledge of 4209 the minimum ASP resources required (e.g., if the SG knows 4210 that "n+k" = "2+1" for a Loadshare AS and "n" currently equals 4211 "1"). 4213 Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., 4214 M3UA heartbeat loss or detection of SCTP failure), the initial ASP 4215 Inactive message exchange (i.e., SGP-ASP1) would not occur. 4217 5.3 Normal Withdrawal of an ASP from an Application Server 4218 and Teardown of an Association 4220 An ASP which is now confirmed in the state ASP-INACTIVE (i.e., 4221 the ASP has received an ASP Inactive Ack message) may now proceed 4222 to the ASP-DOWN state, if it is to be removed from service. Following 4223 on from Section 5.2.1 or 5.2.3, where ASP1 has moved to the 4224 "Inactive" state: 4226 SGP ASP1 4227 | | 4228 |<-----ASP Inactive (RCn)-------| RC: Routing Context 4229 |----ASP Inactive Ack (RCn)---->| 4230 | | 4231 |<-----DEREGISTER REQ(RCn)------| See Notes 4232 | | 4233 |---DEREGISTER RESP(LRCn,RCn)-->| 4234 | | 4235 : : 4236 | | 4237 |<-----------ASP Down-----------| 4238 |---------ASP Down Ack--------->| 4239 | | 4241 Note: The Deregistration procedure MUST be used if the ASP 4242 previously used the Registration procedures for configuration 4243 within the Application Server. ASP Inactive and Deregister 4244 messages exchanges may contain multiple Routing Contexts. 4246 The ASP should be in the ASP-INACTIVE state and should have 4247 deregistered in all its Routing Contexts before attempting to move 4248 to the ASP-DOWN state. 4250 5.4 M3UA/MTP3-User Boundary Examples 4252 5.4.1 At an ASP 4254 This section describes the primitive mapping between the MTP3 User and 4255 the M3UA layer at an ASP. 4257 5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP 4259 5.4.1.1.1 Support for MTP-TRANSFER Request Primitive 4261 When the MTP3-User on the ASP has data to send to a remote 4262 MTP3-User, it uses the MTP-TRANSFER request primitive. The M3UA 4263 layer at the ASP will do the following when it receives an 4264 MTP-TRANSFER request primitive from the M3UA user: 4266 - Determine the correct SGP; 4268 - Determine the correct association to the chosen SGP; 4270 - Determine the correct stream in the association (e.g., based on 4271 SLS); 4273 - Determine whether to complete the optional fields of the DATA 4274 message; 4276 - Map the MTP-TRANSFER request primitive into the Protocol Data 4277 field of a DATA message; 4279 - Send the DATA message to the remote M3UA peer at the SGP, over 4280 the SCTP association. 4282 SGP ASP 4283 | | 4284 |<-----DATA Message-------|<--MTP-TRANSFER req. 4285 | | 4287 5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive 4289 When the M3UA layer on the ASP receives a DATA message from the 4290 M3UA peer at the remote SGP, it will do the following: 4292 - Evaluate the optional fields of the DATA message, if present; 4294 - Map the Protocol Data field of a DATA message into the MTP-TRANSFER 4295 indication primitive; 4297 - Pass the MTP-TRANSFER indication primitive to the user part. In 4298 case of multiple user parts, the optional fields of the Data 4299 message are used to determine the concerned user part. 4301 SGP ASP 4302 | | 4303 |------Data Message------>|-->MTP-Transfer ind. 4304 | | 4306 5.4.1.1.3 Support for ASP Querying of SS7 Destination States 4308 There are situations such as temporary loss of connectivity to the SGP 4309 that may cause the M3UA layer at the ASP to audit SS7 destination 4310 availability/congestion states. Note: there is no primitive for the 4311 MTP3-User to request this audit from the M3UA layer as this is 4312 initiated by an internal M3UA management function. 4314 SGP ASP 4315 | | 4316 |<----------DAUD----------| 4317 |<----------DAUD----------| 4318 |<----------DAUD----------| 4319 | | 4320 | | 4322 5.4.2 At an SGP 4324 This section describes the primitive mapping between the MTP3-User and 4325 the M3UA layer at an SGP. 4327 5.4.2.1 Support for MTP-TRANSFER Request Primitive at the SGP 4329 When the M3UA layer at the SGP has received DATA messages from its peer 4330 destined to the SS7 network it will do the following: 4332 - Evaluate the optional fields of the DATA message, if present, to 4333 determine the Network Appearance; 4335 - Map the Protocol data field of the DATA message into an MTP- 4336 TRANSFER request primitive; 4338 - Pass the MTP-TRANSFER request primitive to the MTP3 of the 4339 concerned Network Appearance. 4341 SGP ASP 4342 | | 4343 <---MTP-TRANSFER req.|<---------DATA ----------| 4344 | | 4346 5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP 4348 When the MTP3 layer at the SGP has data to pass its user parts, it will 4349 use the MTP-TRANSFER indication primitive. The M3UA layer at the SGP 4350 will do the following when it receives an MTP-TRANSFER indication 4351 primitive: 4353 - Determine the correct AS using the distribution function; 4355 - Select an ASP in the ASP-ACTIVE state 4357 - Determine the correct association to the chosen ASP; 4359 - Determine the correct stream in the SCTP association (e.g., based 4360 on SLS); 4362 - Determine whether to complete the optional fields of the DATA 4363 message; 4365 - Map the MTP-TRANSFER indication primitive into the Protocol Data 4366 field of a DATA message; 4368 - Send the DATA message to the remote M3UA peer in the ASP, over the 4369 SCTP association 4371 SGP ASP 4372 | | 4373 --MTP-TRANSFER ind.->|----------DATA --------->| 4374 | | 4376 5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication 4377 Primitives 4379 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the 4380 MTP3 upper layer interface at the SGP need to be made available to the 4381 remote MTP3 User Part lower layer interface at the concerned ASP(s). 4383 5.4.2.3.1 Destination Unavailable 4385 The MTP3 layer at the SGP will generate an MTP-PAUSE indication 4386 primitive when it determines locally that an SS7 destination is 4387 unreachable. The M3UA layer will map this primitive to a DUNA message. 4388 The SGP M3UA layer determines the set of concerned ASPs to be informed 4389 based on internal SS7 network information associated with the MTP-PAUSE 4390 indication primitive indication. 4392 SGP ASP 4393 | | 4394 --MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.--> 4395 | | 4397 5.4.2.3.2 Destination Available 4399 The MTP3 at the SGP will generate an MTP-RESUME indication primitive 4400 when it determines locally that an SS7 destination that was previously 4401 unreachable is now reachable. The M3UA layer will map this primitive 4402 to a DAVA message. The SGP M3UA determines the set of concerned ASPs 4403 to be informed based on internal SS7 network information associated 4404 with the MTP-RESUME indication primitive. 4406 SGP ASP 4407 | | 4408 --MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.--> 4409 | | 4411 5.4.2.3.3 SS7 Network Congestion 4413 The MTP3 layer at the SGP will generate an MTP-STATUS indication 4414 primitive when it determines locally that the route to an SS7 4415 destination is congested. The M3UA layer will map this primitive to a 4416 SCON message. It will determine which ASP(s) to send the SCON message 4417 to, based on the intended Application Server. 4419 SGP ASP 4420 | | 4421 --MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.--> 4422 | | 4424 5.4.2.3.4 Destination User Part Unavailable 4426 The MTP3 layer at the SGP will generate an MTP-STATUS indication 4427 primitive when it receives an UPU message from the SS7 network. The 4428 M3UA layer will map this primitive to a DUPU message. It will 4429 determine which ASP(s) to send the DUPU based on the intended 4430 Application Server. 4432 SGP ASP 4433 | | 4434 --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.--> 4435 | | 4437 5.5 Examples for IPSP communication. 4439 These scenarios show a basic example for IPSP communication for the 4440 three phases of the connection (establishment, data exchange, 4441 disconnection). It is assumed that the SCTP association is already set 4442 up. Both single exchange and double exchange behavior are included 4443 for illustrative purposes. 4445 5.5.1 Single exchange: 4447 IPSP-A IPSP-B 4448 | | 4449 |-------------ASP Up------------>| 4450 |<----------ASP Up Ack-----------| 4451 | | 4452 |<------- ASP Active(RCb)--------| RC: Routing Context 4453 |-----ASP Active Ack (RCb)------>| (optional) 4454 | | 4455 | | 4456 |<========= DATA (RCb) ========>| 4457 | | 4458 |<-----ASP Inactive (RCb)--------| RC: Routing Context 4459 |----ASP Inactive Ack (RCb)----->| (optional) 4460 | | 4461 |<-----------ASP Down------------| 4462 |---------ASP Down Ack---------->| 4463 | | 4465 Routing Context are previously agreed to be the same in both directions. 4467 5.5.2 Double exchange: 4469 IPSP-A IPSP-B 4470 | | 4471 |<-------------ASP Up------------| 4472 |-----------ASP Up Ack---------->| 4473 | | 4474 |-------------ASP Up------------>| (optional) 4475 |<----------ASP Up Ack-----------| (optional) 4476 | | 4477 |<------- ASP Active(RCb)--------| RC: Routing Context 4478 |-----ASP Active Ack (RCb)------>| (optional) 4479 | | 4480 |------- ASP Active(RCa)-------->| RC: Routing Context 4481 |<-----ASP Active Ack (RCa)------| (optional) 4482 | | 4483 |<========= DATA (RCa) =========| 4484 |========== DATA (RCb) ========>| 4485 | | 4486 |<-----ASP Inactive (RCb)--------| RC: Routing Context 4487 |----ASP Inactive Ack (RCb)----->| 4488 | | 4489 |------ASP Inactive (RCa)------->| RC: Routing Context 4490 |<----ASP Inactive Ack (RCa)-----| 4491 | | 4492 |<-----------ASP Down------------| 4493 |---------ASP Down Ack---------->| 4494 | | 4495 |------------ASP Down----------->| (optional) 4496 |<--------ASP Down Ack-----------| (optional) 4497 | | 4499 In this approach, only one single exchange of ASP Up message can be 4500 considered as enough since the response by the other peer can be 4501 considered as a notice that it is in ASP_UP state. 4503 For the same reason, only one ASP Down message is needed since once 4504 that an IPSP receives ASP_Down ack message it is itself considered as 4505 being in the ASP_Down state and not allowed to receive ASPSM messages. 4507 6. Security Considerations 4509 6.1 Introduction 4511 M3UA is designed to carry signalling messages for telephony services. 4512 As such, M3UA must involve the security needs of several parties: the 4513 end users of the services; the network providers and the applications 4514 involved. Additional requirements may come from local regulation. 4515 While having some overlapping security needs, any security solution 4516 should fulfill all of the different parties' needs. 4518 6.2 Threats 4520 There is no quick fix, one-size-fits-all solution for security. As a 4521 transport protocol, M3UA has the following security objectives: 4523 * Availability of reliable and timely user data transport. 4524 * Integrity of user data transport. 4525 * Confidentiality of user data. 4527 M3UA is recommended to be transported on SCTP. SCTP [13] provides 4528 certain transport related security features, such as some protection 4529 against: 4531 * Blind Denial of Service Attacks 4532 * Flooding 4533 * Masquerade 4534 * Improper Monopolization of Services 4536 When M3UA is running in professionally managed corporate or service 4537 provider network, it is reasonable to expect that this network includes 4538 an appropriate security policy framework. The "Site Security Handbook" 4539 [21] should be consulted for guidance. 4541 When the network in which M3UA runs in involves more than one party, it 4542 may not be reasonable to expect that all parties have implemented 4543 security in a sufficient manner. In such a case, it is recommended 4544 that IPSEC is used to ensure confidentiality of user payload. Consult 4545 [22] for more information on configuring IPSEC services. 4547 6.3 Protecting Confidentiality 4549 Particularly for mobile users, the requirement for confidentiality may 4550 include the masking of IP addresses and ports. In this case 4551 application level encryption is not sufficient; IPSEC ESP [23] SHOULD 4552 be used instead. Regardless of which level performs the encryption, 4553 the IPSEC ISAKMP [24] service SHOULD be used for key management. 4555 7. IANA Considerations 4557 7.1 SCTP Payload Protocol Identifier 4559 IANA has assigned an M3UA value for the Payload Protocol Identifier in 4560 the SCTP DATA chunk. The following SCTP Payload Protocol Identifier is 4561 registered: 4563 M3UA "3" 4565 The SCTP Payload Protocol Identifier value "3" SHOULD be included in 4566 each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA 4567 protocol. The value "0" (unspecified) is also allowed but any other 4568 values MUST not be used. This Payload Protocol Identifier is not 4569 directly used by SCTP but MAY be used by certain network entities to 4570 identify the type of information being carried in a DATA chunk. 4572 The User Adaptation peer MAY use the Payload Protocol Identifier as a 4573 way of determining additional information about the data being 4574 presented to it by SCTP. 4576 7.2 M3UA Port Number 4578 IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It 4579 is recommended that SGPs use this SCTP port number for listening for 4580 new connections. SGPs MAY also use statically configured SCTP port 4581 numbers instead. 4583 7.3 M3UA Protocol Extensions 4585 This protocol may also be extended through IANA in three ways: 4586 -- through definition of additional message classes, 4587 -- through definition of additional message types, and 4588 -- through definition of additional message parameters 4590 The definition and use of new message classes, types and parameters is 4591 an integral part of SIGTRAN adaptation layers. Thus these extensions 4592 are assigned by IANA through an IETF Consensus action as defined in 4593 Guidelines for Writing an IANA Considerations Section in RFCs (25] 4595 The proposed extension must in no way adversely affect the general 4596 working of the protocol. 4598 7.3.1 IETF Defined Message Classes 4600 The documentation for a new message class MUST include the following 4601 information: 4602 (a) A long and short name for the new message class; 4603 (b) A detailed description of the purpose of the message class. 4605 7.3.2 IETF Defined Message Types 4607 The documentation for a new message type MUST include the following 4608 information: 4610 (a) A long and short name for the new message type; 4611 (b) A detailed description of the structure of the message;. 4612 (c) A detailed definition and description of intended use for each 4613 field within the message; 4614 (d) A detailed procedural description of the use of the new message 4615 type within the operation of the protocol; 4616 (e) A detailed description of error conditions when receiving this 4617 message type. 4619 When an implementation receives a message type which it does not 4620 support, it MUST respond with an Error (ERR) message ("Unsupported 4621 Message Type"). 4623 7.3.3 IETF Defined Parameter Extension 4625 Documentation of the message parameter MUST contain the following 4626 information: 4628 (a) Name of the parameter type; 4629 (b) Detailed description of the structure of the parameter field. This 4630 structure MUST conform to the general type-length-value format 4631 described in Section 3.2; 4632 (c) Detailed definition of each component of the parameter value; 4633 (d) Detailed description of the intended use of this parameter type, 4634 and an indication of whether and under what circumstances multiple 4635 instances of this parameter type may be found within the same 4636 message. 4638 8. Acknowledgements 4640 The authors would like to thank Antonio Roque Alvarez, Joyce Archibald, 4641 Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain, 4642 Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto 4643 Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, 4644 Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, 4645 John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, 4646 Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their 4647 valuable comments and suggestions. 4649 9. References 4651 [1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong 4652 et al, October 1999 4654 [2] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7) 4655 - ISDN User Part (ISUP)" 4657 [3] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part" 4659 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 4660 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 4661 international interface; Part 1: Basic services" 4663 [5] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 4664 (SS7) - Signalling Connection Control Part (SCCP)" 4666 [6] ANSI T1.112 "Signaling System Number 7 - Signaling Connection 4667 Control Part" 4669 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 4670 Signalling System No.7; Signalling Connection Control Part (SCCP) 4671 (connectionless and connection-oriented class 2) to support 4672 international interconnection; Part 1: Protocol specification" 4674 [8] ITU-T Recommendation Q.720, "Telephone User Part" 4676 [9] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) 4677 - Transaction Capabilities (TCAP)" 4679 [10] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities 4680 Application Part" 4682 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 4683 Signalling System No.7; Transaction Capabilities (TC) version 2; 4684 Part 1: Protocol specification" 4686 [12] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd 4687 Generation partnership Project; Technical Specification Group 4688 Radio Access Network; UTRAN Iu Interface: General Aspects and 4689 Principles" 4691 [13] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, 4692 October 2000. 4694 [14] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7 4695 (SS7) - Message Transfer Part (MTP)" 4697 [15] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part" 4699 [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 4700 Signalling System No.7; Message Transfer Part (MTP) to support 4701 international interconnection; Part 1: Protocol specification" 4703 [17] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service 4704 Specific Coordination Function for signalling at the Network Node 4705 Interface (SSCF at NNI)" 4707 [18] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service 4708 Specific Connection Oriented Protocol (SSCOP)" 4710 [19] RFC 2119, "Key words for use in RFCs to Indicate Requirement 4711 Levels", S. Bradner, March 1997. 4713 [20] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 4714 functions and messages using the services of ITU Recommendation 4715 Q.2140" 4717 [21] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 4719 [22] RFC 2401, "Security Architecture for the Internet Protocol", S. 4720 Kent, R. Atkinson, November 1998. 4722 [23] RFC 2406, "IP Encapsulating Security Payload (ESP)", S.Kent and 4723 R. Atkinson, November 1998. 4725 [24] RFC 2408, "Internet Security Association and Key Management 4726 Protocol", D. Maughan, M. Schertler, M. Schneider and J. Turner, 4727 November 1998. 4729 [25] RFC 2434, "Guidelines for Writing an IANA Considerations Section 4730 in RFCs", T. Narten and H. Alvestrand, October 1998 4732 [26] , "MTP2-User Adaptation Layer", 4733 K. Morneault et al, Sept 2001 (Work in Progress) 4735 [27] , "SS7 MTP2-User Peer-to-Peer 4736 Adaptation Layer", Tom George et al, July 2001 (Work in Progress) 4738 10. Author's Addresses 4740 Greg Sidebottom 4741 gregside consulting 4742 Kanata, Ontario, Canada 4743 EMail: gregside@home.com 4745 Javier Pastor-Balb�s 4746 Ericsson Espa�a S.A. 4747 C/ Omb" 3 4748 28045 Madrid - Spain 4749 EMail: j.javier.pastor@ericsson.com 4751 Guy Mousseau 4752 Nortel Networks 4753 3685 Richmond Rd 4754 Nepean, Ontario, Canada K2H 5B7 4756 Lyndon Ong 4757 Ciena 4758 10480 Ridgeview Court 4759 Cupertino, CA 95014 4760 EMail: lyong@ciena.com 4762 Ian Rytina 4763 Ericsson Australia 4764 37/360 Elizabeth Street 4765 Melbourne, Victoria 3000, Australia 4766 EMail: ian.rytina@ericsson.com.au 4768 Hanns Juergen Schwarzbauer 4769 SIEMENS AG 4770 Hofmannstr. 51 4771 81359 Munich, Germany 4772 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de 4774 Klaus D. Gradischnig 4775 NeuStar, Inc 4776 1120 Vermont Ave. N.W.Suite 400 4777 Washington D.C 20005 4778 EMail: klaus.gradischnig@neustar.com 4780 Ken Morneault 4781 Cisco Systems Inc. 4782 13615 Dulles Technology Drive 4783 Herndon, VA, USA 20171 4784 EMail: kmorneau@cisco.com 4786 Malleswar Kalla 4787 Telcordia Technologies 4788 MCC 1J211R 4789 445 South Street 4790 Morristown, NJ, USA 07960 4791 Email: kalla@research.telcordia.com 4793 Normand Glaude 4794 Performance Technologies 4795 150 Metcalf Sreet, Suite 1300 4796 Ottawa, Ontario, Canada K2P 1P1 4797 EMail: nglaude@microlegend.com 4799 Brian Bidulock 4800 OpenSS7 Corporation 4801 c/o #424, 4701 Preston Park Blvd. 4802 Plano, TX, USA 75093 4803 EMail: bidulock@openss7.org 4804 John Loughney 4805 Nokia Research Center 4806 PO Box 407 4807 FIN-00045 Nokia Group 4808 Finland 4809 EMail: john.loughney@nokia.com 4811 This draft expires May 2002. 4813 Appendix A 4815 A.1 Signalling Network Architecture 4817 A Signalling Gateway is used to support the transport of MTP3-User 4818 signalling traffic received from the SS7 network to multiple 4819 distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA 4820 protocol is not designed to meet the performance and reliability 4821 requirements for such transport by itself. However, the conjunction 4822 of distributed architecture and redundant networks provides support 4823 for reliable transport of signalling traffic over IP. The M3UA 4824 protocol is flexible enough to allow its operation and management 4825 in a variety of physical configurations, enabling Network Operators 4826 to meet their performance and reliability requirements. 4828 To meet the stringent SS7 signalling reliability and performance 4829 requirements for carrier grade networks, Network Operators might require 4830 that no single point of failure is present in the end-to-end 4831 network architecture between an SS7 node and an IP-based application. 4832 This can typically be achieved through the use of redundant SGPs or 4833 SGs, redundant hosts, and the provision of redundant QOS-bounded IP 4834 network paths for SCTP Associations between SCTP End Points. Obviously, 4835 the reliability of the SG, the MGC and other IP-based functional 4836 elements also needs to be taken into account. The distribution of ASPs 4837 and SGPs within the available Hosts MAY also be considered. As an 4838 example, for a particular Application Server, the related ASPs could 4839 be distributed over at least two Hosts. 4841 One example of a physical network architecture relevant to SS7 carrier- 4842 grade operation in the IP network domain is shown in Figure 1 below: 4844 SGs MGCs 4846 Host#1 ************** ************** Host#3 4847 * ********__*__________________________*__******** * = 4848 * *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1 4849 * ******** * \ / * ******** * 4850 * ********__*______\__/________________*__******** * 4851 * *SGP2.1*__*_______\/______ _____*__* ASP2 * * 4852 * ******** * /\ | | * ******** * 4853 * : * / \ | | * : * 4854 * ******** * / \ | | * ******** * 4855 * * SGPn * * | | | | * * ASPn * * 4856 * ******** * | | | | * ******** * 4857 ************** | | | | ************** 4858 | | \ / 4859 Host#2 ************** | | \ / ************** Host#4 4860 * ********__*_____| |______\/_______*__******** * = 4861 * *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2 4862 * ******** * / \ * ******** * 4863 * ********__*_______________/ \_____*__******** * 4864 * *SGP2.2*__*__________________________*__* ASP2 * * 4865 * ******** * * ******** * 4866 * : * SCTP Associations * : * 4867 * ******** * * ******** * 4868 * * SGPn * * * * ASPn * * 4869 * ******** * * ******** * 4870 ************** ************** 4872 SGP1.1 and SGP1.2 are part of SG1 4873 SGP2.1 and SGP2.2 are part of SG2 4875 Figure 1 - Physical Model 4877 In this model, each host MAY have many application processes. In the 4878 case of the MGC, an ASP may provide service to one or more Application 4879 Servers, and is identified as an SCTP end point. One or more 4880 Signalling Gateway Processes make up a single Signalling Gateway. 4882 This example model can also be applied to IPSP-IPSP signalling. In 4883 this case, each IPSP MAY have its services distributed across 2 hosts 4884 or more, and may have multiple server processes on each host. 4886 In the example above, each signalling process (SGP, ASP or IPSP) is the 4887 end point to more than one SCTP association, leading to more than one 4888 other signalling processes. To support this, a signalling process must 4889 be able to support distribution of M3UA messages to many simultaneous 4890 active associations. This message distribution function is based on 4891 the status of provisioned Routing Keys, the status of the signalling 4892 routes to signalling points in the SS7 network , and the redundancy 4893 model (active-standby, load sharing, broadcast, n+k) of the remote 4894 signalling processes. 4896 For carrier grade networks, the failure or isolation of a particular 4897 signalling process should not cause stable calls or transactions to be 4898 lost. This implies that signalling processes need, in some cases, to 4899 share the call/transaction state or be able to pass the call state 4900 information between each other. In the case of ASPs performing call 4901 processing, coordination may also be required with the related Media 4902 Gateway to transfer the MGC control for a particular trunk termination. 4903 However, this sharing or communication of call/transaction state 4904 information is outside the scope of this document. 4906 This model serves as an example. M3UA imposes no restrictions as to 4907 the exact layout of the network elements, the message distribution 4908 algorithms and the distribution of the signalling processes. Instead, 4909 it provides a framework and a set of messages that allow for a flexible 4910 and scalable signalling network architecture, aiming to provide 4911 reliability and performance. 4913 A.2 Redundancy Models 4915 A.2.1 Application Server Redundancy 4917 At the SGP, an Application Server list contains active and inactive 4918 ASPs to support ASP broadcast, loadsharing and failover procedures. 4919 The list of ASPs within a logical Application Server is kept updated in 4920 the SGP to reflect the active Application Server Process(es). 4922 For example, in the network shown in Figure 1, all messages to DPC x 4923 could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1 4924 in Host 1 might look like the following: 4926 Routing Key {DPC=x) - "Application Server #1" 4927 ASP1/Host3 - State = Active 4928 ASP1/Host4 - State = Inactive 4930 In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming 4931 message with DPC=x. ASP1 in Host4 would normally be brought to the 4932 "active" state upon failure of, or loss of connectivity to, ASP1/Host1. 4934 The AS List at SGP1 in Host1 might also be set up in loadshare mode: 4936 Routing Key {DPC=x) - "Application Server #1" 4937 ASP1/Host3 - State = Active 4938 ASP1/Host4 - State = Active 4940 In this case, both the ASPs would be sent a portion of the traffic. 4941 For example the two ASPs could together form a database, where incoming 4942 queries may be sent to any active ASP. 4944 Care might need to be exercised by a Network Operator in the selection 4945 of the routing information to be used as the Routing Key for a 4946 particular AS. 4948 For example, where Application Servers are defined using ranges of ISUP 4949 CIC values, the Operator is implicitly splitting up control of the 4950 related circuit groups. Some CIC value range assignments may interfere 4951 with ISUP circuit group management procedures. 4953 In the process of failover, it is recommended that in the case of ASPs 4954 supporting call processing, stable calls do not fail. It is possible 4955 that calls in "transition" MAY fail, although measures of communication 4956 between the ASPs involved can be used to mitigate this. For example, 4957 the two ASPs MAY share call state via shared memory, or MAY use an ASP 4958 to ASP protocol to pass call state information. Any ASP-to-ASP 4959 protocol to support this function is outside the scope of this 4960 document. 4962 A.2.2 Signalling Gateway Redundancy 4964 Signalling Gateways MAY also be distributed over multiple hosts. Much 4965 like the AS model, SGs may comprise one or more SG Processes (SGPs), 4966 distributed over one or more hosts, using an active/backup or a 4967 loadsharing model. Should an SGP lose all or partial SS7 4968 connectivity and other SGPs exist, the SGP MUST terminate the SCTP 4969 associations to the concerned ASPs. 4971 It is therefore possible for an ASP to route signalling messages 4972 destined to the SS7 network using more than one SGP. In this model, a 4973 Signalling Gateway is deployed as a cluster of hosts acting as a single 4974 SG. A primary/backup redundancy model is possible, where the 4975 unavailability of the SCTP association to a primary SGP could be used 4976 to reroute affected traffic to an alternate SGP. A loadsharing model 4977 is possible, where the signalling messages are loadshared between 4978 multiple SGPs. A broadcast model is also possible, where signalling 4979 messages are sent to each active SGP in the SG. The distribution of the 4980 MTP3-user messages over the SGPs should be done in such a way to 4981 minimize message missequencing, as required by the SS7 User Parts. 4983 It may also be possible for an ASP to use more than one SG to access a 4984 specific SS7 end point, in a model that resembles an SS7 STP mated 4985 pair. Typically, SS7 STPs are deployed in mated pairs, with traffic 4986 loadshared between them. Other models are also possible, subject to 4987 the limitations of the local SS7 network provisioning guidelines. 4989 >From the perspective of the M3UA layer at an ASP, a particular SG is 4990 capable of transferring traffic to a provisioned SS7 destination X if 4991 an SCTP association with at least one SGP of the SG is established, 4992 the SGP has returned an acknowledgement to the ASP to indicate that 4993 the ASP is actively handling traffic for that destination X, the SGP 4994 has not indicated that the destination X is inaccessible and the SGP 4995 has not indicated MTP Restart. When an ASP is configured to use 4996 multiple SGPs for transferring traffic to the SS7 network, the ASP 4997 must maintain knowledge of the current capability of the SGPs to 4998 handle traffic to destinations of interest. This information is 4999 crucial to the overall reliability of the service, for active/backup, 5000 loadsharing and broadcast models, in the event of failures, recovery 5001 and maintenance activities. The ASP M3UA may also use this 5002 information for congestion avoidance purposes. The distribution of 5003 the MTP3-user messages over the SGPs should be done in such a way to 5004 minimize message missequencing, as required by the SS7 User Parts. 5006 This draft expires May 2002