idnits 2.17.1 draft-ietf-sigtran-m3ua-03.txt: -(141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2640): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 23 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 64 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 1027: '...The keywords MUST, MUST NOT, REQUIRED,...' RFC 2119 keyword, line 1028: '...NOT, RECOMMENDED, NOT RECOMMENDED, MAY...' RFC 2119 keyword, line 1054: '... an M3UA message MUST be transmitted i...' RFC 2119 keyword, line 1171: '... Value fields) MUST be a multiple of...' RFC 2119 keyword, line 1176: '... receiver MUST ignore the padding by...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2470 has weird spacing: '...of received S...' -- 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 (June 2000) is 8708 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 1030 ** 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: 9 errors (**), 0 flaws (~~), 5 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 6 Siemens 7 Ken Morneault 8 Cisco 9 Mallesh Kalla 10 Telcordia 11 Normand Glaude 12 Performance Technologies 14 Expires in six months June 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 To learn the current status of any Internet-Draft, please check the 39 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 40 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 41 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 42 ftp.isi.edu (US West Coast). 44 Abstract 46 This Internet Draft defines a protocol for supporting the transport of 47 any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP 48 using the services of the Stream Control Transmission Protocol. Also, 49 provision is made for protocol elements that enable a seamless operation 50 of the MTP3-User peers in the SS7 and IP domains. This protocol would be 51 used between a Signalling Gateway (SG) and a Media Gateway Controller 52 (MGC) or IP-resident Database. It is assumed that the SG receives SS7 53 signalling over a standard SS7 interface using the SS7 Message Transfer 54 Part (MTP) to provide transport. 56 TABLE OF CONTENTS 58 1. Introduction.......................................................3 59 1.1 Scope.........................................................3 60 1.2 Terminology...................................................3 61 1.3 M3UA Overview.................................................5 62 1.4 Functional Areas.............................................10 63 1.5 Sample Configurations........................................18 64 1.6 Definition of M3UA Boundaries................................21 65 2. Conventions.......................................................22 66 3. M3UA Protocol Elements............................................22 67 3.1 Common Message Header........................................22 68 3.2 Transfer Messages............................................24 69 3.3 SS7 Signalling Network management (SSNM) Messages............26 70 3.4 Application Server Process Maintenance Messages..............32 71 3.5 Management Messages..........................................40 72 4. Procedures........................................................44 73 4.1 Procedures to Support the Services of the M3UA Layer.........44 74 4.2 Procedures to Support the M3UA Services in Section 1.4.2.....44 75 4.3 Procedures to Support the M3UA Services in Section 1.4.4.....45 76 4.4 Procedures to Support the M3UA Services in Section 1.4.3.....52 77 5. Examples of M3UA Procedures.......................................54 78 5.1 Establishment of Association and Traffic 79 Between SGs and ASPs.........................................54 80 5.2 ASP traffic Fail-over Examples...............................56 81 5.3 M3UA/MTP3-User Boundary Examples.............................57 82 6. Security..........................................................61 83 6.1 Introduction.................................................61 84 6.2 Threats......................................................61 85 6.3 Protecting Confidentiality...................................62 86 7. IANA Considerations...............................................62 87 8. Acknowledgements..................................................62 88 9. References........................................................62 89 10. Author's Addresses...............................................65 90 1. Introduction 92 1.1 Scope 94 There is a need for SCN signalling protocol delivery from an SS7 95 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP- 96 resident Database as described in the Framework Architecture for 97 Signalling Transport [1]. The delivery mechanism should meet the 98 following criteria: 100 * Support for the transfer of all SS7 MTP3-User Part messages (e.g., 101 ISUP, SCCP, TUP, etc.) 102 * Support for the seamless operation of MTP3-User protocol peers 103 * Support for the management of SCTP transport associations and traffic 104 between an SG and one or more MGCs or IP-resident Databases 105 * Support for MGC or IP-resident Database process fail-over and load- 106 sharing 107 * Support for the asynchronous reporting of status changes to 108 management 110 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 111 protocols and deliver ISUP, SCCP and/or any other MTP3-User protocol 112 messages over SCTP transport associations to MTP3-User peers in MGCs or 113 IP-resident Databases. 115 1.2 Terminology 117 Application Server (AS) - A logical entity serving a specific Routing 118 Key. An example of an Application Server is a virtual switch element 119 handling all call processing for a unique range of PSTN trunks, 120 identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual 121 database element, handling all HLR transactions for a particular SS7 122 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more 123 unique Application Server Processes, of which one or more is normally 124 actively processing traffic. 126 Application Server Process (ASP) - A process instance of an Application 127 Server. An Application Server Process serves as an active or standby 128 process of an Application Server (e.g., part of a distributed virtual 129 switch or database). Examples of ASPs are processes (or process 130 instances of) MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- 131 point and may be configured to process signalling traffic within more 132 than one Application Server. 134 Association - An association refers to an SCTP association. The 135 association provides the transport for MTP3-User protocol data units and 136 M3UA adaptation layer peer messages. 138 IP Server Process (IPSP) � A process instance of an IP-based 139 application. An IPSP is essentially the same as an ASP, except that it 140 uses MU3A in a peer-to-peer fashion. Conceptually, an IPSP does not use 141 the services of a signalling gateway.Signalling Gateway Process (SGP) � 142 A process instance of a Signalling Gateway. It serves as an active, 143 standby or load-sharing process of a Signalling Gateway. 145 Signalling Process � A process instance that uses M3UA to communicate 146 with other signalling process. An ASP, a signalling gateway process and 147 an IPSP are all signalling processes. 149 Routing Key: A Routing Key describes a set of SS7 parameter and 150 parameter values that uniquely define the range of signalling traffic to 151 be handled by a particular Application Server. For example, where all 152 traffic directed to an SS7 DPC, OPC and ISUP CIC_range(s) or SCCP SSN is 153 to be sent to a particular Application Server, that SS7 data defines the 154 associated Routing Key. Routing Keys are unique in the sense that a 155 received SS7 signalling message cannot be directed to more than one 156 Routing Key. Also, a Routing Key cannot extend across more than a 157 single SS7 DPC, in order to more easily support SS7 Management 158 procedures. It is not necessary for the parameter range values within a 159 particular Routing Key to be contiguous. For example, an ASP could be 160 configured to support call processing for multiple ranges of PSTN trunks 161 that are not represented by contiguous CIC values. 163 Routing Context � An Application Server Process may be configured to 164 process traffic related to more than one Application Server, over a 165 single SCTP Association. At an ASP, the Routing Context parameter 166 uniquely identifies the traffic associated with each Application Server 167 that the ASP is configured to support. There is a 1:1 relationship 168 between a received Routing Context value and a Routing Key entry at the 169 sending node. Therefore the Routing Context can be viewed as an index 170 into a sending node's Message Distribution Table containing the Routing 171 Key entries. 173 Fail-over - The capability to re-route signalling traffic as required to 174 an alternate Application Server Process, or group of ASPs, within an 175 Application Server in the event of failure or unavailability of a 176 currently used Application Server Process. Fail-back may apply upon the 177 return to service of a previously unavailable Application Server 178 Process. 180 Signalling Point Management Cluster (SPMC) - A complete set of 181 Application Servers represented to the SS7 network under the same SS7 182 Point Code. SPMCs are used to sum the availability / congestion / 183 User_Part status of an SS7 destination point code that is distributed in 184 the IP domain, for the purpose of supporting MTP3 management procedures 185 at an SG. In some cases, the SG itself may also be a member of the 186 SPMC. In this case, the SG availability / congestion / User_Part status 187 must also be taken into account when considering any supporting MTP3 188 management actions. 190 MTP � The Message Transfer Part of the SS7 protocol 191 MTP3 � MTP Level 3, the signalling network layer of SS7 192 MTP3-User - Any protocol normally using the services of the SS7 MTP3 193 (e.g., ISUP, SCCP, TUP, etc.). 195 Network Appearance � The Network Appearance identifies an SS7 network 196 context for the purposes of logically separating the signalling traffic 197 between the SG and the Application Server Processes over a common SCTP 198 Association. An example is where an SG is logically partitioned to 199 appear as an element in four separate national SS7 networks. A Network 200 Appearance implicitly defines the SS7 Point Code(s), Network Indicator 201 and MTP3 protocol type/variant/version used within a specific SS7 202 network partition. A physical SS7 route-set or link-set at an SG can 203 appear in only one network appearance. The Network Appearance is not 204 globally significant and requires coordination only between the SG and 205 the ASP. 207 Network Byte Order: Most significant byte first, a.k.a Big Endian. 209 Layer Management � Layer Management is a nodal function that handles the 210 inputs and outputs between the M3UA layer and a local management entity. 212 Host - The computing platform that the ASP process is running on. 214 Stream - A stream refers to an SCTP stream. 216 1.3 M3UA Overview 218 1.3.1 Protocol Architecture. 220 The framework architecture that has been defined for SCN signalling 221 transport over IP [1] uses multiple components, including a common 222 signalling transport protocol and an adaptation module to support the 223 services expected by a particular SCN signalling protocol from its 224 underlying protocol layer. 226 Within the framework architecture, this document defines an MTP3-User 227 adaptation module suitable for supporting the transfer of messages of 228 any protocol layer that is identified to the MTP Level 3 layer, in SS7 229 terms, as a user part. The list of these protocol layers include, but 230 is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection 231 Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP 232 [9,10,11] or RANAP [12] messages are transferred transparently by the 233 M3UA as SCCP payload, as they are SCCP-User protocols. 235 It is recommended that the M3UA use the services of the Stream Control 236 Transmission Protocol (SCTP) [13] as the underlying reliable common 237 signalling transport protocol. This is to take advantage of various SCTP 238 features such as: 240 - Explicit packet-oriented delivery (not stream-oriented); 241 - Sequenced delivery of user messages within multiple streams, 242 with an option for order-of-arrival delivery of individual 243 user messages, 244 - Optional multiplexing of user messages into SCTP datagrams; 245 - Network-level fault tolerance through support of multi-homing 246 at either or both ends of an association; 247 - Resistance to flooding and masquerade attacks; and - Data 248 segmentation to conform to discovered path MTU size. 250 Under certain scenarios, such as back-to-back connections without 251 redundancy requirements, the SCTP functions above may not be necessary. 252 In these cases, it is acceptable to use TCP as the underlying common 253 transport protocol. 255 1.3.2 Services Provided by the M3UA Layer 257 The M3UA Layer at an ASP provides the equivalent set of primitives at 258 its upper layer to the MTP3-Users as provided by the MTP Level 3 to its 259 local users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at 260 an ASP is unaware that the expected MTP3 services are offered remotely 261 from an MTP3 Layer at an SG, and not by a local MTP3 layer. The MTP3 262 layer at an SG may also be unaware that its local users are actually 263 remote user parts over M3UA. In effect, the M3UA extends access to the 264 MTP3 layer services to a remote IP-based application. The M3UA does not 265 itself provide the MTP3 services. 267 The M3UA Layer may also be used for point-to-point signalling between 268 two IP Server Processes (IPSPs). In this case, the M3UA provides the 269 same set of primitives and services at its upper layer as the MTP3. 270 However, in this case the expected MTP3 services are not offered 271 remotely from an SG. The MTP3 services are provided but the procedures 272 to support these services are a subset of the MTP3 procedures due to 273 the simplified point-to-point nature of the IPSP to IPSP relationship. 275 1.3.2.1 Support for the transport of MTP3-User Messages 277 The M3UA provides the transport of MTP-TRANSFER primitives across an 278 established SCTP association between an SG and an ASP and between IPSPs. 279 The MTP-TRANSFER primitives are encoded as MTP3-User messages with 280 attached MTP3 Routing Labels as described in the message format sections 281 of the SCCP and ISUP recommendations. In this way, the SCCP and ISUP 282 messages received from the SS7 network are not re-encoded into a 283 different format for transport to/from the server processes. As well, 284 all the required MTP3 Routing Label information (OPC, DPC, SIO) is 285 available at the ASP and the IPSP as is expected by the MTP3-User 286 protocol layer. 288 The M3UA does not impose a 272-octet user information block limit as 289 specified by the SS7 MTP Level 3 protocol. Larger information blocks 290 can be accommodated directly by M3UA/SCTP, without the need for an upper 291 layer segmentation/re-assembly procedure as specified in recent SCCP or 292 ISUP versions. However, in the context of an SG, the maximum 272-octet 293 block size must be followed when inter-working to a SS7 network that 294 does 295 not support the transfer of larger information blocks to the final 296 destination. This avoids potential ISUP or SCCP fragmentation 297 requirements at the SG. However, if the SS7 network is provisioned to 298 support the Broadband MTP [20] to the final SS7 destination, the 299 information block size limit may be increased past 272 octets. 301 1.3.2.2 Native Management Functions 303 The M3UA provides management of the underlying SCTP transport protocol 304 to ensure that SG-ASP and IPSP-IPSP transport is available to the degree 305 called for by the MTP3-User signalling applications. 307 The M3UA provides the capability to indicate errors associated with 308 received M3UA messages and to notify, as appropriate, local management 309 and/or the peer M3UA. 311 1.3.2.3 Inter-working with MTP3 Network Management Functions 313 At the SG, the M3UA must also provide inter-working with MTP3 management 314 functions to support seamless operation of the user SCN signalling 315 applications in the SS7 and IP domains. This includes: 317 - Providing an indication to MTP3-Users at an ASP that a remote 318 destination in the SS7 network is not reachable. 320 - Providing an indication to MTP3-Users at an ASP that a remote 321 destination in the SS7 network is now reachable. 323 - Providing an indication to MTP3-Users at an ASP that messages to a 324 remote MTP3-User peer in the SS7 network are experiencing SS7 325 congestion 327 - Providing an indication to MTP3-Users at an ASP that a remote MTP3- 328 User peer is unavailable. 330 The M3UA layer at an ASP may initiate an audit of the availability or 331 the congested state of remote SS7 destinations. This information is 332 requested from the M3UA at the SG. 334 1.3.2.4 Support for the management of SCTP associations between the SG 335 and ASPs. 337 The M3UA layer at the SG maintains the availability state of all 338 configured remote ASPs, in order to manage the SCTP Associations and the 339 traffic between the SG and ASPs. As well, the active/inactive state of 340 remote ASPs is also maintained - Active ASPs are those currently 341 receiving traffic from the SG. 343 The M3UA layer may be instructed by local management to establish an 344 SCTP association to a peer M3UA node. This can be achieved using the M- 345 SCTP ESTABLISH primitive to request, indicate and confirm the 346 establishment of an SCTP association with a peer M3UA node. 348 The M3UA layer may also need to inform local management of the status of 349 the underlying SCTP associations using the M-SCTP STATUS request and 350 indication primitive. For example, the M3UA may inform local management 351 of the reason for the release of an SCTP association, determined either 352 locally within the M3UA layer or by a primitive from the SCTP. 354 Also the M3UA layer may need to inform the local management of the 355 change in status of an ASP or AS. This can be achieved using the M-ASP 356 STATUS or M-AS STATUS primitives. 358 1.3.3 Signalling Network Architecture 360 A Signalling Gateway is used to support the transport of MTP3-User 361 signalling traffic received from the SS7 network to multiple distributed 362 ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA protocol 363 description is not designed to meet any performance and reliability 364 requirements for such transport. However, the conjunction of 365 distributed architecture and redundant networks does allow for reliable 366 transport of signalling traffic over IP. The M3UA protocol is flexible 367 enough to allow its operation and management in a variety of physical 368 configurations, enabling Network Operators to meet their performance and 369 reliability requirements. 371 To meet the stringent SS7 signalling reliability and performance 372 requirements for carrier grade networks, these Network Operators should 373 ensure that no single point of failure is present in the end-to-end 374 network architecture between an SS7 node and an IP-based application. 375 This can typically be achieved through the use of redundant SGs, 376 redundant hosts, and the provision of redundant QOS-bounded IP network 377 paths for SCTP Associations between SCTP End Points. Obviously, the 378 reliability of the SG, the MGC and other IP-based functional elements 379 also needs to be taken into account. The distribution of ASPs within 380 the available Hosts must also be considered. As an example, for a 381 particular Application Server, the related ASPs should be distributed 382 over at least two Hosts. 384 Here is one example of a physical network architecture relevant to SS7 385 carrier-grade operation, in the IP network domain, shown in Figure 1 386 below: 388 SG MGC 390 Host#1 ************** ************** Host#1 391 = * ********__*__________________________*__******** * = 392 SG1 * * SGP1 *__*_____ _______________*__* ASP1 * * MGC1 393 * ******** * \ / * ******** * 394 * ********__*______\__/________________*__******** * 395 * * SGP2 *__*_______\/______ _____*__* ASP2 * * 396 * ******** * /\ | | * ******** * 397 * : * / \ | | * : * 398 * ******** * / \ | | * ******** * 399 * * SGPn * * | | | | * * ASPn * * 400 * ******** * | | | | * ******** * 401 ************** | | | | ************** 402 | | \ / 403 Host#2 ************** | | \ / ************** Host#2 404 = * ********__*_____| |______\/_______*__******** * = 405 SG2 * * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2 406 * ******** * / \ * ******** * 407 * ********__*_______________/ \_____*__******** * 408 * * SGP2 *__*__________________________*__* ASP2 * * 409 * ******** * * ******** * 410 * : * SCTP Associations * : * 411 * ******** * * ******** * 412 * * SGPn * * * * ASPn * * 413 * ******** * * ******** * 414 ************** ************** 416 Figure 1 � Physical Model 418 In this model, each host has many application processes. In the case of 419 the MGC, an ASP may provide service to one or more application server, 420 and is identified as an SCTP end point. In the case of the SG, a pair 421 of signalling gateway processes may represent, as an example, a single 422 network appearance, serving a signalling point management cluster. 424 This example model can also be applied to IPSP-IPSP signalling. In this 425 case, each IPSP would have its services distributed across 2 hosts or 426 more, and may have multiple server processes on each host. 428 In the example above, each signalling process (SGP, ASP or IPSP) is the 429 end point to more than one SCTP association, leading to many other 430 signalling processes. To support this, a signalling process must be 431 able to support distribution of M3UA messages to many simultaneous 432 active associations. This message distribution function is based on the 433 status of provisioned routing keys, the availability of signalling 434 points in the SS7 network, and the redundancy model (active-standby, 435 load-sharing, n+k) of the remote signalling processes. 437 For carrier grade networks, Operators should ensure that under failure 438 or isolation of a particular signalling process, stable calls or 439 transactions are not lost. This implies that signalling processes need, 440 in some cases, to share the call or transaction state information with 441 other signalling processes. In the case of ASPs performing call 442 processing, coordination may also be required with the related Media 443 Gateway to transfer the MGC control for a particular trunk termination. 444 However, this sharing or communication is outside the scope of this 445 document. 447 This model serves as an example. M3UA imposes no restrictions as to the 448 exact layout of the network elements, the message distribution 449 algorithms and the distribution of the signalling processes. Instead, 450 it provides a framework and a set of messages that allow for a flexible 451 and scalable signalling network architecture, aiming to provide 452 reliability and performance. 454 1.4 Functional Areas 456 1.4.1 Signalling Point Code Representation 458 Within an SS7 network, a Signalling Gateway is charged with representing 459 a set of nodes in the IP domain into the SS7 network for routing 460 purposes. The SG itself, as a physical node in the SS7 network, must be 461 addressable with an SS7 Point Code for MTP3 Management purposes. The SG 462 Point Code will also be used for addressing any local MTP3-Users at the 463 SG such as an SG-resident SCCP function. 465 An SG may be logically partitioned to operate in multiple SS7 network 466 Appearances. In such a case, the SG must be addressable with a Point 467 Code in each network appearance, and must represent a set of nodes in 468 the IP domain into each SS7 network. Alias PCs may also be used within 469 an SG network appearance, but SG MTP3 management messages to/from the 470 SS7 network will not use the alias PCs. 472 The M3UA places no restrictions on the SS7 Point Code representation of 473 an AS. Application servers can be represented under the same PC of the 474 SG, their own individual Point Codes or grouped with other applications 475 for Point Code preservation purposes. A single Point Code may be used 476 to represent the SG and all the ASPs together, if desired. 478 If an ASP or group of ASPs is available to the SS7 network via more than 479 one SG, each with its own Point Code, the ASP(s) can be represented by a 480 Point Code that is separate from any SG Point Code. This allows these 481 SGs to be viewed from the SS7 network as "STPs", each having an ongoing 482 "route" to the same ASP(s). Under failure conditions where an ASP 483 becomes unavailable from one of the SGs, this approach enables MTP3 484 route management messaging between the SG and SS7 network, allowing 485 simple SS7 re-routing through an alternate SG without changing the 486 Destination Point Code Address of SS7 traffic to the ASPs. 488 +--------+ 489 | | 490 +------------+ SG 1 +--------------+ 491 +-------+ | SS7 links | "STP" | IP network | ---- 492 | SEP +---+ +--------+ +---/ \ 493 | or | | ASPs | 494 | STP +---+ +--------+ +---\ / 495 +-------+ | | | | ---- 496 +------------+ SG 2 +--------------+ 497 | "STP" | 498 +--------+ 500 Note: there is no SG to SG communication shown, so each SG can be 501 reached only via the direct Linkset from the SS7 network. 503 The following example shows a signalling gateway partitioned into two 504 network appearances. 506 SG 507 +-------+ +---------------+ 508 | SEP +--------------| SS7 Ntwk |M3UA| ---- 509 +-------+ SS7 links | "A" | | / \ 510 |__________| +-----------+ ASPs | 511 | | | \ / 512 +-------+ | SS7 Ntwk | | ---- 513 | SEP +--------------+ "B" | | 514 +-------+ +---------------+ 516 1.4.2 Message Distribution 518 1.4.2.1 Address Translation and Mapping at the SG 520 In order to direct messages received from the SS7 MTP3 network to the 521 appropriate IP destination, the SG must perform address translation and 522 mapping functions using information from the received MTP3-User message. 524 To support this message distribution, the SG must maintain the 525 equivalent of a network address translation table, mapping incoming SS7 526 message information to an Application Server for a particular 527 application and range of traffic. This is accomplished by comparing 528 elements of the incoming SS7 message to provisioned Routing Keys in the 529 SG. These Routing Keys in turn make reference to an Application Server 530 that is enabled by one or more ASP. These ASPs provide dynamic status 531 information to the SG using various management messages defined in the 532 M3UA protocol. Possible SS7 address/routing information that comprise a 533 Routing Key entry includes, for example, the OPC, DPC, SIO found in the 534 MTP3 routing label, or other MTP3-User specific fields such as the ISUP 535 CIC, SCCP subsystem number, or TCAP transaction ID. Some example routing 536 keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC 537 combination, or the DPC/SSN combination. The particular information 538 used to define an M3UA Routing Key is application and network dependent, 539 and none of the above examples are mandated. 541 An Application Server contains a list of one or more ASPs that are 542 capable of processing the traffic. This list is assumed to be dynamic, 543 taking into account the availability status of the individual ASPs in 544 the list, configuration changes, and possible fail-over mechanisms. The 545 M3UA protocol includes messages to convey the availability status of the 546 individual ASPs as input to a fail-over mechanism. 548 Normally, one or more ASPs is active in the ASP (i.e., currently 549 processing traffic) but in certain failure and transition cases it is 550 possible that there may not be an active ASP available. Both load- 551 sharing and backup scenarios are supported. 553 When there is no Routing Key match for an incoming SS7 message, a 554 default treatment must be specified. Possible solutions are to provide 555 a default Application Server at the SG that directs all unallocated 556 traffic to a (set of) default ASP(s), or to drop the messages and 557 provide a notification to management. The treatment of unallocated 558 traffic is implementation dependent. 560 1.4.2.2 Address Translation and Mapping at the ASP 562 In order to direct messages to the SS7 network, the ASP must also 563 perform an address translation and mapping function in order to choose 564 the proper SGP for a given message. This is accomplished by observing 565 elements of the outgoing message, SS7 network status, SGP availability 566 and network appearance configuration tables. 568 A Signalling Gateway contains a list of one or more SGPs that are 569 capable of routing SS7 traffic. As is the case with ASPs, this list can 570 be dynamic, taking into account the availability status of the 571 individual SGPs, configuration changes and fail-over mechanisms. 573 1.4.3 SS7 and M3UA Interworking 575 In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is 576 designed to provide an extension of the MTP3 defined user primitives. 578 1.4.3.1 Signalling Gateway SS7 Layers 580 The SG is responsible for terminating MTP Level 3 of the SS7 protocol, 581 and offering an IP-based extension to its users. 583 >From an SS7 perspective, it is expected that the Signalling Gateway (SG) 584 transmits and receives SS7 Message Signalling Units (MSUs) to and from 585 the PSTN over a standard SS7 network interface, using the SS7 Message 586 Transfer Part (MTP) [14,15,16] to provide reliable transport of the 587 messages. 589 As a standard SS7 network interface, the use of MTP Level 2 signalling 590 links is not the only possibility. ATM-based High Speed Links can also 591 be used with the services of the Signalling ATM Adaptation Layer (SAAL) 592 [17,18]. It is possible for IP-based links to be present, using the 593 services of the MTP2-User Adaptation Layer (M2UA) [19]. These SS7 594 datalinks may be terminated at a Signalling Transfer Point (STP) or at a 595 Signalling End Point (SEP). Using the services of MTP3, the SG may be 596 capable of communicating with remote SS7 SEPs in a quasi-associated 597 fashion, where STPs may be present in the SS7 path between the SEP and 598 the SG. 600 Where ATM-based High Speed Links are used in the SS7 network, it is 601 possible for the SG to use the services of the MTP-3b [20] for reliable 602 transport to and from an SS7 SEP or STP. The maximum Service Data Unit 603 (SDU) supported by the MTP-3b is 4096 octets compared to the 272-octet 604 maximum of the MTP3. However, for MTP3-Users to take advantage of the 605 larger SDU between MTP3-User peers, network architects should ensure 606 that MTP3-b is used end-to-end between the SG and the SS7-resident peer. 608 1.4.3.2 SS7 and M3UA Inter-Working at the SG 610 The SG provides a functional inter-working of transport functions 611 between the SS7 network and the IP network by also supporting the M3UA 612 adaptation layer. It allows the transfer of MTP3-User signalling 613 messages to and from an IP-based Application Server Process where the 614 peer MTP3-User protocol layer exists. 616 The Signalling Gateway must maintain knowledge of SS7 node and 617 Signalling Point Management Cluster (SPMC) status in their respective 618 domains in order to perform a seamless inter-working of the IP-based 619 signalling and the SS7 domains. For example, SG knowledge of the 620 availability and/or congestion status of the SPMC and SS7 nodes must be 621 maintained and disseminated in the respective networks, in order to 622 ensure that end-to-end operation is transparent to the communicating SCN 623 protocol peers at the SS7 node and ASP. 625 When the SG determines that the transport of SS7 messages to an SPMC is 626 encountering congestion, the SG may optionally inform the MTP3 route 627 management function (by an implementation-dependent mechanism). This 628 information is used by the MTP3 to mark the route to the affected 629 destination as congested and to trigger MTP Transfer Controlled (TFC) 630 messages to any SS7 SEPs generating traffic to the congested DPC, as per 631 current MTP3 procedures. 633 When the SG determines that the transport of SS7 messages to all ASPs in 634 a particular SPMC is interrupted, then it may similarly optionally 635 inform the MTP3 route management function. This information is used by 636 the MTP3 to mark the route to the affected destination as unavailable, 637 and in the case of a signalling transfer point, to send MTP Transfer 638 Prohibited (TFP) messages to the relevant adjacent SS7 nodes, according 639 to the local SS7 network procedures. 641 When the SG determines that the transport of SS7 messages to an ASP in a 642 particular SPMC can be resumed, the SG may similarly optionally inform 643 the MTP3 route management function. This information is used by the 644 MTP3 to mark the route to the affected destination as available, and in 645 the case of a signalling transfer point, to send MTP Transfer Allowed 646 (TFA) messages to the relevant adjacent SS7 nodes, according to the 647 local SS7 network procedures. In some SS7 network architectures, 648 sending TFP and TFA messages from the SG into the SS7 network should be 649 suppressed. As an example, in the case where the SG is seen by the 650 adjacent SS7 nodes as an SEP (i.e., in ANSI MTP terms the SG is 651 connected via A-links or F-links), TFP or TFA messages would not 652 normally be expected by the adjacent SS7 node. 654 In the case of SS7 user part management, it is required that the MTP3- 655 User protocols at ASPs receive indications of SS7 signalling point 656 availability, SS7 network congestion and User Part availability as would 657 be expected an SS7 SEP node. To accomplish this, the MTP-PAUSE, MTP- 658 RESUME and MTP-STATUS indication primitives received at the MTP3 upper 659 layer interface at the SG need to be made propagated to the remote MTP3- 660 User lower layer interface at the ASP. These indication primitives are 661 also made available to any existing local MTP3-Users at the SG, if 662 present. 664 It is important to clarify that MTP3 management messages such as TFPs or 665 TFAs received from the SS7 network are not "encapsulated" and sent 666 blindly to the ASPs. Rather, the existing MTP3 management procedures 667 are followed within the MTP3 function of the SG to re-calculate the MTP3 668 route set status and initiate any required signalling-route-set-test 669 procedures into the SS7 network. Only when an SS7 destination status 670 changes are MTP-PAUSE or MTP-RESUME primitives invoked. These 671 primitives can also be invoked due to local SS7 link set conditions as 672 per existing MTP3 procedures. 674 1.4.3.2 Application Server 676 A cluster of application servers is responsible for providing the 677 overall support for one or many SS7 upper layers. From an SS7 678 standpoint, a signalling point management cluster (SPMC) must provide 679 complete support for the upper layer service for a given point code. As 680 an example, such a SPMC providing MGC capabilities must provide complete 681 support for ISUP for a given point code, according to the local SS7 682 network specifications. 684 This measure is necessary to allow the SG to accurately represent the 685 signalling point on the local SS7 network. 687 1.4.3.3 IPSP 689 Since IPSPs use M3UA in a point-to-point fashion, there is no concept of 690 routing of messages beyond the remote end. Therefore, SS7 and M3UA 691 inter-working is not necessary for this model. 693 1.4.4 Redundancy Models 695 The network address translation and mapping function of the M3UA layer 696 supports signalling process fail-over functions in order to support a 697 high availability of call and transaction processing capability. 699 1.4.4.1 Application Server Redundancy 701 All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG from the SS7 702 network are assigned to a unique Application Server, based on the 703 information in the message and the provisioned Routing Keys. 705 The Application Server is, in practical terms a list of all ASPs 706 actively configured to process a range of MTP3-User traffic defined by 707 Routing Keys. One or more ASPs in the list are normally active (i.e., 708 handling traffic) while any others may be unavailable or inactive, to be 709 possibly used in the event of failure or unavailability of the active 710 ASP(s). 712 The fail-over model supports an "n+k" redundancy model, where "n" ASPs 713 is the minimum number of redundant ASPs required to handle traffic and 714 "k" ASPs are available to take over for a failed or unavailable ASP. A 715 "1+1" active/standby redundancy is a subset of this model. A simplex 716 "1+0" model is also supported as a subset, with no ASP redundancy. 718 At the SG, an Application Server list contains active and inactive ASPs 719 to support ASP load-sharing and fail-over procedures. The list of ASPs 720 within a logical Application Server is kept updated in the SG to reflect 721 the active Application Server Process(es). 723 To avoid a single point of failure, it is recommended that a minimum of 724 two ASPs be in the list, resident in separate hosts, and therefore 725 available over different SCTP Associations. For example, in the network 726 shown in Figure 1, all messages to DPC x could be sent to ASP1 in Host1 727 or ASP1 in Host2. The AS list at SG1 might look like this: 729 Routing Key {DPC=x) - "Application Server #1" 730 ASP1/Host1 � State=Up, Active 731 ASP1/Host2 � State=Up, Inactive 733 In this "1+1" redundancy case, ASP1 in Host1 would be sent any incoming 734 message with DPC=x. ASP1 in Host2 would normally be brought to the 735 active state upon failure of, or loss of connectivity to, ASP1/Host1. In 736 this example, both ASPs are Up, meaning that the related SCTP 737 association and far-end M3UA peer is ready. 739 The AS List at SG1 might also be set up in load-share mode: 741 Routing Key {DPC=x) - "Application Server #1" 742 ASP1/Host1 � State = Up, Active 743 ASP1/Host2 � State = Up, Active 745 In this case, both the ASPs would be sent a portion of the traffic. For 746 example the two ASPs could together form a database, where incoming 747 queries may be sent to any active ASP. 749 Care must be exercised by a Network Operator in the selection of the 750 routing information to be used as the Routing Key for a particular AS. 751 For example, where Application Servers are defined using ranges of ISUP 752 CIC values, the Operator is implicitly splitting up control of the 753 related circuit groups. Some CIC value range assignments may interfere 754 with ISUP circuit group management procedures. Similarly, within an AS, 755 if a load-balancing algorithm were to use CIC values to balance the load 756 across the ASPs, the span of circuit contol assigned to particular ASPs 757 must also be weighed against the ISUP circuit group management 758 procedures. 760 In the process of fail-over or fail-back, it is recommended that in the 761 case of ASPs supporting call processing, stable calls do not fail. It 762 is possible that calls in "transition" may fail, although measures of 763 communication between the ASPs involved can be used to mitigate this. 764 For example, the two ASPs may share call state via shared memory, or may 765 use an ASP to ASP protocol to pass call state information. 767 1.4.4.2 Signalling Gateway Redundancy 769 Signalling Gateways may also be distributed over multiple hosts. Much 770 like the AS model, SGs are comprised of one or more SG processes (SGP), 771 distributed over one or more hosts, using an active/standby or a load- 772 sharing model. An SGP is viewed as a remote SCTP end-point from an ASP 773 perspective. 775 It is therefore possible for an ASP to route signalling messages 776 destined to the SS7 network using more than one SGP. In this model, a 777 signalling gateway is deployed as a cluster of hosts acting as a single 778 SG. A primary/back-up redundancy model is possible, where the 779 unavailability of the SCTP association to a primary SGP, or the 780 unavailability of the SS7 destination node from the primary SGP, could 781 be used to reroute affected traffic to an alternate SGP. A load-sharing 782 model is possible, where the signalling messages are load-shared between 783 multiple SGPs. 785 It may also be possible for an AS to use more than one SG to access a 786 specific SS7 end point, in a model that resembles an SS7 STP mated pair. 787 Typically, SS7 STPs are deployed in mated pairs, with traffic load- 788 shared between them. Other models are also possible, subject to the 789 limitations of the local SS7 network provisioning guidelines. 791 >From the perspective of an ASP, a particular SG is capable of 792 transferring traffic to an SS7 destination if an SCTP association with 793 the SGP is established, the SGP has received an indication from the ASP 794 that it is actively handling traffic for that destination, and the SG 795 has not indicated that the destination is inaccessible. When an ASP is 796 configured to use multiple SGPs or SGs for transferring traffic to the 797 SS7 network, the ASP must maintain knowledge of the current capability 798 of the SG to handle traffic to destinations of interest. This 799 information is crucial to the overall reliability of the service, for 800 both active/standby and load-sharing model, in the event of failures, 801 recovery and maintenance activities. The ASP may also use this 802 information for congestion avoidance purposes. 804 1.4.5 Management Inhibit/Uninhibit 806 Local Management at an ASP or SG may wish to stop traffic across an SCTP 807 association in order to temporarily remove the association from service 808 or to perform testing and maintenance activity. The function could 809 optionally be used to control the start of traffic on to a newly 810 available SCTP association. 812 1.4.6 Congestion Management 814 The M3UA Layer is informed of local and IP network congestion by means 815 of an implementation-dependent function (e.g., an implementation- 816 dependent indication from the SCTP of IP network congestion). When an SG 817 determines that the transport of SS7 messages to a Signalling Point 818 Management Cluster (SPMC) is encountering congestion, the SG may 819 optionally trigger SS7 MTP3 Transfer Controlled management messages to 820 originating SS7 nodes. The triggering of SS7 MTP3 Management messages 821 from an SG is an implementation-dependent function. 823 At an ASP, congestion is indicated to local MTP3-Users by means of an 824 MTP-Status primitive indicating congestion, to invoke appropriate upper 825 layer responses, as per current MTP3 procedures. 827 1.4.7 SCTP Stream Mapping. 829 The M3UA at both the SG and ASP also supports the assignment of 830 signalling traffic into streams within an SCTP association. Traffic 831 that requires sequencing must be assigned to the same stream. To 832 accomplish this, MTP3-User traffic may be assigned to individual streams 833 based on the SLS value in the MTP3 Routing Label or the ISUP CIC 834 assignment, subject of course to the maximum number of streams supported 835 by the underlying SCTP association. 837 The use of SCTP streams within M3UA is recommended in order to minimize 838 transmission and buffering delays, therefore improving the overall 839 performance and reliability of the signalling elements. The 840 distribution of the MTP3 user messages over the various streams should 841 be done in such 842 a way to minimize message mis-sequencing, as required by the SS7 User 843 Parts. 845 1.4.8 Client/Server Model 847 The SG takes on the role of server while the ASP is the client. ASPs 848 must initiate the SCTP association to the SG. 850 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M3UA 851 is 2905. 853 1.5 Sample Configurations 855 1.5.1 Example 1: ISUP message transport 857 ******** SS7 ***************** IP ******** 858 * SEP *---------* SG *--------* ASP * 859 ******** ***************** ******** 861 +------+ +------+ 862 | ISUP | (NIF) | ISUP | 863 +------+ +------+-+------+ +------+ 864 | MTP3 | | MTP3 | | M3UA | | M3UA | 865 +------| +------+ +------+ +------+ 866 | MTP2 | | MTP2 | | SCTP | | SCTP | 867 +------+ +------+ +------+ +------+ 868 | L1 | | L1 | | IP | | IP | 869 +------+ +------+ +------+ +------+ 870 |_______________| |______________| 872 SEP - SS7 Signalling End Point 873 SCTP - Stream Control Transmission Protocol 874 NIF � Nodal Inter-working Function 876 In this example, the SG provides an implementation-dependent nodal 877 inter-working function (NIF) that allows the MGC to exchange SS7 878 signalling messages with the SS7-based SEP. The NIF within the SG 879 serves to transport messages within the SG between the MTP3 and M3UA. 880 This nodal inter-working function has no visible peer protocol with 881 either the MGC or SEP. It also provides network status information to 882 one or both sides of the network. 884 For internal SG modeling purposes, at the NIF level, SS7 signalling 885 messages that are destined to the MGC are received as MTP-TRANSFER 886 indication primitives from the MTP Level 3 upper layer interface and are 887 sent to the local M3UA-resident message distribution function for 888 ongoing routing to the final IP destination. MTP-TRANSFER primitives 889 received from the local M3UA network address translation and mapping 890 function are sent to the MTP Level 3 upper layer interface as MTP- 891 TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 892 SEP. For the purposes of providing SS7 network status information the 893 NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 894 primitives received from the MTP Level 3 upper layer interface to the 895 local M3UA-resident management function. 897 1.5.2 Example 2: SCCP Transport between IPSPs 899 ******** IP ******** 900 * IPSP * * IPSP * 901 ******** ******** 903 +------+ +------+ 904 |SCCP- | |SCCP- | 905 | User | | User | 906 +------+ +------+ 907 | SCCP | | SCCP | 908 +------+ +------+ 909 | M3UA | | M3UA | 910 +------+ +------+ 911 | SCTP | | SCTP | 912 +------+ +------+ 913 | IP | | IP | 914 +------+ +------+ 915 |________________| 917 This example shows an architecture where no Signalling Gateway is used. 918 In this example, SCCP messages are exchanged directly between two IP- 919 resident IPSPs with resident SCCP-User protocol instances, such as RANAP 920 or TCAP. SS7 network inter-working is not required, therefore there is 921 no MTP3 network management status information for the SCCP and SCCP-User 922 protocols to consider. Any MTP-PAUSE, -RESUME or -STATUS indications 923 from the M3UA to the SCCP should consider only the status of the SCTP 924 Association and underlying IP network. 926 1.5.3 Example 3: SG resident SCCP layer, with remote ASP 928 ******** SS7 ***************** IP ******** 929 * SEP *---------* *--------* * 930 * or * * SG * * ASP * 931 * STP * * * * * 932 ******** ***************** ******** 934 +------+ +---------------+ +------+ 935 | SCCP-| | SCCP | | SCCP-| 936 | User | +---------------+ | User | 937 +------+ | _____ | +------+ 938 | SCCP | | | | | | SCCP | 939 +------+ +------+-+------+ +------+ 940 | MTP3 | | MTP3 | | M3UA | | M3UA | 941 +------| +------+ +------+ +------+ 942 | MTP2 | | MTP2 | | SCTP | | SCTP | 943 +------+ +------+ +------+ +------+ 944 | L1 | | L1 | | IP | | IP | 945 +------+ +------+ +------+ +------+ 946 |_______________| |______________| 948 STP - SS7 Signalling Transfer Point 950 In this example, the SG contains an instance of the SS7 SCCP protocol 951 layer that may, for example, perform the SCCP Global Title Translation 952 (GTT) function for messages logically addressed to the SG SCCP. If the 953 result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN address 954 result of an SCCP peer located in the IP domain, the resulting MTP- 955 TRANSFER request primitive is sent to the local M3UA-resident network 956 address translation and mapping function for ongoing routing to the 957 final IP destination. 959 Similarly, the SCCP instance in an SG can perform the SCCP GTT service 960 for messages logically addressed to it from SCCP peers in the IP domain. 961 In this case, MTP-TRANSFER messages are sent from the local M3UA- 962 resident network address translation and mapping function to the SCCP 963 for GTT. If the result of the GTT yields the address of an SCCP peer in 964 the SS7 network then the resulting MTP-TRANSFER request is given to the 965 MTP3 for delivery to an SS7-resident node. 967 It is possible that the above SCCP GTT at the SG could yield the address 968 of an SCCP peer in the IP domain and the resulting MTP-TRANSFER 969 primitive would be sent back to the M3UA for delivery to an IP 970 destination. 972 For internal SG modeling purposes, this may be accomplished with the use 973 of an implementation-dependent nodal inter-working function within the 974 SG that effectively sits below the SCCP and routes MTP-TRANSFER messages 975 to/from both the MTP3 and the M3UA, based on the SS7 DPC or DPC/SSN 976 address information. This nodal inter-working function has no visible 977 peer protocol with either the ASP or SEP. 979 Note that the services and interface provided by the M3UA are the same 980 as in Example 1 and the functions taking place in the SCCP entity are 981 transparent to M3UA. The SCCP protocol functions are not reproduced in 982 the M3UA protocol. 984 1.6 Definition of M3UA Boundaries 986 1.6.1 Definition of the boundary between M3UA and an MTP3-User. 988 >From ITU Q.701 [2]: 990 MTP-TRANSFER request 991 MTP-TRANSFER indication 992 MTP-PAUSE indication 993 MTP-RESUME indication 994 MTP-STATUS indication 996 1.6.2 Definition of the boundary between M3UA and SCTP 998 The upper layer primitives provided by the SCTP are provided in [13] 1000 1.6.3 Definition of the Boundary between M3UA and Layer Management 1002 M-SCTP ESTABLISH request 1003 M-SCTP ESTABLISH indication 1004 M-STCP ESTABLISH confirm 1006 M-SCTP RELEASE request 1007 M-SCTP RELEASE indication 1008 M-SCTP RELEASE confirm 1010 M-SCTP STATUS request 1011 M-SCTP STATUS indication 1013 M-ASP STATUS request 1014 M-ASP STATUS indication 1016 M-AS-STATUS request 1017 M-AS-STATUS indication 1019 M-NOTIFY indication 1020 M-ERROR indication 1022 M-ASP-INHIBIT request 1023 M-ASP-UNINHIBIT request 1025 2.0 Conventions 1027 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 1028 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 1029 in this document, are to be interpreted as described in [RFC2119]. 1031 3.0 M3UA Protocol Elements 1033 The general M3UA message format includes a Common Message Header 1034 followed by zero or more parameters as defined by the Message Type. For 1035 forward compatibility, all Message Types may have attached parameters 1036 even if none are specified in this version. 1038 3.1 Common Message Header 1040 The protocol messages for MTP3-User Adaptation require a message 1041 structure that contains a version, message type, message length, and 1042 message contents. This message header is common among all signalling 1043 protocol adaptation layers: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Version | Reserved | Message Class | Message Type | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Message Length | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | | 1054 All fields in an M3UA message MUST be transmitted in the network byte 1055 order, unless otherwise stated. 1057 M3UA Protocol Version: 8 bits (unsigned integer) 1059 The version field contains the version of the M3UA adaptation layer. 1060 The supported versions are: 1062 Value Version 1063 ----- ------- 1064 1 Release 1.0 1066 Message Class: 8 bits (unsigned integer) 1068 The following list contains the Message Type Classes for the defined 1069 messages. 1071 0 Management (MGMT) Message 1072 1 Transfer Messages 1073 2 SS7 Signalling Network Management (SSNM) Messages 1074 3 ASP State Maintenance (ASPSM) Messages 1075 4 ASP Traffic Maintenance (ASPTM) Messages 1076 5 to 255 Reserved 1078 Message Type: 8 bits (unsigned integer) 1080 The following list contains the message types for the defined 1081 messages. 1083 Management (MGMT) Message 1085 0 Error (ERR) 1086 1 Notify (NTFY) 1087 2 to 255 Reserved for Management Messages 1089 Transfer Messages 1091 0 Reserved 1092 1 Payload Data (DATA) 1093 2 to 255 Reserved for Transfer Messages 1095 SS7 Signalling Network Management (SSNM) Messages 1097 0 SS7 Network Isolation (S7ISO) 1098 1 Destination Unavailable (DUNA) 1099 2 Destination Available (DAVA) 1100 3 Destination State Audit (DAUD) 1101 4 SS7 Network Congestion State (SCON) 1102 5 Destination User Part Unavailable (DUPU) 1103 6 to 255 Reserved for SSNM Messages 1105 ASP State Maintenance (ASPSM) Messages 1107 0 Reserved 1108 1 ASP Up (UP) 1109 2 ASP Down (DOWN) 3 Heartbeat (HEARTBEAT) 1110 4 ASP Up Ack (UP ACK) 1111 5 ASP Down Ack (DOWN ACK) 1112 6 to 255 Reserved for ASPSM Messages 1114 ASP Traffic Maintenance (ASPTM) Messages 1116 0 Reserved 1117 1 ASP Active (ACTIVE) 1118 2 ASP Inactive (INACTIVE) 1119 3 ASP Active Ack (ACTIVE ACK) 1120 4 ASP Inactive Ack (INACTIVE ACK) 1121 5 to 255 Reserved for ASPTM Messages 1123 Reserved: 5 bits 1125 Should be set to all '0's and ignored by the receiver. 1127 Message Length: 32-bits (unsigned integer) 1129 The Message Length defines the length of the message in octets, not 1130 including the header. 1132 3.2 Variable-Length Parameter Format 1134 M3UA messages consist of a Common Header followed by zero or more 1135 variable-length parameters, as defined by the message type. The 1136 variable-length parameters contained in a message are defined in a Tag- 1137 Length-Value format as shown below. 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Parameter Tag | Parameter Length | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 \ \ 1145 / Parameter Value / 1146 \ \ 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Parameter Tag: 16 bits (unsigned integer) 1151 Tag field is a 16-bit identifier of the type of parameter. It takes a 1152 value of 0 to 65534. 1154 The value of 65535 is reserved for IETF-defined extensions. Values 1155 other than those defined in specific parameter description are 1156 reserved for use by the IETF. 1158 Parameter Length: 16 bits (unsigned integer) 1160 The Parameter Length field contains the size of the parameter in 1161 bytes, including the Parameter Tag, Parameter Length, and Parameter 1162 Value fields. The Parameter Length does not include any padding 1163 bytes. 1165 Parameter Value: variable-length. 1167 The Parameter Value field contains the actual information to be 1168 transferred in the parameter. 1170 The total length of a parameter (including Tag, Parameter Length and 1171 Value fields) MUST be a multiple of 4 bytes. If the length of the 1172 parameter is not a multiple of 4 bytes, the sender pads the Parameter 1173 at the end (i.e., after the Parameter Value field) with all zero 1174 bytes. The length of the padding is NOT included in the parameter 1175 length field. A sender should NEVER pad with more than 3 bytes. The 1176 receiver MUST ignore the padding bytes. 1178 3.2 Transfer Messages 1180 The following section describes the Transfer messages and parameter 1181 contents. 1183 3.2.1 Payload Data Message (DATA) 1185 The Data message contains the SS7 MTP3-User protocol data, which is an 1186 MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 1187 Data message contains the following variable length parameters: 1189 Network Appearance Optional 1190 Protocol Data Mandatory 1192 The following format MUST be used for the Data Message: 1194 0 1 2 3 1195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Tag = 1 | Length = 8 | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Network Appearance* | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Tag = 3 | Length | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 \ \ 1204 / Protocol Data / 1205 \ \ 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Network Appearance: 32-bits (unsigned integer) 1210 The optional Network Appearance parameter identifies the SS7 network 1211 context for the message, for the purposes of logically separating the 1212 signalling traffic between the SG and the Application Server Process 1213 over a common SCTP Association. An example is where an SG is 1214 logically partitioned to appear as an element in four different 1215 national SS7 networks. 1217 In a Data message, the Network Appearance defines the SS7 Point Codes 1218 used, the SS7 Network Indicator value and MTP3/MTP3-User protocol 1219 type/variant/version used within the SS7 network partition. Where an 1220 SG operates in the context of a single SS7 network, or individual 1221 SCTP associations are dedicated to each SS7 network context, or the 1222 Network Indicator in the SIO of the MTP-Transfer primitive is 1223 sufficient, the Network Appearance parameter is not required. 1225 The Network Appearance parameter value assigned according to network 1226 operator policy. The values used are of local significance only, 1227 coordinated between the SG and ASP. 1229 Where the optional Network Appearance parameter is present, it must 1230 be the first parameter in the message as it defines the format of the 1231 Protocol Data field. 1233 Protocol Data: variable length 1235 The Protocol Data field contains the MTP3-User application message, 1236 which is in effect an MTP-TRANSFER primitive. As defined for a 1237 specific value of the Protocol Identifier, this will include the MTP- 1238 User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and 1239 the SIO (Service Indicator, Network Indicator & optional Message 1240 Priority codes). Note: in the case of ISUP messages, the Circuit 1241 Identification Code is also included. 1243 3.3 SS7 Signalling Network Management (SSNM) Messages 1245 3.3.1 Destination Unavailable (DUNA) 1247 The DUNA message is sent from the SG to all concerned ASPs to indicate 1248 that the SG has determined that one or more SS7 destinations are 1249 unreachable. The MTP3-User at the ASP is expected to stop traffic to 1250 the affected destination through the SG initiating the DUNA as per the 1251 defined MTP3-User procedures. 1253 The DUNA message contains the following parameters: 1255 Network Appearance Optional 1256 Affected Destination Mandatory 1257 Info String Optional 1259 The format for DUNA Message parameters is as follows: 1261 0 1 2 3 1262 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 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Tag = 1 | Length =8 | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Network Appearance* | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Tag = 5 | Length | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Mask | Affected DPC 1 | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 \ \ 1273 | ... | 1274 \ \ 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Mask | Affected DPC n | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Tag = 4 | Length | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 \ \ 1281 | INFO String* | 1282 \ \ 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Network Appearance: 32-bit unsigned integer 1287 The optional Network Appearance parameter identifies the SS7 network 1288 context for the message, for the purposes of logically separating the 1289 signalling traffic between the SG and the Application Server Process 1290 over a common SCTP Association. An example is where an SG is logically 1291 partitioned to appear as an element in four different national SS7 1292 networks. 1294 In an SSNM message, the Network Appearance parameter defines the format 1295 of the Affected DPC(s) in the Affected Destination parameter. The DPC 1296 point code length (e.g., 14-, 16-, or 24-bit) and sub-field definitions 1297 (e.g., ANSI 24-bit network/cluster/member, ITU-international 14-bit 1298 zone/region/signal_point, many national field variants, ...) are fixed 1299 within a particular Network Appearance. Where an SG operates in the 1300 context of a single SS7 network, or individual SCTP associations are 1301 dedicated to each SS7 network context, the Network Appearance parameter 1302 is not required and the format of the Affected DPC(s) is understood 1303 implicitly. 1305 The format of the Network Appearance parameter is an integer, the values 1306 of which are assigned according to network operator policy. The values 1307 used are of local significance only, coordinated between the SG and ASP. 1309 Where the optional Network Appearance parameter is present, it must be 1310 the first parameter in the message as it defines the format of the 1311 Affected DPCs in the Affected Destination parameter. 1313 Affected Destination: 24-bits 1315 The Affected Destination parameter contains one or more Affected 1316 Destination Point Codes, each a three-octet parameter to allow for 14-, 1317 16- and 24-bit binary formatted SS7 Point Codes. Affected Point Codes 1318 that are less than 24-bits, are padded on the left to the 24-bit 1319 boundary. The encoding is shown below for ANSI and ITU Point Code 1320 examples. 1322 ANSI 24-bit Point Code: 1324 0 1 2 3-----> 1325 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 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Mask | Network | Cluster | Member | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 |MSB-----------------------------------------LSB| 1332 ITU 14-bit Point Code: 1334 0 1 2 3-----> 1335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 |MSB--------------------LSB| 1342 It is optional to send an Affected Destination parameter with more than 1343 one Affected DPC but it is mandatory to receive it. All the Affected 1344 DPCs included must be within the same Network Appearance. Including 1345 multiple Affected DPCs may be useful when reception of an MTP3 1346 management message or a linkset event simultaneously affects the 1347 availability status of a list of destinations at an SG. 1349 Mask: 8-bits 1351 The Mask parameter is used to identify a contiguous range of Affected 1352 Destination Point Codes, independent of the point code format. 1353 Identifying a contiguous range of Affected DPCs may be useful when 1354 reception of an MTP3 management message or a linkset event 1355 simultaneously affects the availability status of a series of 1356 destinations at an SG. For example, if all DPCs in an ANSI cluster are 1357 determined to be unavailable due to local linkset unavailability, the 1358 DUNA could identify potentially 256 Affected DPCs in a single Affected 1359 DPC field. 1361 The Mask parameter is an integer representing a bit mask that can be 1362 applied to the related Affected DPC field. The bit mask identifies how 1363 many bits of the Affected DPC field is significant and which are 1364 effectively "wildcarded". For example, a mask of "8" indicates that the 1365 last eight bits of the DPC is "wildcarded". For an ANSI 24-bit Affected 1366 DPC, this is equivalent to signalling that all DPCs in an ANSI Cluster 1367 are unavailable. A mask of "3" indicates that the last three bits of 1368 the DPC is "wildcarded". For a 14-bit ITU Affected DPC, this is 1369 equivalent to signaling that an ITU Region is unavailable. 1371 Info String: variable length 1373 The optional INFO String parameter can carry any meaningful 8-BIT ASCII 1374 character string along with the message. Length of the INFO String 1375 parameter is from 0 to 255 characters. No procedures are presently 1376 identified for its use but the INFO String may be used by Operators to 1377 identify in text form the location reflected by the Affected DPC for 1378 debugging purposes. 1380 3.3.2 Destination Available (DAVA) 1382 The DAVA message is sent from the SG to all concerned ASPs to indicate 1383 that the SG has determined that one or more SS7 destinations are now 1384 reachable. The ASP MTP3-User protocol is expected to resume traffic to 1385 the affected destination through the SG initiating the DUNA. 1387 The DAVA message contains the following parameters: 1389 Network Appearance Optional 1390 Affected Destination Mandatory 1391 Info String Optional 1393 The format and description of DAVA Message parameters is the same as for 1394 the DUNA message (See Section 3.3.2.1.) 1396 3.3.3 Destination State Audit (DAUD) 1398 The DAUD message can be sent from the ASP to the SG to audit the 1399 availability/congestion state of SS7 routes to one or more affected 1400 destinations. See Section 3.4.3 for the audit procedures. 1402 The DAUD message contains the following parameters: 1404 Network Appearance Optional 1405 Affected Destination Mandatory 1406 Info String Optional 1408 The format and description of DAUD Message parameters is the same as for 1409 the DUNA message (See Section 3.3.2.1.) 1410 Multiple Affected Destination Point Codes parameters may optionally be 1411 included in a DAUD message. However all the Affected Destination Point 1412 Codes must be part of the same Network Appearance. 1414 3.3.4 SS7 Network Congestion (SCON) 1416 The SCON message can be sent from the SG to all concerned ASPs to 1417 indicate that the congestion level in the SS7 network to one or more 1418 destinations has changed. 1420 The SCON message contains the following parameters: 1422 Network Appearance Optional 1423 Affected Destination Mandatory 1424 Congestion Level Mandatory 1425 Info String Optional 1427 The format for SCON Message parameters is as follows: 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Tag = 1 | Length =8 | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Network Appearance* | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Tag = 5 | Length | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Cong. Level 1 | Affected DPC 1 | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 \ \ 1441 | ... | 1442 \ \ 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Cong. Level n | Affected DPC n | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Tag = 4 | Length | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 \ \ 1449 | INFO String* | 1450 \ \ 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 The format and description of the Network Appearance, Affected 1454 Destination and Info String parameters is the same as for the DUNA 1455 message (See Section 3.3.2.1.) 1456 Congestion Level: 8-bits (unsigned integer) 1458 The valid values for the optional Congestion Level parameter are shown 1459 in the following table. 1461 0 No Congestion or Undefined 1462 1 Congestion Level 1 1463 2 Congestion Level 2 1464 3 Congestion Level 3 1466 The congestion levels are as defined in the national congestion method 1467 in the ITU MTP recommendation [14] or in the ANSI MTP standard [15]. 1468 For MTP congestion methods that do not employ congestion levels (e.g., 1469 the ITU international method, the parameter is always "Undefined". 1471 3.3.5 Destination User Part Unavailable (DUPU) 1473 The DUPU message is used by an SG to inform an ASP that a remote peer 1474 MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. 1476 The DUPU message contains the following parameters: 1478 Network Appearance Optional 1479 Affected Destination Mandatory 1480 Unavailability Cause Mandatory 1481 MTP3-User Identity Mandatory 1482 Info String Optional 1484 The format for DUPU Message parameters is as follows: 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Tag = 1 | Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Network Appearance* | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Tag = 5 | Length = 8 | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Cause | User | Affected Destination | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Tag = 4 | Length | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 \ \ 1500 | INFO String* | 1501 \ \ 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 The format and description of the Network Appearance, Affected 1505 Destination and Info String parameters is the same as for the DUNA 1506 message (See Section 3.3.2.1.) One exception is that the Affected 1507 Desination parameter in the DUPU message can only contain one Affected 1508 DPC. 1510 Unavailability Cause: 4-bits (unsigned integer) 1512 The Unavailability Cause parameter provides the reason for the 1513 unavailability of the MTP3-User. The valid values for the 1514 Unavailability Cause parameter are shown in the following table. The 1515 values agree with those provided in the SS7 MTP3 User Part Unavailable 1516 message. Depending on the MTP3 protocol used in the network context, 1517 additional values may be used � the specification of the relevant MTP3 1518 protocol variant/version is definitive. 1520 0 Unknown 1521 1 Unequipped Remote User 1522 2 Inaccessible Remote User 1524 MTP3-User Identity: 4-bits (unsigned integer) 1526 The MTP3-User Identity describes the specific MTP3-User that is 1527 unavailable (e.g., ISUP, SCCP, ...). The valid values for the MTP3-User 1528 Identity are shown below. The values agree with those provided in the 1529 SS7 MTP3 User Part Unavailable message and Service Indicator. Depending 1530 on the MTP3 protocol used in the network context, additional values may 1531 be used � the specification of the relevant MTP3 protocol 1532 variant/version is definitive. 1534 Value Description 1535 00 - 02 Reserved 1536 03 SCCP 1537 04 TUP 1538 05 ISUP 1539 06 � 08 Reserved 1540 09 Broadband ISUP 1541 10 Satellite ISUP 1543 3.4 Application Server Process Maintenance (ASPM) Messages 1545 3.4.1 ASP Up (ASPUP) 1547 The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer 1548 that the Adaptation layer is ready to receive traffic or maintenance 1549 messages. 1551 The ASPUP message contains the following parameters: 1553 Adaptation Layer Identifer Optional 1554 Protocol Identifier Optional 1555 INFO String Optional 1557 The format for ASPUP Message parameters is as follows: 1559 0 1 2 3 1560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Tag = 2 | Length | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Adaptation Layer Identifier* | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Tag = 4 | Length | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 \ \ 1569 | INFO String* | 1570 \ \ 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 The format and description of the optional Info String parameter is the 1574 same as for the DUNA message (See Section 3.3.2.1.) 1576 Adaptation Layer Identity: 32-bits () 1578 The optional Adaptation Layer Identifier (ALI) is a string that 1579 identifies the adaptation layer. This string must be set to "M3UA" 1580 which results in a length of 8. The ALI would normally only be used in 1581 the initial ASP Up message across a new SCTP association to ensure both 1582 peers are assuming the same adaptation layer protocol. 1584 3.4.2 ASP Up Ack 1586 The ASP UP Ack message is used to acknowledge an ASP-Up message received 1587 from a remote M3UA peer. 1589 The ASPUP Ack message contains the following parameters: 1591 Adaptation Layer Identifier (optional) 1592 Protocol Identifier (optional) 1593 INFO String (optional) 1595 The format for ASPUP Ack Message parameters is as follows: 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Tag =2 | Length | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 \ \ 1603 | Adaptation Layer Identifier* | 1604 \ \ 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Tag =4 | Length | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 \ \ 1609 | INFO String* | 1610 \ \ 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 The format and description of the optional Info String parameter is the 1614 same as for the DUNA message (See Section 3.3.2.1.) 1616 The format and description of the optional Adaptation Layer Identifier 1617 (ALI) parameter is the same as for the ASP-UP message. (See Section 1618 3.4.1) 1620 3.4.3 ASP Down (ASPDN) 1622 The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer 1623 that the adaptation layer is not ready to receive traffic or maintenance 1624 messages. 1626 The ASPDN message contains the following parameters: 1628 Reason Mandatory 1629 INFO String Optional 1631 The format for the ASPDN message parameters is as follows: 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Reason | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Tag =4 | Length | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 \ \ 1641 | INFO String* | 1642 \ \ 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 The format and description of the optional Info String parameter is the 1646 same as for the DUNA message (See Section 3.3.2.1.) 1648 Reason: 32-bit (unsigned integer) 1650 The Reason parameter indicates the reason that the remote M3UA 1651 adaptation layer is unavailable. The valid values for Reason are shown 1652 in the following table. 1654 1 Processor Outage 1655 2 Management Inhibit 1657 3.4.4 ASP Down Ack 1659 The ASP Down Ack message is used to acknowledge an ASP-Down message 1660 received from a remote M3UA peer. 1662 The ASP Down Ack message contains the following parameters: 1664 Reason Mandatory 1665 INFO String Optional 1667 The format for the ASPDN Ack message parameters is as follows: 1669 0 1 2 3 1670 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 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | Reason | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Tag = 4 | Length | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 \ \ 1677 | INFO String* | 1678 \ \ 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 The format and description of the optional Info String parameter is the 1682 same as for the DUNA message (See Section 3.3.2.1.) 1684 The format of the Reason parameter is the same as for the ASP-Down 1685 message. (See Section 3.4.3) 1687 3.4.5 ASP Active (ASPAC) 1689 The ASPAC message is sent by an ASP to indicate to a remote M3UA peer 1690 that it is Active and ready to process signalling traffic for a 1691 particular Application Server 1692 The ASPAC message contains the following parameters: 1694 Type Mandatory 1695 Routing Context Optional 1696 INFO String Optional 1698 The format for the ASPAC message is as follows: 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Type | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Tag =6 | Length | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 \ \ 1708 | Routing Context* | 1709 \ \ 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Tag = 4 | Length | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 \ \ 1714 | INFO String* | 1715 \ \ 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Type: 32-bit (unsigned integer) 1720 The Type parameter identifies the traffic mode of operation of the ASP 1721 within an AS. The valid values for Type are shown in the following 1722 table. 1724 1 Over-ride 1725 2 Load-share 1727 Within a particular Routing Context, only one Type can be used. The 1728 Over-ride value indicates that the ASP is operating in Over-ride mode, 1729 where the ASP takes over all traffic in an Application Server (i.e., 1730 primary/back-up operation), over-riding any currently active ASP in the 1731 AS. In Load-share mode, the ASP will share in the traffic distribution 1732 with any other currently active ASPs. 1734 A node that receives an ASPAC with an incorrect Type for a particular 1735 Routing Context will respond with an Error Message (Cause: Invalid 1736 Traffic Handling Mode. 1738 Routing Context: 1740 The optional Routing Context parameter contains (a list of) integers 1741 indexing the Application Server traffic that the sending ASP is 1742 configured/registered to receive. There is one-to-one relationship 1743 between an index entry and an SG Routing Key or AS Name. Because an AS 1744 can only appear in one Network Appearance, the Network Appearance 1745 parameter is not required in the ASPAC message. 1747 An Application Server Process may be configured to process traffic for 1748 more than one logical Application Server. From the perspective of an 1749 ASP, a Routing Context defines a range of signalling traffic that the 1750 ASP is currently configured to receive from the SG. For example, an ASP 1751 could be configured to support call processing for multiple ranges of 1752 PSTN trunks and therefore receive related signalling traffic, identified 1753 by separate SS7 DPC/OPC/CIC_ranges. 1755 The format and description of the optional Info String parameter is the 1756 same as for the DUNA message (See Section 3.3.2.1.) 1758 3.4.6 ASP Active Ack 1760 The ASPAC Ack message is used to acknowledge an ASP-Active message 1761 received from a remote M3UA peer. 1763 The ASPAC Ack message contains the following parameters: 1765 Type Mandatory 1766 Routing Context Optional 1767 INFO String Optional 1769 The format for the ASPAC Ack message is as follows: 1771 0 1 2 3 1772 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 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Type | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Tag = 6 | Length | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 \ \ 1779 | Routing Context* | 1780 \ \ 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Tag = 4 | Length | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 \ \ 1785 | INFO String* | 1786 \ \ 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 The format and description of the optional Info String parameter is the 1790 same as for the DUNA message (See Section 3.3.2.1.) 1792 The format of the Type and Routing Context parameters is the same as for 1793 the ASP-Active message. (See Section 3.4.5). 1795 3.4.7 ASP Inactive (ASPIA) 1797 The ASPIA message is sent by an ASP to indicate to a remote M3UA peer 1798 that it is no longer processing signalling traffic within a particular 1799 Application Server. 1801 The ASPIA message contains the following parameters: 1803 Type Mandatory 1804 Routing Context Optional 1805 INFO String Optional 1807 The format for the ASPIA message parameters is as follows: 1809 0 1 2 3 1810 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 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Type | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Tag = 6 | Length | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 \ \ 1817 | Routing Context* | 1818 \ \ 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Tag = 4 | Length | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 \ \ 1823 | INFO String* | 1824 \ \ 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 The Type parameter identifies the traffic mode of operation of the ASP 1828 within an AS. The valid values for Type are shown in the following 1829 table. 1831 Value Description 1832 0x1 Over-ride 1833 0x2 Load-share 1834 Within a particular Routing Context, only one Type can be used. The 1835 Over-ride value indicates that the ASP is operating in Over-ride mode, 1836 and will no longer handle traffic within an Application Server (i.e., it 1837 is now a backup in a primary/back-up arrangement). The Load-share value 1838 indicates that the ASP is operating in Load-share mode and will no 1839 longer share in the traffic distribution with any other currently active 1840 ASPs. 1842 A node that receives an ASPIA with an incorrect Type for a particular 1843 Routing Context will respond with an Error Message (Cause: Invalid 1844 Traffic Handling Mode. 1846 The format and description of the optional Routing Context and Info 1847 String parameters is the same as for the ASPAC message (See Section 1848 2.3.3.3.) 1850 3.4.8 ASP Inactive Ack 1852 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 1853 received from a remote M3UA peer. 1855 The ASPIA Ack message contains the following parameters: 1857 Type Mandatory 1858 Routing Context Optional 1859 INFO String Optional 1861 The format for the ASPIA Ack message is as follows: 1863 0 1 2 3 1864 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 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | Type | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Tag = 6 | Length | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 \ \ 1871 | Routing Context* | 1872 \ \ 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | Tag = 4 | Length | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 \ \ 1877 | INFO String* | 1878 \ \ 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 The format and description of the optional Info String parameter is the 1882 same as for the DUNA message (See Section 3.3.2.1.) 1884 The format of the Type and Routing Context parameters is the same as for 1885 the ASP-Inctive message. (See Section 3.4.7). 1887 3.4.9 Heartbeat (BEAT) 1889 The Heartbeat message is optionally used to ensure that the M3UA peers 1890 are still available to each other. It is recommended for use when the 1891 M3UA runs over a transport layer other than the SCTP, which has its own 1892 heartbeat. 1894 The BEAT message contains no parameters. 1896 3.5 Management Messages 1898 3.5.1 Error (ERR) 1900 The Error message is used to notify a peer of an error event associated 1901 with an incoming message. For example, the message type might be 1902 unexpected given the current state, or a parameter value might be 1903 invalid. 1905 The ERR message contains the following parameters: 1907 Error Code Mandatory 1908 Diagnostic Information Optional 1910 The format for the ERR message is as follows: 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Error Code | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Tag = 7 | Length | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 \ \ 1920 | Diagnostic Information* | 1921 \ \ 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 Error Code: 32-bits (unsigned integer) 1926 The Error Code parameter indicates the reason for the Error Message. 1927 The Error parameter value can be one of the following values: 1929 Invalid Version 0x1 1930 Invalid Network Appearance 0x2 1931 Invalid Adaptation Layer Identifier 0x3 1932 Invalid Message Type 0x4 1933 Invalid Traffic Handling Mode 0x5 1934 Unexpected Message Type 0x6 1935 Protocol Error 0x7 1937 Diagnostic Information: variable length 1939 When included, the optional Diagnostic information can be any 1940 information germane to the error condition, to assist in identification 1941 of the error condition. In the case of an Invalid Network Appearance, 1942 Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic 1943 information includes the received parameter. In the other cases, the 1944 Diagnostic information may be the first 40 bytes of the offending 1945 message. 1947 In the case of an Invalid Version Error Code, the Common Header contains 1948 the supported Version. 1950 Error messages are not generated in response to other Error messages. 1952 3.5.2 Notify (NTFY) 1954 The Notify message used to provide an autonomous indication of M3UA 1955 events to an M3UA peer. 1957 The NTFY message contains the following parameters: 1959 Status Type Mandatory 1960 Status Identification Mandatory 1961 Routing Context Optional 1962 INFO String Optional 1964 The format for the NTFY message is as follows: 1966 0 1 2 3 1967 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 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Status Type | Status Identification | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Tag = 6 | Length | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 \ \ 1974 | Routing Context* | 1975 \ \ 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Tag = 4 | Length | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 \ \ 1980 | INFO String* | 1981 \ \ 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Status Type: 16-bits (unsigned integer) 1986 The Status Type parameter identifies the type of the Notify message. 1987 Following are the valid Status Type values: 1989 1 Application Server state change (AS_State_Change) 1990 2 Other 1992 Status Information: 16-bits (unsigned integer) 1994 The Status Information parameter contains more detailed information for 1995 the notification, based on the value of the Status Type. 1997 If the Status Type is AS_State_Change the following Status Information 1998 values are used: 2000 1 Application Server Down (AS_Down) 2001 2 Application Server Up (AS_Up) 2002 3 Application Server Active (AS_Active) 2003 4 Application Server Pending (AS_Pending) 2004 5 Alternate ASP Active 2005 6 Insufficient ASPs 2007 These notifications are sent from an SG to an ASP upon a change in 2008 status of a particular Application Server. The value reflects the new 2009 state of the Application Server. 2011 If the Status Type is Other, then the following Status Information 2012 values are defined: 2014 1 Insufficient ASP resources active in AS 2016 This notification is not based on the SG reporting the state change of 2017 an ASP or AS. For the value defined the SG is indicating to an ASP(s) 2018 in the AS that another ASP is required in order to handle the load of 2019 the AS. 2021 The format and description of the optional Routing Context and Info 2022 String parameters is the same as for the ASPAC message (See Section 2023 3.4.6.) 2024 4.0 Procedures 2026 The M3UA layer needs to respond to various local primitives it receives 2027 from the SCTP and M3UA-User layers and Layer Management as well as the 2028 messages that it receives from the peer M3UA layers. This section 2029 describes the M3UA procedures in response to these events. 2031 4.1 Procedures to support the services of the M3UA layer 2033 4.1.1 Receipt of primitives from the M3UA-User 2035 On receiving an MTP-Transfer primitive from an upper layer, or the nodal 2036 inter-working function at an SG, the M3UA layer will send a 2037 corresponding Data message (see Section 2) to its M3UA peer. The M3UA 2038 layer must fill in various fields of the common and specific headers 2039 correctly. 2041 At an SG, the M3UA address translation and mapping function determines 2042 the Application Server (AS) based on the information in the incoming 2043 message. From an ordered list of ASPs within the AS table, an Active 2044 ASP is selected and a Data message is constructed and issued on the 2045 corresponding SCTP Association. If more than one ASP is active (i.e., 2046 traffic is to be load-shared across all the active ASPs), one of the 2047 active ASPs from the list is selected. The selection algorithm is 2048 implementation dependent but could be roud-robin or based on, for 2049 example, the SLS or ISUP CIC. The appropriate selection algorithm must 2050 be chosen carefully as it is dependent on application assumptions and 2051 understanding of the degree of state coordination between the active 2052 ASPs in the AS. 2054 In addition, the message needs to be sent on the appropriate SCTP 2055 stream, again taking care to meet the message sequencing needs of the 2056 signalling application. 2058 4.1.2 Receipt of primitives from the Layer Management 2060 On receiving these primitives from the local Layer Management, the M3UA 2061 layer will send the corresponding management message (Error) to its 2062 peer. The M3UA layer must fill in the various fields of the common and 2063 specific headers correctly. 2065 4.2 Receipt of Peer Management messages 2067 Upon receipt of Management messages, the M3UA layer must invoke the 2068 corresponding Layer Management primitive indications (M-ERROR ind.) to 2069 the local layer management. 2071 4.3 Procedures to support the M3UA services in Section 1.4.4 2073 These procedures support the M3UA management of SCTP Associations 2074 between SGs and ASPs. 2076 4.3.1 State Maintenance 2078 The M3UA layer on the SG maintains the state of each AS, in each 2079 Application Server that it is configured to receive traffic, as input to 2080 the M3UA address translation and mapping function. 2082 4.3.1.1 ASP States 2084 The state of each ASP, in each AS that it is configured, is maintained 2085 in the M3UA layer in the SG. The state of a particular ASP in a 2086 particular AS changes due to events. The events include: 2088 * Reception of messages from the peer M3UA layer at the ASP 2089 * Reception of some messages from the peer M3UA layer at other ASPs 2090 in the AS 2091 * Reception of indications from the SCTP layer 2092 * Switch-over Time triggers 2094 The ASP state transition diagram is shown in Figure 4. The possible 2095 states of an ASP are: 2097 ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the SCTP 2098 association is down. Initially all ASPs will be in this state. 2100 ASP-UP: The remote M3UA peer at the ASP is available (and the SCTP 2101 association is up) but application traffic is stopped. 2103 ASP-ACTIVE: The remote M3UA peer at the ASP is available and application 2104 traffic is active (for a particular Routing Context or set of Routing 2105 Contexts). 2107 Figure 4: ASP State Transition Diagram 2109 +-------------+ 2110 +----------------------| | 2111 | Alternate +-------| ASP-ACTIVE |<------------+ 2112 | ASP | +-------------+ | 2113 | Takeover | ^ | | 2114 | | ASP | | ASP | 2115 | | Active | | Inactive | ASP 2116 | | | v |Takeover 2117 | | +-------------+ | 2118 | | | |-------------+ 2119 | +------>| ASP-UP |-------------+ 2120 | +-------------+ | 2121 | ^ | | 2122 ASP Down/ | ASP | | ASP Down / | ASP 2123 SCTP CDI | Up | | SCTP CDI | Down/ 2124 | | v | SCTP 2125 | +-------------+ | CDI 2126 | | | | 2127 +--------------------->| |<------------+ 2128 | ASP-DOWN | 2129 +-------------+ 2131 SCTP CDI: The local SCTP layer's Communication Down Indication to the 2132 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 2133 indication when it detects the loss of connectivity to the ASP's peer 2134 SCTP layer. 2136 Ts: Switch-over Time Triggers. This timer is configurable by the 2137 0perator on a per AS basis. 2139 4.3.1.2 AS States 2141 The state of the AS is maintained in the M3UA layer on the SG. 2143 The state of an AS changes due to events. These events include: 2145 * ASP state transitions 2146 * Recovery timer triggers 2148 The possible states of an AS are: 2150 AS-DOWN: The Application Server is unavailable. This state implies that 2151 all related ASPs are in the ASP-DOWN state for this AS. Initially the AS 2152 will be in this state. 2154 AS-UP: The Application Server is available but no application traffic is 2155 active (i.e., one or more related ASPs are in the ASP-UP state, but none 2156 in the ASP-Active state). 2158 AS-ACTIVE: The Application Server is available and application traffic 2159 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2161 AS-PENDING: An active ASP has transitioned from active to inactive or 2162 down and it was the last remaining active ASP in the AS. A recovery 2163 timer T(r) will be started and all incoming SCN messages will be queued 2164 by the SG. If an ASP becomes active before T(r) expires, the AS will 2165 move to AS-ACTIVE state and all the queued messages will be sent to the 2166 active ASP. 2168 If T(r) expires before an ASP becomes active, the SG stops queuing 2169 messages and discards all previously queued messages. The AS will move 2170 to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move 2171 to AS-DOWN state. 2173 Figure 5: AS State Transition Diagram 2175 +----------+ one ASP trans to ACTIVE +-------------+ 2176 | |---------------------------->| | 2177 | AS-UP | | AS-ACTIVE | 2178 | |<--- --| | 2179 +----------+ \ / +-------------+ 2180 ^ | \ Tr Expiry, / ^ | 2181 | | \ at least one / | | 2182 | | \ ASP in UP / | | 2183 | | \ / | | 2184 | | \ / | | 2185 | | \ /-------/ | | 2186 one ASP | | all ASP / one ASP | | Last ACTIVE 2187 ASP 2188 trans | | trans to / \ trans to | | trans to UP or 2189 to UP | | DOWN / -------\ ACTIVE | | DOWN 2190 | | / \ | | 2191 | | / \ | | 2192 | | / \ | | 2193 | | /all ASP \ | | 2194 | v / trans to \ | v 2195 +----------+ / DOWN \ +-------------+ 2196 | |<-/ --| | 2197 | AS-DOWN | | AS-PENDING | 2198 | | | (queueing) | 2199 | |<----------------------------| | 2200 +----------+ Tr Expiry no ASP +-------------+ 2201 in UP state 2203 Tr = Recovery Timer 2205 4.3.2 ASPM procedures for primitives 2207 Before the establishment of an SCTP association the ASP state at both 2208 the SG and ASP is assumed to be "Down". 2210 As the ASP is responsible for initiating the setup of an SCTP 2211 association to an SG, the M3UA layer at an ASP receives an M-SCTP 2212 ESTABLISH request primitive from the Layer Management, the M3UA layer 2213 will try to establish an SCTP association with the remote M3UA peer at 2214 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2215 primitive from the SCTP, the M3UA layer will invoke the primitive M-SCTP 2216 ESTABLISH confirm to the Layer Management. 2218 The M3UA layers at the SG will receive an SCTP-Communication_Up 2219 indication primitive from the SCTP when the association is successfully 2220 set up. The M3UA layer will then invoke the primitive M-SCTP ESTABLISH 2221 indication to the Layer Management. 2223 Once the SCTP association is established and assuming that the local 2224 M3UA-User is ready, the local ASP M3UA Application Server Process 2225 Maintenance (ASPM) function will initiate the ASPM procedures, using the 2226 ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to the 2227 SG - see Section 4.3.3. 2229 If the M3UA layer subsequently receives an SCTP-Communication Down 2230 indication from the underlying SCTP layer, it will inform the Layer 2231 Management by invoking the M-SCTP STATUS indication primitive. The state 2232 of the remote ASP will be moved to "Down". 2234 At an ASP, the Layer Management may try to re-establish the SCTP 2235 association using M-SCTP ESTABLISH request primitive. 2237 4.3.3 ASPM procedures for peer-to-peer messages 2239 All ASPM messages are sent on a sequenced stream to ensure ordering. 2240 SCTP stream '0' is used. 2242 4.3.3.1 ASP-Up 2244 After an ASP has successfully established an SCTP association to an SG, 2245 the SG waits for the ASP to send an ASP-Up message, indicating that the 2246 ASP M3UA peer is available. The ASP is always the initiator of the ASP- 2247 Up exchange. 2249 When an ASP-Up message is received at an SG and internally the ASP is 2250 not considered locked-out for local management reasons, the SG marks the 2251 remote ASP as 'Up'. The SG responds with an ASP-Up Ack message in 2252 acknowledgement. The SG sends an-Up Ack message in response to a 2253 received ASP-Up message even if the ASP is already marked as "Up" at the 2254 SG. 2256 If for any local reason the SG cannot respond with an ASP-Up Ack, the SG 2257 responds to an ASP-Up with a ASP-Down message. 2259 At the ASP, the ASP-Up Ack message received from the SG is not 2260 acknowledged by the ASP. If the ASP does not receive a response from 2261 the SG, or an ASP-Down is received, the ASP may resend ASP-Up messages 2262 every 2 seconds until it receives an ASP-Up Ack message from the SG. 2263 The ASP may decide to reduce the frequency (say to every 5 seconds) if 2264 an ASP-Up Ack is not received after a few tries. 2266 The ASP must wait for the ASP-Up Ack message from the SG before sending 2267 any ASP traffic control messages (ASPAC or ASPIA) or Data messages or it 2268 will risk message loss. If the SG receives Data messages before an ASP 2269 Up is received, the SG should discard. 2271 4.3.3.2 ASP-Down 2273 The ASP will send an ASP-Down to an SG when the ASP is to be removed 2274 from the list of ASPs in all Application Servers that it is a member. 2276 The SG marks the ASP as "Down" and returns an ASP-Down Ack message to 2277 the ASP if one of the following events occur: 2279 - an ASP-Down message is received from the ASP, 2280 - another ASPM message is received from the ASP and the SG has 2281 locked out the ASP for management reasons. 2283 The SG sends an ASP-Down Ack message in response to a received ASP-Down 2284 message from the ASP even if the ASP is already marked as "Down" at the 2285 SG. 2287 If the ASP does not receive a response from the SG, the ASP may send 2288 ASP-Down messages every 2 seconds until it receives an ASP-Down Ack 2289 message from the SG or the SCTP association goes down. The ASP may 2290 decide to reduce the frequency (say to every 5 seconds) if an ASP-Down 2291 Ack is not received after a few tries. 2293 4.3.3.3 M3UA Version Control 2295 If an ASP-Up message with an unsupported version is received, the 2296 receiving end responds with an Error message, indicating the version the 2297 receiving node supports. 2299 This is useful when protocol version upgrades are being performed in a 2300 network. A node upgraded to a newer version should support the older 2301 versions used on other nodes it is communicating with. Because ASPs 2302 initiate the ASP-Up procedure it is assumed that the Error message would 2303 normally come from the SG. 2305 4.3.3.4 ASP-Active 2307 Anytime after the ASP has received an ASP-Up Ack from the SG, the ASP 2308 sends an ASP-Active (ASPAC) to the SG indicating that the ASP is ready 2309 to start processing traffic. In the case where an ASP is 2310 configured/registered to process the traffic for more than one 2311 Application Server across an SCTP association, the ASPAC contains one or 2312 more Routing Contexts to indicate for which Application Servers the 2313 ASPAC applies. 2315 When an ASP Active (ASPAC) message is received, the SG responds to the 2316 ASP with a ASPAC Ack message acknowledging that the ASPAC was received 2317 and starts sending traffic for the associated Application Server(s) to 2318 that ASP. 2320 There are two modes of Application Server traffic handling in the SG 2321 M3UA - Over-ride and Load-share. The Type parameter in the ASPAC 2322 message indicates the traffic handling mode used in a particular 2323 Application Server. If the SG determines that the mode indicated in an 2324 ASPAC is incompatible with the mode currently used in the AS, the SG 2325 responds with an Error message indicating "Invalid Traffic Handling 2326 Mode". 2328 In the case of an Over-ride mode AS, reception of an ASPAC message at an 2329 SG causes the redirection of all traffic for the AS to the ASP that sent 2330 the ASPAC. The SG responds to the ASPAC with an ASP-Active Ack message 2331 to the ASP. Any previously active ASP in the AS is now considered 2332 Inactive and will no longer receive traffic from the SG within the AS. 2333 The SG sends a Notify (Alternate ASP-Active) to the previously active 2334 ASP in the AS, after stopping all traffic to that ASP. 2336 In the case of a Load-share mode AS, reception of an ASPAC message at an 2337 SG causes the direction of traffic to the ASP sending the ASPAC, in 2338 addition to all the other ASPs that are currently active in the AS. The 2339 algorithm at the SG for load-sharing traffic within an AS to all the 2340 active ASPs is application and network dependent. The algorithm could, 2341 for example be round-robin or based on information in the Data message 2342 (e.g, such as the SLS, SCCP SSN, ISUP CIC value), depending on the 2343 requirements of the application and the call/transaction state handling 2344 assumptions of the collection of ASPs in the AS. The SG responds to the 2345 ASPAC with an ASP-Active Ack message to the ASP. 2347 4.3.3.5 ASP Inactive 2349 When an ASP wishes to withdraw from receiving traffic within an AS, the 2350 ASP sends an ASP Inactive (ASPIA) to the SG. In the case where an ASP 2351 is configured/registered to process the traffic for more than one 2352 Application Server across an SCTP association, the ASPIA contains one or 2353 more Routing Contexts to indicate for which Application Servers the 2354 ASPIA applies. 2356 There are two modes of Application Server traffic handling in the SG 2357 M3UA when withdrawing an ASP from service - Over-ride and Load-share. 2358 The Type parameter in the ASPIA message indicates the mode used in a 2359 particular Application Server. If the SG determines that the mode 2360 indicates in an ASPAC is incompatible with the traffic handling mode 2361 currently used in the AS, the SG responds with an Error message 2362 indicating "Invalid Traffic Handling Mode". 2364 In the case of an Over-ride mode AS, where normally another ASP has 2365 already taken over the traffic within the AS with an Over-ride ASPAC, 2366 the ASP that sends the ASPIA is already considered by the SG to be 2367 "Inactive" (i.e., in the "Up" state). An ASPIA Ack message is sent to 2368 the ASP, after ensuring that all traffic is stopped to the ASP. 2370 In the case of a Load-share mode AS, the SG moves the ASP to the "Up" 2371 state and the AS traffic is re-allocated across the remaining "active" 2372 ASPs per the load-sharing algorithm currently used within the AS. An 2373 ASPIA Ack message is sent to the ASP after all traffic is halted to the 2374 ASP. 2376 If no other ASPs are "Active" in the Application Server, the SG either 2377 discards all incoming messages for the AS or starts buffering the 2378 incoming messages for T(r)seconds, after which messages will be 2379 discarded. T(r) is configurable by the network operator. If the SG 2380 receives an ASPAC from 2381 an ASP in the AS before expiry of T(r), the buffered traffic is directed 2382 to the ASP and the timer is cancelled. 2384 4.3.3.6 NotifyIn the case where a Notify (AS-Up) message is sent by an 2385 SG that now has no ASPs active to service the traffic, the Notify does 2386 not force the ASP(s) receiving the message to become active. The ASPs 2387 remain in control of what (and when) action is taken. 2389 4.3.3.7 Heartbeat 2391 The optional Heartbeat procedures may be used when operating over 2392 transport layers that do not have their own heartbeat mechanism for 2393 detecting loss of the transport association (i.e., other than the SCTP). 2395 Once the ASP sends an ASP-Up message to the SG, the ASP sends Beat 2396 messages periodically, subject to a provisionable timer T(beat). The SG 2397 M3UA, upon receiving a BEAT message from the ASP, responds with a BEAT 2398 message. If no BEAT message (or any other M3UA message), is received 2399 from the ASP within the timer 2*T(beat), the ASP will consider the 2400 remote M3UA as 'Down". 2402 At the ASP, if no BEAT message (or any other M3UA message) is received 2403 from the SG within 2*T(beat), the SG is considered unavailable. 2405 Transmission of BEAT messages is stopped and ASP-Up procedures are used 2406 to re-establish communication with the SG M3UA peer. 2408 Note: Heartbeat related events are not shown in Figure 4 "ASP state 2409 transition diagram". 2411 4.4 Procedures to support the M3UA services in Section 1.4.3 2413 4.4.1 At an SG 2415 On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication 2416 primitive from the nodal inter-working function at an SG, the SG M3UA 2417 layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message 2418 (see Section 2) to the M3UA peers at concerned ASPs. The M3UA layer 2419 must fill in various fields of the SSNM messages consistently with the 2420 information received in the primitives. 2422 The SG M3UA determines the set of concerned ASPs to be informed based on 2423 the SS7 network partition for which the primitive indication is 2424 relevant. In this way, all ASPs configured to send/receive traffic 2425 within a particular network appearance are informed. If the SG operates 2426 within a single SS7 network appearance, then all ASPs are informed. 2428 Optionally, the SG M3UA may filter further based on the Affected Point 2429 Code in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives. 2430 In this way ASPs can be informed only of affected destinations to which 2431 they actually communicate. The SG M3UA may also suppress DUPU messages 2432 to ASPs that do not implement an MTP3-User protocol peer for the 2433 affected MTP3-User. 2435 DUNA, DAVA, SCON messages must be sent on a sequenced stream as these 2436 primitives should arrive in order. Stream 0 is used. Sequencing is not 2437 required for the DUPU or DAUD message, which may optionally be sent un- 2438 sequenced. 2440 4.4.2 At an ASP 2442 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, the 2443 M3UA layer invokes the appropriate primitive indications to the resident 2444 M3UA-Users. Local management is informed. 2446 4.4.3 ASP Auditing 2448 An ASP may optionally initiate an audit procedure in order to enquire of 2449 an SG the availability or congestion status of an SS7 destination or set 2450 of destinations. A Destination Audit (DAUD) message is sent from the 2451 ASP to the SG requesting the current availability or congestion status 2452 of one or more SS7 Destination Point Codes. 2454 The DAUD may be sent by the ASP in the following cases. The DAUD may be 2455 sent unsequenced. 2457 - Periodic. A Timer originally set upon reception of DUVA or SCON 2458 message has expired without a subsequent DAVA, DUVA or SCON 2459 updating the availability/congestion status of the affected 2460 Destination Point Codes. The Timer is reset upon issuing a DAUD. 2461 In this case the DAUD is sent to the SG that originally sent the 2462 SSNM message. 2464 - the ASP is newly "Up" or "Active" or has been isolated from an SG 2465 for an extended period. The SG can request the 2466 availabilty/congestion status of one or more SS7 destinations to 2467 which it expects to communicate. 2469 In the first case, the DAUD procedure must not be invoked for the case 2470 of received SCON containing a congestion level value of "no congestion" 2471 or undefined" (i.e., congestion Level = "0"). This is because the value 2472 ndicates either congestion abatement or that the ITU MTP3 international 2473 ongestion method is being used. In the international congestion method, 2474 the MTP3 at the SG does not maintain the congestion status of any 2475 destinations and therefore cannot provide any congestion information in 2476 response to the DAUD. For the same reason, in the second case a DAUD 2477 cannot reveal any congested destination(s). 2479 The SG must respond to a DAUD with the MTP3 status of the routeset 2480 associated with each Destination Point Code(s) in the DAUD. The status 2481 of each SS7 destination requested is indicated in a DUNA (if 2482 unavailable), DAVA (if available/uncongested) or an SCON (if 2483 available/congested). Optionally, any DUNA or DAVA in response to a 2484 DAUD may contain more than one Affected Point Code. 2486 Note that from the point of view of an ASP sending an DAUD, the 2487 subsequent reception of an SCON implies that the Affected Destination is 2488 available. The reception of a DAVA implies that the routeset to the 2489 Affected Destination are not congested. Obviously with the reception of 2490 an DUNA, the routeset to the Affected Destination can not also be 2491 congested. 2493 5.0 Examples of M3UA Procedures 2495 5.1 Establishment of Association and Traffic between SGs and ASPs 2497 5.1.1 Single ASP in an Application Server ("1+0" sparing) 2499 This scenario shows the example M3UA message flows for the establishment 2500 of traffic between an SG and an ASP, where only one ASP is configured 2501 within an AS (no backup). It is assumed that the SCTP association is 2502 already set-up. 2504 SG ASP1 2505 | 2506 |<---------ASP Up----------| 2507 |-------ASP-Up Ack-------->| 2508 | - | 2509 |<-------ASP Active--------| 2510 |-----ASP Active Ack------>| 2511 | | 2513 5.1.2 Two ASPs in Application Server ("1+1" sparing) 2515 This scenario shows the example M3UA message flows for the establishment 2516 of traffic between an SG and two ASPs in the same Application Server, 2517 where ASP1 is configured to be "active" and ASP2 a "standby" in the 2518 event of communication failure or the withdrawal from service of ASP1. 2519 ASP2 may act as a hot, warm, or cold standby depending on the extent to 2520 which ASP1 and ASP2 share call/transaction state or can communicate call 2521 state under failure/withdrawal events. The example message flow is the 2522 same whether the ASP-Active messages are Over-ride or Load-share mode 2523 although typically this example would use an Over-ride mode. 2525 SG ASP1 ASP2 2526 | | | 2527 |<--------ASP Up----------| | 2528 |-------ASP-Up Ack------->| | 2529 | | | 2530 |<-----------------------------ASP Up----------------| 2531 |-----------------------------ASP-Up Ack------------>| 2532 | | | 2533 | | | 2534 |<-------ASP Active-------| | 2535 |------ASP-Active Ack---->| | 2536 | | | 2538 5.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing 2539 case) 2541 This scenario shows a similar case to Section 4.1.2 but where the two 2542 ASPs are brought to "active" and load-share the traffic load. In this 2543 case, one ASP is sufficient to handle the total traffic load. 2545 SG ASP1 ASP2 2546 | | | 2547 |<---------ASP Up---------| | 2548 |--------ASP-Up Ack------>| | 2549 | | | 2550 |<------------------------------ASP Up---------------| 2551 |-----------------------------ASP Up Ack------------>| 2552 | | | 2553 | | | 2554 |<--ASP Active (Ldshr)----| | 2555 |-----ASP-Active Ack----->| | 2556 | | | 2557 |<----------------------------ASP Active (Ldshr)-----| 2558 |-------------------------------ASP-Active Ack------>| 2559 | | | 2561 5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 2562 case) 2564 This scenario shows the example M3UA message flows for the establishment 2565 of traffic between an SG and three ASPs in the same Application Server, 2566 where two of the ASPs are brought to "active" and share the load. In 2567 this case, a minimum of two ASPs are required to handle the total 2568 traffic load (2+1 sparing). 2570 SG ASP1 ASP2 ASP3 2571 | | | | 2572 |<------ASP Up-------| | | 2573 |-----ASP-Up Ack---->| | | 2574 | | | | 2575 |<--------------------------ASP Up-------| | 2576 |-------------------------ASP-Up Ack)--->| | 2577 | | | | 2578 |<---------------------------------------------ASP Up--------| 2579 |---------------------------------------------ASP-Up Ack---->| 2580 | | | | 2581 | | | | 2582 |<--ASP Act (Ldshr)--| | | 2583 |----ASP-Act Ack---->| | | 2584 | | | | 2585 |<--------------------ASP Act. (Ldshr)---| | 2586 |-----------------------ASP-Act Ack----->| | 2587 | | | | 2589 5.2 ASP Traffic Fail-over Examples 2591 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2593 Following on from the example in Section 4.1.2, and ASP withdraws from 2594 service: 2596 SG ASP1 ASP2 2597 | | | 2598 |<-----ASP Inactive-------| | 2599 |----ASP Inactive Ack---->| | 2600 |-------------------------NTFY(AS-Down) (Optional)-->| 2601 | | | 2602 |<------------------------------ ASP Active----------| 2603 |------------------------------ASP-Active Ack)------>| 2604 | | 2606 Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or 2607 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 2608 exchange would not occur. 2610 5.2.2 (1+1 Sparing, Back-up Over-ride) 2612 Following on from the example in Section 4.1.2, and ASP2 wishes to over- 2613 ride ASP1 and take over the traffic: 2615 SG ASP1 ASP2 2616 | | | 2617 |<------------------------------ ASP Active----------| 2618 |-------------------------------ASP-Active Ack------>| 2619 |----NTFY(Alt ASP-Act)--->| 2620 | | | 2622 5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) 2624 Following on from the example in Section 4.1.4, and ASP1 withdraws from 2625 service: 2627 SG ASP1 ASP2 ASP3 2628 | | | | 2629 |<----ASP Inact.-----| | | 2630 |---ASP-Inact Ack--->| | | 2631 | | | | 2632 |---------------------------------NTFY(Ins. ASPs)(Optional)->| 2633 | | | | 2634 |<-----------------------------------------ASP Act (Ldshr)---| 2635 |-------------------------------------------ASP Act (Ack)--->| 2636 | | | | 2638 The Notify message to ASP3 is optional, as well as the ASP-Active from 2639 ASP3. The optional Notify can only occur if the SG maintains knowledge 2640 of the minimum ASP resources required � for example if the SG knows that 2641 "n+k" = "2+1" for a load-share AS and "n" currently equals "1". 2643 Note: If the SG detects loss of the ASP1 M3UA peer (M3UA heartbeat loss 2644 or detection of SCTP failure), the first SG-ASP1 ASP Inactive message 2645 exchange would not occur. 2647 5.3 M3UA/MTP3-User Boundary Examples 2649 5.3.1 At an ASP 2651 This section describes the primitive mapping from the MTP3 User to M3UA 2652 at an ASP. 2654 5.3.1.1 Support for MTP-Transfer on the ASP 2656 5.3.1.1.1 Support for MTP-Transfer Request 2657 When the MTP3-User on the ASP has data to send into the SS7 network, it 2658 will use the MTP-Transfer Request primitive. The M3UA on the ASP will 2659 do the following when it receives an MTP-Transfer Request primitive from 2660 the M3UA user: 2662 - Determine the correct SG 2664 - Determine the correct association to the chosen SG 2666 - Determine the correct stream in the association (e.g., based on 2667 SLS) 2669 - Determine whether to complete the optional fields of the Data 2670 message 2672 - Map the MTP-Transfer Request primitive into the Protocol Data 2673 field of an m3ua Data message 2675 - Send the Data message to the remote M3UA peer in the SG, over the 2676 SCTP association 2678 SG ASP 2679 | | 2680 |<-----Data Message-------|<--MTP-Transfer req. 2681 | | 2683 5.3.1.1.2 Support for MTP Transfer Indication 2685 When the M3UA on the ASP has received Data messages from the remote M3UA 2686 peer in the SG it will do the following: 2688 - Evaluate the optional fields of the Data message if present 2690 - Map the Payload of a Data message into the MTP-Transfer Indication 2691 primitive 2693 - Pass the MTP-Transfer Indication primitive to the user part. In 2694 case of multiple user parts, the optional fields of the Data 2695 message are used to determine the concerned user part. 2697 SG ASP 2698 | | 2699 |------Data Message------>|---MTP-Transfer ind. 2700 | | 2702 5.3.1.1.3 Support for ASP Querying of SS7 Destination States 2704 There are situations such as temporary loss of connectivity to the SG 2705 that may cause the M3UA on the ASP to audit SS7 destination availability 2706 states. Note: there is no primitive for the MTP3-User to request this 2707 audit from the M3UA as this is initiated by an internal M3UA management 2708 function. 2710 The M3UA on the ASP normally sends Destination State Audit (DAUD) 2711 messages for each of the destinations that the ASP supports. 2713 SG ASP 2714 | | 2715 |<-----DAUD Message ------| 2716 |<-----DAUD Message ------| 2717 |<-----DAUD Message ------| 2718 | | 2719 | | 2721 5.3.2 At an SG 2723 This section describes the MTP3 upper layer primitive mapping to the 2724 M3UA at the SG. 2726 5.3.2.1 Support for MTP-Transfer Request at the SG 2728 When the M3UA on the SG has received Data messages from its peer 2729 destined to the SS7 network it will do the following: 2731 - Evaluate the optional fields of the Data message if present to 2732 determine the network appearance 2734 - Map the Protocol data of the Data message into an MTP-Transfer 2735 Request primitive 2737 - Pass the MTP-Transfer Request primitive to the MTP3 of the 2738 concerned network appearance. 2740 SG ASP 2741 | | 2742 <---MTP-Transfer req.|<------Data Message------| 2743 | | 2745 5.3.2.2 Support for MTP-Transfer Indication at the SG 2747 When the MTP3 on the SG has data to pass its user parts, it will use the 2748 MTP-Transfer Indication primitive. The M3UA on the S>G will do the 2749 following when it receives an MTP-Transfer Indication: 2751 - Determine the correct ASP 2753 - Determine the correct association to the chosen ASP 2755 - Determine the correct stream in the association (e.g., based on 2756 SLS) 2758 - Determine whether to complete the optional fields of the Data 2759 message 2761 - Map the MTP-Transfer Indication primitive into the Protocol Data 2762 field of an M3UA Data message 2764 - Send the Data message to the remote M3UA peer in the ASP, over the 2765 SCTP association 2767 SG ASP 2768 | | 2769 --MTP-Transfer ind.->|------Data Message------>| 2770 | | 2772 5.3.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS 2774 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the 2775 MTP3 upper layer interface at the SG need to be made available to the 2776 remote MTP3 User Part lower layer interface at the concerned ASP(s). 2778 5.3.2.3.1 Destination Unavailable 2780 The MTP3 on the SG will generate an MTP-PAUSE primitive when it 2781 determines locally that an SS7 destination is unreachable. The M3UA 2782 will map this primitive to a Destination Unavailable (DUNA) message. It 2783 will determine which ASP(s) to send the DUNA based on the Network 2784 Appearance information. 2786 SG ASP 2787 | | 2788 --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.--> 2789 | | 2791 5.3.2.3.2 Destination Available 2793 The MTP3 on the SG will generate an MTP-RESUME primitive when it 2794 determines locally that an SS7 destination that was previously 2795 unreachable is now reachable. The M3UA will map this primitive to a 2796 Destination Unavailable (DAVA) message. It will determine which ASP(s) 2797 to send the DUNA based on the Network Appearance information. 2799 SG ASP 2800 | | 2801 --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.--> 2802 | | 2804 5.3.2.3.3 SS7 Network Congestion 2806 The MTP3 on the SG will generate an MTP-STATUS primitive when it 2807 determines locally that the route to an SS7 destination is congested. 2808 The M3UA will map this primitive to a SS7 Network Congestion State 2809 (SCON) message. It will determine which ASP(s) to send the DUPU to 2810 based on the intended Application Server. 2812 SG ASP 2813 | | 2814 --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.--> 2815 | | 2817 5.3.2.3.4 Destination User Part Unavailable 2819 The MTP3 on the SG will generate an MTP-STATUS primitive when it 2820 determines locally that an SS7 destination User Part is unavailable. 2821 The M3UA will map this primitive to a Destination User Part Unavailable 2822 (DUPU) message. It will determine which ASP(s) to send the DUPU based 2823 on the intended Application Server. 2825 SG ASP 2826 | | 2827 --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.--> 2828 | | 2830 6.0 Security 2832 6.1 Introduction 2834 M3UA is designed to carry signalling messages for telephony services. As 2835 such, M3UA must involve the security needs of several parties: the end 2836 users of the services; the network providers and the applications 2837 involved. Additional requirements may come from local regulation. 2838 While having some overlapping security needs, any security solution 2839 should fulfill all of the different parties' needs. 2841 6.2 Threats 2843 There is no quick fix, one-size-fits-all solution for security. As a 2844 transport protocol, M3UA has the following security objectives: 2846 * Availability of reliable and timely user data transport. 2847 * Integrity of user data transport. 2848 * Confidentiality of user data. 2850 M3UA runs on top of SCTP. SCTP [6] provides certain transport related 2851 security features, such as some protection against: 2853 * Blind Denial of Service Attacks 2854 * Flooding 2855 * Masquerade 2856 * Improper Monopolization of Services 2858 When M3UA is running in professionally managed corporate or service 2859 provider network, it is reasonable to expect that this network includes 2860 an appropriate security policy framework. The "Site Security Handbook" 2861 [21] should be consulted for guidance. 2863 When the network in which M3UA runs in involves more than one party, it 2864 may not be reasonable to expect that all parties have implemented 2865 security in a sufficient manner. In such a case, it is recommended that 2866 IPSEC is used to ensure confidentiality of user payload. Consult [22] 2867 for more information on configuring IPSEC services. 2869 6.3 Protecting Confidentiality 2871 Particularly for mobile users, the requirement for confidentiality may 2872 include the masking of IP addresses and ports. In this case application 2873 level encryption is not sufficient; IPSEC ESP should be used instead. 2874 Regardless of which level performs the encryption, the IPSEC ISAKMP 2875 service should be used for key management. 2877 7.0 IANA Considerations 2879 A request will be made to IANA to assign an M3UA value for the Payload 2880 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 2881 Payload Protocol Identifier will be registered: 2883 M3UA tbd 2885 The SCTP Payload Protocol Identifier is included in each SCTP Data 2886 chunk, to indicate which protocol the SCTP is carrying. This Payload 2887 Protocol Identifier is not directly used by SCTP but may be used by 2888 certain network entities to identify the type of information being 2889 carried in a Data chunk. 2891 The User Adaptation peer may use the Payload Protocol Identifier as a 2892 way of determining additional information about the data being presented 2893 to it by SCTP. 2895 8.0 Acknowledgements 2897 The authors would like to thank John Loughney, Neil Olson, Michael 2898 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Heinz Prantner, Barry 2899 Nagelberg for their valuable comments and suggestions. 2901 9.0 References 2903 [1] RFC 2719, "Framework Architecture for Signaling Transport" 2905 [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) 2906 � ISDN User Part (ISUP)' 2908 [3] ANSI T1.113 - 'Signaling System Number 7 � ISDN User Part 2910 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 2911 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 2912 international interface; Part 1: Basic services" 2914 [5] ITU-T Recommendations Q.711-715, 'Signalling System No. 7 (SS7) - 2915 Signalling Connection Control Part (SCCP)' 2917 [6] ANSI T1.112 'Signaling System Number 7 � Signaling Connection 2918 Control Part' 2920 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 2921 Signalling System No.7; Signalling Connection Control Part (SCCP) 2922 (connectionless and connection-oriented class 2) to support 2923 international interconnection; Part 1: Protocol specification" 2925 [8] ITU-T Recommendations Q.720, 'Telephone User Part' 2927 [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - 2928 Transaction Capabilities (TCAP) 2930 [10] ANSI T1.114 'Signaling System Number 7 � Transaction Capabilities 2931 Application Part' 2933 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 2934 Signalling System No.7; Transaction Capabilities (TC) version 2; 2935 Part 1: Protocol specification" 2937 [12] 3G TS 25.410 V3.1.0 (2000-01) Technical Specification � 3rd 2938 Generation partnership Project; Technical Specification Group 2939 Radio Access Network; UTRAN Iu Interface: General Aspects and 2940 Principles (3G TS 25.410 Version 3.1.0 Release 1999) 2942 [13] Stream Control Transport Protocol , July 2000, Work in Progress 2945 [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7) 2946 - Message Transfer Part (MTP)' 2948 [15] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' 2950 [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 2951 Signalling System No.7; Message Transfer Part (MTP) to support 2952 international interconnection; Part 1: Protocol specification" 2954 [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service 2955 Specific Coordination Function for signalling at the Network Node 2956 Interface (SSCF at NNI) 2958 [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service 2959 Specific Connection Oriented Protocol (SSCOP) 2961 [19] MTP2-User Adaptation Layer , Nov. 2962 1999, Work in Progress 2964 [20] ITU-T Recommendation Q.2210 'B-ISDN MTP' 2966 [21] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 2968 [22] RFC 2401, "Security Architecture for the Internet Protocol", S. 2969 Kent, R. Atkinson, November 1998. 2971 10.0 Author's Addresses 2973 Lyndon Ong 2974 Nortel Networks 2975 4401 Great America Pkwy 2976 Santa Clara, CA, USA 95054 2977 long@nortelnetworks.com 2979 Greg Sidebottom 2980 Nortel Networks 2981 3685 Richmond Rd, 2982 Nepean, Ontario, Canada K2H 5B7 2983 gregside@nortelnetworks.com 2985 Guy Mousseau 2986 Nortel Networks 2987 3685 Richmond Rd 2988 Nepean, Ontario, Canada K2H 5B7 2990 Ian Rytina 2991 Ericsson Australia 2992 37/360 Elizabeth Street 2993 Melbourne, Victoria 3000, Australia 2994 ian.rytina@ericsson.com 2996 Hanns Juergen Schwarzbauer 2997 SIEMENS AG 2998 Hofmannstr. 51 2999 81359 Munich, Germany 3000 HannsJuergen.Schwarzbauer@icn.siemens.de 3002 Ken Morneault 3003 Cisco Systems Inc. 3004 13615 Dulles Technology Drive 3005 Herndon, VA, USA 20171 3006 EMail: kmorneau@cisco.com 3007 Malleswar Kalla 3008 Telcordia Technologies 3009 MCC 1J211R 3010 445 South Street 3011 Morristown, NJ, USA 07960 3012 EMail: kalla@research.telcordia.com 3014 Normand Glaude 3015 Performance Technologies 3016 150 Metcalf Sreet, Suite 1300 3017 Ottawa, Ontario, Canada K2P 1P1 3018 EMail: nglaude@microlegend.com 3020 This draft expires December 2000.