idnits 2.17.1 draft-ietf-sigtran-m3ua-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 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 1) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 96 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 257: '... the SCTP functions above MAY NOT be a...' RFC 2119 keyword, line 362: '...The M3UA layer MAY be instructed by lo...' RFC 2119 keyword, line 372: '...The M3UA layer MAY also need to inform...' RFC 2119 keyword, line 374: '...xample, the M3UA MAY inform local mana...' RFC 2119 keyword, line 407: '...ade networks, Network Operators SHOULD...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2982 has weird spacing: '...opriate respo...' == Line 3319 has weird spacing: '...essages until...' == Line 3492 has weird spacing: '...essages until...' == Line 3735 has weird spacing: '...of received S...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Under certain scenarios, such as back-to-back connections without redundancy requirements, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol. == 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 Affected Destinations parameter can be used to indicate congestion of multiple destinations or ranges of destinations. However, an SCON MUST not be delayed in order to "collect" individual congested destinations into a single SCON as any delay might affect the timing of congestion indications to the M3UA Users. One use for including a range of Congested DPCs is when the SG supports an ANSI cluster route set to the SS7 network that becomes congested due to outgoing link set congestion. == 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: When an ASP Active (ASPAC) message is received, the SG or IPSP responds with an ASPAC Ack message(with the same Type value contained in the received APAC), acknowledging that the ASPAC was received and, depending on the ASPAC Type value, moves the ASP to the "Active" or "Standby" state within the associated Application Server(s). Layer Management is informed with an ASP-Active indication primitive. If the SG or IPSP receives any Data messages before an ASPAC is received, the SG or IPSP should discard them. By sending an ASPAC Ack, the SG or IPSP is now ready to receive and send traffic for the related Routing Contexts. The ASP MUST not send Data messages before receiving an ASPAC Ack. -- 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 (Feb 2001) is 8470 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 1320 -- Looks like a reference, but probably isn't: 'M3UA' on line 1364 -- Looks like a reference, but probably isn't: 'IUA' on line 1369 -- Looks like a reference, but probably isn't: 'M2UA' on line 1370 -- Looks like a reference, but probably isn't: 'SUA' on line 1372 -- Looks like a reference, but probably isn't: 'RFC2434' on line 4285 ** 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. '19' -- 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) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Sidebottom (Editor) 2 INTERNET-DRAFT Guy Mousseau 3 Nortel Networks 4 Lyndon Ong 5 Point Reyes Networks 6 Ian Rytina 7 Ericsson 8 Hanns-Juergen Schwarzbauer 9 Klaus Gradischnig 10 Siemens 11 Ken Morneault 12 Cisco 13 Mallesh Kalla 14 Telcordia 15 Normand Glaude 16 Performance Technologies 18 Expires in six months Feb 2001 20 SS7 MTP3-User Adaptation Layer (M3UA) 21 23 Status of This Memo 25 This document is an Internet-Draft and is in full conformance with all 26 provisions of Section 10 of RFC 2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, and 28 its working groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference material 34 or to cite them other than as 'work in progress.' 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 To learn the current status of any Internet-Draft, please check the 43 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 44 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 45 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 46 ftp.isi.edu (US West Coast). 48 Abstract 50 This Internet Draft defines a protocol for supporting the transport of 51 any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP 52 using the services of the Stream Control Transmission Protocol. Also, 53 provision is made for protocol elements that enable a seamless 54 operation of the MTP3-User peers in the SS7 and IP domains. This 55 protocol would be used between a Signalling Gateway (SG) and a Media 56 Gateway Controller (MGC) or IP-resident Database. It is assumed that 57 the SG receives SS7 signalling over a standard SS7 interface using the 58 SS7 Message Transfer Part (MTP) to provide transport. 60 TABLE OF CONTENTS 62 1. Introduction.......................................................4 63 1.1 Scope.........................................................4 64 1.2 Terminology...................................................4 65 1.3 M3UA Overview.................................................6 66 1.4 Functional Areas.............................................12 67 1.5 Sample Configurations........................................23 68 1.6 Definition of M3UA Boundaries................................26 69 2. Conventions.......................................................29 70 3. M3UA Protocol Elements............................................29 71 3.1 Common Message Header........................................29 72 3.2 Variable-Length Parameter....................................32 73 3.3 Transfer Messages............................................33 74 3.4 SS7 Signalling Network management (SSNM) Messages............36 75 3.5 Application Server Process Maintenance (ASPM) Messages.......44 76 3.6 Management Messages..........................................60 77 4. Procedures........................................................63 78 4.1 Procedures to Support the Services of the M3UA Layer.........63 79 4.2 Receipt of M3UA Peer Management Messages.....................65 80 4.3 Procedures to support the M3UA Management services...........66 81 4.4 Procedures to Support the M3UA Services......................78 82 5. Examples of M3UA Procedures.......................................81 83 5.1 Establishment of Association and Traffic 84 Between SGs and ASPs.........................................81 85 5.2 ASP traffic Fail-over Examples...............................86 86 5.3 M3UA/MTP3-User Boundary Examples.............................87 87 6. Security..........................................................91 88 6.1 Introduction.................................................91 89 6.2 Threats......................................................91 90 6.3 Protecting Confidentiality...................................91 91 7. IANA Considerations...............................................92 92 7.1 SCTP Payload Protocol Identifier.............................92 93 7.2 M3UA Protocol Extensions.....................................92 94 8. Acknowledgements..................................................93 95 9. References........................................................93 96 10. Author's Addresses...............................................95 97 1. Introduction 99 1.1 Scope 101 There is a need for Switched Circuit Network (SCN) signalling protocol 102 delivery from an SS7 Signalling Gateway (SG) to a Media Gateway 103 Controller (MGC) or IP-resident Database as described in the Framework 104 Architecture for Signalling Transport [1]. The delivery mechanism 105 SHOULD meet the following criteria: 107 * Support for the transfer of all SS7 MTP3-User Part messages (e.g., 108 ISUP, SCCP, TUP, etc.) 109 * Support for the seamless operation of MTP3-User protocol peers 110 * Support for the management of SCTP transport associations and 111 traffic between an SG and one or more MGCs or IP-resident Databases 112 * Support for MGC or IP-resident Database process fail-over and load- 113 sharing 114 * Support for the asynchronous reporting of status changes to 115 management 117 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 118 protocol layers and deliver ISUP, SCCP and/or any other MTP3-User 119 protocol messages, as well as certain MTP network management events, 120 over SCTP transport associations to MTP3-User peers in MGCs or IP- 121 resident Databases. 123 1.2 Terminology 125 Application Server (AS) - A logical entity serving a specific Routing 126 Key. An example of an Application Server is a virtual switch element 127 handling all call processing for a unique range of PSTN trunks, 128 identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual 129 database element, handling all HLR transactions for a particular SS7 130 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more 131 unique Application Server Processes, of which one or more is normally 132 actively processing traffic. 134 Application Server Process (ASP) - A process instance of an Application 135 Server. An Application Server Process serves as an active or standby 136 process of an Application Server (e.g., part of a distributed virtual 137 switch or database). Examples of ASPs are processes (or process 138 instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- 139 point and may be configured to process signalling traffic within more 140 than one Application Server. 142 Association - An association refers to an SCTP association. The 143 association provides the transport for the delivery of MTP3-User 144 protocol data units and M3UA adaptation layer peer messages. 146 IP Server Process (IPSP) - A process instance of an IP-based 147 application. An IPSP is essentially the same as an ASP, except that it 148 uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not 149 use the services of a Signalling Gateway. 151 Signalling Gateway Process (SGP) - A process instance of a Signalling 152 Gateway. It serves as an active, standby or load-sharing process of a 153 Signalling Gateway. 155 Signalling Process - A process instance that uses M3UA to communicate 156 with other signalling process. An ASP, a signalling gateway process 157 and an IPSP are all signalling processes. 159 Routing Key: A Routing Key describes a set of SS7 parameters and 160 parameter values that uniquely define the range of signalling traffic 161 to be handled by a particular Application Server. Parameters within the 162 Routing Key cannot extend across more than a single SS7 Destination 163 Point Code. 165 Routing Context - A value that uniquely identifies a Routing Key. 166 Routing Context values are either configured using a configuration 167 management interface, or by using the routing key management procedures 168 defined in this document. 170 Fail-over - The capability to re-route signalling traffic as required 171 to an alternate Application Server Process, or group of ASPs, within an 172 Application Server in the event of failure or unavailability of a 173 currently used Application Server Process. Fail-over also applies upon 174 the return to service of a previously unavailable Application Server 175 Process. 177 Signalling Point Management Cluster (SPMC) - The complete set of 178 Application Servers represented to the SS7 network under one specific 179 SS7 Point Code of one specific Network Appearance. SPMCs are used to 180 sum the availability / congestion / User_Part status of an SS7 181 destination point code that is distributed in the IP domain, for the 182 purpose of supporting MTP3 management procedures at an SG. In some 183 cases, the SG itself may also be a member of the SPMC. In this case, 184 the SG availability / congestion / User_Part status must also be taken 185 into account when considering any supporting MTP3 management actions. 187 MTP - The Message Transfer Part of the SS7 protocol. 189 MTP3 - MTP Level 3, the signalling network layer of SS7 191 MTP3-User - Any protocol normally using the services of the SS7 MTP3 192 (e.g., ISUP, SCCP, TUP, etc.). 194 Network Appearance - The Network Appearance identifies an SS7 network 195 context for the purposes of logically separating the signalling traffic 196 between the SG and the Application Server Processes over a common SCTP 197 Association. An example is where an SG is logically partitioned to 198 appear as an element in four separate national SS7 networks. A Network 199 Appearance implicitly defines the SS7 Point Code(s), Network Indicator 200 and MTP3 protocol type/variant/version used within a specific SS7 201 network partition. A physical SS7 route-set or link-set at an SG can 202 appear in only one network appearance. The Network Appearance is not 203 globally significant and requires coordination only between the SG and 204 the ASP. Therefore, in the case where an ASP is connected to more than 205 one SG, the same SS7 network context may be identified by different 206 Network Appearances depending over which SG a message is being 207 transmitted/received. 209 Network Byte Order: Most significant byte first, a.k.a Big Endian. 211 Layer Management - Layer Management is a nodal function that handles 212 the inputs and outputs between the M3UA layer and a local management 213 entity. 215 Host - The computing platform that the ASP process is running on. 217 Stream - A stream refers to an SCTP stream; a uni-directional logical 218 channel established from one SCTP endpoint to another associated SCTP 219 endpoint, within which all user messages are delivered in-sequence 220 except for those submitted to the un-ordered delivery service. 222 1.3 M3UA Overview 224 1.3.1 Protocol Architecture. 226 The framework architecture that has been defined for SCN signalling 227 transport over IP [1] uses multiple components, including a common 228 signalling transport protocol and an adaptation module to support the 229 services expected by a particular SCN signalling protocol from its 230 underlying protocol layer. 232 Within the framework architecture, this document defines an MTP3-User 233 adaptation module suitable for supporting the transfer of messages of 234 any protocol layer that is identified to the MTP Level 3 layer, in SS7 235 terms, as a user part. The list of these protocol layers include, but 236 is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection 237 Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP 238 [9,10,11] or RANAP [12] messages are transferred transparently by the 239 M3UA as SCCP payload, as they are SCCP-User protocols. 241 It is recommended that the M3UA use the services of the Stream Control 242 Transmission Protocol (SCTP) [13] as the underlying reliable common 243 signalling transport protocol. This is to take advantage of various 244 SCTP features such as: 246 - Explicit packet-oriented delivery (not stream-oriented); 247 - Sequenced delivery of user messages within multiple streams, 248 with an option for order-of-arrival delivery of individual 249 user messages, 250 - Optional multiplexing of user messages into SCTP datagrams; 251 - Network-level fault tolerance through support of multi-homing 252 at either or both ends of an association; 253 - Resistance to flooding and masquerade attacks; and 254 - Data segmentation to conform to discovered path MTU size. 256 Under certain scenarios, such as back-to-back connections without 257 redundancy requirements, the SCTP functions above MAY NOT be a 258 requirement and TCP can be used as the underlying common transport 259 protocol. 261 1.3.2 Services Provided by the M3UA Layer 263 The M3UA Layer at an ASP or IPSP provides the equivalent set of 264 primitives at its upper layer to the MTP3-Users as provided by the MTP 265 Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP 266 and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 267 services are offered remotely from an MTP3 Layer at an SG, and not by a 268 local MTP3 layer. The MTP3 layer at an SG may also be unaware that its 269 local users are actually remote user parts over M3UA. In effect, the 270 M3UA extends access to the MTP3 layer services to a remote IP-based 271 application. The M3UA does not itself provide the MTP3 services. 272 However, in the case where an ASP is connected to more than one SG, the 273 M3UA Layer at an ASP must maintain the status of configured SS7 274 destinations and route messages according to the availability / 275 congestion status of the routes to these destinations via each SG. 277 The M3UA Layer may also be used for point-to-point signalling between 278 two IP Server Processes (IPSPs). In this case, the M3UA provides the 279 same set of primitives and services at its upper layer as the MTP3. 280 However, in this case the expected MTP3 services are not offered 281 remotely from an SG. The MTP3 services are provided but the procedures 282 to support these services are a subset of the MTP3 procedures due to 283 the simplified point-to-point nature of the IPSP to IPSP relationship. 285 1.3.2.1 Support for the transport of MTP3-User Messages 287 The M3UA provides the transport of MTP-TRANSFER primitives across an 288 established SCTP association between an SG and an ASP or between IPSPs. 290 The MTP-TRANSFER primitive information is encoded as in MTP3-User 291 messages. In this way, the SCCP and ISUP messages received from the 292 SS7 network by the SG are not re-encoded into a different format for 293 transport between the M3UA peers. The MTP3 Service Information Octet 294 (SIO) and Routing Label (OPC, DPC, and SLS) are included, encoded as 295 expected by the MTP3 and MTP3-User protocol layer. 297 At an ASP, in the case where a destination is reachable via multiple 298 SGs, the M3UA must also choose via which SG the message is to be routed 299 or support load balancing across the SGs, ensuring that no mis- 300 sequencing occurs. 302 The M3UA does not impose a 272-octet signaling information field (SIF) 303 length limit as specified by the SS7 MTP Level 2 protocol [14] [15] 304 [16]. Larger information blocks can be accommodated directly by 305 M3UA/SCTP, without the need for an upper layer segmentation/re-assembly 306 procedure as specified in recent SCCP or ISUP versions. However, in 307 the context of an SG, the maximum 272-octet block size must be followed 308 when inter-working to a SS7 network that does not support the transfer 309 of larger information blocks to the final destination. This avoids 310 potential ISUP or SCCP fragmentation requirements at the SG. However, 311 if the SS7 network is provisioned to support the Broadband MTP [20] to 312 the final SS7 destination, the information block size limit may be 313 increased past 272 octets. 315 1.3.2.2 Native Management Functions 317 The M3UA provides management of the underlying SCTP transport protocol 318 to ensure that SG-ASP and IPSP-IPSP transport is available to the 319 degree called for by the MTP3-User signalling applications. 321 The M3UA provides the capability to indicate errors associated with 322 received M3UA messages and to notify, as appropriate, local management 323 and/or the peer M3UA. 325 1.3.2.3 Inter-working with MTP3 Network Management Functions 327 At the SG, the M3UA must also provide inter-working with MTP3 328 management functions to support seamless operation of the user SCN 329 signalling applications in the SS7 and IP domains. This includes: 331 - Providing an indication to MTP3-Users at an ASP that a remote 332 destination in the SS7 network is not reachable. 334 - Providing an indication to MTP3-Users at an ASP that a remote 335 destination in the SS7 network is now reachable. 337 - Providing an indication to MTP3-Users at an ASP that messages to a 338 remote MTP3-User peer in the SS7 network are experiencing SS7 339 congestion. 341 - Providing an indication to MTP3-Users at an ASP that the routes to 342 a remote MTP3-User peer in the SS7 network are restricted. 344 - Providing an indication to MTP3-Users at an ASP that a remote MTP3- 345 User peer is unavailable. 347 The M3UA layer at an ASP may initiate an audit of the availability, the 348 restricted or the congested state of remote SS7 destinations. This 349 information is requested from the M3UA at the SG. 351 The M3UA layer at an ASP may also indicate to the SG that the M3UA 352 itself or the ASP or the ASP's Host is congested. 354 1.3.2.4 Support for the management of SCTP associations between the SG 355 and ASPs. 357 The M3UA layer at the SG maintains the availability state of all 358 configured remote ASPs, in order to manage the SCTP Associations and 359 the traffic between the M3UA peers. As well, the active/inactive and 360 congestion state of remote ASPs is maintained. 362 The M3UA layer MAY be instructed by local management to establish an 363 SCTP association to a peer M3UA node. This can be achieved using the 364 M-SCTP ESTABLISH primitive to request, indicate and confirm the 365 establishment of an SCTP association with a peer M3UA node. In order 366 to avoid redundant SCTP associations between two M3UA peers, one side 367 (client) must be designated to establish the SCTP association, or M3UA 368 configuration knowledge maintained to detect redundant associations 369 (e.g., via knowledge of the expected local and remote SCTP endpoint 370 addresses). 372 The M3UA layer MAY also need to inform local management of the status 373 of the underlying SCTP associations using the M-SCTP STATUS request and 374 indication primitive. For example, the M3UA MAY inform local management 375 of the reason for the release of an SCTP association, determined either 376 locally within the M3UA layer or by a primitive from the SCTP. 378 Also the M3UA layer may need to inform the local management of the 379 change in status of an ASP or AS. This may be achieved using the M-ASP 380 STATUS request or M-AS STATUS request primitives. 382 1.3.2.5 Support for the management of connections to multiple SGs 384 As shown in Figure 1 an ASP may be connected to multiple SGs. In such a 385 case a particular SS7 destination may be reachable via more than SG, 386 i.e., via more than one route. As MTP3 users only maintain status on a 387 destination and not on a route basis, M3UA must maintain the status 388 (availability, restriction, and/or congestion of route to destination) 389 of the individual routes, derive the overall availability or congestion 390 status of the destination from the status of the individual routes, and 391 inform the MTP3 users of this derived status whenever it changes. 393 1.3.3 Signalling Network Architecture 395 A Signalling Gateway is used to support the transport of MTP3-User 396 signalling traffic received from the SS7 network to multiple 397 distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA 398 protocol is not designed to meet the performance and reliability 399 requirements for such transport by itself. However, the conjunction of 400 distributed architecture and redundant networks does allow for a 401 sufficiently reliable transport of signalling traffic over IP. The 402 M3UA protocol is flexible enough to allow its operation and management 403 in a variety of physical configurations, enabling Network Operators to 404 meet their performance and reliability requirements. 406 To meet the stringent SS7 signalling reliability and performance 407 requirements for carrier grade networks, Network Operators SHOULD 408 ensure that no single point of failure is present in the end-to-end 409 network architecture between an SS7 node and an IP-based application. 410 This can typically be achieved through the use of redundant SGs, 411 redundant hosts, and the provision of redundant QOS-bounded IP network 412 paths for SCTP Associations between SCTP End Points. Obviously, the 413 reliability of the SG, the MGC and other IP-based functional elements 414 also needs to be taken into account. The distribution of ASPs within 415 the available Hosts must also be considered. As an example, for a 416 particular Application Server, the related ASPs should be distributed 417 over at least two Hosts. 419 One example of a physical network architecture relevant to SS7 carrier- 420 grade operation in the IP network domain is shown in Figure 1 below: 422 SG MGC 424 Host#1 ************** ************** Host#1 425 = * ********__*__________________________*__******** * = 426 SG1 * * SGP1 *__*_____ _______________*__* ASP1 * * MGC1 427 * ******** * \ / * ******** * 428 * ********__*______\__/________________*__******** * 429 * * SGP2 *__*_______\/______ _____*__* ASP2 * * 430 * ******** * /\ | | * ******** * 431 * : * / \ | | * : * 432 * ******** * / \ | | * ******** * 433 * * SGPn * * | | | | * * ASPn * * 434 * ******** * | | | | * ******** * 435 ************** | | | | ************** 436 | | \ / 437 Host#2 ************** | | \ / ************** Host#2 438 = * ********__*_____| |______\/_______*__******** * = 439 SG2 * * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2 440 * ******** * / \ * ******** * 441 * ********__*_______________/ \_____*__******** * 442 * * SGP2 *__*__________________________*__* ASP2 * * 443 * ******** * * ******** * 444 * : * SCTP Associations * : * 445 * ******** * * ******** * 446 * * SGPn * * * * ASPn * * 447 * ******** * * ******** * 448 ************** ************** 450 Figure 1 - Physical Model 452 In this model, each host has many application processes. In the case 453 of the MGC, an ASP may provide service to one or more application 454 server, and is identified as an SCTP end point. In the case of the SG, 455 a pair of signalling gateway processes may represent, as an example, a 456 single network appearance, serving a signalling point management 457 cluster. 459 This example model can also be applied to IPSP-IPSP signalling. In 460 this case, each IPSP would have its services distributed across 2 hosts 461 or more, and may have multiple server processes on each host. 463 In the example above, each signalling process (SGP, ASP or IPSP) is the 464 end point to more than one SCTP association, leading to many other 465 signalling processes. To support this, a signalling process must be 466 able to support distribution of M3UA messages to many simultaneous 467 active associations. This message distribution function is based on 468 the status of provisioned routing keys, the availability of signalling 469 points in the SS7 network, and the redundancy model (active-standby, 470 load-sharing, n+k) of the remote signalling processes. 472 For carrier grade networks, the failure or isolation of a particular 473 signalling process SHOULD NOT cause stable calls or transactions to be 474 lost. This implies that signalling processes need, in some cases, to 475 share the call/transaction state or be able to pass the call state 476 information between each other. In the case of ASPs performing call 477 processing, coordination may also be required with the related Media 478 Gateway to transfer the MGC control for a particular trunk termination. 479 However, this sharing or communication of call/transaction state 480 information is outside the scope of this document. 482 This model serves as an example. M3UA imposes no restrictions as to 483 the exact layout of the network elements, the message distribution 484 algorithms and the distribution of the signalling processes. Instead, 485 it provides a framework and a set of messages that allow for a flexible 486 and scalable signalling network architecture, aiming to provide 487 reliability and performance. 489 1.4 Functional Areas 491 1.4.1 Signalling Point Code Representation 493 Within an SS7 network, a Signalling Gateway is charged with 494 representing a set of nodes in the IP domain into the SS7 network for 495 routing purposes. The SG itself, as a physical node in the SS7 496 network, must be addressable with an SS7 Point Code for MTP3 Management 497 purposes. The SG Point Code is also used for addressing any local MTP3- 498 Users at the SG such as an SG-resident SCCP function. 500 An SG may be logically partitioned to operate in multiple SS7 network 501 Appearances. In such a case, the SG must be addressable with a Point 502 Code in each network appearance, and represents a set of nodes in the 503 IP domain into each SS7 network. Alias Point Codes [15] may also be 504 used within an SG network appearance. 506 The M3UA places no restrictions on the SS7 Point Code representation of 507 an AS. Application Servers can be represented under the same Point 508 Code of the SG, their own individual Point Codes or grouped with other 509 Application Servers for Point Code preservation purposes. A single 510 Point Code may be used to represent the SG and all the Application 511 Servers together, if desired. 513 Where Application Servers are grouped under a Point Code address, an 514 SPMC will include more than one AS. If full advantage of SS7 management 515 procedures is to be taken (as is advisable in carrier grade networks) 516 care must be taken that, if one AS of an SPMC becomes unavailable, all 517 Application Servers of the SPMC become unavailable from the SG. 518 Otherwise, usage of SS7 transfer prohibited procedures by the SG 519 becomes problematic as either traffic to the unavailable AS cannot be 520 stopped/diverted or traffic to a still available AS will be 521 unnecessarily stopped/diverted. (Depending on the network configuration 522 it may even be necessary to assign an individual SS7 point code to each 523 AS.) 525 Observing this principle is of particular importance if alternative 526 routing possibilities exist on the SS7 level (e.g. via mated SGs) or 527 application level (e.g. via another MGC/MG). 529 If an ASP or group of ASPs is available to the SS7 network via more 530 than one SG, each with its own Point Code, the ASP(s) should be 531 represented by a Point Code that is separate from any SG Point Code. 532 This allows these SGs to be viewed from the SS7 network as "STPs", each 533 having an ongoing "route" to the same ASP(s). Under failure 534 conditions where the ASP(s) become(s) unavailable from one of the SGs, 535 this approach enables MTP3 route management messaging between the SG 536 and SS7 network, allowing simple SS7 re-routing through an alternate SG 537 without changing the Destination Point Code Address of SS7 traffic to 538 the ASP(s). 540 Where an AS can be reached via more than one SG it is equally important 541 that the corresponding Routing Keys in the involved SGs are identical. 542 (Note: It is possible for the Routing Key configuration data to be 543 temporarily out-of-synch during configuration updates). 545 +--------+ 546 | | 547 +------------+ SG 1 +--------------+ 548 +-------+ | SS7 links | "STP" | IP network | ---- 549 | SEP +---+ +--------+ +---/ \ 550 | or | | ASPs | 551 | STP +---+ +--------+ +---\ / 552 +-------+ | | | | ---- 553 +------------+ SG 2 +--------------+ 554 | "STP" | 555 +--------+ 557 Note: there is no SG-to-SG communication shown, so each SG can be 558 reached only via the direct linkset from the SS7 network. 560 The following example shows a signalling gateway partitioned into two 561 network appearances. 563 SG 564 +-------+ +---------------+ 565 | SEP +--------------| SS7 Ntwk |M3UA| ---- 566 +-------+ SS7 links | "A" | | / \ 567 |__________| +-----------+ ASPs | 568 | | | \ / 569 +-------+ | SS7 Ntwk | | ---- 570 | SEP +--------------+ "B" | | 571 +-------+ +---------------+ 573 1.4.2 Routing Contexts and Routing Keys 575 1.4.2.1 Overview 577 The distribution of SS7 messages between the SG and the Application 578 Servers is determined by the Routing Keys and their associated Routing 579 Contexts. A Routing Key is essentially a set of SS7 parameters used to 580 filter SS7 messages, whereas the Routing Context parameter is a 4-byte 581 value (integer) that is associated to that Routing Key in a 1:1 582 relationship. The Routing Context therefore can be viewed as an index 583 into a sending node's Message Distribution Table containing the Routing 584 Key entries. 586 Possible SS7 address/routing information that comprise a Routing Key 587 entry includes, for example, the OPC, DPC, SIO found in the MTP3 588 routing label, or other MTP3-User specific fields such as the ISUP CIC, 589 SCCP subsystem number, or TCAP transaction ID. Some example Routing 590 Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC 591 combination, or the DPC/SSN combination. The particular information 592 used to define an M3UA Routing Key is application and network 593 dependent, and none of the above examples are mandated. 595 An Application Server Process may be configured to process signalling 596 traffic related to more than one Application Server, over a single SCTP 597 Association. In ASP Active and Inactive management messages, the 598 signalling traffic to be started or stopped is discriminated by the 599 Routing Context parameter. At an ASP, the Routing Context parameter 600 uniquely identifies the range of signalling traffic associated with 601 each Application Server that the ASP is 602 configured to receive. 604 1.4.2.2 Routing Key Limitiations 606 >From an SS7 network perspective, a Routing Key is limited to within a 607 single SS7 Destination Point Code. This is important, as the SG must be 608 able to present this point code to the SS7 network, without 609 compromising the integrity of the Signaling Point Management Cluster. 611 Some SS7 networks may require the SG to generate UPU messages in 612 failure conditions. In this case, the AS and SG may optionally limit a 613 Routing Key to a single Service Indicator (ISUP, TUP, SCCP, etc.). The 614 SG generation of a UPU message into the SS7 network is implementation 615 dependent, therefore no specific procedures are outlined in this 616 document. 618 Routing Keys MUST be unique in the sense that a received SS7 signalling 619 message cannot be matched to more than one Routing Key. It is not 620 necessary for the parameter range values within a particular Routing 621 Key to be contiguous. For example, an AS could be configured to 622 support call processing for multiple ranges of PSTN trunks that are not 623 represented by contiguous CIC values. 625 1.4.2.3 Managing Routing Contexts and Routing Keys 627 There are two ways to ways to provision a Routing Key at an SG. A 628 Routing Key may be configured using an implementation dependent 629 management interface, statically or dynamically in full accordance to 630 the M3UA specifications. A Routing Key may also be configured using the 631 M3UA dynamic registration/deregistration procedures defined in this 632 document. An M3UA element must implement at least one method of 633 Routing Key provisioning. 635 When using a management interface to configure Routing Keys, the 636 message distribution function within the SG is not limited to the set 637 of parameters defined in this document. Other implementation dependent 638 distribution algorithms may be used. 640 1.4.2.4 Message Distribution the SG 642 In order to direct messages received from the SS7 MTP3 network to the 643 appropriate IP destination, the SG must perform a message distribution 644 function using information from the received MTP3-User message. 646 To support this message distribution, the SG must maintain the 647 equivalent of a network address translation table, mapping incoming SS7 648 message information to an Application Server for a particular 649 application and range of traffic. This is accomplished by comparing 650 elements of the incoming SS7 message to provisioned Routing Keys in the 651 SG. These Routing Keys in turn make reference to an Application Server 652 that is enabled by one or more ASPs. These ASPs provide dynamic status 653 information on their availability, traffic handling capability and 654 congestion to the SG using various management messages defined in the 655 M3UA protocol. 657 The list of ASPs in an AS is assumed to be dynamic, taking into account 658 the availability, traffic handling capability and congestion status of 659 the individual ASPs in the list, as well as configuration changes and 660 possible fail-over mechanisms. 662 Normally, one or more ASPs are active in the AS (i.e., currently 663 processing traffic) but in certain failure and transition cases it is 664 possible that there may be active ASP available. Both load-sharing and 665 backup scenarios are supported. 667 When there is no Routing Key match, or only a partial match, for an 668 incoming SS7 message, a default treatment MUST be specified. Possible 669 solutions are to provide a default Application Server at the SG that 670 directs all unallocated traffic to a (set of) default ASP(s), or to 671 drop the message and provide a notification to management. The 672 treatment of unallocated traffic is implementation dependent. 674 1.4.2.5 Message Distribution at the ASP 676 In order to direct messages to the SS7 network, the ASP must also 677 perform a message distribution function in order to choose the proper 678 SG or SGP for a given message. This is accomplished by observing the 679 Destination Point Code (and possibly other elements of the outgoing 680 message such as the SLS value), together with the SS7 destination 681 availability/restricted/congestion status via the SG(s) and the 682 availability of the SG and SGPs themselves. 684 A remote Signalling Gateway may be composed of one or more SGPs that 685 are capable of routing SS7 traffic. As is the case with ASPs, a 686 dynamic list of SGPs in an SG can be maintained, taking into account 687 the availability status of the individual SGPs, configuration changes 688 and fail-over mechanisms. There is, however, no M3UA messaging to 689 manage the status of an SGP. Whenever an SCTP association to an SGP 690 exists, it is assumed to be available. Also, every SGP of one SG 691 communicating with one ASP regarding one AS provides identical SS7 692 connectivity to this ASP. 694 1.4.3 SS7 and M3UA Interworking 696 In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is 697 designed to provide an extension of the MTP3 defined user primitives. 699 1.4.3.1 Signalling Gateway SS7 Layers 701 The SG is responsible for terminating MTP Level 3 of the SS7 protocol, 702 and offering an IP-based extension to its users. 704 >From an SS7 perspective, it is expected that the Signalling Gateway 705 (SG) transmits and receives SS7 Message Signalling Units (MSUs) to and 706 from the PSTN over a standard SS7 network interface, using the SS7 707 Message Transfer Part (MTP) [14,15,16] to provide reliable transport of 708 the messages. 710 As a standard SS7 network interface, the use of MTP Level 2 signalling 711 links is not the only possibility. ATM-based High Speed Links can also 712 be used with the services of the Signalling ATM Adaptation Layer (SAAL) 713 [17,18]. It is possible for IP-based links to be present, using the 714 services of the MTP2-User Adaptation Layer (M2UA) [19]. These SS7 715 datalinks may be terminated at a Signalling Transfer Point (STP) or at 716 a Signalling End Point (SEP). Using the services of MTP3, the SG may 717 be capable of communicating with remote SS7 SEPs in a quasi-associated 718 fashion, where STPs may be present in the SS7 path between the SEP and 719 the SG. 721 Where ATM-based High Speed Links are used in the SS7 network, it is 722 possible for the SG to use the services of the MTP-3b [20] for reliable 723 transport to and from an SS7 SEP or STP. The maximum SIF length 724 supported by the MTP-3b is 4095 octets compared to the 272-octet 725 maximum of the MTP3. However, for MTP3-Users to take advantage of the 726 larger SDU between MTP3-User peers, network architects should ensure 727 that MTP3-b is used end-to-end between the SG and the SS7-resident 728 peer. 730 1.4.3.2 SS7 and M3UA Inter-Working at the SG 732 The SG provides a functional inter-working of transport functions 733 between the SS7 network and the IP network by also supporting the M3UA 734 adaptation layer. It allows the transfer of MTP3-User signalling 735 messages to and from an IP-based Application Server Process where the 736 peer MTP3-User protocol layer exists. 738 The Signalling Gateway must maintain knowledge of SS7 node and 739 Signalling Point Management Cluster (SPMC) status in their respective 740 domains in order to perform a seamless inter-working of the IP-based 741 signalling and the SS7 domains. For example, SG knowledge of the 742 availability and/or congestion status of the SPMC and SS7 nodes must be 743 maintained and disseminated in the respective networks, in order to 744 ensure that end-to-end operation is transparent to the communicating 745 SCN protocol peers at the SS7 node and ASP. 747 When the SG determines that the transport of SS7 messages to an SPMC 748 (or possibly to parts of an SPMC) is encountering congestion, the SG 749 should inform the MTP3 route management function (by an implementation- 750 dependent mechanism). This information is used by the MTP3 to mark the 751 "route" to the affected destination as congested and to trigger MTP 752 Transfer Controlled (TFC) messages to any SS7 SEPs generating traffic 753 to the congested DPC, as per current MTP3 procedures. 755 When the SG determines that the transport of SS7 messages to all ASPs 756 in a particular SPMC is interrupted, then it should similarly inform 757 the MTP3 route management function. This information is used by the 758 MTP3 to mark the "route" to the affected destination as unavailable, 759 and in the case of the SG acting as a signalling transfer point (i.e., 760 the Point Code of the SG is different from that of the SPMC), to send 761 MTP Transfer Prohibited (TFP) messages to the relevant adjacent SS7 762 nodes, according to the local SS7 network procedures. 764 When the SG determines that the transport of SS7 messages to an ASP in 765 a particular SPMC can be resumed, the SG should similarly inform the 766 MTP3 route management function. This information is used by the MTP3 767 to mark the route to the affected destination as available, and in the 768 case of a signalling transfer point, to send MTP Transfer Allowed (TFA) 769 messages to the relevant adjacent SS7 nodes, according to the local SS7 770 network procedures. 772 For SS7 user part management, it is required that the MTP3-User 773 protocols at ASPs receive indications of SS7 signalling point 774 availability, SS7 network congestion, and remote User Part 775 unavailability as would be expected in an SS7 SEP node. To accomplish 776 this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives 777 received at the MTP3 upper layer interface at the SG need to be 778 propagated to the remote MTP3-User lower layer interface at the ASP. 779 (These indication primitives are, of course, also made available to any 780 existing local MTP3-Users at the SG, if present.) 782 It is important to clarify that MTP3 management messages such as TFPs 783 or TFAs received from the SS7 network are not "encapsulated" and sent 784 blindly to the ASPs. Rather, the existing MTP3 management procedures 785 are followed within the MTP3 function of the SG to re-calculate the 786 MTP3 route set status and to initiate any required signalling-route- 787 set-test procedures into the SS7 network. Only when an SS7 destination 788 status changes are MTP-PAUSE or MTP-RESUME primitives invoked. These 789 primitives can also be invoked due to local SS7 link set conditions as 790 per existing MTP3 procedures. 792 In the case where the MTP in the SG undergoes an MTP restart, event 793 communication to the concerned ASPs should be handled as follows: 795 When the SG discovers SS7 network isolation, the SG sends an indication 796 to all concerned available ASPs (i.e., ASPs in the "active" or 797 "inactive" state), using a DUNA message. For the purposes of MTP 798 Restart, all SPMCs with point codes different from that of the SG with 799 at least one ASP that is active or that has sent an ASPAC message to 800 the SG during the first part of the restart procedure should be 801 considered as available. If the M3UA at the SG receives any ASPAC 802 messages during the restart procedure, it delays the ASPAC-ACK messages 803 until the end of the restart procedure. During the second part of the 804 restart procedure the M3UA at the SG informs all concerned ASPs in the 805 "active" or "inactive" state of any unavailable SS7 destinations. At 806 the end of the restart procedure the M3UA sends an ASPAC-ACK message to 807 all ASPs in the "active" state. 809 1.4.3.3 Application Server 811 A cluster of application servers is responsible for providing the 812 overall support for one or more SS7 upper layers. From an SS7 813 standpoint, a Signalling Point Management Cluster (SPMC) provides 814 complete support for the upper layer service for a given point code. 815 As an example, an SPMC providing MGC capabilities must provide complete 816 support for ISUP (and any other MTP3 user located at the point code of 817 the SPMC) for a given point code, according to the local SS7 network 818 specifications. 820 This measure is necessary to allow the SG to accurately represent the 821 signalling point on the local SS7 network. 823 In the case where an ASP is connected to more than one SG, the M3UA 824 must maintain the status of configured SS7 destinations and route 825 messages according to availability/congestion/restricted status of the 826 routes to these destinations. 828 When an ASP enters the "Inactive" state towards an SG the M3UA must 829 mark all SS7 destinations configured to be reachable via this SG as 830 available. 832 When the M3UA at an ASP receives a DUNA message indicating SS7 network 833 isolation at an SG, it will stop any affected traffic via this SG and 834 clear any unavailability state of SS7 destinations via this SG. When 835 the M3UA subsequently receives any DUNA messages from an SG it will 836 mark the effected SS7 destinations as unavailable via that SG. When 837 the M3UA receives an ASPAC-ACK message it can resume traffic to 838 available SS7 destinations via this SG, provided the ASP is in the 839 active state towards this SG. 841 1.4.3.3 IPSP Considerations 843 Since IPSPs use M3UA in a point-to-point fashion, there is no concept 844 of routing of messages beyond the remote end. Therefore, SS7 and M3UA 845 inter-working is not necessary for this model. 847 1.4.4 Redundancy Models 849 The network address translation and mapping function of the M3UA layer 850 supports signalling process fail-over functions in order to support a 851 high availability of call and transaction processing capability. 853 1.4.4.1 Application Server Redundancy 855 All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG from the 856 SS7 network are assigned to a unique Application Server, based on the 857 information in the message and the provisioned Routing Keys. 859 The Application Server is, in practical terms, a list of all ASPs 860 configured to process a range of MTP3-User traffic defined by one 861 Routing Key. One or more ASPs in the list are normally active (i.e., 862 handling traffic) while any others may be unavailable or inactive, to 863 be possibly used in the event of failure or unavailability of the 864 active ASP(s). 866 The fail-over model supports an "n+k" redundancy model, where "n" ASPs 867 is the minimum number of redundant ASPs required to handle traffic and 868 "k" ASPs are available to take over for a failed or unavailable ASP. A 869 "1+1" active/standby redundancy is a subset of this model. A simplex 870 "1+0" model is also supported as a subset, with no ASP redundancy. 872 At the SG, an Application Server list contains active and inactive ASPs 873 to support ASP load-sharing and fail-over procedures. The list of ASPs 874 within a logical Application Server is kept updated in the SG to 875 reflect the active Application Server Process(es). 877 To avoid a single point of failure, it is recommended that a minimum of 878 two ASPs be in the list, resident in separate hosts and therefore 879 available over different SCTP Associations. For example, in the 880 network shown in Figure 1, all messages to DPC x could be sent to ASP1 881 in Host1 or ASP1 in Host2. The AS list at SG1 might look like the 882 following: 884 Routing Key {DPC=x) - "Application Server #1" 885 ASP1/Host1 - State=Up, Active 886 ASP1/Host2 - State=Up, Inactive 888 In this "1+1" redundancy case, ASP1 in Host1 would be sent any incoming 889 message with DPC=x. ASP1 in Host2 would normally be brought to the 890 active state upon failure of, or loss of connectivity to, ASP1/Host1. 891 In this example, both ASPs are Up, meaning that the related SCTP 892 association and far-end M3UA peer is ready. 894 The AS List at SG1 might also be set up in load-share mode: 896 Routing Key {DPC=x) - "Application Server #1" 897 ASP1/Host1 - State = Up, Active 898 ASP1/Host2 - State = Up, Active 900 In this case, both the ASPs would be sent a portion of the traffic. 901 For example the two ASPs could together form a database, where incoming 902 queries may be sent to any active ASP. 904 Care must be exercised by a Network Operator in the selection of the 905 routing information to be used as the Routing Key for a particular AS. 906 For example, where Application Servers are defined using ranges of ISUP 907 CIC values, the Operator is implicitly splitting up control of the 908 related circuit groups. Some CIC value range assignments may interfere 909 with ISUP circuit group management procedures. 911 In the process of fail-over, it is recommended that in the case of ASPs 912 supporting call processing, stable calls do not fail. It is possible 913 that calls in "transition" MAY fail, although measures of communication 914 between the ASPs involved can be used to mitigate this. For example, 915 the two ASPs MAY share call state via shared memory, or MAY use an ASP 916 to ASP protocol to pass call state information. Any ASP-to-ASP 917 protocol is outside the scope of this document. 919 1.4.4.2 Signalling Gateway Redundancy 921 Signalling Gateways MAY also be distributed over multiple hosts. Much 922 like the AS model, SGs may be comprised of one or more SG Processes 923 (SGPs), distributed over one or more hosts, using an active/standby or 924 a load-sharing model. An SGP is viewed as a remote SCTP end-point from 925 an ASP perspective. There is, however, no M3UA protocol to manage the 926 status of an SGP. Whenever an SCTP association to an SGP exists, the 927 SGP is assumed to be available. Also, every SGP within an SG 928 communicating with an ASP provides identical SS7 connectivity to this 929 ASP. Should an SGP lose all or partial SS7 connectivity and other SGPs 930 exist, the SGP must terminate the SCTP associations to the concerned 931 ASPs. 933 It is therefore possible for an ASP to route signalling messages 934 destined to the SS7 network using more than one SGP. In this model, a 935 Signalling Gateway is deployed as a cluster of hosts acting as a single 936 SG. A primary/back-up redundancy model is possible, where the 937 unavailability of the SCTP association to a primary SGP could be used 938 to reroute affected traffic to an alternate SGP. A load-sharing model 939 is possible, where the signalling messages are load-shared between 940 multiple SGPs. 942 It may also be possible for an ASP to use more than one SG to access a 943 specific SS7 end point, in a model that resembles an SS7 STP mated 944 pair. Typically, SS7 STPs are deployed in mated pairs, with traffic 945 load-shared between them. Other models are also possible, subject to 946 the limitations of the local SS7 network provisioning guidelines. 948 >From the perspective of the M3UA at an ASP, a particular SG is capable 949 of transferring traffic to an SS7 destination if an SCTP association 950 with at least one SGP of the SG is established, the SGP has returned an 951 ASPAC Ack message acknowledging to the ASP M3UA that the ASP is 952 actively handling traffic for that destination, and the SG has not 953 indicated that the destination is inaccessible. When an ASP is 954 configured to use multiple SGs for transferring traffic to the SS7 955 network, the ASP must maintain knowledge of the current capability of 956 the SGs to handle traffic to destinations of interest. This 957 information is crucial to the overall reliability of the service, for 958 both active/standby and load-sharing model, in the event of failures, 959 recovery and maintenance activities. The ASP M3UA may also use this 960 information for congestion avoidance purposes. The distribution of the 961 MTP3-user messages over the SGs should be done in such a way to 962 minimize message mis-sequencing, as required by the SS7 User Parts. 964 1.4.5 Flow Control 965 Local Management at an ASP may wish to stop traffic across an SCTP 966 association in order to temporarily remove the association from service 967 or to perform testing and maintenance activity. The function could 968 optionally be used to control the start of traffic on to a newly 969 available SCTP association. 971 1.4.6 Congestion Management 973 The M3UA Layer is informed of local and IP network congestion by means 974 of an implementation-dependent function (e.g., an implementation- 975 dependent indication from the SCTP of IP network congestion). 977 At an ASP or IPSP, the M3UA indicates congestion to local MTP3-Users by 978 means of an MTP-Status primitive, as per current MTP3 procedures, to 979 invoke appropriate upper layer responses. 981 When an SG determines that the transport of SS7 messages to a 982 Signalling Point Management Cluster (SPMC) is encountering congestion, 983 the SG should trigger SS7 MTP3 Transfer Controlled management messages 984 to originating SS7 nodes, as per current MTP3 procedures. The 985 triggering of SS7 MTP3 Management messages from an SG is an 986 implementation-dependent function. 988 The M3UA at an ASP or IPSP should indicate local congestion to an M3UA 989 peer with an SCON message. When an SG M3UA receives an SCON message 990 from an ASP, and the SG determines that an SPMC is now encountering 991 congestion, it should trigger SS7 MTP3 Transfer Controlled management 992 messages to concerned SS7 destinations according to current MTP 993 procedures. 995 1.4.7 SCTP Stream Mapping. 997 The M3UA at both the SG and ASP also supports the assignment of 998 signalling traffic into streams within an SCTP association. Traffic 999 that requires sequencing must be assigned to the same stream. To 1000 accomplish this, MTP3-User traffic may be assigned to individual 1001 streams based on, for example, the SLS value in the MTP3 Routing Label 1002 or the ISUP CIC assignment, subject of course to the maximum number of 1003 streams supported by the underlying SCTP association. 1005 The use of SCTP streams within M3UA is recommended in order to minimize 1006 transmission and buffering delays, therefore improving the overall 1007 performance and reliability of the signalling elements. The 1008 distribution of the MTP3 user messages over the various streams should 1009 be done in such a way to minimize message mis-sequencing, as required 1010 by the SS7 User Parts. 1012 1.4.8 Client/Server Model 1014 The SG takes on the role of server while the ASP is the client. ASPs 1015 MUST initiate the SCTP association to the SG. 1017 In the case of IPSP to IPSP communication, the peer endpoints using 1018 M3UA SHOULD be configured so that one always takes on the role of 1019 client and the other the role of server for initiating SCTP 1020 associations and M3UA messaging. 1022 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M3UA 1023 is 2905. 1025 1.5 Sample Configurations 1027 1.5.1 Example 1: ISUP message transport 1029 ******** SS7 ***************** IP ******** 1030 * SEP *---------* SG *--------* ASP * 1031 ******** ***************** ******** 1033 +------+ +------+ 1034 | ISUP | (NIF) | ISUP | 1035 +------+ +------+-+------+ +------+ 1036 | MTP3 | | MTP3 | | M3UA | | M3UA | 1037 +------| +------+ +------+ +------+ 1038 | MTP2 | | MTP2 | | SCTP | | SCTP | 1039 +------+ +------+ +------+ +------+ 1040 | L1 | | L1 | | IP | | IP | 1041 +------+ +------+ +------+ +------+ 1042 |_______________| |______________| 1044 SEP - SS7 Signalling End Point 1045 SCTP - Stream Control Transmission Protocol 1046 NIF - Nodal Inter-working Function 1048 In this example, the SG provides an implementation-dependent nodal 1049 inter-working function (NIF) that allows the MGC to exchange SS7 1050 signalling messages with the SS7-based SEP. The NIF within the SG 1051 serves as the interface within the SG between the MTP3 and M3UA. This 1052 nodal inter-working function has no visible peer protocol with either 1053 the MGC or SEP. It also provides network status information to one or 1054 both sides of the network. 1056 For internal SG modeling purposes, at the NIF level, SS7 signalling 1057 messages that are destined to the MGC are received as MTP-TRANSFER 1058 indication primitives from the MTP Level 3 upper layer interface and 1059 are sent to the local M3UA-resident message distribution function for 1060 ongoing routing to the final IP destination. MTP-TRANSFER primitives 1061 received from the local M3UA network address translation and mapping 1062 function are sent to the MTP Level 3 upper layer interface as MTP- 1063 TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 1064 SEP. For the purposes of providing SS7 network status information the 1065 NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 1066 primitives received from the MTP Level 3 upper layer interface to the 1067 local M3UA-resident management function. In addition, as an 1068 implementation and network option, restricted destinations are 1069 communicated from MTP network management to the local M3UA-resident 1070 management function. 1072 1.5.2 Example 2: SCCP Transport between IPSPs 1074 ******** IP ******** 1075 * IPSP * * IPSP * 1076 ******** ******** 1078 +------+ +------+ 1079 |SCCP- | |SCCP- | 1080 | User | | User | 1081 +------+ +------+ 1082 | SCCP | | SCCP | 1083 +------+ +------+ 1084 | M3UA | | M3UA | 1085 +------+ +------+ 1086 | SCTP | | SCTP | 1087 +------+ +------+ 1088 | IP | | IP | 1089 +------+ +------+ 1090 |________________| 1092 This example shows an architecture where no Signalling Gateway is used. 1093 In this example, SCCP messages are exchanged directly between two IP- 1094 resident IPSPs with resident SCCP-User protocol instances, such as 1095 RANAP or TCAP. SS7 network inter-working is not required, therefore 1096 there is no MTP3 network management status information for the SCCP and 1097 SCCP-User protocols to consider. Any MTP-PAUSE, -RESUME or -STATUS 1098 indications from the M3UA to the SCCP should consider the status of the 1099 SCTP Association and underlying IP network and any congestion 1100 information received from the remote site. 1102 1.5.3 Example 3: SG resident SCCP layer, with remote ASP 1104 ******** SS7 ***************** IP ******** 1105 * SEP *---------* *--------* * 1106 * or * * SG * * ASP * 1107 * STP * * * * * 1108 ******** ***************** ******** 1110 +------+ +---------------+ +------+ 1111 | SCCP-| | SCCP | | SCCP-| 1112 | User | +---------------+ | User | 1113 +------+ | _____ | +------+ 1114 | SCCP | | | | | | SCCP | 1115 +------+ +------+-+------+ +------+ 1116 | MTP3 | | MTP3 | | M3UA | | M3UA | 1117 +------| +------+ +------+ +------+ 1118 | MTP2 | | MTP2 | | SCTP | | SCTP | 1119 +------+ +------+ +------+ +------+ 1120 | L1 | | L1 | | IP | | IP | 1121 +------+ +------+ +------+ +------+ 1122 |_______________| |______________| 1124 STP - SS7 Signalling Transfer Point 1126 In this example, the SG contains an instance of the SS7 SCCP protocol 1127 layer that may, for example, perform the SCCP Global Title Translation 1128 (GTT) function for messages logically addressed to the SG SCCP. If the 1129 result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN 1130 address an SCCP peer located in the IP domain, the resulting MTP- 1131 TRANSFER request primitive is sent to the local M3UA-resident network 1132 address translation and mapping function for ongoing routing to the 1133 final IP destination. 1135 Similarly, the SCCP instance in an SG can perform the SCCP GTT service 1136 for messages logically addressed to it from SCCP peers in the IP 1137 domain. In this case, MTP-TRANSFER messages are sent from the local 1138 M3UA-resident network address translation and mapping function to the 1139 SCCP for GTT. If the result of the GTT yields the address of an SCCP 1140 peer in the SS7 network then the resulting MTP-TRANSFER request is 1141 given to the MTP3 for delivery to an SS7-resident node. 1143 It is possible that the above SCCP GTT at the SG could yield the 1144 address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER 1145 primitive would be sent back to the M3UA for delivery to an IP 1146 destination. 1148 For internal SG modeling purposes, this may be accomplished with the 1149 use of an implementation-dependent nodal inter-working function within 1150 the SG that effectively sits below the SCCP and routes MTP-TRANSFER 1151 messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or 1152 DPC/SSN 1153 address information. This nodal inter-working function has no visible 1154 peer protocol with either the ASP or SEP. 1156 Note that the services and interface provided by the M3UA are the same 1157 as in Example 1 and the functions taking place in the SCCP entity are 1158 transparent to M3UA. The SCCP protocol functions are not reproduced in 1159 the M3UA protocol. 1161 1.6 Definition of M3UA Boundaries 1163 1.6.1 Definition of the boundary between M3UA and an MTP3-User. 1165 >From ITU Q.701 [14]: 1167 MTP-TRANSFER request 1168 MTP-TRANSFER indication 1169 MTP-PAUSE indication 1170 MTP-RESUME indication 1171 MTP-STATUS indication 1173 1.6.2 Definition of the boundary between M3UA and SCTP 1175 An example of the upper layer primitives provided by the SCTP are 1176 provided in Reference [13] Section 10. 1178 1.6.3 Definition of the Boundary between M3UA and Layer Management 1180 M-SCTP ESTABLISH request 1181 Direction: LM -> M3UA 1182 Purpose: LM requests ASP to establish an SCTP association with an 1183 SG. 1185 M-STCP ESTABLISH confirm 1186 Direction: M3UA -> LM 1187 Purpose: ASP confirms to LM that it has established an SCTP 1188 association with an SG. 1190 M-SCTP ESTABLISH indication 1191 Direction: M3UA -> LM 1192 Purpose: M3UA informs LM that a remote ASP has established an SCTP 1193 association. 1195 M-SCTP RELEASE request 1196 Direction: LM -> M3UA 1197 Purpose: LM requests ASP to release an SCTP association with SG. 1199 M-SCTP RELEASE confirm 1200 Direction: M3UA -> LM 1201 Purpose: ASP confirms to LM that it has released SCTP association 1202 with SG. 1204 M-SCTP RELEASE indication 1205 Direction: M3UA -> LM 1206 Purpose: M3UA informs LM that a remote ASP has released an SCTP 1207 Association or the SCTP association has failed. 1209 M-SCTP STATUS request 1210 Direction: LM -> M3UA 1211 Purpose: LM requests M3UA to report the status of an SCTP 1212 association. 1214 M-SCTP STATUS confirm 1215 Direction: M3UA -> LM 1216 Purpose: M3UA reports the status of an SCTP association. 1218 M-ASP STATUS request 1219 Direction: LM -> M3UA 1220 Purpose: LM requests M3UA to report the status of a local or remote 1221 ASP. 1223 M-ASP STATUS confirm 1224 Direction: M3UA -> LM 1225 Purpose: M3UA reports status of local or remote ASP. 1227 M-AS STATUS request 1228 Direction: LM -> M3UA 1229 Purpose: LM requests M3UA to report the status of an AS. 1231 M-AS STATUS confirm 1232 Direction: M3UA -> LM 1233 Purpose: M3UA reports the status of an AS. 1235 M-NOTIFY indication 1236 Direction: M3UA -> LM 1237 Purpose: M3UA reports that it has received a NOTIFY message 1238 from its peer. 1240 M-ERROR indication 1241 Direction: M3UA -> LM 1242 Purpose: M3UA reports that it has received an ERROR message from 1243 its peer or that a local operation has been unsuccessful. 1245 M-ASP UP request 1246 Direction: LM -> M3UA 1247 Purpose: LM requests ASP to start its operation and send an ASP-UP 1248 Message to its peer. 1250 M-ASP UP confirm 1251 Direction: M3UA -> LM 1252 Purpose: ASP reports that is has received an ASP UP Acknowledgement 1253 message from the SG. 1255 M-ASP UP indication 1256 Direction: M3UA -> LM 1257 Purpose: M3UA reports it has successfully processed an incoming ASP- 1258 UP request from its peer. 1260 M-ASP DOWN request 1261 Direction: LM -> M3UA 1262 Purpose: LM requests ASP to stop its operation and send an ASP-DOWN 1263 Message to its peer. 1265 M-ASP DOWN confirm 1266 Direction: M3UA -> LM 1267 Purpose: ASP reports that is has received an ASP DOWN 1268 Acknowledgement message from the SG. 1270 M-ASP DOWN indication 1271 Direction: M3UA -> LM 1272 Purpose: M3UA reports it has successfully processed an incoming ASP- 1273 DOWN request from its peer. 1275 M-ASP-ACTIVE request 1276 Direction: LM -> M3UA 1277 Purpose: LM requests ASP to send an ASP-ACTIVE message to its peer. 1279 M-ASP ACTIVE confirm 1280 Direction: M3UA -> LM 1281 Purpose: ASP reports that is has received an ASP ACTIVE 1282 Acknowledgement message from the SG. 1284 M-ASP ACTIVE indication 1285 Direction: M3UA -> LM 1286 Purpose: LM reports it has successfully processed an incoming ASP- 1287 ACTIVE request from its peer. 1289 M-ASP-INACTIVE request 1290 Direction: LM -> M3UA 1291 Purpose: LM requests ASP to send an ASP- Inactive message to the SG. 1293 M-ASP INACTIVE confirm 1294 Direction: LM -> M3UA 1295 Purpose: ASP reports that is has received an ASP INACTIVE 1296 Acknowledgement message from the SG. 1298 M-ASP INACTIVE indication 1299 Direction: M3UA -> LM 1300 Purpose: LM reports it has successfully processed an incoming ASP- 1301 INACTIVE request from its peer. 1303 M-AS ACTIVE indication 1304 Direction: M3UA -> LM 1305 Purpose: LM reports that an AS has moved to the ACTIVE state. 1307 M-AS INACTIVE indication 1308 Direction: M3UA -> LM 1309 Purpose: LM reports that an AS has moved to the INACTIVE state. 1311 M-AS DOWN indication 1312 Direction: M3UA -> LM 1313 Purpose: LM reports that an AS has moved to the DOWN state. 1315 2.0 Conventions 1317 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 1318 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 1319 in this document, are to be interpreted as described in [RFC2119]. 1321 3.0 M3UA Protocol Elements 1323 The general M3UA message format includes a Common Message Header 1324 followed by zero or more parameters as defined by the Message Type. 1325 For forward compatibility, all Message Types may have attached 1326 parameters even if none are specified in this version. 1328 3.1 Common Message Header 1330 The protocol messages for MTP3-User Adaptation require a message header 1331 which contains the adaptation layer version, the message type, and 1332 message length. 1334 0 1 2 3 1335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Version | Reserved | Message Class | Message Type | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Message Length | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 \ \ 1342 / / 1344 All fields in an M3UA message MUST be transmitted in the network byte 1345 order, unless otherwise stated. 1347 3.1.1 M3UA Protocol Version: 8 bits (unsigned integer) 1349 The version field contains the version of the M3UA adaptation layer. 1351 The supported versions are the following: 1353 1 Release 1.0 1355 3.1.2 Message Classes and Types 1357 The following list contains the valid Message Classes: 1359 Message Class: 8 bits (unsigned integer) 1361 The following list contains the valid Message Type Classes: 1363 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 1364 1 Transfer Messages [M3UA] 1365 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 1366 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 1367 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 1368 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 1369 [IUA] 1370 6 MTP2 User Adaptation (MAUP) Messages [M2UA] 1371 7 Connectionless Messages [SUA] 1372 8 Connection-Oriented Messages [SUA] 1373 9 Routing Key Management (RKM) Messages (M3UA) 1374 10 to 127 Reserved by the IETF 1375 28 to 255 Reserved for IETF-Defined Message Class extensions 1377 Message Type: 8 bits (unsigned integer) 1379 The following list contains the message types for the defined 1380 messages. 1382 Management (MGMT) Message 1384 0 Error (ERR) 1385 1 Notify (NTFY) 1386 2 to 127 Reserved by the IETF 1387 128 to 255 Reserved for IETF-Defined MGMT extensions 1389 Transfer Messages 1391 0 Reserved 1392 1 Payload Data (DATA) 1393 2 to 127 Reserved by the IETF 1394 128 to 255 Reserved for IETF-Defined Transfer extensions 1395 SS7 Signalling Network Management (SSNM) Messages 1397 0 Reserved 1398 1 Destination Unavailable (DUNA) 1399 2 Destination Available (DAVA) 1400 3 Destination State Audit (DAUD) 1401 4 SS7 Network Congestion State (SCON) 1402 5 Destination User Part Unavailable (DUPU) 1403 6 Destination Restricted (DRST) 1404 7 to 127 Reserved by the IETF 1405 128 to 255 Reserved for IETF-Defined SSNM extensions 1407 ASP State Maintenance (ASPSM) Messages 1409 0 Reserved 1410 1 ASP Up (UP) 1411 2 ASP Down (DOWN) 1412 3 Heartbeat (BEAT) 1413 4 ASP Up Ack (UP ACK) 1414 5 ASP Down Ack (DOWN ACK) 1415 6 Heatbeat Ack (BEAT ACK) 1416 7 to 127 Reserved by the IETF 1417 128 to 255 Reserved for IETF-Defined ASPSM extensions 1419 ASP Traffic Maintenance (ASPTM) Messages 1421 0 Reserved 1422 1 ASP Active (ACTIVE) 1423 2 ASP Inactive (INACTIVE) 1424 3 ASP Active Ack (ACTIVE ACK) 1425 4 ASP Inactive Ack (INACTIVE ACK) 1426 5 to 127 Reserved by the IETF 1427 128 to 255 Reserved for IETF-Defined ASPTM extensions 1429 Routing Key Management (RKM) Messages 1431 0 Reserved 1432 1 Registration Request (REG REQ) 1433 2 Registration Response (REG RSP) 1434 3 Deregistration Request (DEREG REQ) 1435 4 Deregistration Response (DEREG RSP) 1436 5 to 127 Reserved by the IETF 1437 128 to 255 Reserved for IETF-Defined ASPTM extensions 1439 3.1.3 Reserved: 8 bits 1441 The Reserved field SHOULD be set to all '0's and ignored by the 1442 receiver. 1444 3.1.4 Message Length: 32-bits (unsigned integer) 1446 The Message Length defines the length of the message in octets, 1447 including the Common Header. For messages with a final parameter 1448 containing padding, the parameter padding MUST be included in the 1449 Message Length. 1451 Note: A receiver SHOULD accept the message whether or not the final 1452 parameter padding is included in the message length. 1454 3.2 Variable-Length Parameter Format 1456 M3UA messages consist of a Common Header followed by zero or more 1457 variable length parameters, as defined by the message type. All the 1458 parameters contained in a message are defined in a Tag-Length-Value 1459 format as shown below. 1461 0 1 2 3 1462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Parameter Tag | Parameter Length | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 \ \ 1467 / Parameter Value / 1468 \ \ 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Where more than one parameter is included in a message, the parameters 1472 may be in any order, except where explicitly mandated. A receiver 1473 SHOULD accept the parameters in any order. 1475 Parameter Tag: 16 bits (unsigned integer) 1477 The Tag field is a 16-bit identifier of the type of parameter. It 1478 takes a value of 0 to 65534. The parameter Tags defined are as 1479 follows: 1481 0 Reserved 1482 1 Network Appearance 1483 2 Protocol Data 1 1484 3 Protocol Data 2 1485 4 Info String 1486 5 Affected Destinations 1487 6 Routing Context 1488 7 Diagnostic Information 1489 8 Heartbeat Data 1490 9 User/Cause 1491 10 Reason 1492 11 Traffic Mode Type 1493 12 Error Code 1494 13 Status Type/ID 1495 14 Congestion Indications 1496 15 Concerned Destination 1497 16 Routing Key 1498 17 Registration Result 1499 18 De-registration Result 1500 19 Local_Routing Key Identifier 1501 20 Destination Point Code 1502 21 Service Indicators 1503 22 Subsystem Numbers 1504 23 Originating Point Code List 1505 24 Circuit Range 1506 25 Registration Results 1507 26 De-Registration Results 1508 27 to 65534 Reserved by the IETF 1510 The value of 65535 is reserved for IETF-defined extensions. Values 1511 other than those defined in specific parameter description are 1512 reserved for use by the IETF. 1514 Parameter Length: 16 bits (unsigned integer) 1516 The Parameter Length field contains the size of the parameter in 1517 bytes, including the Parameter Tag, Parameter Length, and Parameter 1518 Value fields. The Parameter Length does not include any padding 1519 bytes. 1521 Parameter Value: variable-length. 1523 The Parameter Value field contains the actual information to be 1524 transferred in the parameter. 1526 The total length of a parameter (including Tag, Parameter Length and 1527 Value fields) MUST be a multiple of 4 bytes. If the length of the 1528 parameter is not a multiple of 4 bytes, the sender pads the 1529 Parameter at the end (i.e., after the Parameter Value field) with 1530 all zero bytes. The length of the padding is NOT included in the 1531 parameter length field. A sender SHOULD NEVER pad with more than 3 1532 bytes. The receiver MUST ignore the padding bytes. 1534 3.3 Transfer Messages 1536 The following section describes the Transfer messages and parameter 1537 contents. 1539 3.3.1 Payload Data Message (DATA) 1541 The DATA message contains the SS7 MTP3-User protocol data, which is an 1542 MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 1543 Data message contains the following variable length parameters: 1545 Network Appearance Optional 1546 Protocol Data 1 or 2 Mandatory 1548 The following format MUST be used for the Data Message: 1550 0 1 2 3 1551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Tag = 1 | Length = 8 | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Network Appearance* | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Tag = 3 | Length | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 \ \ 1560 / Protocol Data / 1561 \ \ 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 Network Appearance: 32-bits (unsigned integer) 1566 The optional Network Appearance parameter identifies the SS7 network 1567 context for the message, for the purposes of logically separating 1568 the signalling traffic between the SG and the Application Server 1569 Process over a common SCTP Association. An example is where an SG 1570 is logically partitioned to appear as an element in four different 1571 national SS7 networks. 1573 In a Data message, the Network Appearance implicitly defines the SS7 1574 Point Code format used, the SS7 Network Indicator value, and the 1575 MTP3 and possibly the MTP3-User protocol type/variant/version used 1576 within the SS7 network partition. Where an SG operates in the 1577 context of a single SS7 network, or individual SCTP associations are 1578 dedicated to each SS7 network context, the Network Appearance 1579 parameter is not required. 1581 The Network Appearance parameter value is of local significance 1582 only, coordinated between the SG and ASP. Therefore, in the case 1583 where an ASP is connected to more than one SG, the same SS7 network 1584 context may be identified by different Network Appearances depending 1585 over which SG a message is being transmitted/received. 1587 Where the optional Network Appearance parameter is present, it must 1588 be the first parameter in the message as it defines the format of 1589 the Protocol Data field. 1591 Protocol Data 1 or 2: variable length 1593 One of two possible Protocol Data parameters are included in a DATA 1594 message: Protocol Data 1 or Protocol Data 2. 1596 The Protocol Data 1 parameter contains the original SS7 MTP3 1597 message, including the Service Information Octet and Routing Label. 1599 The Protocol Data 1 parameter contains the following fields: 1601 Service Information Octet. Includes: 1602 Service Indicator, 1603 Network Indicator, 1604 and Spare/Priority codes 1606 Routing Label. Includes: 1607 Destination Point Code, 1608 Originating Point Code, 1609 And Signalling Link Selection Code (SLS) 1611 User Protocol Data. Includes: 1612 MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP 1613 parameters) 1615 The Protocol Data 2 parameter contains all the information in 1616 Protocol Data 1 as described above, plus the MTP2 Length Indicator 1617 octet. The MTP2 Length Indicator (LI) octet appears before the SIO 1618 and Routing Label information. The MTP2 Length Indicator octet is 1619 required for some national MTP variants that use the spare bits in 1620 the LI to carry additional information of interest to the MTP3 and 1621 MTP3-User (e.g., the Japan TTC standard use of LI spare bits to 1622 indicate message priority) 1624 The Payload Data format is as defined in the relevant MTP standards 1625 for the SS7 protocol being transported. The format is either 1626 implicitly known or identified by the Network Appearance parameter. 1627 Note: In the SS7 Recommendations, the format of the messages and 1628 fields within the messages are based on bit transmission order. In 1629 these recommendations the Least Significant Bit (LSB) of each field 1630 is positioned to the right. For this document the received SS7 1631 fields are populated octet by octet as received into the 4-octet 1632 word as shown in the examples below. 1634 For the ANSI protocol example, the Protocol Data field format is 1635 shown below: 1637 0 1 2 3 1638 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | SIO | DPC Member | DPC Cluster | DPC Network | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | OPC Member | OPC Cluster | OPC Network | SLS | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 \ \ 1645 / Protocol Data / 1646 \ \ 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 |MSB---------------------------------------------------------LSB| 1651 Within each octet the Least Significant Bit (LSB) per the SS7 1652 Recommendations is to the right (e.g., bit 7 of SIO is the LSB). 1654 For the ITU international protocol example, the Protocol Data field 1655 is shown below. 1657 0 1 2 3 1658 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | SIO | DPC | DPC |OPC| DPC | DPC | OPC |@| 1661 | | Region *| SP *|SP*|Zone*| reg.| Region *| | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | SLS | OPC |$| Protocol | 1664 | *| SP *| | Data | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 * marks LSB of each field; @ = OPC SP MSB; $ = OPC region MSB 1669 3.4 SS7 Signalling Network Management (SSNM) Messages 1671 3.4.1 Destination Unavailable (DUNA) 1673 The DUNA message is sent from the SG to all concerned ASPs to indicate 1674 that the SG has determined that one or more SS7 destinations are 1675 unreachable. It is also sent in response to a message from the ASP to 1676 an unreachable SS7 destination. As an implementation option the SG may 1677 suppress the sending of subsequent "response" DUNAs regarding a certain 1678 unreachable SS7 destination for a certain period in order to give the 1679 remote side time to react. The MTP3-User at the ASP is expected to stop 1680 traffic to the affected destination through the SG initiating the DUNA 1681 as per the defined MTP3-User procedures. 1683 The DUNA message contains the following parameters: 1685 Network Appearance Optional 1686 Affected Destinations Mandatory 1687 Info String Optional 1689 The format for DUNA Message parameters is as follows: 1691 0 1 2 3 1692 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Tag = 1 | Length =8 | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Network Appearance* | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Tag = 5 | Length | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Mask | Affected DPC 1 | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 \ \ 1703 / ... / 1704 \ \ 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Mask | Affected DPC n | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Tag = 4 | Length | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 \ \ 1711 / INFO String* / 1712 \ \ 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Network Appearance: 32-bit unsigned integer 1717 See Section 3.3.1 1719 Affected Destinations: n x 32-bits 1721 The Affected Destinations parameter contains up to sixteen Affected 1722 Destination Point Code fields, each a three-octet parameter to allow 1723 for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected 1724 Point Codes that are less than 24-bits, are padded on the left to 1725 the 24-bit boundary. The encoding is shown below for ANSI and ITU 1726 Point Code examples. 1728 ANSI 24-bit Point Code: 1730 0 1 2 3 1731 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Mask | Network | Cluster | Member | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 |MSB-----------------------------------------LSB| 1738 ITU 14-bit Point Code: 1740 0 1 2 3 1741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 |MSB--------------------LSB| 1748 It is optional to send an Affected Destinations parameter with more 1749 than one Affected DPC but it is mandatory to receive and process it. 1750 All the Affected DPCs included must be within the same Network 1751 Appearance. Including multiple Affected DPCs may be useful when 1752 reception of an MTP3 management message or a linkset event 1753 simultaneously affects the availability status of a list of 1754 destinations at an SG. 1756 Mask: 8-bits (unsigned integer) 1758 The Mask field associated with each Affected DPC in the Affected 1759 Destinations parameter, used to identify a contiguous range of 1760 Affected Destination Point Codes, independent of the point code 1761 format. Identifying a contiguous range of Affected DPCs may be 1762 useful when reception of an MTP3 management message or a linkset 1763 event simultaneously affects the availability status of a series of 1764 destinations at an SG. For example, if all DPCs in an ANSI cluster 1765 are determined to be unavailable due to local linkset 1766 unavailability, the DUNA could identify potentially 256 Affected 1767 DPCs in a single Affected DPC field. 1769 The Mask parameter represents a bit mask that can be applied to the 1770 related Affected DPC field. The bit mask identifies how many bits 1771 of the Affected DPC field are significant and which are effectively 1772 "wildcarded". For example, a mask of "8" indicates that the least 1773 significant eight bits of the DPC is "wildcarded". For an ANSI 24- 1774 bit Affected DPC, this is equivalent to signalling that all DPCs in 1775 an ANSI Cluster are unavailable. A mask of "3" indicates that the 1776 least significant three bits of the DPC is "wildcarded". For a 14- 1777 bit ITU Affected DPC, this is equivalent to signaling that an ITU 1778 Region is unavailable. A mask value equal to the number of bits in 1779 the DPC indicates that the entire network appearance is affected � 1780 this is used to indicate network isolation to the ASP. 1782 Info String: variable length 1784 The optional INFO String parameter can carry any 8-bit ASCII 1785 character string along with the message. Length of the INFO 1786 String parameter is from 0 to 255 characters. No procedures are 1787 presently identified for its use but the INFO String MAY be used by 1788 Operators to identify in text form the location reflected by the 1789 Affected DPC for debugging purposes. 1791 3.4.2 Destination Available (DAVA) 1793 The DAVA message is sent from the SG to all concerned ASPs to indicate 1794 that the SG has determined that one or more SS7 destinations are now 1795 reachable (and not restricted), or in response to a DAUD message if 1796 appropriate. The ASP MTP3-User protocol is allowed to resume traffic to 1797 the affected destination through the SG initiating the DUNA. 1799 The DAVA message contains the following parameters: 1801 Network Appearance Optional 1802 Affected Destinations Mandatory 1803 Info String Optional 1805 The format and description of the Network Appearance, Affected 1806 Destinations and Info String parameters is the same as for the DUNA 1807 message (See Section 3.4.1.) 1809 3.4.3 Destination State Audit (DAUD) 1811 The DAUD message can be sent from the ASP to the SG to audit the 1812 availability/congestion state of SS7 routes to one or more affected 1813 destinations. 1815 The DAUD message contains the following parameters: 1817 Network Appearance Optional 1818 Affected Destinations Mandatory 1819 Info String Optional 1821 The format and description of DAUD Message parameters is the same as 1822 for the DUNA message (See Section 3.4.1.) 1824 3.4.4 SS7 Network Congestion (SCON) 1826 The SCON message can be sent from the SG to all concerned ASPs to 1827 indicate congestion in the SS7 network to one or more destinations, or 1828 to an ASP in response to a DATA or DAUD message as appropriate. For 1829 some MTP protocol variants (e.g., ANSI MTP) the SCON may be sent when 1830 the SS7 congestion level changes. The SCON message MAY also be sent 1831 from the M3UA of an ASP to an M3UA peer indicating that the M3UA or the 1832 ASP is congested. 1834 The SCON message contains the following parameters: 1836 Network Appearance Optional 1837 Affected Destinations Mandatory 1838 Concerned Destination Optional Congestion Indications 1839 Optional 1840 Info String Optional 1842 The format for SCON Message parameters is as follows: 1844 0 1 2 3 1845 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | Tag = 1 | Length =8 | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | Network Appearance* | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Tag = 5 | Length | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Mask | Affected DPC 1 | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 \ \ 1856 / ... / 1857 \ \ 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Mask | Affected DPC n | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Tag = 15 | Length | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | reserved | Concerned DPC | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Tag = 14 | Length | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Reserved | Cong. Level* | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Tag = 4 | Length | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 \ \ 1872 / INFO String* / 1873 \ \ 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 The format and description of the Network Appearance, Affected 1877 Destinations, and Info String parameters is the same as for the DUNA 1878 message (See Section 3.4.1.) 1880 The Affected Destinations parameter can be used to indicate congestion 1881 of multiple destinations or ranges of destinations. However, an SCON 1882 MUST not be delayed in order to "collect" individual congested 1883 destinations into a single SCON as any delay might affect the timing of 1884 congestion indications to the M3UA Users. One use for including a 1885 range of Congested DPCs is when the SG supports an ANSI cluster route 1886 set to the SS7 network that becomes congested due to outgoing link set 1887 congestion. 1889 Concerned Destination: 32-bits 1891 The optional Concerned Destination parameter is only used if the 1892 SCON is sent from an ASP to the SG. It contains the point code of 1893 the originator of the message that triggered the SCON. The Concerned 1894 Destination parameter contains one Concerned Destination Point Code 1895 field, a three-octet parameter to allow for 14-, 16- and 24-bit 1896 binary formatted SS7 Point Codes. A Concerned Point Code that is 1897 less than 24-bits, is padded on the left to the 24-bit boundary. The 1898 SG sends a Transfer Controlled Message to the Concerned Point Code 1899 using the single Affected DPC contained in the SCON to populate the 1900 (affected) Destination field of the TFC message. Normally the 1901 Affected DPC will be equal to the point code of the ASP. 1903 Congested Indications: 32-bits 1905 The optional Congestion Indications parameter contains a Congestion 1906 Level field. This optional parameter is used to communicate 1907 congestion levels in national MTP networks with multiple congestion 1908 thresholds, such as in ANSI MTP3. For MTP congestion methods 1909 without multiple congestion levels (e.g., the ITU international 1910 method) the parameter is not included. 1912 Congestion Level field: 8-bits (unsigned integer) 1914 The Congestion Level field, associated with all of the Affected 1915 DPC(s) in the Affected Destinations parameter, contains one of the 1916 Following values: 1918 0 No Congestion or Undefined 1919 1 Congestion Level 1 1920 2 Congestion Level 2 1921 3 Congestion Level 3 1923 The congestion levels are defined in the congestion method in the 1924 appropriate national MTP recommendations [14,15]. 1926 3.4.5 Destination User Part Unavailable (DUPU) 1928 The DUPU message is used by an SG to inform an ASP that a remote peer 1929 MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. 1931 The DUPU message contains the following parameters: 1933 Network Appearance Optional 1934 Affected Destinations Mandatory 1935 User/Cause Mandatory 1936 Info String Optional 1938 The format for DUPU Message parameters is as follows: 1940 0 1 2 3 1941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | Tag = 1 | Length | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Network Appearance* | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Tag = 5 | Length = 8 | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Mask = 0 | Affected DPC | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Tag = 9 | Length = 8 | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Cause | User | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Tag = 4 | Length | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 \ \ 1958 / INFO String* / 1959 \ \ 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 User/Cause: 32-bits 1964 The Unavailability Cause and MTP3-User Identity fields, associated 1965 with the Affected DPC in the Affected Destinations parameter, are 1966 encoded as follows: 1968 Unavailability Cause field: 16-bits (unsigned integer) 1970 The Unavailability Cause parameter provides the reason for the 1971 unavailability of the MTP3-User. The valid values for the 1972 Unavailability Cause parameter are shown in the following table. 1973 The values agree with those provided in the SS7 MTP3 User Part 1974 Unavailable message. Depending on the MTP3 protocol used in the 1975 network appearance, additional values may be used - the 1976 specification of the relevant MTP3 protocol variant/version 1977 recommendation is definitive. 1979 0 Unknown 1980 1 Unequipped Remote User 1981 2 Inaccessible Remote User 1983 MTP3-User Identity field: 16-bits (unsigned integer) 1985 The MTP3-User Identity describes the specific MTP3-User that is 1986 unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for 1987 the MTP3-User Identity are shown below. The values agree with those 1988 provided in the SS7 MTP3 User Part Unavailable message and Service 1989 Indicator. Depending on the MTP3 protocol variant/version used in 1990 the network appearance, additional values may be used. The relevant 1991 MTP3 protocol variant/version recommendation is definitive. 1993 0 to 2 Reserved 1994 3 SCCP 1995 4 TUP 1996 5 ISUP 1997 6 to 8 Reserved 1998 9 Broadband ISUP 1999 10 Satellite ISUP 2001 The format and description of the Affected Destinations parameter is 2002 the same as for the DUNA message (See Section 3.4.1.) except that the 2003 Mask field is not used and only a single Affected DPC is included. 2004 Ranges and lists of Affected DPCs cannot be signaled in a DUPU, but 2005 this is consistent with UPU operation in the SS7 network. The Affected 2006 Destinations parameter in an MTP3 User Part Unavailable message (UPU) 2007 received by an SG from the SS7 network contains only one destination. 2009 The format and description of the Network Appearance and Info String 2010 parameters is the same as for the DUNA message (See Section 3.4.1.). 2012 3.4.6 Destination Restricted (DRST) 2014 The DRST message is optionally sent from the SG to all concerned ASPs 2015 to indicate that the SG has determined that one or more SS7 2016 destinations are now restricted, or in response to a DAUD message if 2017 appropriate. The M3UA at the ASP is expected to send traffic to the 2018 affected destination via an alternate SG of equal priority, but only if 2019 such an alternate route exists and is available. If the affected 2020 destination is currently considered unavailable by the ASP, traffic to 2021 the affected destination through the SG initiating the DRST should be 2022 resumed. 2024 This message is optional for the SG to send and optional for the ASP to 2025 process. It is for use in the "STP" case described in Section 1.4.2. 2027 The DRST message contains the following parameters: 2029 Network Appearance Optional 2030 Affected Destinations Mandatory 2031 Info String Optional 2033 The format and description of the Network Appearance, Affected 2034 Destinations and Info String parameters is the same as for the DUNA 2035 message (See Section 3.4.1.) 2037 3.5 Application Server Process Maintenance (ASPM) Messages 2039 3.5.1 ASP Up (ASPUP) 2041 The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer 2042 that the Adaptation layer is ready to receive SSNM or ASPM management 2043 messages for all Routing Keys that the ASP is configured to serve. 2045 The ASPUP message contains the following parameters: 2047 INFO String Optional 2049 The format for ASPUP Message parameters is as follows: 2051 0 1 2 3 2052 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | Tag = 4 | Length | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 \ \ 2057 / INFO String* / 2058 \ \ 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 The format and description of the optional Info String parameter is the 2062 same as for the DUNA message (See Section 3.4.1.) 2064 3.5.2 ASP Up Ack 2066 The ASP UP Ack message is used to acknowledge an ASP-Up message 2067 received from a remote M3UA peer. 2069 The ASPUP Ack message contains the following parameters: 2071 INFO String (optional) 2073 The format for ASPUP Ack Message parameters is as follows: 2075 0 1 2 3 2076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 | Tag =4 | Length | 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 \ \ 2081 / INFO String* / 2082 \ \ 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 The format and description of the optional Info String parameter is the 2086 same as for the DUNA message (See Section 3.4.1.) 2088 3.5.3 ASP Down (ASPDN) 2090 The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer 2091 that the adaptation layer is NOT ready to receive traffic or 2092 maintenance messages. 2094 The ASPDN message contains the following parameters: 2096 Reason Mandatory 2097 INFO String Optional 2099 The format for the ASPDN message parameters is as follows: 2101 0 1 2 3 2102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Tag = 10 | Length | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Reason | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Tag =4 | Length | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 \ \ 2111 / INFO String* / 2112 \ \ 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 The format and description of the optional Info String parameter is the 2116 same as for the DUNA message (See Section 3.4.1.) 2118 Reason: 32-bit (unsigned integer) 2120 The Reason parameter indicates the reason that the remote M3UA 2121 adaptation layer is unavailable. The valid values for Reason are 2122 shown in the following table. 2124 0 Unspecified 2125 1 User Unavailable 2126 2 Management Blocking 2128 3.5.4 ASP Down Ack 2130 The ASP Down Ack message is used to acknowledge an ASP-Down message 2131 received from a remote M3UA peer, or to reply to an ASPM message from 2132 an ASP which is locked out for management reasons. 2134 The ASP Down Ack message contains the following parameters: 2136 Reason Mandatory 2137 INFO String Optional 2139 The format for the ASPDN Ack message parameters is as follows: 2141 0 1 2 3 2142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Tag = 10 | Length | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Reason | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Tag = 4 | Length | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 \ \ 2151 / INFO String* / 2152 \ \ 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 The format and description of the optional Info String parameter is the 2156 same as for the DUNA message (See Section 3.4.1.) 2158 The format of the Reason parameter is the same as for the ASP-Down 2159 message. (See Section 3.4.3) 2161 3.5.5 Registration Request (REG REQ) 2163 The REG REQ message is sent by an ASP to indicate to a remote M3UA peer 2164 that it wishes to register one or more given Routing Key with the 2165 remote peer. Typically, an ASP would send this message to an SGP, and 2166 expects to receive a REG RSP in return with an associated Routing 2167 Context value. 2169 The REG REQ message contains the following parameters: 2171 Routing Key Mandatory 2173 The format for the REG REQ message is as follows: 2175 0 1 2 3 2176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | Tag = 16 | Length | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 \ \ 2181 / Routing Key 1 / 2182 \ \ 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 \ \ 2185 / ... / 2186 \ \ 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | Tag = 16 | Length | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 \ \ 2191 / Routing Key n / 2192 \ \ 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 Routing Key: variable length 2197 The Routing Key parameter is mandatory. The sender of this message 2198 expects that the receiver of this message will create a Routing 2199 Key entry and assign a unique Routing Context value to it, if the 2200 Routing Key entry does not already exist. 2202 The Routing Key parameter may be present multiple times in the same 2203 message. This is used to allow the registration of multiple Routing 2204 Keys in a single message. 2206 The format of the Routing Key parameter is as follows. 2208 0 1 2 3 2209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | Local-RK-Identifier | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | Destination Point Code | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | Network Appearance (optional) | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | SI (optional) | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | SSN (optional) | 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Origination Point Code List (optional) | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Circuit Range List (optional) | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 Local-RK-Identifier: 32-bit integer 2228 The mandatory Local-RK-Identifier field is used to uniquely identify 2229 the registration request. The Identifier value is assigned by the 2230 ASP, and is used to correlate the response in an REG RSP message 2231 with the original registration request. The Identifier value must 2232 remain unique until the REG RSP is received. 2234 The format of the Local-RK-Identifier field is as follows: 2236 0 1 2 3 2237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Tag = 19 | Length = 8 | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Local-RK-Identifier value | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Destination Point Code: 2246 The Destination Point Code parameter is mandatory, and identifies 2247 the Destination Point Code of incoming SS7 traffic for which the ASP 2248 is registering. The format is the same as described for the 2249 Affected Destination parameter in the DUNA Message (See Section 2250 3.4.1). Its format is: 2252 0 1 2 3 2253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 | Tag = 20 | Length = 8 | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | Mask = 0 | Destination Point Code | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 Network Appearance: 2262 The optional Network Appearance parameter field identifies the SS7 2263 Network context for the Routing Key, and has the same format as in 2264 the Data message (See Section 3.3.1). Its format is: 2266 0 1 2 3 2267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Tag = 1 | Length = 8 | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Network Appearance | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 Service Indicators (SI): n X 8-bit integers 2276 The SI field contains one or more Service Indicators from the values 2277 as described in the MTP3-User Identity field of the DUPU Message. 2278 The absence of the SI parameter in the Routing Key indicates the use 2279 of any SI values, excluding of course MTP management. Where an SI 2280 parameter does not contain a multiple of four SIs, the parameter is 2281 padded out to 32-byte alignment. An SI value of zero is not valid 2282 in M3UA. The SI format is: 2284 0 1 2 3 2285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Tag = 21 | Length = var. | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | SI #1 | SI #2 | SI #3 | SI #4 | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 / ... / 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | SI #n | 0 Padding, if necessary | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 Subsystem Numbers (SSN): n X 8-bit integers 2298 The optional SSN field contains one or more SCCP subsystem numbers, 2299 and is used in conjunction with an SI values of 3 (i.e., SCCP) only. 2300 Where an SSN parameter does not contain a multiple of four SSNs, the 2301 parameter is padded out to 32-byte alignment. The subsystem number 2302 values associated are defined by the local network operator, and 2303 typically follow ITU-T Recommendation Q.713. An SSN value of zero 2304 is not valid in M3UA. The format of this field is as follows: 2306 0 1 2 3 2307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | Tag = 22 | Length = var. | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | SSN #1 | SSN #2 | SSN #3 | SSN #4 | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 / ... / 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | SSN #n | 0 Padding, if necessary | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 OPC List: 2320 The Originating Point Code List parameter contains one or more SS7 2321 OPC entries, and its format is the same as the Destination Point 2322 Code parameter. 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | Tag = 23 | Length = var. | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | Mask = 0 | Origination Point Code #1 | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | Mask = 0 | Origination Point Code #2 | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 / ... / 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Mask = 0 | Origination Point Code #n | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 Circuit Range: 2338 An ISUP controlled circuit is uniquely identified by the SS7 OPC, 2339 DPC and CIC value. For the purposes of identifying Circuit Ranges 2340 in an M3UA Routing Key, the optional Circuit Range parameter 2341 includes one or more circuit ranges, each identified by an OPC and 2342 Upper/Lower CIC value. The DPC is implicit as it is mandatory and 2343 already included in the DPC parameter of the Routing Key. The 2344 Origination Point Code is encoded the same as the Destination Point 2345 Code parameter, while the CIC values are 16-bit integers. 2347 The Circuit Range format is as follows: 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Tag = 24 | Length = var. | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Mask = 0 | Origination Point Code #1 | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Lower CIC Value #1 | Upper CIC Value #1 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | Mask = 0 | Origination Point Code #2 | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Lower CIC Value #2 | Upper CIC Value #2 | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 / ... / 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | Mask = 0 | Origination Point Code #n | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | Lower CIC Value #n | Upper CIC Value #n | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 3.5.6 Registration Response (REG RSP) 2369 The REG RSP message is used as a response to the REG REQ message from a 2370 remote M3UA peer. It contains indications of success/failure for 2371 registration requests and returns a unique Routing Context value for 2372 successful registration requests, to be used in subsequent M3UA Traffic 2373 Management protocol. 2375 The REG RSP message contains the following parameters: 2377 Registration Results Mandatory 2379 The format for the REG RSP message is as follows: 2381 0 1 2 3 2382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Tag = 25 | Length = var. | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | Registration Result 1 | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 / ... / 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Registration Result n | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 Registration Results: 2395 The Registration Results parameter contains one or more results, 2396 each containing the registration status for a single Routing Key in 2397 an REG REQ message. The number of results in a single REG RSP 2398 message MAY match the number of Routing Key parameters found in the 2399 corresponding REG REQ message. The format of each result is as 2400 follows: 2402 0 1 2 3 2403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | Local-RK-Identifier value | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | Registration Status | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | Routing Context | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 Local-RK-Identifier: 32-bit integer 2414 The Local-RK-Identifier contains the same value as found in the 2415 matching Routing Key parameter found in the REG Req message. 2417 Registration Status: 32-bit integer 2419 The Registration Result Status field indicates the success or the 2420 reason for failure of a registration request. 2422 Its values may be: 2424 0 Successfully Registered 2425 1 Error - Unknown 2426 2 Error - Invalid DPC 2427 3 Error - Invalid Network Appearance 2428 4 Error - Invalid Routing Key 2429 5 Error - Permission Denied 2430 6 Error - Overlapping (Non-unique) Routing Key 2431 7 Error - Routing Key not Provisioned 2432 8 Error - Insufficient Resources 2434 Routing Context: 32-bit integer 2436 The Routing Context field contains the Routing Context value for the 2437 associated Routing Key if the registration was successful. It is set 2438 to "0" if the registration was not successful. 2440 3.5.7 De-Registration Request (DEREG REQ) 2442 The DEREG REQ message is sent by an ASP to indicate to a remote M3UA 2443 peer that it wishes to de-register a given Routing Key. Typically, an 2444 ASP would send this message to an SGP, and expects to receive a DEREG 2445 RSP in return with the associated Routing Context value. 2447 The DEREG REQ message contains the following parameters: 2449 Routing Context Mandatory 2451 The format for the DEREG REQ message is as follows: 2453 0 1 2 3 2454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | Tag = 6 | Length | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 \ \ 2459 / Routing Context / 2460 \ \ 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 Routing Context: n X 32-bit integers 2465 The Routing Context parameter contains (a list of) integers indexing 2466 the Application Server traffic that the sending ASP is currently 2467 registered to receive from the SG but now wishes to deregister. 2469 3.5.8 De-Registration Response (DEREG RSP) 2471 The DEREG RSP message is used as a response to the DEREG REQ message 2472 from a remote M3UA peer. 2474 The DEREG RSP message contains the following parameters: 2476 De-registration Results Mandatory 2478 The format for the DEREG RSP message is as follows: 2480 0 1 2 3 2481 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | Tag = 18 | Length = var | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | De-Registration Result 1 | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 / ... / 2488 \ \ 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | De-Registration Result n | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 De-Registration Results: 2495 The De-Registration Results parameter contains one or more results, 2496 each containing the de-registration status for a single Routing 2497 Context in a DEREG REQ message. The number of results in a single 2498 DEREG RSP message MAY match the number of Routing Contexts found in 2499 the corresponding DEREG REQ message. The format of each result is 2500 as follows: 2502 0 1 2 3 2503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Routing Context | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | De-Registration Status | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 Routing Context: 32-bit integer 2512 The Routing Context field contains the Routing Context value of the 2513 matching Routing Key to deregister, as found in the DEREG Req. 2515 De-Registration Status: 32-bit integer 2517 The De-Registration Result Status field indicates the success or the 2518 reason for failure of the de-registration. 2520 Its values may be: 2521 0 Successfully De-registered 2522 1 Error - Unknown 2523 2 Error - Invalid Routing Context 2524 3 Error - Permission Denied 2525 4 Error - Not Registered 2527 3.5.5 ASP Active (ASPAC) 2529 The ASPAC message is sent by an ASP to indicate to a remote M3UA peer 2530 that it is Active and ready to process signalling traffic for a 2531 particular Application Server. The ASPAC affects only the ASP state 2532 for the routing keys identified by the Routing Contexts, if present. 2534 The ASPAC message contains the following parameters: 2536 Traffic Mode Type Mandatory 2537 Routing Context Optional 2538 INFO String Optional 2540 The format for the ASPAC message is as follows: 2542 0 1 2 3 2543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Tag = 11 | Length | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Traffic Mode Type | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | Tag = 6 | Length | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 \ \ 2552 / Routing Context* / 2553 \ \ 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | Tag = 4 | Length | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 \ \ 2558 / INFO String* / 2559 \ \ 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 Traffic Mode Type: 32-bit (unsigned integer) 2564 The Traffic Mode Type parameter identifies the traffic mode of 2565 operation of the ASP within an AS. The valid values for Type are 2566 shown in the following table. 2568 1 Over-ride 2569 2 Load-share 2570 3 Over-ride (Standby) 2571 4 Load-share (Standby) 2573 Within a particular Routing Context, only one Traffic Mode Type 2574 can be used. The Over-ride value indicates that the ASP is 2575 operating in Over-ride mode, and the ASP takes over all 2576 traffic in an Application Server (i.e., primary/back-up operation), 2577 over-riding any currently active ASPs in the AS. In Load-share 2578 mode, the ASP will share in the traffic distribution with any other 2579 currently active ASPs. The Standby versions of the Over-ride and 2580 Load-share Types indicate that the ASP is declaring itself ready to 2581 accept traffic but leaves it up to the sender as to when the traffic 2582 is started. Over-ride (Standby) indicates that the traffic sender 2583 continues to use the currently active ASP until it can no longer 2584 send/receive traffic (i.e., the currently active ASP transitions to 2585 Down or Inactive). At this point the sender MUST move the standby 2586 ASP to Active and commence traffic. Load-share (Standby) is similar 2587 - the sender continues to load-share to the current ASPs until it is 2588 determined that there is insufficient resources in 2589 the Load-share group. When there are insufficient ASPs, the sender 2590 MUST move the ASP to Active. 2592 Routing Context: n X 32-bit integers 2594 The optional Routing Context parameter contains (a list of) integers 2595 indexing the Application Server traffic that the sending ASP is 2596 configured/registered to receive. 2598 There is one-to-one relationship between an index entry and an SG 2599 Routing Key or AS Name. Because an AS can only appear in one 2600 Network Appearance, the Network Appearance parameter is not required 2601 in the ASPAC message. 2603 An Application Server Process may be configured to process traffic 2604 for more than one logical Application Server. From the perspective 2605 of an ASP, a Routing Context defines a range of signalling traffic 2606 that the ASP is currently configured to receive from the SG. For 2607 example, an ASP could be configured to support call processing for 2608 multiple ranges of PSTN trunks and therefore receive related 2609 signalling traffic, identified by separate SS7 DPC/OPC/CIC_ranges. 2611 The format and description of the optional Info String parameter is the 2612 same as for the DUNA message (See Section 3.4.1.) 2614 3.5.6 ASP Active Ack 2616 The ASPAC Ack message is used to acknowledge an ASP-Active message 2617 received from a remote M3UA peer. In the case where an ASPAC (Over- 2618 ride (standby)) or ASPAC (load-share (standby) is received, a second 2619 ASPACK Ack is sent when the ASP is moved to the "Active" state from 2620 "Active (Standby)". 2622 The ASPAC Ack message contains the following parameters: 2624 Traffic Mode Type Mandatory 2625 Routing Context Optional 2626 INFO String Optional 2628 The format for the ASPAC Ack message is as follows: 2630 0 1 2 3 2631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Tag = 11 | Length | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Traffic Mode Type | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Tag = 6 | Length | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 \ \ 2640 / Routing Context* / 2641 \ \ 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Tag = 4 | Length | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 \ \ 2646 / INFO String* / 2647 \ \ 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 The format and description of the optional Info String parameter is the 2651 same as for the DUNA message (See Section 3.3.2.1.) 2653 The format of the Traffic Mode Type and Routing Context parameters is 2654 the same as for the ASP-Active message. (See Section 3.4.5). 2656 3.5.7 ASP Inactive (ASPIA) 2658 The ASPIA message is sent by an ASP to indicate to a remote M3UA peer 2659 that it is no longer an active ASP to be used from within a list of 2660 ASPs. The ASPIA affects only the ASP state in the Routing Keys 2661 identified by the Routing Contexts, if present. 2663 The ASPIA message contains the following parameters: 2665 Routing Context Optional 2666 INFO String Optional 2668 The format for the ASPIA message parameters is as follows: 2670 0 1 2 3 2671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | Tag = 6 | Length | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 \ \ 2676 / Routing Context* / 2677 \ \ 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | Tag = 4 | Length | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 \ \ 2682 / INFO String* / 2683 \ \ 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 The format and description of the optional Routing Context and Info 2687 String parameters is the same as for the ASPAC message (See Section 2688 3.5.5.) 2690 3.5.8 ASP Inactive Ack 2692 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 2693 received from a remote M3UA peer. 2695 The ASPIA Ack message contains the following parameters: 2697 Routing Context Optional 2698 INFO String Optional 2700 The format for the ASPIA Ack message is as follows: 2702 0 1 2 3 2703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | Tag = 6 | Length | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 \ \ 2708 / Routing Context* / 2709 \ \ 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Tag = 4 | Length | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 \ \ 2714 / INFO String* / 2715 \ \ 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 The format and description of the optional Info String parameter is the 2719 same as for the DUNA message (See Section 3.4.1.) 2721 The format of the Routing Context parameter is the same as for the ASP- 2722 Inactive message. (See Section 3.5.7). 2724 3.5.9 Heartbeat (BEAT) 2726 The Heartbeat message is optionally used to ensure that the M3UA peers 2727 are still available to each other. It is recommended for use when the 2728 M3UA runs over a transport layer other than the SCTP, which has its own 2729 heartbeat. 2731 The BEAT message contains the following parameters: 2733 Heatbeat Data Optional 2735 The format for the BEAT message is as follows: 2737 0 1 2 3 2738 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | Tag = 8 | Length | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 \ \ 2743 / Heartbeat Data * / 2744 \ \ 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 The Heartbeat Data parameter contents are defined by the sending node. 2748 The Heartbeat Data could include, for example, a Heartbeat Sequence 2749 Number and/or Timestamp. The receiver of a Heartbeat message does not 2750 process this field as it is only of significance to the sender. The 2751 receiver MUST respond with a BEAT-Ack message. 2753 3.5.10 Heartbeat Ack (Beat-Ack) 2755 The Heartbeat Ack message is sent in response to a received Heartbeat 2756 message. It includes all the parameters of the received Heartbeat 2757 message, without any change. 2759 3.6 Management Messages 2761 3.6.1 Error (ERR) 2763 The Error message is used to notify a peer of an error event associated 2764 with an incoming message. For example, the message type might be 2765 unexpected given the current state, or a parameter value might be 2766 invalid. 2768 The ERR message contains the following parameters: 2770 Error Code Mandatory 2771 Diagnostic Information Optional 2773 The format for the ERR message is as follows: 2775 0 1 2 3 2776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Tag = 12 | Length | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Error Code | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Tag = 7 | Length | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 \ \ 2785 / Diagnostic Information* / 2786 \ \ 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 Error Code: 32-bits (unsigned integer) 2791 The Error Code parameter indicates the reason for the Error Message. 2792 The Error parameter value can be one of the following values: 2794 1 Invalid Version 2795 2 Invalid Network Appearance 2796 3 Unsupported Message Class 2797 4 Unsupported Message Type 2798 5 Unsupported/Invalid Traffic Handling Mode 2799 6 Unexpected Message 2800 7 Protocol Error 2801 8 Invalid Routing Context 2802 9 Invalid Stream Identifier 2803 10 Invalid Parameter Value 2805 The "Invalid Version" error is sent if a message was received with an 2806 invalid or unsupported version. The Error message contains the 2807 supported version in the Common header. The Error message could 2808 optionally provide the supported version in the Diagnostic Information 2809 area. 2811 The "Invalid Network Appearance" error is sent by a SG if an ASP sends 2812 a message with an invalid (unconfigured) Network Appearance value. 2814 The "Unsupported Message Class" error is sent if a message with an 2815 unexpected or unsupported Message Class is received. 2817 The "Unsupported Message Type" error is sent if a message with an 2818 unexpected or unsupported Message Type is received. 2820 The "Unsupported/Invalid Traffic Handling Mode" error is sent by a SG 2821 if an ASP sends an ASP Active with an unsupported Traffic Handling Mode 2822 or a Traffic Handling mode that is inconsistent with the presently 2823 configured mode for the Application Server. An example would be a case 2824 in which the SG did not support load-sharing. 2826 The "Unexpected Message" error MAY be sent if a defined and recognized 2827 message is received that is not expected in the current state( in some 2828 cases the ASP may optionally silently discard the message and not send 2829 an Error). For example, silent discard is used by an ASP if it 2830 received a Transfer message from an SG while it was in the Inactive 2831 state. 2833 The "Protocol Error" error is sent for any protocol anomaly(i.e., 2834 reception of a parameter that is syntactically correct but unexpected 2835 in the current situation. 2837 The "Invalid Routing Context" error is sent by an SG if an Asp sends a 2838 message with an invalid (unconfigured) Routing Context value. 2840 The "Invalid Stream Identifier" error is sent if a message was received 2841 on an unexpected SCTP stream (e.g., a MGMT message was received on a 2842 stream other than "0"). 2844 The " Invalid Parameter Value " error is sent if a message was received 2845 with an invalid parameter value (e.g., a DUPU message was received with 2846 a Mask value other than "0"). 2848 Diagnostic Information: variable length 2850 When included, the optional Diagnostic information can be any 2851 information germane to the error condition, to assist in 2852 identification of the error condition. In the case of an Invalid 2853 Network Appearance, Traffic Handling Mode, Routing Context or 2854 Parameter Value, the Diagnostic information includes the received 2855 parameter. In the other cases, the Diagnostic information may be 2856 the first 40 bytes of the offending message. 2858 Error messages are not generated in response to other Error messages. 2860 3.6.2 Notify (NTFY) 2862 The Notify message used to provide an autonomous indication of M3UA 2863 events to an M3UA peer. 2865 The NTFY message contains the following parameters: 2867 Status Type/ID Mandatory 2868 Routing Context Optional 2869 INFO String Optional 2871 The format for the NTFY message is as follows: 2873 0 1 2 3 2874 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 | Tag = 13 | Length | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | Status Type | Status Identification | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | Tag = 6 | Length | 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 \ \ 2883 / Routing Context* / 2884 \ \ 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2886 | Tag = 4 | Length | 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 \ \ 2889 / INFO String* / 2890 \ \ 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 Status Type: 16-bits (unsigned integer) 2895 The Status Type parameter identifies the type of the Notify message. 2896 The following are the valid Status Type values: 2898 1 Application Server State Change (AS-StateChange) 2899 2 Other 2901 Status Information: 16-bits (unsigned integer) 2903 The Status Information parameter contains more detailed information 2904 for the notification, based on the value of the Status Type. 2906 If the Status Type is AS_State_Change the following Status 2907 Information values are used: 2909 1 reserved 2910 2 Application Server Inactive (AS-Inactive) 2911 3 Application Server Active (AS-Active) 2912 4 Application Server Pending (AS-Pending) 2914 These notifications are sent from an SG to an ASP upon a change in 2915 status of a particular Application Server. The value reflects the 2916 new state of the Application Server. 2918 If the Status Type is Other, then the following Status Information 2919 values are defined: 2921 1 Insufficient ASP resources active in AS 2922 2 Alternate ASP Active 2924 These notifications are not based on the SG reporting the state change 2925 of an ASP or AS. In the Insufficent ASP Resources case, the SG is 2926 indicating to an "Inactive" ASP(s) in the AS that another ASP is 2927 required in order to handle the load of the AS (Load-sharing mode). 2928 For the Alternate ASP Active case, an ASP is informed when an alternate 2929 ASP transitions to the ASP-Active state in Over-ride mode. 2931 The format and description of the optional Routing Context and Info 2932 String parameters is the same as for the ASPAC message (See Section 2933 3.4.6.) 2935 4.0 Procedures 2937 The M3UA layer needs to respond to various local primitives it receives 2938 from other layers as well as the messages that it receives from the 2939 peer M3UA layer. This section describes the M3UA procedures in 2940 response to these events. 2942 4.1 Procedures to support the services of the M3UA layer 2944 4.1.1 Receipt of primitives from the M3UA-User 2946 On receiving an MTP-Transfer request primitive from an upper layer, or 2947 the nodal inter-working function at an SG, the M3UA layer sends a 2948 corresponding DATA message (see Section 3) to its M3UA peer. The M3UA 2949 peer receiving the Data message sends an MTP-Transfer indication 2950 primitive to the upper layer. 2952 The M3UA message distribution function (see Section 1.4.2.1) determines 2953 the Application Server (AS) based on comparing the information in the 2954 MTP-Transfer request primitive with a provisioned Routing Key. 2956 >From the list of ASPs within the AS table, an Active ASP is selected 2957 and a DATA message is constructed and issued on the corresponding SCTP 2958 Association. If more than one ASP is active (i.e., traffic is to be 2959 load-shared across all the active ASPs), one of the active ASPs from 2960 the list is selected. The selection algorithm is implementation 2961 dependent but could, for example, be round-robin or based on, for 2962 example, the SLS or ISUP CIC. The appropriate selection algorithm must 2963 be chosen carefully as it is dependent on application assumptions and 2964 understanding of the degree of state coordination between the active 2965 ASPs in the AS. 2967 In addition, the message needs to be sent on the appropriate SCTP 2968 stream, again taking care to meet the message sequencing needs of the 2969 signalling application. 2971 When there is no Routing Key match, or only a partial match, for an 2972 incoming SS7 message, a default treatment must be specified. Possible 2973 solutions are to provide a default Application Server at the SG that 2974 directs all unallocated traffic to a (set of) default ASP(s), or to 2975 drop the message and provide a notification to management in an M-Error 2976 indication primitive. The treatment of unallocated traffic is 2977 implementation dependent. 2979 4.1.2 Receipt of primitives from the Layer Management 2981 On receiving primitives from the local Layer Management, the M3UA layer 2982 will take the requested action and provide an appropriate response 2983 primitive to Layer Management. 2985 An M-SCTP ESTABLISH request from Layer Management at an ASP or IPSP 2986 will initiate the establishment of an SCTP association. The M3UA layer 2987 will attempt to establish an SCTP association with the remote M3UA peer 2988 at by sending an SCTP-Associate primitive to the local SCTP layer. 2990 When an SCTP association has been successfully established, the SCTP 2991 will send an SCTP-Communication Up notification to the local M3UA 2992 layer. At the SG or IPSP that initiated the request, the M3UA will 2993 send an M-SCTP ESTABLISH confirm to Layer Management when the 2994 association set-up is complete. At the peer M3UA layer, an M-SCTP 2995 ESTABLISH indication is sent to Layer Management upon successful 2996 completion of an incoming SCTP association set-up. 2998 An M-SCTP RELEASE request from Layer Management initates the tear-down 2999 of an SCTP association. M3UA accomplishes a graceful shutdown of the 3000 SCTP association by sending a SHUTDOWN primitive to the SCTP layer. 3002 When the graceful shutdown of the SCTP association has been 3003 accomplished, the SCTP layer returns a SHUTDOWN COMPLETE notification 3004 to the local M3UA Layer. At the M3UA Layer that initiated the request, 3005 the M3UA will send an M-SCTP RELEASE confirm to Layer Management when 3006 the association teardown is complete. At the peer M3UA Layer, an M- 3007 SCTP RELEASE indication is sent to Layer Management upon successful 3008 tear-down of an SCTP association. 3010 An M-SCTP STATUS request supports a Layer Management query of the local 3011 status of a particular SCTP association. The M3UA simply maps the M- 3012 SCTP STATUS request to a STATUS primitive to the SCTP. When the SCTP 3013 responds, the M3UA maps the association status information to an M-SCTP 3014 STATUS confirm. No peer protocol is invoked. 3016 Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-LM mappings can be 3017 described for the various other SCTP Upper layer primitives in RFC2960 3018 such as Initialize, Set Primary, Change Heartbeat, Request Heartbeat, 3019 Get SRTT Report, Set Failure Threshold, Set Protocol parameters, 3020 Destroy SCTP Instance, Send Failure, and Network Status Change. 3021 Alternatively, these SCTP Upper Layer primitives (and Status as well) 3022 can be considered for modeling purposes as a Layer Management 3023 interaction directly with the SCTP Layer. 3025 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 3026 Management the notification or error information contained in a 3027 received M3UA Notify or Error message respectively. These indications 3028 can also be generated based on local M3UA events. 3030 An M-ASP STATUS request supports a Layer Management query of the status 3031 of a particular local or remote ASP. The M3UA responds with the status 3032 in an M-ASP STATUS confirm. No M3UA peer protocol is invoked. 3034 An M-AS STATUS request supports a Layer Management query of the status 3035 of a particular AS. The M3UA responds with an M-AS STATUS confirm. No 3036 M3UA peer protocol is invoked. 3038 M-ASP-UP request, M-ASP-DOWN request, M-ASP-ACTIVE request and M-ASP- 3039 INACTIVE request primitives allow Layer Management at an ASP to 3040 initiate state changes. Upon successful completion, a corresponding 3041 confirm is provided by the M3UA to Layer Management. If an invocation 3042 is unsuccessful, an Error indication is provided. 3044 These requests result in outgoing M3UA ASP-UP, ASP-DOWN, ASP-ACTIVE and 3045 ASP-INACTIVE messages to the remote M3UA peer at an SG or IPSP. 3047 4.2 Receipt of M3UA Peer Management messages 3049 Upon successful state changes resulting from reception of M3UA ASP-UP, 3050 ASP-DOWN, ASP-ACTIVE and ASP-INACTIVE messages from a peer M3UA, the 3051 M3UA layer MUST invoke corresponding M-ASP UP, M-ASP DOWN, M-ASP ACTIVE 3052 and M-ASP INACTIVE, M-AS ACTIVE, M-AS INACTIVE, and M-AS DOWN 3053 indications to the local Layer Management. 3055 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 3056 the notification or error information contained in a received M3UA 3057 Notify or Error message. These indications can also be generated based 3058 on local M3UA events. 3060 4.3 Procedures to support the M3UA Management services 3062 These procedures support the M3UA management of SCTP Associations 3063 between SGs and ASPs. 3065 4.3.1 AS and ASP State Maintenance 3067 The M3UA layer on the SG maintains the state of each remote ASP, in 3068 each Application Server that the ASP is configured to receive traffic, 3069 as input to the M3UA message distribution function. Similarly, where 3070 IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP 3071 maintains the state of remote IPSPs. For the purposes of the following 3072 procedures, only the SG/ASP case is described but the SG side of the 3073 procedures also apply to an IPSP sending traffic to an AS consisting of 3074 a set of remote IPSPs. 3076 4.3.1.1 ASP States 3078 The state of each remote ASP, in each AS that it is configured to 3079 operate, is maintained in the M3UA layer in the SG. The state of a 3080 particular ASP in a particular AS changes due to events. The events 3081 include: 3083 * Reception of messages from the peer M3UA layer at the ASP; 3084 * Reception of some messages from the peer M3UA layer at other ASPs 3085 in the AS (e.g., ASPAC Take-over); 3086 * Reception of indications from the SCTP layer; or 3087 * Local Management intervention. 3089 The ASP state transition diagram is shown in Figure 4. The possible 3090 states of an ASP are: 3092 ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the 3093 related SCTP association is down. Initially all ASPs will be in this 3094 state. An ASP in this state should not be sent any M3UA messages. 3096 ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the 3097 related SCTP association is up) but application traffic is stopped. In 3098 this state the ASP can be sent any non-Data M3UA messages. 3100 ASP-ACTIVE: The remote M3UA peer at the ASP is available and 3101 application traffic is active (for a particular Routing Context or set 3102 of Routing Contexts). 3104 ASP-STANDBY: The remote M3UA peer at the ASP is available and ready to 3105 receive application traffic at any time (for a particular Routing 3106 Context or set of Routing Contexts). In this state the ASP can be sent 3107 any non-Data M3UA messages. 3109 Figure 4: ASP State Transition Diagram 3111 +--------------+ 3112 | ASP-ACTIVE | 3113 +----------------------| or | 3114 | Alternate +-------| ASP-STANDBY* | 3115 | ASP | +--------------+ 3116 | Takeover | ^ | 3117 | | ASP | | ASP 3118 | | Active | | Inact 3119 | | | v 3120 | | +--------------+ 3121 | | | | 3122 | +------>| ASP-INACTIVE | 3123 | +--------------+ 3124 | ^ | 3125 ASP Down/ | ASP | | ASP Down / 3126 SCTP CDI | Up | | SCTP CDI 3127 | | v 3128 | +--------------+ 3129 | | | 3130 +--------------------->| ASP-DOWN | 3131 | | 3132 +--------------+ 3134 *Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is 3135 currently receiving Data traffic within the AS. 3137 SCTP CDI: The local SCTP layer's Communication Down Indication to the 3138 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 3139 indication when it detects the loss of connectivity to the ASP's peer 3140 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 3141 notification or COMMUNICATION LOST notification from the SCTP. 3143 4.3.1.2 AS States 3145 The state of the AS is maintained in the M3UA layer on the SG. 3147 The 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. 3158 AS-INACTIVE: The Application Server is available but no application 3159 traffic is active (i.e., one or more related ASPs are in the ASP- 3160 Inactive state, but none in the ASP-Active state). The recovery timer 3161 T(r) is not running or has expired. 3163 AS-ACTIVE: The Application Server is available and application traffic 3164 is active. This state implies that at least one ASP is in the ASP- 3165 ACTIVE state. 3167 AS-PENDING: An active ASP has transitioned to inactive and it was the 3168 last remaining active ASP in the AS (and no STANDBY ASPs are available. 3169 A recovery timer T(r) will be started and all incoming SCN messages 3170 will be queued by the SG. If an ASP becomes active before T(r) expires, 3171 the AS will move to AS-ACTIVE state and all the queued messages will be 3172 sent to the active ASP. 3174 If T(r) expires before an ASP becomes active, the SG stops queuing 3175 messages and discards all previously queued messages. The AS will move 3176 to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise 3177 it will move to AS-DOWN state. 3179 Figure 5: AS State Transition Diagram 3181 +----------+ one ASP trans to ACTIVE +-------------+ 3182 | |---------------------------->| | 3183 | AS-INACT | | AS-ACTIVE | 3184 | |<--- | | 3185 +----------+ \ +-------------+ 3186 ^ | \ Tr Expiry, ^ | 3187 | | \ at least one | | 3188 | | \ ASP in INACT | | 3189 | | \ | | 3190 | | \ | | 3191 | | \ | | 3192 one ASP | | all ASP \ one ASP | | Last ACT ASP 3193 trans | | trans to \ trans to | | trans to 3194 INACT 3195 to INACT| | DOWN -------\ ACTIVE | | or DOWN 3196 | | \ | | 3197 | | \ | | 3198 | | \ | | 3199 | | \ | | 3200 | v \ | v 3201 +----------+ \ +-------------+ 3202 | | --| | 3203 | AS-DOWN | | AS-PENDING | 3204 | | | (queueing) | 3205 | |<----------------------------| | 3206 +----------+ Tr Expiry no ASP +-------------+ 3207 in INACT state 3209 Tr = Recovery Timer 3211 4.3.2 M3UA Management procedures for primitives 3213 Before the establishment of an SCTP association the ASP state at both 3214 the SG and ASP is assumed to be "Down". 3216 Once the SCTP association is established (See Section 4.1.2) and 3217 assuming that the local M3UA-User is ready, the local ASP M3UA 3218 Application Server Process Maintenance (ASPM) function will initiate 3219 the ASPM procedures, using the ASP-Up/-Down/-Active/-Inactive messages 3220 to convey the ASP-state to the SG - see Section 4.3.3. 3222 If the M3UA layer subsequently receives an SCTP-Communication Down 3223 indication from the underlying SCTP layer, it will inform the Layer 3224 Management by invoking the M-SCTP STATUS indication primitive. The 3225 state of the remote ASP will be moved to "Down". At an ASP, the MTP3- 3226 User at an ASP will be informed of the unavailability of any affected 3227 SS7 destinations through the use of MTP-PAUSE primitives. In the case 3228 of SS7 network isolation, the local MTP3-Users may be informed by 3229 implementation-dependent means as there is currently no primitive 3230 defined for conveying this information. 3232 At an ASP, the Layer Management may try to re-establish the SCTP 3233 association using M-SCTP ESTABLISH request primitive. 3235 4.3.3 M3UA Management procedures for peer-to-peer messages 3237 All M3UA MGMT and ASP Maintenance messages are sent on a sequenced 3238 stream to ensure ordering. SCTP stream '0' is used. 3240 4.3.3.1 ASP-Up 3242 After an ASP has successfully established an SCTP association to an SG, 3243 the SG waits for the ASP to send an ASP-Up message, indicating that the 3244 ASP M3UA peer is available. The ASP is always the initiator of the 3245 ASP-Up exchange. This action MAY be initiated at the ASP by an M-ASP 3246 UP request primitive from Layer Management or may be initiated 3247 automatically by an M3UA management function. 3249 When an ASP-Up message is received at an SG and internally the remote 3250 ASP is in the "Down" state and not considered locked-out for local 3251 management reasons, the SG marks the remote ASP as "Inactive" and 3252 informs Layer Management with an M-ASP-Up indication primitive. If the 3253 SG knows, via current configuration data, which Application Servers the 3254 ASP is configured to operate in, it can update the ASP status to 3255 "Inactive" in each AS that it is a member. Alternatively, the SG may 3256 move the ASP into a pool of Inactive ASPs available for future 3257 activation in Application Server(s) denoted in the subsequent ASP- 3258 Active Routing Contexts. The SG responds with an ASP-Up Ack message in 3259 acknowledgement. The SG sends an ASP-Up Ack message in response to a 3260 received ASP-Up message even if the ASP is already marked as "Inactive" 3261 at the SG. 3263 If for any local reason (e.g., management lock-out) the SG cannot 3264 respond with an ASP-Up Ack, the SG responds to an ASP-Up with an ASP- 3265 Down Ack message with Reason "Management Blocking". 3267 At the ASP, the ASP-Up Ack message received is not acknowledged. Layer 3268 Management is informed with an M-ASP UP confirm primitive . 3270 When the ASP sends an ASP-Up message it starts timer T(ack). If the 3271 ASP does not receive a response to an ASP-Up within T(ack), the ASP MAY 3272 restart T(ack) and resend ASP-Up messages until it receives an ASP-Up 3273 Ack message. T(ack) is provisionable, with a default of 2 seconds. 3274 Alternatively, retransmission of ASP-Up messages may be put under 3275 control of Layer Management. In this method, expiry of T(ack) results 3276 in a M-ASP-Up confirmation carrying a negative indication. 3278 The ASP must wait for the ASP-Up Ack message before sending any other 3279 M3UA messages (e.g., ASPAC, REG REQ). If the SG receives any other 3280 M3UA messages before an ASP Up is received, the SG should discard them. 3282 If an ASP-Up is received and internally the remote ASP is in the 3283 "Active" or "Standby" state, an Error ("Unexpected Message) is returned 3284 and the remote ASP state is not changed. 3286 If an ASP-Up is received and internally the remote ASP is already in 3287 the "Inactive" state, and ASP-Up Ack is returned and no action is 3288 taken. 3290 4.3.3.2 ASP-Down 3292 The ASP will send an ASP-Down to an SG when the ASP wishes to be 3293 removed from service in all Application Servers that it is a member and 3294 no longer receive any M3UA traffic or management messages. This action 3295 MAY be initiated at the ASP by an M-ASP DOWN request primitive from 3296 Layer Management or may be initiated automatically by an M3UA 3297 management function. 3299 Whether the ASP is permanently removed from any AS is a function of 3300 configuration management. 3302 The SG marks the ASP as "Down", informs Layer Management with an M-ASP- 3303 Down indication primitive, and returns an ASP-Down Ack message to the 3304 ASP if one of the following events occur: 3306 - an ASP-Down message is received from the ASP, 3307 - another ASPM message is received from the ASP and the SG has 3308 locked out the ASP for management reasons. 3310 The SG sends an ASP-Down Ack message in response to a received ASP-Down 3311 message from the ASP even if the ASP is already marked as "Down" at the 3312 SG. 3314 At the ASP, the ASP-Down Ack message received is not acknowledged. 3315 Layer Management is informed with an M-ASP Down confirm primitive. 3317 When the ASP sends an ASP-Down it starts timer T(ack). If the ASP does 3318 not receive a response to an ASP-Down within T(ack), the ASP MAY 3319 restart T(ack) and resend ASP-Down messages until it receives an ASP- 3320 Down Ack message. T(ack) is provisionable, with a default of 2 3321 seconds. Alternatively, retransmission of ASP-Down messages may be put 3322 under control of Layer Management. In this method, expiry of T(ack) 3323 results in a M-ASP-Down confirmation carrying a negative indication. 3325 4.3.3.3 M3UA Version Control 3327 If an ASP-Up message with an unsupported version is received, the 3328 receiving end responds with an Error message, indicating the version 3329 the receiving node supports and notifies Layer Management. 3331 This is useful when protocol version upgrades are being performed in a 3332 network. A node upgraded to a newer version should support the older 3333 versions used on other nodes it is communicating with. Because ASPs 3334 initiate the ASP-Up procedure it is assumed that the Error message 3335 would normally come from the SG. 3337 4.3.3.4 ASP-Active 3339 Anytime after the ASP has received an ASP-Up Ack from the SG or IPSP, 3340 the ASP sends an ASP-Active (ASPAC) to the SG indicating that the ASP 3341 is ready to start processing traffic. This action MAY be initiated at 3342 the ASP by an M-ASP Active request primitive from Layer Management or 3343 may be initiated automatically by an M3UA management function. In the 3344 case where an ASP wishes to process the traffic for more than one 3345 Application Server across a common SCTP association, the ASPAC contains 3346 a list of one or more Routing Contexts to indicate for which 3347 Application Servers the ASPAC applies. It is not necessary for the ASP 3348 to include all Routing Contexts of interest in the initial ASPAC 3349 message, thus becoming active in all Routing Contexts at the same time. 3350 Multiple ASPAC messages MAY be used to activate within the Application 3351 Servers independently. In the case where an ASP-Active message does 3352 not contain a Routing Context parameter, the receiver must know, via 3353 configuration data, which Application Server(s) the ASP is a member. 3355 When an ASP Active (ASPAC) message is received, the SG or IPSP responds 3356 with an ASPAC Ack message(with the same Type value contained in the 3357 received APAC), acknowledging that the ASPAC was received and, 3358 depending on the ASPAC Type value, moves the ASP to the "Active" or 3359 "Standby" state within the associated Application Server(s). Layer 3360 Management is informed with an ASP-Active indication primitive. If the 3361 SG or IPSP receives any Data messages before an ASPAC is received, the 3362 SG or IPSP should discard them. By sending an ASPAC Ack, the SG or 3363 IPSP is now ready to receive and send traffic for the related Routing 3364 Contexts. The ASP MUST not send Data messages before receiving an 3365 ASPAC Ack. 3367 Multiple ASPAC Ack messages MAY be used in response to an ASPAC 3368 containing multiple Routing Contexts, allowing the SG or IPSP to 3369 independently Ack for different (sets of) Routing Contexts. The SG or 3370 IPSP sends an Error ("Invalid Routing Context") message for each 3371 invalid or un-configured Routing Context value in a received ASPAC 3372 message. 3374 The SG MUST send an ASP-Active Ack message in response to a received 3375 ASP-Active message from the ASP and the ASP is already marked as 3376 "Active" at the SG. 3378 At the ASP, the ASP-Active Ack message received is not acknowledged. 3379 Layer Management is informed with an M-ASP Active confirm primitive. 3381 When the ASP sends an ASP-Active it starts timer T(ack). If the ASP 3382 does not receive a response to an ASP-Active within T(ack), the ASP MAY 3383 restart T(ack) and resend ASP-Active messages until it receives an ASP- 3384 Active Ack message. T(ack) is provisionable, with a default of 2 3385 seconds. Alternatively, retransmission of ASP-Active messages may be 3386 put under control of Layer Management. In this method, expiry of 3387 T(ack) results in a M-ASP-Active confirmation carrying a negative 3388 indication. 3390 There are four modes of Application Server traffic handling in the SG 3391 M3UA - Over-ride, Over-ride (Standby), Loadshare and Load-share 3392 (Standby). The Traffic Mode Type parameter in the ASPAC message 3393 indicates the traffic handling mode used in a particular Application 3394 Server. If the SG determines that the mode indicated in an ASPAC is 3395 unsupported or incompatible with the mode currently configured for the 3396 AS, the SG responds with an Error message indicating "Unsupported / 3397 Invalid Traffic Handling Mode". If the Traffic Handling mode of the 3398 Application Server is not already known via configuration data, then 3399 the Traffic handling mode indicated in the first ASPAC message causing 3400 the transition of the Application Server state to "Active" MAY be used 3401 to set the mode. 3403 In the case of an Over-ride mode AS, reception of an ASPAC message at 3404 an SG causes the redirection of all traffic for the AS to the ASP that 3405 sent the ASPAC. Any previously active ASP in the AS is now considered 3406 Inactive and will no longer receive traffic from the SG within the AS. 3407 The SG or IPSP sends a Notify (Alternate ASP-Active) to the previously 3408 active ASP in the AS, after stopping all traffic to that ASP. 3410 In the case of Over-ride (Standby) mode the traffic is not started to 3411 the ASP until the previously active ASP transitions to "Inactive or 3412 "Down" state. At this point the ASP that sent the Over-Ride (Standby) 3413 ASPAC is moved to the Active state and the traffic is redirected. A 3414 second ASP-Active Ack message with a new Traffic Mode Type ("Over- 3415 ride", previously "Over-ride(Standby)") is sent to the ASP. A Notify 3416 (Alternate ASP-Active) message is not sent in this case. 3418 In the case of a Load-share mode AS, reception of an ASPAC message at 3419 an SG or IPSP causes the direction of traffic to the ASP sending the 3420 ASPAC, in addition to all the other ASPs that are currently active in 3421 the AS. The algorithm at the SG for load-sharing traffic within an AS 3422 to all the active ASPs is implementation dependent. The algorithm 3423 could, for example be round-robin or based on information in the Data 3424 message (e.g., such as the SLS, SCCP SSN, ISUP CIC value). 3426 An SG or IPSP, upon reception of an ASPAC for the first ASP in a 3427 Loadshare AS, MAY choose not to direct traffic to a newly active ASP 3428 until it determines that there are sufficient resources to handle the 3429 expected load (e.g., until there are sufficient ASPs "Active" in the 3430 AS). 3432 In the case of Load-share (Standby) mode, the traffic is not started to 3433 the ASP until the SG or IPSP determines that there are insufficient 3434 resources available in the AS. This is likely when one of the active 3435 load-sharing ASPs transitions to the "Inactive" or "Down" state. At 3436 this point the ASP that sent the Load-share (Standby) ASPAC is moved to 3437 the Active state and traffic is started. A second ASP-Active Ack 3438 message with a new Traffic Mode Type ("Load-share" - previously 3439 "Loadshare(Standby)") is sent to the ASP. A Notify ("Insufficient ASP 3440 resources active in AS ") message is not sent in this case. 3442 All ASPs within a load-sharing mode AS must be able to handle any 3443 traffic within the AS, in order to accommodate any potential fail-over 3444 or rebalancing of the offered load. 3446 4.3.3.5 ASP Inactive 3448 When an ASP wishes to withdraw from receiving traffic within an AS, the 3449 ASP sends an ASP Inactive (ASPIA) to the SG or IPSP. This action MAY 3450 be initiated at the ASP by an M-ASP INACTIVE request primitive from 3451 Layer Management or may be initiated automatically by an M3UA 3452 management function. In the case where an ASP is processing the 3453 traffic for more than one Application Server across a common SCTP 3454 association, the ASPIA contains one or more Routing Contexts to 3455 indicate for which Application Servers the ASPIA applies. In the case 3456 where an ASP-Inactive message does not contain a Routing Context 3457 parameter, the receiver must know, via configuration data, which 3458 Application Servers the ASP is a member and move the ASP to the 3459 "Inactive" state in each AS. 3461 In the case of an Over-ride mode AS, where another ASP has already 3462 taken over the traffic within the AS with an Over-ride ASPAC, the ASP 3463 that sends the ASPIA is already considered by the SG to be "Inactive". 3464 An ASPIA Ack message is sent to the ASP, after ensuring that all 3465 traffic is stopped to the ASP. 3467 In the case of a Load-share mode AS, the SG moves the ASP to the 3468 "Inactive" state and the AS traffic is re-allocated across the 3469 remaining "active" ASPs per the load-sharing algorithm currently used 3470 within the AS. A NTFY(Insufficient ASP resources active in AS) may be 3471 sent to all inactive ASPs, if required. However, if a Loadshare 3472 (Standby) ASP is available, it may be now immediately included in the 3473 loadshare group and a Notify message is not sent. An ASPIA Ack message 3474 is sent to the ASP after all traffic is halted and Layer Management is 3475 informed with an ASP-INACTIVE indication primitive. 3477 Multiple ASPIA Ack messages MAY be used in response to an ASPIA 3478 containing multiple Routing Contexts, allowing the SG or IPSP to 3479 independently Ack for different (sets of) Routing Contexts. The SG or 3480 IPSP sends an Error ("Invalid Routing Context") message for each 3481 invalid or un-configured Routing Context value in a received ASPIA 3482 message. 3484 The SG MUST send an ASP-Inactive Ack message in response to a received 3485 ASP-Inactive message from the ASP and the ASP is already marked as 3486 "Inactive" at the SG. 3488 At the ASP, the ASP-INACTIVE Ack message received is not acknowledged. 3489 Layer Management is informed with an M-ASP INACTIVE confirm primitive. 3490 When the ASP sends an ASP-Inactive it starts timer T(ack). If the ASP 3491 does not receive a response to an ASP-Inactive within T(ack), the ASP 3492 MAY restart T(ack) and resend ASP-Inactive messages until it receives 3493 an ASP-Inactive Ack message. T(ack) is provisionable, with a default 3494 of 2 seconds. Alternatively, retransmission of ASP-Inactive messages 3495 may be put under control of Layer Management. In this method, expiry 3496 of T(ack) results in a M-ASP-Inactive confirmation carrying a negative 3497 indication. 3499 If no other ASPs are "Active" or "Standby" in the Application Server, 3500 the SG sends a NTFY(AS-Pending) to all inactive ASPs of the AS and 3501 either discards all incoming messages for the AS or starts buffering 3502 the incoming messages for T(r)seconds, after which messages will be 3503 discarded. T(r) is configurable by the network operator. If the SG 3504 receives an ASPAC from an ASP in the AS before expiry of T(r), the 3505 buffered traffic is directed to the ASP and the timer is cancelled. If 3506 T(r) expires, the AS is moved to the "Inactive" state. 3508 4.3.3.6 Notify 3510 A Notify message reflecting a change in the AS state is sent to all 3511 ASPs in the AS, except those in the "Down" state, with appropriate 3512 Status Identification. At the ASP, Layer Management is informed with 3513 an M-NOTIFY indication primitive. 3515 In the case where a Notify (AS-Pending) message is sent by an SG that 3516 now has no ASPs active to service the traffic, or a NTFY(Insufficient 3517 ASP resources active in AS) is sent in the Loadshare mode, the Notify 3518 does not explicitly compel the ASP(s) receiving the message to become 3519 active. The ASPs remain in control of what (and when) traffic action is 3520 taken. 3522 4.3.3.7 Heartbeat 3524 The optional Heartbeat procedures may be used when operating over 3525 transport layers that do not have their own heartbeat mechanism for 3526 detecting loss of the transport association (i.e., other than the 3527 SCTP). 3529 After receiving an ASP-Up Ack message from an M3UA peer in response to 3530 an ASP-Up message, an ASP may optionally send Beat messages 3531 periodically, subject to a provisionable timer T(beat). Upon receiving 3532 a BEAT message, the M3UA peer MUST respond with a BEAT ACK message. If 3533 no BEAT ACK message (or any other M3UA message), is received by the ASP 3534 within the timer 2*T(beat), the ASP will consider the remote M3UA peer 3535 as "Down". 3537 At the ASP, if no BEAT ACK message (or any other M3UA message) is 3538 received from the M3UA peer within 2*T(beat), the remote M3UA peer is 3539 considered unavailable. Transmission of BEAT messages is stopped and 3540 ASP-Up procedures are used to re-establish communication with the SG 3541 M3UA peer. 3543 The BEAT message may optionally contain an opaque Heartbeat Data 3544 parameter that MUST be echoed back unchanged in the related Beat Ack 3545 message. The ASP upon examining the contents of the returned BEAT Ack 3546 message MAY choose to consider the remote ASP as unavailable. The 3547 contents/format of the Heartbeat Data parameter is implementation- 3548 dependent and only of local interest to the original sender. The 3549 contents may be used, for example, to support a Heartbeat sequence 3550 algorithm (to detect missing Heartbeats), and/or a timestamp mechanism 3551 (to evaluate delays). 3553 Note: Heartbeat related events are not shown in Figure 4 "ASP state 3554 transition diagram". 3556 4.3.4 Routing Key Management procedures 3558 4.3.4.1 Registration 3560 An ASP MAY dynamically register with an SG as an ASP within an 3561 Application Server using the REG REQ message. A Routing Key parameter 3562 in the REG REQ specifies the parameters associated with the Routing 3563 Key. 3565 The SG examines the contents of the received Routing Key parameter and 3566 compares it with the currently provisioned Routing Keys. If the 3567 received Routing Key matches an existing SG Routing Key entry, and the 3568 ASP is not currently included in the list of ASPs for the related 3569 Application Server, the ASP MAY authorize the ASP to be added to the 3570 AS. Or, if the Routing Key does not currently exist and the received 3571 Routing Key data is valid and unique, an SG supporting dynamic 3572 configuration MAY authorize the creation of a new Routing Key and 3573 related Application Server and add the ASP to the new AS. In either 3574 case, the SG returns a Registration Response message to the ASP, 3575 containing the same Local-RK-Identifier as provided in the initial 3576 request, and a Registration Result "Successfully Registered". A unique 3577 Routing Context value assigned to the SG Routing Key is included. The 3578 method of Routing Context value assignment at the SG/SGP is 3579 implementation dependent but must be guaranteed to be unique across all 3580 SGPs in an SG. 3582 If the SG determines that the received Routing Key data is invalid, or 3583 contains invalid parameter values, the SG returns a Registration 3584 Response message to the ASP, containing a Registration Result "Error - 3585 Invalid Routing Key", "Error - Invalid DPC, "Error - Invalid Network 3586 Appearance" as appropriate. 3588 If the SG determines that the Routing Key parameter overlaps with an 3589 existing Routing Key entry, the SG returns a Registration Response 3590 message to the ASP, with a Registration Status of "Error - Overlapping 3591 (Non-Unique) Routing Key". An incoming signalling message received at 3592 an SG cannot match against more than one Routing Key. 3594 If the SG does not authorize the registration request, the SG returns a 3595 REG RSP message to the ASP containing the Registration Result "Error � 3596 Permission Denied". 3598 If an SG determines that a received Routing Key does not currently 3599 exist and the SG does not support dynamic configuration, the SG returns 3600 a Registration Response message to the ASP, containing a Registration 3601 Result "Error - Routing Key not Provisioned". 3603 If an SG determines that a received Routing Key does not currently 3604 exist and the SG supports dynamic configuration but does not have the 3605 capacity to add new Routing Key and Application Server entries, the SG 3606 returns a Registration Response message to the ASP, containing a 3607 Registration Result "Error - Insufficient Resources". 3609 An ASP MAY register multiple Routing Keys at once by including a number 3610 of Routing Key parameters in a single REG REQ message. The SG MAY 3611 respond to each registration request in a single REG RSP message, 3612 indicating the success or failure result for each Routing Key in a 3613 separate Registration Result parameter. Alternatively the SG MAY 3614 respond with multiple REG RSP messages, each with one or more 3615 Registration Result parameters. The ASP uses the Local-RK-Identifier 3616 parameter to correlate the requests with the responses. 3618 Upon successful registration of an ASP in an AS, the SG can now send 3619 related SSNM messaging, if this did not previously start upon the ASP 3620 transitioning to "Inactive". 3622 4.3.4.2 Deregistration 3624 An ASP MAY dynamically deregister with an SG as an ASP within an 3625 Application Server using the DEREG REQ message. A Routing Context 3626 parameter in the DEREG REQ specifies which Routing Key to de-register. 3628 The SG examines the contents of the received Routing Context parameter 3629 and validates that the ASP is currently registered in the Application 3630 Server(s) related to the included Routing Context(s). If validated, 3631 the ASP is de-registered as an ASP in the related Application Server. 3633 The deregistration procedure does not necessarily imply the deletion of 3634 Routing Key and Application Server configuration data at the SG. Other 3635 ASPs may continue to be associated with the Application Server, in 3636 which case the Routing Key data CANNOT be deleted. If a Deregistration 3637 results in no more ASPs in an Application Server, an SG MAY delete the 3638 Routing Key data. 3640 The SG acknowledges the de-registration request by returning a DEREG 3641 RSP to the requesting ASP. The result of the de-registration is found 3642 in the Deregistration Result parameter, indicating success or failure 3643 with cause. 3645 An ASP MAY deregister multiple Routing Contexts at once by including a 3646 number of Routing Contexts in a single DEREG REQ message. The SG MUST 3647 respond to each deregistration request in a single DEREG RSP message, 3648 indicating the success or failure result for each Routing Context in a 3649 separate Deregistration Result parameter. 3651 4.4 Procedures to support the M3UA services 3653 4.4.1 At an SG 3655 On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication 3656 primitive from the nodal inter-working function at an SG, the SG M3UA 3657 layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message 3658 (see Section 2) to the M3UA peers at concerned ASPs. The M3UA layer 3659 must fill in various fields of the SSNM messages consistently with the 3660 information received in the primitives. 3662 The SG M3UA determines the set of concerned ASPs to be informed based 3663 on the SS7 network partition for which the primitive indication is 3664 relevant. In this way, all ASPs configured to send/receive traffic 3665 within a particular network appearance are informed. If the SG 3666 operates within a single SS7 network appearance, then all ASPs are 3667 informed. 3669 Optionally, the SG M3UA may filter further based on the Affected Point 3670 Code in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives. 3671 In this way ASPs can be informed only of affected destinations to which 3672 they actually communicate. The SG M3UA may also suppress DUPU messages 3673 to ASPs that do not implement an MTP3-User protocol peer for the 3674 affected MTP3-User. 3676 DUNA, DAVA, SCON messages must be sent on a sequenced stream as these 3677 primitives should arrive in order. Stream 0 is used. Sequencing is 3678 not required for the DUPU or DAUD message, which may optionally be sent 3679 un-sequenced. The same applies for the SCON message if the 3680 international congestion method (see Q.704) is used. 3682 4.4.2 At an ASP 3684 4.4.2.1 Single SG configurations 3686 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 3687 the M3UA layer invokes the appropriate primitive indications to the 3688 resident M3UA-Users. Local management is informed. 3690 In the case where a local event has caused the unavailability or 3691 congestion status of SS7 destinations, the M3UA at the ASP should pass 3692 up appropriate indications n the primitives to the M3UA User, as though 3693 equivalent SSNM messages were received. For example, the loss of an 3694 SCTP association to an SG may cause the unavailability of a set of SS7 3695 destinations. MTP-Pause indications to the M3UA User is appropriate. 3696 To accomplish this, the M3UA layer at an ASP maintains the status of 3697 routes via the SG, much like an MTP3 layer maintains route-set status. 3699 4.4.2.2 Multiple SG configurations 3701 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 3702 the M3UA layer updates the status of the affected route(s) via the 3703 originating SG and determines, whether or not the overall availability 3704 or congestion status of the effected destination(s) has changed. In 3705 this case the M3UA layer invokes the appropriate primitive indications 3706 to the resident M3UA-Users. Local management is informed. 3708 4.4.3 ASP Auditing 3710 An ASP may optionally initiate an audit procedure in order to enquire 3711 of an SG the availability and, if the congestion method with multiple 3712 congestion levels and message priorities is used, congestion status of 3713 an SS7 destination or set of destinations. A Destination Audit (DAUD) 3714 message is sent from the ASP to the SG requesting the current 3715 availability and congestion status of one or more SS7 Destination Point 3716 Codes. 3718 The DAUD may be sent un-sequenced. The DAUD may be sent by the ASP in 3719 the following cases: 3721 - Periodic. A Timer originally set upon reception of DUNA or SCON 3722 message has expired without a subsequent DAVA, DUNA or SCON 3723 updating the availability/congestion status of the affected 3725 Destination Point Codes. The Timer is reset upon issuing a DAUD. 3726 In this case the DAUD is sent to the SG that originally sent the 3727 SSNM message. 3729 - the ASP is newly "Inactive" or "Active" or has been isolated from 3730 an SG for an extended period. The ASP can request the 3731 availability/congestion status of one or more SS7 destinations to 3732 which it expects to communicate. 3734 In the first case, the DAUD procedure must not be invoked for the case 3735 of received SCON containing a congestion level value of "no 3736 congestion" or undefined" (i.e., congestion Level = "0"). This is 3737 because the value indicates either congestion abatement or that the ITU 3738 MTP3 international congestion method is being used. In the 3739 international congestion method, the MTP3 at the SG MTP3 does not 3740 maintain the congestion status of any destinations and therefore the SG 3741 cannot provide any congestion information in response to the DAUD. For 3742 the same reason, in the second case a DAUD cannot reveal any congested 3743 destination(s). 3745 The SG MUST respond to a DAUD with the MTP3 status of the routeset 3746 associated with each Destination Point Code(s) in the DAUD. The status 3747 of each SS7 destination requested is indicated in a DUNA (if 3748 unavailable), DAVA (if available/uncongested) or an SCON (if 3749 available/congested). Optionally, any DUNA or DAVA message in response 3750 to a DAUD may contain a list of up to sixteen Affected Point Codes. 3751 Note that from the point of view of an ASP sending an DAUD, the 3752 subsequent reception of an SCON implies that the Affected Destination 3753 is available. The reception of a DAVA implies that the routeset to the 3754 Affected Destination is not congested. Obviously with the reception of 3755 an DUNA, the routeset to the Affected Destination can not also be 3756 congested. 3758 5.0 Examples of M3UA Procedures 3760 5.1 Establishment of Association and Traffic between SGs and ASPs 3762 5.1.1a Single ASP in an Application Server ("1+0" sparing), No 3763 Registration 3765 This scenario shows the example M3UA message flows for the 3766 establishment of traffic between an SG and an ASP, where only one ASP 3767 is configured within an AS (no backup). It is assumed that the SCTP 3768 association is already set-up. The sending of DUNA/SCON messages by the 3769 SG is not shown but would be similar to 5.1.2. 3771 SG ASP1 3772 | | 3773 |<-------------ASP Up------------| 3774 |-----------ASP-Up Ack---------->| 3775 | | 3776 |<------- ASP Active(RCn)--------| RC: Routing Context 3777 |-----ASP Active Ack (RCn)------>| (optional) 3778 | | 3780 Note: If ASPAC contains an optional Routing Context parameter, The 3781 ASPAC only applies for the specified RC value. For an unknown RC value, 3782 the SG responds with an Error message. 3784 5.1.1b Single ASP in Application Server ("1+0" sparing), With Dynamic 3785 Registration 3787 This scenario is the same as for 5.1.1a but with the optional exchange 3788 of registration information. In this case the Registration is accepted 3789 by the SG. 3791 SG ASP1 3792 | | 3793 |<------------ASP Up-------------| 3794 |----------ASP-Up Ack----------->| 3795 | | 3796 |<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing 3797 | | Context 3798 |----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key 3799 | | RC: Routing Context 3800 | | 3801 |<------- ASP Active(RCn)--------| 3802 |-----ASP Active Ack (RCn)------>| 3803 | | 3805 Note: In the case of an unsuccessful registration attempt (e.g., 3806 Invalid RKn), the Register Response will contain an unsuccessful 3807 indication and the ASP will not subsequently send an ASPAC. 3809 5.1.1c Single ASP in multiple Application Servers (each with "1+0" 3810 sparing), With Dynamic Registration (Case 1 � Multiple Registration 3811 Requests) 3813 SG ASP1 3814 | | 3815 |<------------ASP Up-------------| 3816 |----------ASP-Up Ack----------->| 3817 | | 3818 |<----REGISTER REQ(LRC1,RK1)-----| LRC: Local Routing 3819 | | Context 3820 |----REGISTER RESP(LRC1,RC1)---->| RK: Routing Key 3821 | | RC: Routing Context 3822 | | 3823 |<------- ASP Active(RC1)--------| 3824 |-----ASP Active Ack (RC1)------>| 3825 | | 3826 : : 3827 : : 3828 | | 3829 |<----REGISTER REQ(LRCn,RKn)-----| 3830 | | 3831 |----REGISTER RESP(LRCn,RCn)---->| 3832 | | 3833 | | 3834 |<------- ASP Active(RCn)--------| 3835 |-----ASP Active Ack (RCn)------>| 3836 | | 3838 Note: In the case of an unsuccessful registration attempt (e.g., 3839 Invalid RKn), the Register Response will contain an unsuccessful 3840 indication and the ASP will not subsequently send an ASPAC. Each LRC/RK 3841 pair registration is considered independently. 3843 It is not necessary to follow a Registration Request/Response with an 3844 ASP Active before sending the next Registration Request. The ASP Active 3845 can happen any time after the related successful Registration. 3847 5.1.1.d Single ASP in multiple Application Servers (each with "1+0" 3848 sparing), With Dynamic Registration (Case 2 � Single Registration 3849 Request) 3851 SG ASP1 3852 | | 3853 |<------------ASP Up-------------| 3854 |----------ASP-Up Ack----------->| 3855 | | 3856 |<---REGISTER REQ({LRC1,RK1},----| 3857 | ..., | 3858 | {LRCn,RKn}),----| 3859 | | 3860 |---REGISTER RESP({LRC1,RC1},--->| 3861 | ..., | 3862 | (LRCn,RCn}) | 3863 | | 3864 |<------- ASP Active(RC1)--------| 3865 |-----ASP Active Ack (RC1)------>| 3866 | | 3867 : : 3868 : : 3869 | | 3870 |<------- ASP Active(RCn)--------| 3871 |-----ASP Active Ack (RCn)------>| 3872 | | 3874 Note: In the case of an unsuccessful registration attempt (e.g., 3875 Invalid RKn), the Register Response will contain an unsuccessful 3876 indication and the ASP will not subsequently send an ASPAC. Each LRC/RK 3877 pair registration is considered independently. 3879 The ASP Active can happen any time after the related successful 3880 Registration, and may have more than one RC. 3882 5.1.2 Two ASPs in Application Server ("1+1" sparing) 3884 This scenario shows the example M3UA message flows for the 3885 establishment of traffic between an SG and two ASPs in the same 3886 Application Server, where ASP1 is configured to be "active" and ASP2 a 3887 "standby" in the event of communication failure or the withdrawal from 3888 service of ASP1. ASP2 may act as a hot, warm, or cold standby 3889 depending on the extent to which ASP1 and ASP2 share call/transaction 3890 state or can communicate call state under failure/withdrawal events. 3891 The example message flow is the same whether the ASP-Active messages 3892 are Over-ride or Load-share mode although typically this example would 3893 use an Over-ride mode. In the case of MTP Restart, the SG starts 3894 sending any relevant DUNA and SCON messages to the ASPs as soon as they 3895 enter the ASP-INACTIVE state. The ASP-Active Ack message is only sent 3896 after all relevant DUNA/SCON messages have been transmitted to the 3897 concerned ASP. 3899 SG ASP1 ASP2 3900 | | | 3901 |<--------ASP Up----------| | 3902 |-------ASP-Up Ack------->| | 3903 | | | 3904 |<-----------------------------ASP Up----------------| 3905 |-----------------------------ASP-Up Ack------------>| 3906 | | | 3907 | | | 3908 |<-------ASP Active-------| | 3909 |------ASP-Active Ack---->| | 3910 | | | 3912 5.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing 3913 case) 3915 This scenario shows a similar case to Section 4.1.2 but where the two 3916 ASPs are brought to "active" and load-share the traffic load. In this 3917 case, one ASP is sufficient to handle the total traffic load. The 3918 sending of DUNA/SCON messages by the SG is not shown but would be 3919 similar to 5.1.2. 3921 SG ASP1 ASP2 3922 | | | 3923 |<---------ASP Up---------| | 3924 |--------ASP-Up Ack------>| | 3925 | | | 3926 |<------------------------------ASP Up---------------| 3927 |-----------------------------ASP Up Ack------------>| 3928 | | | 3929 | | | 3930 |<--ASP Active (Ldshr)----| | 3931 |-----ASP-Active Ack----->| | 3932 | | | 3933 |<----------------------------ASP Active (Ldshr)-----| 3934 |-------------------------------ASP-Active Ack------>| 3935 | | | 3937 5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 3938 case) 3940 This scenario shows the example M3UA message flows for the 3941 establishment of traffic between an SG and three ASPs in the same 3942 Application Server, where two of the ASPs are brought to "active" and 3943 share the load. In this case, a minimum of two ASPs are required to 3944 handle the total traffic load (2+1 sparing). The sending of DUNA/SCON 3945 messages by the SG is not shown but would be similar to 5.1.2. 3947 SG ASP1 ASP2 ASP3 3948 | | | | 3949 |<------ASP Up-------| | | 3950 |-----ASP-Up Ack---->| | | 3951 | | | | 3952 |<--------------------------ASP Up-------| | 3953 |-------------------------ASP-Up Ack)--->| | 3954 | | | | 3955 |<---------------------------------------------ASP Up--------| 3956 |---------------------------------------------ASP-Up Ack---->| 3957 | | | | 3958 | | | | 3959 |<--ASP Act (Ldshr)--| | | 3960 |----ASP-Act Ack---->| | | 3961 | | | | 3962 |<--------------------ASP Act. (Ldshr)---| | 3963 |-----------------------ASP-Act Ack----->| | 3964 | | | | 3966 5.2 ASP Traffic Fail-over Examples 3968 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 3970 Following on from the example in Section 5.1.2, and ASP1 withdraws from 3971 service: 3973 SG ASP1 ASP2 3974 | | | 3975 |<-----ASP Inactive-------| | 3976 |----ASP Inactive Ack---->| | 3977 |------------------------NTFY(AS-Pending)----------->| 3978 | | | 3979 |<------------------------------ ASP Active----------| 3980 |------------------------------ASP-Active Ack)------>| 3981 | | 3983 Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or 3984 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 3985 exchange would not occur. 3987 5.2.2 (1+1 Sparing, Back-up Over-ride) 3989 Following on from the example in Section 5.1.2, and ASP2 wishes to 3990 over-ride ASP1 and take over the traffic: 3992 SG ASP1 ASP2 3993 | | | 3994 |<------------------------------ ASP Active----------| 3995 |-------------------------------ASP-Active Ack------>| 3996 |----NTFY(Alt ASP-Act)--->| 3997 | | | 3999 5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) 4001 Following on from the example in Section 5.1.4, and ASP1 withdraws from 4002 service: 4004 SG ASP1 ASP2 ASP3 4005 | | | | 4006 |<----ASP Inact.-----| | | 4007 |---ASP-Inact Ack--->| | | 4008 | | | | 4009 |---------------------------------NTFY(Ins. ASPs)----------->| 4010 | | | | 4011 |<-----------------------------------------ASP Act (Ldshr)---| 4012 |-------------------------------------------ASP Act (Ack)--->| 4013 | | | | 4015 For the Notify to occur the SG maintains knowledge of the minimum ASP 4016 resources required - for example if the SG knows that "n+k" = "2+1" for 4017 a load-share AS and "n" currently equals "1". 4019 Note: If the SG detects loss of the ASP1 M3UA peer (M3UA heartbeat loss 4020 or detection of SCTP failure), the first SG-ASP1 ASP Inactive message 4021 exchange would not occur. 4023 5.3 M3UA/MTP3-User Boundary Examples 4025 5.3.1 At an ASP 4027 This section describes the primitive mapping from the MTP3 User to M3UA 4028 at an ASP. 4030 5.3.1.1 Support for MTP-Transfer on the ASP 4032 5.3.1.1.1 Support for MTP-Transfer Request 4033 When the MTP3-User on the ASP has data to send into the SS7 network, it 4034 will use the MTP-Transfer Request primitive. The M3UA on the ASP will 4035 do the following when it receives an MTP-Transfer Request primitive 4036 from the M3UA user: 4038 - Determine the correct SG 4040 - Determine the correct association to the chosen SG 4042 - Determine the correct stream in the association (e.g., based on 4043 SLS) 4045 - Determine whether to complete the optional fields of the Data 4046 message 4048 - Map the MTP-Transfer Request primitive into the Protocol Data 4049 field of an m3ua Data message 4051 - Send the Data message to the remote M3UA peer in the SG, over the 4052 SCTP association 4054 SG ASP 4055 | | 4056 |<-----Data Message-------|<--MTP-Transfer req. 4057 | | 4059 5.3.1.1.2 Support for MTP Transfer Indication 4061 When the M3UA on the ASP has received Data messages from the remote 4062 M3UA peer in the SG it will do the following: 4064 - Evaluate the optional fields of the Data message if present 4066 - Map the Payload of a Data message into the MTP-Transfer Indication 4067 primitive 4069 - Pass the MTP-Transfer Indication primitive to the user part. In 4070 case of multiple user parts, the optional fields of the Data 4071 message are used to determine the concerned user part. 4073 SG ASP 4074 | | 4075 |------Data Message------>|-->MTP-Transfer ind. 4076 | | 4078 5.3.1.1.3 Support for ASP Querying of SS7 Destination States 4080 There are situations such as temporary loss of connectivity to the SG 4081 that may cause the M3UA on the ASP to audit SS7 destination 4082 availability states. Note: there is no primitive for the MTP3-User to 4083 request this audit from the M3UA as this is initiated by an internal 4084 M3UA management function. 4086 The M3UA on the ASP normally sends Destination State Audit (DAUD) 4087 messages for each of the destinations that the ASP supports. 4089 SG ASP 4090 | | 4091 |<-----DAUD Message ------| 4092 |<-----DAUD Message ------| 4093 |<-----DAUD Message ------| 4094 | | 4095 | | 4097 5.3.2 At an SG 4099 This section describes the MTP3 upper layer primitive mapping to the 4100 M3UA at the SG. 4102 5.3.2.1 Support for MTP-Transfer Request at the SG 4104 When the M3UA on the SG has received Data messages from its peer 4105 destined to the SS7 network it will do the following: 4107 - Evaluate the optional fields of the Data message if present to 4108 determine the network appearance 4110 - Map the Protocol data of the Data message into an MTP-Transfer 4111 Request primitive 4113 - Pass the MTP-Transfer Request primitive to the MTP3 of the 4114 concerned network appearance. 4116 SG ASP 4117 | | 4118 <---MTP-Transfer req.|<------Data Message------| 4119 | | 4121 5.3.2.2 Support for MTP-Transfer Indication at the SG 4123 When the MTP3 on the SG has data to pass its user parts, it will use 4124 the MTP-Transfer Indication primitive. The M3UA on the SG will do the 4125 following when it receives an MTP-Transfer Indication: 4127 - Determine the correct ASP 4129 - Determine the correct association to the chosen ASP 4131 - Determine the correct stream in the association (e.g., based on 4132 SLS) 4134 - Determine whether to complete the optional fields of the Data 4135 message 4137 - Map the MTP-Transfer Indication primitive into the Protocol Data 4138 field of an M3UA Data message 4140 - Send the Data message to the remote M3UA peer in the ASP, over the 4141 SCTP association 4143 SG ASP 4144 | | 4145 --MTP-Transfer ind.->|------Data Message------>| 4146 | | 4148 5.3.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS 4150 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the 4151 MTP3 upper layer interface at the SG need to be made available to the 4152 remote MTP3 User Part lower layer interface at the concerned ASP(s). 4154 5.3.2.3.1 Destination Unavailable 4156 The MTP3 on the SG will generate an MTP-PAUSE primitive when it 4157 determines locally that an SS7 destination is unreachable. The M3UA 4158 will map this primitive to a Destination Unavailable (DUNA) message. 4159 The SG M3UA determines the set of concerned ASPs to be informed based 4160 on internal SS7 network information associated with the MTP-PAUSE 4161 primitive indication. 4163 SG ASP 4164 | | 4165 --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.--> 4166 | | 4168 5.3.2.3.2 Destination Available 4170 The MTP3 on the SG will generate an MTP-RESUME primitive when it 4171 determines locally that an SS7 destination that was previously 4172 unreachable is now reachable. The M3UA will map this primitive to a 4173 Destination Available (DAVA) message. The SG M3UA determines the set 4174 of concerned ASPs to be informed based on internal SS7 network 4175 information associated with the MTP-RESUME primitive indication. 4177 SG ASP 4178 | | 4179 --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.--> 4180 | | 4182 5.3.2.3.3 SS7 Network Congestion 4184 The MTP3 on the SG will generate an MTP-STATUS primitive when it 4185 determines locally that the route to an SS7 destination is congested. 4186 The M3UA will map this primitive to a SS7 Network Congestion State 4187 (SCON) message. It will determine which ASP(s) to send the DUPU to 4188 based on the intended Application Server. 4190 SG ASP 4191 | | 4192 --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.--> 4193 | | 4195 5.3.2.3.4 Destination User Part Unavailable 4197 The MTP3 on the SG will generate an MTP-STATUS primitive when it 4198 receives an UPU message from the SS7 network. The M3UA will map this 4199 primitive to a Destination User Part Unavailable (DUPU) message. It 4200 will determine which ASP(s) to send the DUPU based on the intended 4201 Application Server. 4203 SG ASP 4204 | | 4205 --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.--> 4206 | | 4208 6.0 Security 4210 6.1 Introduction 4212 M3UA is designed to carry signalling messages for telephony services. 4213 As such, M3UA must involve the security needs of several parties: the 4214 end users of the services; the network providers and the applications 4215 involved. Additional requirements may come from local regulation. 4216 While having some overlapping security needs, any security solution 4217 should fulfill all of the different parties' needs. 4219 6.2 Threats 4221 There is no quick fix, one-size-fits-all solution for security. As a 4222 transport protocol, M3UA has the following security objectives: 4224 * Availability of reliable and timely user data transport. 4225 * Integrity of user data transport. 4226 * Confidentiality of user data. 4228 M3UA runs on top of SCTP. SCTP [6] provides certain transport related 4229 security features, such as some protection against: 4231 * Blind Denial of Service Attacks 4232 * Flooding 4233 * Masquerade 4234 * Improper Monopolization of Services 4236 When M3UA is running in professionally managed corporate or service 4237 provider network, it is reasonable to expect that this network includes 4238 an appropriate security policy framework. The "Site Security Handbook" 4239 [21] should be consulted for guidance. 4241 When the network in which M3UA runs in involves more than one party, it 4242 may not be reasonable to expect that all parties have implemented 4243 security in a sufficient manner. In such a case, it is recommended 4244 that IPSEC is used to ensure confidentiality of user payload. Consult 4245 [22] for more information on configuring IPSEC services. 4247 6.3 Protecting Confidentiality 4249 Particularly for mobile users, the requirement for confidentiality may 4250 include the masking of IP addresses and ports. In this case 4251 application level encryption is not sufficient; IPSEC ESP should be 4252 used instead. Regardless of which level performs the encryption, the 4253 IPSEC ISAKMP service should be used for key management. 4255 7.0 IANA Considerations 4257 7.1 SCTP Payload Protocol Identifier 4259 A request will be made to IANA to assign an M3UA value for the Payload 4260 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 4261 Payload Protocol Identifier will be registered: 4263 M3UA "3" 4265 The SCTP Payload Protocol Identifier is included in each SCTP Data 4266 chunk, to indicate which protocol the SCTP is carrying. This Payload 4267 Protocol Identifier is not directly used by SCTP but MAY be used by 4268 certain network entities to identify the type of information being 4269 carried in a Data chunk. 4271 The User Adaptation peer MAY use the Payload Protocol Identifier as a 4272 way of determining additional information about the data being 4273 presented to it by SCTP. 4275 7.2 M3UA Protocol Extensions 4277 This protocol may also be extended through IANA in three ways: 4278 -- through definition of additional message classes, 4279 -- through definition of additional message types, and 4280 -- through definition of additional message parameters 4282 The definition and use of new message classes, types and parameters is 4283 an integral part of SIGTRAN adaptation layers. Thus these extensions 4284 are assigned by IANA through an IETF Consensus action as defined in 4285 [RFC2434]. 4287 The proposed extension must in no way adversely affect the general 4288 working of the protocol. 4290 7.2.1 IETF Defined Message Classes 4292 The documentation for a new message class MUST include the following 4293 information: 4294 (a) A long and short name for the new message class; 4295 (b) A detailed description of the purpose of the message class. 4297 7.2.2 IETF Defined Message Types 4299 The documentation for a new message type MUST include the following 4300 information: 4301 (a) A long and short name for the new message type; 4302 (b) A detailed description of the structure of the message. 4303 (c) A detailed definition and description of intended use for each 4304 field within the message. 4306 (d) A detailed procedural description of the use of the new message 4307 type within the operation of the protocol. 4308 (e) A detailed description of error conditions when receiving this 4309 message type. 4311 When an implementation receives a message type which it does not 4312 support, it MUST respond with an Error (ERR) message, with an Error 4313 Code = Unsupported Message Type. 4315 7.2.3 IETF-defined TLV Parameter extension 4317 Documentation of the message parameter MUST contain the following 4318 information: 4320 (a) Name of the parameter type. 4321 (b) Detailed description of the structure of the parameter field. This 4322 structure MUST conform to the general type-length-value format 4323 described in Section 3.1.5. 4324 (c) Detailed definition of each component of the parameter value. 4325 (d) Detailed description of the intended use of this parameter type, 4326 and an indication of whether and under what circumstances multiple 4327 instances of this parameter type may be found within the same 4328 message. 4330 8.0 Acknowledgements 4332 The authors would like to thank John Loughney, Neil Olson, Michael 4333 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 4334 Prantner, Barry Nagelberg, Naoto Makinae, Selvam Rengasami, Shyamal 4335 Prasad, Joyce Archibald, Ray Singh, Antonio Roque Alvarez and many 4336 others for their valuable comments and suggestions. 4338 9.0 References 4340 [1] RFC 2719, "Framework Architecture for Signaling Transport" 4342 [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) 4343 - ISDN User Part (ISUP)' 4345 [3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part 4347 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 4348 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 4349 international interface; Part 1: Basic services" 4351 [5] ITU-T Recommendations Q.711-715, 'Signalling System No. 7 (SS7) - 4352 Signalling Connection Control Part (SCCP)' 4354 [6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection 4355 Control Part' 4357 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 4358 Signalling System No.7; Signalling Connection Control Part (SCCP) 4359 (connectionless and connection-oriented class 2) to support 4360 international interconnection; Part 1: Protocol specification" 4362 [8] ITU-T Recommendations Q.720, 'Telephone User Part' 4364 [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - 4365 Transaction Capabilities (TCAP) 4367 [10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities 4368 Application Part' 4370 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 4371 Signalling System No.7; Transaction Capabilities (TC) version 2; 4372 Part 1: Protocol specification" 4374 [12] 3G TS 25.410 V3.1.0 (2000-01) Technical Specification - 3rd 4375 Generation partnership Project; Technical Specification Group 4376 Radio Access Network; UTRAN Iu Interface: General Aspects and 4377 Principles (3G TS 25.410 Version 3.1.0 Release 1999) 4379 [13] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, 4380 October 2000. 4382 [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7) 4383 - Message Transfer Part (MTP)' 4385 [15] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' 4387 [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 4388 Signalling System No.7; Message Transfer Part (MTP) to support 4389 international interconnection; Part 1: Protocol specification" 4391 [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service 4392 Specific Coordination Function for signalling at the Network Node 4393 Interface (SSCF at NNI) 4395 [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service 4396 Specific Connection Oriented Protocol (SSCOP) 4398 [19] MTP2-User Adaptation Layer , Nov. 4399 2000, Work in Progress 4401 [20] ITU-T Recommendation Q.2210 'B-ISDN MTP' 4402 [21] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 4404 [22] RFC 2401, "Security Architecture for the Internet Protocol", S. 4405 Kent, R. Atkinson, November 1998. 4407 10.0 Author's Addresses 4409 Greg Sidebottom 4410 Nortel Networks 4411 3685 Richmond Rd, 4412 Nepean, Ontario, Canada K2H 5B7 4413 gregside@nortelnetworks.com 4415 Guy Mousseau 4416 Nortel Networks 4417 3685 Richmond Rd 4418 Nepean, Ontario, Canada K2H 5B7 4420 Lyndon Ong 4421 Point Reyes Networks 4422 1991 Concourse Dr. 4423 San Jose, CA, USA 95131 4424 long@pointreyesnet.com 4426 Ian Rytina 4427 Ericsson Australia 4428 37/360 Elizabeth Street 4429 Melbourne, Victoria 3000, Australia 4430 ian.rytina@ericsson.com 4432 Hanns Juergen Schwarzbauer 4433 SIEMENS AG 4434 Hofmannstr. 51 4435 81359 Munich, Germany 4436 HannsJuergen.Schwarzbauer@icn.siemens.de 4438 Klaus D. Gradischnig 4439 SIEMENS AG 4440 Hofmannstr. 51 4441 81359 Munich, Germany 4442 klaus.gradischnig@icn.siemens.de 4444 Ken Morneault 4445 Cisco Systems Inc. 4446 13615 Dulles Technology Drive 4447 Herndon, VA, USA 20171 4448 EMail: kmorneau@cisco.com 4449 Malleswar Kalla 4450 Telcordia Technologies 4451 MCC 1J211R 4452 445 South Street 4453 Morristown, NJ, USA 07960 4454 Email: kalla@research.telcordia.com 4456 Normand Glaude 4457 Performance Technologies 4458 150 Metcalf Sreet, Suite 1300 4459 Ottawa, Ontario, Canada K2P 1P1 4460 EMail: nglaude@microlegend.com 4462 This draft expires August 2001.