idnits 2.17.1 draft-ietf-sigtran-rfc3332bis-06.txt: -(4019): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5474. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 5490), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 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 11 longer pages, the longest (page 20) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 110 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2772 has weird spacing: '...nt Code n ...' == Line 3287 has weird spacing: '... The transi...' == Line 3288 has weird spacing: '...message at th...' == Line 3666 has weird spacing: '...ge from the A...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a DATA chunk. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 2006) is 6607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Optional' on line 3959 -- Looks like a reference, but probably isn't: 'ASPAC-Ack' on line 3260 -- Looks like a reference, but probably isn't: 'ASPIA-Ack' on line 3260 -- Looks like a reference, but probably isn't: 'ASPUP-Ack' on line 3270 == Unused Reference: '22' is defined on line 5159, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 5163, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 5166, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 5172, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 5186, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: 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' -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '18') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '25') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. '26') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '27') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Morneault 3 INTERNET-DRAFT Cisco Systems 4 Obsoletes: 3332 J. Pastor-Balbas 5 Ericsson 7 Feb 2006 9 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - 10 User Adaptation Layer (M3UA) 11 13 STATUS OF THIS MEMO 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 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 This Internet-Draft will expire August 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). All Rights Reserved. 42 Abstract 44 This memo defines a protocol for supporting the transport of any SS7 45 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the 46 services of the Stream Control Transmission Protocol. Also, 47 provision is made for protocol elements that enable a seamless 48 operation of the MTP3-User peers in the SS7 and IP domains. This 49 protocol would be used between a Signalling Gateway (SG) and a Media 50 Gateway Controller (MGC) or IP-resident Database, or between two 51 IP-based applications. It is assumed that the SG receives SS7 52 signalling over a standard SS7 interface using the SS7 Message 53 Transfer Part (MTP) to provide transport. This document obsoletes 54 RFC 3332. 56 TABLE OF CONTENTS 58 1. Introduction.....................................................5 59 1.1 Scope............................................................5 60 1.2 Terminology......................................................5 61 1.3 M3UA Overview....................................................7 62 1.4 Functional Areas................................................11 63 1.5 Sample Configuration............................................18 64 1.6 Definition of M3UA Boundaries...................................20 65 2. Conventions......................................................24 66 3. M3UA Protocol Elements...........................................24 67 3.1 Common Message Header...........................................25 68 3.2 Variable Length Parameter Format................................27 69 3.3 Transfer Messages...............................................29 70 3.4 SS7 Signalling Network Management (SSNM) Messages...............32 71 3.5 ASP State Maintenance (ASPSM) Messages..........................41 72 3.6 Routing Key Management (RKM) Messages [Optional]................44 73 3.7 ASP Traffic Maintenance (ASPTM) Messages........................52 74 3.8 Management (MGMT) Messages.....................................57 75 4. Procedures.......................................................62 76 4.1 Procedures to Support the M3UA-User.............................62 77 4.2 Receipt of Primitives from the Layer Management.................63 78 4.3 AS and ASP/IPSP State Maintenance...............................65 79 4.4 Routing Key Management Procedures [Optional]....................81 80 4.5 Procedures to Support the Availability or Congestion Status of 81 SS7 Destination.................................................84 82 4.6 MTP3 Restart....................................................86 83 4.7 NIF not Available...............................................87 84 4.8 M3UA Version Control............................................88 85 4.9 M3UA Termination................................................88 86 5. Examples of M3UA Procedures......................................88 87 5.1 Establishment of Association and Traffic between SGPs and ASPs..88 88 5.2 ASP Traffic Failover Examples...................................94 89 5.3 Normal Withdrawal of an ASP from an Application Server..........95 90 5.4 Auditing examples...............................................96 91 5.5 M3UA/MTP3-User Boundary Examples................................96 92 5.6 Examples for IPSP communication................................100 93 6. Security Considerations.........................................101 94 7. IANA Considerations.............................................101 95 7.1 SCTP Payload Protocol Identifier...............................102 96 7.2 M3UA Port Number...............................................102 97 7.3 M3UA Protocol Extensions.......................................103 98 8. References......................................................103 99 8.1 Normative References...........................................103 100 8.2 Informative References.........................................104 101 9. Acknowledgements................................................105 102 10. Document Contributors..........................................106 103 11. Change Log.....................................................106 104 Appendix A.........................................................107 105 A.1 Signalling Network Architecture................................108 106 A.2 Redundancy Models..............................................110 107 Editors' Addresses.................................................113 109 1. Introduction 111 This memo defines a protocol for supporting the transport of any SS7 112 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the 113 services of the Stream Control Transmission Protocol [17]. Also, 114 provision is made for protocol elements that enable a seamless 115 operation of the MTP3-User peers in the SS7 and IP domains. This 116 protocol would be used between a Signalling Gateway (SG) and a Media 117 Gateway Controller (MGC) or IP-resident Database [11], or between two 118 IP-based applications. 120 1.1 Scope 122 There is a need for Switched Circuit Network (SCN) signalling 123 protocol delivery from an SS7 Signalling Gateway (SG) to a Media 124 Gateway Controller (MGC) or IP-resident Database as described in the 125 Framework Architecture for Signalling Transport [11]. The delivery 126 mechanism should meet the following criteria: 128 * Support for the transfer of all SS7 MTP3-User Part messages (e.g., 129 ISUP [1,2,3], SCCP [4,5,6], TUP [12], etc.) 130 * Support for the seamless operation of MTP3-User protocol peers 131 * Support for the management of SCTP transport associations and 132 traffic between an SG and one or more MGCs or IP-resident 133 Databases 134 * Support for MGC or IP-resident Database process failover and load 135 sharing 136 * Support for the asynchronous reporting of status changes to 137 management 139 In simplistic transport terms, the SG will terminate SS7 MTP2 and 140 MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP and/or any other 141 MTP3-User protocol messages, as well as certain MTP network 142 management events, over SCTP transport associations to MTP3-User 143 peers in MGCs or IP-resident Databases. 145 1.2 Terminology 147 Application Server (AS) - A logical entity serving a specific Routing 148 Key. An example of an Application Server is a virtual switch element 149 handling all call processing for a signalling relation, identified by 150 a SS7 DPC/OPC. Another example is a virtual database element, 151 handling all HLR transactions for a particular SS7 SIO/DPC/OPC 152 combination. The AS contains a set of one or more unique Application 153 Server Processes, of which one or more is normally actively processing 154 traffic. Note that there is a 1:1 relationship between an AS and a 155 Routing Key. 157 Application Server Process (ASP) - A process instance of an 158 Application Server. An Application Server Process serves as an active 159 or backup process of an Application Server (e.g., part of a 160 distributed virtual switch or database). Examples of ASPs are 161 processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP 162 contains an SCTP endpoint and may be configured to process signalling 163 traffic within more than one Application Server. 165 Association - An association refers to an SCTP association. The 166 association provides the transport for the delivery of MTP3-User 167 protocol data units and M3UA adaptation layer peer messages. 169 IP Server Process (IPSP) - A process instance of an IP-based 170 application. An IPSP is essentially the same as an ASP, except that 171 it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does 172 not use the services of a Signalling Gateway node. 174 Failover - The capability to reroute signalling traffic as required 175 to an alternate Application Server Process, or group of ASPs, within 176 an Application Server in the event of failure or unavailability of a 177 currently used Application Server Process. Failover also applies 178 upon the return to service of a previously unavailable Application 179 Server Process. 181 Host - The computing platform that the process (SGP, ASP or IPSP) is 182 running on. 184 Layer Management - Layer Management is a nodal function that handles 185 the inputs and outputs between the M3UA layer and a local management 186 entity. 188 Linkset - A number of signalling links that directly interconnect two 189 signalling points, which are used as a module. 191 MTP - The Message Transfer Part of the SS7 protocol. 193 MTP3 - MTP Level 3, the signalling network layer of SS7 195 MTP3-User - Any protocol normally using the services of the SS7 MTP3 196 (e.g., ISUP, SCCP, TUP, etc.). 198 Network Appearance - The Network Appearance is a M3UA local reference 199 shared by SG and AS (typically an integer) that together with an 200 Signaling Point Code uniquely identifies an SS7 node by indicating 201 the specific SS7 network it belongs to. It can be used to distinguish 202 between signalling traffic associated with different networks being 203 sent between the SG and the ASP over a common SCTP association. An 204 example scenario is where an SG appears as an element in multiple 205 separate national SS7 networks and the same Signaling Point Code 206 value may be reused in different networks. 208 Network Byte Order - Most significant byte first, a.k.a Big Endian. 210 Routing Key - A Routing Key describes a set of SS7 parameters and 211 parameter values that uniquely define the range of signalling traffic 212 to be handled by a particular Application Server. Parameters within 213 the Routing Key cannot extend across more than a single Signalling 214 Point Management Cluster. 216 Routing Context - A value that uniquely identifies a Routing Key. 217 Routing Context values are either configured using a configuration 218 management interface, or by using the routing key management 219 procedures defined in this document. 221 Signaling End Point (SEP) - A node in the SS7 network associated with 222 an originating or terminating local exchange (switch) or a gateway 223 exchange. 225 Signalling Gateway Process (SGP) - A process instance of a Signalling 226 Gateway. It serves as an active, backup, load-sharing or broadcast 227 process of a Signalling Gateway. 229 Signalling Gateway (SG) - An SG is a signaling agent that receives/ 230 sends SCN native signaling at the edge of the IP network [11]. An SG 231 appears to the SS7 network as an SS7 Signalling Point. An SG 232 contains a set of one or more unique Signalling Gateway Processes, of 233 which one or more is normally actively processing traffic. Where an 234 SG contains more than one SGP, the SG is a logical entity and the 235 contained SGPs are assumed to be coordinated into a single management 236 view to the SS7 network and to the supported Application Servers. 238 Signalling Process - A process instance that uses M3UA to communicate 239 with other signalling processes. An ASP, an SGP and an IPSP are all 240 signalling processes. 242 Signalling Point Management Cluster (SPMC) - The complete set of 243 Application Servers represented to the SS7 network under a single MTP 244 entity (Signalling Point) in one specific Network Appearance. SPMCs 245 are used to aggregate the availability, congestion, and user part 246 status of an MTP entity (Signalling Point) that is distributed in the 247 IP domain, for the purpose of supporting MTP3 management procedures 248 towards the SS7 network. In some cases, the SG itself may also be a 249 member of the SPMC. In this case, the SG availability /congestion 250 /User_Part status should also be taken into account when considering 251 any supporting MTP3 management actions. 253 Signaling Transfer Point (STP) - A node in the SS7 network that 254 provides network access and performs message routing, screening and 255 transfer of of signaling messages. 257 Stream - A stream refers to an SCTP stream; a unidirectional logical 258 channel established from one SCTP endpoint to another associated SCTP 259 endpoint, within which all user messages are delivered in-sequence 260 except for those submitted to the unordered delivery service. 262 1.3 M3UA Overview 264 1.3.1 Protocol Architecture 266 The framework architecture that has been defined for SCN signalling 267 transport over IP [11] uses multiple components, including a common 268 signalling transport protocol and an adaptation module to support the 269 services expected by a particular SCN signalling protocol from its 270 underlying protocol layer. 272 Within the framework architecture, this document defines an MTP3-User 273 adaptation module suitable for supporting the transfer of messages of 274 any protocol layer that is identified to the MTP Level 3 as an MTP 275 User. The list of these protocol layers includes, but is not limited 276 to, ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part 277 (SCCP) [4,5,6] and Telephone User Part (TUP) [12]. TCAP [13,14,15] 278 or RANAP [16] messages are transferred transparently by the M3UA 279 protocol as SCCP payload, as they are SCCP-User protocols. 281 It is recommended that M3UA use the services of the Stream Control 282 Transmission Protocol (SCTP) [17] as the underlying reliable common 283 signalling transport protocol. This is to take advantage of various 284 SCTP features such as: 286 - Explicit packet-oriented delivery (not stream-oriented), 287 - Sequenced delivery of user messages within multiple streams, 288 with an option for order-of-arrival delivery of individual 289 user messages, 290 - Optional multiplexing of user messages into SCTP datagrams, 291 - Network-level fault tolerance through support of multi-homing 292 at either or both ends of an association, 293 - Resistance to flooding and masquerade attacks, and 294 - Data segmentation to conform to discovered path MTU size. 296 Under certain scenarios, such as back-to-back connections without 297 redundancy requirements, the SCTP functions above might not be a 298 requirement and TCP MAY be used as the underlying common transport 299 protocol. 301 1.3.2 Services Provided by the M3UA Layer 303 The M3UA Layer at an ASP or IPSP provides the equivalent set of 304 primitives at its upper layer to the MTP3-Users as provided by the 305 MTP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the 306 ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected 307 MTP3 services are offered remotely from an MTP3 Layer at an SGP, and 308 not by a local MTP3 layer. The MTP3 layer at an SGP may also be 309 unaware that its local users are actually remote user parts over 310 M3UA. In effect, the M3UA extends access to the MTP3 layer services 311 to a remote IP-based application. The M3UA layer does not itself 312 provide the MTP3 services. However, in the case where an ASP is 313 connected to more than one SG, the M3UA layer at an ASP should 314 maintain the status of configured SS7 destinations and route messages 315 according to the availability and congestion status of the routes to 316 these destinations via each SG. 318 The M3UA layer may also be used for point-to-point signalling between 319 two IP Server Processes (IPSPs). In this case, the M3UA layer 320 provides the same set of primitives and services at its upper layer 321 as the MTP3. However, in this case the expected MTP3 services are not 322 offered remotely from an SGP. The MTP3 services are provided but the 323 procedures to support these services are a subset of the MTP3 324 procedures due to the simplified point-to-point nature of the IPSP to 325 IPSP relationship. 327 1.3.2.1 Support for the Transport of MTP3-User Messages 329 The M3UA layer provides the transport of MTP-TRANSFER primitives 330 across an established SCTP association between an SGP and an ASP or 331 between IPSPs. 333 At an ASP, in the case where a destination is reachable via multiple 334 SGPs, the M3UA layer must also choose via which SGP the message is to 335 be routed or support load balancing across the SGPs, minimizing 336 missequencing. 338 The M3UA layer does not impose a 272-octet signalling information 339 field (SIF) length limit as specified by the SS7 MTP Level 2 protocol 340 [7,8,9]. Larger information blocks can be accommodated directly by 341 M3UA/SCTP, without the need for an upper layer segmentation/re- 342 assembly procedure as specified in recent SCCP or ISUP versions. 343 However, in the context of an SG, the maximum 272-octet block size 344 must be followed when interworking to a SS7 network that does not 345 support the transfer of larger information blocks to the final 346 destination. This avoids potential ISUP or SCCP fragmentation 347 requirements at the SGPs. The provisioning and configuration of the 348 SS7 network determines the restriction placed on the maximum block 349 size. Some configurations (e.g., Broadband MTP [21]) may permit 350 larger block sizes. 352 1.3.2.2 Native Management Functions 354 The M3UA layer provides the capability to indicate errors associated 355 with received M3UA messages and to notify, as appropriate, local 356 management and/or the peer M3UA. 358 1.3.2.3 Interworking with MTP3 Network Management Functions 360 At the SGP, the M3UA layer provides interworking with MTP3 management 361 functions to support seamless operation of the user SCN signalling 362 applications in the SS7 and IP domains. This includes: 364 - Providing an indication to MTP3-Users at an ASP that a destination 365 in the SS7 network is not reachable. 367 - Providing an indication to MTP3-Users at an ASP that a destination 368 in the SS7 network is now reachable. 370 - Providing an indication to MTP3-Users at an ASP that messages to a 371 destination in the SS7 network are experiencing SS7 congestion. 373 - Providing an indication to the M3UA layer at an ASP that the routes 374 to a destination in the SS7 network are restricted. 376 - Providing an indication to MTP3-Users at an ASP that a MTP3-User 377 peer is unavailable. 379 The M3UA layer at an ASP keeps the state of the routes to remote SS7 380 destinations and may initiate an audit of the availability, the 381 restricted or the congested state of remote SS7 destinations. This 382 information is requested from the M3UA layer at the SGP. 384 The M3UA layer at an ASP may also indicate to the SG that the M3UA 385 layer itself or the ASP or the ASP's Host is congested. 387 1.3.2.4 Support for the Management of SCTP Associations between the SGP 388 and ASPs. 390 The M3UA layer at the SGP maintains the availability state of all 391 configured remote ASPs, to manage the SCTP Associations and the 392 traffic between the M3UA peers. As well, the active/inactive and 393 congestion state of remote ASPs is maintained. 395 The M3UA layer MAY be instructed by local management to establish an 396 SCTP association to a peer M3UA node. This can be achieved using the 397 M-SCTP_ESTABLISH primitives (See Section 1.6.3 for a description of 398 management primitives.) to request, indicate and confirm the 399 establishment of an SCTP association with a peer M3UA node. In order 400 to avoid redundant SCTP associations between two M3UA peers, one side 401 (client) SHOULD be designated to establish the SCTP association, or 402 M3UA configuration information maintained to detect redundant 403 associations (e.g., via knowledge of the expected local and remote 404 SCTP endpoint addresses). 406 Local management MAY request from the M3UA layer the status of the 407 underlying SCTP associations using the M-SCTP_STATUS request and 408 confirm primitives. Also, the M3UA MAY autonomously inform local 409 management of the reason for the release of an SCTP association, 410 determined either locally within the M3UA layer or by a primitive 411 from the SCTP. 413 Also the M3UA layer MAY inform the local management of the change in 414 status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS 415 request or M-AS_STATUS request primitives. 417 1.3.2.5 Support for the Management of Connections to Multiple SGPs 419 As shown in Figure 1 an ASP may be connected to multiple SGPs. In 420 such a case a particular SS7 destination may be reachable via more 421 than one SGP and/or SG, i.e., via more than one route. As MTP3 users 422 only maintain status on a destination and not on a route basis, the 423 M3UA layer must maintain the status (availability, restriction, 424 and/or congestion of route to destination) of the individual routes, 425 derive the overall availability or congestion status of the 426 destination from the status of the individual routes, and inform the 427 MTP3 users of this derived status whenever it changes. 429 1.4 Functional Areas 431 1.4.1 Signalling Point Code Representation 433 For example, within an SS7 network, a Signalling Gateway might be 434 charged with representing a set of nodes in the IP domain into the 435 SS7 network for routing purposes. The SG itself, as a signalling 436 point in the SS7 network, might also be addressable with an SS7 Point 437 Code for MTP3 Management purposes. The SG Point Code might also be 438 used for addressing any local MTP3-Users at the SG such as a local 439 SCCP layer. 441 An SG may be logically partitioned to operate in multiple SS7 network 442 appearances. In such a case, the SG could be addressable with a 443 Point Code in each network appearance, and represents a set of nodes 444 in the IP domain into each SS7 network. Alias Point Codes [8] may 445 also be used within an SG network appearance. 447 Where an SG contains more than one SGP, the MTP3 routeset, SPMC and 448 remote AS/ASP states of each SGP SHOULD be coordinated across all the 449 SGPs. Rerouting of traffic between the SGPs MAY also be supported. 451 Application Servers can be represented under the same Point Code of 452 the SG, their own individual Point Codes or grouped with other 453 Application Servers for Point Code preservation purposes. A single 454 Point Code may be used to represent the SG and all the Application 455 Servers together, if desired. 457 If an ASP or group of ASPs is available to the SS7 network via more 458 than one SG, each with its own Point Code, the ASP(s) will typically 459 be represented by a Point Code that is separate from any SG Point 460 Code. This allows, for example, these SGs to be viewed from the SS7 461 network as "STPs", each having an ongoing "route" to the same ASP(s). 462 Under failure conditions where the ASP(s) become(s) unavailable from 463 one of the SGs, this approach enables MTP3 route management messaging 464 between the SG and SS7 network, allowing simple SS7 rerouting through 465 an alternate SG without changing the Destination Point Code Address 466 of SS7 traffic to the ASP(s). 468 Where a particular AS can be reached via more than one SGP, the 469 corresponding Routing Keys in the SGPs should be identical. (Note: 470 It is possible for the SGP Routing Key configuration data to be 471 temporarily out-of-sync during configuration updates). 473 +--------+ 474 | | 475 +------------+ SG 1 +--------------+ 476 +-------+ | SS7 links | "STP" | IP network | ---- 477 | SEP +---+ +--------+ +---/ \ 478 | or | |* | ASPs | 479 | STP +---+ +--------+ +---\ / 480 +-------+ | | | | ---- 481 +------------+ SG 2 +--------------+ 482 | "STP" | 483 +--------+ 485 Figure 1 Example with mated SGs 487 * Note:. SG-to-SG communication (i.e., "C-links") is recommended for 488 carrier grade networks, using an MTP3 linkset or an equivalent, to 489 allow rerouting between the SGs in the event of route failures. Where 490 SGPs are used, inter-SGP communication might be used. Inter-SGP 491 protocol is outside of the scope of this document. 493 The following example shows a signalling gateway partitioned into two 494 network appearances. 496 SG 497 +-------+ +---------------+ 498 | SEP +--------------| SS7 Ntwk.|M3UA| ---- 499 +-------+ SS7 links | "A" | | / \ 500 |__________| +-----------+ ASPs | 501 | | | \ / 502 +-------+ | SS7 Ntwk.| | ---- 503 | SEP +--------------+ "B" | | 504 +-------+ +---------------+ 506 Figure 2 Example with multiple Network 508 1.4.2 Routing Contexts and Routing Keys 510 1.4.2.1 Overview 512 The distribution of SS7 messages between the SGP and the Application 513 Servers is determined by the Routing Keys and their associated 514 Routing Contexts. A Routing Key is essentially a set of SS7 515 parameters used to filter SS7 messages, whereas the Routing Context 516 parameter is a 4-octet value (integer) that is associated to that 517 Routing Key in a 1:1 relationship. The Routing Context therefore can 518 be viewed as an index into a sending node's Message Distribution 519 Table containing the Routing Key entries. 521 Possible SS7 address/routing information that comprise a Routing Key 522 entry includes, for example, the OPC, DPC, SIO found in the MTP3 523 routing label. Some example Routing Keys are: the DPC alone, the 524 DPC/OPC combination, or the DPC/OPC/SI combination. The particular 525 information used to define an M3UA Routing Key is application and 526 network dependent, and none of the above examples are mandated. 528 An Application Server Process may be configured to process signalling 529 traffic related to more than one Application Server, over a single 530 SCTP Association. In ASP Active and ASP Inactive management 531 messages, the signalling traffic to be started or stopped is 532 discriminated by the Routing Context parameter. At an ASP, the 533 Routing Context parameter uniquely identifies the range of signalling 534 traffic associated with each Application Server that the ASP is 535 configured to receive. 537 1.4.2.2 Routing Key Limitations 539 Routing Keys SHOULD be unique in the sense that each received SS7 540 signalling message SHOULD have a full or partial match to a single 541 routing result. An example of a partial match would be a default 542 Routing Key which would be the result if there are no other Routing 543 Keys to which the message belongs. It is not necessary for the 544 parameter range values within a particular Routing Key to be 545 contiguous. 547 1.4.2.3 Managing Routing Contexts and Routing Keys 549 There are two ways to provision a Routing Key at an SGP. A Routing 550 Key may be configured statically using an implementation dependent 551 management interface, or dynamically using the M3UA Routing Key 552 registration procedure. 554 When using a management interface to configure Routing Keys, the 555 message distribution function within the SGP is not limited to the 556 set of parameters defined in this document. Other implementation 557 dependent distribution algorithms may be used. 559 1.4.2.4 Message Distribution at the SGP 561 To direct messages received from the SS7 MTP3 network to the 562 appropriate IP destination, the SGP must perform a message 563 distribution function using information from the received MTP3-User 564 message. 566 To support this message distribution, the SGP might, for example, 567 maintain the equivalent of a network address translation table, 568 mapping incoming SS7 message information to an Application Server for 569 a particular application and range of traffic. This could be 570 accomplished by comparing elements of the incoming SS7 message to 571 currently defined Routing Keys in the SGP. 573 These Routing Keys could in turn map directly to an Application 574 Server that is enabled by one or more ASPs. These ASPs provide 575 dynamic status information regarding their availability, traffic 576 handling capability and congestion to the SGP using various 577 management messages defined in the M3UA protocol. 579 The list of ASPs in an AS is assumed to be dynamic, taking into 580 account the availability, traffic handling capability and congestion 581 status of the individual ASPs in the list, as well as configuration 582 changes and possible failover mechanisms. 584 Normally, one or more ASPs are active (i.e., currently processing 585 traffic) in the AS but in certain failure and transition cases it is 586 possible that there may be no active ASP available. Broadcast, 587 loadsharing and backup scenarios are supported. 589 When there is no matching Routing Key entry for an incoming SS7 590 message, a default treatment MAY be specified. Possible solutions 591 are to provide a default Application Server at the SGP that directs 592 all unallocated traffic to a (set of) default ASP(s), or to drop the 593 message and provide a notification to layer management. The 594 treatment of unallocated traffic is implementation dependent. 596 1.4.2.5 Message Distribution at the ASP 598 The ASP must choose an SGP to direct a message to the SS7 network. 599 This is accomplished by observing the Destination Point Code (and 600 possibly other elements of the outgoing message such as the SLS 601 value). The ASP must also take into account whether the related 602 Routing Context is active or not (See Section 4.3.4.3). 604 Implementation Note: Where more than one route (or SGP) is possible 605 for routing to the SS7 network, the ASP could, for example, maintain 606 a dynamic table of available SGP routes for the SS7 destinations, 607 taking into account the SS7 destination 608 availability/restricted/congestion status received from the SGP(s), 609 the availability status of the individual SGPs and configuration 610 changes and failover mechanisms. There is, however, no M3UA messaging 611 to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive 612 messaging). 614 Whenever an SCTP association to an SGP exists, the SGP is assumed to 615 be ready for the purposes of responding to M3UA ASPSM messages (Refer 616 to Section 3). 618 1.4.3 SS7 and M3UA Interworking 620 In the case of SS7 and M3UA interworking, the M3UA adaptation layer 621 is designed to provide an extension of the MTP3 defined user 622 primitives. 624 1.4.3.1 Signalling Gateway SS7 Layers 625 The SG is responsible for terminating MTP Level 3 of the SS7 626 protocol, and offering an IP-based extension to its users. 628 From an SS7 perspective, it is expected that the Signalling Gateway 629 transmits and receives SS7 Message Signalling Units (MSUs) over a 630 standard SS7 network interface, using the SS7 Message Transfer Part 631 (MTP) [7,8,9]. 633 As a standard SS7 network interface, the use of MTP Level 2 634 signalling links is not the only possibility. ATM-based High Speed 635 Links can also be used with the services of the Signalling ATM 636 Adaptation Layer (SAAL) [18,19]. 638 Note: It is also possible for IP-based interfaces to be present, 639 using the services of the MTP2-User Adaptation Layer (M2UA) [27] or 640 M2PA [28]. 642 These could be terminated at a Signalling Transfer Point (STP) or 643 Signalling End Point (SEP). Using the services of MTP3, the SG could 644 be capable of communicating with remote SS7 SEPs in a quasi- 645 associated fashion, where STPs may be present in the SS7 path between 646 the SEP and the SG. 648 1.4.3.2 SS7 and M3UA Interworking at the SG 650 The SGP provides a functional interworking of transport functions 651 between the SS7 network and the IP network by also supporting the 652 M3UA adaptation layer. It allows the transfer of MTP3-User 653 signalling messages to and from an IP-based Application Server 654 Process where the peer MTP3-User protocol layer exists. 656 For SS7 user part management, it is required that the MTP3-User 657 protocols at ASPs receive indications of SS7 signalling point 658 availability, SS7 network congestion, and remote User Part 659 unavailability as would be expected in an SS7 SEP node. To 660 accomplish this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 661 primitives received at the MTP3 upper layer interface at the SG need 662 to be propagated to the remote MTP3-User lower layer interface at the 663 ASP. 665 MTP3 management messages (such as TFPs or TFAs received from the SS7 666 network) MUST NOT be encapsulated as Data message Payload Data and 667 sent either from SG to ASP or from ASP to SG. The SG MUST terminate 668 these messages and generate M3UA messages as appropriate. 670 1.4.3.3 Application Server 672 A cluster of application servers is responsible for providing the 673 overall support for one or more SS7 upper layers. From an SS7 674 standpoint, a Signalling Point Management Cluster (SPMC) provides 675 complete support for the upper layer service for a given point code. 676 As an example, an SPMC providing MGC capabilities could provide 677 complete support for ISUP (and any other MTP3 user located at the 678 point code of the SPMC) for a given point code. 680 In the case where an ASP is connected to more than one SGP, the M3UA 681 layer must maintain the status of configured SS7 destinations and 682 route messages according to availability/congestion/restricted status 683 of the routes to these SS7 destinations. 685 1.4.3.4 IPSP Considerations 687 Since IPSPs use M3UA in a point-to-point fashion, there is no concept 688 of routing of messages beyond the remote end. Therefore, SS7 and 689 M3UA interworking is not necessary for this model. 691 1.4.4 Redundancy Models 693 1.4.4.1 Application Server Redundancy 695 All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned 696 Routing Key at an SGP are mapped to an Application Server. 698 The Application Server is the set of all ASPs associated with a 699 specific Routing Key. Each ASP in this set may be active, inactive or 700 unavailable. Active ASPs handle traffic; inactive ASPs might be used 701 when active ASPs become unavailable. 703 The failover model supports an "n+k" redundancy model, where "n" ASPs 704 is the minimum number of redundant ASPs required to handle traffic and 705 "k" ASPs are available to take over for a failed or unavailable ASP. 706 Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be 707 either active at the same time as "n" or kept inactive until needed 708 due to a failed or unavailable ASP. 710 A "1+1" active/backup redundancy is a subset of this model. A 711 simplex "1+0" model is also supported as a subset, with no ASP 712 redundancy. 714 1.4.5 Flow Control 716 Local Management at an ASP may wish to stop traffic across an SCTP 717 association to temporarily remove the association from service or to 718 perform testing and maintenance activity. The function could 719 optionally be used to control the start of traffic on to a newly 720 available SCTP association. 722 1.4.6 Congestion Management 724 The M3UA layer is informed of local and IP network congestion by 725 means of an implementation-dependent function (e.g., an 726 implementation dependent indication from the SCTP of IP network 727 congestion). 729 At an ASP or IPSP, the M3UA layer indicates IP network congestion to 730 local MTP3-Users by means of an MTP-STATUS primitive, as per current 731 MTP3 procedures, to invoke appropriate upper layer responses. 733 When an SG determines that the transport of SS7 messages to a 734 Signalling Point Management Cluster (SPMC) is encountering 735 IP network congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled 736 management messages to originating SS7 nodes, per the congestion 737 procedures of the relevant MTP3 standard. The triggering of SS7 MTP3 738 Management messages from an SG is an implementation-dependent 739 function. 741 The M3UA layer at an ASP or IPSP MAY indicate local congestion to an 742 M3UA peer with an SCON message. When an SG receives a congestion 743 message (SCON) from an ASP, and the SG determines that an SPMC is now 744 encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled 745 management messages to concerned SS7 destinations according to 746 congestion procedures of the relevant MTP3 standard. 748 1.4.7 SCTP Stream Mapping 750 The M3UA layer at both the SGP and ASP also supports the assignment 751 of signalling traffic into streams within an SCTP association. 752 Traffic that requires sequencing SHOULD be assigned to the same 753 stream. To accomplish this, MTP3-User traffic may be assigned to 754 individual streams based on, for example, the SLS value in the MTP3 755 Routing Label, subject of course to the maximum number of streams 756 supported by the underlying SCTP association. 758 The following rules apply (see section 3.1.2): 760 1. DATA message MUST NOT be sent on stream 0. 761 2. ASPSM, MGMT, RKM classes SHOULD be sent on stream 0 (Other than 762 BEAT, BEAT ACK and NTFY messages) 763 3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be 764 sent on any stream. 766 1.4.8 SCTP Client/Server Model 768 It is recommended that the SGP and ASP be able to support both client 769 and server operation. The peer endpoints using M3UA SHOULD be 770 configured so that one always takes on the role of client and the 771 other the role of server for initiating SCTP associations. The 772 default orientation would be for the SGP to take on the role of 773 server while the ASP is the client. In this case, ASPs SHOULD 774 initiate the SCTP association to the SGP. 776 In the case of IPSP to IPSP communication, the peer endpoints using 777 M3UA SHOULD be configured so that one always takes on the role of 778 client and the other the role of server for initiating SCTP 779 associations. 781 The SCTP and TCP Registered User Port Number Assignment for M3UA is 782 2905. 784 1.5 Sample Configuration 786 1.5.1 Example 1: ISUP Message Transport 788 ******** SS7 ***************** IP ******** 789 * SEP *---------* SGP *--------* ASP * 790 ******** ***************** ******** 792 +------+ +---------------+ +------+ 793 | ISUP | | (NIF) | | ISUP | 794 +------+ +------+ +------+ +------+ 795 | MTP3 | | MTP3 | | M3UA | | M3UA | 796 +------| +------+-+------+ +------+ 797 | MTP2 | | MTP2 | | SCTP | | SCTP | 798 +------+ +------+ +------+ +------+ 799 | L1 | | L1 | | IP | | IP | 800 +------+ +------+ +------+ +------+ 801 |_______________| |______________| 803 SEP - SS7 Signalling End Point 804 SCTP - Stream Control Transmission Protocol 805 NIF - Nodal Interworking Function 807 In this example, the SGP provides an implementation-dependent nodal 808 interworking function (NIF) that allows the MGC to exchange SS7 809 signalling messages with the SS7-based SEP. The NIF within the SGP 810 serves as the interface within the SGP between the MTP3 and M3UA. 811 This nodal interworking function has no visible peer protocol with 812 either the MGC or SEP. It also provides network status information 813 to one or both sides of the network. 815 For internal SGP modeling purposes, at the NIF level, SS7 signalling 816 messages that are destined to the MGC are received as MTP-TRANSFER 817 indication primitives from the MTP Level 3 upper layer interface, 818 translated to MTP-TRANSFER request primitives, and sent to the local 819 M3UA-resident message distribution function for ongoing routing to 820 the final IP destination. Messages received from the local M3UA 821 network address translation and mapping function as MTP-TRANSFER 822 indication primitives are sent to the MTP Level 3 upper layer 823 interface as MTP-TRANSFER request primitives for ongoing MTP Level 3 824 routing to an SS7 SEP. For the purposes of providing SS7 network 825 status information the NIF also delivers MTP-PAUSE, MTP-RESUME and 826 MTP-STATUS indication primitives received from the MTP Level 3 upper 827 layer interface to the local M3UA-resident management function. In 828 addition, as an implementation and network option, restricted 829 destinations are communicated from MTP network management to the 830 local M3UA-resident management function. 832 1.5.2 Example 2: SCCP Transport between IPSPs 834 ******** IP ******** 835 * IPSP * * IPSP * 836 ******** ******** 838 +------+ +------+ 839 |SCCP- | |SCCP- | 840 | User | | User | 841 +------+ +------+ 842 | SCCP | | SCCP | 843 +------+ +------+ 844 | M3UA | | M3UA | 845 +------+ +------+ 846 | SCTP | | SCTP | 847 +------+ +------+ 848 | IP | | IP | 849 +------+ +------+ 850 |________________| 852 This example shows an architecture where no Signalling Gateway is 853 used. In this example, SCCP messages are exchanged directly between 854 two IP-resident IPSPs with resident SCCP-User protocol instances, 855 such as RANAP or TCAP. SS7 network interworking is not required, 856 therefore there is no MTP3 network management status information for 857 the SCCP and SCCP-User protocols to consider. Any MTP-PAUSE, MTP- 858 RESUME or MTP-STATUS indications from the M3UA layer to the SCCP 859 layer should consider the status of the SCTP Association and 860 underlying IP network and any congestion information received from 861 the remote site. 863 1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP 865 ******** SS7 ***************** IP ******** 866 * SEP *---------* *--------* * 867 * or * * SGP * * ASP * 868 * STP * * * * * 869 ******** ***************** ******** 871 +------+ +---------------+ +------+ 872 | SCCP-| | SCCP | | SCCP-| 873 | User | +---------------+ | User | 874 +------+ | _____ | +------+ 875 | SCCP | | | | | | SCCP | 876 +------+ +------+-+------+ +------+ 877 | MTP3 | | MTP3 | | M3UA | | M3UA | 878 +------| +------+ +------+ +------+ 879 | MTP2 | | MTP2 | | SCTP | | SCTP | 880 +------+ +------+ +------+ +------+ 881 | L1 | | L1 | | IP | | IP | 882 +------+ +------+ +------+ +------+ 883 |_______________| |______________| 885 STP - SS7 Signalling Transfer Point 887 In this example, the SGP contains an instance of the SS7 SCCP 888 protocol layer that may, for example, perform the SCCP Global Title 889 Translation (GTT) function for messages logically addressed to the SG 890 SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC 891 or DPC/SSN address of an SCCP peer located in the IP domain, the 892 resulting MTP-TRANSFER request primitive is sent to the local M3UA- 893 resident network address translation and mapping function for ongoing 894 routing to the final IP destination. 896 Similarly, the SCCP instance in an SGP can perform the SCCP GTT 897 service for messages logically addressed to it from SCCP peers in the 898 IP domain. In this case, MTP-TRANSFER indication primitives are sent 899 from the local M3UA-resident network address translation and mapping 900 function to the SCCP for GTT. If the result of the GTT yields the 901 address of an SCCP peer in the SS7 network then the resulting MTP- 902 TRANSFER request primitive is given to the MTP3 for delivery to an 903 SS7-resident node. 905 It is possible that the above SCCP GTT at the SGP could yield the 906 address of an SCCP peer in the IP domain and the resulting MTP- 907 TRANSFER request primitive would be sent back to the M3UA layer for 908 delivery to an IP destination. 910 For internal SGP modeling purposes, this may be accomplished with the 911 use of an implementation-dependent nodal interworking function within 912 the SGP that effectively sits below the SCCP and routes MTP-TRANSFER 913 request/indication messages to/from both the MTP3 and the M3UA layer, 914 based on the SS7 DPC or DPC/SI address information. This nodal 915 interworking function has no visible peer protocol with either the 916 ASP or SEP. 918 Note that the services and interface provided by the M3UA layer are 919 the same as in Example 1 and the functions taking place in the SCCP 920 entity are transparent to the M3UA layer. The SCCP protocol 921 functions are not reproduced in the M3UA protocol. 923 1.6 Definition of M3UA Boundaries 925 This section provides a definition of the boundaries of the M3UA 926 protoccol. They consist of SCTP, Layer Management and the MTP3-User. 928 +-----------+ 929 | MTP3-User | 930 +-----------+ 931 | 932 | 933 +-----------+ +------------+ 934 | M3UA |-----| Layer Mgmt | 935 +-----------+ +------------+ 936 | 937 | 938 +-----------+ 939 | SCTP | 940 +-----------+ 942 1.6.1 Definition of the Boundary between M3UA and an MTP3-User. 944 From ITU Q.701 [7]: 946 MTP-TRANSFER request 947 MTP-TRANSFER indication 948 MTP-PAUSE indication 949 MTP-RESUME indication 950 MTP-STATUS indication 952 1.6.2 Definition of the Boundary between M3UA and SCTP 954 An example of the upper layer primitives provided by the SCTP are 955 provided in Reference [17] Section 10. 957 1.6.3 Definition of the Boundary between M3UA and Layer Management 959 M-SCTP_ESTABLISH request 960 Direction: LM -> M3UA 961 Purpose: LM requests ASP to establish an SCTP association with its 962 peer. 964 M-SCTP_ESTABLISH confirm 965 Direction: M3UA -> LM 966 Purpose: ASP confirms to LM that it has established an SCTP 967 association with its peer. 969 M-SCTP_ESTABLISH indication 970 Direction: M3UA -> LM 971 Purpose: M3UA informs LM that a remote ASP has established an SCTP 972 association. 974 M-SCTP_RELEASE request 975 Direction: LM -> M3UA 976 Purpose: LM requests ASP to release an SCTP association with its 977 peer. 979 M-SCTP_RELEASE confirm 980 Direction: M3UA -> LM 981 Purpose: ASP confirms to LM that it has released SCTP association 982 with its peer. 984 M-SCTP_RELEASE indication 985 Direction: M3UA -> LM 986 Purpose: M3UA informs LM that a remote ASP has released an SCTP 987 Association or the SCTP association has failed. 989 M-SCTP_RESTART indication 990 Direction: M3UA -> LM 991 Purpose: M3UA informs LM that an SCTP restart indication has been 992 received. 994 M-SCTP_STATUS request 995 Direction: LM -> M3UA 996 Purpose: LM requests M3UA to report the status of an SCTP 997 association. 999 M-SCTP_STATUS confirm 1000 Direction: M3UA -> LM 1001 Purpose: M3UA responds with the status of an SCTP association. 1003 M-SCTP STATUS indication 1004 Direction: M3UA -> LM 1005 Purpose: M3UA reports the status of an SCTP association. 1007 M-ASP_STATUS request 1008 Direction: LM -> M3UA 1009 Purpose: LM requests M3UA to report the status of a local or remote 1010 ASP. 1012 M-ASP_STATUS confirm 1013 Direction: M3UA -> LM 1014 Purpose: M3UA reports status of local or remote ASP. 1016 M-AS_STATUS request 1017 Direction: LM -> M3UA 1018 Purpose: LM requests M3UA to report the status of an AS. 1020 M-AS_STATUS confirm 1021 Direction: M3UA -> LM 1022 Purpose: M3UA reports the status of an AS. 1024 M-NOTIFY indication 1025 Direction: M3UA -> LM 1026 Purpose: M3UA reports that it has received a Notify message 1027 from its peer. 1029 M-ERROR indication 1030 Direction: M3UA -> LM 1031 Purpose: M3UA reports that it has received an Error message from 1032 its peer or that a local operation has been unsuccessful. 1034 M-ASP_UP request 1035 Direction: LM -> M3UA 1036 Purpose: LM requests ASP to start its operation and send an ASP Up 1037 message to its peer. 1039 M-ASP_UP confirm 1040 Direction: M3UA -> LM 1041 Purpose: ASP reports that is has received an ASP UP Ack message from 1042 its peer. 1044 M-ASP_UP indication 1045 Direction: M3UA -> LM 1046 Purpose: M3UA reports it has successfully processed an incoming ASP 1047 Up message from its peer. 1049 M-ASP_DOWN request 1050 Direction: LM -> M3UA 1051 Purpose: LM requests ASP to stop its operation and send an ASP Down 1052 message to its peer. 1054 M-ASP_DOWN confirm 1055 Direction: M3UA -> LM 1056 Purpose: ASP reports that is has received an ASP Down Ack message 1057 from its peer. 1059 M-ASP_DOWN indication 1060 Direction: M3UA -> LM 1061 Purpose: M3UA reports it has successfully processed an incoming ASP 1062 Down message from its peer, or the SCTP association has 1063 been lost/reset. 1065 M-ASP_ACTIVE request 1066 Direction: LM -> M3UA 1067 Purpose: LM requests ASP to send an ASP Active message to its peer. 1069 M-ASP_ACTIVE confirm 1070 Direction: M3UA -> LM 1071 Purpose: ASP reports that is has received an ASP Active 1072 Ack message from its peer. 1074 M-ASP_ACTIVE indication 1075 Direction: M3UA -> LM 1076 Purpose: M3UA reports it has successfully processed an incoming ASP 1077 Active message from its peer. 1079 M-ASP_INACTIVE request 1080 Direction: LM -> M3UA 1081 Purpose: LM requests ASP to send an ASP Inactive message to its 1082 peer. 1084 M-ASP_INACTIVE confirm 1085 Direction: LM -> M3UA 1086 Purpose: ASP reports that is has received an ASP Inactive 1087 Ack message from its peer. 1089 M-ASP_INACTIVE indication 1090 Direction: M3UA -> LM 1091 Purpose: M3UA reports it has successfully processed an incoming ASP 1092 Inactive message from its peer. 1094 M-AS_ACTIVE indication 1095 Direction: M3UA -> LM 1096 Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state. 1098 M-AS_INACTIVE indication 1099 Direction: M3UA -> LM 1100 Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state. 1102 M-AS_DOWN indication 1103 Direction: M3UA -> LM 1104 Purpose: M3UA reports that an AS has moved to the AS-DOWN state. 1106 If dynamic registration of RK is supported by the M3UA layer, the 1107 layer MAY support the following additional primitives: 1109 M-RK_REG request 1110 Direction: LM -> M3UA 1111 Purpose: LM requests ASP to register RK(s) with its peer by sending 1112 REG REQ message 1114 M-RK_REG confirm 1115 Direction: M3UA -> LM 1116 Purpose: ASP reports that it has received REG RSP message with 1117 registration status as successful from its peer. 1119 M-RK_REG indication 1120 Direction: M3UA -> LM 1121 Purpose: M3UA informs LM that it has successfully processed an 1122 incoming REG REQ message. 1124 M-RK_DEREG request 1125 Direction: LM -> M3UA 1126 Purpose: LM requests ASP to deregister RK(s) with its peer by 1127 sending DEREG REQ message. 1129 M-RK_DEREG confirm 1130 Direction: M3UA -> LM 1131 Purpose: ASP reports that it has received DEREG REQ message with 1132 deregistration status as successful from its peer. 1134 M-RK_DEREG indication 1135 Direction: M3UA -> LM 1136 Purpose: M3UA informs LM that it has successfully processed an 1137 incoming DEREG REQ from its peer. 1139 2. Conventions 1141 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 1142 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 1143 they appear in this document, are to be interpreted as described in 1144 [20]. 1146 3. M3UA Protocol Elements 1148 The general M3UA message format includes a Common Message Header 1149 followed by zero or more parameters as defined by the Message Type. 1151 For forward compatibility, all Message Types may have attached 1152 parameters even if none are specified in this version. 1154 3.1 Common Message Header 1156 The protocol messages for MTP3-User Adaptation require a message 1157 header which contains the adaptation layer version, the message type, 1158 and message length. 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Version | Reserved | Message Class | Message Type | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Message Length | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 \ \ 1168 / / 1170 All fields in an M3UA message MUST be transmitted in the network byte 1171 order, unless otherwise stated. 1173 3.1.1 M3UA Protocol Version: 8 bits (unsigned integer) 1175 The version field contains the version of the M3UA adaptation layer. 1177 The supported versions are the following: 1179 1 Release 1.0 1181 3.1.2 Message Classes and Types 1183 The following list contains the valid Message Classes: 1185 Message Class: 8 bits (unsigned integer) 1187 The following list contains the valid Message Type Classes: 1189 0 Management (MGMT) Messages 1190 1 Transfer Messages 1191 2 SS7 Signalling Network Management (SSNM) Messages 1192 3 ASP State Maintenance (ASPSM) Messages 1193 4 ASP Traffic Maintenance (ASPTM) Messages 1194 5 Reserved for Other SIGTRAN Adaptation Layers 1195 6 Reserved for Other SIGTRAN Adaptation Layers 1196 7 Reserved for Other SIGTRAN Adaptation Layers 1197 8 Reserved for Other SIGTRAN Adaptation Layers 1198 9 Routing Key Management (RKM) Messages 1199 10 to 127 Reserved by the IETF 1200 128 to 255 Reserved for IETF-Defined Message Class extensions 1201 Message Type: 8 bits (unsigned integer) 1203 The following list contains the message types for the defined 1204 messages. 1206 Management (MGMT) Messages (See Section 3.8) 1208 0 Error (ERR) 1209 1 Notify (NTFY) 1210 2 to 127 Reserved by the IETF 1211 128 to 255 Reserved for IETF-Defined MGMT extensions 1213 Transfer Messages (See Section 3.3) 1215 0 Reserved 1216 1 Payload Data (DATA) 1217 2 to 127 Reserved by the IETF 1218 128 to 255 Reserved for IETF-Defined Transfer extensions 1220 SS7 Signalling Network Management (SSNM) Messages (See Section 1221 3.4) 1223 0 Reserved 1224 1 Destination Unavailable (DUNA) 1225 2 Destination Available (DAVA) 1226 3 Destination State Audit (DAUD) 1227 4 Signalling Congestion (SCON) 1228 5 Destination User Part Unavailable (DUPU) 1229 6 Destination Restricted (DRST) 1230 7 to 127 Reserved by the IETF 1231 128 to 255 Reserved for IETF-Defined SSNM extensions 1233 ASP State Maintenance (ASPSM) Messages (See Section 3.5) 1235 0 Reserved 1236 1 ASP Up (ASPUP) 1237 2 ASP Down (ASPDN) 1238 3 Heartbeat (BEAT) 1239 4 ASP Up Acknowledgement (ASPUP ACK) 1240 5 ASP Down Acknowledgement (ASPDN ACK) 1241 6 Heartbeat Acknowledgement (BEAT ACK) 1242 7 to 127 Reserved by the IETF 1243 128 to 255 Reserved for IETF-Defined ASPSM extensions 1245 ASP Traffic Maintenance (ASPTM) Messages (See Section 3.7) 1247 0 Reserved 1248 1 ASP Active (ASPAC) 1249 2 ASP Inactive (ASPIA) 1250 3 ASP Active Acknowledgement (ASPAC ACK) 1251 4 ASP Inactive Acknowledgement (ASPIA ACK) 1253 5 to 127 Reserved by the IETF 1254 128 to 255 Reserved for IETF-Defined ASPTM extensions 1256 Routing Key Management (RKM) Messages (See Section 3.6) 1258 0 Reserved 1259 1 Registration Request (REG REQ) 1260 2 Registration Response (REG RSP) 1261 3 Deregistration Request (DEREG REQ) 1262 4 Deregistration Response (DEREG RSP) 1263 5 to 127 Reserved by the IETF 1264 128 to 255 Reserved for IETF-Defined RKM extensions 1266 3.1.3 Reserved: 8 bits 1268 The Reserved field SHOULD be set to all '0's and ignored by the 1269 receiver. 1271 3.1.4 Message Length: 32-bits (unsigned integer) 1273 The Message Length defines the length of the message in octets, 1274 including the Common Header. The Message Length MUST include 1275 parameter padding octets, if any. 1277 Note: A receiver SHOULD accept the message whether or not the final 1278 parameter padding is included in the message length. 1280 3.2 Variable Length Parameter Format 1282 M3UA messages consist of a Common Header followed by zero or more 1283 variable length parameters, as defined by the message type. All the 1284 parameters contained in a message are defined in a Tag Length-Value 1285 format as shown below. 1287 0 1 2 3 1288 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 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Parameter Tag | Parameter Length | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 \ \ 1293 / Parameter Value / 1294 \ \ 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 Where more than one parameter is included in a message, the 1298 parameters may be in any order, except where explicitly mandated. A 1299 receiver SHOULD accept the parameters in any order. 1301 Unless explicitly stated or shown in a message format diagram, only 1302 one parameter of the same type is allowed in a message. 1304 Parameter Tag: 16 bits (unsigned integer) 1306 The Tag field is a 16-bit identifier of the type of parameter. It 1307 takes a value of 0 to 65534. Common parameters used by adaptation 1308 layers are in the range of 0x00 to 0x3f. M3UA-specific 1309 parameters have Tags in the range 0x0200 to 0x02ff. The parameter 1310 Tags defined are as follows: 1312 Common Parameters. These TLV parameters are common across the 1313 different adaptation layers: 1315 Parameter Name Parameter ID 1316 ============== ============ 1317 Reserved 0x0000 1318 Not Used in M3UA 0x0001 1319 Not Used in M3UA 0x0002 1320 Not Used in M3UA 0x0003 1321 INFO String 0x0004 1322 Not Used in M3UA 0x0005 1323 Routing Context 0x0006 1324 Diagnostic Information 0x0007 1325 Not Used in M3UA 0x0008 1326 Heartbeat Data 0x0009 1327 Not Used in M3UA 0x000a 1328 Traffic Mode Type 0x000b 1329 Error Code 0x000c 1330 Status 0x000d 1331 Not Used in M3UA 0x000e 1332 Not Used in M3UA 0x000f 1333 Not Used in M3UA 0x0010 1334 ASP Identifier 0x0011 1335 Affected Point Code 0x0012 1336 Correlation ID 0x0013 1338 M3UA-Specific parameters. These TLV parameters are specific to 1339 the M3UA protocol: 1341 Network Appearance 0x0200 1342 Reserved 0x0201 1343 Reserved 0x0202 1344 Reserved 0x0203 1345 User/Cause 0x0204 1346 Congestion Indications 0x0205 1347 Concerned Destination 0x0206 1348 Routing Key 0x0207 1349 Registration Result 0x0208 1350 Deregistration Result 0x0209 1351 Local Routing Key Identifier 0x020a 1352 Destination Point Code 0x020b 1353 Service Indicators 0x020c 1354 Reserved 0x020d 1355 Originating Point Code List 0x020e 1356 Reserved 0x020f 1357 Protocol Data 0x0210 1358 Reserved 0x0211 1359 Registration Status 0x0212 1360 Deregistration Status 0x0213 1362 Reserved by the IETF 0x0214 to 0xffff 1364 The value of 65535 is reserved for IETF-defined extensions. 1365 Values other than those defined in specific parameter description 1366 are reserved for use by the IETF. A RFC is required to make use 1367 of parameter values "Reserved by the IETF". 1369 Parameter Length: 16 bits (unsigned integer) 1371 The Parameter Length field contains the size of the parameter 1372 in octets, including the Parameter Tag, Parameter Length, and 1373 Parameter Value fields. Thus, a parameter with a zero-length 1374 Parameter Value field would have a Length field of 4. The 1375 Parameter Length does not include any padding octets. If the 1376 parameter contains subparameters, the Parameter Length field 1377 will include all the octets of each subparameter including 1378 subparameter padding octets (if any). 1380 Parameter Value: variable length. 1382 The Parameter Value field contains the actual information to be 1383 transferred in the parameter. 1385 The total length of a parameter (including Tag, Parameter Length 1386 and Value fields) MUST be a multiple of 4 octets. If the length of 1387 the parameter is not a multiple of 4 octets, the sender pads the 1388 Parameter at the end (i.e., after the Parameter Value field) with 1389 all zero octets. The length of the padding is NOT included in the 1390 parameter length field. A sender MUST NOT pad with more than 3 1391 octets. The receiver MUST ignore the padding octets. 1393 3.3 Transfer Messages 1395 The following section describes the Transfer messages and parameter 1396 contents. 1398 3.3.1 Payload Data Message (DATA) 1400 The DATA message contains the SS7 MTP3-User protocol data, which is 1401 an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. 1402 The DATA message contains the following variable length parameters: 1404 Network Appearance Optional 1405 Routing Context Conditional 1406 Protocol Data Mandatory 1407 Correlation Id Optional 1409 The following format MUST be used for the Data Message: 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Tag = 0x0200 | Length = 8 | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Network Appearance | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Tag = 0x0006 | Length = 8 | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Routing Context | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Tag = 0x0210 | Length | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 \ \ 1425 / Protocol Data / 1426 \ \ 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | Tag = 0x0013 | Length = 8 | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Correlation Id | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 Network Appearance: 32-bits (unsigned integer) 1435 The Network Appearance parameter identifies the SS7 network 1436 context for the message and implicitly identifies the SS7 Point 1437 Code format used, the SS7 Network Indicator value, and the MTP3 1438 and possibly the MTP3-User protocol type/variant/version used 1439 within the specific SS7 network. Where a SG operates in the 1440 context of a single SS7 network, or individual SCTP associations 1441 are dedicated to each SS7 network context, the Network Appearance 1442 parameter is not required. In other cases the parameter may be 1443 configured to be present for the use of the receiver. 1445 The Network Appearance parameter value is of local significance 1446 only, coordinated between the SGP and ASP. Therefore, in the case 1447 where an ASP is connected to more than one SGP, the same SS7 1448 network context may be identified by different Network Appearance 1449 values depending over which SGP a message is being transmitted/ 1450 received. 1452 Where the optional Network Appearance parameter is present, it 1453 MUST be the first parameter in the message as it defines the 1454 format of the Protocol Data field. 1456 IMPLEMENTATION NOTE: For simplicity of configuration it may be 1457 desirable to use the same NA value across all nodes sharing a 1458 particular network context. 1460 Routing Context: 32-bits (unsigned integer) 1462 The Routing Context parameter contains the Routing Context value 1463 associated with the DATA message. Where a Routing Key has not 1464 been coordinated between the SGP and ASP, sending of Routing 1465 Context is not required. Where multiple Routing Keys and Routing 1466 Contexts are used across a common association, the Routing Context 1467 MUST be sent to identify the traffic flow, assisting in the 1468 internal distribution of Data messages. 1470 Protocol Data: variable length 1472 The Protocol Data parameter contains the original SS7 MTP3 1473 message, including the Service Information Octet and Routing 1474 Label. 1476 The Protocol Data parameter contains the following fields: 1478 Service Indicator, 1479 Network Indicator, 1480 Message Priority. 1482 Destination Point Code, 1483 Originating Point Code, 1485 Signalling Link Selection Code (SLS). 1487 User Protocol Data. Includes: 1489 MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP 1490 parameters). 1492 The Protocol Data parameter is encoded as follows: 1494 0 1 2 3 1495 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 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Originating Point Code | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Destination Point Code | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | SI | NI | MP | SLS | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 \ \ 1504 / User Protocol Data / 1505 \ \ 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Originating Point Code: 32 bits (unsigned integer) 1509 Destination Point Code: 32 bits (unsigned integer) 1511 The Originating and Destination Point Code fields contains the OPC 1512 and DPC from the routing label of the original SS7 message in Network 1513 Byte Order, justified to the least significant bit. Unused bits are 1514 coded `0'. 1516 Service Indicator: 8 bits (unsigned integer) 1518 The Service Indicator field contains the SI field from the original 1519 SS7 message justified to the least significant bit. Unused bits are 1520 coded `0'. 1522 Network Indicator: 8-bits (unsigned integer) 1524 The Network Indicator contains the NI field from the original SS7 1525 message justified to the least significant bit. Unused bits are 1526 coded `0'. 1528 Message Priority: 8 bits (unsigned integer) 1530 The Message Priority field contains the MP bits (if any) from the 1531 original SS7 message, both for ANSI-style and TTC-style [29] message 1532 priority bits. The MP bits are aligned to the least significant bit. 1533 Unused bits are coded `0'. 1535 Signalling Link Selection: 8 bits (unsigned integer) 1537 The Signalling Link Selection field contains the SLS bits from the 1538 routing label of the original SS7 message justified to the least 1539 significant bit and in Network Byte Order. Unused bits are coded 1540 `0'. 1542 User Protocol Data: (variable length octet string) 1544 The User Protocol Data field contains a octet string of MTP-User 1545 information from the original SS7 message starting with the 1546 first octet of the original SS7 message following the Routing 1547 Label [7][8][29]. 1549 Correlation Id: 32-bits (unsigned integer) 1551 The Correlation Id parameter uniquely identifies the MSU carried in 1552 the Protocol Data within an AS. This Correlation Id parameter is 1553 assigned by the sending M3UA. 1555 3.4 SS7 Signalling Network Management (SSNM) Messages 1557 3.4.1 Destination Unavailable (DUNA) 1559 The DUNA message is sent from an SGP in an SG to all concerned ASPs 1560 to indicate that the SG has determined that one or more SS7 1561 destinations are unreachable. It is also sent by an SGP in response 1562 to a message from the ASP to an unreachable SS7 destination. As an 1563 implementation option the SG may suppress the sending of subsequent 1564 "response" DUNA messages regarding a certain unreachable SS7 1565 destination for a certain period to give the remote side time to 1566 react. If there is no alternate route via another SG, the MTP3-User 1567 at the ASP is expected to stop traffic to the affected destination 1568 via the SG as per the defined MTP3-User procedures. 1570 The DUNA message contains the following parameters: 1572 Network Appearance Optional 1573 Routing Context Conditional 1574 Affected Point Code Mandatory 1575 INFO String Optional 1577 The format for DUNA Message parameters is as follows: 1579 0 1 2 3 1580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Tag = 0x0200 | Length = 8 | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Network Appearance | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Tag = 0x0006 | Length | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 \ \ 1589 / Routing Context / 1590 \ \ 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Tag = 0x0012 | Length | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Mask | Affected PC 1 | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 \ \ 1597 / ... / 1598 \ \ 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Mask | Affected PC n | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Tag = 0x0004 | Length | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 \ \ 1605 / INFO String / 1606 \ \ 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Network Appearance: 32-bit unsigned integer 1610 The description of Network Appearance in Section 3.3.1 applies 1611 with the exception that Network Appearance does not have to be 1612 the first parameter in this message. 1614 Routing Context: n x 32-bits (unsigned integer) 1616 The conditional Routing Context parameter contains the Routing 1617 Context values associated with the DUNA message. Where a Routing 1618 Key has not been coordinated between the SGP and ASP, sending of 1620 Routing Context is not required. Where multiple Routing Keys and 1621 Routing Contexts are used across a common association, the Routing 1622 Context(s) MUST be sent to identify the concerned traffic flows 1623 for which the DUNA message applies, assisting in outgoing traffic 1624 management and internal distribution of MTP-PAUSE indications to 1625 MTP3-Users at the receiver. 1627 Affected Point Code: n x 32-bits 1629 The Affected Point Code parameter contains a list of Affected 1630 Destination Point Code fields, each a three-octet parameter to 1631 allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. 1632 Affected Point Codes that are less than 24-bits, are padded on the 1633 left to the 24-bit boundary. The encoding is shown below for ANSI 1634 and ITU Point Code examples. 1636 ANSI 24-bit Point Code: 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Mask | Network | Cluster | Member | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 |MSB-----------------------------------------LSB| 1646 ITU 14-bit Point Code: 1648 0 1 2 3 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 |MSB--------------------LSB| 1656 It is optional to send an Affected Point Code parameter with more 1657 than one Affected PC but it is mandatory to receive it. Including 1658 multiple Affected PCs may be useful when reception of an MTP3 1659 management message or a linkset event simultaneously affects the 1660 availability status of a list of destinations at an SG. 1662 Mask: 8-bits (unsigned integer) 1664 The Mask field can be used to identify a contiguous range of 1665 Affected Destination Point Codes. Identifying a contiguous range 1666 of Affected DPCs may be useful when reception of an MTP3 1667 management message or a linkset event simultaneously affects the 1668 availability status of a series of destinations at an SG. 1670 The Mask parameter is an integer representing a bit mask that can 1671 be applied to the related Affected PC field. The bit mask 1672 identifies how many bits of the Affected PC field are significant 1673 and which are effectively "wildcarded". For example, a mask of 1674 "8" indicates that the last eight bits of the PC is "wildcarded". 1675 For an ANSI 24-bit Affected PC, this is equivalent to signalling 1676 that all PCs in an ANSI Cluster are unavailable. A mask of "3" 1677 indicates that the last three bits of the PC is "wildcarded". For 1678 a 14-bit ITU Affected PC, this is equivalent to signaling that an 1679 ITU Region is unavailable. A mask value equal (or greater than) 1680 the number of bits in the PC indicates that the entire network 1681 appearance is affected - this is used to indicate network 1682 isolation to the ASP. 1684 INFO String: variable length 1686 The optional INFO String parameter can carry any meaningful UTF-8 1687 [10] character string along with the message. Length of the INFO 1688 String parameter is from 0 to 255 octets. No procedures are 1689 presently identified for its use but the INFO String MAY be used 1690 for debugging purposes. An INFO String with a zero length 1691 parameter is not considered as an error (A zero length parameter is 1692 one in which the Length field in the TLV will be set to 4). 1694 3.4.2 Destination Available (DAVA) 1696 The DAVA message is sent from an SGP to all concerned ASPs to 1697 indicate that the SG has determined that one or more SS7 destinations 1698 are now reachable (and not restricted), or in response to a DAUD 1699 message if appropriate. If the ASP M3UA layer previously had no 1700 routes to the affected destinations the ASP MTP3-User protocol is 1701 informed and may now resume traffic to the affected destination. The 1702 ASP M3UA layer now routes the MTP3-user traffic through the SG 1703 initiating the DAVA message. 1705 The DAVA message contains the following parameters: 1707 Network Appearance Optional 1708 Routing Context Conditional 1709 Affected Point Code Mandatory 1710 INFO String Optional 1712 The format and description of the Network Appearance, Routing 1713 Context, Affected Point Code and INFO String parameters is the same 1714 as for the DUNA message (See Section 3.4.1). 1716 3.4.3 Destination State Audit (DAUD) 1718 The DAUD message MAY be sent from the ASP to the SGP to audit the 1719 availability/congestion state of SS7 routes from the SG to one or 1720 more affected destinations. 1722 The DAUD message contains the following parameters: 1724 Network Appearance Optional 1725 Routing Context Conditional 1726 Affected Point Code Mandatory 1727 INFO String Optional 1729 The format and description of DAUD Message parameters is the same as 1730 for the DUNA message (See Section 3.4.1). 1732 It is recommended that during normal operation (traffic handling) the 1733 mask field of the Affected Point Code parameter in the DAUD message is 1734 kept to a zero value in order to avoid SG overloading. 1736 3.4.4 Signalling Congestion (SCON) 1738 The SCON message can be sent from an SGP to all concerned ASPs to 1739 indicate that an SG has determined that there is congestion in the 1740 SS7 network to one or more destinations, or to an ASP in response to 1741 a DATA or DAUD message as appropriate. For some MTP protocol 1742 variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 1743 congestion level changes. The SCON message MAY also be sent from the 1744 M3UA layer of an ASP to an M3UA peer indicating that the congestion 1745 level of the M3UA layer or the ASP has changed. 1747 IMPLEMENTATION NOTE: An M3UA node may maintain a timer to control 1748 congestion notification validity, if desired. This timer will be 1749 useful in those cases where the peer node fails to indicate 1750 congestion abatement. 1752 The SCON message contains the following parameters: 1754 Network Appearance Optional 1755 Routing Context Conditional 1756 Affected Point Code Mandatory 1757 Concerned Destination Optional 1758 Congestion Indications Optional 1759 INFO String Optional 1761 The format for SCON Message parameters is as follows: 1763 0 1 2 3 1764 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 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Tag = 0x0200 | Length = 8 | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Network Appearance | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Tag = 0x0006 | Length | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 \ \ 1773 / Routing Context / 1774 \ \ 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Tag = 0x0012 | Length | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Mask | Affected PC 1 | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 \ \ 1781 / ... / 1782 \ \ 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Mask | Affected PC n | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Tag = 0x0206 | Length = 8 | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | reserved | Concerned DPC | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Tag = 0x0205 | Length = 8 | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Reserved | Cong. Level | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Tag = 0x0004 | Length | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 \ \ 1797 / INFO String / 1798 \ \ 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 The format and description of the Network Appearance, Routing 1802 Context, Affected Point Code, and INFO String parameters is the same 1803 as for the DUNA message (See Section 3.4.1). 1805 The Affected Point Code parameter can be used to indicate congestion 1806 of multiple destinations or ranges of destinations. 1808 Concerned Destination: 32-bits 1810 The optional Concerned Destination parameter is only used if the 1811 SCON message is sent from an ASP to the SGP. It contains the point 1812 code of the originator of the message that triggered the SCON 1813 message. The Concerned Destination parameter contains one 1814 Concerned Destination Point Code field, a three-octet parameter to 1815 allow for 14-, 16- and 24-bit binary formatted SS7 Point Codes. A 1816 Concerned Point Code that is less than 24-bits is padded on the 1817 left to the 24-bit boundary. Any resulting Transfer Controlled 1818 (TFC) message from the SG is sent to the Concerned Point Code 1819 using the single Affected DPC contained in the SCON message to 1820 populate the (affected) Destination field of the TFC message 1822 Congested Indications: 32-bits 1824 The optional Congestion Indications parameter contains a 1825 Congestion Level field. This optional parameter is used to 1826 communicate congestion levels in national MTP networks with 1827 multiple congestion thresholds, such as in ANSI MTP3. For MTP 1828 congestion methods without multiple congestion levels (e.g., the 1829 ITU international method) the parameter is not included. 1831 Congestion Level field: 8-bits (unsigned integer) 1833 The Congestion Level field, associated with all of the Affected 1834 DPC(s) in the Affected Destinations parameter, contains one of the 1835 following values: 1837 0 No Congestion or Undefined 1838 1 Congestion Level 1 1839 2 Congestion Level 2 1840 3 Congestion Level 3 1842 The congestion levels are defined in the congestion method in the 1843 appropriate national MTP recommendations [7,8]. 1845 3.4.5 Destination User Part Unavailable (DUPU) 1847 The DUPU message is used by an SGP to inform concerned ASPs that a 1848 remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is 1849 unavailable. 1851 The DUPU message contains the following parameters: 1853 Network Appearance Optional 1854 Routing Context Conditional 1855 Affected Point Code Mandatory 1856 User/Cause Mandatory 1857 INFO String Optional 1859 The format for DUPU message parameters is as follows: 1861 0 1 2 3 1862 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 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Tag = 0x0200 | Length = 8 | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | Network Appearance | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Tag = 0x0006 | Length | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 \ \ 1871 / Routing Context / 1872 \ \ 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | Tag = 0x0012 | Length = 8 | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | Mask = 0 | Affected PC | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Tag = 0x0204 | Length = 8 | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Cause | User | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Tag = 0x0004 | Length | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 \ \ 1885 / INFO String / 1886 \ \ 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 User/Cause: 32-bits 1891 The Unavailability Cause and MTP3-User Identity fields, associated 1892 with the Affected PC in the Affected Point Code parameter, are 1893 encoded as follows: 1895 Unavailability Cause field: 16-bits (unsigned integer) 1897 The Unavailability Cause parameter provides the reason for the 1898 unavailability of the MTP3-User. The valid values for the 1899 Unavailability Cause parameter are shown in the following table. 1900 The values agree with those provided in the SS7 MTP3 User Part 1901 Unavailable message. Depending on the MTP3 protocol used in the 1902 Network Appearance, additional values may be used - the 1903 specification of the relevant MTP3 protocol variant/version 1904 recommendation is definitive. 1906 0 Unknown 1907 1 Unequipped Remote User 1908 2 Inaccessible Remote User 1910 MTP3-User Identity field: 16-bits (unsigned integer) 1912 The MTP3-User Identity describes the specific MTP3-User that is 1913 unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for 1914 the MTP3-User Identity are shown below. The values align with 1915 those provided in the SS7 MTP3 User Part Unavailable message and 1916 Service Indicator. Depending on the MTP3 protocol variant/version 1917 used in the Network Appearance, additional values may be used. 1918 The relevant MTP3 protocol variant/version recommendation is 1919 definitive. 1921 0 to 2 Reserved 1922 3 SCCP 1923 4 TUP 1924 5 ISUP 1925 6 to 8 Reserved 1926 9 Broadband ISUP 1927 10 Satellite ISUP 1928 11 Reserved 1929 12 AAL type 2 Signalling 1930 13 Bearer Independent Call Control (BICC) 1931 14 Gateway Control Protocol 1932 15 Reserved 1934 The format and description of the Affected Point Code parameter is 1935 the same as for the DUNA message (See Section 3.4.1.) except that 1936 the Mask field is not used and only a single Affected DPC is 1937 included. Ranges and lists of Affected DPCs cannot be signaled in 1938 a DUPU message, but this is consistent with UPU operation in the 1939 SS7 network. The Affected Destinations parameter in an MTP3 User 1940 Part Unavailable message (UPU) received by an SGP from the SS7 1941 network contains only one destination. 1943 The format and description of the Network Appearance, Routing 1944 Context, and INFO String parameters is the same as for the DUNA 1945 message (See Section 3.4.1). 1947 3.4.6 Destination Restricted (DRST) 1949 The DRST message is optionally sent from the SGP to all concerned 1950 ASPs to indicate that the SG has determined that one or more SS7 1951 destinations are now restricted from the point of view of the SG, or 1952 in response to a DAUD message if appropriate. The M3UA layer at the 1953 ASP is expected to send traffic to the affected destination via an 1954 alternate SG with route(s) of equal priority, but only if such an 1955 alternate route exists and is available. If the affected destination 1956 is currently considered unavailable by the ASP, The MTP3-User should 1957 be informed that traffic to the affected destination can be resumed. 1958 In this case, the M3UA layer should route the traffic through the SG 1959 initiating the DRST message. 1961 This message is optional for the SG to send and it is optional for 1962 the ASP to act on any information received in the message. It is for 1963 use in the "STP" case described in Section 1.4.1. 1965 The DRST message contains the following parameters: 1967 Network Appearance Optional 1968 Routing Context Conditional 1969 Affected Point Code Mandatory 1970 INFO String Optional 1972 The format and description of the Network Appearance, Routing 1973 Context, Affected Point Code and INFO String parameters is the same 1974 as for the DUNA message (See Section 3.4.1). 1976 3.5 ASP State Maintenance (ASPSM) Messages 1978 3.5.1 ASP Up 1980 The ASP Up message is used to indicate to a remote M3UA peer that the 1981 adaptation layer is ready to receive any ASPSM/ASPTM messages for all 1982 Routing Keys that the ASP is configured to serve. 1984 The ASP Up message contains the following parameters: 1986 ASP Identifier Optional 1987 INFO String Optional 1989 The format for ASP Up message parameters is as follows: 1991 0 1 2 3 1992 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 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Tag = 0x0011 | Length = 8 | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | ASP Identifier | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Tag = 0x0004 | Length | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 \ \ 2001 / INFO String / 2002 \ \ 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 ASP Identifier: 32-bit unsigned integer 2007 The optional ASP Identifier parameter contains a unique value that 2008 is locally significant among the ASPs that support an AS. The SGP 2009 should save the ASP Identifier to be used, if necessary, with the 2010 Notify message (see Section 3.8.2). 2012 The format and description of the optional INFO String parameter 2013 is the same as for the DUNA message (See Section 3.4.1). 2015 3.5.2 ASP Up Acknowledgement (ASP Up Ack) 2016 The ASP UP Ack message is used to acknowledge an ASP Up message 2017 received from a remote M3UA peer. 2019 The ASP Up Ack message contains the following parameters: 2020 ASP Identifier Optional 2021 INFO String Optional 2023 The format for ASP Up Ack message parameters is as follows: 2025 0 1 2 3 2026 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 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Tag = 0x0011 | Length = 8 | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | ASP Identifier | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Tag =0x0004 | Length | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 \ \ 2035 / INFO String / 2036 \ \ 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 The optional ASP Identifier parameter is specifically useful for IPSP 2040 communication. In that case the IPSP answering the ASP Up message MAY 2041 include its own ASP Identifier value. 2043 The format and description of the optional INFO String parameter is 2044 the same as for the DUNA message (See Section 3.4.1). The INFO 2045 String in an ASP Up Ack message is independent from the INFO String 2046 in the ASP Up message (i.e., it does not have to echo back the INFO 2047 String received). 2049 3.5.3 ASP Down 2051 The ASP Down message is used to indicate to a remote M3UA peer that 2052 the adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM 2053 messages. 2055 The ASP Down message contains the following parameters: 2057 INFO String Optional 2059 The format for the ASP Down message parameters is as follows: 2061 0 1 2 3 2062 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 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Tag =0x0004 | Length | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 \ \ 2067 / INFO String / 2068 \ \ 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 The format and description of the optional INFO String parameter is 2072 the same as for the DUNA message (See Section 3.4.1). 2074 3.5.4 ASP Down Acknowledgement (ASP Down Ack) 2076 The ASP Down Ack message is used to acknowledge an ASP Down message 2077 received from a remote M3UA peer. 2079 The ASP Down Ack message contains the following parameters: 2081 INFO String Optional 2083 The format for the ASP Down Ack message parameters is as follows: 2085 0 1 2 3 2086 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 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | Tag = 0x0004 | Length | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 \ \ 2091 / INFO String / 2092 \ \ 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 The format and description of the optional INFO String parameter is 2096 the same as for the DUNA message (See Section 3.4.1). 2098 The INFO String in an ASP Down Ack message is independent from the 2099 INFO String in the ASP Down message (i.e., it does not have to echo 2100 back the INFO String received). 2102 3.5.5 Heartbeat (BEAT) 2104 The BEAT message is optionally used to ensure that the M3UA peers are 2105 still available to each other. It is recommended for use when the 2106 M3UA runs over a transport layer other than the SCTP, which has its 2107 own heartbeat. 2109 The BEAT message contains the following parameters: 2111 Heartbeat Data Optional 2113 The format for the BEAT message is as follows: 2115 0 1 2 3 2116 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 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Tag = 0x0009 | Length | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 \ \ 2122 / Heartbeat Data / 2123 \ \ 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 The Heartbeat Data parameter contents are defined by the sending 2127 node. The Heartbeat Data could include, for example, a Heartbeat 2128 Sequence Number and/or Timestamp. The receiver of a BEAT message 2129 does not process this field as it is only of significance to the 2130 sender. The receiver MUST respond with a BEAT Ack message. 2132 3.5.6 Heartbeat Acknowledgement (BEAT Ack) 2134 The BEAT Ack message is sent in response to a received BEAT message. 2135 It includes all the parameters of the received BEAT message, without 2136 any change. 2138 3.6 Routing Key Management (RKM) Messages [Optional] 2140 3.6.1 Registration Request (REG REQ) 2142 The REG REQ message is sent by an ASP to indicate to a remote M3UA 2143 peer that it wishes to register one or more given Routing Keys with 2144 the remote peer. Typically, an ASP would send this message to an 2145 SGP, and expects to receive a REG RSP message in return with an 2146 associated Routing Context value. 2148 The REG REQ message contains the following parameters: 2150 Routing Key Mandatory 2152 One or more Routing Key parameters MAY be included. The format for 2153 the REG REQ message is as follows: 2155 0 1 2 3 2156 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 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Tag = 0x0207 | Length | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 \ \ 2161 / Routing Key 1 / 2162 \ \ 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 \ \ 2165 / ... / 2166 \ \ 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Tag = 0x0207 | Length | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 \ \ 2171 / Routing Key n / 2172 \ \ 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 Routing Key: variable length 2177 The Routing Key parameter is mandatory. The sender of this message 2178 expects that the receiver of this message will create a Routing 2179 Key entry and assign a unique Routing Context value to it, if the 2180 Routing Key entry does not already exist. 2182 The Routing Key parameter may be present multiple times in the 2183 same message. This is used to allow the registration of multiple 2184 Routing Keys in a single message. 2186 The format of the Routing Key parameter is as follows. 2188 0 1 2 3 2189 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 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Local-RK-Identifier | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | Routing Context (optional) | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Traffic Mode Type (optional) | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Destination Point Code | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Network Appearance (optional) | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Service Indicators (optional) | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | Originating Point Code List (optional) | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 \ \ 2206 / ... / 2207 \ \ 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | Destination Point Code | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | Service Indicators (optional) | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | Originating Point Code List (optional) | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 Note: The Destination Point Code, Service Indicators, and 2217 Originating Point Code List parameters MAY be repeated as a 2218 grouping within the Routing Key parameter, in the structure shown 2219 above. 2221 Local-RK-Identifier: 32-bit unsigned integer 2223 The mandatory Local-RK-Identifier field is used to uniquely 2224 identify the registration request. The Identifier value is 2225 assigned by the ASP, and is used to correlate the response in an 2226 REG RSP message with the original registration request. The 2227 Identifier value must remain unique until the REG RSP message is 2228 received. 2230 The format of the Local-RK-Identifier field is as follows: 2232 0 1 2 3 2233 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 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 | Tag = 0x020a | Length = 8 | 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | Local-RK-Identifier value | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 Traffic Mode Type: 32-bit (unsigned integer) 2242 The optional Traffic Mode Type parameter identifies the traffic mode 2243 of operation of the ASP(s) within an Application Server. The format 2244 of the Traffic Mode Type Identifier is as follows: 2246 0 1 2 3 2247 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 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Tag = 0x000b | Length = 8 | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | Traffic Mode Type | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 The valid values for Traffic Mode Type are shown in the following 2255 table: 2257 1 Override 2258 2 Loadshare 2259 3 Broadcast 2261 Destination Point Code: 2263 The Destination Point Code parameter is mandatory, and 2264 Identifies the Destination Point Code of incoming SS7 traffic 2265 for which the ASP is registering. For an alias point code 2266 configuration, the DPC parameter would be repeated for each 2267 point code. The format is the same as described for the 2268 Affected Destination parameter in the DUNA message (See Section 2269 3.4.1). Its format is: 2271 0 1 2 3 2272 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 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Tag = 0x020b | Length = 8 | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | Mask = 0 | Destination Point Code | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 Network Appearance: 2281 The optional Network Appearance parameter field identifies the SS7 2282 network context for the Routing Key, and has the same format as in 2283 the DATA message (See Section 3.3.1) with the exception that it 2284 does not have to be the first parameter in the message. If the 2285 Network Appearance is not specified and the Routing Key applies to 2286 all Network Appearances, then this Routing Key MUST be the only 2287 one registered for the association: that is, Routing Context is 2288 implied and DATA and SSNM messages are discriminated on Network 2289 Appearance rather than Routing Context. Where Network Appearance 2290 is not specified and there is only one Network Appearance, then 2291 Network Appearance is implied. Its format is: 2293 0 1 2 3 2294 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 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | Tag = 0x0200 | Length = 8 | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Network Appearance | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 Service Indicators (SI): n X 8-bit integers 2303 The optional SI [7,8] field contains one or more Service 2304 Indicators from the values as described in the MTP3-User Identity 2305 field of the DUPU message. The absence of the SI parameter in the 2306 Routing Key indicates the use of any SI value, excluding of course 2307 MTP management. Where an SI parameter does not contain a multiple 2308 of four SIs, the parameter is padded out to 32-byte alignment. 2310 The SI format is: 2312 0 1 2 3 2313 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 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | Tag = 0x020c | Length | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | SI #1 | SI #2 | SI #3 | SI #4 | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 / ... / 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | SI #n | 0 Padding, if necessary | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 OPC List: 2326 The Originating Point Code List parameter contains one or more SS7 2327 OPC entries, and its format is the same as the Destination Point 2328 Code parameter. The absence of the OPC List parameter in the 2329 Routing Key indicates the use of any OPC value, 2331 0 1 2 3 2332 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 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Tag = 0x020e | Length | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Mask | Origination Point Code #1 | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Mask | Origination Point Code #2 | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 / ... / 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Mask | Origination Point Code #n | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 3.6.2 Registration Response (REG RSP) 2347 The REG RSP message is used as a response to the REG REQ message from 2348 a remote M3UA peer. It contains indications of success/failure for 2349 registration requests and returns a unique Routing Context value for 2350 successful registration requests, to be used in subsequent M3UA 2351 Traffic Management protocol. 2353 The REG RSP message contains the following parameters: 2355 Registration Result Mandatory 2357 One or more Registration Result parameters MUST be included. The 2358 format for the REG RSP message is as follows: 2360 0 1 2 3 2361 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 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | Tag = 0x0208 | Length | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | Registration Result 1 | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 \ \ 2368 / ... / 2369 \ \ 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2371 | Tag = 0x0208 | Length | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Registration Result n | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 Registration Results: 2378 The Registration Result parameter contains the registration result 2379 for a single Routing Key in an REG REQ message. The number of 2380 results in a single REG RSP message MUST be anywhere from one to 2381 the total number of number of Routing Key parameters found in the 2382 corresponding REG REQ message. Where multiple REG RSP messages 2383 are used in reply to REG REQ message, a specific result SHOULD be 2384 in only one REG RSP message. The format of each result is as 2385 follows: 2387 0 1 2 3 2388 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 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Tag = 0x020a | Length = 8 | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Local-RK-Identifier value | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | Tag = 0x0212 | Length = 8 | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | Registration Status | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Tag = 0x0006 | Length = 8 | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | Routing Context | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 Local-RK-Identifier: 32-bit integer 2405 The Local-RK-Identifier contains the same value as found in the 2406 matching Routing Key parameter found in the REG REQ message (See 2407 Section 3.6.1). 2409 Registration Status: 32-bit integer 2411 The Registration Result Status field indicates the success or the 2412 reason for failure of a registration request. 2414 Its values may be: 2416 0 Successfully Registered 2417 1 Error - Unknown 2418 2 Error - Invalid DPC 2419 3 Error - Invalid Network Appearance 2420 4 Error - Invalid Routing Key 2421 5 Error - Permission Denied 2422 6 Error - Cannot Support Unique Routing 2423 7 Error - Routing Key not Currently Provisioned 2424 8 Error - Insufficient Resources 2425 9 Error - Unsupported RK parameter Field 2426 10 Error - Unsupported/Invalid Traffic Handling Mode 2427 11 Error - Routing Key Change Refused 2428 12 Error - Routing Key Already Registered 2430 Routing Context: 32-bit integer 2432 The Routing Context field contains the Routing Context value for 2433 the associated Routing Key if the registration was successful. It 2434 is set to "0" if the registration was not successful. 2436 3.6.3 Deregistration Request (DEREG REQ) 2438 The DEREG REQ message is sent by an ASP to indicate to a remote M3UA 2439 peer that it wishes to deregister a given Routing Key. Typically, an 2440 ASP would send this message to an SGP, and expects to receive a DEREG 2441 RSP message in return with the associated Routing Context value. 2443 The DEREG REQ message contains the following parameters: 2445 Routing Context Mandatory 2447 The format for the DEREG REQ message is as follows: 2449 0 1 2 3 2450 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 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | Tag = 0x0006 | Length | 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 \ \ 2455 / Routing Context / 2456 \ \ 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 Routing Context: n X 32-bit integers 2461 The Routing Context parameter contains (a list of) integers 2462 indexing the Application Server traffic that the sending ASP is 2463 currently registered to receive from the SGP but now wishes to 2464 deregister. 2466 3.6.4 Deregistration Response (DEREG RSP) 2468 The DEREG RSP message is used as a response to the DEREG REQ message 2469 from a remote M3UA peer. 2471 The DEREG RSP message contains the following parameters: 2473 Deregistration Result Mandatory 2475 One or more Deregistration Result parameters MUST be included. The 2476 format for the DEREG RSP message is as follows: 2478 0 1 2 3 2479 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 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Tag = 0x0209 | Length | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | Deregistration Result 1 | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 \ \ 2486 / ... / 2487 \ \ 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | Tag = 0x0209 | Length | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | Deregistration Result n | 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 Deregistration Results: 2496 The Deregistration Result parameter contains the deregistration 2497 status for a single Routing Context in a DEREG REQ message. The 2498 number of results in a single DEREG RSP message MAY be anywhere 2499 from one to the total number of number of Routing Context values 2500 found in the corresponding DEREG REQ message. 2502 Where multiple DEREG RSP messages are used in reply to DEREG REQ 2503 message, a specific result SHOULD be in only one DEREG RSP 2504 message. The format of each result is as follows: 2506 0 1 2 3 2507 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 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Tag = 0x0006 | Length = 8 | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | Routing Context | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 | Tag = 0x0213 | Length = 8 | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | Deregistration Status | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 Routing Context: 32-bit integer 2520 The Routing Context field contains the Routing Context value of 2521 the matching Routing Key to deregister, as found in the DEREG REQ 2522 message. 2524 Deregistration Status: 32-bit integer 2525 The Deregistration Result Status field indicates the success or 2526 the reason for failure of the deregistration. 2528 Its values may be: 2530 0 Successfully Deregistered 2531 1 Error - Unknown 2532 2 Error - Invalid Routing Context 2533 3 Error - Permission Denied 2534 4 Error - Not Registered 2535 5 Error - ASP Currently Active for Routing Context 2537 3.7 ASP Traffic Maintenance (ASPTM) Messages 2539 3.7.1 ASP Active 2541 The ASP Active message is sent by an ASP to indicate to a remote M3UA 2542 peer that it is ready to process signalling traffic for a particular 2543 Application Server. The ASP Active message affects only the ASP 2544 state for the Routing Keys identified by the Routing Contexts, if 2545 present. 2547 The ASP Active message contains the following parameters: 2549 Traffic Mode Type Optional 2550 Routing Context Optional 2551 INFO String Optional 2553 The format for the ASP Active message is as follows: 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Tag = 0x000b | Length = 8 | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Traffic Mode Type | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Tag = 0x0006 | Length | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 \ \ 2565 / Routing Context / 2566 \ \ 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Tag = 0x0004 | Length | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 \ \ 2571 / INFO String / 2572 \ \ 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 Traffic Mode Type: 32-bit (unsigned integer) 2576 The Traffic Mode Type parameter identifies the traffic mode of 2577 operation of the ASP within an AS. The valid values for Traffic 2578 Mode Type are shown in the following table: 2580 1 Override 2581 2 Loadshare 2582 3 Broadcast 2584 Within a particular Routing Context, Override, Loadshare and 2585 Broadcast SHOULD NOT be mixed. The Override value indicates that 2586 the ASP is operating in Override mode, and the ASP takes over all 2587 traffic in an Application Server (i.e., primary/backup operation), 2588 overriding any currently active ASPs in the AS. In Loadshare 2589 mode, the ASP will share in the traffic distribution with any 2590 other currently active ASPs. In Broadcast mode, the ASP will 2591 receive the same messages as any other currently active ASP. 2593 Routing Context: n X 32-bit integers 2595 The optional Routing Context parameter contains (a list of) 2596 integers indexing the Application Server traffic that the sending 2597 ASP is configured/registered to receive. 2599 There is one-to-one relationship between an index entry and an SGP 2600 Routing Key or AS Name. Because an AS can only appear in one 2601 Network Appearance, the Network Appearance parameter is not 2602 required in the ASP Active message. 2604 An Application Server Process may be configured to process traffic 2605 for more than one logical Application Server. From the 2606 perspective of an ASP, a Routing Context defines a range of 2607 signalling traffic that the ASP is currently configured to receive 2608 from the SGP. For example, an ASP could be configured to support 2609 signalling for multiple MTP3-Users, identified by separate SS7 2610 DPC/OPC/SI ranges. 2612 The format and description of the optional INFO String parameter is 2613 the same as for the DUNA message (See Section 3.4.1). 2615 3.7.2 ASP Active Acknowledgement (ASP Active Ack) 2617 The ASP Active Ack message is used to acknowledge an ASP Active 2618 message received from a remote M3UA peer. 2620 The ASP Active Ack message contains the following parameters: 2622 Traffic Mode Type Optional 2623 Routing Context Optional 2624 INFO String Optional 2626 The format for the ASP Active Ack message is as follows: 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Tag = 0x000b | Length = 8 | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Traffic Mode Type | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Tag = 0x0006 | Length | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 \ \ 2638 / Routing Context / 2639 \ \ 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Tag = 0x0004 | Length | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 \ \ 2644 / INFO String / 2645 \ \ 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 The format and description of the optional INFO String parameter is 2649 the same as for the DUNA message (See Section 3.4.1). 2651 The INFO String in an ASP Active Ack message is independent from the 2652 INFO String in the ASP Active message (i.e., it does not have to echo 2653 back the INFO String received). 2655 The format of the Traffic Mode Type and Routing Context parameters is 2656 the same as for the ASP Active message. (See Section 3.7.1). 2658 3.7.3 ASP Inactive 2660 The ASP Inactive message is sent by an ASP to indicate to a remote 2661 M3UA peer that it is no longer an active ASP to be used from within a 2662 list of ASPs. The ASP Inactive message affects only the ASP state in 2663 the Routing Keys identified by the Routing Contexts, if present. 2665 The ASP Inactive message contains the following parameters: 2666 Routing Context Optional 2667 INFO String Optional 2669 The format for the ASP Inactive message parameters is as follows: 2671 0 1 2 3 2672 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 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Tag = 0x0006 | Length | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 \ \ 2677 / Routing Context / 2678 \ \ 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | Tag = 0x0004 | Length | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 \ \ 2683 / INFO String / 2684 \ \ 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 The format and description of the optional Routing Context and INFO 2688 String parameters is the same as for the ASP Active message (See 2689 Section 3.5.5.) 2691 3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack) 2693 The ASP Inactive Ack message is used to acknowledge an ASP Inactive 2694 message received from a remote M3UA peer. 2696 The ASP Inactive Ack message contains the following parameters: 2698 Routing Context Optional 2699 INFO String Optional 2701 The format for the ASP Inactive Ack message is as follows: 2703 0 1 2 3 2704 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 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 | Tag = 0x0006 | Length | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 \ \ 2709 / Routing Context / 2710 \ \ 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | Tag = 0x0004 | Length | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 \ \ 2715 / INFO String / 2716 \ \ 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 The format and description of the optional INFO String parameter is 2720 the same as for the DUNA message (See Section 3.4.1.) 2722 The INFO String in an ASP Inactive Ack message is independent from 2723 the INFO String in the ASP Inactive message (i.e., it does not have 2724 to echo back the INFO String received). 2726 The format of the Routing Context parameter is the same as for the 2727 ASP Inactive message. (See Section 3.7.3). 2729 3.8 Management (MGMT) Messages 2731 3.8.1 Error 2733 The Error message is used to notify a peer of an error event 2734 associated with an incoming message. For example, the message type 2735 might be unexpected given the current state, or a parameter value 2736 might be invalid. Error messages MUST NOT be generated in response to 2737 other Error messages. 2739 The Error message contains the following parameters: 2741 Error Code Mandatory 2742 Routing Context Mandatory* 2743 Network Appearance Mandatory* 2744 Affected Point Code Mandatory* 2745 Diagnostic Information Conditional 2747 (*) Only mandatory for specific Error Codes 2749 The format for the Error message is as follows: 2751 0 1 2 3 2752 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 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | Tag = 0x000c | Length = 8 | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | Error Code | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | Tag = 0x0006 | Length | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 \ \ 2761 / Routing Context / 2762 \ \ 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | Tag - 0x0012 | Length | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Mask | Affected Point Code 1 | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 \ \ 2769 / ... / 2770 \ \ 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | Mask | Affected Point Code n | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Tag = 0x0200 | Length = 8 | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | Network Appearance | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Tag = 0x0007 | Length | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 \ \ 2781 / Diagnostic Information / 2782 \ \ 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 Error Code: 32-bits (unsigned integer) 2787 The Error Code parameter indicates the reason for the Error 2788 Message. The Error parameter value can be one of the following 2789 values: 2791 0x01 Invalid Version 2792 0x02 Not Used in M3UA 2793 0x03 Unsupported Message Class 2794 0x04 Unsupported Message Type 2795 0x05 Unsupported Traffic Mode Type 2796 0x06 Unexpected Message 2798 0x07 Protocol Error 2799 0x08 Not used in M3UA 2800 0x09 Invalid Stream Identifier 2801 0x0a Not used in M3UA 2802 0x0b Not used in M3UA 2803 0x0c Not used in M3UA 2804 0x0d Refused - Management Blocking 2805 0x0e ASP Identifier Required 2806 0x0f Invalid ASP Identifier 2807 0x10 Not Used in M3UA 2808 0x11 Invalid Parameter Value 2809 0x12 Parameter Field Error 2810 0x13 Unexpected Parameter 2811 0x14 Destination Status Unknown 2812 0x15 Invalid Network Appearance 2813 0x16 Missing Parameter 2814 0x17 Not Used in M3UA 2815 0x18 Not Used in M3UA 2816 0x19 Invalid Routing Context 2817 0x1a No Configured AS for ASP 2819 The "Invalid Version" error is sent if a message with an unsupported 2820 version is received, the receiving end responds with an Error message, 2821 indicating the version the receiving node supports and notifies layer 2822 management. 2824 The "Unsupported Message Class" error is sent if a message with an 2825 unexpected or unsupported Message Class is received. For this error, 2826 the Diagnostic Information parameter MUST be included with the first 2827 40 octets of the offending message. 2829 The "Unsupported Message Type" error is sent if a message with an 2830 unexpected or unsupported Message Type is received. For this error, 2831 the Diagnostic Information parameter MUST be included with the first 2832 40 octets of the offending message. 2834 The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP 2835 sends an ASP Active message with an unsupported Traffic Mode Type or 2836 a Traffic Mode Type that is inconsistent with the presently 2837 configured mode for the Application Server. An example would be a 2838 case in which the SGP did not support loadsharing. 2840 The "Unexpected Message" error MAY be sent if a defined and 2841 recognized message is received that is not expected in the current 2842 state (in some cases the ASP may optionally silently discard the 2843 message and not send an Error message). For example, silent discard 2844 is used by an ASP if it received a DATA message from an SGP while it 2845 was in the ASP-INACTIVE state. If the Unexpected message contained 2846 Routing Context(s), the Routing Context(s) SHOULD be included in the 2847 Error message. 2849 The "Protocol Error" error is sent for any protocol anomaly (i.e., 2850 reception of a parameter that is syntactically correct but unexpected 2851 in the current situation. 2853 The "Invalid Stream Identifier" error is sent if a message is 2854 received on an unexpected SCTP stream (e.g., a Management message was 2855 received on a stream other than "0"). 2857 The "Refused - Management Blocking" error is sent when an ASP Up or 2858 ASP Active message is received and the request is refused for 2859 management reasons (e.g., management lockout"). If this error is in 2860 response to an ASP Active message, the Routing Context(s) in the ASP 2861 Active message SHOULD be included in the Error message. 2863 The "ASP Identifier Required" is sent by a SGP in response to an ASP 2864 Up message which does not contain an ASP Identifier parameter when 2865 the SGP requires one. The ASP SHOULD resend the ASP Up message with 2866 an ASP Identifier. 2868 The "Invalid ASP Identifier" is sent by an SGP in response to an ASP 2869 Up message with an invalid (i.e., non-unique) ASP Identifier. 2871 The "Invalid Parameter Value " error is sent if a message is received 2872 with an invalid parameter value (e.g., a DUPU message was received 2873 with a Mask value other than "0". 2875 The "Parameter Field Error" would be sent if a message is received 2876 with a parameter having a wrong length field. 2878 The "Unexpected Parameter" error would be sent if a message contains 2879 an invalid parameter. 2881 The "Destination Status Unknown" Error MAY be sent if a DAUD is 2882 received at an SG enquiring of the availability/congestion status of 2883 a destination, and the SG does not wish to provide the status (e.g., 2884 the sender is not authorized to know the status). For this error, 2885 the invalid or unauthorized Point Code(s) MUST be included along with 2886 the Network Appearance and/or Routing Context associated with the 2887 Point Code(s). 2889 The "Invalid Network Appearance" error is sent by a SGP if an ASP 2890 sends a message with an invalid (unconfigured) Network Appearance 2891 value. For this error, the invalid (unconfigured) Network Appearance 2892 MUST be included in the Network Appearance parameter. 2894 The "Missing Parameter" error would be sent if a mandatory parameter 2895 were not included in a message. This error is also sent if a 2896 conditional parameter is not included in the message but is required 2897 in the context of the received message. 2899 The "Invalid Routing Context" error is sent if a message is received 2900 from a peer with an invalid (unconfigured) Routing Context value. For 2901 this error, the invalid Routing Context(s) MUST be included in the 2902 Error message. 2904 The "No Configured AS for ASP" error is sent if a message is received 2905 from a peer without a Routing Context parameter and it is not known by 2906 configuration data which Application Servers are referenced. 2908 Diagnostic Information: variable length 2910 When included, the optional Diagnostic information can be any 2911 information germane to the error condition, to assist in 2912 identification of the error condition. The Diagnostic information 2913 SHOULD contain the offending message. The Diagnostic Information 2914 parameter with a zero length parameter is not considered as an 2915 error (this means that the Length field in the TLV will be set to 2916 4). 2918 3.8.2 Notify 2920 The Notify message used to provide an autonomous indication of M3UA 2921 events to an M3UA peer. 2923 The Notify message contains the following parameters: 2925 Status Mandatory 2926 ASP Identifier Conditional 2927 Routing Context Optional 2928 INFO String Optional 2930 The format for the Notify message is as follows: 2932 0 1 2 3 2933 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 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | Tag = 0x000d | Length = 8 | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Status Type | Status Information | 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | Tag = 0x0011 | Length = 8 | 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 | ASP Identifier | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 | Tag = 0x0006 | Length | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 \ \ 2946 / Routing Context / 2947 \ \ 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 | Tag = 0x0004 | Length | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 \ \ 2952 / INFO String / 2953 \ \ 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 Status Type: 16-bits (unsigned integer) 2958 The Status Type parameter identifies the type of the Notify 2959 message. The following are the valid Status Type values: 2961 1 Application Server State Change (AS-State_Change) 2962 2 Other 2964 Status Information: 16-bits (unsigned integer) 2966 The Status Information parameter contains more detailed 2967 information for the notification, based on the value of the Status 2968 Type. If the Status Type is AS-State_Change the following Status 2969 Information values are used: 2971 1 reserved 2972 2 Application Server Inactive (AS-INACTIVE) 2973 3 Application Server Active (AS-ACTIVE) 2974 4 Application Server Pending (AS-PENDING) 2976 These notifications are sent from an SGP to an ASP upon a change 2977 in status of a particular Application Server. The value reflects 2978 the new state of the Application Server. 2980 If the Status Type is Other, then the following Status Information 2981 values are defined: 2983 1 Insufficient ASP Resources Active in AS 2984 2 Alternate ASP Active 2985 3 ASP Failure 2987 These notifications are not based on the SGP reporting the state 2988 change of an ASP or AS. In the Insufficient ASP Resources case, 2989 the SGP is indicating to an ASP_INACTIVE ASP in the AS that 2990 another ASP is required to handle the load of the AS (Loadsharing 2991 or Broadcast mode). For the Alternate ASP Active case, an ASP is 2992 informed when an alternate ASP transitions to the ASP-ACTIVE state 2993 in Override mode. The ASP Identifier (if available) of the 2994 Alternate ASP MUST be placed in the message. For the ASP Failure 2995 case, the SGP is indicating to ASP(s) in the AS that one of the 2996 ASPs has failed. The ASP Identifier (if available) of the failed 2997 ASP MUST be placed in the message. 2999 The format and description of the conditional ASP Identifier is the 3000 same as for the ASP Up message (See Section 3.5.1). The format and 3001 description of the Routing Context and Info String parameters is the 3002 same as for the ASP Active message (See Section 3.7.1) 3004 4. Procedures 3006 The M3UA layer needs to respond to various local primitives it 3007 receives from other layers as well as the messages that it receives 3008 from the peer M3UA layer. This section describes the M3UA procedures 3009 in response to these events. 3011 4.1 Procedures to Support the M3UA-User 3013 4.1.1 Receipt of Primitives from the M3UA-User 3015 On receiving an MTP-TRANSFER request primitive from an upper layer at 3016 an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA 3017 layer sends a corresponding DATA message (see Section 3) to its M3UA 3018 peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER 3019 indication primitive to the upper layer. 3021 The M3UA message distribution function (see Section 1.4.2.1) 3022 determines the Application Server (AS) based on comparing the 3023 information in the MTP-TRANSFER request primitive with a provisioned 3024 Routing Key. 3026 From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE 3027 state is selected and a DATA message is constructed and issued on the 3028 corresponding SCTP association. If more than one ASP is in the ASP- 3029 ACTIVE state (i.e., traffic is to be loadshared across more than one 3030 ASP), one of the ASPs in the ASP-ACTIVE state is selected from the 3031 list. If the ASPs are in Broadcast Mode, all active ASPs will be 3032 selected and the message sent to each of the active ASPs. The 3033 selection algorithm is implementation dependent but could, for 3034 example, be round robin or based on the SLS or ISUP CIC. The 3035 appropriate selection algorithm must be chosen carefully as it is 3036 dependent on application assumptions and understanding of the degree 3037 of state coordination between the ASP-ACTIVE ASPs in the AS. 3039 In addition, the message needs to be sent on the appropriate SCTP 3040 stream, again taking care to meet the message sequencing needs of the 3041 signalling application. DATA messages MUST be sent on an SCTP stream 3042 other than stream '0'. 3044 When there is no Routing Key match, or only a partial match, for an 3045 incoming SS7 message, a default treatment MAY be specified. Possible 3046 solutions are to provide a default Application Server at the SGP that 3047 directs all unallocated traffic to a (set of) default ASP(s), or to 3048 drop the message and provide a notification to Layer Management in an 3049 M-ERROR indication primitive. The treatment of unallocated traffic 3050 is implementation dependent. 3052 4.2 Receipt of Primitives from the Layer Management 3054 On receiving primitives from the local Layer Management, the M3UA 3055 layer will take the requested action and provide an appropriate 3056 response primitive to Layer Management. 3058 An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP 3059 or IPSP will initiate the establishment of an SCTP association. The 3060 M3UA layer will attempt to establish an SCTP association with the 3061 remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local 3062 SCTP layer. 3064 When an SCTP association has been successfully established, the SCTP 3065 will send an SCTP-COMMUNICATION_UP notification primitive to the 3066 local M3UA layer. At the SGP or IPSP that initiated the request, the 3067 M3UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer 3068 Management when the association setup is complete. At the peer M3UA 3070 layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer 3071 Management upon successful completion of an incoming SCTP association 3072 setup. 3074 An M-SCTP_RELEASE request primitive from Layer Management initiates 3075 the teardown of an SCTP association. The M3UA layer accomplishes a 3076 graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN 3077 primitive to the SCTP layer. 3079 When the graceful shutdown of the SCTP association has been 3080 accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE 3081 notification primitive to the local M3UA layer. At the M3UA Layer 3082 that initiated the request, the M3UA layer will send an M- 3083 SCTP_RELEASE confirm primitive to Layer Management when the 3084 association shutdown is complete. At the peer M3UA Layer, an M- 3085 SCTP_RELEASE indication primitive is sent to Layer Management upon 3086 abort or successful shutdown of an SCTP association. 3088 An M-SCTP_STATUS request primitive supports a Layer Management query 3089 of the local status of a particular SCTP association. The M3UA layer 3090 simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS 3091 primitive to the SCTP layer. When the SCTP responds, the M3UA layer 3092 maps the association status information to an M-SCTP_STATUS confirm 3093 primitive. No peer protocol is invoked. 3095 Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive 3096 mappings can be described for the various other SCTP Upper Layer 3097 primitives in RFC2960 [17] such as INITIALIZE, SET PRIMARY, CHANGE 3098 HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, 3099 SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND 3100 NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer 3101 primitives (and Status as well) can be considered for modeling 3102 purposes as a Layer Management interaction directly with the SCTP 3103 Layer. 3105 M-NOTIFY indication and M-ERROR indication primitives indicate to 3106 Layer Management the notification or error information contained in a 3107 received M3UA Notify or Error message respectively. These 3108 indications can also be generated based on local M3UA events. 3110 An M-ASP_STATUS request primitive supports a Layer Management query 3111 of the status of a particular local or remote ASP. The M3UA layer 3112 responds with the status in an M-ASP_STATUS confirm primitive. No 3113 M3UA peer protocol is invoked. 3115 An M-AS_STATUS request supports a Layer Management query of the 3116 status of a particular AS. The M3UA responds with an M-AS_STATUS 3117 confirm primitive. No M3UA peer protocol is invoked. 3119 M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M- 3120 ASP_INACTIVE request primitives allow Layer Management at an ASP to 3121 initiate state changes. Upon successful completion, a corresponding 3122 confirm primitive is provided by the M3UA layer to Layer Management. 3123 If an invocation is unsuccessful, an Error indication primitive is 3124 provided in the primitive. These requests result in outgoing ASP Up, 3125 ASP Down, ASP Active and ASP Inactive messages to the remote M3UA 3126 peer at an SGP or IPSP. 3128 4.2.1 Receipt of M3UA Peer Management Messages 3130 Upon successful state changes resulting from reception of ASP Up, ASP 3131 Down, ASP Active and ASP Inactive messages from a peer M3UA, the M3UA 3132 layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and 3133 M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication 3134 primitives to the local Layer Management. 3136 M-NOTIFY indication and M-ERROR indication primitives indicate to 3137 Layer Management the notification or error information contained in a 3138 received M3UA Notify or Error message. These indications can also be 3139 generated based on local M3UA events. 3141 All non-Transfer and non-SSNM, messages, except BEAT and BEAT Ack, 3142 SHOULD be sent with sequenced delivery to ensure ordering. ASPTM 3143 messages MAY be sent on one of the streams used to carry the data 3144 traffic related to the Routing Context(s), to minimize possible 3145 message loss. BEAT and BEAT Ack messages MAY be sent using out-of- 3146 order delivery, and MAY be sent on any stream. 3148 4.3 AS and ASP/IPSP State Maintenance 3150 The M3UA layer on the SGP maintains the state of each remote ASP, in 3151 each Application Server that the ASP is configured to receive 3152 traffic, as input to the M3UA message distribution function. 3153 Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA 3154 layer in an IPSP maintains the state of remote IPSPs. 3156 Two IPSP models are defined as follows: 3158 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM 3159 and ASPSM messages are needed to change the IPSP states. This means 3160 that a set of request from one end and acknowledgement from the 3161 other will be enough. The RK must define both sides of the traffic 3162 flow. Each exchange of ASPTM or ASPSM messages can be initiated by 3163 either IPSP. For this exchange, the initiating IPSP follows the 3164 procedures described in section 4.3.1. 3166 2- IPSP Double Exchange (DE) model. A double exchange of ASPTM and 3167 ASPSM messages are normally needed (ASPSM single exchange is 3168 optional as a simplification). Each exchange of ASPTM or ASPSM 3169 messages can be initiated by either IPSP. The RKs define the 3170 traffic to be directed to the peer as in the AS-SG model. Therefore 3171 two different RKs are usually used, one installed on each peer. 3173 When using double exchanges for ASPSM messages, the management of 3174 the connection in the two directions are considered independent. 3175 This means that connections from IPSP-A to IPSP-B is handled in an 3176 independent way that connection from IPSP-B to IPSP-A. Therefore it 3177 could happen that only one of the two directions are activated or 3178 closed, while the other remain in the same state as it was. 3180 When using single exchange of ASPSM, what is seen as a 3181 simplification, it is only the activation phase (ASPTM messages) 3182 what is independent for each of the two directions. In this case it 3183 could happen the sending the ASPSM from IPSP-A or IPSP-B will have 3184 an effect in the whole communication as it is defined in the 3185 standard SG-AS communication. 3187 Because of these differences, there should be an agreements on the 3188 way ASPSM messages are being handled before starting DE-IPSP 3189 communication. 3191 In order to ensure interoperability, an M3UA implementation supporting 3192 IPSP communication MUST support IPSP SE model and MAY implement IPSP 3193 DE model. 3195 In section 4.3.1 ASP/IPSP States are described. 3197 In section 4.3.2, only the SGP-ASP scenario is described. All of the 3198 procedures referring to an AS served by ASPs are also applicable to 3199 ASes served by IPSPs. 3201 In section 4.3.3, only the Management procedures for the SGP-ASP 3202 scenario are described. The corresponding Management procedures for 3203 IPSPs are directly inferred. 3205 The remaining sections contain specific IPSP Considerations sub- 3206 sections. 3208 4.3.1 ASP/IPSP States 3210 The state of each remote ASP/IPSP, in each AS that it is configured to 3211 operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer 3212 IPSP, respectively). The state of a particular ASP/IPSP in a 3213 particular AS changes due to events. The events include: 3215 * Reception of messages from the peer M3UA layer at the ASP/IPSP; 3216 * Reception of some messages from the peer M3UA layer at other 3217 ASPs/IPSPs in the AS (e.g., ASP Active message indicating 3218 "Override"); 3219 * Reception of indications from the SCTP layer; or 3220 * Local Management intervention. 3222 The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3. 3223 The possible states of an ASP/D-IPSP/C-IPSP are: 3225 ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable and/or 3226 the related SCTP association is down. Initially all ASPs/IPSPs will 3227 be in this state. An ASP/IPSP in this state SHOULD NOT be sent any 3228 M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error 3229 messages. 3231 ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and 3232 the related SCTP association is up) but application traffic is 3233 stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or 3234 SSNM messages for the AS for which the ASP/IPSP is inactive. 3236 ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and 3237 application traffic is active (for a particular Routing Context or 3238 set of Routing Contexts). 3240 SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication 3241 Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The 3242 local SCTP layer will send this indication when it detects the loss 3243 of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood 3244 as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 3245 notification from the SCTP layer. 3247 SCTP RI: The local SCTP layer's Restart indication to the upper layer 3248 protocol (M3UA) on an SG. The local SCTP will send this indication 3249 when it detects a restart from the peer SCTP layer. 3251 Figure 3: ASP State Transition Diagram, per AS 3253 +--------------+ 3254 | | 3255 +----------------------| ASP-ACTIVE | 3256 | Other ASP/ +-------| | 3257 | IPSP in AS | +--------------+ 3258 | Overrides | ^ | 3259 | | ASPAC/ | | ASPIA/ 3260 | |[ASPAC-Ack]| | [ASPIA-Ack] 3261 | | | v 3262 | | +--------------+ 3263 | | | | 3264 | +------>| ASP-INACTIVE | 3265 | | | 3266 | +--------------+ 3267 | ^ | 3268 ASPDN/ | | | ASPDN / 3269 [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] 3270 SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ 3271 SCTP RI | | | SCTP RI 3272 | | v 3273 | +--------------+ 3274 | | | 3275 +--------------------->| ASP-DOWN | 3276 | | 3277 +--------------+ 3279 The transitions are depicted as a result of the reception of ASP*M 3280 messages or other events. In some of the transitions there are some 3281 messages in brackets. They mean that for a given node the state 3282 transition will be different depending on its role: whether or not it 3283 is generating the ASP*M request message (i.e. ASPUP, ASPAC, ASPIA or 3284 ASPDN) or simply receiving it. In a peer-to-peer based architecture 3285 (IPSP), this role may change between the peers. 3287 The transitions not in brackets are valid to track the states of ASPs 3288 and IPSPs that send an ASP*M request message at the peer node. 3290 The transition in brackets may be used in an ASP or in the IPSP that 3291 receives an ASP*M request to track the peer SGP/IPSP states 3292 respectively. There may be an SGP per AS state machine at ASPs. 3294 Then the transitions in brackets can be used for the IPSP DE model 3295 communication (DE-IPSPs) and are related to the special cases when 3296 just one ASP*M messages exchange is needed, as follows: 3298 - ASPSM messages. When exchanging ASPSM messages using only a single 3299 exchange (only one request and one acknowledgment). . 3300 Example: (see section 5.6.2) whenever a DE-IPSP is taking the 3301 leading role to start communication to a peer DE-IPSP, it sends ASP 3302 Up message to the peer DE-IPSP. The peer MAY consider the initiating 3303 DE-IPSPs as being in ASP-INACTIVE state, as it already sent a 3304 message, and answer back with ASP Up Ack. Upon the reception of this 3305 answer by the initiating DE-IPSP it alsoMAY consider the peer as 3306 being in ASP-INACTIVE state since it did respond. Therefore a second 3307 ASP Up message exchange to be started by the peer DE-IPSP could be 3308 avoided. In this case the reception of ASP Up Ack will turn into a 3309 state change. 3311 - ASPTM messages. When sending ASPTM messages to activate/deactivate 3312 all the traffic independently of routing keys by not specifying any 3313 RC, a single exchange could be sufficient. 3315 4.3.2 AS States 3317 The state of the AS is maintained in the M3UA layer on the SGPs. The 3318 state of an AS changes due to events. These events include: 3319 * ASP state transitions 3320 * Recovery timer triggers 3322 The possible states of an AS are: 3324 AS-DOWN: The Application Server is unavailable. This state implies 3325 that all related ASPs are in ASP-DOWN state for this AS. Initially the 3326 AS will be in this state. An Application Server is in the AS-DOWN 3327 state when it is removed from a configuration. 3329 AS-INACTIVE: The Application Server is available but no application 3330 traffic is active. One or more related ASPs are in ASP-INACTIVE state 3331 and/or the number of related ASPs in ASP-ACTIVE state has not reached 3332 n (n is the number of ASPs required to be in ASP-ACTIVE state before 3333 AS can transition to AS-ACTIVE, n = 1 for Override Traffic Mode) for 3334 this AS. The recovery timer T(r) is not running or has expired. 3336 AS-ACTIVE: The Application Server is available and application traffic 3337 is active. The AS moves to this state after being in AS-INACTIVE and 3338 getting n ASPs (n is the number of ASPs required to be in ASP-ACTIVE 3339 state before AS can transition to AS-ACTIVE, n = 1 for Override 3340 Traffic Mode) in ASP-ACTIVE state or, after reaching AS-ACTIVE and 3341 keeping one or more ASPs in ASP-ACTIVE state. 3342 When it is considered that one ASP is enough to handle traffic (smooth 3343 start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the 3344 first ASP moves to the ASP-ACTIVE state. 3346 AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP DOWN 3347 and it was the last remaining active ASP in the AS. A recovery timer 3348 T(r) SHOULD be started and all incoming signalling messages SHOULD be 3349 queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, 3350 the AS is moved to the AS-ACTIVE state and all the queued messages 3351 will be sent to the ASP. 3353 If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no 3354 alternative, the SGP may stop queuing messages and discards all 3355 previously queued messages. The AS will move to the AS-INACTIVE state 3356 if at least one ASP is in ASP-INACTIVE, otherwise it will move to AS- 3357 DOWN state. 3359 Figure 4 shows an example AS state machine for the case where the 3360 AS/ASP data is preconfigured and an n+k redundancy model. In other 3361 cases where the AS/ASP configuration data is created dynamically, 3362 there would be differences in the state machine, especially at 3363 creation of the AS. 3365 Figure 4: AS State Transition Diagram 3367 +----------+ IA2AC +-------------+ 3368 | AS- |---------------------------->| AS- | 3369 | INACTIVE | | ACTIVE | 3370 | |<----------- | | 3371 +----------+ \ +-------------+ 3372 ^ | \ ^ | 3373 | | IA2DN \ PN2IA | | AC2PN 3374 | | \ | | 3375 DN2IA | | \ PN2AC | | 3376 | v \ | v 3377 +----------+ \ +-------------+ 3378 | | ----------| | 3379 | AS-DOWN | | AS-PENDING | 3380 | | PN2DN | (queueing) | 3381 | |<----------------------------| | 3382 +----------+ +-------------+ 3384 DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. 3386 IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that the 3387 all the ASPs are in ASP-DOWN state. 3389 IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the ASP- 3390 ACTIVE state to be n. 3391 In a special case of smooth start, this transition MAY be done when 3392 the first ASP moves to ASP-ACTIVE state. 3394 AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- 3395 DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1. 3397 PN2AC: One ASP moves to ASP-ACTIVE. 3399 PN2IA: T(r) Expiry, an ASP is in ASP-INACTIVE state but no ASPs are in 3400 ASP-ACTIVE state. 3402 PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state. 3404 An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state 3405 during the start-up phase (except for smooth start). Once the traffic 3406 is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns to 3407 another state different to ASP-ACTIVE, avoiding unnecessary traffic 3408 disturbances as long as there are ASPs available, in the assumption 3409 that the system will not always be exposed to the maximum load. 3411 There are other cases where the AS/ASP configuration data is created 3412 dynamically. In those cases there would be differences in the state 3413 machine, especially at creation of the AS. For example, where the 3414 AS/ASP configuration data is not created until Registration of the 3415 first ASP, the AS-INACTIVE state is entered directly upon the nth 3416 successful REG REQ from an ASP belonging to that AS. Another example 3417 is where the AS/ASP configuration data is not created until the nth 3418 ASP successfully enters the ASP-ACTIVE state. In this latter case the 3419 AS-ACTIVE state is entered directly. 3421 4.3.3 M3UA Management Procedures for Primitives 3423 Before the establishment of an SCTP association the ASP state at both 3424 the SGP and ASP is assumed to be in the state ASP-DOWN. 3426 Once the SCTP association is established (see Section 4.2) and 3427 assuming that the local M3UA-User is ready, the local M3UA ASP 3428 Maintenance (ASPM) function will initiate the relevant procedures, 3429 using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey 3430 the ASP state to the SGP (see Section 4.3.4). 3432 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or 3433 SCTP-RESTART indication primitive from the underlying SCTP layer, it 3434 will inform the Layer Management by invoking the M-SCTP_STATUS 3435 indication primitive. The state of the ASP will be moved to ASP-DOWN. 3436 At an ASP, the MTP3-User will be informed of the unavailability of 3437 any affected SS7 destinations through the use of MTP-PAUSE indication 3438 primitives. 3440 In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to 3441 re-establish the SCTP Association. This MAY be done by the M3UA 3442 layer automatically, or Layer Management MAY re-establish using the 3443 M-SCTP_ESTABLISH request primitive. 3445 In the case of an SCTP-RESTART indication at an ASP, the ASP is now 3446 considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if 3447 it is to recover, must begin any recovery with the ASP-Up procedure. 3449 4.3.4 ASPM Procedures for Peer-to-Peer Messages 3451 4.3.4.1 ASP Up Procedures 3453 After an ASP has successfully established an SCTP association to an 3454 SGP, the SGP waits for the ASP to send an ASP Up message, indicating 3455 that the ASP M3UA peer is available. The ASP is always the initiator 3456 of the ASP Up message. This action MAY be initiated at the ASP by an 3457 M-ASP_UP request primitive from Layer Management or MAY be initiated 3458 automatically by an M3UA management function. 3460 When an ASP Up message is received at an SGP and internally the 3461 remote ASP is in the ASP-DOWN state and not considered locked out for 3462 local management reasons, the SGP marks the remote ASP in the state 3463 ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication 3464 primitive. If the SGP is aware, via current configuration data, 3465 which Application Servers the ASP is configured to operate in, the 3466 SGP updates the ASP state to ASP-INACTIVE in each AS that it is a 3467 member. 3469 Alternatively, the SGP may move the ASP into a pool of Inactive ASPs 3470 available for future configuration within Application Server(s), 3471 determined in a subsequent Registration Request or ASP Active 3472 procedure. If the ASP Up message contains an ASP Identifier, the SGP 3473 should save the ASP Identifier for that ASP. The SGP MUST send an ASP 3474 Up Ack message in response to a received ASP Up message even if the 3475 ASP is already marked as ASP-INACTIVE at the SGP. 3477 If for any local reason (e.g., management lockout) the SGP cannot 3478 respond with an ASP Up Ack message, the SGP responds to an ASP Up 3479 message with an Error message with reason "Refused - Management 3480 Blocking". 3482 At the ASP, the ASP Up Ack message received is not acknowledged. 3483 Layer Management is informed with an M-ASP_UP confirm primitive. 3485 When the ASP sends an ASP Up message it starts timer T(ack). If the 3486 ASP does not receive a response to an ASP Up message within T(ack), 3487 the ASP MAY restart T(ack) and resend ASP Up messages until it 3488 receives an ASP Up Ack message. T(ack) is provisionable, with a 3489 default of 2 seconds. Alternatively, retransmission of ASP Up 3490 messages MAY be put under control of Layer Management. In this 3491 method, expiry of T(ack) results in an M-ASP_UP confirm primitive 3492 carrying a negative indication. 3494 The ASP must wait for the ASP Up Ack message before sending any other 3495 M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any 3496 other M3UA messages before an ASP Up message is received (other than 3497 ASP Down - see Section 4.3.4.2), the SGP MAY discard them. 3499 If an ASP Up message is received and internally the remote ASP is in 3500 the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as, 3501 an Error message ("Unexpected Message). In addition, the remote ASP 3502 state is changed to ASP-INACTIVE in all relevant Application Servers 3503 and all registered Routing Keys are considered deregistered. 3505 If an ASP Up message is received and internally the remote ASP is 3506 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 3507 and no further action is taken. 3509 If the ASP receives an unexpected ASP Up Ack message, the ASP should 3510 consider itself in the ASP-INACTIVE state. If the ASP was not in the 3511 ASP-INACTIVE state, it SHOULD send an Error message and then initiate 3512 procedures to return itself to its previous state. 3514 4.3.4.1.1 M3UA Version Control and ASP Up 3516 If an ASP Up message with an unsupported version is received, the 3517 receiving end responds with an Error message, indicating the version 3518 the receiving node supports and notifies Layer Management. See section 3519 4.8 for more on this issue. 3521 4.3.4.1.2 IPSP Considerations (ASP Up) 3523 An IPSP may be considered in the ASP-INACTIVE state after an ASP Up 3524 or ASP Up Ack has been received from it. An IPSP can be considered 3525 in the ASP-DOWN state after an ASP Down or ASP Down Ack has been 3526 received from it. The IPSP may inform Layer Management of the change 3527 in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or 3528 confirmation primitives. 3530 Alternatively, when using IPSP DE model, an interchange of ASP Up 3531 messages from each end MUST be performed. Four messages are needed for 3532 completion. 3534 If for any local reason (e.g., management lockout) an IPSP cannot 3535 respond to an ASP Up message with an ASP Up Ack message, it responds 3536 to an ASP Up message with an Error message with reason "Refused 3537 Management Blocking" and leaves the remote IPSP in the ASP-DOWN 3538 state. 3540 4.3.4.2 ASP-Down Procedures 3542 The ASP will send an ASP Down message to an SGP when the ASP wishes 3543 to be removed from service in all Application Servers that it is a 3544 member and no longer receive any DATA, SSNM or ASPTM messages. This 3545 action MAY be initiated at the ASP by an M-ASP_DOWN request primitive 3546 from Layer Management or MAY be initiated automatically by an M3UA 3547 management function. 3549 Whether the ASP is permanently removed from any AS is a function of 3550 configuration management. In the case where the ASP previously used 3551 the Registration procedures (see Section 4.4.1) to register within 3552 Application Servers but has not deregistered from all of them prior 3553 to sending the ASP Down message, the SGP MUST consider the ASP as 3554 Deregistered in all Application Servers that it is still a member. 3556 The SGP marks the ASP as ASP-DOWN, informs Layer Management with an 3557 M-ASP_Down indication primitive, and returns an ASP Down Ack message 3558 to the ASP. 3560 The SGP MUST send an ASP Down Ack message in response to a received 3561 ASP Down message from the ASP even if the ASP is already marked as 3562 ASP-DOWN at the SGP. 3564 At the ASP, the ASP Down Ack message received is not acknowledged. 3565 Layer Management is informed with an M-ASP_DOWN confirm primitive. 3566 If the ASP receives an ASP Down Ack without having sent an ASP Down 3567 message, the ASP should now consider itself as in the ASP-DOWN state. 3569 If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, 3570 the ASP should then initiate procedures to return itself to its 3571 previous state. 3573 When the ASP sends an ASP Down message it starts timer T(ack). If 3574 the ASP does not receive a response to an ASP Down message within 3575 T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until 3576 it receives an ASP Down Ack message. T(ack) is provisionable, with a 3577 default of 2 seconds. Alternatively, retransmission of ASP Down 3578 messages MAY be put under control of Layer Management. In this 3579 method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive 3580 carrying a negative indication. 3582 4.3.4.3 ASP Active Procedures 3584 Anytime after the ASP has received an ASP Up Ack message from the SGP 3585 or IPSP, the ASP MAY send an ASP Active message to the SGP indicating 3586 that the ASP is ready to start processing traffic. This action MAY 3587 be initiated at the ASP by an M-ASP_ACTIVE request primitive from 3588 Layer Management or MAY be initiated automatically by an M3UA 3589 management function. In the case where an ASP wishes to process the 3590 traffic for more than one Application Server across a common SCTP 3591 association, the ASP Active message(s) SHOULD contain a list of one 3592 or more Routing Contexts to indicate for which Application Servers 3593 the ASP Active message applies. It is not necessary for the ASP to 3594 include all Routing Contexts of interest in a single ASP Active 3595 message, thus requesting to become active in all Routing Contexts at 3596 the same time. Multiple ASP Active messages MAY be used to activate 3597 within the Application Servers independently, or in sets. 3599 In the case where an ASP Active message does not contain a Routing 3600 Context parameter, the receiver must know, via configuration data, 3601 which Application Server(s) the ASP is a member. 3603 For the Application Servers that the ASP can be successfully 3604 activated, the SGP or IPSP responds with one or more ASP Active Ack 3605 messages, including the associated Routing Context(s) and reflecting 3606 any Traffic Mode Type value present in the related ASP Active 3607 message. The Routing Context parameter MUST be included in the ASP 3608 Active Ack message(s) if the received ASP Active message contained 3609 any Routing Contexts. Depending on any Traffic Mode Type request in 3610 the ASP Active message, or local configuration data if there is no 3611 request, the SGP moves the ASP to the correct ASP traffic state 3612 within the associated Application Server(s). Layer Management is 3613 informed with an M-ASP_Active indication. If the SGP or IPSP receives 3614 any Data messages before an ASP Active message is received, the SGP 3615 or IPSP MAY discard them. By sending an ASP Active Ack message, the 3616 SGP or IPSP is now ready to receive and send traffic for the related 3618 Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages 3619 for the related Routing Context(s) before receiving an ASP Active Ack 3620 message, or it will risk message loss. 3622 Multiple ASP Active Ack messages MAY be used in response to an ASP 3623 Active message containing multiple Routing Contexts, allowing the SGP 3624 or IPSP to independently acknowledge the ASP Active message for 3625 different (sets of) Routing Contexts. 3627 The ASP Active message will be responded in the following way as a 3628 function of the presence/need of the RC parameter: 3630 - If the RC parameter is included in the ASP Active message and the 3631 corresponding RK has been previously defined (by either static 3632 configuration or dynamic registration), the peer node MUST respond 3633 with an ASP Active Ack message. If for any local reason (e.g. 3634 management lockout) the SGP responds t an ASP Active message with an 3635 Error message with reason "Refused � Management Blocking". 3637 - If the RC parameter is included in the ASP Active message and a 3638 corresponding RK has not been previously defined (by either static 3639 configuration or dynamic registration), the peer MUST respond with 3640 an ERROR message with Error Code = "No configured AS for ASP". 3642 - If the RC parameter is not included in the ASP Active message, there 3643 are RKs defined (by either static configuration or dynamic 3644 registration) and RC is not mandatory, the peer node SHOULD respond 3645 with an ASP Active Ack message and activate all the RKs it has 3646 defined for that specific ASP. 3648 - If the RC parameter is not included in the ASP Active message, there 3649 are RKs defined (by either static configuration or dynamic 3650 registration) and RC is mandatory, the peer node MUST respond with 3651 and ERROR message with the Error Code = "Missing Parameter". 3653 - If the RC parameter is not included in the ASP Active message, there 3654 are RKs defined (by either static configuration or dynamic 3655 registration) and RC is not mandatory, the peer node MUST respond 3656 with an ASP Active Ack message if it is ready to handle traffic; 3657 otherwise it will send an ERROR message with the Error Code = "No 3658 Configured AS for ASP" (meaning that it is not ready to become 3659 active). 3661 - If the RC parameter is not included in the ASP Active message and 3662 there are no RKs defined, the peer node SHOULD respond with and 3663 ERROR message with the Error Code = "Invalid Routing Context". 3665 Independently of the RC, the SGP MUST send an ASP Active Ack message 3666 in response to a received ASP Active message from the ASP, if the ASP 3667 is already marked in the APS-ACTIVE state. 3669 At the ASP, the ASP Active Ack message received is not acknowledged. 3670 Layer Management is informed with an M-ASP_ACTIVE confirm primitive. 3671 It is possible for the ASP to receive Data message(s) before the ASP 3672 Active Ack message as the ASP Active Ack and Data messages from an SG 3673 or IPSP may be sent on different SCTP streams. Message loss is 3674 possible as the ASP does not consider itself in the ASP-ACTIVE state 3675 until reception of the ASP Active Ack message. 3677 When the ASP sends an ASP Active message it starts timer T(ack). If 3678 the ASP does not receive a response to an ASP Active message within 3679 T(ack), the ASP MAY restart T(ack) and resend ASP Active messages 3680 until it receives an ASP Active Ack message. T(ack) is 3681 provisionable, with a default of 2 seconds. Alternatively, 3682 retransmission of ASP Active messages MAY be put under control of 3683 Layer Management. In this method, expiry of T(ack) results in an M- 3684 ASP_ACTIVE confirm primitive carrying a negative indication. 3686 There are three modes of Application Server traffic handling in the 3687 SGP M3UA layer: Override, Loadshare and Broadcast. When included, 3688 the Traffic Mode Type parameter in the ASP Active message indicates 3689 the traffic handling mode to be used in a particular Application 3690 Server. If the SGP determines that the mode indicated in an ASP 3691 Active message is unsupported or incompatible with the mode currently 3692 configured for the AS, the SGP responds with an Error message 3693 ("Unsupported / Invalid Traffic Handling Mode"). If the traffic 3694 handling mode of the Application Server is not already known via 3695 configuration data, then the traffic handling mode indicated in the 3696 first ASP Active message causing the transition of the Application 3697 Server state to AS-ACTIVE MAY be used to set the mode. 3699 In the case of an Override mode AS, reception of an ASP Active 3700 message at an SGP causes the (re)direction of all traffic for the AS 3701 to the ASP that sent the ASP Active message. Any previously active 3702 ASP in the AS is now considered to be in state ASP-INACTIVE and 3703 SHOULD no longer receive traffic from the SGP within the AS. The SGP 3704 or IPSP then MUST send a Notify message ("Alternate ASP_Active") to 3705 the previously active ASP in the AS, and SHOULD stop traffic to/from 3706 that ASP. The ASP receiving this Notify MUST consider itself now in 3707 the ASP-INACTIVE state, if it is not already aware of this via 3708 inter-ASP communication with the Overriding ASP. 3710 In the case of a Loadshare mode AS, reception of an ASP Active 3711 message at an SGP or IPSP causes the direction of traffic to the ASP 3712 sending the ASP Active message, in addition to all the other ASPs 3713 that are currently active in the AS. The algorithm at the SGP for 3714 loadsharing traffic within an AS to all the active ASPs is 3715 implementation dependent. The algorithm could, for example, be 3716 round-robin or based on information in the Data message (e.g., the 3717 SLS, SCCP SSN, ISUP CIC value). 3718 An SGP or IPSP, upon reception of an ASP Active message for the first 3719 ASP in a Loadshare AS, MAY choose not to direct traffic to a newly 3720 active ASP until it determines that there are sufficient resources to 3721 handle the expected load (e.g., until there are "n" ASPs in state 3722 ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold 3723 the Notify (AS-ACTIVE) until there are sufficient resources. 3725 For the n+k redundancy case, ASPs which are in that AS should 3726 coordinate among themselves the number of active ASPs in the AS, and 3727 should start sending traffic only after n ASPs are active. 3728 All ASPs within a loadsharing mode AS must be able to process any 3729 Data message received for the AS, to accommodate any potential 3730 failover or rebalancing of the offered load. 3732 In the case of a Broadcast mode AS, reception of an ASP Active 3733 message at an SGP or IPSP causes the direction of traffic to the ASP 3734 sending the ASP Active message, in addition to all the other ASPs 3735 that are currently active in the AS. The algorithm at the SGP for 3736 broadcasting traffic within an AS to all the active ASPs is a simple 3737 broadcast algorithm, where every message is sent to each of the 3738 active ASPs. 3740 At start-up or re-start phases, an SGP or IPSP, upon reception of an 3741 ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT 3742 direct traffic to a newly active ASP until it determines that there 3743 are sufficient resources to handle the expected load (e.g., until 3744 there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the 3745 SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are 3746 sufficient resources. 3748 An SGP or IPSP, upon reception of an ASP Active message for the first 3749 ASP in a Broadcast AS, MAY choose not to direct traffic to a newly 3750 active ASP until it determines that there are sufficient resources to 3751 handle the expected load (e.g., until there are "n" ASPs in state 3752 ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold 3753 the Notify (AS-ACTIVE) until there are sufficient resources. 3755 For the n+k redundancy case, ASPs which are in that AS should 3756 coordinate among themselves the number of active ASPs in the AS, and 3757 should start sending traffic only after n ASPs are active. 3759 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP 3760 MUST tag the first DATA message broadcast in each traffic flow with 3761 a unique Correlation Id parameter. The purpose of this Id is to 3762 permit the newly active ASP to synchronize its processing of traffic 3763 in each traffic flow with the other ASPs in the broadcast group. 3765 4.3.4.3.1 IPSP Considerations (ASP Active) 3767 Either of the IPSPs can initiate communication. When an IPSP receives 3768 an ASP Active, it should mark the peer as ASP-ACTIVE and return an 3769 ASP Active Ack message. An ASP receiving an ASP Active Ack message 3770 may mark the peer as ASP-Active, if it is not already in the ASP- 3771 ACTIVE state. 3773 Alternatively, when using IPSP DE model, an interchange of ASP Active 3774 messages from each end MUST be performed. Four messages are needed for 3775 completion. 3777 4.3.4.4 ASP Inactive Procedures 3779 When an ASP wishes to withdraw from receiving traffic within an AS, or 3780 the ASP wants to initiate the process of deactivation, the ASP sends 3781 an ASP Inactive message to the SGP or IPSP. 3783 An ASP Inactive message MUST always be responded by the peer (although 3784 other messages may be sent in the middle) in the following way: 3786 - If the received ASP Inactive message contains a RC parameter and 3787 the corresponding RK is defined (by either static configuration 3788 or dynamic registration), the SGP/IPSP MUST respond with an ASP 3789 Inactive Ack message. 3791 - If the received ASP Inactive message contains a RC parameter 3792 that is not defined (by either static configuration or dynamic 3793 registration), the SGP/IPSP MUST respond with an ERROR message 3794 with Error Code = "Invalid Routing Context". 3796 - If the received ASP Inactive message does not contain a RC 3797 parameter and the RK is defined (by either static configuration 3798 or dynamic registration), the SGP/IPSP must turn the ASP/IPSP to 3799 ASP-INACTIVE state in all the ASes it serves and MUST respond 3800 with an ASP Inactive Ack message. 3802 - If the received ASP Inactive message does not contain a RC 3803 parameter and the RK is not defined (by either static 3804 configuration or dynamic registration), the SGP/IPSP MUST 3805 respond with an ERROR message with Error Code = "No configured 3806 AS for ASP". 3808 The action of sending the ASP Inactive message MAY be initiated at the 3809 ASP by an M-ASP_INACTIVE request primitive from Layer Management or 3810 MAY be initiated automatically by an M3UA management function. In the 3811 case where an ASP is processing the traffic for more than one 3812 Application Server across a common SCTP association, the ASP Inactive 3813 message contains one or more Routing Contexts to indicate for which 3814 Application Servers the ASP Inactive message applies. 3816 In the case where an ASP Inactive message does not contain a Routing 3817 Context parameter, the receiver must know, via configuration data, 3818 which Application Servers the ASP is a member and move the ASP to the 3819 ASP-INACTIVE state in all Application Servers. 3821 In the case of an Override mode AS, where another ASP has already 3822 taken over the traffic within the AS with an ASP Active ("Override") 3823 message, the ASP that sends the ASP Inactive message is already 3824 considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive 3825 Ack message is sent to the ASP, after ensuring that all traffic is 3826 stopped to the ASP. 3828 In the case of a Loadshare mode AS, the SGP moves the ASP to the 3829 ASP-INACTIVE state and the AS traffic is reallocated across the 3830 remaining ASPs in the state ASP-ACTIVE, as per the loadsharing 3831 algorithm currently used within the AS. A Notify message 3832 ("Insufficient ASP resources active in AS") MAY be sent to all 3833 inactive ASPs, if required. An ASP Inactive Ack message is sent to 3834 the ASP after all traffic is halted and Layer Management is informed 3835 with an M-ASP_INACTIVE indication primitive. 3837 In the case of a Broadcast mode AS, the SGP moves the ASP to the 3838 ASP-INACTIVE state and the AS traffic is broadcast only to the 3839 remaining ASPs in the state ASP-ACTIVE. A Notify message 3840 ("Insufficient ASP resources active in AS") MAY be sent to all 3841 inactive ASPs, if required. An ASP Inactive Ack message is sent to 3842 the ASP after all traffic is halted and Layer Management is informed 3843 with an M-ASP_INACTIVE indication primitive. 3845 Multiple ASP Inactive Ack messages MAY be used in response to an ASP 3846 Inactive message containing multiple Routing Contexts, allowing the 3847 SGP or IPSP to independently acknowledge for different (sets of) 3848 Routing Contexts. The SGP or IPSP sends an Error message ("Invalid 3849 Routing Context") message for each invalid or unconfigured Routing 3850 Context value in a received ASP Inactive message. 3852 The SGP MUST send an ASP Inactive Ack message in response to a 3853 received ASP Inactive message from the ASP and the ASP is already 3854 marked as ASP-INACTIVE at the SGP. 3856 At the ASP, the ASP Inactive Ack message received is not 3857 acknowledged. Layer Management is informed with an M-ASP_INACTIVE 3858 confirm primitive. If the ASP receives an ASP Inactive Ack without 3859 having sent an ASP Inactive message, the ASP should now consider 3860 itself as in the ASP-INACTIVE state. If the ASP was previously in 3861 the ASP-ACTIVE state, the ASP should then initiate procedures to 3862 return itself to its previous state. 3864 When the ASP sends an ASP Inactive message it starts timer T(ack). 3865 If the ASP does not receive a response to an ASP Inactive message 3866 within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive 3867 messages until it receives an ASP Inactive Ack message. T(ack) is 3868 provisionable, with a default of 2 seconds. Alternatively, 3869 retransmission of ASP Inactive messages MAY be put under control of 3870 Layer Management. In this method, expiry of T(ack) results in a M- 3871 ASP_Inactive confirm primitive carrying a negative indication. 3873 If no other ASPs in the Application Server are in the state ASP- 3874 ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all of 3875 the ASPs in the AS which are in the state ASP-INACTIVE. The SGP 3876 SHOULD start buffering the incoming messages for T(r) seconds, after 3877 which messages MAY be discarded. T(r) is configurable by the network 3878 operator. If the SGP receives an ASP Active message from an ASP in 3879 the AS before expiry of T(r), the buffered traffic is directed to 3880 that ASP and the timer is cancelled. If T(r) expires, the AS is moved 3881 to the AS-INACTIVE state. 3883 4.3.4.4.1 IPSP Considerations (ASP Inactive) 3884 An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP 3885 after an ASP Inactive or ASP Inactive Ack message has been received 3886 from it. 3888 Alternatively, when using IPSP DE model, an interchange of ASP 3889 Inactive messages from each end MUST be performed. Four messages are 3890 needed for completion. 3892 4.3.4.5 Notify Procedures 3894 A Notify message reflecting a change in the AS state MUST be sent to 3895 all ASPs in the AS, except those in the ASP-DOWN state, with 3896 appropriate Status Information and any ASP Identifier of the failed 3897 ASP. At the ASP, Layer Management is informed with an M-NOTIFY 3898 indication primitive. The Notify message must be sent whether the AS 3899 state change was a result of an ASP failure or reception of an ASP 3900 State management (ASPSM) / ASP Traffic Management (ASPTM) message. 3901 In the second case, the Notify message MUST be sent after any related 3902 acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active 3903 Ack, or ASP Inactive Ack). 3905 When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular 3906 AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after 3907 sending the ASP-UP-ACK, in order to inform the ASP of the current AS 3908 state. 3910 In the case where a Notify message ("AS-PENDING") message is sent by 3911 an SGP that now has no ASPs active to service the traffic, or where a 3912 Notify ("Insufficient ASP resources active in AS") message is sent in 3913 the Loadshare or Broadcast mode, the Notify message does not 3914 explicitly compel the ASP(s) receiving the message to become active. 3915 The ASPs remain in control of what (and when) traffic action is 3916 taken. 3918 In the case where a Notify message does not contain a Routing Context 3919 parameter, the receiver must know, via configuration data, of which 3920 Application Servers the ASP is a member and take the appropriate 3921 action in each AS. 3923 4.3.4.5.1 IPSP Considerations (NTFY) 3925 Notify works in the same manner as in the SG-AS case. One of the 3926 IPSPs can send this message to any remote IPSP that is not in the 3927 ASP-DOWN state. 3929 4.3.4.6 Heartbeat Procedures 3931 The optional Heartbeat procedures MAY be used when operating over 3932 transport layers that do not have their own heartbeat mechanism for 3933 detecting loss of the transport association (i.e., other than SCTP). 3935 Either M3UA peer may optionally send Heartbeat messages periodically, 3936 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 3937 message, the M3UA peer MUST respond with a Heartbeat Ack message. 3939 If no Heartbeat Ack message (or any other M3UA message) is received 3940 from the M3UA peer within 2*T(beat), the remote M3UA peer is 3941 considered unavailable. Transmission of Heartbeat messages is 3942 stopped and the signalling process SHOULD attempt to re-establish 3943 communication if it is configured as the client for the disconnected 3944 M3UA peer. 3946 The Heartbeat message may optionally contain an opaque Heartbeat Data 3947 parameter that MUST be echoed back unchanged in the related Heartbeat 3948 Ack message. The sender, upon examining the contents of the returned 3949 Heartbeat Ack message, MAY choose to consider the remote M3UA peer as 3950 unavailable. The contents/format of the Heartbeat Data parameter is 3951 implementation-dependent and only of local interest to the original 3952 sender. The contents may be used, for example, to support a 3953 Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a 3954 timestamp mechanism (to evaluate delays). 3956 Note: Heartbeat related events are not shown in Figure 3 "ASP state 3957 transition diagram". 3959 4.4 Routing Key Management Procedures [Optional] 3961 4.4.1 Registration 3963 An ASP MAY dynamically register with an SGP as an ASP within an 3964 Application Server using the REG REQ message. A Routing Key 3965 parameter in the REG REQ message specifies the parameters associated 3966 with the Routing Key. 3968 The SGP examines the contents of the received Routing Key parameter 3969 and compares it with the currently provisioned Routing Keys. If the 3970 received Routing Key matches an existing SGP Routing Key entry, and 3971 the ASP is not currently included in the list of ASPs for the related 3972 Application Server, the SGP MAY authorize the ASP to be added to the 3973 AS. Or, if the Routing Key does not currently exist and the received 3974 Routing Key data is valid and unique, an SGP supporting dynamic 3975 configuration MAY authorize the creation of a new Routing Key and 3976 related Application Server and add the ASP to the new AS. In either 3977 case, the SGP returns a Registration Response message to the ASP, 3978 containing the same Local-RK-Identifier as provided in the initial 3979 request, and a Registration Result "Successfully Registered". A 3980 unique Routing Context value assigned to the SGP Routing Key is 3981 included. The method of Routing Context value assignment at the SGP 3982 is implementation dependent but must be guaranteed to be unique for 3983 each Application Server or Routing Key supported by the SGP. 3985 If the SGP does not support the registration procedure, the SGP 3986 returns an Error message to the ASP, with an error code of 3987 "Unsupported Message Class". 3989 If the SGP determines that the received Routing Key data is invalid, 3990 or contains invalid parameter values, the SGP returns a Registration 3991 Response message to the ASP, containing a Registration Result "Error 3992 Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network 3993 Appearance" as appropriate. 3995 If the SGP determines that the requested RK partially, but not 3996 exactly, matches an existing RK, and that an incoming signalling 3997 message received at an SGP could possibly match both the requested and 3998 the existing RK, the SGP returns a Registration Response message to 3999 the ASP, with a Registration Status of "Error - "Cannot Support Unique 4000 Routing. An incoming signalling message received at an SGP should not 4001 match against more than one Routing Key. 4003 If the SGP determines that the received RK was already registered, 4004 fully and exactly, either statically or dynamically, by the sending 4005 ASP, the SGP returns a Registration Response message to the ASP, 4006 containing a Registration Result "Error - Routing Key Already 4007 Registered ". This error applies whether the sending ASP/IPSP is in 4008 ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error 4009 code, the RC field in the Registration Response message MUST be 4010 populated with the actual value of RC in SGP corresponding to the 4011 specified RK in the Registration Request message. 4013 An ASP MAY request modification of an existing Routing Key by 4014 including a Routing Context parameter in a Registration Request 4015 message. Upon receipt of a Registration Request message containing a 4016 Routing Context, if the SGP determines that the Routing Context 4017 applies to an existing Routing Key, the SGP MAY adjust the existing 4018 Routing Key to match the new information provided in the Routing Key 4019 parameter. A Registration Response "ERR � Routing Key Change Refused" 4020 is returned if the SGP does not support this re-registration procedure 4021 or RC does not exist. Otherwise, a Registration Response "Successfully 4022 Registered" is returned. 4024 If the SGP does not authorize an otherwise valid registration request, 4025 the SGP returns a REG RSP message to the ASP containing the 4026 Registration Result "Error - Permission Denied". 4028 If an SGP determines that a received Routing Key does not currently 4029 exist and the SGP does not support dynamic configuration, the SGP 4030 returns a Registration Response message to the ASP, containing a 4031 Registration Result "Error - Routing Key not Currently Provisioned". 4033 If an SGP determines that a received Routing Key does not currently 4034 exist and the SGP supports dynamic configuration but does not have 4035 the capacity to add new Routing Key and Application Server entries, 4036 the SGP returns a Registration Response message to the ASP, 4037 containing a Registration Result "Error - Insufficient Resources". 4039 If an SGP determines that a received Routing Key does not currently 4040 exist, and the SGP supports dynamic configuration but requires that 4041 the Routing Key first be manually provisioned at the SGP, the SGP 4042 returns a Registration Response message to the ASP, containing a 4043 Registration Result "Error - Routing Key not Currently Provisioned. 4045 If an SGP determines that one or more of the Routing Key parameters 4046 are not supported for the purpose of creating new Routing Key entries, 4047 the SGP returns a Registration Response message to the ASP, containing 4048 a Registration Result "Error - Unsupported RK parameter field. 4050 A Registration Response "Error - Unsupported Traffic Handling Mode" 4051 is returned if the Routing Key in the REG REQ contains an Traffic 4052 Handling Mode that is inconsistent with the presently configured mode 4053 for the matching Application Server. 4055 An ASP MAY register multiple Routing Keys at once by including a 4056 number of Routing Key parameters in a single REG REQ message. The 4057 SGP MAY respond to each registration request in a single REG RSP 4058 message, indicating the success or failure result for each Routing 4059 Key in a separate Registration Result parameter. Alternatively the 4060 SGP MAY respond with multiple REG RSP messages, each with one or more 4061 Registration Result parameters. The ASP uses the Local-RK-Identifier 4062 parameter to correlate the requests with the responses. 4064 Upon successful registration of an ASP in an AS, the SGP can now send 4065 related SS7 Signalling Network Management messaging, if this did not 4066 previously start upon the ASP transitioning to state ASP-INACTIVE 4068 4.4.2 Deregistration 4070 An ASP MAY dynamically deregister with an SGP as an ASP within an 4071 Application Server using the DEREG REQ message. A Routing Context 4072 parameter in the DEREG REQ message specifies which Routing Keys to 4073 deregister. An ASP SHOULD move to the ASP-INACTIVE state for an 4074 Application Server before attempting to deregister the Routing Key 4075 (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP 4076 SHOULD deregister from all Application Servers that it is a member 4077 before attempting to move to the ASP-Down state. 4079 The SGP examines the contents of the received Routing Context 4080 parameter and validates that the ASP is currently registered in the 4081 Application Server(s) related to the included Routing Context(s). If 4082 validated, the ASP is deregistered as an ASP in the related 4083 Application Server. 4085 The deregistration procedure does not necessarily imply the deletion 4086 of Routing Key and Application Server configuration data at the SG. 4088 Other ASPs may continue to be associated with the Application Server, 4089 in which case the Routing Key data SHOULD NOT be deleted. If a 4090 Deregistration results in no more ASPs in an Application Server, an 4091 SG MAY delete the Routing Key data. 4093 The SGP acknowledges the deregistration request by returning a DEREG 4094 RSP message to the requesting ASP. The result of the deregistration 4095 is found in the Deregistration Result parameter, indicating success 4096 or failure with cause. 4098 An ASP MAY deregister multiple Routing Contexts at once by including 4099 a number of Routing Contexts in a single DEREG REQ message. The SGP 4100 MAY respond to each deregistration request in a single DEREG RSP 4101 message, indicating the success or failure result for each Routing 4102 Context in a separate Deregistration Result parameter. 4104 4.4.3 IPSP Considerations (REG/DEREG) 4106 The Registration/Deregistration procedures work in the IPSP cases in 4107 the same way as in AS-SG cases. An IPSP may register an RK in the 4108 remote IPSP. An IPSP is responsible for deregistering the RKs that it 4109 has registered. 4111 4.5 Procedures to Support the Availability or Congestion Status of SS7 4112 Destination 4114 4.5.1 At an SGP 4116 On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication 4117 primitive from the nodal interworking function at an SGP, the SGP 4118 M3UA layer will send a corresponding SS7 Signalling Network 4119 Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) 4120 to the M3UA peers at concerned ASPs. The M3UA layer must fill in 4121 various fields of the SSNM messages consistently with the information 4122 received in the primitives. 4124 The SGP M3UA layer determines the set of concerned ASPs to be informed 4125 based on the specific SS7 network for which the primitive indication 4126 is relevant. In this way, all ASPs configured to send/receive traffic 4127 within a particular Network Appearance are informed. If the SGP 4128 operates within a single SS7 Network Appearance, then all ASPs are 4129 informed. 4131 For the particular case that an ASP becomes active for an AS and 4132 destinations normally accessible to the AS are inaccessible, 4133 restricted or congested, the SG MAY send DUNA, DRST or SCON messages 4134 for the inaccessible, restricted or congested destinations to the ASP 4135 newly active for the AS to prevent the ASP from sending traffic for 4136 destinations that it might otherwise not know that are inaccessible, 4137 restricted or congested. For the newly activating ASP from which the 4138 SGP has received an ASP Active message, these DUNA, DRST and SCON 4139 messages MAY be sent before sending the ASP Active Ack that completes 4140 the activation procedure. 4142 DUNA, DAVA, SCON, and DRST messages may be sent sequentially and 4143 processed at the receiver in the order sent. 4145 Sequencing is not required for the DUPU or DAUD messages, which MAY 4146 be sent unsequenced. 4148 4.5.2 At an ASP 4150 4.5.2.1 Single SG Configurations 4152 At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) 4153 message from the remote M3UA Peer, the M3UA layer invokes the 4154 appropriate primitive indications to the resident M3UA-Users. Local 4155 management is informed. 4157 In the case where a local event has caused the unavailability or 4158 congestion status of SS7 destinations, the M3UA layer at the ASP 4159 SHOULD pass up appropriate indications in the primitives to the M3UA 4160 User, as though equivalent SSNM messages were received. For example, 4161 the loss of an SCTP association to an SGP may cause the 4162 unavailability of a set of SS7 destinations. MTP-PAUSE indication 4163 primitives to the M3UA User are appropriate. 4165 4.5.2.2 Multiple SG Configurations 4167 At an ASP, upon receiving a Signalling Network Management message 4168 from the remote M3UA Peer, the M3UA layer updates the status of the 4169 affected route(s) via the originating SG and determines, whether or 4170 not the overall availability or congestion status of the effected 4171 destination(s) has changed. If so, the M3UA layer invokes the 4172 appropriate primitive indications to the resident M3UA-Users. Local 4173 management is informed. 4175 Implementation Note: To accomplish this, the M3UA layer at an ASP 4176 maintains the status of routes via the SG, much like an MTP3 layer 4177 maintains route-set status. 4179 4.5.3 ASP Auditing 4181 An ASP may optionally initiate an audit procedure to enquire of an 4182 SGP the availability and, if the national congestion method with 4183 multiple congestion levels and message priorities is used, congestion 4184 status of an SS7 destination or set of destinations. A Destination 4186 Audit (DAUD) message is sent from the ASP to the SGP requesting the 4187 current availability and congestion status of one or more SS7 4188 Destination Point Codes. 4190 The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the 4191 ASP in the following cases: 4193 - Periodic. A Timer originally set upon reception of a DUNA, SCON 4194 or DRST message has expired without a subsequent 4195 DAVA, DUNA, SCON or DRST message updating the 4196 availability/congestion status of the affected 4197 Destination Point Codes. The Timer is reset upon 4198 issuing a DAUD. In this case the DAUD is sent to the 4199 SGP that originally sent the SSNM message. 4201 - Isolation. The ASP is newly ASP-ACTIVE or has been 4202 isolated from an SGP for an extended period. The ASP 4203 MAY request the availability/congestion status of one 4204 or more SS7 destinations to which it expects to 4205 communicate. 4207 IMPLEMENTATION NOTE: In the first of the cases above, the auditing 4208 procedure must not be invoked for the case of a received SCON 4209 message 4210 containing a congestion level value of "no congestion" or undefined" 4211 (i.e., congestion Level = "0"). 4213 The SGP SHOULD respond to a DAUD message with the MTP3 4214 availability/congestion status of the routeset associated with each 4215 Destination Point Code(s) in the DAUD message. The status of each SS7 4216 destination requested is indicated in a DUNA message (if unavailable), 4217 a DAVA message (if available ), or a DRST (if restricted and the SGP 4218 supports this feature in national networks). For national networks, 4219 the SGP SHOULD additionally respond with a SCON message (if the 4220 destination is congested) before the DAVA or DRST. 4221 Where the SGP does not maintain the congestion status of the SS7 4222 destination, the response to a DAUD message should always be only a 4223 DAVA, DRST or DUNA message as appropriate. 4225 Any DUNA or DAVA message in response to a DAUD message MAY contain a 4226 list of Affected Point Codes. 4228 An SG MAY refuse to provide the availability or congestion status of 4229 a destination if, for example, the ASP is not authorized to know the 4230 status of the destination. The SG MAY respond with an Error Message 4231 (Error Code = "Destination Status Unknown"). 4233 An SG SHOULD response with a DUNA message when DAUD was received with 4234 an unknown Signalling Point Code. 4236 4.6 MTP3 Restart 4238 In the case where the MTP3 in the SG undergoes an MTP restart, event 4239 communication SHOULD be handled as follows: 4241 When the SG discovers SS7 network isolation, the SGPs send an 4242 indication to all concerned available ASPs (i.e., ASPs in the ASP- 4243 ACTIVE state) using DUNA messages for the concerned destinations. 4245 When the SG has completed the MTP Restart procedure, the M3UA layers 4246 at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any 4247 available/restricted SS7 destinations using the DAVA/DRST messages. 4248 No message is necessary for those destinations still unavailable 4249 after the restart procedure. 4251 When the M3UA layer at an ASP receives a DUNA message indicating SS7 4252 destination unavailability at an SG, MTP Users will receive an MTP- 4253 PAUSE indication and will stop any affected traffic to this 4254 destination. When the M3UA receives a DAVA/DRST message, MTP Users 4255 will receive an MTP-RESUME indication and can resume traffic to the 4256 newly available SS7 destination, provided the ASP is in the ASP- 4257 ACTIVE state towards this SGP. 4259 The ASP MAY choose to audit the availability of unavailable 4260 destinations by sending DAUD messages. This would be for example the 4261 case when an AS becomes active at an ASP and does not have current 4262 destination statuses. If MTP restart is in progress at the SG, the 4263 SGP returns a DUNA message for that destination, even if it received 4264 an indication that the destination became available or restricted. 4266 When an ASP becomes active for an AS and the SG is experiencing SS7 4267 network isolation or is performing the MTP Restart procedure for the 4268 AS, the SG MAY send a DUNA message for the concerned destinations to 4269 the newly active ASP to prevent the ASP from sending traffic. These 4270 messages can be sent after receiving the ASP Active and before sending 4271 the ASP Active Ack to ensure that traffic is not initiated by the ASP 4272 to these destinations before the SSNM are received. In addition to 4273 DUNA messages, SCON, DRST and DAVA can also be sent. 4275 In the IPSP case, MTP restart could be considered if the IPSP also 4276 has connection to an SS7 network. In that case, the same behavior as 4277 described above for the SGP would apply to the restarting IPSP. This 4278 would also be the case if the IPSPs were perceived as exchanging MTP 4279 Peer PDUs, instead of MTP primitives between MTP User and MTP 4280 Provider. In other words, M3UA does not provide the equivalent to 4282 Traffic Restart Allowed messages indicating the end of the restart 4283 procedure between peer IPSPs that would also be connected to an SS7 4284 network. 4286 4.7 NIF not Available 4288 IMPLEMENTATION NOTE: Although the NIF is decided to be an 4289 implementation dependent function, here there are some guidelines that 4290 may be useful to follow: 4292 - If an SGP is isolated entirely from the NIF, the SGP should send ASP 4293 Down Ack to all its connected ASPs. Upon receiving an ASP Up 4294 message while isolated from the NIF, the SGP should respond with 4295 Error("Refused - Management Blocking"). 4297 - If an SGP suffers a partial failure (where an SGP can continue to 4298 service one or more active AS, but due to a partial failure it is 4299 unable to service one or more other active AS), the SGP should send 4300 ASP Inactive Ack to all its connected ASPs for the affected AS. Upon 4301 receiving an ASP Active message for an affected AS and while still 4302 partially isolated from the NIF, the SGP should respond with 4303 Error("Refused - Management Blocking"). 4305 - If SG is isolated from NIF it means that each SGP within an SG 4307 should follow the procedure mentioned above. 4309 4.8 M3UA Version Control 4311 If a message with an unsupported version is received, the receiving 4312 end responds with an Error message, indicating the version the 4313 receiving node supports and notifies Layer Management. 4315 This is useful when protocol version upgrades are being performed in a 4316 network. A node upgraded to a newer version should support the older 4317 versions used on other nodes it is communicating with. Because ASPs 4318 initiate the ASP Up procedure it is likely that the message 4319 having an unsupported version is an ASP Up message and therefore that 4320 the Error message would normally come from the SGP. 4322 4.9 M3UA Termination 4324 Whenever a M3UA node wants to stop the communication with the peer 4325 node, it MAY use one of the following procedures 4327 a) Send the sequence of ASP-INACTIVE, DEREG (optionally whenever 4328 dynamic registration is used), ASP-DOWN messages and perform the 4329 SCTP Shutdown procedure after that. 4331 b) Just do the SCTP Shutdown procedure. 4333 5. Examples of M3UA Procedures 4335 5.1 Establishment of Association and Traffic between SGPs and ASPs 4337 These scenarios show the example M3UA message flows for the 4338 establishment of traffic between an SGP and an ASP or between two 4339 IPSPs. In all cases it is assumed that the SCTP association is 4340 already set up. 4342 5.1.1 Single ASP in an Application Server ("1+0" sparing), 4344 These scenarios show the example M3UA message flows for the 4345 establishment of traffic between an SGP and an ASP where only one ASP 4346 is configured within an AS (no backup). 4348 5.1.1.1 Single ASP in an Application Server ("1+0" sparing), 4349 No Registration 4351 SGP ASP1 4352 | | 4353 |<-------------ASP Up-----------| 4354 |-----------ASP Up Ack--------->| 4355 | | 4356 |-----NTFY(AS-INACTIVE)(RCn)--->| 4357 | | 4358 |<------- ASP Active(RCn)-------| RC: Routing Context 4359 |-----ASP Active Ack (RCn)----->| (optional) 4360 | | 4361 |-----NTFY(AS-ACTIVE)(RCn)----->| 4362 | | 4364 Note: If the ASP Active message contains an optional Routing Context 4365 parameter, the ASP Active message only applies for the specified RC 4366 value(s). For an unknown RC value, the SGP responds with an Error 4367 message. 4369 5.1.1.2 Single ASP in Application Server ("1+0" sparing), 4370 Dynamic Registration 4372 This scenario is the same as for 5.1.1.1 but with the optional 4373 exchange of registration information. In this case the Registration 4374 is accepted by the SGP. 4376 SGP ASP1 4377 | | 4378 |<------------ASP Up------------| 4379 |----------ASP Up Ack---------->| 4380 | | 4381 | | 4382 |<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing 4383 | | Key Id 4384 |----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key 4385 | | RC: Routing Context 4386 |----NTFY(AS-INACTIVE)(RCn)---->| 4387 | | 4388 | | 4389 |<------- ASP Active(RCn)-------| 4390 |-----ASP Active Ack (RCn)----->| 4391 | | 4392 |-----NTFY(AS-ACTIVE)(RCn)----->| 4393 | | 4395 Note: In the case of an unsuccessful registration attempt (e.g., 4396 invalid RKn), the Register Response message will contain an 4397 unsuccessful indication and the ASP will not subsequently send an ASP 4398 Active message. 4400 5.1.1.3 Single ASP in Multiple Application Servers (each 4401 with "1+0" sparing), Dynamic Registration (Case 1 - Multiple 4402 Registration Requests) 4404 SGP ASP1 4405 | | 4406 |<------------ASP Up------------| 4407 |----------ASP Up Ack---------->| 4408 | | 4409 |<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing 4410 | | Key Id 4411 |----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key 4412 | | RC: Routing Context 4413 |---NOTIFY(AS-INACTIVE)(RC1)--->| 4414 | | 4415 | | 4416 |<------- ASP Active(RC1)-------| 4417 |-----ASP Active Ack (RC1)----->| 4418 | | 4419 |----NOTIFY(AS-ACTIVE)(RC1)---->| 4420 | | 4421 ~ ~ 4422 | | 4423 |<----REGISTER REQ(LRCn,RKn)----| 4424 | | 4425 |----REGISTER RESP(LRCn,RCn)--->| 4426 | | 4427 |---NOTIFY(AS-INACTIVE)(RCn)--->| 4428 | | 4429 |<------- ASP Active(RCn)-------| 4430 |-----ASP Active Ack (RCn)----->| 4431 | | 4432 |----NOTIFY(AS-ACTIVE)(RCn)---->| 4433 | | 4435 Note: In the case of an unsuccessful registration attempt (e.g., 4436 invalid RKn), the Register Response message will contain an 4437 unsuccessful indication and the ASP will not subsequently send an ASP 4438 Active message. Each LRC/RK pair registration is considered 4439 independently. 4441 It is not necessary to follow a Registration Request/Response message 4442 pair with an ASP Active message before sending the next Registration 4443 Request. The ASP Active message can be sent at any time after the 4444 related successful registration. 4446 5.1.1.4 Single ASP in Multiple Application Servers (each 4447 with "1+0" sparing), Dynamic Registration (Case 2 - Single 4448 Registration Request) 4450 SGP ASP1 4451 | | 4452 |<------------ASP Up------------| 4453 |----------ASP Up Ack---------->| 4454 | | 4455 | | 4456 |<---REGISTER REQ({LRC1,RK1}, | 4457 | ..., | 4458 | {LRCn,RKn}),--| 4459 | | 4460 |---REGISTER RESP({LRC1,RC1},-->| 4461 | ..., | 4462 | (LRCn,RCn}) | 4463 | | 4464 |--NTFY(AS-INACTIVE)(RC1..RCn)->| 4465 | | 4466 | | 4467 |<------- ASP Active(RC1)-------| 4468 |-----ASP Active Ack (RC1)----->| 4469 | | 4470 |----NOTIFY(AS-ACTIVE)(RC1)---->| 4471 | | 4472 : : 4473 : : 4474 | | 4475 |<------- ASP Active(RCn)-------| 4476 |-----ASP Active Ack (RCn)----->| 4477 | | 4478 |----NOTIFY(AS-ACTIVE)(RCn)---->| 4479 | | 4481 Note: In the case of an unsuccessful registration attempt (e.g., 4482 Invalid RKn), the Register Response message will contain an 4483 unsuccessful indication and the ASP will not subsequently send an ASP 4484 Active message. Each LRC/RK pair registration is considered 4485 independently. 4487 The ASP Active message can be sent at any time after the related 4488 successful registration, and may have more than one RC. 4490 5.1.2 Two ASPs in Application Server ("1+1" sparing) 4491 This scenario shows the example M3UA message flows for the 4492 establishment of traffic between an SGP and two ASPs in the same 4493 Application Server, where ASP1 is configured to be in the ASP-ACTIVE 4494 state and ASP2 is to be a "backup" in the event of communication 4495 failure or the withdrawal from service of ASP1. ASP2 may act as a 4496 hot, warm, or cold backup depending on the extent to which ASP1 and 4497 ASP2 share call/transaction state or can communicate call state under 4498 failure/withdrawal events. The example message flow is the same 4499 whether the ASP Active messages indicate "Override", "Loadshare" or 4500 "Broadcast" mode, although typically this example would use an 4501 Override mode. 4503 SGP ASP1 ASP2 4504 | | | 4505 |<--------ASP Up---------| | 4506 |-------ASP Up Ack------>| | 4507 | | | 4508 |--NOTIFY(AS-INACTIVE)-->| | 4509 | | | 4510 |<----------------------------ASP Up----------------| 4511 |----------------------------ASP Up Ack------------>| 4512 | | | 4513 |--------------------------NOTIFY(AS-INACTIVE)----->| 4514 | | | 4515 | | | 4516 |<-------ASP Active------| | 4517 |------ASP Active Ack--->| | 4518 | | | 4519 |---NOTIFY(AS-ACTIVE)--->| | 4520 |--------------------------NOTIFY(AS-ACTIVE)------->| 4521 | | | 4523 5.1.3 Two ASPs in an Application Server ("1+1" sparing, 4524 loadsharing case) 4526 This scenario shows a similar case to Section 5.1.2 but where the two 4527 ASPs are brought to the state ASP-ACTIVE and subsequently loadshare 4528 the traffic. In this case, one ASP is sufficient to handle the total 4529 traffic load. 4531 SGP ASP1 ASP2 4532 | | | 4533 |<---------ASP Up--------| | 4534 |--------ASP Up Ack----->| | 4535 | | | 4536 |--NOTIFY(AS-INACTIVE)-->| | 4537 | | | 4538 |<-----------------------------ASP Up---------------| 4539 |----------------------------ASP Up Ack------------>| 4540 | | | 4541 |--------------------------NOTIFY(AS-INACTIVE)----->| 4542 | | | 4543 |<--ASP Active (Ldshr)---| | 4544 |-----ASP-Active Ack---->| | 4545 | | | 4546 |---NOTIFY (AS-ACTIVE)-->| | 4547 |-----------------------------NOTIFY(AS-ACTIVE)---->| 4548 | | | 4549 |<---------------------------ASP Active (Ldshr)-----| 4550 |------------------------------ASP Active Ack------>| 4551 | | | 4553 5.1.4 Three ASPs in an Application Server ("n+k" sparing, 4554 loadsharing case) 4556 This scenario shows the example M3UA message flows for the 4557 establishment of traffic between an SGP and three ASPs in the same 4558 Application Server, where two of the ASPs are brought to the state 4559 ASP-ACTIVE and subsequently share the load. In this case, a minimum 4560 of two ASPs are required to handle the total traffic load (2+1 4561 sparing). 4563 SGP ASP1 ASP2 ASP3 4564 | | | | 4565 |<------ASP Up------| | | 4566 |-----ASP Up Ack--->| | | 4567 | | | | 4568 |NTFY(AS-INACTIVE)->| | | 4569 | | | | 4570 |<-------------------------ASP Up-------| | 4571 |------------------------ASP Up Ack---->| | 4572 | | | | 4573 |------------------NOTIFY(AS-INACTIVE)->| | 4574 | | | | 4575 |<--------------------------------------------ASP Up--------| 4576 |--------------------------------------------ASP Up Ack---->| 4577 | | | | 4578 |--------------------------------------NOTIFY(AS-INACTIVE)->| 4579 | | | | 4580 | | | | 4581 |<--ASP Act (Ldshr)-| | | 4582 |----ASP Act Ack--->| | | 4583 | | | | 4584 | | | | 4585 |<-------------------ASP Act. (Ldshr)---| | 4586 |----------------------ASP Act Ack----->| | 4587 | | | | 4588 |--NTFY(AS-ACTIVE)->| | | 4589 |--------------------NOTIFY(AS-ACTIVE)->| | 4590 |----------------------------------------NOTIFY(AS-ACTIVE)->| 4591 | | | | 4592 | | | | 4594 5.2 ASP Traffic Failover Examples 4596 5.2.1 (1+1 Sparing, Withdrawal of ASP, Backup Override) 4598 Following on from the example in Section 5.1.2, and ASP1 withdraws 4599 from service: 4601 SGP ASP1 ASP2 4602 | | | 4603 |<-----ASP Inactive------| | 4604 |----ASP Inactive Ack--->| | 4605 | | | 4606 |----NTFY(AS-PENDING)--->| | 4607 |-----------------------NTFY(AS-PENDING)----------->| 4608 | | | 4609 |<----------------------------- ASP Active----------| 4610 |-----------------------------ASP Active Ack------->| 4611 | | | 4612 |----NTFY(AS-ACTIVE)---->| | 4613 |-----------------------NTFY(AS-ACTIVE)------------>| 4615 Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., 4616 M3UA heartbeat loss or detection of SCTP failure), the initial ASP 4617 Inactive message exchange (i.e., SGP to ASP1) would not occur. 4619 5.2.2 (1+1 Sparing, Backup Override) 4621 Following on from the example in Section 5.1.2, ASP2 wishes to 4622 Override ASP1 and take over the traffic: 4624 SGP ASP1 ASP2 4625 | | | 4626 |<----------------------------- ASP Active----------| 4627 |------------------------------ASP Active Ack------>| 4628 |----NTFY(Alt ASP-Act)-->| 4629 | | | 4631 5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP) 4633 Following on from the example in Section 5.1.4, and ASP1 withdraws 4634 from service: 4636 SGP ASP1 ASP2 ASP3 4637 | | | | 4638 |<----ASP Inact.----| | | 4639 |---ASP Inact Ack-->| | | 4640 | | | | 4641 |--NTFY(Ins. ASPs)->| | | 4642 |---------------------------------------NOTIFY(Ins. ASPs)-->| 4643 | | | | 4644 | | | | 4645 |<----------------------------------------ASP Act (Ldshr)---| 4646 |------------------------------------------ASP Act (Ack)--->| 4647 | | | | 4648 |-NTFY(AS-ACTIVE)-->| | | 4649 |-------------------NOTIFY(AS-ACTIVE)-->| | 4650 |---------------------------------------NOTIFY(AS-ACTIVE)-->| 4651 | | | | 4652 | | | | 4654 For the Notify message to be sent, the SG maintains knowledge of the 4655 minimum ASP resources required (e.g., if the SG knows that "n+k" = 4656 "2+1" for a Loadshare AS and "n" currently equals "1"). 4658 Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA 4659 heartbeat loss or detection of SCTP failure), the initial ASP 4660 Inactive message exchange (i.e., SGP-ASP1) would not occur. 4662 5.3 Normal Withdrawal of an ASP from an Application Server 4663 and Teardown of an Association 4665 An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the 4666 ASP has received an ASP Inactive Ack message) may now proceed to the 4667 ASP-DOWN state, if it is to be removed from service. Following on 4668 from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" 4669 state: 4671 SGP ASP1 4672 | | 4673 |<-----ASP Inactive (RCn)------| RC: Routing Context 4674 |----ASP Inactive Ack (RCn)--->| 4675 | | 4676 |<-----DEREGISTER REQ(RCn)-----| See Notes 4677 | | 4678 |---DEREGISTER RESP(LRCn,RCn)->| 4679 | | 4680 : : 4681 | | 4682 |<-----------ASP Down----------| 4683 |---------ASP Down Ack-------->| 4684 | | 4686 Note: The Deregistration procedure will typically be used if the ASP 4687 previously used the Registration procedures for configuration within 4688 the Application Server. ASP Inactive and Deregister messages 4689 exchanges may contain multiple Routing Contexts. 4691 The ASP should be in the ASP-INACTIVE state and should have 4692 deregistered in all its Routing Contexts before attempting to move to 4693 the ASP-DOWN state. 4695 5.4 Auditing examples 4697 5.4.1 SG State: Uncongested / Available 4699 ASP SGP 4700 --- --- 4701 | -------- DAUD ---------> | 4702 | <------ SCON(0) -------- | 4703 | <------- DAVA ---------- | 4705 5.4.2 SG state: Congested (Congestion Level=2) / Available 4707 ASP SGP 4708 --- --- 4709 | -------- DAUD ---------> | 4710 | <------ SCON(2) -------- | 4711 | <------- DAVA ---------- | 4713 5.4.3 SG state: Unknown / Available 4715 ASP SGP 4716 --- --- 4717 | -------- DAUD ---------> | 4718 | <------- DAVA ---------- | 4720 5.4.4 SG state: Unavailable 4722 ASP SGP 4723 --- --- 4724 | -------- DAUD ---------> | 4725 | <------- DUNA ---------- | 4727 5.5 M3UA/MTP3-User Boundary Examples 4729 5.5.1 At an ASP 4731 This section describes the primitive mapping between the MTP3 User 4732 and the M3UA layer at an ASP. 4734 5.5.1.1 Support for MTP-TRANSFER Primitives at the ASP 4735 5.5.1.1.1 Support for MTP-TRANSFER Request Primitive 4737 When the MTP3-User on the ASP has data to send to a remote MTP3-User, 4738 it uses the MTP-TRANSFER request primitive. The M3UA layer at the 4739 ASP will do the following when it receives an MTP-TRANSFER request 4740 primitive from the M3UA user: 4742 - Determine the correct SGP; 4744 - Determine the correct association to the chosen SGP; 4746 - Determine the correct stream in the association (e.g., 4747 based on SLS); 4749 - Determine whether to complete the optional fields of the DATA 4750 message; 4752 - Map the MTP-TRANSFER request primitive into the Protocol Data 4753 field of a DATA message; 4755 - Send the DATA message to the remote M3UA peer at the SGP, 4756 over the SCTP association. 4758 SGP ASP 4759 | | 4760 |<-----DATA Message-------|<--MTP-TRANSFER req. 4761 | | 4763 5.5.1.1.2 Support for the MTP-TRANSFER Indication Primitive 4765 When the M3UA layer on the ASP receives a DATA message from the M3UA 4766 peer at the remote SGP, it will do the following: 4768 - Evaluate the optional fields of the DATA message, if present; 4770 - Map the Protocol Data field of a DATA message into the 4771 MTP-TRANSFER indication primitive; 4773 - Pass the MTP-TRANSFER indication primitive to the user part. In 4774 case of multiple user parts, the optional fields of the Data 4775 message are used to determine the concerned user part. 4777 SGP ASP 4778 | | 4779 |------Data Message------>|-->MTP-Transfer ind. 4780 | | 4782 5.5.1.1.3 Support for ASP Querying of SS7 Destination States 4784 There are situations such as temporary loss of connectivity to the 4785 SGP that may cause the M3UA layer at the ASP to audit SS7 destination 4786 availability/congestion states. Note: there is no primitive for the 4787 MTP3-User to request this audit from the M3UA layer as this is 4788 initiated by an internal M3UA management function. 4790 SGP ASP 4791 | | 4792 |<----------DAUD-----------| 4793 |<----------DAUD-----------| 4794 |<----------DAUD-----------| 4795 | | 4796 | | 4798 5.5.2 At an SGP 4800 This section describes the primitive mapping between the MTP3-User 4801 and the M3UA layer at an SGP. 4803 5.5.2.1 Support for MTP-TRANSFER Request Primitive at the SGP 4805 When the M3UA layer at the SGP has received DATA messages from its 4806 peer destined to the SS7 network it will do the following: 4808 - Evaluate the optional fields of the DATA message, if present, to 4809 determine the Network Appearance; 4811 - Map the Protocol data field of the DATA message into an 4812 MTP-TRANSFER request primitive; 4814 - Pass the MTP-TRANSFER request primitive to the MTP3 of the 4815 concerned Network Appearance. 4817 SGP ASP 4818 | | 4819 <---MTP-TRANSFER req.|<---------DATA -----------| 4820 | | 4822 5.5.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP 4824 When the MTP3 layer at the SGP has data to pass its user parts, it 4825 will use the MTP-TRANSFER indication primitive. The M3UA layer at 4826 the SGP will do the following when it receives an MTP-TRANSFER 4827 indication primitive: 4829 - Determine the correct AS using the distribution function; 4831 - Select an ASP in the ASP-ACTIVE state 4833 - Determine the correct association to the chosen ASP; 4835 - Determine the correct stream in the SCTP association (e.g., 4836 based on SLS); 4838 - Determine whether to complete the optional fields of the DATA 4839 message; 4841 - Map the MTP-TRANSFER indication primitive into the Protocol Data 4842 field of a DATA message; 4844 - Send the DATA message to the remote M3UA peer in the ASP, over 4845 the SCTP association 4847 SGP ASP 4848 | | 4849 --MTP-TRANSFER ind.->|-----------DATA --------->| 4850 | | 4852 5.5.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication 4853 Primitives 4855 The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from 4856 the MTP3 upper layer interface at the SGP need to be made available 4857 to the remote MTP3 User Part lower layer interface at the concerned 4858 ASP(s). 4860 5.5.2.3.1 Destination Unavailable 4862 The MTP3 layer at the SGP will generate an MTP-PAUSE indication 4863 primitive when it determines locally that an SS7 destination is 4864 unreachable. The M3UA layer will map this primitive to a DUNA 4865 message. The SGP M3UA layer determines the set of concerned ASPs to 4866 be informed based on internal SS7 network information associated with 4867 the MTP-PAUSE indication primitive indication. 4869 SGP ASP 4870 | | 4871 --MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.--> 4872 | | 4874 5.5.2.3.2 Destination Available 4876 The MTP3 at the SGP will generate an MTP-RESUME indication primitive 4877 when it determines locally that an SS7 destination that was 4878 previously unreachable is now reachable. The M3UA layer will map 4879 this primitive to a DAVA message. The SGP M3UA determines the set of 4880 concerned ASPs to be informed based on internal SS7 network 4881 information associated with the MTP-RESUME indication primitive. 4883 SGP ASP 4884 | | 4885 --MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.--> 4886 | | 4888 5.5.2.3.3 SS7 Network Congestion 4890 The MTP3 layer at the SGP will generate an MTP-STATUS indication 4891 primitive when it determines locally that the route to an SS7 4892 destination is congested. The M3UA layer will map this primitive to 4893 a SCON message. It will determine which ASP(s) to send the SCON 4894 message to, based on the intended Application Server. 4896 SGP ASP 4897 | | 4898 --MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.--> 4899 | | 4901 5.5.2.3.4 Destination User Part Unavailable 4903 The MTP3 layer at the SGP will generate an MTP-STATUS indication 4904 primitive when it receives an UPU message from the SS7 network. The 4905 M3UA layer will map this primitive to a DUPU message. It will 4906 determine which ASP(s) to send the DUPU based on the intended 4907 Application Server. 4909 SGP ASP 4910 | | 4911 --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.--> 4912 | | 4914 5.6 Examples for IPSP communication. 4916 These scenarios show a basic example for IPSP communication for the 4917 three phases of the connection (establishment, data exchange, 4918 disconnection). It is assumed that the SCTP association is already 4919 set up. Both single exchange and double exchange behavior are 4920 included for illustrative purposes. 4922 5.6.1 Single exchange 4924 IPSP-A IPSP-B 4925 | | 4926 |-------------ASP Up------------>| 4927 |<----------ASP Up Ack-----------| 4928 | | 4929 |<------- ASP Active(RCb)--------| RC: Routing Context 4930 |-----ASP Active Ack (RCb)------>| (optional) 4931 | | 4932 | | 4933 |<========= DATA (RCb) ========>| 4934 | | 4935 |<-----ASP Inactive (RCb)--------| RC: Routing Context 4936 |----ASP Inactive Ack (RCb)----->| (optional) 4937 | | 4938 |<-----------ASP Down------------| 4939 |---------ASP Down Ack---------->| 4940 | | 4942 Routing Context are previously agreed to be the same in both 4943 directions. 4945 5.6.2 Double exchange 4947 IPSP-A IPSP-B 4948 | | 4949 |<-------------ASP Up------------| 4950 |-----------ASP Up Ack---------->| 4951 | | 4952 |-------------ASP Up------------>| (optional) 4953 |<----------ASP Up Ack-----------| (optional) 4954 | | 4955 |<------- ASP Active(RCb)--------| RC: Routing Context 4956 |-----ASP Active Ack (RCb)------>| (optional) 4957 | | 4958 |------- ASP Active(RCa)-------->| RC: Routing Context 4959 |<-----ASP Active Ack (RCa)------| (optional) 4960 | | 4961 |<========= DATA (RCa) =========| 4962 |========== DATA (RCb) ========>| 4963 | | 4964 |<-----ASP Inactive (RCb)--------| RC: Routing Context 4965 |----ASP Inactive Ack (RCb)----->| 4966 | | 4967 |------ASP Inactive (RCa)------->| RC: Routing Context 4968 |<----ASP Inactive Ack (RCa)-----| 4969 | | 4970 |<-----------ASP Down------------| 4971 |---------ASP Down Ack---------->| 4972 | | 4973 |------------ASP Down----------->| (optional) 4974 |<--------ASP Down Ack-----------| (optional) 4975 | | 4977 In this approach, only one single exchange of ASP Up message can be 4978 considered as enough since the response by the other peer can be 4979 considered as a notice that it is in ASP_UP state. 4981 For the same reason, only one ASP Down message is needed since once 4982 that an IPSP receives ASP_Down ack message it is itself considered as 4983 being in the ASP_Down state and not allowed to receive ASPSM 4984 messages. 4986 6. Security Considerations 4988 Implementations MUST follow the normative guidance of RFC3788 on 4989 the integration and usage of security mechanisms in SIGTRAN 4990 protocols. 4992 7. IANA Considerations 4994 This document contains no new actions for IANA. The subsections 4995 below are retained for historical purposes. 4997 7.1 SCTP Payload Protocol Identifier 4999 IANA has assigned an M3UA value for the Payload Protocol Identifier 5000 in the SCTP DATA chunk. The following SCTP Payload Protocol 5001 Identifier has been registered: 5003 M3UA "3" 5005 The SCTP Payload Protocol Identifier value "3" SHOULD be included in 5006 each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA 5007 protocol. The value "0" (unspecified) is also allowed but any other 5008 values MUST not be used. This Payload Protocol Identifier is not 5009 directly used by SCTP but MAY be used by certain network entities to 5010 identify the type of information being carried in a DATA chunk. 5012 The User Adaptation peer MAY use the Payload Protocol Identifier as a 5013 way of determining additional information about the data being 5014 presented to it by SCTP. 5016 7.2 M3UA Port Number 5018 IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It 5019 is recommended that SGPs use this SCTP port number for listening for 5020 new connections. SGPs MAY also use statically configured SCTP port 5021 numbers instead. 5023 7.3 M3UA Protocol Extensions 5025 This protocol may also be extended through IANA in three ways: 5027 -- through definition of additional message classes, 5028 -- through definition of additional message types, and 5029 -- through definition of additional message parameters 5031 The definition and use of new message classes, types and parameters 5032 is an integral part of SIGTRAN adaptation layers. Thus these 5033 extensions are assigned by IANA through an IETF Consensus action as 5034 defined in Guidelines for Writing an IANA Considerations Section in 5035 RFCs [25]. 5037 The proposed extension must in no way adversely affect the general 5038 working of the protocol. 5040 7.3.1 IETF Defined Message Classes 5042 The documentation for a new message class MUST include the following 5043 information: 5045 (a) A long and short name for the new message class; 5046 (b) A detailed description of the purpose of the message class. 5048 7.3.2 IETF Defined Message Types 5050 The documentation for a new message type MUST include the following 5051 information: 5053 (a) A long and short name for the new message type; 5054 (b) A detailed description of the structure of the message;. 5055 (c) A detailed definition and description of intended use for each 5056 field within the message; 5057 (d) A detailed procedural description of the use of the new 5058 message type within the operation of the protocol; 5059 (e) A detailed description of error conditions when receiving this 5060 message type. 5062 When an implementation receives a message type which it does not 5063 support, it MUST respond with an Error (ERR) message ("Unsupported 5064 Message Type"). 5066 7.3.3 IETF Defined Parameter Extension 5068 Documentation of the message parameter MUST contain the following 5069 information: 5071 (a) Name of the parameter type; 5072 (b) Detailed description of the structure of the parameter field. 5073 This structure MUST conform to the general type-length-value 5074 format described in Section 3.2; 5075 (c) Detailed definition of each component of the parameter value; 5076 (d) Detailed description of the intended use of this parameter 5077 type, and an indication of whether and under what 5078 circumstances multiple instances of this parameter type may be 5079 found within the same message. 5081 8. References 5083 8.1 Normative References 5085 [1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 5086 (SS7) - ISDN User Part (ISUP)" 5088 [2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part" 5090 [3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); 5091 Signalling System No.7; ISDN User Part (ISUP) version 2 for the 5092 international interface; Part 1: Basic services" 5094 [4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 5095 (SS7) - Signalling Connection Control Part (SCCP)" 5097 [5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection 5098 Control Part" 5100 [6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); 5101 Signalling System No.7; Signalling Connection Control Part 5102 (SCCP) (connectionless and connection-oriented class 2) to 5103 support international interconnection; Part 1: Protocol 5104 specification" 5106 [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 5107 (SS7) - Message Transfer Part (MTP)" 5109 [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part" 5111 [9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); 5112 Signalling System No.7; Message Transfer Part (MTP) to support 5113 international interconnection; Part 1: Protocol specification" 5115 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 5116 3629, November 2003. 5118 [11] Loughney, J., Tuexen, M., Pastor-Balbas, J., "Security 5119 Considerations for Signaling Transport (SIGTRAN) Protocols", 5120 RFC 3788, June 2004. 5122 8.2 Informative References 5124 [12] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H., 5125 Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for 5126 Signaling Transport", RFC 2719, October 1999. 5128 [13] ITU-T Recommendation Q.720, "Telephone User Part" 5130 [14] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 5131 (SS7) - Transaction Capabilities (TCAP)" 5133 [15] ANSI T1.114 "Signaling System Number 7 - Transaction 5134 Capabilities Application Part" 5136 [16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); 5137 Signalling System No.7; Transaction Capabilities (TC) version 2; 5138 Part 1: Protocol specification" 5140 [17] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd 5141 Generation partnership Project; Technical Specification Group 5142 Radio Access Network; UTRAN Iu Interface: General Aspects and 5143 Principles" 5145 [18] Stewart, R., Xie, Q., Morneault, K., Sharp, H., Taylor, T., 5146 Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control 5147 Transport Protocol", RFC 2960, October 2000. 5149 [19] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - 5150 Service Specific Coordination Function for signalling at the 5151 Network Node Interface (SSCF at NNI)" 5153 [20] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - 5154 Service Specific Connection Oriented Protocol (SSCOP)" 5156 [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5157 Levels", BCP 14, RFC 2119, March 1997. 5159 [22] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 5160 functions and messages using the services of ITU Recommendation 5161 Q.2140" 5163 [23] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 5164 1997. 5166 [24] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture 5167 for the Internet Protocol", RFC 3168, November 1998. 5169 [25] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 5170 (ESP)", RFC 2406, November 1998. 5172 [26] Maughan, D., Schertler, M., Schneider, M. and J. Turner, 5173 "Internet Security Association and Key Management Protocol", RFC 5174 2408, November 1998. 5176 [27] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA 5177 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 5179 [28] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. 5180 Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) 5181 - User Adaptation Layer", RFC 3331, August 2002. 5183 [29] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation 5184 Layer", Work in Progress. 5186 [30] Telecommunication Technology Committee (TTC) Standard JT-Q704, 5187 "Message Transfer Part Signaling Network Functions", April 28, 5188 1992. 5190 9. Acknowledgements 5192 The authors would like to thank Antonio Roque Alvarez, Joyce 5193 Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, 5194 Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, 5195 Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois 5196 Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal 5197 Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh, 5198 Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo 5199 Watanabe, Ben Wilson and many others for their valuable comments and 5200 suggestions. 5202 10. Document Contributors 5204 Ian Rytina - Ericsson 5205 Guy Mousseau - Nortel Networks 5206 Lyndon Ong - Ciena 5207 Hanns Juergen Schwarzbauer - Siemens 5208 Klaus Gradischnig - Detecon Inc. 5210 Mallesh Kalla - Telcordia 5211 Normand Glaude - Performance Technologies 5212 Brian Bidulock - OpenSS7 5213 John Loughney - Nokia 5214 Greg Sidebottom - Signatus Technologies 5216 11. Change Log (as compared to RFC3332) 5218 Below is a summary of differences between this document and RFC3332. 5220 1. updated security section 5222 2. removed support for CIC and SSN as parameters for Routing Keys 5224 3. fixed grammar and spelling errors 5226 4. updated language on "n+k" redundancy 5228 5. added language to address forward compatibility with future 5229 versions of the protocol 5231 6. fixed language regarding pad octets 5233 7. added additional error return values for Routing Key 5234 Registration 5236 8. clarified text regarding ASP states and state changes 5238 9. clarified text regarding IPSP SE and DE models, updated state 5239 diagrams to include IPSP information 5241 10. fixed a few errors in message flow examples 5243 Appendix A 5245 A.1 Signalling Network Architecture 5247 A Signalling Gateway is used to support the transport of MTP3-User 5248 signalling traffic received from the SS7 network to multiple 5249 distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA 5250 protocol is not designed to meet the performance and reliability 5251 requirements for such transport by itself. However, the conjunction 5252 of distributed architecture and redundant networks provides support 5253 for reliable transport of signalling traffic over IP. The M3UA 5254 protocol is flexible enough to allow its operation and management in 5255 a variety of physical configurations, enabling Network Operators to 5256 meet their performance and reliability requirements. 5258 To meet the stringent SS7 signalling reliability and performance 5259 requirements for carrier grade networks, Network Operators might 5260 require that no single point of failure is present in the end-to-end 5261 network architecture between an SS7 node and an IP-based application. 5262 This can typically be achieved through the use of redundant SGPs or 5263 SGs, redundant hosts, and the provision of redundant QOS-bounded IP 5264 network paths for SCTP Associations between SCTP End Points. 5265 Obviously, the reliability of the SG, the MGC and other IP-based 5266 functional elements also needs to be taken into account. The 5267 distribution of ASPs and SGPs within the available Hosts MAY also be 5268 considered. As an example, for a particular Application Server, the 5269 related ASPs could be distributed over at least two Hosts. 5271 One example of a physical network architecture relevant to SS7 5272 carrier grade operation in the IP network domain is shown in Figure A- 5273 1 below: 5275 SGs MGCs 5277 Host#1 ************** ************** Host#3 5278 * ********__*__________________________*__******** * = 5279 * *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1 5280 * ******** * \ / * ******** * 5281 * ********__*______\__/________________*__******** * 5282 * *SGP2.1*__*_______\/______ _____*__* ASP2 * * 5283 * ******** * /\ | | * ******** * 5284 * : * / \ | | * : * 5285 * ******** * / \ | | * ******** * 5286 * * SGPn * * | | | | * * ASPn * * 5287 * ******** * | | | | * ******** * 5288 ************** | | | | ************** 5289 | | \ / 5290 Host#2 ************** | | \ / ************** Host#4 5291 * ********__*_____| |______\/_______*__******** * = 5292 * *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2 5293 * ******** * / \ * ******** * 5294 * ********__*_______________/ \_____*__******** * 5295 * *SGP2.2*__*__________________________*__* ASP2 * * 5296 * ******** * * ******** * 5297 * : * SCTP Associations * : * 5298 * ******** * * ******** * 5299 * * SGPn * * * * ASPn * * 5300 * ******** * * ******** * 5301 ************** ************** 5303 SGP1.1 and SGP1.2 are part of SG1 5304 SGP2.1 and SGP2.2 are part of SG2 5306 Figure A-1 - Physical Model 5308 In this model, each host may have many application processes. In the 5309 case of the MGC, an ASP may provide service to one or more 5310 Application Servers, and is identified as an SCTP end point. One or 5311 more Signalling Gateway Processes make up a single Signalling 5312 Gateway. 5314 This example model can also be applied to IPSP-IPSP signalling. In 5315 this case, each IPSP may have its services distributed across 2 hosts 5316 or more, and may have multiple server processes on each host. 5318 In the example above, each signalling process (SGP, ASP or IPSP) is 5319 the end point to more than one SCTP association, leading to more than 5320 one other signalling processes. To support this, a signalling 5321 process must be able to support distribution of M3UA messages to many 5322 simultaneous active associations. This message distribution function 5323 is based on the status of provisioned Routing Keys, the status of the 5324 signalling routes to signalling points in the SS7 network, and the 5325 redundancy model (active-standby, load sharing, broadcast, n+k) of 5326 the remote signalling processes. 5328 For carrier grade networks, the failure or isolation of a particular 5329 signalling process should not cause stable calls or transactions to 5330 be lost. This implies that signalling processes need, in some cases, 5331 to share the call/transaction state or be able to pass the call state 5332 information between each other. In the case of ASPs performing call 5333 processing, coordination may also be required with the related Media 5334 Gateway to transfer the MGC control for a particular trunk 5335 termination. However, this sharing or communication of 5336 call/transaction state information is outside the scope of this 5337 document. 5339 This model serves as an example. M3UA imposes no restrictions as to 5340 the exact layout of the network elements, the message distribution 5341 algorithms and the distribution of the signalling processes. 5342 Instead, it provides a framework and a set of messages that allow for 5343 a flexible and scalable signalling network architecture, aiming to 5344 provide reliability and performance. 5346 A.2 Redundancy Models 5348 A.2.1 Application Server Redundancy 5350 At the SGP, an Application Server list contains active and inactive 5351 ASPs to support ASP broadcast, loadsharing and failover procedures. 5352 The list of ASPs within a logical Application Server is kept updated 5353 in the SGP to reflect the active Application Server Process(es). 5355 For example, in the network shown in Figure 1, all messages to DPC x 5356 could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1 5357 in Host 1 might look like the following: 5359 Routing Key {DPC=x) - "Application Server #1" 5360 ASP1/Host3 - State = Active 5361 ASP1/Host4 - State = Inactive 5363 In this "1+1" redundancy case, ASP1 in Host3 would be sent any 5364 incoming message with DPC=x. ASP1 in Host4 would normally be brought 5365 to the "active" state upon failure of, or loss of connectivity to, 5366 ASP1/Host1. 5368 The AS List at SGP1 in Host1 might also be set up in loadshare mode: 5370 Routing Key {DPC=x) - "Application Server #1" 5371 ASP1/Host3 - State = Active 5372 ASP1/Host4 - State = Active 5374 In this case, both the ASPs would be sent a portion of the traffic. 5375 For example the two ASPs could together form a database, where 5376 incoming queries may be sent to any active ASP. 5378 Care might need to be exercised by a Network Operator in the 5379 selection of the routing information to be used as the Routing Key 5380 for a particular AS. 5382 In the process of failover, it is recommended that in the case of 5383 ASPs supporting call processing, stable calls do not fail. It is 5384 possible that calls in "transition" may fail, although measures of 5385 communication between the ASPs involved can be used to mitigate this. 5387 For example, the two ASPs may share call state via shared memory, or 5388 may use an ASP to ASP protocol to pass call state information. Any 5389 ASP-to-ASP protocol to support this function is outside the scope of 5390 this document. 5392 A.2.2 Signalling Gateway Redundancy 5394 Signalling Gateways may also be distributed over multiple hosts. 5395 Much like the AS model, SGs may comprise one or more SG Processes 5396 (SGPs), distributed over one or more hosts, using an active/backup or 5397 a loadsharing model. Should an SGP lose all or partial SS7 5398 connectivity and other SGPs exist, the SGP may terminate the SCTP 5399 associations to the concerned ASPs. 5401 It is therefore possible for an ASP to route signalling messages 5402 destined to the SS7 network using more than one SGP. In this model, 5403 a Signalling Gateway is deployed as a cluster of hosts acting as a 5404 single SG. A primary/backup redundancy model is possible, where the 5405 unavailability of the SCTP association to a primary SGP could be used 5406 to reroute affected traffic to an alternate SGP. A loadsharing model 5407 is possible, where the signalling messages are loadshared between 5408 multiple SGPs. A broadcast model is also possible, where signalling 5409 messages are sent to each active SGP in the SG. The distribution of 5410 the MTP3-user messages over the SGPs should be done in such a way to 5411 minimize message missequencing, as required by the SS7 User Parts. 5413 It may also be possible for an ASP to use more than one SG to access 5414 a specific SS7 end point, in a model that resembles an SS7 STP mated 5415 pair. Typically, SS7 STPs are deployed in mated pairs, with traffic 5416 loadshared between them. Other models are also possible, subject to 5417 the limitations of the local SS7 network provisioning guidelines. 5419 From the perspective of the M3UA layer at an ASP, a particular SG is 5420 capable of transferring traffic to a provisioned SS7 destination X if 5421 an SCTP association with at least one SGP of the SG is established, 5422 the SGP has returned an acknowledgement to the ASP to indicate that 5423 the ASP is actively handling traffic for that destination X, the SGP 5424 has not indicated that the destination X is inaccessible and the SGP 5425 has not indicated MTP Restart. When an ASP is configured to use 5426 multiple SGPs for transferring traffic to the SS7 network, the ASP 5427 must maintain knowledge of the current capability of the SGPs to 5428 handle traffic to destinations of interest. This information is 5429 crucial to the overall reliability of the service, for active/backup, 5430 loadsharing and broadcast models, in the event of failures, recovery 5431 and maintenance activities. The ASP M3UA may also use this 5432 information for congestion avoidance purposes. The distribution of 5433 the MTP3-user messages over the SGPs should be done in such a way to 5434 minimize message missequencing, as required by the SS7 User Parts. 5436 Editors' Addresses 5438 Ken Morneault 5439 Cisco Systems Inc. 5440 13615 Dulles Technology Drive 5441 Herndon, VA, USA 20171 5443 EMail: kmorneau@cisco.com 5445 Javier Pastor-Balbas 5446 Ericsson Espana S.A. 5447 C/ Retama 1 5448 28045 Madrid - Spain 5450 EMail: j.javier.pastor@ericsson.com 5452 Intellectual Property Statement 5454 The IETF takes no position regarding the validity or scope of any 5455 Intellectual Property Rights or other rights that might be claimed to 5456 pertain to the implementation or use of the technology described in 5457 this document or the extent to which any license under such rights 5458 might or might not be available; nor does it represent that it has 5459 made any independent effort to identify any such rights. Information 5460 on the procedures with respect to rights in RFC documents can be 5461 found in BCP 78 and BCP 79. 5463 Copies of IPR disclosures made to the IETF Secretariat and any 5464 assurances of licenses to be made available, or the result of an 5465 attempt made to obtain a general license or permission for the use of 5466 such proprietary rights by implementers or users of this 5467 specification can be obtained from the IETF on-line IPR repository at 5468 http://www.ietf.org/ipr. 5470 The IETF invites any interested party to bring to its attention any 5471 copyrights, patents or patent applications, or other proprietary 5472 rights that may cover technology that may be required to implement 5473 this standard. Please address the information to the IETF at 5474 ietf-ipr@ietf.org. 5476 Disclaimer of Validity 5478 This document and the information contained herein are provided on an 5479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5481 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5482 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5483 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5486 Copyright Statement 5488 Copyright (C) The Internet Society (2006). This document is subject 5489 to the rights, licenses and restrictions contained in BCP 78, and 5490 except as set forth therein, the authors retain all their rights. 5492 Acknowledgment 5494 Funding for the RFC Editor function is currently provided by the 5495 Internet Society.