idnits 2.17.1 draft-ietf-sigtran-m3ua-02.txt: -(194): 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 20 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 55 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. ** 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 874: '... an M3UA message MUST be transmitted i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 544 has weird spacing: '...e hosts and t...' == Line 1727 has weird spacing: '...ges and disca...' -- 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 (10 March 2000) is 8810 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) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '21') ** Obsolete normative reference: RFC 2401 (ref. '22') (Obsoleted by RFC 4301) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 21 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 12 Expires in six months 10 March 2000 14 SS7 MTP3-User Adaptation Layer (M3UA) 15 17 Status of This Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC 2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as 'work in progress.' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check the 37 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 38 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 40 ftp.isi.edu (US West Coast). 42 Abstract 44 This Internet Draft defines a protocol for the transport of any SS7 45 MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the 46 Simple Control Transport Protocol. Also, provision is made for 47 protocol elements that enable a seamless operation of the MTP3-User 48 peers in the SS7 and IP domains. This protocol would be used between a 49 Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP- 50 resident Database. It is assumed that the SG receives SS7 signaling 51 over a standard SS7 interface using the SS7 Message Transfer Part (MTP) 52 to provide transport. 54 TABLE OF CONTENTS 56 1. Introduction.......................................................3 57 1.1 Scope.........................................................3 58 1.2 Terminology...................................................5 59 1.3 Signalling Transport Architecture.............................5 60 1.4 Services Provided by the M3UA Layer..........................13 61 1.5 Internal Functions in the M3UA...............................15 62 1.6 Definition of M3UA Boundaries................................18 63 2. M3UA Protocol Elements............................................18 64 2.1 Common Message Header........................................19 65 2.2 Transfer Messages............................................20 66 2.3 SS7 Signaling Network management (SSNM) Messages.............21 67 2.4 Application Server Process Maintenance Messages..............27 68 2.5 Management Messages..........................................31 69 3. Procedures........................................................34 70 3.1 Procedures to Support the Services of the M3UA Layer.........34 71 3.2 Procedures to Support the M3UA Services in Section 1.4.2.....34 72 3.3 Procedures to Support the M3UA Services in Section 1.4.4.....35 73 3.4 Procedures to Support the M3UA Services in Section 1.4.3.....43 74 4. Examples of M3UA Procedures.......................................45 75 4.1 Establishment of Association and Traffic 76 Between SGs and ASPs.........................................45 77 4.2 ASP traffic Failover Examples................................47 78 4.3 M3UA/MTP3-User Boundary Examples.............................48 79 5. Security..........................................................52 80 5.1 Introduction.................................................52 81 5.2 Threats......................................................52 82 5.3 Protecting Confidentiality...................................53 83 6. IANA Considerations...............................................53 84 7. Acknowledgements..................................................53 85 8. References........................................................53 86 9. Author's Addresses................................................55 87 1. Introduction 89 1.1 Scope 91 There is a need for SCN signaling protocol delivery from an SS7 92 Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP- 93 resident Database as described in the Framework Architecture for 94 Signalling Transport [1]. The delivery mechanism should meet the 95 following criteria: 97 * Support for transfer of all SS7 MTP3-User Part messages (e.g., ISUP, 98 SCCP, TUP, etc.) 99 * Support for the seamless operation of MTP3-User protocol peers 100 * Support for the management of SCTP transport associations and 101 traffic between an SG and one or more MGCs or IP-resident Databases 102 * Support for MGC or IP-resident Database failover and loadsharing 103 * Support for the asynchronous reporting of status changes to 104 management 106 In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols 107 and deliver ISUP, SCCP and/or any other MTP3-User protocol messages 108 over SCTP transport associations to MTP3-User peers in MGCs or IP- 109 resident Databases. 111 1.2 Terminology 113 Application Server (AS) - A logical entity serving a specific Routing 114 Key. An example of an Application Server is a virtual switch element 115 handling all call processing for a unique range of PSTN trunks, 116 identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual 117 database element, handling all HLR transactions for a particular SS7 118 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more 119 unique Application Server Processes, of which one or more is normally 120 actively processing traffic. 122 Application Server Process (ASP) - A process instance of an Application 123 Server. An Application Server Process serves as an active or standby 124 process of an Application Server (e.g., part of a distributed virtual 125 switch or database element). Examples of ASPs are processes (or process 126 instances of) MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- 127 point and may be configured to process signalling traffic within more 128 than one Application Server. 130 Association - An association refers to an SCTP association. The 131 association provides the transport for the delivery of MTP3-User 132 protocol data units and M3UA adaptation layer peer messages. 134 Routing Key: At the SG, the Routing Key describes a set of SS7 135 parameter/parameter-ranges that uniquely defines the range of 136 signalling traffic configured to be handled by a particular Application 137 Server. For example, where all traffic directed to a particular SS7 138 DPC, OPC and ISUP CIC_range(s) or SCCP SSN is to be sent to a 139 particular Application Server, that SS7 data defines the associated 140 Routing Key. Routing Keys are mutually exclusive in the sense that a 141 received SS7 signalling message cannot be directed to more than one 142 Routing Key. Also, a Routing Key cannot extend across more than a 143 single SS7 DPC, in order to more easily support SS7 Management 144 procedures. It is not necessary for the parameter ranges within a 145 particular Routing Key to be contiguous. For example, an ASP could be 146 configured to support call processing for multiple ranges of PSTN 147 trunks that are not represented by contiguous CIC values. 149 Routing Context � An Application Server Process may be configured to 150 process traffic within more than one Application Server. In this case, 151 the Routing Context parameter is exchanged beween the SG and the ASP, 152 identifying the relevant Application Server. From the perspective of 153 an ASP, the Routing Context uniquely identifies the range of traffic 154 associated with a particular Application Server, which the ASP is 155 configured to receive from the SG. There is a 1:1 relationship between 156 a Routing Context value and a Routing Key at an SG. Therefore the 157 Routing Context can be viewed as an index into an SG Table containing 158 the SG Routing Keys. 160 Fail-over - The capability to re-route signaling traffic as required to 161 an alternate Application Server Process, or group of ASPs, within an 162 Application Server in the event of failure or unavailability of a 163 currently used Application Server Process. Fail-back may apply upon 164 the return to service of a previously unavailable Application Server 165 Process. 167 Signalling Point Management Cluster (SPMC) A complete set of 168 Application Servers represented to the SS7 network under the same SS7 169 Point Code. SPMCs are used to sum the 170 availability/congestion/User_Part status of an SS7 destination point 171 code that is distributed in the IP domain, for the purpose of 172 supporting MTP3 management procedures at an SG. In some cases, the SG 173 itself may also be a member of the SPMC. In this case, the SG 174 availability/congestion/User_Part status must also be taken into 175 account when considering any supporting MTP3 management actions. 177 MTP3-User - Any protocol normally using the services of the SS7 MTP3 178 (e.g., ISUP, SCCP, TUP, etc.). 180 Network Appearance � The Network Appearance identifies an SS7 network 181 context for the purposes of logically separating the signaling traffic 182 between the SG and the Application Server Processes over a common SCTP 183 Association. An example is where an SG is logically partitioned to 184 appear as an element in four separate national SS7 networks. A Network 185 Appearance implicitly defines the SS7 Point Code(s), Network Indicator 186 and MTP3 protocol type/variant/version used within a specific SS7 187 network partition. An physical SS7 route-set or link-set at an SG can 188 appear in only one network appearance. The Network Appearance is not 189 globally significant and requires coordination only between the SG and 190 the ASP. 192 Network Byte Order: Most significant byte first, a.k.a Big Endian. 194 Layer Management � Layer Management is a nodal function in an SG or ASP 195 that handles the inputs and outputs between the M3UA layer and a local 196 management entity. 198 Host - The computing platform that the ASP process is running on. 200 Stream - A stream refers to an SCTP stream. 202 1.3 Signaling Transport Architecture 204 1.3.1 Protocol Architecture. 206 The framework architecture that has been defined for SCN signaling 207 transport over IP [1] uses multiple components, including a signaling 208 common transport protocol and an adaptation module to support the 209 services expected by a particular SCN signaling protocol from its 210 underlying protocol layer. 212 Within the framework architecture, this document defines an MTP3-User 213 adaptation module that is suitable for the transport of SS7 ISDN User 214 Part (ISUP) [2,3,4] and Signalling Connection Control Part (SCCP) 215 [5,6,7] messages but could be equally used to transport other SS7 MTP3- 216 User Part messages such as, for example, the Telephone User Part (TUP) 217 [8]. TCAP [9,10,11] or RANAP [12] messages are transported 218 transparently by the M3UA as SCCP payload, as they are SCCP-User 219 protocols. The M3UA uses the services of the Simple Common Transport 220 protocol [13] as the underlying reliable signaling common transport 221 protocol. 223 In a Signaling Gateway, it is expected that the SS7 MTP3-User signaling 224 is transmitted and received from the PSTN over a standard SS7 network 225 interface, using the SS7 Message Transfer Part (MTP) [14,15,16] to 226 provide reliable transport of the MTP3-User signaling messages to and 227 from an SS7 Signaling End Point (SEP) or Signaling Transfer Point 228 (STP). The SG then provides a functional inter-working of transport 229 functions with the IP transport, in order to transfer the MTP3-User 230 signaling messages to and from an Application Server Process where the 231 peer MTP3-User protocol layer exists. 233 The use of standard MTP Level 2 signaling links in the SS7 network 234 interface is not the only possibility. ATM-based High Speed Links 235 could also be used, using the services of the Signaling ATM Adaptation 236 Layer (SAAL) [17,18]. For that matter, it is possible that IP-based 237 links could be present, using the services of the MTP2-User Adaptation 238 Layer (M2UA) [19]. Also note that STPs may be present in the SS7 path 239 between the SS7 SEP and the SG. 241 Where ATM-base High Speed Links are used in the SS7 network, it is 242 possible for the SG to use the services of the MTP-3b [20] for reliable 243 transport to and from an SS7 SEP or STP. The maximum Service Data Unit 244 (SDU) supported by the MTP-3b is 4096 octets compared to the 272 octet 245 maximum of the MTP. However, for MTP3-Users to take advantage of the 246 larger SDU between MTP3-User peers, network architects should ensure 247 that MTP3-b is used end-to-end between the SG and the SS7-resident 248 peer. 250 Three example cases are shown below: 252 1.3.1.1 Example 1: ISUP transport 254 ******** SS7 ***************** IP ******** 255 * SEP *---------* SG *--------* ASP * 256 ******** ***************** ******** 258 +------+ +------+ 259 | ISUP | (NIF) | ISUP | 260 +------+ +------+-+------+ +------+ 261 | MTP3 | | MTP3 | | M3UA | | M3UA | 262 +------| +------+ +------+ +------+ 263 | MTP2 | | MTP2 | | SCTP | | SCTP | 264 +------+ +------+ +------+ +------+ 265 | L1 | | L1 | | IP | | IP | 266 +------+ +------+ +------+ +------+ 267 |_______________| |______________| 269 SEP - SS7 Signaling End Point 270 SCTP - Simple Common Transport Protocol 271 NIF � Nodal Interworking Function 273 Within the SG, MTP-TRANSFER indication primitives received from the MTP 274 Level 3 upper layer interface are sent to the local M3UA-resident 275 network address translation and mapping function for ongoing routing to 276 the final IP destination. MTP-TRANSFER primitives received from the 277 local M3UA network address translation and mapping function are sent to 278 the MTP Level 3 upper layer interface as MTP-TRANSFER request 279 primitives for on-going MTP Level 3 routing to an SS7 SEP. 281 For internal SG modelling purposes, this may be accomplished with the 282 use of an implementation-dependent nodal inter-working function within 283 the SG that serves to transport messages within the SG between the MTP3 284 and M3UA. This nodal inter-working function has no visible peer 285 protocol with either the ASP or SEP. 287 1.3.1.2 Example 2: SCCP transport where an SCCP function at the SG is 288 invoked: 290 ******** SS7 ***************** IP ******** 291 * SEP *---------* *--------* * 292 * or * * SG * * ASP * 293 * STP * * * * * 294 ******** ***************** ******** 296 +------+ +---------------+ +------+ 297 | SCCP | | SCCP | | SCCP | 298 +------+ +------+-+------+ +------+ 299 | MTP3 | | MTP3 | | M3UA | | M3UA | 300 +------| +------+ +------+ +------+ 301 | MTP2 | | MTP2 | | SCTP | | SCTP | 302 +------+ +------+ +------+ +------+ 303 | L1 | | L1 | | IP | | IP | 304 +------+ +------+ +------+ +------+ 305 |_______________| |______________| 307 STP - SS7 Signaling Transfer Point 309 In this example, the SG contains an instance of the SS7 SCCP protocol 310 layer that may, for example, perform the SCCP Global Title Translation 311 (GTT) function for messages logically addressed to the SG SCCP. If the 312 result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN 313 address result of an SCCP peer located in the IP domain, the resulting 314 MTP-TRANSFER request primitive is sent to the local M3UA-resident 315 network address translation and mapping function for ongoing routing to 316 the final IP destination. 318 Similarly, the SCCP instance in an SG can perform the SCCP GTT service 319 for messages logically addressed to it from SCCP peers in the IP 320 domain. In this case, MTP-TRANSFER messages are sent from the local 321 M3UA-resident network address translation and mapping function to the 322 SCCP for GTT. If the result of the GTT yields the address of an SCCP 323 peer in the SS7 network then the resulting MTP-TRANSFER request is 324 given to the MTP3 for delivery to an SS7-resident node. 326 It is possible that the above SCCP GTT at the SG could yield the 327 address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER 328 primitive would be sent back to the M3UA for delivery to an IP 329 destination. 331 For internal SG modelling purposes, this may be accomplished with the 332 use of an implementation-dependent nodal inter-working function within 333 the SG that effectively sits below the SCCP and routes MTP-TRANSFER 334 messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or 335 DPC/SSN address information. This nodal inter-working function has no 336 visible peer protocol with either the ASP or SEP. 338 Note that the services and interface provided by M3UA are the same as 339 in Example 1 and the functions taking place in the SCCP entity are 340 transparent to M3UA. The SCCP protocol functions are not reproduced in 341 the M3UA protocol. 343 1.3.1.3 Example 3 � Seamless Handling of MTP3 Management 345 ******** SS7 ***************** IP ******** 346 * SEP *---------* *--------* * 347 * or * * SG * * ASP * 348 * STP * * * * * 349 ******** ***************** ******** 351 (NIF) 352 +------+ +------+-+------+ +------+ 353 | MTP3 | | MTP3 | | M3UA | | M3UA | 354 +------| +------+ +------+ +------+ 355 | MTP2 | | MTP2 | | SCTP | | SCTP | 356 +------+ +------+ +------+ +------+ 357 | L1 | | L1 | | IP | | IP | 358 +------+ +------+ +------+ +------+ 359 |_______________| |______________| 361 In the case of SS7 MTP3 network management, it is required that the 362 MTP3-User protocols at ASPs receive indications of SS7 signaling point 363 availability, SS7 network congestion and User Part availability as 364 would be expected an SS7 SEP node. To accomplish this, the MTP-PAUSE, 365 MTP-RESUME and MTP-STATUS indication primitives received at the MTP3 366 upper layer interface at the SG need to be made available to the remote 367 MTP3-User lower layer interface at the ASP. Note: These indication 368 primitives are also made available to any existing local MTP3-Users at 369 the SG, such as the SCCP in the previous example. 371 For internal SG modelling purposes, this may be accomplished with the 372 use of an implementation-dependent nodal inter-working function within 373 the SG that effectively sits above the MTP3 and delivers MTP-PAUSE, 374 MTP-RESUME and MTP-STATUS indication primitives received from the MTP 375 Level 3 upper layer interface to the local M3UA-resident management 376 function. This nodal inter-working function has no visible peer 377 protocol with either the ASP or SEP. 379 It is important to clarify that MTP3 management messages such as TFPs 380 or TFAs received from the SS7 network are not "encapsulated" and sent 381 blindly to the ASPs. Rather, the existing MTP3 management procedures 382 are followed within the MTP3 function of the SG to re-calculate the 383 MTP3 route set status and initiate any signaling-route-set-test 384 procedures into the SS7 network. Only when a route set status changes 385 are MTP-PAUSE or MTP-RESUME primitives invoked. These primitives can 386 also be invoked due to local SS7 link set conditions as per existing 387 MTP3 procedures. 389 1.3.2 Signaling Network Architecture 391 A Signaling Gateway is used to support the transport of MTP3-User 392 signaling traffic received from the SS7 network to multiple distributed 393 ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA protocol 394 description cannot in itself meet any performance and reliability 395 requirements for such transport. A physical network architecture is 396 required, with data on the availability and transfer performance of the 397 physical nodes involved in any particular exchange of information. 398 However, the M3UA protocol must be flexible enough allow its operation 399 and management in a variety of physical configurations that will enable 400 Network Operators to meet their performance and reliability 401 requirements. 403 To meet the stringent SS7 signaling reliability and performance 404 requirements for carrier grade networks, these Network Operators should 405 ensure that there is no single point of failure provisioned in the end- 406 to-end network architecture between an SS7 node and an IP ASP. 407 Depending of course on the reliability of the SG and ASP functional 408 elements, this can typically be met by the use of redundant SGs, the 409 provision of redundant QOS-bounded IP network paths for SCTP 410 Associations between SCTP End Points, and redundant Hosts. The 411 distribution of ASPs within the available Hosts is also important. For 412 a particular Application Server, the related ASPs should be distributed 413 over at least two Hosts. 415 An example physical network architecture relevant to carrier-grade 416 operation in the IP network domain is shown in Figure 1 below: 418 ******** ************** 419 * *_________________________________________* ******** * Host1 420 * * _________* * ASP1 * * 421 * SG1 * SCTP Associations | * ******** * 422 * *_______________________ | * ******** * 423 * * | | * * ASP2 * * 424 * * | | * ******** * 425 * * | | * ******** * 426 * * | | * * ASP3 * * 427 ******** | | * ******** * 428 | | * . * 429 ******** | | * . * 430 * *_______________________________| * * 431 * * | * ******** * 432 * SG2 * SCTP Associations | * * ASPn * * 433 * *____________ | * ******** * 434 * * | | ************** 435 * * | | ************** 436 * * | |_________________* ******** * Host2 437 * * |____________________________* * ASP1 * * 438 ******** * ******** * 439 * ******** * 440 * * ASP2 * * 441 * ******** * 442 * ******** * 443 * * ASP3 * * 444 * ******** * 445 * . * 446 * . * 447 * * 448 * ******** * 449 * * ASPn * * 450 * ******** * 451 ************** 452 . 453 . 454 . 456 Figure 1 � Physical Model 458 For carrier grade networks, Operators should ensure that under failure 459 or isolation of a particular ASP, stable calls or transactions are not 460 lost. This implies that ASPs need, in some cases, to share the 461 call/transaction state or be able to pass the call/transaction state 462 between each other. Also, in the case of ASPs performing call 463 processing, coordination may be required with the related Media Gateway 464 to transfer the MGC control for a particular trunk termination. 465 However, this sharing or communication is outside the scope of this 466 document. 468 1.3.3 SS7 Point Code Representation 470 Within an SS7 network, a Signaling Gateway is charged with representing 471 a set of nodes in the IP domain into the SS7 network for routing 472 purposes. The SG itself, as a physical node in the SS7 network, must 473 be addressable with an SS7 Point Code for MTP3 Management purposes. 474 The SG Point Code will also be used for addressing any local MTP3-Users 475 at the SG such as an SG-resident SCCP function. 477 Where an SG is logically partitioned to operate in multiple SS7 network 478 appearances, the SG must be addressable with a Point Code in each 479 network appearance and represents a set of nodes in the IP domain into 480 each SS7 network. Alias PCs may also be used within an SG network 481 appearance, but SG MTP3 management messages to/from the SS7 network 482 will not use the alias PCs. 484 The M3UA places no restrictions on the SS7 Point Code representation of 485 any of the ASPs. ASPs can be represented under the same PC of the SG, 486 their own individual Point Codes or grouped with other ASPs for Point 487 Code preservation purposes. A single Point Code may be used to 488 represent the SG and all the ASPs together, if desired. 490 If an ASP or group of ASPs is available to the SS7 network via more 491 than one SG, each with its own Point Code, the ASP(s) can be 492 represented by a Point Code that is separate from any SG Point Code. 493 This allows these SGs to be viewed from the SS7 network as "STPs", each 494 having an ongoing "route" to the same ASP(s). Under failure 495 conditions where an ASP becomes unavailable from one of the SGs, this 496 approach enables MTP3 route management messaging between the SG and SS7 497 network, allowing simple SS7 re-routing through an alternate SG without 498 changing the Destination Point Code Address of SS7 traffic to the ASPs. 500 +--------+ 501 | | 502 +------------+ SG 1 +--------------+ 503 +-------+ | | "STP" | | ---- 504 | SEP +---+ +--------+ +---/ \ 505 | or | | ASPs | 506 | STP +---+ +--------+ +---\ / 507 +-------+ | | | | ---- 508 +------------+ SG 2 +--------------+ 509 | "STP" | 510 +--------+ 512 Note: there is no SG to SG communication shown, so each SG can be 513 reached only via the direct Linkset from the SS7 network. 515 1.3.4 ASP Fail-over Model and Terminology 517 The network address translation and mapping function of the M3UA 518 supports ASP fail-over functions in order to support a high 519 availability of call and transaction processing capability. All MTP3- 520 User messages (e.g., ISUP, SCCP) incoming to an SG from the SS7 network 521 are assigned to a unique Application Server, based on the information 522 in the message. The information examined may be one or more of the MTP 523 DPC, OPC, SLS, or any MTP3-User specific fields such as, for example, 524 the ISUP CIC, SCCP SSN, or TCAP TRID. Some example possibilities are 525 the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or 526 the DPC/SSN combination. The information used to point to an AS is not 527 limited by the M3UA and none of the examples are mandated. 529 The Application Server is in practical terms a list of all ASPs 530 currently configured/registered to process MTP3-User messages within a 531 certain range of routing information, known as a Routing Key. One or 532 more ASPs in the list are normally active (i.e., handling traffic) 533 while any others may be unavailable or inactive, to be possibly used in 534 the event of failure or unavailability of the active ASP(s). 536 The fail-over model supports an "n+k" redundancy model, where "n" ASPs 537 is the minimum number of redundant ASPs required to handle traffic and 538 "k" ASPs are available to take over for a failed or unavailable ASP. 539 Note that "1+1" active/standby redundancy is a subset of this model. A 540 simplex "1+0" model is also supported as a subset, with no ASP 541 redundancy. 543 To avoid a single point of failure, it is recommended that a minimum of 544 two ASPs be in the list, resident in separate hosts and therefore 545 available over different SCTP Associations. For example, in the 546 network shown in Figure 1, all messages to DPC x could be sent to ASP1 547 in Host1 or ASP1 in Host2. The AS list at SG1 might look like this: 549 Routing Key {DPC=x) "Application Server #1" 550 ASP1/Host1 � State=Up, Active 551 ASP1/Host2 � State=Up, Inactive 553 In this "1+1" redundancy case, ASP1 in Host1 would be sent any incoming 554 message with DPC=x. ASP1 in Host2 would normally be brought to the 555 active state upon failure of, or loss of connectivity to, ASP1/Host1. 556 In this example, both ASPs are Up, meaning that the related SCTP 557 association and far-end M3UA peer is ready. 559 The AS List at SG1 might also be set up in loadshare mode: 561 Routing Key {DPC=x) - Application Server #1 562 ASP1/Host1 � State = Up, Active 563 ASP1/Host2 � State = Up, Active 565 In this case, both the ASPs would be sent a portion of the traffic. 566 For example the two ASPs could together form a database, where incoming 567 queries may be sent to any active ASP. 569 Care must be exercised by a Network Operator in the selection of the 570 routing information to be used as the Routing Key for a particular AS. 571 For example, where Application Servers are defined using ranges of ISUP 572 CIC values, the Operator is implicitly splitting up control of the 573 related circuit groups. Some CIC value range assignments may interfere 574 with ISUP circuit group management procedures. Similarly, within an 575 AS, if a loadbalancing algorithm were to use CIC values to balance the 576 load across the ASPs, the span of circuit contol assigned to particular 577 ASPs must also be weighed against the ISUP circuit group management 578 procedures. 580 In the process of fail-over or fail-back, it is recommended that in the 581 case of ASPs supporting call processing, stable calls do not fail. It 582 is possible that calls in "transition" may fail, although measures of 583 communication between the ASPs involved can be used to mitigate this. 584 For example, the two ASPs may share call state via shared memory, or 585 may use an ASP to ASP protocol to pass call state information. 587 1.3.5 Client/Server Model 589 The SG takes on the role of server while the ASP is the client. ASPs 590 must initiate the SCTP association to the SG. 592 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M3UA 593 is 2905. 595 1.4 Services Provided by the M3UA Layer 597 The M3UA Layer at the ASP provides the equivalent set of primitives at 598 its upper layer to the MTP3-Users as provided by the MTP Level 3 to its 599 local users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at 600 an ASP is unaware that the expected MTP3 services are offered remotely 601 from an MTP3 Layer at an SG and not by a local MTP3 layer. In effect, 602 the M3UA extends access to the MTP3 layer services to a remote ASP � 603 the M3UA does not itself provide the MTP3 services so does not 604 duplicate MTP3 procedures. 606 1.4.1 Support for the transport of MTP3-User Messages 608 The M3UA provides the transport of MTP-TRANSFER primitives across SCTP 609 associations between an SG and an ASP. The MTP-TRANSFER primitives are 610 encoded as MTP3-User messages with attached MTP3 Routing Labels as 611 described in the message format sections of the SCCP and ISUP 612 recommendations. In this way, the SCCP and ISUP messages received from 613 the SS7 network are not re-encoded into a different format for 614 transport to/from the ASP. As well, all the required MTP3 Routing Label 615 information (OPC, DPC, SIO) is available at the ASP as is expected by 616 the MTP3-User protocol layer. 618 Note that M3UA does not itself impose a 272-octet user information 619 block limit as specified by the MTP Level 3. Larger information blocks 620 can be accommodated directly by M3UA/SCTP without the need for an upper 621 layer segmentation/re-assembly procedure such as specified in recent 622 SCCP or ISUP versions. However, in the context of an SG, the maximum 623 272-octet block size must be followed when inter-working to a SS7 624 network that does not support the transfer of larger information blocks 625 to the final destination, as is possible in the Broadband MTP [20]. 626 This will avoid ISUP or SCCP fragmentation requirements at the SG. 627 However, if the SS7 network is provisioned to support the Broadband MTP 628 to the final SS7 destination, the information block size limit may be 629 increased past 272 octets. 631 1.4.2 Native Management Functions 633 The M3UA may provide management of the underlying SCTP transport 634 protocol to ensure that SG-ASP transport is available to the degree 635 called for by the MTP3-User signaling applications. 637 The M3UA provides the capability to indicate errors associated with 638 received M3UA messages and to notify, as appropriate, local management 639 and/or the remote peer M3UA. 641 1.4.3 Inter-working with MTP3 Network Management Functions 643 At the SG, the M3UA must also provide inter-working with MTP3 644 management functions to support seamless operation of the user SCN 645 signaling applications in the SS7 and IP domains. This includes: 647 - Providing an indication to MTP3-Users at an ASP that a remote 648 destination in the SS7 network is not reachable. 650 - Providing an indication to MTP3-Users at an ASP that a remote 651 destination in the SS7 network is now reachable. 653 - Providing an indication to MTP3-Users at an ASP that messages to a 654 remote MTP3-User peer in the SS7 network are experiencing SS7 655 congestion 657 - Providing an indication to MTP3-Users at an ASP that a remote MTP3- 658 User peer is unavailable. 660 The M3UA layer at an ASP may initiate an audit of the availability or 661 the congested state of remote SS7 destinations. This information is 662 requested from the M3UA at the SG. 664 1.4.4 Support for the management of SCTP associations between the SG 665 and ASPs. 667 The M3UA layer at the SG maintains the availability state of all 668 configured remote ASPs, in order to manage the SCTP Associations and 669 the traffic between the SG and ASPs. As well, the active/inactive 670 state of remote ASPs is also maintained - Active ASPs are those 671 currently receiving traffic from the SG. 673 The M3UA layer at either the SG or ASP can be instructed by local 674 management to establish an SCTP association to a peer M3UA node. This 675 can be achieved using the M-SCTP ESTABLISH primitive to request, 676 indicate and confirm the establishment of an SCTP association with a 677 peer M3UA node. 679 The M3UA layer may also need to inform local management of the status 680 of the underlying SCTP associations using the M-SCTP STATUS request and 681 indication primitive. For example, the M3UA may inform local management 682 of the reason for the release of an SCTP association, determined either 683 locally within the M3UA layer or by a primitive from the SCTP. 685 Also the M3UA layer may need to inform the local management of the 686 change in availability status of an ASP. This can be achieved using 687 the M-ASP STATUS primitive to change and indicate the status of an ASP. 689 1.5 Internal Functions in the M3UA 691 1.5.1 Address Translation and Mapping at the SG M3UA 693 In order to direct messages received from the SS7 MTP3 network to the 694 desired IP destination, the SG M3UA must perform address translation 695 and mapping functions using information from the received MTP3-User 696 message. 698 To support this mapping, the SG must maintain a network address 699 translation table, mapping incoming SS7 message information to an 700 Application Server serving a particular application and range of 701 traffic. This is accomplished by comparing a set of the information in 702 an incoming SS7 message to provisioned SG Routing Keys to determine an 703 Application Server that serves a particular range of traffic. 705 Possible SS7 address/routing information that may comprise a Routing 706 Key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or 707 SCCP Subsystem Number. The particular information used in an SG M3UA 708 Routing Key is application and network dependent. 710 An Application Server contains a list of one or more ASPs which are 711 capable of processing the traffic. This list is assumed to be dynamic, 712 taking into account the availability status of the individual ASPs in 713 the list, configuration changes, and possible fail-over mechanisms. 714 The M3UA protocol includes messages to convey the availability status 715 of the individual ASPs as input to a fail-over mechanism. 717 Normally, one or more ASPs is active in the ASP (i.e., currently 718 processing traffic) but in certain failure and transition cases it is 719 possible that there may not be an active ASP available. Both 720 loadsharing and backup scenarios are supported. 722 Where there is no Routing Key match for an incoming SS7 message, a 723 default treatment must be specified. Possible solutions are to provide 724 a "Default" Application Server at the SG that will direct all 725 unallocated traffic to a (set of) "Default" ASP(s), or to drop the 726 messages and provide a notification to management. 728 1.5.2 SG Redundancy 730 It is possible that the ASP could route signaling messages destined to 731 the SS7 network through more than one SG. A primary/back-up case is 732 possible where the unavailability of the SCTP assocation to a primary 733 SG, or the unavailability of the SS7 destination node from the primary 734 SG, could be used to reroute affected traffic to a next-preferred SG. 735 Also, a load-sharing case is possible where the signaling messages are 736 load-shared across two (or more) SGs. 738 >From the perspective of an ASP, it is assumed that a particular SG is 739 capable of handling traffic to an SS7 destination if an SCTP 740 association to the SG is available, the SG has received an indication 741 from the ASP that it is currently actively handling traffic, and the SG 742 has not indicated that the SS7 destination is unavailable. Where an 743 ASP is configured to use two or more SGs for directing traffic to the 744 SS7 network, the ASP must maintain knowledge of the current capability 745 of the SG to handle traffic to destinations of interest, for the 746 purpose of efficiently supporting the redirection/loadsharing of 747 traffic. The ASP may also use information received from the SGs of 748 congestion to concerned destinations. 750 1.5.3 SCTP Stream Mapping. 752 The M3UA at both the SG and ASP also supports the assignment of 753 signaling traffic into streams within an SCTP association. Traffic 754 that requires sequencing must be assigned to the same stream. To 755 accomplish this, MTP3-User traffic may be assigned to individual 756 streams based on the SLS value in the MTP3 Routing Label or the ISUP 757 CIC assignment, subject of course to the maximum number of streams 758 supported by the underlying SCTP association. 760 1.5.4 Congestion Control. 762 The M3UA Layer is informed of local and IP network congestion by means 763 of an implementation-dependent function (e.g., an implementation- 764 dependent indication from the SCTP of IP network congestion). When an 765 SG determines that the transport of SS7 messages to an Signalling Point 766 Management Cluster (SPMC) is encountering congestion, the SG may 767 optionally trigger SS7 MTP3 Transfer Controlled management messages to 768 originating SS7 nodes. The triggering of SS7 MTP3 Management messages 769 from an SG is an implementation-dependent function. At an ASP, 770 congestion is indicated to local MTP3-Users by means of an MTP-Status 771 primitive indicating congestion, to invoke appropriate upper layer 772 responses, as per current MTP3 procedures. 774 1.5.5 Seamless Network Management Inter-working. 776 The M3UA at an SG must maintain knowledge of SS7 node and Signalling 777 Point Management Cluster (SPMC) status in their respective domains in 778 order to perform as seamless as possible inter-working of the two 779 domains. For example, SG M3UA knowledge of the availability and/or 780 congestion status of SPMC and SS7 nodes must be maintained and 781 disseminated in the respective networks so that end-to-end operation is 782 transparent to the communicating SCN protocol peers at the SS7 node and 783 ASP. 785 When an SG M3UA determines that the transport of SS7 messages to an 786 SPMC is encountering congestion, the SG may optionally inform the MTP3 787 route management function (by an implementation-dependent mechanism). 788 This information is used by the MTP3 to mark the route to the affected 789 destination as congested and to trigger MTP Transfer Controlled (TFC) 790 messages to any SS7 SEPs generating traffic to the congested DPC, as 791 per current MTP3 procedures. 793 When an SG M3UA determines that the transport of SS7 messages to all 794 ASPs in a particular SPMC is interrupted, the SG M3UA may similarly 795 optionally inform the MTP3 route management function. This information 796 is used by the MTP3 to mark the route to the affected destination as 797 unavailable and to trigger MTP Transfer Prohibited (TFP) messages to 798 the adjacent SS7 nodes which are generating traffic to the unavailable 799 DPC as per current MTP procedures. If the SG is considered part of the 800 SPMC, MTP TFP messages must not be triggered into the SS7 network, as 801 SS7 procedures do not support the sending of TFPs by an SS7 node to 802 indicate its own unavailability. 804 When an SG M3UA determines that the transport of SS7 messages to an ASP 805 in a particular SPMC can be resumed, the SG M3UA may similarly 806 optionally inform the MTP3 route management function. This information 807 is used by the MTP3 to mark the route to the affected destination as 808 now available and to trigger MTP Transfer Allowed (TFA) messages to the 809 adjacent SS7 nodes as per current MTP3 procedures. 811 Note: In some SS7 network architectures, the sending of TFP and TFA 812 messages from the SG into the SS7 network should be suppressed. For 813 example, in the case where an SG seen by the adjacent SS7 nodes as an 814 SEP (i.e., in ANSI MTP terms the SG is connected via A-links or F- 815 links), TFP or TFA messages would not normally be expected by the 816 adjacent SS7 node. 818 1.5.6 Management Inhibit/Uninhibit 820 Local Management at an ASP or SG may wish to stop traffic across an 821 SCTP association in order to temporarily remove the association from 822 service or to perform testing and maintenance activity. The function 823 could optionally be used to control the start of traffic on to a newly- 824 available SCTP association. 826 1.5.7 Active Association Control 828 At an SG, an Application Server list may contain active and inactive 829 ASPs to support ASP loads-haring and fail-over procedures. When, for 830 example, both a primary and a back-up ASP are available, M3UA peer 831 protocol is required to control which ASP is currently active. The 832 ordered list of ASPs within a logical Application Server is kept 833 updated in the SG to reflect the active Application Server Process(es). 835 1.6 Definition of M3UA Boundaries 837 1.6.1 Definition of the boundary between M3UA and an MTP3-User. 839 >From ITU Q.701 [2]: 841 MTP-TRANSFER request 842 MTP-TRANSFER indication 843 MTP-PAUSE indication 844 MTP-RESUME indication 845 MTP-STATUS indication 847 1.6.2 Definition of the boundary between M3UA and SCTP 849 The upper layer primitives provided by the SCTP are provided in [13] 851 2.0 M3UA Protocol Elements 853 The general M3UA message format includes a Common Message Header 854 followed by zero or more parameters as defined by the Message Type. 855 For forward compatibility, all Message Types may have attached 856 parameters even if none are specified in this version. 858 2.1 Common Message Header 860 The protocol messages for MTP3-User Adaptation require a message 861 structure which contains a version, message type, message length, and 862 message contents. This message header is common among all signaling 863 protocol adaptation layers: 865 0 1 2 3 866 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Version | Spare | Message Type | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Message Length | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | | 874 All fields in an M3UA message MUST be transmitted in the network byte order, 875 unless otherwise stated. 877 2.1.1 M3UA Protocol Version 879 The version field (Vers.) contains the version of the M3UA adaptation 880 layer. The supported versions are: 882 0000 0001 Release 1.0 protocol 884 2.1.2 Message Types 886 The following list contains the message types for the defined messages. 888 Transfer Messages 890 Data 0101 892 SS7 Signaling Network Management (SSNM) Messages 894 Destination Unavailable (DUNA) 0201 895 Destination Available (DAVA) 0202 896 Destination State Audit (DAUD) 0203 897 SS7 Network Congestion State (SCON) 0204 898 Destination User Part Unavailable (DUPU) 0205 900 Application Server Process Maintenance (ASPM) messages 902 ASP Up 0301 903 ASP Down 0302 904 Heartbeat 0303 905 ASP Active 0401 906 ASP Inactive 0402 908 Management (MGMT) Messages 910 Error 0000 911 Notify 0001 913 2.1.3 Message Length 915 The Message Length defines the length of the message in octets, not 916 including the header. 918 2.2 Transfer Messages 920 The following section describes the Transfer messages and parameter 921 contents. The general message format includes a Common Message Header 922 together with a list of zero or more parameters as defined by the 923 Message Type. All Message Types can have attached parameters. 925 2.2.1 Data Message 927 The Data message contains the SS7 MTP3-User protocol data, which is an 928 MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 929 Data message contains the following parameters: 931 NETWORK APPEARANCE (Optional) 932 PROTOCOL DATA 934 The format for the Data Message parameters is as follows: 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Tag (0x1) | Length | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Network Appearance* | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Tag (0x3) | Length | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Protocol Data | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 The optional Network Appearance parameter identifies the SS7 network 951 context for the message, for the purposes of logically separating the 952 signaling traffic between the SG and the Application Server Process 953 over a common SCTP Association. An example is where an SG is logically 954 partitioned to appear as an element in four different national SS7 955 networks. 957 In a Data message, the Network Appearance defines the SS7 Point Codes 958 used, the SS7 Network Indicator value and MTP3/MTP3-User protocol 959 type/variant/version used within the SS7 network partition. Where an 960 SG operates in the context of a single SS7 network, or individual SCTP 961 associations are dedicated to each SS7 network context, or the Network 962 Indicator in the SIO of the MTP-Transfer primitive is sufficient, the 963 Network Appearance parameter is not required. 965 The format is an integer, the values of which are assigned according to 966 network operator policy. The values used are of local significance 967 only, coordinated between the SG and ASP. 969 Where the optional Network Appearance parameter is present, it must be 970 the first parameter in the message as it defines the format of the 971 Protocol Data field. 973 The Protocol Data field contains the MTP3-User application message, 974 which is in effect an MTP-TRANSFER primitive. As defined for a 975 specific value of the Protocol Identifier, this will include the MTP- 976 User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and 977 the SIO (Service Indicator, Network Indicator & optional Message 978 Priority codes). Note: in the case of ISUP messages, the Circuit 979 Identification Code is also included. 981 2.3 SS7 Signaling Network Management (SSNM) Messages 983 2.3.1 Destination Unavailable (DUNA) 985 The DUNA message is sent from the SG to all concerned ASPs to indicate 986 that the SG has determined that one or more SS7 destinations are 987 unreachable. The MTP3-User at the ASP is expected to stop traffic to 988 the affected destination through the SG initiating the DUNA as per the 989 defined MTP3-User procedures. 991 The DUNA message contains the following parameters: 993 Network Appearance (Optional) 994 Affected Destination 995 Info String (Optional) 997 The format for DUNA Message parameters is as follows: 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Tag (0x1) | Length | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Network Appearance* | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Tag (0x5) | Length | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Spare | Affected DPC 1 | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | ... | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Spare | Affected DPC n | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Tag (0x4) | Length | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | INFO String* | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 The optional Network Appearance parameter identifies the SS7 network 1024 context for the message, for the purposes of logically separating the 1025 signaling traffic between the SG and the Application Server Process 1026 over a common SCTP Association. An example is where an SG is logically 1027 partitioned to appear as an element in four different national SS7 1028 networks. 1030 In an SSNM message, the Network Appearance parameter defines the format 1031 of the Affected DPC(s) in the Affected Destination parameter. The DPC 1032 point code length (e.g., 14-, 16-, or 24-bit) and sub-field definitions 1033 (e.g., ANSI network/cluster/member, ITU-international 1034 zone/region/signal_point, many national field variants, ...) are fixed 1035 within a particular Network Appearance. Where an SG operates in the 1036 context of a single SS7 network, or individual SCTP associations are 1037 dedicated to each SS7 network context, the Network Appearance parameter 1038 is not required and the format of the Affected DPC(s) is understood 1039 implicitly. 1041 The format of the Network Appearance parameter is an integer, the 1042 values of which are assigned according to network operator policy. The 1043 values used are of local significance only, coordinated between the SG 1044 and ASP. 1046 Where the optional Network Appearance parameter is present, it must be 1047 the first parameter in the message as it defines the format of the 1048 Affected DPCs in the Affected Destination parameter. 1050 The Affected Destination parameter contains one or optionally more 1051 Affected Destination Point Codes, each a three-octet parameter to allow 1052 14-, 16- and 24-bit binary formatted SS7 Point Codes. Where the 1053 Affected Point Code is less than 24-bits, it is padded on the left to 1054 the 24-bit boundary. 1056 It is optional to send an Affected Destination parameter with more than 1057 one Affected DPC but it is mandatory to receive it. Also all the 1058 Affected DPCs included must be part of the same Network Appearance. 1059 Including multiple Affected DPCs may be useful when, for example, ANSI 1060 Cluster Route Sets are used at the SG, or a linkset event at the SG is 1061 simultaneously affecting the status of many destinations. 1063 The optional INFO String parameter can carry any meaningful 8-BIT ASCII 1064 character string along with the message. Length of the INFO String 1065 parameter is from 0 to 255 characters. No procedures are presently 1066 identified for its use but the INFO String may be used by Operators to 1067 identify in text form the location reflected by the Affected DPC for 1068 debugging purposes. 1070 2.3.2 Destination Available (DAVA) 1072 The DAVA message is sent from the SG to all concerned ASPs to indicate 1073 that the SG has determined that one or more SS7 destinations are now 1074 reachable. The ASP MTP3-User protocol is expected to resume traffic to 1075 the affected destination through the SG initiating the DUNA. 1077 The DAVA message contains the following parameters: 1079 Network Appearance (Optional) 1080 Affected Destination 1081 Info String (Optional) 1083 The format and description of DAVA Message parameters is the same as 1084 for the DUNA message (See Section 2.3.2.1.) 1086 2.3.3 Destination State Audit (DAUD) 1088 The DAUD message can be sent from the ASP to the SG to audit the 1089 availability/congestion state of SS7 routes to one or more affected 1090 destinations. See Section 3.4.3 for the audit procedures. 1092 The DAUD message contains the following parameters: 1094 Network Appearance (Optional) 1095 Affected Destination 1096 Info String (Optional) 1098 The format and description of DAUD Message parameters is the same as 1099 for the DUNA message (See Section 2.3.2.1.) 1101 Multiple Affected Destination Point Codes parameters may optionally be 1102 included in a DAUD message. However all the Affected Destination Point 1103 Codes must be part of the same Network Appearance. 1105 2.3.4 SS7 Network Congestion (SCON) 1107 The SCON message can be sent from the SG to all concerned ASPs to 1108 indicate that the congestion level in the SS7 network to one or more 1109 destinations has changed. 1111 The SCON message contains the following parameters: 1113 Network Appearance (Optional) 1114 Affected Destination 1115 Congestion Level 1116 Info String (Optional) 1118 The format for SCON Message parameters is as follows: 1120 0 1 2 3 1121 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 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Tag (0x1) | Length | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Network Appearance* | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Tag (0x5) | Length | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Cong. Level 1 | Affected DPC 1 | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | ... | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Cong. Level n | Affected DPC n | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Tag (0x4) | Length | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | INFO String* | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 The format and description of the Network Appearance, Affected 1145 Destination and Info String parameters is the same as for the DUNA 1146 message (See Section 2.3.2.1.) 1148 The valid values for the optional Congestion Level parameter are shown 1149 in the following table. 1151 Value Description 1152 00 No Congestion or Undefined 1153 01 Congestion Level 1 1154 02 Congestion Level 2 1155 03 Congestion Level 3 1157 The congestion levels are as defined in the national congestion method 1158 in the ITU MTP recommendation [14] or in the ANSI MTP standard [15]. 1159 For MTP congestion methods that do not employ congestion levels (e.g., 1160 the ITU international method, the parameter is always "Undefined". 1162 2.3.5 Destination User Part Unavailable (DUPU) 1164 The DUPU message is used by an SG to inform an ASP that a remote peer 1165 MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. 1167 The DUPU message contains the following parameters: 1169 Network Appearance (Optional) 1170 Affected Destination 1171 Unavailability Cause 1172 MTP3-User Identity 1173 Info String (Optional) 1175 The format for DUPU Message parameters is as follows: 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Tag (0x1) | Length | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Network Appearance* | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Tag (0x5) | Length | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Cause | User | Affected Destination | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Tag (0x4) | Length | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | INFO String* | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 The format and description of the Network Appearance, Affected 1196 Destination and Info String parameters is the same as for the DUNA 1197 message (See Section 2.3.2.1.) One exception is that the Affected 1198 Desination parameter in the DUPU message can only contain one Affected 1199 DPC. 1201 The Unavailability Cause parameter provides the reason for the 1202 unavailability of the MTP3-User. The valid values for the 1203 Unavailability Cause parameter are shown in the following table. The 1204 values agree with those provided in the SS7 MTP3 User Part Unavailable 1205 message. Depending on the MTP3 protocol used in the network context, 1206 additional values may be used � the specification of the relevant MTP3 1207 protocol variant/version is definitive. 1209 Value Description 1210 00 Unknown 1211 01 Unequipped Remote User 1212 02 Inaccessible Remote User 1214 The MTP3-User Identity describes the specific MTP3-User that is 1215 unavailable (e.g., ISUP, SCCP, ...). The valid values for the MTP3- 1216 User Identity are shown below. The values agree with those provided in 1217 the SS7 MTP3 User Part Unavailable message and Service Indicator. 1218 Depending on the MTP3 protocol used in the network context, additional 1219 values may be used � the specification of the relevant MTP3 protocol 1220 variant/version is definitive. 1222 Value Description 1223 00 - 02 Reserved 1224 03 SCCP 1225 04 TUP 1226 05 ISUP 1227 06 � 08 Reserved 1228 09 Broadband ISUP 1229 10 Satellite ISUP 1231 2.4 Application Server Process Maintenance (ASPM) Messages 1233 2.4.1 ASP Up (ASPUP) 1235 The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer 1236 that the Adaptation layer is ready to receive traffic or maintenance 1237 messages. 1239 The ASPUP message contains the following parameters: 1241 Adaptation Layer Identifer (optional) 1242 Protocol Identifier (optional) 1243 INFO String (optional) 1245 The format for ASPUP Message parameters is as follows: 1247 0 1 2 3 1248 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 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Tag (0x2) | Length | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Adaptation Layer Identifier* | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Tag (0x4) | Length | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | INFO String* | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 The format and description of the optional Info String parameters is 1264 the same as for the DUNA message (See Section 2.3.2.1.) 1266 The optional Adaptation Layer Identifier (ALI) is a string that 1267 identifies the adaptation layer. This string must be set to "M3UA" 1268 which results in a length of 4. The ALI would normally only be used in 1269 the initial ASP Up message across a new SCTP association to ensure both 1270 peers are assuming the same adaptation layer protocol. 1272 Note: Strings are padded to 32-bit boundaries. The length field 1273 indicates the end of the string. 1275 2.4.2 ASP Down (ASPDN) 1277 The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer 1278 that the adaptation layer is not ready to receive traffic or 1279 maintenance messages. 1281 The ASPDN message contains the following parameters: 1283 Reason 1284 INFO String (Optional) 1286 The format for the ASPDN message parameters is as follows: 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Reason | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Tag (0x4) | Length | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | INFO String* | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 The format and description of the optional Info String parameter is the 1301 same as for the DUNA message (See Section 2.3.2.1.) 1303 The Reason parameter indicates the reason that the remote M3UA 1304 adaptation layer is unavailable. The valid values for Reason are shown 1305 in the following table. 1307 Value Description 1308 0x1 Processor Outage 1309 0x2 Management Inhibit 1311 2.4.3 ASP Active (ASPAC) 1313 The ASPAC message is sent by an ASP to indicate to an SG that it is 1314 Active and ready to be used. 1316 The ASPAC message contains the following parameters: 1318 Type 1319 Routing Context (Optional) 1320 INFO String (Optional) 1322 The format for the ASPAC message is as follows: 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 | Type | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Tag (0x6) | Length | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Routing Context* | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Tag (0x4) | Length | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | INFO String* | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 The Type parameter identifies the traffic mode of operation of the ASP 1343 within an AS. The valid values for Type are shown in the following 1344 table. 1346 Value Description 1347 0x1 Over-ride 1348 0x2 Load-share 1349 0x3 New traffic 1351 Within a particular Routing Context, only one Type can be used. The 1352 Over-ride value indicates that the ASP is operating in Over-ride mode, 1353 where the ASP takes over all traffic in an Application Server (i.e., 1354 primary/back-up operation), over-riding any currently active ASPs in 1355 the AS. In loadshare mode, the ASP will share in the traffic 1356 distribution with any other currently active ASPs. In New Traffic mode 1357 the ASP wishes to take on traffic in the AS but does not expect to 1358 receive messages related to calls/transactions that are pending 1359 completion in another ASP. 1361 An SG that receives an ASPAC with an incorrect type for a particular 1362 Routing Context will respond with an Error Message. 1364 The optional Routing Context parameter contains (a list of) integers 1365 indexing the Application Server traffic that the sending ASP is 1366 configured/registered to receive. There is one-to-one relationship 1367 between an index entry and an SG Routing Key or AS Name. Because an AS 1368 can only appear in one Network Appearance, the Network Appearance 1369 parameter is not required in the ASPAC message 1371 An Application Server Process may be configured to process traffic for 1372 more than one logical Application Server. From the perspective of an 1373 ASP, a Routing Context defines a range of signaling traffic that the 1374 ASP is currently configured to receive from the SG. For example, an 1375 ASP could be configured to support call processing for multiple ranges 1376 of PSTN trunks and therefore receive related signaling traffic, 1377 identified by separate SS7 DPC/OPC/CIC_ranges. 1379 The format and description of the optional Info String parameter is the 1380 same as for the DUNA message (See Section 2.3.2.1.) 1382 2.4.4 ASP Inactive (ASPIA) 1384 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1385 longer an active ASP to be used from within a list of ASPs. The SG 1386 will respond with an ASPIA message and either discard incoming messages 1387 or buffer for a timed period and then discard. 1389 The ASPIA message contains the following parameters: 1391 Type 1392 Routing Context (Optional) 1393 INFO String (Optional) 1395 The format for the ASPIA message parameters is as follows: 1397 0 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Type | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Tag (0x6) | Length | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Routing Context* | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Tag (0x4) | Length | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | INFO String* | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 The Type parameter identifies the traffic mode of operation of the ASP 1416 within an AS. The valid values for Type are shown in the following 1417 table. 1419 Value Description 1420 0x1 Over-ride 1421 0x2 Load-share 1422 0x3 Graceful Withdrawal 1424 The format and description of the optional Routing Context and Info 1425 String parameters is the same as for the ASPAC message (See Section 1426 2.3.3.3.) 1428 2.4.5 Heartbeat (BEAT) 1430 The Heartbeat message is optionally used to ensure that the M3UA peers 1431 are still available to each other. It is recommended for use when the 1432 M3UA runs over a transport layer other than the SCTP, which has its own 1433 heartbeat. 1435 The BEAT message contains no parameters. 1437 2.5 Management Messages 1439 2.5.1 Error (ERR) 1441 The ERR message is sent when an invalid value is found in an incoming 1442 message. 1444 The ERR message contains the following parameters: 1446 Error Code 1447 Diagnostic Information (optional) 1449 The format for the ERR message is as follows: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Error Code | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Tag (0x7) | Length | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Diagnostic Information* | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 The Error Code parameter indicates the reason for the Error Message. 1464 The Error parameter value can be one of the following values: 1466 Invalid Version 0x1 1467 Invalid Network Appearance 0x2 1468 Invalid Adaptation Layer Identifier 0x3 1469 Invalid Message Type 0x4 1470 Invalid Traffic Handling Mode 0x5 1472 The optional Diagnostic information can be any information germain to 1473 the error condition, to assist in identification of the error 1474 condition. In the case of an Invalid Version Error Code the Diagnostic 1475 information includes the supported Version parameter. In the other 1476 cases, the Diagnostic information may be the first 40 bytes of the 1477 offending message. 1479 Error messages are not generated in response to other Error messages. 1481 2.5.2 Notify (NTFY) 1483 The Notify message used to provide an autonomous indication of M3UA 1484 events to an M3UA peer. 1486 The NTFY message contains the following parameters: 1488 Status Type 1489 Status Identification 1490 Routing Context (Optional) 1491 INFO String (Optional) 1493 The format for the NTFY message is as follows: 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Status Type | Status Identification | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Tag (0x6) | Length | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Routing Context* | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Tag (0x4) | Length | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | INFO String* | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 The Status Type parameter identifies the type of the Notify message. 1514 Following are the valid Status Type values: 1516 Value Description 1517 0x1 Application Server state change (AS_State_Change) 1518 0x2 Application Server Process state change (ASP_State_Change) 1519 0x3 Other 1521 The Status Information parameter contains more detailed information for 1522 the notification, based on the value of the Status Type. If the Status 1523 Type is AS_State_Change the following Status Information values are 1524 used: 1526 Value Description 1527 0x1 Application Server Down (AS_Down) 1528 0x2 Application Server Up (AS_Up) 1529 0x3 Application Server Active (AS_Active) 1530 0x4 Application Server Pending (AS_Pending) 1532 These notifications are sent from an SG to an ASP upon a change in 1533 status of a particular Application Server. The value reflects the new 1534 state of the Application Server. 1536 If the Status type is ASP_State_Change, the Status Information values 1537 are: 1539 Value Description 1540 0x1 Application Server Process (ASP) Down 1541 0x2 Application Server Process (ASP) Up 1542 0x3 Application Server Process (ASP) Active 1543 0x4 Application Server Process (ASP) Active_Old 1544 0x5 Application Server Process (ASP) Active_New 1546 These notifications are sent from an SG to an ASP upon a change in 1547 status of a particular Application Server process within the ASP list 1548 of a particular Application Server. The value reflects the new state 1549 of the Application Server Process. 1551 If the Status Type is Other, then the following Status Information 1552 values are defined: 1554 Value Description 1555 0x1 Insufficient ASP resources active in AS 1557 This notification is not based on the SG reporting the state change of 1558 an ASP or AS. For the value defined the SG is indicating to an ASP(s) 1559 in the AS that another ASP is required in order to handle the load of 1560 the AS. 1562 The format and description of the optional Routing Context and Info 1563 String parameters is the same as for the ASPAC message (See Section 1564 2.3.3.3.) 1565 3.0 Procedures 1567 The M3UA layer needs to respond to various local primitives it receives 1568 from other layers as well as the messages that it receives from the 1569 peer M3UA layers. This section describes the M3UA procedures in 1570 response to these events. 1572 3.1 Procedures to support the services of the M3UA layer 1574 The services of the M3UA layer are described in Section 1.4.1. These 1575 procedures support the M3UA transport of MTP3-User/MTP3 boundary 1576 primitives. 1578 3.1.1 Receipt of Local primitives 1580 On receiving an MTP-Transfer primitive from an upper layer, or the 1581 nodal inter-working function at an SG, the M3UA layer will send a 1582 corresponding Data message (see Section 2) to its M3UA peer. The M3UA 1583 layer must fill in various fields of the common and specific headers 1584 correctly. 1586 At an SG, the M3UA address translation and mapping function determines 1587 the Application Server (AS) based on the information in the incoming 1588 message. From an ordered list of ASPs within the AS table, an Active 1589 ASP is selected and a Data message is constructed and issued on the 1590 corresponding SCTP Association. If more than one ASP is active (i.e., 1591 traffic is to be load-shared across all the active ASPs), one of the 1592 active ASPs from the list is selected. The selection algorithm is 1593 implementation dependent but could be roud-robin or based on, for 1594 example, the SLS or ISUP CIC. The appropriate selection algorithm must 1595 be chosen carefully as it is dependent on application assumptions and 1596 understanding of the degree of state coordination between the active 1597 ASPs in the AS. 1599 In addition, the message needs to be sent on the appropriate SCTP 1600 stream, again taking care to meet the message sequencing needs of the 1601 signaling application. 1603 3.2 Procedures to support the M3UA services in Section 1.4.2 1605 3.2.1 Local Layer Management primitives procedures 1607 On receiving these primitives from the local layer management, the M3UA 1608 layer will send the corresponding management message (Error) to its 1609 peer. The M3UA layer must fill in the various fields of the common and 1610 specific headers correctly. 1612 3.2.2 Receipt of Peer Management messages 1614 Upon receipt of Management messages, the M3UA layer must invoke the 1615 corresponding Layer Management primitive indications (M-ERROR ind.) to 1616 the local layer management. 1618 3.3 Procedures to support the M3UA services in Section 1.4.4 1620 These procedures support the M3UA management of SCTP Associations 1621 between SGs and ASPs 1623 3.3.1 State Maintenance 1625 The M3UA layer on the SG maintains the state of each AS, in each 1626 Appliction Server that it is configured to receive traffic, as input to 1627 the SGs address translation and mapping function. 1629 3.3.1.1 ASP States 1631 The state of each ASP, in each AS that it is configured, is maintained 1632 in the M3UA layer in the SG. The state of a particular ASP in a 1633 particular AS changes due to events. The events include: 1635 * Reception of messages from the peer M3UA layer at the ASP 1636 * Reception of some messages from the peer M3UA layer at other ASPs 1637 in the AS 1638 * Reception of indications from the SCTP layer 1639 * Switch-over Time triggers 1641 The ASP state transition diagram is shown in Figure 4. The possible 1642 states of an ASP are: 1644 ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the 1645 SCTP association is down. Initially all ASPs will be in this state. 1647 ASP-UP: The remote M3UA peer at the ASP is available (and the SCTP 1648 association is up) but application traffic is stopped. 1650 ASP-ACTIVE: The remote M3UA peer at the ASP is available and 1651 application traffic is active (for a particular Routing Context or set 1652 of Routing Contexts). 1654 ASP-ACT-OLD: The remote M3UA peer at the ASP is available and 1655 application traffic is active (for a particular Routing Context or set 1656 of Routing Contexts), but for draining of current call/transactions 1657 only (i.e., no new calls/transactions) 1658 ASP-ACT-NEW: The remote M3UA peer at the ASP is available and 1659 application traffic is active (for a particular Routing Context or set 1660 of Routing Contexts), but for new calls/transactions only (i.e., not 1661 for traffic related to completing calls/transactions in another ASP). 1663 Figure 4: ASP State Transition Diagram 1665 +-------------+ 1666 |----------------------| | 1667 | Some other /| ASP-ACTIVE |<--------\ 1668 | ASP / +-------------+ | 1669 | Takeover / ^ | | Ts 1670 | / ASP | | ASP | 1671 | / Active | | Inactive | 1672 | v | v | 1673 | +-------------+ +-------------+ +-------------+ 1674 | | | | | | | 1675 | | ASP-ACT-OLD |----->| ASP-UP |------>| ASP-ACT-NEW | 1676 | +-------------+ Ts / +-------------+ ASP +-------------+ 1677 | | ASP Inactive ^ | Takeover | 1678 |<---| | | | 1679 | | | | 1680 ASP Down/ | ASP | | ASP Down / | ASP 1681 SCTP CDI | Up | | SCTP CDI | Down/ 1682 | | v | SCTP 1683 | +-------------+ | CDI 1684 | | | | 1685 |------------------>| |<-------------| 1686 | ASP-DOWN | 1687 +-------------+ 1689 SCTP CDI: The local SCTP layer's Communication Down Indication to the 1690 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 1691 indication when it detects the loss of connectivity to the ASP's peer 1692 SCTP layer. 1694 Ts: Switch-over Time Triggers. This timer is configurable by the 1695 Operator on a per AS basis. 1697 3.3.1.2 AS States 1699 The state of the AS is maintained in the M3UA layer on the SG. 1701 The state of an AS changes due to events. These events include: 1703 * ASP state transitions 1704 * Recovery timer triggers 1706 The possible states of an AS are: 1708 AS-DOWN: The Application Server is unavailable. This state implies 1709 that all related ASPs are in the ASP-DOWN state for this AS. Initially 1710 the AS will be in this state. 1712 AS-UP: The Application Server is available but no application traffic 1713 is active (i.e., one or more related ASPs are in the ASP-UP state, but 1714 none in the ASP-Active state). 1716 AS-ACTIVE: The Application Server is available and application traffic 1717 is active. This state implies that one ASP is in the ASP-ACTIVE state. 1719 AS-PENDING: An active ASP has transitioned from active to inactive or 1720 down and it was the last remaining active ASP in the AS. A recovery 1721 timer T(r) will be started and all incoming SCN messages will be queued 1722 by the SG. If an ASP becomes active before T(r) expires, the AS will 1723 move to AS-ACTIVE state and all the queued messages will be sent to the 1724 active ASP. 1726 If T(r) expires before an ASP becomes active, the SG stops queuing 1727 messages and discards all previously queued messages. The AS will move 1728 to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move 1729 to AS-DOWN state. 1731 Figure 5: AS State Transition Diagram 1733 +----------+ one ASP trans ACTIVE +-------------+ 1734 | |------------------------>| | 1735 | AS-UP | | AS-ACTIVE | 1736 | | | | 1737 | |< -| | 1738 +----------+ \ / +-------------+ 1739 ^ | \ Tr Trigger / ^ | 1740 | | \ at least one / | | 1741 | | \ ASP in UP / | | 1742 | | \ / | | 1743 | | \ / | | 1744 | | \ /---/ | | 1745 one ASP | | \ / one ASP | | Last ACTIVE ASP 1746 trans | | all ASP \-/----\ trans to | | trans to UP or 1747 to UP | | trans to / \ ACTIVE | | DOWN 1748 | | DOWN / \ | | 1749 | | / \ | | 1750 | | / \ | | 1751 | | /all ASP \ | | 1752 | v / trans to \ | v 1753 +----------+ / DOWN \ +-------------+ 1754 | |<--/ -| | 1755 | AS-DOWN | | AS-PENDING | 1756 | | | (queueing) | 1757 | |<------------------------| | 1758 +----------+ Tr Trigger no ASP +-------------+ 1759 in UP state 1761 Tr = Recovery Timer 1763 3.3.2 ASPM procedures for primitives 1765 Before the establishment of an SCTP association the ASP state at both 1766 the SG and ASP is assumed to be "Down". 1768 As the ASP is responsible for initiating the setup of an SCTP 1769 association to an SG, the M3UA layer at an ASP receives an M-SCTP 1770 ESTABLISH request primitive from the Layer Management, the M3UA layer 1771 will try to establish an SCTP association with the remote M3UA peer at 1772 an SG. Upon reception of an eventual SCTP-Communication Up confirm 1773 primitive from the SCTP, the M3UA layer will invoke the primitive M- 1774 SCTP ESTABLISH confirm to the Layer Management. 1776 At the SG, the M3UA layer will receive an SCTP Communication Up 1777 indication primitive from the SCTP. The M3UA layer will then invoke the 1778 primitive M-SCTP ESTABLISH indication to the Layer Management. 1780 Once the SCTP association is established, The M3UA layer at an ASP will 1781 then find out the state of its local M3UA-user from the Layer 1782 Management using the primitive M-ASP STATUS. Based on the status of 1783 the local M3UA-User, the local ASP M3UA Application Server Process 1784 Maintenance (ASPM) function will initiate the ASPM procedures, using 1785 the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to 1786 the SG - see Section 3.3.3. 1788 If the M3UA layer subsequently receives an SCTP-Communication Down 1789 indication from the underlying SCTP layer, it will inform the Layer 1790 Management by invoking the M-SCTP STATUS indication primitive. The 1791 state of the ASP will be moved to "Down" at both the SG and ASP. 1793 At an ASP, the Layer Management may try to reestablish the SCTP 1794 association using M-SCTP ESTABLISH request primitive. 1796 3.3.3 ASPM procedures for peer-to-peer messages 1798 All ASPM messages are sent on a sequenced stream to ensure ordering. 1799 SCTP stream '0' is used. 1801 3.3.3.1 ASP-Up 1803 After an ASP has successfully established an SCTP association to an SG, 1804 the SG waits for the ASP to send an ASP-Up message, indicating that the 1805 ASP M3UA peer is available. The ASP is always the initiator of the 1806 ASP-Up exchange. 1808 When an ASP-Up message is received at an SG and internally the ASP is 1809 not locked-out for local management reasons, the SG marks the remote 1810 ASP as 'Up'. The SG responds with an Notify (ASP-Up) message to the 1811 ASP in acknowledgement. The SG sends a Notify (ASP-Up) message in 1812 response to a received ASP-Up message from the ASP even if the ASP is 1813 already marked as "Up" at the SG. 1815 If for any local reason the SG cannot respond with an ASP-Up, the SG 1816 responds to a ASP-Up with a ASP-Down message. 1818 At the ASP, the Notify (ASP-Up) message received from the SG is not 1819 acknowledged by the ASP. If the ASP does not receive a response from 1820 the SG, or an ASP-Down is received, the ASP may resend ASP-Up messages 1821 every 2 seconds until it receives a Notify (ASP-Up) message from the 1822 SG. The ASP may decide to reduce the frequency (say to every 5 1823 seconds) if a Notify (ASP-Up) is not received after a few tries. 1825 The ASP must wait for the Notify (ASP-Up) message from the SG before 1826 sending any ASP traffic control messages (ASPAC or ASPIA) or Data 1827 messages or it will risk message loss. If the SG receives Data 1828 messages before an ASP Up is received, the SG should discard. 1830 3.3.3.2 ASP-Down 1832 The ASP will send an ASP-Down to an SG when the ASP is to be removed 1833 from the list of ASPs in all Application Servers that it is a member. 1835 The SG marks the ASP as "Down" and returns an Notify (ASP-Down) message 1836 to the ASP if one of the following events occur: 1838 - an ASP-Down message is received from the ASP, 1839 - another ASPM message is received from the ASP and the SG has 1840 locked out the ASP for management reasons. 1842 The SG sends a Notify (ASP-Down) message in response to a received ASP- 1843 Down message from the ASP even if the ASP is already marked as "Down" 1844 at the SG. 1846 If the ASP does not receive a response from the SG, the ASP may send 1847 ASP-Down messages every 2 seconds until it receives a ASP-Down message 1848 from the SG or the SCTP association goes down. The ASP may decide to 1849 reduce the frequency (say to every 5 seconds) if an ASP-Down is not 1850 received after a few tries. 1852 3.3.3.3 M3UA Version Control 1854 If a ASP-Up message with an unsupported version is received, the 1855 receiving end responds with an Error message, indicating the version 1856 the receiving node supports. 1858 This is useful when protocol version upgrades are being performed in a 1859 network. A node upgraded to a newer version should support the older 1860 versions used on other nodes it is communicating with. Because ASPs 1861 initiate the ASP-Up procedure it is assumed that the Error message 1862 would normally come from the SG. 1864 3.3.3.4 ASP-Active 1866 Anytime after the ASP has received a Notify (ASP-Up) acknowledgement 1867 from the SG, the ASP sends an ASP-Active (ASPAC) to the SG indicating 1868 that the ASP is ready to start processing traffic. In the case where 1869 an ASP is configured/registered to process the traffic for more than 1870 one Application Server across an SCTP association, the ASPAC contains 1871 one or more Routing Contexts to indicate for which Application Servers 1872 the ASPAC applies. 1874 When an ASP Active (ASPAC) message is received, the SG responds to the 1875 ASP with a Notify message acknowledging that the ASPAC was received and 1876 starts sending traffic for the associated Application Server(s) to that 1877 ASP. 1879 There are three modes of Application Server traffic handling in the SG 1880 M3UA - Over-ride, Load-balancing and New Traffic. The Type parameter 1881 in the ASPAC messge indicates the traffic handling mode used in a 1882 particular Application Server. If the SG determines that the mode 1883 indicated in an ASPAC is incompatible with the mode currently used in 1884 the AS, the SG responds with an Error message indicating "Invalid 1885 Traffic Handling Mode". 1887 In the case of an Over-ride mode AS, reception of an ASPAC message at 1888 an SG causes the redirection of all traffic for the AS to the ASP which 1889 sent the ASPAC. Any previously active ASP in the AS is now considered 1890 Inactive and will no longer receive traffic within the AS. The SG 1891 responds to the ASPAC with a Notify (ASP-Active) message to the ASP. 1892 The SG sends a Notify (ASP-Up) to the previously active ASP in the AS, 1893 after stopping all traffic to the ASP. 1895 In the case of a Loadshare mode AS, reception of an ASPAC message at an 1896 SG causes the direction of traffic to the ASP sending the ASPAC, in 1897 addition to all the other ASPs that are currently active in the AS. 1898 The algorithm at the SG for loadsharing traffic within an AS to all the 1899 active ASPs is application and network dependent. The algorithm could, 1900 for example be round-robin or based on information in the Data message 1901 (e.g, such as the SLS, SCCP SSN, ISUP CIC value), depending on the 1902 requirements of the application and the call/transaction state handling 1903 assumptions of the collection of ASPs in the AS. The SG responds to the 1904 ASPAC with a Notify (ASP-Active) message to the ASP. 1906 In the case of a New Traffic mode AS, reception of an ASPAC message at 1907 an SG causes the direction of traffic to the ASP sending the ASPAC. 1908 However, traffic related to completing calls/transactions in another 1909 ASP is not sent to the new ASP (i.e., new calls/transactions only). How 1910 an SG accomplishes the differentiation of old and new transactions and 1911 any loadsharing of traffic is application and implementation dependent. 1912 The SG responds to the ASPAC with a Notify (ASP-Active_New) message to 1913 the ASP. After a configurable time Ts, the ASP is moved to the ASP- 1914 Active state and a Notify (ASP-Active) is sent to the ASP. 1916 3.3.3.5 ASP Inactive 1918 When an ASP wishes to withdraw from receiving traffic the ASP sends an 1919 ASP Inactive (ASPIA) to the SG. In the case where an ASP is 1920 configured/registered to process the traffic for more than one 1921 Application Server across an SCTP association, the ASPIA contains one 1922 or more Routing Contexts to indicate for which Application Servers the 1923 ASPIA applies. 1925 There are three modes of Application Server traffic handling in the SG 1926 M3UA when withdrawing an ASP from service - Over-ride, Load-balancing 1927 and Graceful Withdrawal. The Type parameter in the ASPIA messge 1928 indicates the mode used in a particular Application Server. If the SG 1929 determines that the mode indicates in an ASPAC is incompatible with the 1930 traffic handling mode currently used in the AS, the SG responds with an 1931 Error message indicating "Invalid Traffic Handling Mode". 1933 In the case of an Over-ride mode AS, where normally another ASP has 1934 already taken over the traffic within the AS with an Over-ride ASPAC, 1935 the ASP which sent the ASPIA is already considered by the SG to be 1936 "Inactive". A Notify (ASP_Up) message is resent to the ASP, after 1937 ensuring that all traffic is stopped to the ASP. 1939 In the case of a Loadshare mode AS, the SG moves the ASP to the 1940 "Inactive" state and the AS traffic is re-allocated across the 1941 remaining "active" ASPs per the laoadsharing algorithm currently used 1942 within the AS. A Notify (ASP-Up) message is sent to the ASP after al 1943 traffic is halted to the ASP. 1945 In the case of Graceful Withdrawal, the SG diverts all traffic related 1946 to new calls/transactions to other "active" ASPs and therafter sends 1947 only traffic related to incomplete transactons to the ASP. A Notify 1948 (ASP-Act_Old) is sent to the ASP and the ASP is moved to the 1949 "Active_Old" state. When the outstanding calls/transactions are 1950 drained, or after a configurable time Ts, the SG moves the ASP to the 1951 "Up" state and sends a Notify (ASP-Up) message to the ASP. 1953 If no other ASPs are "Active" in the Application Server, the SG either 1954 discards all incoming messages (except messages related to an 1955 "Active_Old" ASP) for the AS or starts buffering the incoming messages 1956 for T(r)seconds after which messages will be discarded. T(r) is 1957 configurable by the network operator. If the SG receives an ASPAC from 1958 an ASP in the AS before expiry of T(r), the buffered traffic is 1959 directed to the ASP and the timer is cancelled. 1961 3.3.3.6 Notify 1963 In the case where a Notify (AS-Up) message is sent by an SG that now 1964 has no ASPs active to service the traffic, the Notify does not force 1965 the ASP(s) receiving the message to become active. The ASPs remain in 1966 control of what (and when) action is taken. 1968 3.3.3.7 Heartbeat 1970 The optional Heartbeat procedures may be used when operating over 1971 transport layers that do not have their own heartbeat mechanism for 1972 detecting loss of the transport association (i.e., other than the 1973 SCTP). 1975 Once the ASP sends an ASP-Up message to the SG, the ASP sends Beat 1976 messages periodically, subject to a provisionable timer T(beat). The 1977 SG M3UA, upon receiving a BEAT message from the ASP, responds with a 1978 BEAT message. If no BEAT message (or any other M3UA message), is 1979 received from the ASP within the timer 2*T(beat), the ASP will consider 1980 the remote M3UA as 'Down". 1982 At the ASP, if no BEAT message (or any other M3UA message) is received 1983 from the SG within 2*T(beat), the SG is considered unavailable. 1984 Transmission of BEAT messages is stopped and ASP-Up procedures are used 1985 to re-establish communication with the SG M3UA peer. 1987 Note: Heartbeat related events are not shown in Figure 4 "ASP state 1988 transition diagram". 1990 3.4 Procedures to support the M3UA services in Section 1.4.3 1992 3.4.1 At an SG 1994 On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication 1995 primitive from the nodal inter-working function at an SG, the SG M3UA 1996 layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message 1997 (see Section 2) to the M3UA peers at concerned ASPs. The M3UA layer 1998 must fill in various fields of the SSNM messages consistently with the 1999 information received in the primitives. 2001 The SG M3UA determines the set of concerned ASPs to be informed based 2002 on the SS7 network partition for which the primitive indication is 2003 relevant. In this way, all ASPs configured to send/receive traffic 2004 within a particular network appearance are informed. If the SG 2005 operates within a single SS7 network appearance, then all ASPs are 2006 informed. 2008 Optionally, the SG M3UA may filter further based on the Affected Point 2009 Code in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives. 2010 In this way ASPs can be informed only of affected destinations to which 2011 they actually communicate. The SG M3UA may also suppress DUPU messages 2012 to ASPs that do not implement an MTP3-User protocol peer for the 2013 affected MTP3-User. 2015 DUNA, DAVA, SCON messages must be sent on a sequenced stream as these 2016 primitives should arrive in order. Stream 0 is used. Sequencing is 2017 not required for the DUPU or DAUD message, which may optionally be sent 2018 un-sequenced. 2020 3.4.2 At an ASP 2022 At an ASP, upon receiving an SSNM message from the remote M3UA Peer, 2023 the M3UA layer invokes the appropriate primitive indications to the 2024 resident M3UA-Users. Local management is informed. 2026 3.4.3 ASP Auditing 2028 An ASP may optionally initiate an audit procedure in order to enquire 2029 of an SG the availability or congestion status of an SS7 destination or 2030 set of destinations. A Destination Audit (DAUD) message is sent from 2031 the ASP to the SG requesting the current availability or congestion 2032 status of one or more SS7 Destination Point Codes. 2034 The DAUD may be sent by the ASP in the following cases. The DAUD may 2035 be sent unsequenced. 2037 - Periodic. A Timer originally set upon reception of DUVA or SCON 2038 message has expired without a subsequent DAVA, DUVA or SCON 2039 updating the availability/congestion status of the affected 2040 Destination Point Codes. The Timer is reset upon issuing a DAUD. 2041 In this case the DAUD is sent to the SG that originally sent the 2042 SSNM message. 2044 - the ASP is newly "Up" or "Active" or has been isolated from an SG 2045 for an extended period. The SG can request the 2046 availabilty/congestion status of one or more SS7 destinations to 2047 which it expects to communicate. 2049 In the first case, the DAUD procedure must not be invoked for the case 2050 of a received SCON containing a congestion level value of "no 2051 congestion" or "undefined" (i.e., congestion Level = "0"). This is 2052 because the value indicates either congestion abatement or that the ITU 2053 MTP3 international congestion method is being used. In the 2054 international congestion method, the MTP3 at the SG does not maintain 2055 the congestion status of any destinations and therefore cannot provide 2056 any congestion information in response to the DAUD. For the same 2057 reason, in the second case a DAUD cannot reveal any congested 2058 destination(s). 2060 The SG must respond to a DAUD with the MTP3 status of the routeset 2061 associated with each Destination Point Code(s) in the DAUD. The status 2062 of each SS7 destination requested is indicated in a DUNA (if 2063 unavailable), DAVA (if available/uncongested) or an SCON (if 2064 available/congested). Optionally, any DUNA or DAVA in response to a 2065 DAUD may contain more than one Affected Point Code. 2067 Note that from the point of view of an ASP sending an DAUD, the 2068 subsequent reception of an SCON implies that the Affected Destination 2069 is available. The reception of a DAVA implies that the routeset to the 2070 Affected Destination are not congested. Obviously with the reception 2071 of an DUNA, the routeset to the Affected Destination can not also be 2072 congested. 2074 4.0 Examples of M3UA Procedures 2076 4.1 Establishment of Association and Traffic between SGs and ASPs 2078 4.1.1 Single ASP in an Application Server ("1+0" sparing) 2080 This scenario shows the example M3UA message flows for the 2081 establishment of traffic between an SG and an ASP, where only one ASP 2082 is configured within an AS (no backup). It is assumed that the SCTP 2083 association is already set-up. 2085 SG ASP1 2086 | 2087 |<---------ASP Up----------| 2088 |------NTFY (ASP-Up)------>| 2089 | - | 2090 |<-------ASP Active--------| 2091 |----NTFY (ASP_Active)---->| 2092 | | 2094 4.1.2 Two ASPs in Application Server ("1+1" sparing) 2096 This scenario shows the example M3UA message flows for the 2097 establishment of traffic between an SG and two ASPs in the same 2098 Application Server, where ASP1 is configured to be "active" and ASP2 a 2099 "standby" in the event of communication failure or the withdrawal from 2100 service of ASP1. ASP2 may act as a hot, warm, or cold standby 2101 depending on the extent to which ASP1 and ASP2 share call/transaction 2102 state or can communicate call state under failure/withdrawal events. 2103 The example message flow is the same whether the ASP-Active messages 2104 are Over-ride or Load-share mode although typically this example would 2105 use an Over-ride mode. 2107 SG ASP1 ASP2 2108 | | | 2109 |<--------ASP Up----------| | 2110 |-------TFY (ASP-Up)----->| | 2111 | | | 2112 |<-----------------------------ASP Up----------------| 2113 |----------------------------NTFY (ASP-Up)---------->| 2114 | | | 2115 | | | 2116 |<-------ASP Active-------| | 2117 |----NTFY(ASP-Active)---->| | 2118 | | | 2120 4.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing 2121 case) 2123 This scenario shows a similar case to Section 4.1.2 but where the two 2124 ASPs are brought to "active" and loadshare the traffic load. In this 2125 case, one ASP is sufficient to handle the total traffic load. 2127 SG ASP1 ASP2 2128 | | | 2129 |<---------ASP Up---------| | 2130 |-------NTFY(ASP-Up)----->| | 2131 | | | 2132 |<------------------------------ASP Up---------------| 2133 |-----------------------------NTFY(ASP Up)---------->| 2134 | | | 2135 | | | 2136 |<--ASP Active (Ldshr)----| | 2137 |----NTFY(ASP-Active)---->| | 2138 | | | 2139 |<----------------------------ASP Active (Ldshr)-----| 2140 |-----------------------------NTFY(ASP-Active)------>| 2141 | | | 2143 4.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 2144 case) 2146 This scenario shows the example M3UA message flows for the 2147 establishment of traffic between an SG and three ASPs in the same 2148 Application Server, where two of the ASPs are brought to "active" and 2149 share the load. In this case, a minimum of two ASPs are required to 2150 handle the total traffic load (2+1 sparing). 2152 SG ASP1 ASP2 ASP3 2153 | | | | 2154 |<------ASP Up-------| | | 2155 |----NTFY(ASP-Up)--->| | | 2156 | | | | 2157 |<--------------------------ASP Up-------| | 2158 |------------------------NTFY(ASP-Up)--->| | 2159 | | | | 2160 |<---------------------------------------------ASP Up--------| 2161 |--------------------------------------------NTFY(ASP-Up)--->| 2162 | | | | 2163 | | | | 2164 |<-ASP Act. (Ldshr)--| | | 2165 |---NTFY(ASP-Act.)-->| | | 2166 | | | | 2167 |<--------------------ASP Act. (Ldshr)---| | 2168 |----------------------NTFY(ASP-Act.)--->| | 2169 | | | | 2171 4.2 ASP Traffic Fail-over Examples 2173 4.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2175 Following on from the example in Section 4.1.2, and ASP withdraws from 2176 service: 2178 SG ASP1 ASP2 2179 | | | 2180 |<-----ASP Inactive-------| | 2181 |---NTFY(ASP Inactive)--->| | 2182 |--------------------NTFY(ASP-Inactive) (Optional)-->| 2183 | | | 2184 |<------------------------------ ASP Active----------| 2185 |-----------------------------NTFY(ASP-Active)------>| 2186 | | 2188 Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or 2189 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 2190 exchange would not occur. 2192 4.2.2 (1+1 Sparing, Back-up Over-ride) 2194 Following on from the example in Section 4.1.2, and ASP2 wishes to 2195 over-ride ASP1 and take over the traffic: 2197 SG ASP1 ASP2 2198 | | | 2199 |<------------------------------ ASP Active----------| 2200 |-----------------------------NTFY(ASP-Active)------>| 2201 |----NTFY(ASP-Inactive)-->| 2202 | | | 2204 4.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) 2206 Following on from the example in Section 4.1.4, and ASP1 withdraws from 2207 service: 2209 SG ASP1 ASP2 ASP3 2210 | | | | 2211 |<----ASP Inact.-----| | | 2212 |--NTFY(ASP-Inact.)->| | | 2213 | | | | 2214 |---------------------------------NTFY(Ins. ASPs)(Optional)->| 2215 | | | | 2216 |<-----------------------------------------ASP Act. (Ldshr)--| 2217 |-------------------------------------------ASP Act. (Ack)-->| 2218 | | | | 2220 The Notify message to ASP3 is optional, as well as the ASP-Active from 2221 ASP3. The optional Notify can only occur if the SG maintains knowledge 2222 of the minimum ASP resources required � for example if the SG knows 2223 that "n+k" = "2+1" for a loadshare AS and "n" currently equals "1". 2225 Note: If the SG detects loss of the ASP1 M3UA peer (M3UA heartbeat loss 2226 or detection of SCTP failure), the first SG-ASP1 ASP Inactive message 2227 exchange would not occur. 2229 4.3 M3UA/MTP3-User Boundary Examples 2231 4.3.1 At an ASP 2233 This section describes the primitive mapping from the MTP3 User to M3UA 2234 at an ASP. 2236 4.3.1.1 Support for MTP-Transfer on the ASP 2238 4.3.1.1.1 Support for MTP-Transfer Request 2239 When the MTP3-User on the ASP has data to send into the SS7 network, it 2240 will use the MTP-Transfer Request primitive. The M3UA on the ASP will 2241 do the following when it receives an MTP-Transfer Request primitive 2242 from the M3UA user: 2244 - Determine the correct SG 2246 - Determine the correct association to the chosen SG 2248 - Determine the correct stream in the association (e.g., based on 2249 SLS) 2251 - Determine whether to complete the optional fields of the Data 2252 message 2254 - Map the MTP-Transfer Request primitive into the Protocol Data 2255 field of an m3ua Data message 2257 - Send the Data message to the remote M3UA peer in the SG, over the 2258 SCTP association 2260 SG ASP 2261 | | 2262 |<-----Data Message-------|<--MTP-Transfer req. 2263 | | 2265 4.3.1.1.2 Support for MTP Transfer Indication 2267 When the M3UA on the ASP has received Data messages from the remote 2268 M3UA peer in the SG it will do the following: 2270 - Evaluate the optional fields of the Data message if present 2272 - Map the Payload of a Data message into the MTP-Transfer Indication 2273 primitive 2275 - Pass the MTP-Transfer Indication primitive to the user part. In 2276 case of multiple user parts, the optional fields of the Data 2277 message are used to determine the concerned user part. 2279 SG ASP 2280 | | 2281 |------Data Message------>|---MTP-Transfer ind.? 2282 | | 2284 4.3.1.1.3 Support for ASP Querying of SS7 Destination States 2286 There are situations such as temporary loss of connectivity to the SG 2287 that may cause the M3UA on the ASP to audit SS7 destination 2288 availability states. Note: there is no primitive for the MTP3-User to 2289 request this audit from the M3UA as this is initiated by an internal 2290 M3UA management function. 2292 The M3UA on the ASP normally sends Destination State Audit (DAUD) 2293 messages for each of the destinations that the ASP supports. 2295 SG ASP 2296 | | 2297 |<-----DAUD Message ------| 2298 |<-----DAUD Message ------| 2299 |<-----DAUD Message ------| 2300 | | 2301 | | 2303 4.3.2 At an SG 2305 This section describes the MTP3 upper layer primitive mapping to the 2306 M3UA at the SG. 2308 4.3.2.1 Support for MTP-Transfer Request at the SG 2310 When the M3UA on the SG has received Data messages from its peer 2311 destined to the SS7 network it will do the following: 2313 - Evaluate the optional fields of the Data message if present to 2314 determine the network appearance 2316 - Map the Protocol data of the Data message into an MTP-Transfer 2317 Request primitive 2319 - Pass the MTP-Transfer Request primitive to the MTP3 of the 2320 concerned network appearance. 2322 SG ASP 2323 | | 2324 <---MTP-Transfer req.|<------Data Message------| 2325 | | 2327 4.3.2.2 Support for MTP-Transfer Indication at the SG 2329 When the MTP3 on the SG has data to pass its user parts, it will use 2330 the MTP-Transfer Indication primitive. The M3UA on the S>G will do the 2331 following when it receives an MTP-Transfer Indication: 2333 - Determine the correct ASP 2335 - Determine the correct association to the chosen ASP 2337 - Determine the correct stream in the association (e.g., based on 2338 SLS) 2340 - Determine whether to complete the optional fields of the Data 2341 message 2343 - Map the MTP-Transfer Indication primitive into the Protocol Data 2344 field of an M3UA Data message 2346 - Send the Data message to the remote M3UA peer in the ASP, over the 2347 SCTP association 2349 SG ASP 2350 | | 2351 --MTP-Transfer ind.->|------Data Message------>| 2352 | | 2354 4.3.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS 2356 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the 2357 MTP3 upper layer interface at the SG need to be made available to the 2358 remote MTP3 User Part lower layer interface at the concerned ASP(s). 2360 4.3.2.3.1 Destination Unavailable 2362 The MTP3 on the SG will generate an MTP-PAUSE primitive when it 2363 determines locally that an SS7 destination is unreachable. The M3UA 2364 will map this primitive to a Destination Unavailable (DUNA) message. 2365 It will determine which ASP(s) to send the DUNA based on the Network 2366 Appearance information. 2368 SG ASP 2369 | | 2370 --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.--> 2371 | | 2373 4.3.2.3.2 Destination Available 2375 The MTP3 on the SG will generate an MTP-RESUME primitive when it 2376 determines locally that an SS7 destination that was previously 2377 unreachable is now reachable. The M3UA will map this primitive to a 2378 Destination Unavailable (DAVA) message. It will determine which ASP(s) 2379 to send the DUNA based on the Network Appearance information. 2381 SG ASP 2382 | | 2383 --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.--> 2384 | | 2386 4.3.2.3.3 SS7 Network Congestion 2388 The MTP3 on the SG will generate an MTP-STATUS primitive when it 2389 determines locally that the route to an SS7 destination is congested. 2390 The M3UA will map this primitive to a SS7 Network Congestion State 2391 (SCON) message. It will determine which ASP(s) to send the DUPU to 2392 based on the intended Application Server. 2394 SG ASP 2395 | | 2396 --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.--> 2397 | | 2399 4.3.2.3.4 Destination User Part Unavailable 2401 The MTP3 on the SG will generate an MTP-STATUS primitive when it 2402 determines locally that an SS7 destination User Part is unavailable. 2403 The M3UA will map this primitive to a Destination User Part Unavailable 2404 (DUPU) message. It will determine which ASP(s) to send the DUPU to 2405 based on the intended Application Server. 2407 SG ASP 2408 | | 2409 --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.--> 2410 | | 2412 5.0 Security 2414 5.1 Introduction 2416 M3UA is designed to carry signaling messages for telephony services. As such, 2417 M3UA must involve the security needs of several parties: the end users 2418 of the services; the network providers and the applications involved. 2419 Additional requirements may come from local regulation. While having some 2420 overlapping security needs, any security solution should fulfill all of the 2421 different parties' needs. 2423 5.2 Threats 2425 There is no quick fix, one-size-fits-all solution for security. As a 2426 transport protocol, M3UA has the following security objectives: 2428 * Availability of reliable and timely user data transport. 2429 * Integrity of user data transport. 2430 * Confidentiality of user data. 2432 M3UA runs on top of SCTP. SCTP [6] provides certain transport related 2433 security features, such as: 2435 * Blind Denial of Service Attacks 2436 * Flooding 2437 * Masquerade 2438 * Improper Monopolization of Services 2440 When M3UA is running in professionally managed corporate or service provider 2441 network, it is reasonable to expect that this network includes an 2442 appropriate security policy framework. The "Site Security Handbook" [21] 2443 should be consulted for guidance. 2445 When the network in which M3UA runs in involves more than one party, it may 2446 not be reasonable to expect that all parties have implemented security in a 2447 sufficient manner. In such a case, it is recommended that IPSEC is used to 2448 ensure confidentiality of user payload. Consult [22] for more information on 2449 configuring IPSEC services. 2451 5.3 Protecting Confidentiality 2453 Particularly for mobile users, the requirement for confidentiality may 2454 include the masking of IP addresses and ports. In this case application 2455 level encryption is not sufficient; IPSEC ESP should be used instead. 2456 Regardless of which level performs the encryption, the IPSEC ISAKMP service 2457 should be used for key management. 2459 6.0 IANA Considerations 2461 A request will be made to IANA to assign an M3UA value for the Payload Protocol 2462 Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol 2463 Identifier will be registered: 2465 M3UA tbd 2467 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to 2468 indicate which protocol the SCTP is carrying. This Payload Protocol Identifier 2469 is not directly used by SCTP but may be used by certain network entities to 2470 identify the type of information being carried in a Data chunk. 2472 The User Adaptation peer may use the Payload Protocol Identifier as a way of 2473 determining additional information about the data being presented to it by SCTP. 2475 7.0 Acknowledgements 2477 The authors would like to thank John Loughney, Neil Olson, Norm Glaude, 2478 Michael Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Heinz Prantner 2479 for their valuable comments and suggestions. 2481 8.0 References 2483 [1] RFC 2719, "Framework Architecture for Signaling Transport" 2485 [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) 2486 � ISDN User Part (ISUP)' 2488 [3] ANSI T1.113 - 'Signaling System Number 7 � ISDN User Part 2490 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 2491 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 2492 international interface; Part 1: Basic services" 2494 [5] ITU-T Recommendations Q.711-715, 'Signalling System No. 7 (SS7) - 2495 Signalling Connection Control Part (SCCP)' 2497 [6] ANSI T1.112 'Signaling System Number 7 � Signaling Connection 2498 Control Part' 2500 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 2501 Signalling System No.7; Signalling Connection Control Part (SCCP) 2502 (connectionless and connection-oriented class 2) to support 2503 international interconnection; Part 1: Protocol specification" 2505 [8] ITU-T Recommendations Q.720, 'Telephone User Part' 2507 [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - 2508 Transaction Capabilities (TCAP) 2510 [10] ANSI T1.114 'Signaling System Number 7 � Transaction Capabilities 2511 Application Part' 2513 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 2514 Signalling System No.7; Transaction Capabilities (TC) version 2; 2515 Part 1: Protocol specification" 2517 [12] 3G TS 25.410 V3.1.0 (2000-01) Technical Specification � 3rd 2518 Generation partnership Project; Technical Specification Group 2519 Radio Access Network; UTRAN Iu Interface: General Aspects and 2520 Principles (3G TS 25.410 Version 3.1.0 Release 1999) 2522 [13] Simple Control Transport Protocol , Dec. 1999, Work in Progress 2525 [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7) 2526 - Message Transfer Part (MTP)' 2528 [15] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 2530 [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 2531 Signalling System No.7; Message Transfer Part (MTP) to support 2532 international interconnection; Part 1: Protocol specification" 2534 [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service 2535 Specific Coordination Function for signaling at the Network Node 2536 Interface (SSCF at NNI) 2538 [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service 2539 Specific Connection Oriented Protocol (SSCOP) 2541 [19] MTP2-User Adaptation Layer , Nov. 2542 1999, Work in Progress 2544 [20] ITU-T Recommendation Q.2210 'B-ISDN MTP' 2546 [21] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997 2548 [22] RFC 2401, "Security Architecture for the Internet Protocol", S. 2549 Kent, R. Atkinson, November 1998. 2551 9.0 Author's Addresses 2553 Lyndon Ong 2554 Nortel Networks 2555 4401 Great America Pkwy 2556 Santa Clara, CA, USA 95054 2557 long@nortelnetworks.com 2559 Greg Sidebottom 2560 Nortel Networks 2561 3685 Richmond Rd, 2562 Nepean, Ontario, Canada K2H 5B7 2563 gregside@nortelnetworks.com 2565 Guy Mousseau 2566 Nortel Networks 2567 3685 Richmond Rd 2568 Nepean, Ontario, Canada K2H 5B7 2570 Ian Rytina 2571 Ericsson Australia 2572 37/360 Elizabeth Street 2573 Melbourne, Victoria 3000, Australia 2574 ian.rytina@ericsson.com 2576 Hanns Juergen Schwarzbauer 2577 SIEMENS AG 2578 Hofmannstr. 51 2579 81359 Munich, Germany 2580 HannsJuergen.Schwarzbauer@icn.siemens.de 2582 Ken Morneault 2583 Cisco Systems Inc. 2584 13615 Dulles Technology Drive 2585 Herndon, VA, USA 20171 2586 EMail: kmorneau@cisco.com 2587 Malleswar Kalla 2588 Telcordia Technologies 2589 MCC 1J211R 2590 445 South Street 2591 Morristown, NJ, USA 07960 2592 EMail: kalla@research.telcordia.com 2594 This draft expires September 2000.