idnits 2.17.1 draft-ietf-sigtran-m3ua-04.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 75 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 1189: '...The keywords MUST, MUST NOT, REQUIRED,...' RFC 2119 keyword, line 1190: '...NOT, RECOMMENDED, NOT RECOMMENDED, MAY...' RFC 2119 keyword, line 1217: '... an M3UA message MUST be transmitted i...' RFC 2119 keyword, line 1335: '... Value fields) MUST be a multiple of...' RFC 2119 keyword, line 1340: '...es. The receiver MUST ignore the paddi...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2909 has weird spacing: '...of received S...' == 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 to the ASP with an ASPAC Ack message, acknowledging that the ASPAC was received and, depending on the ASPAC Type value received, moves the ASP to the "Active" or "Standby" state within the associated Application Server(s). The ASP MUST not send Data messages before receiving an ASPAC Ack. If the SG or IPSP receives any Data messages before an ASPAC is received, the SG or IPSP should discard them. -- 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 (Sept 2000) is 8898 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 1192 ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Sidebottom, L. Ong, Guy Mousseau 2 INTERNET-DRAFT Nortel Networks 3 Ian Rytina 4 Ericsson 5 Hanns-Juergen Schwarzbauer, Klaus Gradischnig 6 Siemens 7 Ken Morneault 8 Cisco 9 Mallesh Kalla 10 Telcordia 11 Normand Glaude 12 Performance Technologies 14 Expires in six months Sept 2000 16 SS7 MTP3-User Adaptation Layer (M3UA) 17 19 Status of This Memo 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of RFC 2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, and 24 its working groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as 'work in progress.' 32 To learn the current status of any Internet-Draft, please check the 33 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 This Internet Draft defines a protocol for supporting the transport of 41 any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP 42 using the services of the Stream Control Transmission Protocol. Also, 43 provision is made for protocol elements that enable a seamless 44 operation of the MTP3-User peers in the SS7 and IP domains. This 45 protocol would be used between a Signalling Gateway (SG) and a Media 46 Gateway Controller (MGC) or IP-resident Database. It is assumed that 47 the SG receives SS7 signalling over a standard SS7 interface using the 48 SS7 Message Transfer Part (MTP) to provide transport. 50 TABLE OF CONTENTS 52 1. Introduction.......................................................3 53 1.1 Scope.........................................................3 54 1.2 Terminology...................................................3 55 1.3 M3UA Overview.................................................5 56 1.4 Functional Areas.............................................10 57 1.5 Sample Configurations........................................18 58 1.6 Definition of M3UA Boundaries................................21 59 2. Conventions.......................................................22 60 3. M3UA Protocol Elements............................................22 61 3.1 Common Message Header........................................22 62 3.2 Variable-Length Parameter Format 63 3.3 Transfer Messages............................................24 64 3.4 SS7 Signalling Network management (SSNM) Messages............26 65 3.5 Application Server Process Maintenance Messages..............32 66 3.6 Management Messages..........................................40 67 4. Procedures........................................................44 68 4.1 Procedures to Support the Services of the M3UA Layer.........44 69 4.2 Procedures to Support the M3UA Services in Section 1.4.2.....44 70 4.3 Procedures to Support the M3UA Services in Section 1.4.4.....45 71 4.4 Procedures to Support the M3UA Services in Section 1.4.3.....52 72 5. Examples of M3UA Procedures.......................................54 73 5.1 Establishment of Association and Traffic 74 Between SGs and ASPs.........................................54 75 5.2 ASP traffic Fail-over Examples...............................56 76 5.3 M3UA/MTP3-User Boundary Examples.............................57 77 6. Security..........................................................61 78 6.1 Introduction.................................................61 79 6.2 Threats......................................................61 80 6.3 Protecting Confidentiality...................................62 81 7. IANA Considerations...............................................62 82 8. Acknowledgements..................................................62 83 9. References........................................................62 84 10. Author's Addresses...............................................65 85 1. Introduction 87 1.1 Scope 89 There is a need for SCN signalling protocol delivery from an SS7 90 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP- 91 resident Database as described in the Framework Architecture for 92 Signalling Transport [1]. The delivery mechanism should meet the 93 following criteria: 95 * Support for the transfer of all SS7 MTP3-User Part messages (e.g., 96 ISUP, SCCP, TUP, etc.) 97 * Support for the seamless operation of MTP3-User protocol peers 98 * Support for the management of SCTP transport associations and 99 traffic between an SG and one or more MGCs or IP-resident Databases 100 * Support for MGC or IP-resident Database process fail-over and load- 101 sharing 102 * Support for the asynchronous reporting of status changes to 103 management 105 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 106 protocol layers and deliver ISUP, SCCP and/or any other MTP3-User 107 protocol messages over SCTP transport associations to MTP3-User peers 108 in MGCs or IP-resident Databases. 110 1.2 Terminology 112 Application Server (AS) - A logical entity serving a specific Routing 113 Key. An example of an Application Server is a virtual switch element 114 handling all call processing for a unique range of PSTN trunks, 115 identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual 116 database element, handling all HLR transactions for a particular SS7 117 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more 118 unique Application Server Processes, of which one or more is normally 119 actively processing traffic. 121 Application Server Process (ASP) - A process instance of an Application 122 Server. An Application Server Process serves as an active or standby 123 process of an Application Server (e.g., part of a distributed virtual 124 switch or database). Examples of ASPs are processes (or process 125 instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- 126 point and may be configured to process signalling traffic within more 127 than one Application Server. 129 Association - An association refers to an SCTP association. The 130 association provides the transport for MTP3-User protocol data units 131 and M3UA adaptation layer peer messages. 133 IP Server Process (IPSP) - A process instance of an IP-based 134 application. An IPSP is essentially the same as an ASP, except that it 135 uses MU3A in a peer-to-peer fashion. Conceptually, an IPSP does not 136 use the services of a signalling gateway. 138 Signalling Gateway Process (SGP) - A process instance of a Signalling 139 Gateway. It serves as an active, standby or load-sharing process of a 140 Signalling Gateway. 142 Signalling Process - A process instance that uses M3UA to communicate 143 with other signalling process. An ASP, a signalling gateway process 144 and an IPSP are all signalling processes. 146 Routing Key: A Routing Key describes a set of SS7 parameter and 147 parameter values that uniquely define the range of signalling traffic 148 to be handled by a particular Application Server. For example, where 149 all traffic directed to an SS7 DPC, OPC and ISUP CIC_range(s) or SCCP 150 SSN is to be sent to a particular Application Server, that SS7 data 151 defines the associated Routing Key. Routing Keys are unique in the 152 sense that a received SS7 signalling message cannot be directed to more 153 than one Routing Key. Also, a Routing Key cannot extend across more 154 than a single SS7 DPC, in order to more easily support SS7 Management 155 procedures. It is not necessary for the parameter range values within 156 a particular Routing Key to be contiguous. For example, an ASP could 157 be configured to support call processing for multiple ranges of PSTN 158 trunks that are not represented by contiguous CIC values. 160 Routing Context - An Application Server Process may be configured to 161 process signalling traffic related to more than one Application Server, 162 over a single SCTP Association. At an ASP, the Routing Context 163 parameter uniquely identifies the range of signalling traffic 164 associated with each Application Server that the ASP is configured to 165 receive. There is a 1:1 relationship between a received Routing 166 Context value and a Routing Key entry at the sending node. Therefore 167 the Routing Context can be viewed as an index into a sending node's 168 Message Distribution Table containing the Routing Key entries. 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-back may apply 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 190 MTP3-User - Any protocol normally using the services of the SS7 MTP3 191 (e.g., ISUP, SCCP, TUP, etc.). 193 Network Appearance - The Network Appearance identifies an SS7 network 194 context for the purposes of logically separating the signalling traffic 195 between the SG and the Application Server Processes over a common SCTP 196 Association. An example is where an SG is logically partitioned to 197 appear as an element in four separate national SS7 networks. A Network 198 Appearance implicitly defines the SS7 Point Code(s), Network Indicator 199 and MTP3 protocol type/variant/version used within a specific SS7 200 network partition. A physical SS7 route-set or link-set at an SG can 201 appear in only one network appearance. The Network Appearance is not 202 globally significant and requires coordination only between the SG and 203 the ASP. Therefore, in the case where an ASP is connected to more than 204 one SG, the same SS7 network context may be identified by different 205 Network Appearances depending over which SG a message is being 206 transmitted/received. 208 Network Byte Order: Most significant byte first, a.k.a Big Endian. 210 Layer Management - Layer Management is a nodal function that handles 211 the inputs and outputs between the M3UA layer and a local management 212 entity. 214 Host - The computing platform that the ASP process is running on. 216 Stream - A stream refers to an SCTP stream; a uni-directional logical 217 channel established from one SCTP endpoint to another associated SCTP 218 endpoint, within which all user messages are delivered in-sequence 219 except for those submitted to the un-ordered delivery service. 221 1.3 M3UA Overview 223 1.3.1 Protocol Architecture. 225 The framework architecture that has been defined for SCN signalling 226 transport over IP [1] uses multiple components, including a common 227 signalling transport protocol and an adaptation module to support the 228 services expected by a particular SCN signalling protocol from its 229 underlying protocol layer. 231 Within the framework architecture, this document defines an MTP3-User 232 adaptation module suitable for supporting the transfer of messages of 233 any protocol layer that is identified to the MTP Level 3 layer, in SS7 234 terms, as a user part. The list of these protocol layers include, but 235 is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection 236 Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP 237 [9,10,11] or RANAP [12] messages are transferred transparently by the 238 M3UA as SCCP payload, as they are SCCP-User protocols. 240 It is recommended that the M3UA use the services of the Stream Control 241 Transmission Protocol (SCTP) [13] as the underlying reliable common 242 signalling transport protocol. This is to take advantage of various 243 SCTP features such as: 245 - Explicit packet-oriented delivery (not stream-oriented); 246 - Sequenced delivery of user messages within multiple streams, 247 with an option for order-of-arrival delivery of individual 248 user messages, 249 - Optional multiplexing of user messages into SCTP datagrams; 250 - Network-level fault tolerance through support of multi-homing 251 at either or both ends of an association; 252 - Resistance to flooding and masquerade attacks; and - Data 253 segmentation to conform to discovered path MTU size. 255 Under certain scenarios, such as back-to-back connections without 256 redundancy requirements, the SCTP functions above may not be necessary. 257 In these cases, it is acceptable to use TCP as the underlying common 258 transport protocol. 260 1.3.2 Services Provided by the M3UA Layer 262 The M3UA Layer at an ASP provides the equivalent set of primitives at 263 its upper layer to the MTP3-Users as provided by the MTP Level 3 to its 264 local users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at 265 an ASP is unaware that the expected MTP3 services are offered remotely 266 from an MTP3 Layer at an SG, and not by a local MTP3 layer. The MTP3 267 layer at an SG may also be unaware that its local users are actually 268 remote user parts over M3UA. In effect, the M3UA extends access to the 269 MTP3 layer services to a remote IP-based application. The M3UA does 270 not itself provide the MTP3 services. In the case where an ASP is 271 connected to more than one SG, however, the M3UA must maintain the 272 status of configured SS7 destinations and route messages according to 273 availability/congestion status of the routes to these destinations. 275 The M3UA Layer may also be used for point-to-point signalling between 276 two IP Server Processes (IPSPs). In this case, the M3UA provides the 277 same set of primitives and services at its upper layer as the MTP3. 278 However, in this case the expected MTP3 services are not offered 279 remotely from an SG. The MTP3 services are provided but the procedures 280 to support these services are a subset of the MTP3 procedures due to 281 the simplified point-to-point nature of the IPSP to IPSP relationship. 283 1.3.2.1 Support for the transport of MTP3-User Messages 285 The M3UA provides the transport of MTP-TRANSFER primitives across an 286 established SCTP association between an SG and an ASP and between 287 IPSPs. 289 The MTP-TRANSFER primitives are encoded as MTP3-User messages with 290 attached MTP3 Routing Labels as described in the message format 291 sections of the SCCP and ISUP recommendations. In this way, the SCCP 292 and ISUP messages received from the SS7 network are not re-encoded into 293 a different format for transport to/from the server processes. As 294 well, all the required MTP3 Routing Label information (OPC, DPC, SIO) 295 is available at the ASP and the IPSP as is expected by the MTP3-User 296 protocol layer. 298 At an ASP, in the case where a destination is reachable via multiple 299 SGs, the M3UA must also choose via which SG the message is to be routed 300 or support load balancing across the SGs, ensuring that no mis- 301 sequencing occurs. 303 The M3UA does not impose a 272-octet user information block limit as 304 specified by the SS7 MTP Level 3 protocol. Larger information blocks 305 can be accommodated directly by M3UA/SCTP, without the need for an 306 upper layer segmentation/re-assembly procedure as specified in recent 307 SCCP or ISUP versions. However, in the context of an SG, the maximum 308 272-octet block size must be followed when inter-working to a SS7 309 network that does not support the transfer of larger information blocks 310 to the final destination. This avoids potential ISUP or SCCP 311 fragmentation requirements at the SG. However, if the SS7 network is 312 provisioned to support the Broadband MTP [20] to the final SS7 313 destination, the information block size limit may be increased past 272 314 octets. 316 1.3.2.2 Native Management Functions 318 The M3UA provides management of the underlying SCTP transport protocol 319 to ensure that SG-ASP and IPSP-IPSP transport is available to the 320 degree called for by the MTP3-User signalling applications. 322 The M3UA provides the capability to indicate errors associated with 323 received M3UA messages and to notify, as appropriate, local management 324 and/or the peer M3UA. 326 1.3.2.3 Inter-working with MTP3 Network Management Functions 328 At the SG, the M3UA must also provide inter-working with MTP3 329 management functions to support seamless operation of the user SCN 330 signalling applications in the SS7 and IP domains. This includes: 332 - Providing an indication to MTP3-Users at an ASP that a remote 333 destination in the SS7 network is not reachable. 335 - Providing an indication to MTP3-Users at an ASP that a remote 336 destination in the SS7 network is now reachable. 338 - Providing an indication to MTP3-Users at an ASP that messages to a 339 remote MTP3-User peer in the SS7 network are experiencing SS7 340 congestion. 342 - Providing an indication to MTP3-Users at an ASP that a remote MTP3- 343 User peer is unavailable. 345 The M3UA layer at an ASP may initiate an audit of the availability or 346 the congested state of remote SS7 destinations. This information is 347 requested from the M3UA at the SG. 349 The M3UA layer at an ASP may also indicate to the SG that the M3UA 350 itself or the ASP or the ASP's host is congested. 352 1.3.2.4 Support for the management of SCTP associations between the SG 353 and ASPs. 355 The M3UA layer at the SG maintains the availability state of all 356 configured remote ASPs, in order to manage the SCTP Associations and 357 the 358 traffic between the SG and ASPs. As well, the active/inactive state of 359 remote ASPs is also maintained - Active ASPs are those currently 360 receiving traffic from the SG. 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 multiple SCTP associations between two IPSPs, one side must be 367 designated to establish the association or the mutual SCTP endpoint 368 addresses must be pre-configured. 370 The M3UA layer may also need to inform local management of the status 371 of the underlying SCTP associations using the M-SCTP STATUS request and 372 indication primitive. For example, the M3UA may inform local management 373 of the reason for the release of an SCTP association, determined either 374 locally within the M3UA layer or by a primitive from the SCTP. 376 Also the M3UA layer may need to inform the local management of the 377 change in status of an ASP or AS. This can be achieved using the M-ASP 378 STATUS or M-AS STATUS primitives. 380 1.3.2.5 Support for the management of connections to multiple SGs 382 As shown in Figure 1 an ASP may be connected to multiple SGs. In such a 383 case a particular SS7 destination may be reachable via more than SG, 384 i.e., via more than one route. As MTP3 users only maintain status on a 385 destination and not on a route basis M3UA must maintain the status 386 (availability and/or congestion of route to destination) of the 387 individual routes, derive the overall status of the destination from 388 the status of the individual routes, and inform the MTP3 users of this 389 derived status whenever it changes. 391 1.3.3 Signalling Network Architecture 393 A Signalling Gateway is used to support the transport of MTP3-User 394 signalling traffic received from the SS7 network to multiple 395 distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA 396 protocol is not designed to meet the performance and reliability 397 requirements for such transport by itself. However, the conjunction of 398 distributed architecture and redundant networks does allow for a 399 sufficiently reliable transport of signalling traffic over IP. The 400 M3UA protocol is flexible enough to allow its operation and management 401 in a variety of physical configurations, enabling Network Operators to 402 meet their performance and reliability requirements. 404 To meet the stringent SS7 signalling reliability and performance 405 requirements for carrier grade networks, Network Operators should 406 ensure that no single point of failure is present in the end-to-end 407 network architecture between an SS7 node and an IP-based application. 408 This can typically be achieved through the use of redundant SGs, 409 redundant hosts, and the provision of redundant QOS-bounded IP network 410 paths for SCTP Associations between SCTP End Points. Obviously, the 411 reliability of the SG, the MGC and other IP-based functional elements 412 also needs to be taken into account. The distribution of ASPs within 413 the available Hosts must also be considered. As an example, for a 414 particular Application Server, the related ASPs should be distributed 415 over at least two Hosts. 417 Here is one example of a physical network architecture relevant to SS7 418 carrier-grade operation, in the IP network domain, shown in Figure 1 419 below: 421 SG MGC 423 Host#1 ************** ************** Host#1 424 = * ********__*__________________________*__******** * = 425 SG1 * * SGP1 *__*_____ _______________*__* ASP1 * * MGC1 426 * ******** * \ / * ******** * 427 * ********__*______\__/________________*__******** * 428 * * SGP2 *__*_______\/______ _____*__* ASP2 * * 429 * ******** * /\ | | * ******** * 430 * : * / \ | | * : * 431 * ******** * / \ | | * ******** * 432 * * SGPn * * | | | | * * ASPn * * 433 * ******** * | | | | * ******** * 434 ************** | | | | ************** 435 | | \ / 436 Host#2 ************** | | \ / ************** Host#2 437 = * ********__*_____| |______\/_______*__******** * = 438 SG2 * * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2 439 * ******** * / \ * ******** * 440 * ********__*_______________/ \_____*__******** * 441 * * SGP2 *__*__________________________*__* ASP2 * * 442 * ******** * * ******** * 443 * : * SCTP Associations * : * 444 * ******** * * ******** * 445 * * SGPn * * * * ASPn * * 446 * ******** * * ******** * 447 ************** ************** 449 Figure 1 - Physical Model 451 In this model, each host has many application processes. In the case 452 of the MGC, an ASP may provide service to one or more application 453 server, and is identified as an SCTP end point. In the case of the SG, 454 a pair of signalling gateway processes may represent, as an example, a 455 single network appearance, serving a signalling point management 456 cluster. 458 This example model can also be applied to IPSP-IPSP signalling. In 459 this case, each IPSP would have its services distributed across 2 hosts 460 or more, and may have multiple server processes on each host. 462 In the example above, each signalling process (SGP, ASP or IPSP) is the 463 end point to more than one SCTP association, leading to many other 464 signalling processes. To support this, a signalling process must be 465 able to support distribution of M3UA messages to many simultaneous 466 active associations. This message distribution function is based on 467 the status of provisioned routing keys, the availability of signalling 468 points in the SS7 network, and the redundancy model (active-standby, 469 load-sharing, n+k) of the remote signalling processes. 471 For carrier grade networks, Operators should ensure that under failure 472 or isolation of a particular signalling process, stable calls or 473 transactions are not lost. This implies that signalling processes 474 need, in some cases, to share the call or transaction state information 475 with other signalling processes. In the case of ASPs performing call 476 processing, coordination may also be required with the related Media 477 Gateway to transfer the MGC control for a particular trunk termination. 478 However, this sharing or communication is outside the scope of this 479 document. 481 This model serves as an example. M3UA imposes no restrictions as to 482 the exact layout of the network elements, the message distribution 483 algorithms and the distribution of the signalling processes. Instead, 484 it provides a framework and a set of messages that allow for a flexible 485 and scalable signalling network architecture, aiming to provide 486 reliability and performance. 488 1.4 Functional Areas 490 1.4.1 Signalling Point Code Representation 492 Within an SS7 network, a Signalling Gateway is charged with 493 representing a set of nodes in the IP domain into the SS7 network for 494 routing purposes. The SG itself, as a physical node in the SS7 495 network, must be addressable with an SS7 Point Code for MTP3 Management 496 purposes. The SG Point Code may also be used for addressing any local 497 MTP3-Users at the SG such as an SG-resident SCCP function. 499 An SG may be logically partitioned to operate in multiple SS7 network 500 Appearances. In such a case, the SG must be addressable with a Point 501 Code in each network appearance, and represents a set of nodes in the 502 IP domain into each SS7 network. Alias PCs may also be used within an 503 SG network appearance. 505 The M3UA places no restrictions on the SS7 Point Code representation of 506 an AS. Application Servers can be represented under the same PC of the 507 SG, their own individual Point Codes or grouped with other applications 508 for Point Code preservation purposes. A single Point Code may be used 509 to represent the SG and all the ASPs together, if desired. 511 Where Application Servers are grouped under a Point Code address, an 512 SPMC will include more than one AS. If full advantage of SS7 management 513 procedures is to be taken (as is advisable in carrier grade networks) 514 care must be taken that, if (the connection to) one AS of an SPMC 515 fails, all AS of the SPMC fail or become unreachable from the SG. If 516 this is not the case, usage of SS7 transfer prohibited procedures by 517 the SG becomes problematic as either traffic to the failed AS cannot be 518 stopped/diverted or traffic to a still available AS will unnecessarily 519 be stopped/diverted. (Depending on the network configuration it may 520 even be necessary to assign an individual SS7 point code to each AS.) 521 Observing these principles is of particular importance if alternative 522 routing possibilities exist on the SS7 level (e.g. via mated SGs) or 523 application level (e.g. via another MGC/MG). 525 If an ASP or group of ASPs is available to the SS7 network via more 526 than one SG, each with its own Point Code, the ASP(s) should be 527 represented by a Point Code that is separate from any SG Point Code. 528 This allows these SGs to be viewed from the SS7 network as "STPs", each 529 having an ongoing "route" to the same ASP(s). Under failure 530 conditions where the ASP(s) become(s) unavailable from one of the SGs, 531 this approach enables MTP3 route management messaging between the SG 532 and SS7 network, allowing simple SS7 re-routing through an alternate SG 533 without changing the Destination Point Code Address of SS7 traffic to 534 the ASP(s). 536 Where an AS can be reached via more than one SG it is equally important 537 that the corresponding Routing Keys in the involved SGs are identical. 538 (Note: It is possible for the Routing Key configuration data to be 539 temporarily out-of-synch during configuration updates). 541 +--------+ 542 | | 543 +------------+ SG 1 +--------------+ 544 +-------+ | SS7 links | "STP" | IP network | ---- 545 | SEP +---+ +--------+ +---/ \ 546 | or | | ASPs | 547 | STP +---+ +--------+ +---\ / 548 +-------+ | | | | ---- 549 +------------+ SG 2 +--------------+ 550 | "STP" | 551 +--------+ 553 Note: there is no SG-to-SG communication shown, so each SG can be 554 reached only via the direct linkset from the SS7 network. 556 The following example shows a signalling gateway partitioned into two 557 network appearances. 559 SG 560 +-------+ +---------------+ 561 | SEP +--------------| SS7 Ntwk |M3UA| ---- 562 +-------+ SS7 links | "A" | | / \ 563 |__________| +-----------+ ASPs | 564 | | | \ / 565 +-------+ | SS7 Ntwk | | ---- 566 | SEP +--------------+ "B" | | 567 +-------+ +---------------+ 569 1.4.2 Message Distribution 571 1.4.2.1 Address Translation and Mapping at the SG 573 In order to direct messages received from the SS7 MTP3 network to the 574 appropriate IP destination, the SG must perform address translation and 575 mapping functions using information from the received MTP3-User 576 message. 578 To support this message distribution, the SG must maintain the 579 equivalent of a network address translation table, mapping incoming SS7 580 message information to an Application Server for a particular 581 application and range of traffic. This is accomplished by comparing 582 elements of the incoming SS7 message to provisioned Routing Keys in the 583 SG. These Routing Keys in turn make reference to an Application Server 584 that is enabled by one or more ASP. These ASPs provide dynamic status 585 information to the SG using various management messages defined in the 586 M3UA protocol. Possible SS7 address/routing information that comprise 587 a Routing Key entry includes, for example, the OPC, DPC, SIO found in 588 the MTP3 routing label, or other MTP3-User specific fields such as the 589 ISUP CIC, SCCP subsystem number, or TCAP transaction ID. Some example 590 routing keys are: the DPC alone, the DPC/OPC combination, the 591 DPC/OPC/CIC combination, or the DPC/SSN combination. The particular 592 information used to define an M3UA Routing Key is application and 593 network dependent, and none of the above examples are mandated. 595 An Application Server contains a list of one or more ASPs that are 596 capable of processing the traffic. This list is assumed to be dynamic, 597 taking into account the availability status of the individual ASPs in 598 the list, configuration changes, and possible fail-over mechanisms. The 599 M3UA protocol includes messages to convey the availability status of 600 the individual ASPs as input to a fail-over mechanism. 602 Normally, one or more ASPs is active in the ASP (i.e., currently 603 processing traffic) but in certain failure and transition cases it is 604 possible that there may not be an active ASP available. Both load- 605 sharing and backup scenarios are supported. 607 When there is no Routing Key match for an incoming SS7 message, a 608 default treatment must be specified. Possible solutions are to provide 609 a default Application Server at the SG that directs all unallocated 610 traffic to a (set of) default ASP(s), or to drop the messages and 611 provide a notification to management. The treatment of unallocated 612 traffic is implementation dependent. 614 1.4.2.2 Address Translation and Mapping at the ASP 616 In order to direct messages to the SS7 network, the ASP must also 617 perform an address translation and mapping function in order to choose 618 the proper SG or SGP for a given message. This is accomplished by 619 observing the Destination Point Code and other elements of the outgoing 620 message, SS7 network status, SG and SGP availability, and network 621 appearance configuration tables. 623 A remote Signalling Gateway may be composed of one or more SGPs that 624 are capable of routing SS7 traffic. As is the case with ASPs, a 625 dynamic list of SGPs in an SG can be maintained, taking into account 626 the availability status of the individual SGPs, configuration changes 627 and fail-over mechanisms. There is, however, no M3UA messaging to 628 manage the status of an SGP. Whenever an SCTP association to an SGP 629 exists, it is assumed to be available. Also, every SGP of one SG 630 communicating with one ASP regarding one AS provides identical SS7 631 connectivity to this ASP. 633 1.4.3 SS7 and M3UA Interworking 635 In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is 636 designed to provide an extension of the MTP3 defined user primitives. 638 1.4.3.1 Signalling Gateway SS7 Layers 640 The SG is responsible for terminating MTP Level 3 of the SS7 protocol, 641 and offering an IP-based extension to its users. 643 >From an SS7 perspective, it is expected that the Signalling Gateway 644 (SG) transmits and receives SS7 Message Signalling Units (MSUs) to and 645 from 646 the PSTN over a standard SS7 network interface, using the SS7 Message 647 Transfer Part (MTP) [14,15,16] to provide reliable transport of the 648 messages. 650 As a standard SS7 network interface, the use of MTP Level 2 signalling 651 links is not the only possibility. ATM-based High Speed Links can also 652 be used with the services of the Signalling ATM Adaptation Layer (SAAL) 653 [17,18]. It is possible for IP-based links to be present, using the 654 services of the MTP2-User Adaptation Layer (M2UA) [19]. These SS7 655 datalinks may be terminated at a Signalling Transfer Point (STP) or at 656 a Signalling End Point (SEP). Using the services of MTP3, the SG may 657 be capable of communicating with remote SS7 SEPs in a quasi-associated 658 fashion, where STPs may be present in the SS7 path between the SEP and 659 the SG. 661 Where ATM-based High Speed Links are used in the SS7 network, it is 662 possible for the SG to use the services of the MTP-3b [20] for reliable 663 transport to and from an SS7 SEP or STP. The maximum Service Data Unit 664 (SDU) supported by the MTP-3b is 4096 octets compared to the 272-octet 665 maximum of the MTP3. However, for MTP3-Users to take advantage of the 666 larger SDU between MTP3-User peers, network architects should ensure 667 that MTP3-b is used end-to-end between the SG and the SS7-resident 668 peer. 670 1.4.3.2 SS7 and M3UA Inter-Working at the SG 672 The SG provides a functional inter-working of transport functions 673 between the SS7 network and the IP network by also supporting the M3UA 674 adaptation layer. It allows the transfer of MTP3-User signalling 675 messages to and from an IP-based Application Server Process where the 676 peer MTP3-User protocol layer exists. 678 The Signalling Gateway must maintain knowledge of SS7 node and 679 Signalling Point Management Cluster (SPMC) status in their respective 680 domains in order to perform a seamless inter-working of the IP-based 681 signalling and the SS7 domains. For example, SG knowledge of the 682 availability and/or congestion status of the SPMC and SS7 nodes must be 683 maintained and disseminated in the respective networks, in order to 684 ensure that end-to-end operation is transparent to the communicating 685 SCN protocol peers at the SS7 node and ASP. 687 When the SG determines that the transport of SS7 messages to an SPMC 688 (or possibly to parts of an SPMC) is encountering congestion, the SG 689 should inform the MTP3 route management function (by an implementation- 690 dependent mechanism). This information is used by the MTP3 to mark the 691 "route" to the affected destination as congested and to trigger MTP 692 Transfer Controlled (TFC) messages to any SS7 SEPs generating traffic 693 to the congested DPC, as per current MTP3 procedures. 695 When the SG determines that the transport of SS7 messages to all ASPs 696 in a particular SPMC is interrupted, then it should similarly inform 697 the MTP3 route management function. This information is used by the 698 MTP3 to mark the "route" to the affected destination as unavailable, 699 and in the case of the SG acting as a signalling transfer point (i.e., 700 the Point Code of the SG is different from that of the SPMC), to send 701 MTP Transfer Prohibited (TFP) messages to the relevant adjacent SS7 702 nodes, according to the local SS7 network procedures. 704 When the SG determines that the transport of SS7 messages to an ASP in 705 a particular SPMC can be resumed, the SG should similarly inform the 706 MTP3 route management function. This information is used by the MTP3 707 to mark the route to the affected destination as available, and in the 708 case of a signalling transfer point, to send MTP Transfer Allowed (TFA) 709 messages to the relevant adjacent SS7 nodes, according to the local SS7 710 network procedures. 712 For SS7 user part management, it is required that the MTP3-User 713 protocols at ASPs receive indications of SS7 signalling point 714 availability, SS7 network congestion, and remote User Part 715 unavailability as would be expected in an SS7 SEP node. To accomplish 716 this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives 717 received at the MTP3 upper layer interface at the SG need to be 718 propagated to the remote MTP3-User lower layer interface at the ASP. 719 (These indication primitives are, of course, also made available to any 720 existing local MTP3-Users at the SG, if present.) 721 It is important to clarify that MTP3 management messages such as TFPs 722 or TFAs received from the SS7 network are not "encapsulated" and sent 723 blindly to the ASPs. Rather, the existing MTP3 management procedures 724 are followed within the MTP3 function of the SG to re-calculate the 725 MTP3 route set status and initiate any required signalling-route-set- 726 test procedures into the SS7 network. Only when an SS7 destination 727 status changes are MTP-PAUSE or MTP-RESUME primitives invoked. These 728 primitives can also be invoked due to local SS7 link set conditions as 729 per existing MTP3 procedures. 731 In case where the MTP in the SG undergoes an MTP restart, event 732 communication to the concerned ASPs should be handled as follows: 734 When the SG discovers SS7 network isolation, the SG sends an indication 735 to all concerned available ASPs (i.e., ASPs in the "active" or 736 "inactive" state), using a DUNA message. For the purposes of MTP 737 Restart, all SPMCs with point codes different from that of the SG with 738 at least one ASP that is active or has sent an ASPAC message to the SG 739 during the first part of the restart procedure should be considered as 740 available. If the M3UA at the SG receives any ASPAC messages during 741 the restart procedure, it delays the ASPAC-ACK messages until the end 742 of the restart procedure. During the second part of the restart 743 procedure the M3UA at the SG informs all concerned ASPs in the "active" 744 or "inactive" state of any unavailable SS7 destinations. At the end of 745 the restart procedure the M3UA sends an ASPAC-ACK message to all ASPs 746 in the "active" state. 748 1.4.3.2 Application Server 750 A cluster of application servers is responsible for providing the 751 overall support for one or more SS7 upper layers. From an SS7 752 standpoint, a Signalling Point Management Cluster (SPMC) provides 753 complete support for the upper layer service for a given point code. 754 As an example, an SPMC providing MGC capabilities must provide complete 755 support for ISUP for a given point code, according to the local SS7 756 network specifications. 758 This measure is necessary to allow the SG to accurately represent the 759 signalling point on the local SS7 network. 761 In the case where an ASP is connected to more than one SG, the M3UA 762 must maintain the status of configured SS7 destinations and route 763 messages according to availability/congestion status of the routes to 764 these destinations. 766 When an ASP enters the "Inactive" state towards an SG the M3UA must 767 mark all SS7 destinations configured to be reachable via this SG as 768 available. 770 When the M3UA at an ASP receives a DUNA message indicating SS7 network 771 isolation at an SG, it will stop any affected traffic via this SG and 772 clear any unavailability state of SS7 destinations via this SG. When 773 the M3UA subsequently receives any DUNA messages from an SG it will 774 mark the effected SS7 destinations as unavailable via that SG. When 775 the M3UA receives an ASPAC-ACK message it can resume traffic to 776 available SS7 destinations via this SG, provided the ASP is in the 777 active state towards this SG. 779 1.4.3.3 IPSP 781 Since IPSPs use M3UA in a point-to-point fashion, there is no concept 782 of routing of messages beyond the remote end. Therefore, SS7 and M3UA 783 inter-working is not necessary for this model. 785 1.4.4 Redundancy Models 787 The network address translation and mapping function of the M3UA layer 788 supports signalling process fail-over functions in order to support a 789 high availability of call and transaction processing capability. 791 1.4.4.1 Application Server Redundancy 793 All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG from the 794 SS7 network are assigned to a unique Application Server, based on the 795 information in the message and the provisioned Routing Keys. 797 The Application Server is, in practical terms, a list of all ASPs 798 configured to process a range of MTP3-User traffic defined by one 799 Routing Key. One or more ASPs in the list are normally active (i.e., 800 handling traffic) while any others may be unavailable or inactive, to 801 be possibly used in the event of failure or unavailability of the 802 active ASP(s). 804 The fail-over model supports an "n+k" redundancy model, where "n" ASPs 805 is the minimum number of redundant ASPs required to handle traffic and 806 "k" ASPs are available to take over for a failed or unavailable ASP. A 807 "1+1" active/standby redundancy is a subset of this model. A simplex 808 "1+0" model is also supported as a subset, with no ASP redundancy. 810 At the SG, an Application Server list contains active and inactive ASPs 811 to support ASP load-sharing and fail-over procedures. The list of ASPs 812 within a logical Application Server is kept updated in the SG to 813 reflect the active Application Server Process(es). 815 To avoid a single point of failure, it is recommended that a minimum of 816 two ASPs be in the list, resident in separate hosts, and therefore 817 available over different SCTP Associations. For example, in the 818 network shown in Figure 1, all messages to DPC x could be sent to ASP1 819 in Host1 or ASP1 in Host2. The AS list at SG1 might look like this: 821 Routing Key {DPC=x) - "Application Server #1" 822 ASP1/Host1 - State=Up, Active 823 ASP1/Host2 - State=Up, Inactive 825 In this "1+1" redundancy case, ASP1 in Host1 would be sent any incoming 826 message with DPC=x. ASP1 in Host2 would normally be brought to the 827 active state upon failure of, or loss of connectivity to, ASP1/Host1. 828 In this example, both ASPs are Up, meaning that the related SCTP 829 association and far-end M3UA peer is ready. 831 The AS List at SG1 might also be set up in load-share mode: 833 Routing Key {DPC=x) - "Application Server #1" 834 ASP1/Host1 - State = Up, Active 835 ASP1/Host2 - State = Up, Active 837 In this case, both the ASPs would be sent a portion of the traffic. 838 For example the two ASPs could together form a database, where incoming 839 queries may be sent to any active ASP. 841 Care must be exercised by a Network Operator in the selection of the 842 routing information to be used as the Routing Key for a particular AS. 843 For example, where Application Servers are defined using ranges of ISUP 844 CIC values, the Operator is implicitly splitting up control of the 845 related circuit groups. Some CIC value range assignments may interfere 846 with ISUP circuit group management procedures. 848 In the process of fail-over or fail-back, it is recommended that in the 849 case of ASPs supporting call processing, stable calls do not fail. It 850 is possible that calls in "transition" may fail, although measures of 851 communication between the ASPs involved can be used to mitigate this. 852 For example, the two ASPs may share call state via shared memory, or 853 may use an ASP to ASP protocol to pass call state information. 855 1.4.4.2 Signalling Gateway Redundancy 857 Signalling Gateways may also be distributed over multiple hosts. Much 858 like the AS model, SGs may be comprised of one or more SG Processes 859 (SGPs), distributed over one or more hosts, using an active/standby or 860 a load-sharing model. An SGP is viewed as a remote SCTP end-point from 861 an ASP perspective. There is, however, no M3UA protocol to manage the 862 status of an SGP. Whenever an SCTP association to an SGP exists, the 863 SGP is assumed to be available. Also, every SGP within an SG 864 communicating with an ASP provides identical SS7 connectivity to this 865 ASP. Should an SGP lose all or partial SS7 connectivity and other SGPs 866 exist, the SGP must terminate the SCTP associations to the concerned 867 ASPs. 869 It is therefore possible for an ASP to route signalling messages 870 destined to the SS7 network using more than one SGP. In this model, a 871 Signalling Gateway is deployed as a cluster of hosts acting as a single 872 SG. A primary/back-up redundancy model is possible, where the 873 unavailability of the SCTP association to a primary SGP could be used 874 to reroute affected traffic to an alternate SGP. A load-sharing model 875 is possible, where the signalling messages are load-shared between 876 multiple SGPs. 878 It may also be possible for an ASP to use more than one SG to access a 879 specific SS7 end point, in a model that resembles an SS7 STP mated 880 pair. Typically, SS7 STPs are deployed in mated pairs, with traffic 881 load-shared between them. Other models are also possible, subject to 882 the limitations of the local SS7 network provisioning guidelines. 884 >From the perspective of the M3UA at an ASP, a particular SG is capable 885 of transferring traffic to an SS7 destination if an SCTP association 886 with at least one SGP of the SG is established, the SGP has received an 887 indication from the ASP M3UA that the ASP is actively handling traffic 888 for that destination, and the SG has not indicated that the destination 889 is inaccessible. When an ASP is configured to use multiple SGs for 890 transferring traffic to the SS7 network, the ASP must maintain 891 knowledge of the current capability of the SGs to handle traffic to 892 destinations of interest. This information is crucial to the overall 893 reliability of the service, for both active/standby and load-sharing 894 model, in the event of failures, recovery and maintenance activities. 895 The ASP M3UA may also use this information for congestion avoidance 896 purposes. 898 1.4.5 Flow Control 899 Local Management at an ASP may wish to stop traffic across an SCTP 900 association in order to temporarily remove the association from service 901 or to perform testing and maintenance activity. The function could 902 optionally be used to control the start of traffic on to a newly 903 available SCTP association. 905 1.4.6 Congestion Management 907 The M3UA Layer is informed of local and IP network congestion by means 908 of an implementation-dependent function (e.g., an implementation- 909 dependent indication from the SCTP of IP network congestion). When an 910 SG determines that the transport of SS7 messages to a Signalling Point 911 Management Cluster (SPMC) is encountering congestion, the SG should 912 trigger SS7 MTP3 Transfer Controlled management messages to originating 913 SS7 nodes. The triggering of SS7 MTP3 Management messages from an SG is 914 an implementation-dependent function. 916 At an ASP, congestion is indicated to local MTP3-Users by means of an 917 MTP-Status primitive indicating congestion, to invoke appropriate upper 918 layer responses, as per current MTP3 procedures. 920 The M3UA should indicate local ASP congestion to the SG with an SCON 921 message. When an SG receives an SCON message from an ASP it should 922 trigger SS7 MTP3 Transfer Controlled management messages to concerned 923 SS7 destinations according to established MTP procedures. 925 1.4.7 SCTP Stream Mapping. 927 The M3UA at both the SG and ASP also supports the assignment of 928 signalling traffic into streams within an SCTP association. Traffic 929 that requires sequencing must be assigned to the same stream. To 930 accomplish this, MTP3-User traffic may be assigned to individual 931 streams based on, for example, the SLS value in the MTP3 Routing Label 932 or the ISUP CIC assignment, subject of course to the maximum number of 933 streams supported by the underlying SCTP association. 935 The use of SCTP streams within M3UA is recommended in order to minimize 936 transmission and buffering delays, therefore improving the overall 937 performance and reliability of the signalling elements. The 938 distribution of the MTP3 user messages over the various streams should 939 be done in such a way to minimize message mis-sequencing, as required 940 by the SS7 User Parts. 942 1.4.8 Client/Server Model 944 The SG takes on the role of server while the ASP is the client. ASPs 945 must initiate the SCTP association to the SG. 947 In the case of IPSP to IPSP communication, one side can be designated 948 as the initiator of the SCTP association and M3UA messaging. 950 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M3UA 951 is 2905. 953 1.5 Sample Configurations 955 1.5.1 Example 1: ISUP message transport 957 ******** SS7 ***************** IP ******** 958 * SEP *---------* SG *--------* ASP * 959 ******** ***************** ******** 961 +------+ +------+ 962 | ISUP | (NIF) | ISUP | 963 +------+ +------+-+------+ +------+ 964 | MTP3 | | MTP3 | | M3UA | | M3UA | 965 +------| +------+ +------+ +------+ 966 | MTP2 | | MTP2 | | SCTP | | SCTP | 967 +------+ +------+ +------+ +------+ 968 | L1 | | L1 | | IP | | IP | 969 +------+ +------+ +------+ +------+ 970 |_______________| |______________| 972 SEP - SS7 Signalling End Point 973 SCTP - Stream Control Transmission Protocol 974 NIF - Nodal Inter-working Function 976 In this example, the SG provides an implementation-dependent nodal 977 inter-working function (NIF) that allows the MGC to exchange SS7 978 signalling messages with the SS7-based SEP. The NIF within the SG 979 serves as the interface within the SG between the MTP3 and M3UA. This 980 nodal inter-working function has no visible peer protocol with either 981 the MGC or SEP. It also provides network status information to one or 982 both sides of the network. 984 For internal SG modeling purposes, at the NIF level, SS7 signalling 985 messages that are destined to the MGC are received as MTP-TRANSFER 986 indication primitives from the MTP Level 3 upper layer interface and 987 are sent to the local M3UA-resident message distribution function for 988 ongoing routing to the final IP destination. MTP-TRANSFER primitives 989 received from the local M3UA network address translation and mapping 990 function are sent to the MTP Level 3 upper layer interface as MTP- 991 TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 992 SEP. For the purposes of providing SS7 network status information the 993 NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 994 primitives received from the MTP Level 3 upper layer interface to the 995 local M3UA-resident management function. 997 1.5.2 Example 2: SCCP Transport between IPSPs 999 ******** IP ******** 1000 * IPSP * * IPSP * 1001 ******** ******** 1003 +------+ +------+ 1004 |SCCP- | |SCCP- | 1005 | User | | User | 1006 +------+ +------+ 1007 | SCCP | | SCCP | 1008 +------+ +------+ 1009 | M3UA | | M3UA | 1010 +------+ +------+ 1011 | SCTP | | SCTP | 1012 +------+ +------+ 1013 | IP | | IP | 1014 +------+ +------+ 1015 |________________| 1017 This example shows an architecture where no Signalling Gateway is used. 1018 In this example, SCCP messages are exchanged directly between two IP- 1019 resident IPSPs with resident SCCP-User protocol instances, such as 1020 RANAP or TCAP. SS7 network inter-working is not required, therefore 1021 there is no MTP3 network management status information for the SCCP and 1022 SCCP-User protocols to consider. Any MTP-PAUSE, -RESUME or -STATUS 1023 indications from the M3UA to the SCCP should consider only the status 1024 of the SCTP Association and underlying IP network. 1026 1.5.3 Example 3: SG resident SCCP layer, with remote ASP 1028 ******** SS7 ***************** IP ******** 1029 * SEP *---------* *--------* * 1030 * or * * SG * * ASP * 1031 * STP * * * * * 1032 ******** ***************** ******** 1034 +------+ +---------------+ +------+ 1035 | SCCP-| | SCCP | | SCCP-| 1036 | User | +---------------+ | User | 1037 +------+ | _____ | +------+ 1038 | SCCP | | | | | | SCCP | 1039 +------+ +------+-+------+ +------+ 1040 | MTP3 | | MTP3 | | M3UA | | M3UA | 1041 +------| +------+ +------+ +------+ 1042 | MTP2 | | MTP2 | | SCTP | | SCTP | 1043 +------+ +------+ +------+ +------+ 1044 | L1 | | L1 | | IP | | IP | 1045 +------+ +------+ +------+ +------+ 1046 |_______________| |______________| 1048 STP - SS7 Signalling Transfer Point 1050 In this example, the SG contains an instance of the SS7 SCCP protocol 1051 layer that may, for example, perform the SCCP Global Title Translation 1052 (GTT) function for messages logically addressed to the SG SCCP. If the 1053 result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN 1054 address result of an SCCP peer located in the IP domain, the resulting 1055 MTP-TRANSFER request primitive is sent to the local M3UA-resident 1056 network address translation and mapping function for ongoing routing to 1057 the final IP destination. 1059 Similarly, the SCCP instance in an SG can perform the SCCP GTT service 1060 for messages logically addressed to it from SCCP peers in the IP 1061 domain. In this case, MTP-TRANSFER messages are sent from the local 1062 M3UA-resident network address translation and mapping function to the 1063 SCCP for GTT. If the result of the GTT yields the address of an SCCP 1064 peer in the SS7 network then the resulting MTP-TRANSFER request is 1065 given to the MTP3 for delivery to an SS7-resident node. 1067 It is possible that the above SCCP GTT at the SG could yield the 1068 address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER 1069 primitive would be sent back to the M3UA for delivery to an IP 1070 destination. 1072 For internal SG modeling purposes, this may be accomplished with the 1073 use of an implementation-dependent nodal inter-working function within 1074 the SG that effectively sits below the SCCP and routes MTP-TRANSFER 1075 messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or 1076 DPC/SSN 1077 address information. This nodal inter-working function has no visible 1078 peer protocol with either the ASP or SEP. 1080 Note that the services and interface provided by the M3UA are the same 1081 as in Example 1 and the functions taking place in the SCCP entity are 1082 transparent to M3UA. The SCCP protocol functions are not reproduced in 1083 the M3UA protocol. 1085 1.6 Definition of M3UA Boundaries 1087 1.6.1 Definition of the boundary between M3UA and an MTP3-User. 1089 >From ITU Q.701 [14]: 1091 MTP-TRANSFER request 1092 MTP-TRANSFER indication 1093 MTP-PAUSE indication 1094 MTP-RESUME indication 1095 MTP-STATUS indication 1097 1.6.2 Definition of the boundary between M3UA and SCTP 1099 The upper layer primitives provided by the SCTP are provided in [13] 1101 1.6.3 Definition of the Boundary between M3UA and Layer Management 1103 M-SCTP ESTABLISH request 1104 Direction: LM -> M3UA 1105 Purpose: LM requests ASP to establish an SCTP association with an SG 1106 or IPSP. 1108 M-STCP ESTABLISH confirm 1109 Direction: M3UA -> LM 1110 Purpose: ASP confirms to LM that it has established an SCTP 1111 association with an SG or IPSP. 1113 M-SCTP ESTABLISH indication 1114 Direction: M3UA -> LM 1115 Purpose: SG or IPSP informs LM that an ASP has established an SCTP 1116 association. 1118 M-SCTP RELEASE request 1119 Direction: LM -> M3UA 1120 Purpose: LM requests ASP to release an SCTP association with SG or 1121 IPSP. 1123 M-SCTP RELEASE confirm 1124 Direction: M3UA -> LM 1125 Purpose: ASP confirms to LM that it has released SCTP association 1126 with SG. 1128 M-SCTP RELEASE indication 1129 Direction: M3UA -> LM 1130 Purpose: SG or IPSP informs LM that ASP has released an SCTP 1131 association. 1133 M-SCTP STATUS request 1134 Direction: LM -> M3UA 1135 Purpose: LM requests M3UA to report status of SCTP association. 1137 M-SCTP STATUS indication 1138 Direction: M3UA -> LM 1139 Purpose: M3UA reports status of SCTP association. 1141 M-ASP STATUS request 1142 Direction: LM -> M3UA 1143 Purpose: LM requests SG or IPSP to report status of remote ASP. 1145 M-ASP STATUS indication 1146 Direction: M3UA -> LM 1147 Purpose: SG or IPSP reports status of remote ASP. 1149 M-AS-STATUS request 1150 Direction: LM -> M3UA 1151 Purpose: LM requests SG or IPSP to report status of AS. 1153 M-AS-STATUS indication 1154 Direction: M3UA -> LM 1155 Purpose: SG or IPSP reports status of AS. 1157 M-NOTIFY indication 1158 Direction: M3UA -> LM 1159 Purpose: ASP reports that it has received a NOTIFY message 1160 from its peer. 1162 M-ERROR indication 1163 Direction: M3UA -> LM 1164 Purpose: ASP, SG or IPSP reports that it has received an ERROR 1165 message from its peer. 1167 M-ASP-DOWN request 1168 Direction: LM -> M3UA 1169 Purpose: LM requests ASP to stop its operation and send an ASP-DOWN 1170 message to the SG. 1172 M-ASP-UP request 1173 Direction: LM -> M3UA 1174 Purpose: LM requests ASP to start its operation and send an ASP-UP 1175 message to the SG. 1177 M-ASP-INACTIVE request 1178 Direction: LM -> M3UA 1179 Purpose: LM requests ASP to stop data transfer and send an ASP- 1180 Inactive message to the SG. 1182 M-ASP-ACTIVE request 1183 Direction: LM -> M3UA 1184 Purpose: LM requests ASP to start data transfer and send an ASP- 1185 Active message to the SG. 1187 2.0 Conventions 1189 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 1190 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 1191 in this document, are to be interpreted as described in [RFC2119]. 1193 3.0 M3UA Protocol Elements 1195 The general M3UA message format includes a Common Message Header 1196 followed by zero or more parameters as defined by the Message Type. 1197 For forward compatibility, all Message Types may have attached 1198 parameters even if none are specified in this version. 1200 3.1 Common Message Header 1202 The protocol messages for MTP3-User Adaptation require a message 1203 structure that contains a version, message type, message length, and 1204 message contents. This message header is common among all signalling 1205 protocol adaptation layers: 1207 0 1 2 3 1208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Version | Reserved | Message Class | Message Type | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Message Length | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 \ \ 1215 / / 1217 All fields in an M3UA message MUST be transmitted in the network byte 1218 order, unless otherwise stated. 1220 M3UA Protocol Version: 8 bits (unsigned integer) 1222 The version field contains the version of the M3UA adaptation layer. 1223 The supported versions are: 1225 1 Release 1.0 1227 Message Class: 8 bits (unsigned integer) 1229 The following list contains the Message Type Classes for the defined 1230 messages. 1232 0 Management (MGMT) Message 1233 1 Transfer Messages 1234 2 SS7 Signalling Network Management (SSNM) Messages 1235 3 ASP State Maintenance (ASPSM) Messages 1236 4 ASP Traffic Maintenance (ASPTM) Messages 1237 5 to 255 Reserved 1239 Message Type: 8 bits (unsigned integer) 1241 The following list contains the message types for the defined 1242 messages. 1244 Management (MGMT) Message 1246 0 Error (ERR) 1247 1 Notify (NTFY) 1248 2 to 255 Reserved for Management Messages 1250 Transfer Messages 1252 0 Reserved 1253 1 Payload Data (DATA) 1254 2 to 255 Reserved for Transfer Messages 1256 SS7 Signalling Network Management (SSNM) Messages 1258 0 Reserved 1259 1 Destination Unavailable (DUNA) 1260 2 Destination Available (DAVA) 1261 3 Destination State Audit (DAUD) 1262 4 SS7 Network Congestion State (SCON) 1263 5 Destination User Part Unavailable (DUPU) 1264 6 to 255 Reserved for SSNM Messages 1266 ASP State Maintenance (ASPSM) Messages 1268 0 Reserved 1269 1 ASP Up (UP) 1270 2 ASP Down (DOWN) 1271 3 Heartbeat (BEAT) 1272 4 ASP Up Ack (UP ACK) 1273 5 ASP Down Ack (DOWN ACK) 1274 6 Heatbeat Ack (BEAT ACK) 1276 7 to 255 Reserved for ASPSM Messages 1278 ASP Traffic Maintenance (ASPTM) Messages 1280 0 Reserved 1281 1 ASP Active (ACTIVE) 1282 2 ASP Inactive (INACTIVE) 1283 3 ASP Active Ack (ACTIVE ACK) 1284 4 ASP Inactive Ack (INACTIVE ACK) 1285 5 to 255 Reserved for ASPTM Messages 1287 Reserved: 8 bits 1289 Should be set to all '0's and ignored by the receiver. 1291 Message Length: 32-bits (unsigned integer) 1293 The Message Length defines the length of the message in octets, 1294 including the header. 1296 3.2 Variable-Length Parameter Format 1298 M3UA messages consist of a Common Header followed by zero or more 1299 parameters, as defined by the message type. The variable-length 1300 parameters contained in a message are defined in a Tag-Length-Value 1301 format as shown below. 1303 0 1 2 3 1304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Parameter Tag | Parameter Length | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 \ \ 1309 / Parameter Value / 1310 \ \ 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 Parameter Tag: 16 bits (unsigned integer) 1315 Tag field is a 16-bit identifier of the type of parameter. It takes 1316 a value of 0 to 65534. 1318 The value of 65535 is reserved for IETF-defined extensions. Values 1319 other than those defined in specific parameter description are 1320 reserved for use by the IETF. 1322 Parameter Length: 16 bits (unsigned integer) 1324 The Parameter Length field contains the size of the parameter in 1325 bytes, including the Parameter Tag, Parameter Length, and Parameter 1326 Value fields. The Parameter Length does not include any padding 1327 bytes. 1329 Parameter Value: variable-length. 1331 The Parameter Value field contains the actual information to be 1332 transferred in the parameter. 1334 The total length of a parameter (including Tag, Parameter Length and 1335 Value fields) MUST be a multiple of 4 bytes. If the length of the 1336 parameter is not a multiple of 4 bytes, the sender pads the 1337 Parameter at the end (i.e., after the Parameter Value field) with 1338 all zero bytes. The length of the padding is NOT included in the 1339 parameter length field. A sender should NEVER pad with more than 3 1340 bytes. The receiver MUST ignore the padding bytes. 1342 3.3 Transfer Messages 1344 The following section describes the Transfer messages and parameter 1345 contents. 1347 3.3.1 Payload Data Message (DATA) 1349 The Data message contains the SS7 MTP3-User protocol data, which is an 1350 MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 1351 Data message contains the following variable length parameters: 1353 Network Appearance Optional 1354 Protocol Data Mandatory 1356 The following format MUST be used for the Data Message: 1358 0 1 2 3 1359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Tag = 1 | Length = 8 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Network Appearance* | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Tag = 3 | Length | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 \ \ 1368 / Protocol Data / 1369 \ \ 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 Network Appearance: 32-bits (unsigned integer) 1374 The optional Network Appearance parameter identifies the SS7 network 1375 context for the message, for the purposes of logically separating 1376 the signalling traffic between the SG and the Application Server 1377 Process over a common SCTP Association. An example is where an SG 1378 is logically partitioned to appear as an element in four different 1379 national SS7 networks. 1381 In a Data message, the Network Appearance implicitly defines the SS7 1382 Point Code format used, the SS7 Network Indicator value, and the 1383 MTP3/MTP3-User protocol type/variant/version used within the SS7 1384 network partition. Where an SG operates in the context of a single 1385 SS7 network, or individual SCTP associations are dedicated to each 1386 SS7 network context, or the Network Indicator in the SIO of the MTP- 1387 Transfer primitive is sufficient, the Network Appearance parameter 1388 is not required. 1390 The Network Appearance parameter value is of local significance 1391 only, coordinated between the SG and ASP. 1393 Where the optional Network Appearance parameter is present, it must 1394 be the first parameter in the message as it defines the format of 1395 the Protocol Data field. 1397 Protocol Data: variable length 1399 The Protocol Data field contains the SS7 MTP3-User application 1400 message, including the complete Routing Label. The Protocol Data 1401 parameter contains the following fields: 1403 Service Information Octet. Includes: 1404 Service Indicator, 1405 Network Indicator, 1406 and Spare/Priority codes 1408 MTP Routing Label. Includes: 1409 Destination Point Code, 1410 Originating Point Code, 1411 And Signalling Link Selection Code (SLS) 1413 User Protocol Data. Includes MTP3-User protocol elements: 1414 ISUP, SCCP, or TUP parameters 1416 The format is as defined in the relevant MTP standards for the SS7 1417 protocol being transported. The format is either implicitly known 1418 or identified by the Network Appearance parameter. 1420 For the ANSI protocol example, the Protocol Data field format is 1421 shown below: 1423 0 1 2 3 1424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | SIO | DPC Network | DPC Cluster | DPC Member | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | OPC Network | OPC Cluster | OPC Member | SLS | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 \ \ 1431 / Protocol Data / 1432 \ \ 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 |MSB---------------------------------------------------------LSB| 1437 For the ITU international protocol example, the Protocol Data field 1438 is shown below. 1440 0 1 2 3 1441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | SIO | DPC | DPC | DPC | OPC | OPC | 1444 | |Zone | Region | SP |Zone | Region | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 |*| OPC | SLS | | 1447 |*| SP | | | 1448 +-+-+-+-+-+-+-+-+ + 1449 \ \ 1450 / Protocol Data / 1451 \ \ 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 |MSB---------------------------------------------------------LSB| 1456 * LSB of OPC Region 1458 3.4 SS7 Signalling Network Management (SSNM) Messages 1460 3.4.1 Destination Unavailable (DUNA) 1462 The DUNA message is sent from the SG to all concerned ASPs to indicate 1463 that the SG has determined that one or more SS7 destinations are 1464 unreachable. It is also sent in response to a message from the ASP to 1465 an unreachable SS7 destination. The MTP3-User at the ASP is expected 1466 to stop traffic to the affected destination through the SG initiating 1467 the DUNA as per the defined MTP3-User procedures. 1469 The DUNA message contains the following parameters: 1471 Network Appearance Optional 1472 Affected Destinations Mandatory 1473 Info String Optional 1475 The format for DUNA Message parameters is as follows: 1477 0 1 2 3 1478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Tag = 1 | Length =8 | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Network Appearance* | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Tag = 5 | Length | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Mask | Affected DPC 1 | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 \ \ 1489 / ... / 1490 \ \ 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Mask | Affected DPC n | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Tag = 4 | Length | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 \ \ 1497 / INFO String* / 1498 \ \ 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 Network Appearance: 32-bit unsigned integer 1503 The optional Network Appearance parameter identifies the SS7 network 1504 context for the message, for the purposes of logically separating 1505 the signalling traffic between the SG and the Application Server 1506 Process over a common SCTP Association. An example is where an SG 1507 is logically partitioned to appear as an element in four different 1508 national SS7 networks. 1510 In an SSNM message, the Network Appearance parameter defines the 1511 format of the Affected DPC(s) in the Affected Destination parameter. 1512 The DPC point code length (e.g., 14-, 16-, or 24-bit) and sub-field 1513 definitions (e.g., ANSI 24-bit network/cluster/member, ITU- 1514 international 14-bit zone/region/signal_point, many national field 1515 variants, ...) are fixed within a particular Network Appearance. 1516 Where an SG operates in the context of a single SS7 network, or 1517 individual SCTP associations are dedicated to each SS7 network 1518 context, the Network Appearance parameter is not required and the 1519 format of the Affected DPC(s) is understood implicitly. 1521 The format of the Network Appearance parameter is an integer, the 1522 values used are of local significance only, coordinated between the 1523 SG and ASP. 1525 Where the optional Network Appearance parameter is present, it must 1526 be the first parameter in the message as it defines the format of 1527 the Affected DPCs in the Affected Destination parameter. 1529 Affected Destinations: n x 32-bits 1531 The Affected Destinations parameter contains up to sixteen Affected 1532 Destination Point Code fields, each a three-octet parameter to allow 1533 for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected 1534 Point Codes that are less than 24-bits, are padded on the left to 1535 the 24-bit boundary. The encoding is shown below for ANSI and ITU 1536 Point Code examples. 1538 ANSI 24-bit Point Code: 1540 0 1 2 3 1541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Mask | Network | Cluster | Member | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 |MSB-----------------------------------------LSB| 1548 ITU 14-bit Point Code: 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 | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 |MSB--------------------LSB| 1558 It is optional to send an Affected Destinations parameter with more 1559 than one Affected DPC but it is mandatory to receive and process it. 1560 All the Affected DPCs included must be within the same Network 1561 Appearance. Including multiple Affected DPCs may be useful when 1562 reception of an MTP3 management message or a linkset event 1563 simultaneously affects the availability status of a list of 1564 destinations at an SG. 1566 Mask: 8-bit unsigned integer 1568 The Mask field associated with each Affected DPC in the Affected 1569 Destinations parameter, used to identify a contiguous range of 1570 Affected Destination Point Codes, independent of the point code 1571 format. Identifying a contiguous range of Affected DPCs may be 1572 useful when reception of an MTP3 management message or a linkset 1573 event simultaneously affects the availability status of a series of 1574 destinations at an SG. For example, if all DPCs in an ANSI cluster 1575 are determined to be unavailable due to local linkset 1576 unavailability, the DUNA could identify potentially 256 Affected 1577 DPCs in a single Affected DPC field. 1579 The Mask parameter represents a bit mask that can be applied to the 1580 related Affected DPC field. The bit mask identifies how many bits 1581 of the Affected DPC field are significant and which are effectively 1582 "wildcarded". For example, a mask of "8" indicates that the last 1583 eight bits of the DPC is "wildcarded". For an ANSI 24-bit Affected 1584 DPC, this is equivalent to signalling that all DPCs in an ANSI 1585 Cluster are unavailable. A mask of "3" indicates that the last 1586 three bits of the DPC is "wildcarded". For a 14-bit ITU Affected 1587 DPC, this is equivalent to signaling that an ITU Region is 1588 unavailable. A mask value equal to the number of bits in the DPC 1589 indicates that the entire network appearance is affected - this is 1590 used to indicate network isolation to the ASP. 1592 Info String: variable length 1594 The optional INFO String parameter can carry any meaningful 8-BIT 1595 ASCII character string along with the message. Length of the INFO 1596 String parameter is from 0 to 255 characters. No procedures are 1597 presently identified for its use but the INFO String may be used by 1598 Operators to identify in text form the location reflected by the 1599 Affected DPC for debugging purposes. 1601 3.4.2 Destination Available (DAVA) 1603 The DAVA message is sent from the SG to all concerned ASPs to indicate 1604 that the SG has determined that one or more SS7 destinations are now 1605 reachable, or in response to a DAUD message if appropriate. The ASP 1606 MTP3-User protocol is expected to resume traffic to the affected 1607 destination through the SG initiating the DUNA. 1609 The DAVA message contains the following parameters: 1611 Network Appearance Optional 1612 Affected Destinations Mandatory 1613 Info String Optional 1615 The format and description of the Network Appearance, Affected 1616 Destinations and Info String parameters is the same as for the DUNA 1617 message (See Section 3.4.1.) 1619 3.4.3 Destination State Audit (DAUD) 1621 The DAUD message can be sent from the ASP to the SG to audit the 1622 availability/congestion state of SS7 routes to one or more affected 1623 destinations. 1625 The DAUD message contains the following parameters: 1627 Network Appearance Optional 1628 Affected Destinations Mandatory 1629 Info String Optional 1631 The format and description of DAUD Message parameters is the same as 1632 for the DUNA message (See Section 3.4.1.) 1634 3.4.4 SS7 Network Congestion (SCON) 1636 The SCON message can be sent from the SG to all concerned ASPs to 1637 indicate the congestion level in the SS7 network to one or more 1638 destinations or in response to a DAUD message, if appropriate. For 1639 some MTP protocol variants (e.g., ANSI MTP) the SCON may be sent when 1640 the SS7 congestion level changes. The SCON message is also sent from 1641 the M3UA of an ASP to the SG or IPSP indicating that the M3UA or the 1642 ASP is congested. 1644 The SCON message contains the following parameters: 1646 Network Appearance Optional 1647 Affected Destinations Mandatory 1648 Info String Optional 1650 The format for SCON Message parameters is as follows: 1652 0 1 2 3 1653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Tag = 1 | Length =8 | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Network Appearance* | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Tag = 5 | Length | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Cong. Level 1 | Affected DPC 1 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 \ \ 1664 / ... / 1665 \ \ 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Cong. Level n | Affected DPC n | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Tag = 4 | Length | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 \ \ 1672 / INFO String* / 1673 \ \ 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 The Affected Destinations parameter differs from the Affected 1677 Destinations parameter in the DUNA, DAVA, and DAUD in that a Congestion 1678 Level field is included instead of a Mask field. Therefore ranges of 1679 congested Affected DPCs cannot be signaled, but this is consistent with 1680 operation in the SS7 network. 1682 The format and description of the Network Appearance and Info String 1683 parameters is the same as for the DUNA message (See Section 3.3.2.1.) 1685 Congestion Level field: 8-bits (unsigned integer) 1687 The Congestion Level field, associated with each Affected DPC in the 1688 Affected Destinations parameter, contains one of the following 1689 values: 1691 0 No Congestion or Undefined 1692 1 Congestion Level 1 1693 2 Congestion Level 2 1694 3 Congestion Level 3 1696 The congestion levels are as defined in the national congestion 1697 method in the appropriate MTP recommendation [14,15]. For MTP 1698 congestion methods that do not employ congestion levels (e.g., the 1699 ITU international method, the parameter is always "Undefined". 1701 When an SCON is received at the SG, a TFC message is generated into the 1702 SS7 network. 1704 Editors Note: May need a different message type (ASPCON) and specify 1705 more detailed procedures at the SG or IPSP upon reception. 1707 3.4.5 Destination User Part Unavailable (DUPU) 1709 The DUPU message is used by an SG to inform an ASP that a remote peer 1710 MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. 1712 The DUPU message contains the following parameters: 1714 Network Appearance Optional 1715 Affected Destinations Mandatory 1716 User/Cause Mandatory 1717 Info String Optional 1719 The format for DUPU Message parameters is as follows: 1721 0 1 2 3 1722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Tag = 1 | Length | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Network Appearance* | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Tag = 5 | Length = 8 | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Reserved | Affected DPC | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Tag = 9 | Length = 8 | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Cause | User | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Tag = 4 | Length | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 \ \ 1739 / INFO String* / 1740 \ \ 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 User/Cause: 32-bits 1745 The Unavailability Cause and MTP3-User Identity fields, associated 1746 with the Affected DPC in the Affected Destinations parameter, are 1747 encoded as follows: 1749 Unavailability Cause field: 16-bits (unsigned integer) 1751 The Unavailability Cause parameter provides the reason for the 1752 unavailability of the MTP3-User. The valid values for the 1753 Unavailability Cause parameter are shown in the following table. 1754 The values agree with those provided in the SS7 MTP3 User Part 1755 Unavailable message. Depending on the MTP3 protocol used in the 1756 network appearance, additional values may be used - the 1757 specification of the relevant MTP3 protocol variant/version 1758 recommendation is definitive. 1760 0 Unknown 1761 1 Unequipped Remote User 1762 2 Inaccessible Remote User 1764 MTP3-User Identity field: 16-bits (unsigned integer) 1766 The MTP3-User Identity describes the specific MTP3-User that is 1767 unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for 1768 the MTP3-User Identity are shown below. The values agree with those 1769 provided in the SS7 MTP3 User Part Unavailable message and Service 1770 Indicator. Depending on the MTP3 protocol used in the network 1771 appearance, additional values may be used - the specification of the 1772 relevant MTP3 protocol variant/version recommendation is definitive. 1774 0 to 2 Reserved 1775 3 SCCP 1776 4 TUP 1777 5 ISUP 1778 6 to 8 Reserved 1779 9 Broadband ISUP 1780 10 Satellite ISUP 1782 The Affected Destinations parameter differs from the Affected 1783 Destinations parameter in the DUNA, DAVA, and DAUD in that a Reserved 1784 field is included instead of a Mask field. Therefore, ranges of 1785 congested Affected DPCs cannot be signaled, but this is consistent with 1786 operation in the SS7 network. The Affected Destinations parameter in 1787 the DUPU message can only contain one Affected DPC. 1789 The format and description of the Network Appearance and Info String 1790 parameters is the same as for the DUNA message (See Section 3.4.1.). 1792 3.5 Application Server Process Maintenance (ASPM) Messages 1794 3.5.1 ASP Up (ASPUP) 1796 The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer 1797 that the Adaptation layer is ready to receive SSNM or ASPM management 1798 messages for all Routing Keys that the ASP is configured to serve. 1800 The ASPUP message contains the following parameters: 1802 Adaptation Layer Identifier Optional 1803 INFO String Optional 1805 The format for ASPUP Message parameters is as follows: 1807 0 1 2 3 1808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Tag = 2 | Length | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Adaptation Layer Identifier* | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Tag = 4 | Length | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 \ \ 1817 / INFO String* / 1818 \ \ 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 The format and description of the optional Info String parameter is the 1822 same as for the DUNA message (See Section 3.3.2.1.) 1824 Adaptation Layer Identifier: 32-bits 1826 The optional Adaptation Layer Identifier (ALI) is a string that 1827 identifies the adaptation layer. This string must be set to "M3UA" 1828 which results in a length of 8. The ALI would normally only be used in 1829 the initial ASP Up message across a new SCTP association to ensure both 1830 peers are assuming the same adaptation layer protocol. 1832 Editors Note: Info in SCTP (Payload Identifier) could be used - is 1833 there any need for ALI anymore? 1835 3.5.2 ASP Up Ack 1837 The ASP UP Ack message is used to acknowledge an ASP-Up message 1838 received from a remote M3UA peer. 1840 The ASPUP Ack message contains the following parameters: 1842 Adaptation Layer Identifier (optional) 1843 INFO String (optional) 1845 The format for ASPUP Ack Message parameters is as follows: 1847 0 1 2 3 1848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | Tag =2 | Length | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 \ \ 1853 / Adaptation Layer Identifier* / 1854 \ \ 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Tag =4 | Length | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 \ \ 1859 / INFO String* / 1860 \ \ 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 The format and description of the optional Info String parameter is the 1864 same as for the DUNA message (See Section 3.3.2.1.) 1866 The format and description of the optional Adaptation Layer Identifier 1867 (ALI) parameter is the same as for the ASP-UP message. (See Section 1868 3.4.1) 1869 3.5.3 ASP Down (ASPDN) 1871 The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer 1872 that the adaptation layer is not ready to receive traffic or 1873 maintenance messages. 1875 The ASPDN message contains the following parameters: 1877 Reason Mandatory 1878 INFO String Optional 1880 The format for the ASPDN message parameters is as follows: 1882 0 1 2 3 1883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Reason | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Tag =4 | Length | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 \ \ 1890 / INFO String* / 1891 \ \ 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 The format and description of the optional Info String parameter is the 1895 same as for the DUNA message (See Section 3.3.2.1.) 1897 Reason: 32-bit (unsigned integer) 1899 The Reason parameter indicates the reason that the remote M3UA 1900 adaptation layer is unavailable. The valid values for Reason are 1901 shown in the following table. 1903 0 Unspecified 1904 1 User Unavailable 1905 2 Management Blocking 1907 3.5.4 ASP Down Ack 1909 The ASP Down Ack message is used to acknowledge an ASP-Down message 1910 received from a remote M3UA peer. 1912 The ASP Down Ack message contains the following parameters: 1914 Reason Mandatory 1915 INFO String Optional 1917 The format for the ASPDN Ack message parameters is as follows: 1919 0 1 2 3 1920 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Reason | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Tag = 4 | Length | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 \ \ 1927 / INFO String* / 1928 \ \ 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 The format and description of the optional Info String parameter is the 1932 same as for the DUNA message (See Section 3.3.2.1.) 1934 The format of the Reason parameter is the same as for the ASP-Down 1935 message. (See Section 3.4.3) 1937 3.5.5 ASP Active (ASPAC) 1939 The ASPAC message is sent by an ASP to indicate to a remote M3UA peer 1940 that it is Active and ready to process signalling traffic for a 1941 particular Application Server. The ASPAC affects only the ASP state 1942 for the routing keys identified by the Routing Contexts, if present. 1944 The ASPAC message contains the following parameters: 1946 Type Mandatory 1947 Routing Context Optional 1948 INFO String Optional 1950 The format for the ASPAC message is as follows: 1952 0 1 2 3 1953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Type | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Tag =6 | Length | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 \ \ 1960 / Routing Context* / 1961 \ \ 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Tag = 4 | Length | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 \ \ 1966 / INFO String* / 1967 \ \ 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 Type: 32-bit (unsigned integer) 1972 The Type parameter identifies the traffic mode of operation of the 1973 ASP within an AS. The valid values for Type are shown in the 1974 following table. 1976 1 Over-ride 1977 2 Load-share 1978 3 Over-ride (Standby) 1979 4 Loadshare (Standby) 1981 Within a particular Routing Context, Over-ride and Loadshare Types 1982 cannot be mixed. The Over-ride value indicates that the ASP is 1983 operating in Over-ride mode, and the ASP wishes to take over all 1984 traffic in an Application Server (i.e., primary/back-up operation), 1985 over-riding any currently active ASP in the AS. In Load-share mode, 1986 the ASP wishes to share in the traffic distribution with any other 1987 currently active ASPs. The Standby versions of the Over-ride and 1988 Loadshare Types indicate that the ASP is declaring itself ready to 1989 accept traffic but leaves it up to the sender as to when the traffic 1990 is started. Over-ride (Standby) indicates that the traffic sender 1991 continues to use the currently active ASP until it can no longer 1992 send/receive traffic (i.e., the currently active ASP transitions to 1993 Down or Inactive). At this point the sender may immediately move 1994 the ASP to Active and commence traffic. Loadshare (Standby) is 1995 similar - the sender continues to loadshare to the current ASPs 1996 until there it is determined that there is insufficient resources in 1997 the Loadshare group. When there is insufficient ASPs, the sender 1998 may immediately move the ASP to Active. 2000 Routing Context: 2002 The optional Routing Context parameter contains (a list of) 4-byte 2003 unsigned integers indexing the Application Server traffic that the 2004 sending ASP is configured/registered to receive. 2006 There is one-to-one relationship between an index entry and an SG 2007 Routing Key or AS Name. Because an AS can only appear in one 2008 Network Appearance, the Network Appearance parameter is not required 2009 in the ASPAC message. 2011 An Application Server Process may be configured to process traffic 2012 for more than one logical Application Server. From the perspective 2013 of an ASP, a Routing Context defines a range of signalling traffic 2014 that the ASP is currently configured to receive from the SG. For 2015 example, an ASP could be configured to support call processing for 2016 multiple ranges of PSTN trunks and therefore receive related 2017 signalling traffic, identified by separate SS7 DPC/OPC/CIC_ranges. 2019 The format and description of the optional Info String parameter is the 2020 same as for the DUNA message (See Section 3.3.2.1.) 2022 3.5.6 ASP Active Ack 2024 The ASPAC Ack message is used to acknowledge an ASP-Active message 2025 received from a remote M3UA peer. 2027 The ASPAC Ack message contains the following parameters: 2029 Type Mandatory 2030 Routing Context Optional 2031 INFO String Optional 2033 The format for the ASPAC Ack message is as follows: 2035 0 1 2 3 2036 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Type | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Tag = 6 | Length | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 \ \ 2043 / Routing Context* / 2044 \ \ 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | Tag = 4 | Length | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 \ \ 2049 / INFO String* / 2050 \ \ 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 The format and description of the optional Info String parameter is the 2054 same as for the DUNA message (See Section 3.3.2.1.) 2056 The format of the Type and Routing Context parameters is the same as 2057 for the ASP-Active message. (See Section 3.4.5). 2059 3.5.7 ASP Inactive (ASPIA) 2061 The ASPIA message is sent by an ASP to indicate to a remote M3UA peer 2062 that it is no longer processing signalling traffic within a particular 2063 Application Server. The ASPIA affects only the ASP state in the 2064 Routing Keys identified by the Routing Contexts, if present. 2066 The ASPIA message contains the following parameters: 2068 Type Mandatory 2069 Routing Context Optional 2070 INFO String Optional 2072 The format for the ASPIA message parameters is as follows: 2074 0 1 2 3 2075 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Type | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | Tag = 6 | Length | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 \ \ 2082 / Routing Context* / 2083 \ \ 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | Tag = 4 | Length | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 \ \ 2088 / INFO String* / 2089 \ \ 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 Type: 32-bit (unsigned integer) 2094 The Type parameter identifies the traffic mode of operation of the 2095 ASP within an AS. The valid values for Type are shown in the 2096 following table. 2098 1 Over-ride 2099 2 Load-share 2101 Within a particular Routing Context, only one Type can be used. The 2102 Over-ride value indicates that the ASP is operating in Over-ride 2103 mode, and will no longer handle traffic within an Application Server 2104 (i.e., it is now a backup in a primary/back-up arrangement). The 2105 Load-share value indicates that the ASP is operating in Load-share 2106 mode and will no longer share in the traffic distribution with any 2107 other currently active ASPs. 2109 A node that receives an ASPIA with an incorrect Type for a 2110 particular routing Context will respond with an Error Message 2111 (Cause: Invalid Traffic Handling Mode. 2113 The format and description of the optional Routing Context and Info 2114 String parameters is the same as for the ASPAC message (See Section 2115 2.3.3.3.) 2116 3.5.8 ASP Inactive Ack 2118 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 2119 received from a remote M3UA peer. 2121 The ASPIA Ack message contains the following parameters: 2123 Type Mandatory 2124 Routing Context Optional 2125 INFO String Optional 2127 The format for the ASPIA Ack message is as follows: 2129 0 1 2 3 2130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Type | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Tag = 6 | Length | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 \ \ 2137 / Routing Context* / 2138 \ \ 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Tag = 4 | Length | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 \ \ 2143 / INFO String* / 2144 \ \ 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 The format and description of the optional Info String parameter is the 2148 same as for the DUNA message (See Section 3.3.2.1.) 2150 The format of the Type and Routing Context parameters is the same as 2151 for the ASP-Inactive message. (See Section 3.4.7). 2153 3.5.9 Heartbeat (BEAT) 2155 The Heartbeat message is optionally used to ensure that the M3UA peers 2156 are still available to each other. It is recommended for use when the 2157 M3UA runs over a transport layer other than the SCTP, which has its own 2158 heartbeat. 2160 The BEAT message contains the following parameters: 2162 Heatbeat Data Optional 2164 The format for the BEAT message is as follows: 2166 0 1 2 3 2167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Tag = 8 | Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 \ \ 2172 / Heartbeat Data * / 2173 \ \ 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 The Heartbeat Data parameter contents are defined by the sending node. 2177 The Heartbeat Data could include, for example, a Heartbeat Sequence 2178 Number and/or Timestamp. The receiver of a Heartbeat message does not 2179 process this field as it is only of significance to the sender. The 2180 receiver MUST respond with a BEAT-Ack message. 2182 3.5.10 Heartbeat Ack (Beat-Ack) 2184 The Heartbeat Ack message is sent in response to a received Heartbeat 2185 message. It includes all the parameters of the received Heartbeat 2186 message, without any change. 2188 3.6 Management Messages 2190 3.6.1 Error (ERR) 2192 The Error message is used to notify a peer of an error event associated 2193 with an incoming message. For example, the message type might be 2194 unexpected given the current state, or a parameter value might be 2195 invalid. 2197 The ERR message contains the following parameters: 2199 Error Code Mandatory 2200 Diagnostic Information Optional 2202 The format for the ERR message is as follows: 2204 0 1 2 3 2205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Error Code | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | Tag = 7 | Length | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 \ \ 2212 / Diagnostic Information* / 2213 \ \ 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 Error Code: 32-bits (unsigned integer) 2218 The Error Code parameter indicates the reason for the Error Message. 2219 The Error parameter value can be one of the following values: 2221 1 Invalid Version 2222 2 Invalid Network Appearance 2223 3 Invalid Adaptation Layer Identifier 2224 4 Invalid Message Type 2225 5 Invalid Traffic Handling Mode 2226 6 Unexpected Message Type 2227 7 Protocol Error 2228 8 Invalid Routing Context 2230 Diagnostic Information: variable length 2232 When included, the optional Diagnostic information can be any 2233 information germane to the error condition, to assist in 2234 identification of the error condition. In the case of an Invalid 2235 Network Appearance, Adaptation Layer Identifier, Traffic Handling 2236 Mode or Invalid Routing Context, the Diagnostic information includes 2237 the received parameter. In the other cases, the Diagnostic 2238 information may be the first 40 bytes of the offending message. 2240 In the case of an Invalid Version Error Code, the Common Header 2241 contains the supported Version. 2243 Error messages are not generated in response to other Error messages. 2245 3.6.2 Notify (NTFY) 2247 The Notify message used to provide an autonomous indication of M3UA 2248 events to an M3UA peer. 2250 The NTFY message contains the following parameters: 2252 Status Type Mandatory 2253 Status Identification Mandatory 2254 Routing Context Optional 2255 INFO String Optional 2257 The format for the NTFY message is as follows: 2259 0 1 2 3 2260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Status Type | Status Identification | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | Tag = 6 | Length | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 \ \ 2267 / Routing Context* / 2268 \ \ 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | Tag = 4 | Length | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 \ \ 2273 / INFO String* / 2274 \ \ 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 Status Type: 16-bits (unsigned integer) 2279 The Status Type parameter identifies the type of the Notify message. 2280 Following are the valid Status Type values: 2282 1 Application Server State Change (AS-StateChange) 2283 2 Other 2285 Status Information: 16-bits (unsigned integer) 2287 The Status Information parameter contains more detailed information 2288 for the notification, based on the value of the Status Type. 2290 If the Status Type is AS_State_Change the following Status 2291 Information values are used: 2293 1 reserved 2294 2 Application Server Inactive (AS-Inactive) 2295 3 Application Server Active (AS-Active) 2296 4 Application Server Pending (AS-Pending) 2298 These notifications are sent from an SG to an ASP upon a change in 2299 status of a particular Application Server. The value reflects the 2300 new state of the Application Server. 2302 If the Status Type is Other, then the following Status Information 2303 values are defined: 2305 1 Insufficient ASP resources active in AS 2306 2 Alternate ASP Active 2308 These notifications are not based on the SG reporting the state change 2309 of an ASP or AS. In the Insufficent ASP Resources case, the SG is 2310 indicating to an "Inactive" ASP(s) in the AS that another ASP is 2311 required in order to handle the load of the AS (Load-sharing mode). 2312 For the Alternate ASP Active case, an ASP is informed when an alternate 2313 ASP transitions to the ASP-Active state in Over-ride mode. 2315 The format and description of the optional Routing Context and Info 2316 String parameters is the same as for the ASPAC message (See Section 2317 3.4.6.) 2318 4.0 Procedures 2320 The M3UA layer needs to respond to various local primitives it receives 2321 from the SCTP and M3UA-User layers and Layer Management as well as the 2322 messages that it receives from the peer M3UA layers. This section 2323 describes the M3UA procedures in response to these events. 2325 4.1 Procedures to support the services of the M3UA layer 2327 4.1.1 Receipt of primitives from the M3UA-User 2329 On receiving an MTP-Transfer primitive from an upper layer, or the 2330 nodal inter-working function at an SG, the M3UA layer will send a 2331 corresponding DATA message (see Section 3) to its M3UA peer. The M3UA 2332 layer must fill in the fields of the common and specific headers 2333 correctly. 2335 At an SG, the M3UA address translation and mapping function determines 2336 the Application Server (AS) based on the information in the incoming 2337 message. From the list of ASPs within the AS table, an Active ASP is 2338 selected and a DATA message is constructed and issued on the 2339 corresponding SCTP Association. If more than one ASP is active (i.e., 2340 traffic is to be load-shared across all the active ASPs), one of the 2341 active ASPs from the list is selected. The selection algorithm is 2342 implementation dependent but could, for example, be round-robin or 2343 based on, for example, the SLS or ISUP CIC. The appropriate selection 2344 algorithm must be chosen carefully as it is dependent on application 2345 assumptions and understanding of the degree of state coordination 2346 between the active ASPs in the AS. 2348 In addition, the message needs to be sent on the appropriate SCTP 2349 stream, again taking care to meet the message sequencing needs of the 2350 signalling application. 2352 4.1.2 Receipt of primitives from the Layer Management 2354 On receiving these primitives from the local Layer Management, the M3UA 2355 layer will provide the appropriate response primitive across the 2356 internal local Layer Management interface. 2358 An M-SCTP ESTABLISH request from Layer Management will initiate the 2359 establishment of an SCTP association. An M-SCTP ESTABLISH confirm will 2360 be sent to Layer Management when the initiated association set-up is 2361 complete. An M-SCTP ESTABLISH indication is sent to Layer Management 2362 upon successful completion of an incoming SCTP association set-up from 2363 a peer M3UA node 2364 An M-SCTP RELEASE request from Layer Management will initate the tear- 2365 down of an SCTP association. An M-SCTP RELEASE confirm will be sent by 2366 Layer Management when the association teardown is complete. An M-SCTP 2367 RELEASE indication is sent to Layer Management upon successful tear- 2368 down of an SCTP association initiated by a peer M3UA 2370 M-SCTP STATUS request and indication support a Layer Management query 2371 of the local status of a particular SCTP association. 2373 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 2374 the notification or error information contained in a received M3UA 2375 Notify or Error message. These indications can also be generated based 2376 on local M3UA events. 2378 M-ASP STATUS request/indication and M-AS-STATUS request/indication 2379 support a Layer Management query of the local status of a particular 2380 ASP or AS. No M3UA peer protocol is invoked. 2382 M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request and M-ASP- 2383 ACTIVE request allow Layer Management at an ASP to initiate state 2384 changes . These requests result in outgoing M3UA ASP-UP, ASP-DOWN, 2385 ASP-INACTIVE and ASP-ACTIVE messages. 2387 4.2 Receipt of M3UA Peer Management messages 2389 Upon receipt of M3UA Management messages, the M3UA layer must invoke 2390 the corresponding Layer Management primitive indications (e.g., M-AS 2391 Status ind., M-ASP Status ind., M-ERROR ind., ...) to the local layer 2392 management. 2393 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 2394 the notification or error information contained in a received M3UA 2395 Notify or Error message. These indications can also be generated based 2396 on local M3UA events. 2398 4.3 Procedures to support the M3UA Management services 2400 These procedures support the M3UA management of SCTP Associations 2401 between SGs and ASPs. 2403 4.3.1 AS and ASP State Maintenance 2405 The M3UA layer on the SG maintains the state of each remote ASP, in 2406 each Application Server that the ASP is configured to receive traffic, 2407 as input to the M3UA message distribution function. Similarly, where 2408 IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP 2409 maintains the state of remote ASPs in IPSPs. For the purposes of the 2410 following procedures, only the SG/ASP case is described but the SG side 2411 of the procedures also apply to an IPSP sending traffic to an AS 2412 consisting of remote ASPs in IPSPs. 2414 4.3.1.1 ASP States 2416 The state of each remote ASP, in each AS that it is configured to 2417 operate, is maintained in the M3UA layer in the SG or IPSP. The state 2418 of a particular ASP in a particular AS changes due to events. The 2419 events include: 2421 * Reception of messages from the peer M3UA layer at the ASP 2422 * Reception of some messages from the peer M3UA layer at other ASPs 2423 in the AS (e.g., ASPAC Take-over) 2424 * Reception of indications from the SCTP layer 2426 The ASP state transition diagram is shown in Figure 4. The possible 2427 states of an ASP are: 2429 ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the 2430 related SCTP association is down. Initially all ASPs will be in this 2431 state. An ASP in this state should not be sent any M3UA messages. 2433 ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the 2434 related SCTP association is up) but application traffic is stopped. In 2435 this state the ASP can be sent any non-Data M3UA messages. 2437 ASP-ACTIVE: The remote M3UA peer at the ASP is available and 2438 application traffic is active (for a particular Routing Context or set 2439 of Routing Contexts). 2441 ASP-STANDBY: The remote M3UA peer at the ASP is available and ready to 2442 receive application traffic at any time (for a particular Routing 2443 Context or set of Routing Contexts). In this state the ASP can be sent 2444 any non-Data M3UA messages. 2446 Figure 4: ASP State Transition Diagram 2448 +-------------+ 2449 | ASP-ACTIVE | 2450 +----------------------| or | 2451 | Alternate +-------| ASP-STNDBY* | 2452 | ASP | +-------------+ 2453 | Takeover | ^ | 2454 | | ASP | | ASP 2455 | | Active | | Inact 2456 | | | v 2457 | | +-------------+ 2458 | | | | 2459 | +------>| ASP-INACT | 2460 | +-------------+ 2461 | ^ | 2462 ASP Down/ | ASP | | ASP Down / 2463 SCTP CDI | Up | | SCTP CDI 2464 | | v 2465 | +-------------+ 2466 | | | 2467 +--------------------->| | 2468 | ASP-DOWN | 2469 +-------------+ 2471 *Note: ASP-ACTIVE and ASP-STNDBY differ only in whether the ASP is 2472 currently receiving Data traffic. 2474 SCTP CDI: The local SCTP layer's Communication Down Indication to the 2475 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 2476 indication when it detects the loss of connectivity to the ASP's peer 2477 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 2478 notification or COMMUNICATION LOST notification from the SCTP. 2480 4.3.1.2 AS States 2482 The state of the AS is maintained in the M3UA layer on the SG. 2484 The state of an AS changes due to events. These events include: 2486 * ASP state transitions 2487 * Recovery timer triggers 2489 The possible states of an AS are: 2491 AS-DOWN: The Application Server is unavailable. This state implies 2492 that all related ASPs are in the ASP-DOWN state for this AS. Initially 2493 the AS will be in this state. 2495 AS-INACTIVE: The Application Server is available but no application 2496 traffic is active (i.e., one or more related ASPs are in the ASP- 2497 Inactive state, but none in the ASP-Active state). 2499 AS-ACTIVE: The Application Server is available and application traffic 2500 is active. This state implies that at least one ASP is in the ASP- 2501 ACTIVE state. 2503 AS-PENDING: An active ASP has transitioned to inactive and it was the 2504 last remaining active ASP in the AS (and no STANDBY ASPs are available. 2505 A recovery timer T(r) will be started and all incoming SCN messages 2506 will be queued by the SG. If an ASP becomes active before T(r) expires, 2507 the AS will move to AS-ACTIVE state and all the queued messages will be 2508 sent to the active ASP. 2510 If T(r) expires before an ASP becomes active, the SG stops queuing 2511 messages and discards all previously queued messages. The AS will move 2512 to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise 2513 it will move to AS-DOWN state. 2515 Figure 5: AS State Transition Diagram 2517 +----------+ one ASP trans to ACTIVE +-------------+ 2518 | |---------------------------->| | 2519 | AS-INACT | | AS-ACTIVE | 2520 | |<--- | | 2521 +----------+ \ +-------------+ 2522 ^ | \ Tr Expiry, ^ | 2523 | | \ at least one | | 2524 | | \ ASP in INACT | | 2525 | | \ | | 2526 | | \ | | 2527 | | \ | | 2528 one ASP | | all ASP \ one ASP | | Last ACT ASP 2529 trans | | trans to \ trans to | | trans to 2530 INACT 2531 to INACT| | DOWN -------\ ACTIVE | | or DOWN 2532 | | \ | | 2533 | | \ | | 2534 | | \ | | 2535 | | \ | | 2536 | v \ | v 2537 +----------+ \ +-------------+ 2538 | | --| | 2539 | AS-DOWN | | AS-PENDING | 2540 | | | (queueing) | 2541 | |<----------------------------| | 2542 +----------+ Tr Expiry no ASP +-------------+ 2543 in INACT state 2545 Tr = Recovery Timer 2547 4.3.2 M3UA Management procedures for primitives 2549 Before the establishment of an SCTP association the ASP state at both 2550 the SG and ASP is assumed to be "Down". 2552 As the ASP is responsible for initiating the setup of an SCTP 2553 association to an SG, the M3UA layer at an ASP receives an M-SCTP 2554 ESTABLISH request primitive from the Layer Management, the M3UA layer 2555 will try to establish an SCTP association with the remote M3UA peer at 2556 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2557 primitive from the SCTP, the M3UA layer will invoke the primitive M- 2558 SCTP ESTABLISH confirm to the Layer Management. 2560 The M3UA layers at the SG will receive an SCTP-CommunicationUp 2561 indication primitive from the SCTP when the association is successfully 2562 set up. The M3UA layer will then invoke the primitive M-SCTP ESTABLISH 2563 indication to the Layer Management. 2565 Once the SCTP association is established and assuming that the local 2566 M3UA-User is ready, the local ASP M3UA Application Server Process 2567 Maintenance (ASPM) function will initiate the ASPM procedures, using 2568 the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to 2569 the SG - see Section 4.3.3. 2571 If the M3UA layer subsequently receives an SCTP-Communication Down 2572 indication from the underlying SCTP layer, it will inform the Layer 2573 Management by invoking the M-SCTP STATUS indication primitive. The 2574 state of the remote ASP will be moved to "Down". At an ASP, the MTP3- 2575 User at an ASP will be informed of the unavailability of any affected 2576 SS7 destinations through the use of MTP-PAUSE primitives. In the case 2577 of SS7 network isolation, the local MTP3-Users may be informed by 2578 implementation-dependent means as there is currently no primitive 2579 defined for conveying this information. 2581 At an ASP, the Layer Management may try to re-establish the SCTP 2582 association using M-SCTP ESTABLISH request primitive. 2584 4.3.3 M3UA Management procedures for peer-to-peer messages 2586 All M3UA MGMT and ASP Maintenance messages are sent on a sequenced 2587 stream to ensure ordering. SCTP stream '0' is used. 2589 4.3.3.1 ASP-Up 2591 After an ASP has successfully established an SCTP association to an SG 2592 or IPSP, the SG or IPSP waits for the ASP to send an ASP-Up message, 2593 indicating that the ASP M3UA peer is available. The ASP is always the 2594 initiator of the ASP-Up exchange. 2596 When an ASP-Up message is received at an SG or IPSP and internally the 2597 remote ASP is not considered locked-out for local management reasons, 2598 the SG marks the remote ASP as 'Inactive'. If the SG knows via 2599 configuration data which Application Servers that the ASP is configured 2600 to operate in, it can update the ASP status to "Inactive" in each AS 2601 pool that it is a member. Alternatively, the SG may move the ASP into 2602 a pool of Inactive ASPs available for future activation in AS pool(s) 2603 denoted in the subsequent ASP-Active Routing Contexts. The SG responds 2604 with an ASP-Up Ack message in acknowledgement. The SG sends an ASP-Up 2605 Ack message in response to a received ASP-Up message even if the ASP is 2606 already marked as "Inactive" at the SG. 2608 If for any local reason (e.g., management lock-out) the SG cannot 2609 respond with an ASP-Up Ack, the SG responds to an ASP-Up with an ASP- 2610 Down Ack message with Reason "Management Blocking". 2612 At the ASP, the ASP-Up Ack message received is not acknowledged. If 2613 the ASP does not receive a response , or an ASP-Down Ack is received, 2614 the ASP may resend ASP-Up messages every 2 seconds until it receives an 2615 ASP-Up Ack message. The ASP may decide to reduce the frequency (say to 2616 every 5 seconds) if an ASP-Up Ack is not received after a few tries. 2618 The ASP must wait for the ASP-Up Ack message before sending any ASP 2619 traffic control messages (i.e., ASPAC). If the SG or IPSP receives any 2620 other M3UA messages before an ASP Up is received, the SG or IPSP should 2621 discard them. 2623 4.3.3.2 ASP-Down 2625 The ASP will send an ASP-Down to an SG or IPSP when the ASP wishes to 2626 be removed from service in all Application Servers that it is a member 2627 And no longer receive any M3UA traffic or management messages. 2629 Whether the ASP is permanently removed from any AS is a function of 2630 configuration management. 2632 The SG marks the ASP as "Down" and returns an ASP-Down Ack message to 2633 the ASP if one of the following events occur: 2635 - an ASP-Down message is received from the ASP, 2636 - another ASPM message is received from the ASP and the SG has 2637 locked out the ASP for management reasons. 2639 The SG sends an ASP-Down Ack message in response to a received ASP-Down 2640 message from the ASP even if the ASP is already marked as "Down" at the 2641 SG. 2643 If the ASP does not receive a response from the SG, the ASP may send 2644 ASP-Down messages every 2 seconds until it receives an ASP-Down Ack 2645 message from the SG or the SCTP association goes down. The ASP may 2646 decide to reduce the frequency (say to every 5 seconds) if an ASP-Down 2647 Ack is not received after a few tries. 2649 4.3.3.3 M3UA Version Control 2651 If an ASP-Up message with an unsupported version is received, the 2652 receiving end responds with an Error message, indicating the version 2653 the receiving node supports and notifies Layer Management. 2655 This is useful when protocol version upgrades are being performed in a 2656 network. A node upgraded to a newer version should support the older 2657 versions used on other nodes it is communicating with. Because ASPs 2658 initiate the ASP-Up procedure it is assumed that the Error message 2659 would normally come from the SG. 2661 4.3.3.4 ASP-Active 2663 Anytime after the ASP has received an ASP-Up Ack from the SG or IPSP, 2664 the ASP sends an ASP-Active (ASPAC) to the SG indicating that the ASP 2665 is ready to start processing traffic. In the case where an ASP wishes 2666 to process the traffic for more than one Application Server across a 2667 common SCTP association, the ASPAC contains a list of one or more 2668 Routing Contexts to indicate for which Application Servers the ASPAC 2669 applies. In the case where an ASP-Active message does not contain a 2670 Routing Context, the receiver must know, via configuration data, which 2671 AS pools the ASP will be a member. 2673 When an ASP Active (ASPAC) message is received, the SG or IPSP responds 2674 to the ASP with an ASPAC Ack message, acknowledging that the ASPAC was 2675 received and, depending on the ASPAC Type value received, moves the ASP 2676 to the "Active" or "Standby" state within the associated Application 2677 Server(s). The ASP MUST not send Data messages before receiving an 2678 ASPAC Ack. If the SG or IPSP receives any Data messages before an 2679 ASPAC is received, the SG or IPSP should discard them. 2681 There are two modes of Application Server traffic handling in the SG 2682 M3UA - Over-ride and Load-share. The Type parameter in the ASPAC 2683 message indicates the traffic handling mode used in a particular 2684 Application Server. If the SG determines that the mode indicated in an 2685 ASPAC is incompatible with the mode currently used in the AS, the SG 2686 responds with an Error message indicating "Invalid Traffic Handling 2687 Mode". 2689 In the case of an Over-ride mode AS, reception of an ASPAC message at 2690 an SG causes the redirection of all traffic for the AS to the ASP that 2691 sent the ASPAC. Any previously active ASP in the AS is now considered 2692 Inactive and will no longer receive traffic from the SG within the AS. 2693 The SG or IPSP sends a Notify (Alternate ASP-Active) to the previously 2694 active ASP in the AS, after stopping all traffic to that ASP. In the 2695 case of Over-ride (Standby) mode the actions are the same with the 2696 exception that the traffic is not started to the ASP until the 2697 previously active ASP transitions to "Inactive or "Down" state. At 2698 this point the ASP that sent the Over-Ride (Standby) ASPAC is moved to 2699 the Active state and the traffic is redirected. A Notify message is 2700 not sent in this case. 2702 In the case of a Load-share mode AS, reception of an ASPAC message at 2703 an SG or IPSP causes the direction of traffic to the ASP sending the 2704 ASPAC, in addition to all the other ASPs that are currently active in 2705 the AS. The algorithm at the SG for load-sharing traffic within an AS 2706 to all the active ASPs is implementation dependent. The algorithm 2707 could, for example be round-robin or based on information in the Data 2708 message (e.g., such as the SLS, SCCP SSN, ISUP CIC value). 2710 Depending on the requirements of the application and the 2711 call/transaction state handling assumptions of the collection of ASPs 2712 in the AS. The SG or IPSP responds to the ASPAC with an ASP-Active Ack 2713 message to the ASP. N the case of Loadshare (Standby) mode, the 2714 actions are the same with the exception that the traffic is not started 2715 to the ASP until the SG or IPSP determines that there are insufficient 2716 resources available in the AS. This is likely due to one of the active 2717 loadsharing ASPs transitions to the "Inactive" or "Down" state. At 2718 this point the ASP that sent the Loadshare (Standby) ASPAC s moved to 2719 the Active state and traffic is started. A Notify message is not sent 2720 in this case. 2722 All ASPs within a loadsharing mode AS must be able to handle any 2723 traffic within the AS, in order to accommodate any potential fail-over 2724 or rebalancing of the offered load. 2726 A node that receives an ASPAC with an incorrect Type for a particular 2727 Routing Context will respond with an Error Message (Cause: Invalid 2728 Traffic Handling Mode). A node that receives an unknown Routing 2729 Context value responds with an Error message (Cause: Invalid Routing 2730 Context). 2732 4.3.3.5 ASP Inactive 2734 When an ASP wishes to withdraw from receiving traffic within an AS, the 2735 ASP sends an ASP Inactive (ASPIA) to the SG or IPSP. In the case where 2736 an ASP is processing the traffic for more than one Application Server 2737 across a common SCTP association, the ASPIA contains one or more 2738 Routing Contexts to indicate for which Application Servers the ASPIA 2739 applies. In the case where an ASP-Inactive message does not contain a 2740 Routing Context, the receiver must know via configuration data which AS 2741 pools the ASP is a member and move the ASP to the "Inactive" state in 2742 each AS. 2744 There are two modes of Application Server traffic handling in the SG or 2745 IPSP M3UA when withdrawing an ASP from service - Over-ride and Load- 2746 share. The Type parameter in the ASPIA message indicates the mode used 2747 in a particular Application Server. If the SG or IPSP determines that 2748 the mode indicates in an ASPIA is inconsistent with the traffic 2749 handling mode currently used in the AS, a this is reported to local 2750 management indicating("Invalid Traffic Handling Mode"). The ASPIA is 2751 still processed. 2753 In the case of an Over-ride mode AS, where another ASP has already 2754 taken over the traffic within the AS with an Over-ride ASPAC, the ASP 2755 that sends the ASPIA is already considered by the SG to be "Inactive". 2756 An ASPIA Ack message is sent to the ASP, after ensuring that all 2757 traffic is stopped to the ASP. In the case where another ASP has 2758 already sent an Over-ride (Standby) ASPAC, the ASP is moved to the 2759 "Inactive state" and traffic s immediately started to the standby ASP. 2761 In the case of a Load-share mode AS, the SG moves the ASP to the 2762 "Inactive" state and the AS traffic is re-allocated across the 2763 remaining "active" ASPs per the load-sharing algorithm currently used 2764 within the AS. A NTFY(Insufficient ASPs) may be sent to all inactive 2765 ASPs, if required. However, if a Loadshare (Standby) ASP is available, 2766 it may be now immediately included in the loadshare group and a Notify 2767 message is not sent. An ASPIA Ack message is sent to the ASP after all 2768 traffic is halted. 2770 If no other ASPs are "Active" or "Standby" in the Application Server, 2771 the SG sends a NTFY(AS-Pending) to all inactive ASPs of the AS and 2772 either discards all incoming messages for the AS or starts buffering 2773 the incoming messages for T(r)seconds, after which messages will be 2774 discarded. T(r) is configurable by the network operator. If the SG 2775 receives an ASPAC from an ASP in the AS before expiry of T(r), the 2776 buffered traffic is directed to the ASP and the timer is cancelled. If 2777 T(r) expires, the AS is moved to the "Down" state. 2779 4.3.3.6 Notify 2781 A Notify message reflecting a change in the AS state is sent to all 2782 ASPs in the AS, except those in the "Down" state, with appropriate 2783 Status Identification. 2785 In the case where a Notify (AS-Pending) message is sent by an SG that 2786 now has no ASPs active to service the traffic, or a NTFY(Insufficient 2787 ASPs) is sent in the Loadshare mode, the Notify does not explicitly 2788 force the ASP(s) receiving the message to become active. The ASPs 2789 remain in control of what (and when) action is taken. 2791 4.3.3.7 Heartbeat 2793 The optional Heartbeat procedures may be used when operating over 2794 transport layers that do not have their own heartbeat mechanism for 2795 detecting loss of the transport association (i.e., other than the 2796 SCTP). 2798 After receiving an ASP-Up Ack message from an M3UA peer in response to 2799 an ASP-Up message, an ASP may optionally send Beat messages 2800 periodically, subject to a provisionable timer T(beat). Upon receiving 2801 a BEAT message, the M3UA peer MUST respond with a BEAT ACK 2802 message. If no BEAT ACK message (or any other M3UA message), is 2803 received by the ASP within the timer 2*T(beat), the ASP will consider 2804 the remote M3UA peer as "Down". 2806 At the ASP, if no BEAT ACK message (or any other M3UA message) is 2807 received from the M3UA peer within 2*T(beat), the remote M3UA peer is 2808 considered unavailable. Transmission of BEAT messages is stopped and 2809 ASP-Up procedures are used to re-establish communication with the SG 2810 M3UA peer. 2812 The BEAT message may optionally contain an opaque Heartbeat Data 2813 parameter that MUST be echoed back unchanged in the related Beat Ack 2814 message. The ASP upon examining the contents of the returned BEAT Ack 2815 message MAY choose to consider the remote ASP as unavailable. The 2816 contents/format of the Heartbeat Data parameter is implementation- 2817 dependent and only of local interest to the original sender. The 2818 contents may be used, for example, to support a Heartbeat sequence 2819 algorithm (to detect missing Heartbeats), and/or a timestamp mechanism 2820 (to evaluate delays). 2822 Note: Heartbeat related events are not shown in Figure 4 "ASP state 2823 transition diagram". 2825 4.4 Procedures to support the M3UA services 2827 4.4.1 At an SG 2829 On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication 2830 primitive from the nodal inter-working function at an SG, the SG M3UA 2831 layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message 2832 (see Section 2) to the M3UA peers at concerned ASPs. The M3UA layer 2833 must fill in various fields of the SSNM messages consistently with the 2834 information received in the primitives. 2836 The SG M3UA determines the set of concerned ASPs to be informed based 2837 on the SS7 network partition for which the primitive indication is 2838 relevant. In this way, all ASPs configured to send/receive traffic 2839 within a particular network appearance are informed. If the SG 2840 operates within a single SS7 network appearance, then all ASPs are 2841 informed. 2843 Optionally, the SG M3UA may filter further based on the Affected Point 2844 Code in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives. 2845 In this way ASPs can be informed only of affected destinations to which 2846 they actually communicate. The SG M3UA may also suppress DUPU messages 2847 to ASPs that do not implement an MTP3-User protocol peer for the 2848 affected MTP3-User. 2850 DUNA, DAVA, SCON messages must be sent on a sequenced stream as these 2851 primitives should arrive in order. Stream 0 is used. Sequencing is 2852 not required for the DUPU or DAUD message, which may optionally be sent 2853 un-sequenced. The same applies for the SCON message if the 2854 international congestion method (see Q.704) is used. 2856 4.4.2 At an ASP 2858 4.4.2.1 Single SG configurations 2860 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 2861 the M3UA layer invokes the appropriate primitive indications to the 2862 resident M3UA-Users. Local management is informed. 2864 In the case where a local event has caused the unavailability or 2865 congestion status of SS7 destinations, the M3UA at the ASP should pass 2866 up appropriate indications n the primitives to the M3UA User, as though 2867 equivalent SSNM messages were received. For example, the loss of an 2868 SCTP association to an SG may cause the unavailability of a set of SS7 2869 destinations. MTP-Pause indications to the M3UA User is appropriate. 2870 To accomplish this, the M3UA layer at an ASP maintains the status of 2871 routes via the SG, much like an MTP3 layer maintains route-set status. 2873 4.4.2.2 Multiple SG configurations 2875 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 2876 the 2877 M3UA layer updates the status of the affected route(s) via the 2878 originating SG and determines, whether or not the overall availability 2879 or congestion status of the effected destination(s) has changed. In 2880 this case the M3UA layer invokes the appropriate primitive indications 2881 to the resident M3UA-Users. Local management is informed. 2883 4.4.3 ASP Auditing 2885 An ASP may optionally initiate an audit procedure in order to enquire 2886 of an SG the availability and, if the congestion method with multiple 2887 congestion levels and message priorities is used, congestion status of 2888 an SS7 destination or set of destinations. A Destination Audit (DAUD) 2889 message is sent from the ASP to the SG requesting the current 2890 availability and congestion status of one or more SS7 Destination Point 2891 Codes. 2893 The DAUD may be sent un-sequenced. The DAUD may be sent by the ASP in 2894 the following cases: 2896 - Periodic. A Timer originally set upon reception of DUNA or SCON 2897 message has expired without a subsequent DAVA, DUNA or SCON 2898 updating the availability/congestion status of the affected 2899 Destination Point Codes. The Timer is reset upon issuing a DAUD. 2900 In this case the DAUD is sent to the SG that originally sent the 2901 SSNM message. 2903 - the ASP is newly "Inactive" or "Active" or has been isolated from 2904 an SG for an extended period. The ASP can request the 2905 availability/congestion status of one or more SS7 destinations to 2906 which it expects to communicate. 2908 In the first case, the DAUD procedure must not be invoked for the case 2909 of received SCON containing a congestion level value of "no 2910 congestion" or undefined" (i.e., congestion Level = "0"). This is 2911 because the value indicates either congestion abatement or that the ITU 2912 MTP3 international congestion method is being used. In the 2913 international congestion method, the MTP3 at the SG MTP3 does not 2914 maintain the congestion status of any destinations and therefore the SG 2915 cannot provide any congestion information in response to the DAUD. For 2916 the same reason, in the second case a DAUD cannot reveal any congested 2917 destination(s). 2919 The SG MUST respond to a DAUD with the MTP3 status of the routeset 2920 associated with each Destination Point Code(s) in the DAUD. The status 2921 of each SS7 destination requested is indicated in a DUNA (if 2922 unavailable), DAVA (if available/uncongested) or an SCON (if 2923 available/congested). Optionally, any DUNA or DAVA message in response 2924 to a DAUD may contain a list of up to sixteen Affected Point Codes. 2926 Note that from the point of view of an ASP sending an DAUD, the 2927 subsequent reception of an SCON implies that the Affected Destination 2928 is available. The reception of a DAVA implies that the routeset to the 2929 Affected Destination is not congested. Obviously with the reception of 2930 an DUNA, the routeset to the Affected Destination can not also be 2931 congested. 2933 5.0 Examples of M3UA Procedures 2935 5.1 Establishment of Association and Traffic between SGs and ASPs 2937 5.1.1 Single ASP in an Application Server ("1+0" sparing) 2939 This scenario shows the example M3UA message flows for the 2940 establishment of traffic between an SG and an ASP, where only one ASP 2941 is configured within an AS (no backup). It is assumed that the SCTP 2942 association is already set-up. The sending of DUNA/SCON messages by the 2943 SG is not shown but would be similar to 5.1.2. 2945 SG ASP1 2946 | 2947 |<---------ASP Up----------| 2948 |-------ASP-Up Ack-------->| 2949 | | 2950 |<-------ASP Active--------| 2951 |-----ASP Active Ack------>| 2952 | | 2954 5.1.2 Two ASPs in Application Server ("1+1" sparing) 2956 This scenario shows the example M3UA message flows for the 2957 establishment of traffic between an SG and two ASPs in the same 2958 Application Server, where ASP1 is configured to be "active" and ASP2 a 2959 "standby" in the event of communication failure or the withdrawal from 2960 service of ASP1. ASP2 may act as a hot, warm, or cold standby 2961 depending on the extent to which ASP1 and ASP2 share call/transaction 2962 state or can communicate call state under failure/withdrawal events. 2963 The example message flow is the same whether the ASP-Active messages 2964 are Over-ride or Load-share mode although typically this example would 2965 use an Over-ride mode. In the case of MTP Restart, the SG starts 2966 sending any relevant DUNA and SCON messages to the ASPs as soon as they 2967 enter the ASP-INACTIVE state. The ASP-Active Ack message is only sent 2968 after all relevant DUNA/SCON messages have been transmitted to the 2969 concerned ASP. 2971 SG ASP1 ASP2 2972 | | | 2973 |<--------ASP Up----------| | 2974 |-------ASP-Up Ack------->| | 2975 | | | 2976 |<-----------------------------ASP Up----------------| 2977 |-----------------------------ASP-Up Ack------------>| 2978 | | | 2979 | | | 2980 |<-------ASP Active-------| | 2981 |------ASP-Active Ack---->| | 2982 | | | 2984 5.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing 2985 case) 2987 This scenario shows a similar case to Section 4.1.2 but where the two 2988 ASPs are brought to "active" and load-share the traffic load. In this 2989 case, one ASP is sufficient to handle the total traffic load. The 2990 sending of DUNA/SCON messages by the SG is not shown but would be 2991 similar to 5.1.2. 2993 SG ASP1 ASP2 2994 | | | 2995 |<---------ASP Up---------| | 2996 |--------ASP-Up Ack------>| | 2997 | | | 2998 |<------------------------------ASP Up---------------| 2999 |-----------------------------ASP Up Ack------------>| 3000 | | | 3001 | | | 3002 |<--ASP Active (Ldshr)----| | 3003 |-----ASP-Active Ack----->| | 3004 | | | 3005 |<----------------------------ASP Active (Ldshr)-----| 3006 |-------------------------------ASP-Active Ack------>| 3007 | | | 3009 5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 3010 case) 3012 This scenario shows the example M3UA message flows for the 3013 establishment of traffic between an SG and three ASPs in the same 3014 Application Server, where two of the ASPs are brought to "active" and 3015 share the load. In this case, a minimum of two ASPs are required to 3016 handle the total traffic load (2+1 sparing). The sending of DUNA/SCON 3017 messages by the SG is not shown but would be similar to 5.1.2. 3019 SG ASP1 ASP2 ASP3 3020 | | | | 3021 |<------ASP Up-------| | | 3022 |-----ASP-Up Ack---->| | | 3023 | | | | 3024 |<--------------------------ASP Up-------| | 3025 |-------------------------ASP-Up Ack)--->| | 3026 | | | | 3027 |<---------------------------------------------ASP Up--------| 3028 |---------------------------------------------ASP-Up Ack---->| 3029 | | | | 3030 | | | | 3031 |<--ASP Act (Ldshr)--| | | 3032 |----ASP-Act Ack---->| | | 3033 | | | | 3034 |<--------------------ASP Act. (Ldshr)---| | 3035 |-----------------------ASP-Act Ack----->| | 3036 | | | | 3038 5.2 ASP Traffic Fail-over Examples 3040 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 3042 Following on from the example in Section 4.1.2, and ASP withdraws from 3043 service: 3045 SG ASP1 ASP2 3046 | | | 3047 |<-----ASP Inactive-------| | 3048 |----ASP Inactive Ack---->| | 3049 |------------------------NTFY(AS-Inact.)(Optional)-->| 3050 | | | 3051 |<------------------------------ ASP Active----------| 3052 |------------------------------ASP-Active Ack)------>| 3053 | | 3055 Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or 3056 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 3057 exchange would not occur. 3059 5.2.2 (1+1 Sparing, Back-up Over-ride) 3061 Following on from the example in Section 4.1.2, and ASP2 wishes to 3062 over-ride ASP1 and take over the traffic: 3064 SG ASP1 ASP2 3065 | | | 3066 |<------------------------------ ASP Active----------| 3067 |-------------------------------ASP-Active Ack------>| 3068 |----NTFY(Alt ASP-Act)--->| 3069 | | | 3071 5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) 3073 Following on from the example in Section 4.1.4, and ASP1 withdraws from 3074 service: 3076 SG ASP1 ASP2 ASP3 3077 | | | | 3078 |<----ASP Inact.-----| | | 3079 |---ASP-Inact Ack--->| | | 3080 | | | | 3081 |---------------------------------NTFY(Ins. ASPs)(Optional)->| 3082 | | | | 3083 |<-----------------------------------------ASP Act (Ldshr)---| 3084 |-------------------------------------------ASP Act (Ack)--->| 3085 | | | | 3087 The Notify message to ASP3 is optional, as well as the ASP-Active from 3088 ASP3. The optional Notify can only occur if the SG maintains knowledge 3089 of the minimum ASP resources required - for example if the SG knows 3090 that "n+k" = "2+1" for a load-share AS and "n" currently equals "1". 3092 Note: If the SG detects loss of the ASP1 M3UA peer (M3UA heartbeat loss 3093 or detection of SCTP failure), the first SG-ASP1 ASP Inactive message 3094 exchange would not occur. 3096 5.3 M3UA/MTP3-User Boundary Examples 3098 5.3.1 At an ASP 3100 This section describes the primitive mapping from the MTP3 User to M3UA 3101 at an ASP. 3103 5.3.1.1 Support for MTP-Transfer on the ASP 3105 5.3.1.1.1 Support for MTP-Transfer Request 3106 When the MTP3-User on the ASP has data to send into the SS7 network, it 3107 will use the MTP-Transfer Request primitive. The M3UA on the ASP will 3108 do the following when it receives an MTP-Transfer Request primitive 3109 from the M3UA user: 3111 - Determine the correct SG 3113 - Determine the correct association to the chosen SG 3115 - Determine the correct stream in the association (e.g., based on 3116 SLS) 3118 - Determine whether to complete the optional fields of the Data 3119 message 3121 - Map the MTP-Transfer Request primitive into the Protocol Data 3122 field of an m3ua Data message 3124 - Send the Data message to the remote M3UA peer in the SG, over the 3125 SCTP association 3127 SG ASP 3128 | | 3129 |<-----Data Message-------|<--MTP-Transfer req. 3130 | | 3132 5.3.1.1.2 Support for MTP Transfer Indication 3134 When the M3UA on the ASP has received Data messages from the remote 3135 M3UA peer in the SG it will do the following: 3137 - Evaluate the optional fields of the Data message if present 3139 - Map the Payload of a Data message into the MTP-Transfer Indication 3140 primitive 3142 - Pass the MTP-Transfer Indication primitive to the user part. In 3143 case of multiple user parts, the optional fields of the Data 3144 message are used to determine the concerned user part. 3146 SG ASP 3147 | | 3148 |------Data Message------>|---MTP-Transfer ind. 3149 | | 3151 5.3.1.1.3 Support for ASP Querying of SS7 Destination States 3153 There are situations such as temporary loss of connectivity to the SG 3154 that may cause the M3UA on the ASP to audit SS7 destination 3155 availability states. Note: there is no primitive for the MTP3-User to 3156 request this audit from the M3UA as this is initiated by an internal 3157 M3UA management function. 3159 The M3UA on the ASP normally sends Destination State Audit (DAUD) 3160 messages for each of the destinations that the ASP supports. 3162 SG ASP 3163 | | 3164 |<-----DAUD Message ------| 3165 |<-----DAUD Message ------| 3166 |<-----DAUD Message ------| 3167 | | 3168 | | 3170 5.3.2 At an SG 3172 This section describes the MTP3 upper layer primitive mapping to the 3173 M3UA at the SG. 3175 5.3.2.1 Support for MTP-Transfer Request at the SG 3177 When the M3UA on the SG has received Data messages from its peer 3178 destined to the SS7 network it will do the following: 3180 - Evaluate the optional fields of the Data message if present to 3181 determine the network appearance 3183 - Map the Protocol data of the Data message into an MTP-Transfer 3184 Request primitive 3186 - Pass the MTP-Transfer Request primitive to the MTP3 of the 3187 concerned network appearance. 3189 SG ASP 3190 | | 3191 <---MTP-Transfer req.|<------Data Message------| 3192 | | 3194 5.3.2.2 Support for MTP-Transfer Indication at the SG 3196 When the MTP3 on the SG has data to pass its user parts, it will use 3197 the MTP-Transfer Indication primitive. The M3UA on the SG will do the 3198 following when it receives an MTP-Transfer Indication: 3200 - Determine the correct ASP 3202 - Determine the correct association to the chosen ASP 3204 - Determine the correct stream in the association (e.g., based on 3205 SLS) 3207 - Determine whether to complete the optional fields of the Data 3208 message 3210 - Map the MTP-Transfer Indication primitive into the Protocol Data 3211 field of an M3UA Data message 3213 - Send the Data message to the remote M3UA peer in the ASP, over the 3214 SCTP association 3216 SG ASP 3217 | | 3218 --MTP-Transfer ind.->|------Data Message------>| 3219 | | 3221 5.3.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS 3223 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the 3224 MTP3 upper layer interface at the SG need to be made available to the 3225 remote MTP3 User Part lower layer interface at the concerned ASP(s). 3227 5.3.2.3.1 Destination Unavailable 3229 The MTP3 on the SG will generate an MTP-PAUSE primitive when it 3230 determines locally that an SS7 destination is unreachable. The M3UA 3231 will map this primitive to a Destination Unavailable (DUNA) message. 3232 The SG M3UA determines the set of concerned ASPs to be informed based 3233 on internal SS7 network information associated with the MTP-PAUSE 3234 primitive indication. 3236 SG ASP 3237 | | 3238 --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.--> 3239 | | 3241 5.3.2.3.2 Destination Available 3243 The MTP3 on the SG will generate an MTP-RESUME primitive when it 3244 determines locally that an SS7 destination that was previously 3245 unreachable is now reachable. The M3UA will map this primitive to a 3246 Destination Available (DAVA) message. The SG M3UA determines the set 3247 of concerned ASPs to be informed based on internal SS7 network 3248 information associated with the MTP-RESUME primitive indication. 3250 SG ASP 3251 | | 3252 --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.--> 3253 | | 3255 5.3.2.3.3 SS7 Network Congestion 3257 The MTP3 on the SG will generate an MTP-STATUS primitive when it 3258 determines locally that the route to an SS7 destination is congested. 3259 The M3UA will map this primitive to a SS7 Network Congestion State 3260 (SCON) message. It will determine which ASP(s) to send the DUPU to 3261 based on the intended Application Server. 3263 SG ASP 3264 | | 3265 --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.--> 3266 | | 3268 5.3.2.3.4 Destination User Part Unavailable 3270 The MTP3 on the SG will generate an MTP-STATUS primitive when it 3271 receives an UPU message from the SS7 network. The M3UA will map this 3272 primitive to a Destination User Part Unavailable (DUPU) message. It 3273 will determine which ASP(s) to send the DUPU based on the intended 3274 Application Server. 3276 SG ASP 3277 | | 3278 --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.--> 3279 | | 3281 6.0 Security 3283 6.1 Introduction 3285 M3UA is designed to carry signalling messages for telephony services. 3286 As such, M3UA must involve the security needs of several parties: the 3287 end users of the services; the network providers and the applications 3288 involved. Additional requirements may come from local regulation. 3289 While having some overlapping security needs, any security solution 3290 should fulfill all of the different parties' needs. 3292 6.2 Threats 3294 There is no quick fix, one-size-fits-all solution for security. As a 3295 transport protocol, M3UA has the following security objectives: 3297 * Availability of reliable and timely user data transport. 3298 * Integrity of user data transport. 3299 * Confidentiality of user data. 3301 M3UA runs on top of SCTP. SCTP [6] provides certain transport related 3302 security features, such as some protection against: 3304 * Blind Denial of Service Attacks 3305 * Flooding 3306 * Masquerade 3307 * Improper Monopolization of Services 3309 When M3UA is running in professionally managed corporate or service 3310 provider network, it is reasonable to expect that this network includes 3311 an appropriate security policy framework. The "Site Security Handbook" 3312 [21] should be consulted for guidance. 3314 When the network in which M3UA runs in involves more than one party, it 3315 may not be reasonable to expect that all parties have implemented 3316 security in a sufficient manner. In such a case, it is recommended 3317 that 3319 IPSEC is used to ensure confidentiality of user payload. Consult [22] 3320 for more information on configuring IPSEC services. 3322 6.3 Protecting Confidentiality 3324 Particularly for mobile users, the requirement for confidentiality may 3325 include the masking of IP addresses and ports. In this case 3326 application level encryption is not sufficient; IPSEC ESP should be 3327 used instead. Regardless of which level performs the encryption, the 3328 IPSEC ISAKMP service should be used for key management. 3330 7.0 IANA Considerations 3332 A request will be made to IANA to assign an M3UA value for the Payload 3333 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 3334 Payload Protocol Identifier will be registered: 3336 M3UA "3" 3338 The SCTP Payload Protocol Identifier is included in each SCTP Data 3339 chunk, to indicate which protocol the SCTP is carrying. This Payload 3340 Protocol Identifier is not directly used by SCTP but may be used by 3341 certain network entities to identify the type of information being 3342 carried in a Data chunk. 3344 The User Adaptation peer may use the Payload Protocol Identifier as a 3345 way of determining additional information about the data being 3346 presented to it by SCTP. 3348 8.0 Acknowledgements 3350 The authors would like to thank John Loughney, Neil Olson, Michael 3351 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 3352 Prantner, Barry Nagelberg, Naoto Makinae for their valuable comments 3353 and suggestions. 3355 9.0 References 3357 [1] RFC 2719, "Framework Architecture for Signaling Transport" 3359 [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) 3360 - ISDN User Part (ISUP)' 3362 [3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part 3364 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 3365 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 3366 international interface; Part 1: Basic services" 3368 [5] ITU-T Recommendations Q.711-715, 'Signalling System No. 7 (SS7) - 3369 Signalling Connection Control Part (SCCP)' 3371 [6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection 3372 Control Part' 3374 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 3375 Signalling System No.7; Signalling Connection Control Part (SCCP) 3376 (connectionless and connection-oriented class 2) to support 3377 international interconnection; Part 1: Protocol specification" 3379 [8] ITU-T Recommendations Q.720, 'Telephone User Part' 3381 [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - 3382 Transaction Capabilities (TCAP) 3384 [10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities 3385 Application Part' 3387 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 3388 Signalling System No.7; Transaction Capabilities (TC) version 2; 3389 Part 1: Protocol specification" 3391 [12] 3G TS 25.410 V3.1.0 (2000-01) Technical Specification - 3rd 3392 Generation partnership Project; Technical Specification Group 3393 Radio Access Network; UTRAN Iu Interface: General Aspects and 3394 Principles (3G TS 25.410 Version 3.1.0 Release 1999) 3396 [13] Stream Control Transport Protocol , July 2000, Work in Progress 3399 [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7) 3400 - Message Transfer Part (MTP)' 3402 [15] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' 3404 [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 3405 Signalling System No.7; Message Transfer Part (MTP) to support 3406 international interconnection; Part 1: Protocol specification" 3408 [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service 3409 Specific Coordination Function for signalling at the Network Node 3410 Interface (SSCF at NNI) 3412 [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service 3413 Specific Connection Oriented Protocol (SSCOP) 3415 [19] MTP2-User Adaptation Layer , Nov. 3416 1999, Work in Progress 3418 [20] ITU-T Recommendation Q.2210 'B-ISDN MTP' 3420 [21] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 3422 [22] RFC 2401, "Security Architecture for the Internet Protocol", S. 3423 Kent, R. Atkinson, November 1998. 3425 10.0 Author's Addresses 3427 Lyndon Ong 3428 Nortel Networks 3429 4401 Great America Pkwy 3430 Santa Clara, CA, USA 95054 3431 long@nortelnetworks.com 3433 Greg Sidebottom 3434 Nortel Networks 3435 3685 Richmond Rd, 3436 Nepean, Ontario, Canada K2H 5B7 3437 gregside@nortelnetworks.com 3438 Guy Mousseau 3439 Nortel Networks 3440 3685 Richmond Rd 3441 Nepean, Ontario, Canada K2H 5B7 3443 Ian Rytina 3444 Ericsson Australia 3445 37/360 Elizabeth Street 3446 Melbourne, Victoria 3000, Australia 3447 ian.rytina@ericsson.com 3449 Hanns Juergen Schwarzbauer 3450 SIEMENS AG 3451 Hofmannstr. 51 3452 81359 Munich, Germany 3453 HannsJuergen.Schwarzbauer@icn.siemens.de 3455 Klaus D. Gradischnig 3456 SIEMENS AG 3457 Hofmannstr. 51 3458 81359 Munich, Germany 3459 klaus.gradischnig@icn.siemens.de 3461 Ken Morneault 3462 Cisco Systems Inc. 3463 13615 Dulles Technology Drive 3464 Herndon, VA, USA 20171 3465 EMail: kmorneau@cisco.com 3467 Malleswar Kalla 3468 Telcordia Technologies 3469 MCC 1J211R 3470 445 South Street 3471 Morristown, NJ, USA 07960 3472 EMail: kalla@research.telcordia.com 3474 Normand Glaude 3475 Performance Technologies 3476 150 Metcalf Sreet, Suite 1300 3477 Ottawa, Ontario, Canada K2P 1P1 3478 EMail: nglaude@microlegend.com 3480 This draft expires March 2000.