idnits 2.17.1 draft-ietf-sigtran-m2ua-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 10) being 87 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 76 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 25: '... that other groups MAY also distribute...' RFC 2119 keyword, line 29: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 139: '...cess. Fail-back MAY apply upon the re...' RFC 2119 keyword, line 257: '...Note: STPs MAY be present in the SS7 p...' RFC 2119 keyword, line 276: '... the SCTP functions above MAY NOT be a...' (153 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2904 has weird spacing: '...imitive carry...' == Line 3166 has weird spacing: '...essages until...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the network in which M2UA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [11] for more information on configuring IPSEC services. -- 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 (Dec 2001) is 8161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 692 -- Looks like a reference, but probably isn't: 'M3UA' on line 739 -- Looks like a reference, but probably isn't: 'IUA' on line 744 -- Looks like a reference, but probably isn't: 'M2UA' on line 745 -- Looks like a reference, but probably isn't: 'SUA' on line 747 == Missing Reference: '13' is mentioned on line 2634, but not defined -- Looks like a reference, but probably isn't: 'RFC2434' on line 3835 == Unused Reference: '8' is defined on line 3914, 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' -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '5') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-00 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Cisco Systems 3 Ram Dantu 4 NetRake 5 Greg Sidebottom 6 gregside consulting 7 Tom George 8 Alcatel 9 Brian Bidulock 10 OpenSS7 11 Jacob Heitz 12 Lucent 14 Expires in May 2002 Dec 2001 16 Signaling System 7 (SS7) Message Transfer Part (MTP) 2 - 17 User Adaptation Layer 18 20 Status of This Memo 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC 2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups MAY also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and MAY be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as 'work in progress'. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 To learn the current status of any Internet-Draft, please check the 40 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 41 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 42 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 43 ftp.isi.edu (US West Coast). 45 Abstract 47 This Internet Draft defines a protocol for backhauling of SS7 MTP2 48 User signalling messages over IP using the Stream Control 49 Transmission Protocol (SCTP). This protocol would be used between a 50 Signalling Gateway (SG) and Media Gateway Controller (MGC). It is 51 assumed that the SG receives SS7 signalling over a standard SS7 52 interface using the SS7 Message Transfer Part (MTP) to provide 53 transport. The Signalling Gateway would act as a Signalling Link 54 Terminal. 56 TABLE OF CONTENTS 58 1. Introduction..............................................3 59 1.1 Scope..................................................3 60 1.2 Terminology............................................3 61 1.3 Signalling Transport Architecture......................5 62 1.4 Services Provide by the M2UA Adaptation Layer..........7 63 1.5 Function Provided by the M2UA Layer....................9 64 1.6 Definition of the M2UA Boundaries.....................11 65 2. Conventions..............................................13 66 3. Protocol Elements........................................13 67 3.1 Common Message Header.................................13 68 3.2 M2UA Message Header...................................17 69 3.3 M2UA Messages.........................................18 70 4. Procedures...............................................48 71 4.1 Procedures to Support the M2UA-User Layer.............49 72 4.2 Receipt of Primitives from the Layer Management.......49 73 4.3 AS and ASP State Maintenance..........................51 74 4.4 Link Key Management Procedures........................62 75 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......63 76 5.1 Establishment of associations between SG and MGC......63 77 examples 78 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........66 79 5.3 Layer Management Communication Examples...............66 80 6. Timers...................................................71 81 7. Security Considerations..................................71 82 7.1 Threats................................................71 83 7.2 Protecting Confidentiality.............................72 84 8. IANA Considerations......................................72 85 8.1 SCTP Payload Protocol Identifier.......................72 86 8.2 IUA Protocol Extensions................................72 87 9. Acknowledgements.........................................74 88 10. References...............................................74 89 11. Author's Addresses.......................................75 90 1. Introduction 92 This draft defines a protocol for the backhauling of SS7 [1] MTP2 User 93 [2] [3] (i.e. MTP3) signalling messages over IP using the Stream Control 94 Transmission Protocol (SCTP) [5]. This protocol would be used between 95 a Signalling Gateway (SG) and Media Gateway Controller (MGC). 97 1.1 Scope 99 There is a need for Switched Circuit Network (SCN) signalling protocol 100 delivery from an Signalling Gateway (SG) to a Media Gateway 101 Controller (MGC) [6]. The delivery mechanism addresses the following 102 objectives: 104 * Support for MTP Level 2 / MTP Level 3 interface boundary 105 * Support for communication between Layer Management modules on SG 106 and MGC 107 * Support for management of SCTP active associations between the SG and 108 MGC 110 The SG will terminate up to MTP Level 2 and the MGC will terminate 111 MTP Level 3 and above. In other words, the SG will transport MTP 112 Level 3 messages over an IP network to a MGC. 114 1.2 Terminology 116 Application Server (AS) - A logical entity serving a specific application 117 instance. An example of an Application Server is a MGC handling the 118 MTP Level 3 and call processing for SS7 links terminated by the 119 Signalling Gateways. Practically speaking, an AS is modeled at the SG 120 as an ordered list of one or more related Application Server Processes 121 (e.g., primary, secondary, tertiary, ...). 123 Application Server Process (ASP) - A process instance of an Application 124 Server. Examples of Application Server Processes are active or standby 125 MGC instances. 127 Association - An association refers to a SCTP association. The 128 association will provide the transport for the delivery of protocol 129 data units for one or more interfaces. 131 Backhaul - Refers to the transport of signalling from the point of 132 interface for the associated data stream (i.e., SG function in the MGU) 133 back to the point of call processing (i.e., the MGCU), if this is not 134 local [4]. 136 Fail-over - The capability to reroute signalling traffic as required 137 to an alternate Application Server Process within an Application Server 138 in the event of failure or unavailability of a currently used Application 139 Server Process. Fail-back MAY apply upon the return to service of a 140 previously unavailable Application Server Process. 142 Host - The computing platform that the ASP process is running on. 144 Interface - For the purposes of this document, an interface is a SS7 145 signalling link. 147 Interface Identifier - The Interface Identifier identifies the physical 148 interface at the SG for which the signalling messages are sent/received. 149 The format of the Interface Identifier parameter can be text or integer, 150 the values of which are assigned according to network operator policy. 151 The values used are of local significance only, coordinated between the 152 SG and ASP. 154 Layer Management - Layer Management is a nodal function in an SG or 155 ASP that handles the inputs and outputs between the M2UA layer and a 156 local management entity. 158 Link Key - The link key is a locally unique (between ASP and SG) 159 value that identifies a registration request for a particular 160 Signalling Data Link and Signalling Terminal pair. 162 MTP - The Message Transfer Part of the SS7 protocol 164 MTP2 - MTP Level 2, the signalling datalink layer of SS7 166 MTP3 - MTP Level 3, the signalling network layer of SS7 168 MTP2-User - A protocol that uses the services of MTP Level 2 169 (i.e. MTP3). 171 Network Byte Order: Most significant byte first, a.k.a Big Endian. 173 Signalling Data Link - An SDL refers to a specific communications 174 facility that connects two Signalling Link Terminals. 176 Signalling Gateway (SG) - An SG is a signalling agent at the edge of 177 the IP network. An SG appears to the SS7 as one or more Signalling 178 Link Terminals that are connected to one or more Signalling Data Links 179 in the SS7 network. An SG contains a set of one or more unique 180 Signalling Gateway Processes, on which one or more is normally 181 actively processing traffic. Where an SG contains more than one SGP, 182 the SG is a logical entity. 184 Signalling Gateway Process (SGP) - A process instance that uses M2UA to 185 communicate to and from a Signalling Link Terminal. It serves as an 186 active, backup or load-sharing proces of a Signalling Gateway. 188 Signalling Link Terminal (SLT) - Refers to the means of performing all 189 of the functions defined at MTP level 2 regardless of their 190 implementation [2]. 192 Stream - A stream refers to an SCTP stream; a unidirectional logical 193 channel established from one SCTP endpoint to another associated SCTP 194 endpoint, within which all user messages are delivered in-sequence 195 except for those submitted to the unordered delivery service. 197 1.3 M2UA Overview 199 The framework architecture that has been defined for SCN signalling 200 transport over IP [6] uses two components: a signalling common 201 transport protocol and an adaptation module to support the services 202 expected by a particular SCN signalling protocol from its underlying 203 protocol layer. 205 Within this framework architecture, this document defines a SCN 206 adaptation module that is suitable for the transport of SS7 MTP2 User 207 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 208 of the Stream Control Transmission Protocol [5] as the underlying 209 reliable signalling common transport protocol. 211 In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling 212 is transmitted and received from the PSTN over a standard SS7 network 213 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 214 to provide reliable transport of the MTP3-User signalling messages to and 215 from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). 216 The SG then provides a interworking of transport functions 217 with the IP transport, in order to transfer the MTP2-User signalling 218 messages to and from an Application Server Process where the peer MTP2- 219 User protocol layer exists. 221 1.3.1 Example - SG to MGC 223 In a Signalling Gateway, it is expected that the SS7 signalling is 224 received over a standard SS7 network termination, using the SS7 Message 225 Transfer Part (MTP) to provide transport of SS7 signalling messages to 226 and from an SS7 Signalling End Point (SEP) or SS7 Signalling Transfer 227 Point (STP). In other words, the SG acts as a Signalling Link Terminal 228 (SLT) [2]. The SG then provides interworking of transport functions 229 with IP Signalling Transport, in order to transport the MTP3 signalling 230 messages to the MGC where the peer MTP3 protocol layer exists, as shown 231 below: 233 ****** SS7 ****** IP ******* 234 *SEP *-----------* SG *-------------* MGC * 235 ****** ****** ******* 237 +----+ +----+ 238 |S7UP| |S7UP| 239 +----+ +----+ 240 |MTP + |MTP | 241 | L3 | (NIF) |L3 | 242 +----+ +----+----+ +----+ 243 |MTP | |MTP |M2UA| |M2UA| 244 | | | +----+ +----+ 245 |L2 | |L2 |SCTP| |SCTP| 246 |L1 | |L1 +----+ +----+ 247 | | | |IP | |IP | 248 +----+ +---------+ +----+ 250 NIF - Nodal Interworking Function 251 SEP - SS7 Signalling Endpoint 252 IP - Internet Protocol 253 SCTP - Stream Control Transmission Protocol (Reference [5]) 255 Figure 1 M2UA in the SG to MGC Application 257 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 259 It is recommended that the M2UA use the services of the Stream 260 Control Transmission Protocol (SCTP) as the underlying reliable 261 common signalling transport protocol. The use of SCTP provides 262 the following features: 264 - explicit packet-oriented delivery (not stream-oriented) 265 - sequenced delivery of user messages within multiple streams, 266 with an option for order-of-arrival delivery of individual 267 user messages, 268 - optional multiplexing of user messages into SCTP datagrams, 269 - network-level fault tolerance through support of multi-homing 270 at either or both ends of an association, 271 - resistance to flooding and masquerade attacks, and 272 - data segmentation to conform to discovered path MTU size 274 There are scenarios without redundancy requirements and 275 scenarios in which redundancy is supported below the transport 276 layer. In these cases, the SCTP functions above MAY NOT be a 277 requirement and TCP can be used as the underlying common 278 transport protocol. 280 1.3.2 ASP Fail-over Model and Terminology 282 The M2UA layer supports ASP fail-over functions in order to support a 283 high availability of call and transaction processing capability. All 284 MTP2-User messages incoming to a SGP from the SS7 network are assigned 285 to the unique Application Server, based on the Interface Identifier of 286 the message. 288 The M2UA layer supports a n+k redundancy model (active-standby, 289 loadsharing, broadcast) where n is the minimum number of redundant 290 ASPs required to handle traffic and k ASPs are available to take over 291 for a failed or unavailable ASP. Note that 1+1 active/standby 292 redundancy is a subset of this model. A simplex 1+0 model is also 293 supported as a subset, with no ASP redundancy. 295 1.3.3 Client/Server Model 297 It is recommended that the SGP and ASP be able to support both client 298 and server operation. The peer endpoints using M2UA SHOULD be 299 configured so that one always takes on the role of client and the 300 other the role of server for initiating SCTP associations. The 301 default orientation would be for the SGP to take on the role of server 302 while the ASP is the client. In this case, ASPs SHOULD initiate the 303 SCTP association to the SGP. 305 The SCTP and TCP Registered User Port Number Assignment for M2UA 306 is 2904. 308 1.4 Services Provided by the M2UA Adaptation Layer 310 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 311 point in the IP network, so that the M2UA protocol layer is required to 312 provide the equivalent set of services to its users as provided by the 313 MTP Level 2 to MTP Level 3. 315 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 317 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 318 a seamless, or as seamless as possible, operation of the MTP2-User peers 319 in the SS7 and IP domains. An example of the primitives that need to be 320 supported can be found in [7]. 322 1.4.2 Support for communication between Layer Management modules 323 on SG and MGC 325 The M2UA layer needs to provide some messages that will facilitate 326 communication between Layer Management modules on the SG and MGC. 328 To facilitate reporting of errors that arise because of backhauling MTP 329 Level 3 scenario, the following primitive is defined: 331 M-ERROR 333 The M-ERROR message is used to indicate an error with a received 334 M2UA message (e.g., an interface identifier value is not known to the 335 SG). 337 1.4.3 Support for management of active associations between SG and MGC 339 The M2UA layer on the SG keeps the state of the configured ASPs. A set 340 of primitives between M2UA layer and the Layer Management are defined 341 below to help the Layer Management manage the association(s) between 342 the SG and the MGC. The M2UA layer can be instructed by the Layer 343 Management to establish a SCTP association to a peer M2UA node. This 344 procedure can be achieved using the M-SCTP ESTABLISH primitive. 346 M-SCTP_ESTABLISH 348 The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm 349 the establishment of a SCTP association to a peer M2UA node. 351 M-SCTP_RELEASE 353 The M-SCTP_RELEASE primitives are used to request, indicate, and 354 confirm the release of a SCTP association to a peer M2UA node. 356 The M2UA layer MAY also need to inform the status of the SCTP 357 association(s) to the Layer Management. This can be achieved using 358 the following primitive. 360 M-SCTP_STATUS 362 The M-SCTP_STATUS primitive is used to request and indicate the status 363 of underlying SCTP association(s). 365 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 366 status (i.e., failure, active, etc.), so that messages can be exchanged 367 between M2UA layer peers to stop traffic to the local M2UA user. This 368 can be achieved using the following primitive. 370 M-ASP_STATUS 372 The ASP status is stored inside M2UA layer on both the SG and MGC 373 sides. The M-ASP_STATUS primitive can be used by Layer Management to 374 request the status of the Application Server Process from the M2UA 375 layer. This primitive can also be used to indicate the status of the 376 Application Server Process. 378 M-ASP_MODIFY 380 The M-ASP_MODIFY primitive can be used by Layer Management to modify 381 the status of the Application Server Process. In other words, the 382 Layer Management on the ASP side uses this primitive to initiate 383 the ASPM procedures. 385 M-AS_STATUS 387 The M-AS_STATUS primitive can be used by Layer Management to request 388 the status of the Application Server. This primitive can also be 389 used to indicate the status of the Application Server. 391 1.5 Functions Provided by the M2UA Layer 393 1.5.1 Mapping 395 The M2UA layer MUST maintain a map of a Interface ID to a physical 396 interface on the Signalling Gateway. A physical interface would be a 397 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 398 MUST also maintain a map of Interface Identifier to SCTP association 399 and to the related stream within the association. 401 The SGP maps an Interface Identifier to an SCTP association/stream 402 only when an ASP sends an ASP Active message for a particular Interface 403 Identifier. It MUST be noted, however, that this mapping is dynamic 404 and could change at any time due to a change of ASP state. This mapping 405 could even temporarily be invalid, for example during failover of one 406 ASP to another. Therefore, the SGP MUST maintain the states of AS/ASP 407 and reference them during the routing of an messages to an AS/ASP. 409 Note that only one SGP SHOULD provide Signalling Link Terminal 410 services to an SS7 link. Therefore, within an SG, an Application 411 Server MUST be active for only one SGP at any given point in time. 413 An example of the logical view of relationship between SS7 link, 414 Interface Identifier, AS and ASP in an SGP is shown below: 416 /-------------------------------------------------+ 417 / /----------------------------------------------|--+ 418 / / v | 419 / / +----+ act+-----+ +-------+ -+--+|-+- 420 SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v 421 / +----+ | +----+ | +-----+ +-------+ -+--+--+- 422 / +->| AS |--+ Streams 423 / +----+ | +----+ stb+-----+ 424 SS7 link2-------->|IID |-+ | ASP | 425 +----+ +-----+ 427 where IID = Interface Identifier 429 A SGP MAY support more than one AS. An AS MAY support more than 430 one Interface Identifier. 432 1.5.2 Support for the management of SCTP associations between the 433 SGPs and ASPs 435 The M2UA layer at the SG maintains the availability state of all 436 configured ASPs, in order to manage the SCTP associations and the 437 traffic between the SG and ASPs. As well, the active/inactive state 438 of remote ASP(s) are also maintained. The Active ASP(s) are the 439 one(s) currently receiving traffic from the SG. 441 The M2UA layer MAY be instructed by local management to establish an 442 SCTP association to a peer M2UA node. This can be achieved using the 443 M-SCTP_ESTABLISH primitive to request, indicate and confirm the 444 establishment of an SCTP association with a peer M2UA node. 446 The M2UA layer MAY also need to inform local management of the status of 447 the underlying SCTP associations using the M-SCTP_STATUS request and 448 indication primitive. For example, the M2UA MAY inform local management 449 of the reason for the release of an SCTP association, determined either 450 locally within the M2UA layer or by a primitive from the SCTP. 452 Also the M2UA layer may need to inform the local management of the 453 change in status of an ASP or AS. This may be achieved using the M-ASP 454 STATUS request or M-AS_STATUS request primitives. 456 1.5.3 Status of ASPs 458 The M2UA layer on the SG MUST maintain the state of the ASPs it is 459 supporting. The state of an ASP changes because of reception of 460 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 461 or reception of indications from the local SCTP association. ASP 462 state transition procedures are described in Section 4.3.1. 464 At a SGP, an Application Server list MAY contain active and inactive 465 ASPs to support ASP fail-over procedures. When, for example, both 466 a primary and a backup ASP are available, M2UA peer protocol is 467 required to control which ASP is currently active. The ordered 468 list of ASPs within a logical Application Server is kept updated in 469 the SGP to reflect the active Application Server Process. 471 Also the M2UA layer MAY need to inform the local management of the 472 change in status of an ASP or AS. This can be achieved using the M-ASP 473 STATUS or M-AS_STATUS primitives. 475 1.5.4 SCTP Specifics 477 1.5.4.1 SCTP Stream Management 479 SCTP allows a user specified number of streams to be opened during 480 initialization of the association. It is the responsibility of the 481 M2UA layer to ensure proper management of these streams. Because of 482 the unidirectional nature of streams, a M2UA layer is not aware of the 483 stream information from its peer M2UA layer. Instead, the Interface 484 Identifier is in the M2UA message header. 486 The use of SCTP streams within M2UA is recommended in order to minimize 487 transmission and buffering delay, therefore improving the overall 488 performance and reliability of the signalling elements. A separate 489 SCTP stream can be used for each SS7 link. Or, an implementation may 490 choose to split the SS7 link across several streams based on SLS. 491 This method may be of particular interest for high speed SS7 links 492 (MTP3b) since high speed links have a 24-bit sequence number and the 493 stream sequence number is 16-bits. 495 SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) 496 messages (see Section 3) since stream '0' SHOULD only be used for ASP 497 Management (ASPM) messages (see Section 4.3.3). 499 1.5.5 Seamless SS7 Network Management Interworking 501 The M2UA layer on the SGP SHOULD pass an indication of unavailability 502 of the M2UA-User (MTP3) to the local Layer Management, if the 503 currently active ASP moves from the ACTIVE state. The actions taken by 504 M2UAon the SGP with regards to MTP Level 2 should be in accordance 505 with the appropriate MTP specifications. 507 1.5.6 Flow Control / Congestion 509 It is possible for the M2UA layer to be informed of IP network 510 congestion onset and abatement by means of an implementation dependent 511 function (i.e. an indication from the SCTP). The handling of 512 this congestion indication by M2UA is implementation dependent. 513 However, the actions taken by the SG should be accordance with the 514 appropriate MTP specification and should enable SS7 functionality 515 (e.g. flow control) to be correctly maintained. 517 1.5.7 Audit of SS7 Link State 519 After a failover of one ASP to another ASP, it may be necessary for the 520 M2UA on the ASP to audit the current SS7 link state to ensure consistency. 521 The M2UA on the SGP would respond to the audit request with information 522 regarding the current state of the SS7 link (i.e. in-service, 523 out-of-service, congestion state, LPO/RPO state). 525 1.6 Definition of the M2UA Boundaries 527 1.6.1 Definition of the M2UA / MTP Level 3 boundary 529 DATA 530 ESTABLISH 531 RELEASE 532 STATE 533 DATA RETRIEVAL 534 DATA RETRIEVAL COMPLETE 536 1.6.2 Definition of the M2UA / MTP Level 2 boundary 538 DATA 539 ESTABLISH 540 RELEASE 541 STATE 542 DATA RETRIEVAL 543 DATA RETRIEVAL COMPLETE 545 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 547 The upper layer and layer management primitives provided by SCTP are 548 provided in Reference [5] Section 9. 550 1.6.4 Definition of Layer Management / M2UA Boundary 552 M-SCTP_ESTABLISH request 553 Direction: LM -> M2UA 554 Purpose: LM requests ASP to establish an SCTP association with an 555 SGP. 557 M-SCTP_ESTABLISH confirm 558 Direction: M2UA -> LM 559 Purpose: ASP confirms to LM that it has established an SCTP 560 association with an SGP. 562 M-SCTP_ESTABLISH indication 563 Direction: M2UA -> LM 564 Purpose: SGP informs LM that an ASP has established an SCTP 565 association. 567 M-SCTP_RELEASE request 568 Direction: LM -> M2UA 569 Purpose: LM requests ASP to release an SCTP association with SGP. 571 M-SCTP_RELEASE confirm 572 Direction: M2UA -> LM 573 Purpose: ASP confirms to LM that it has released SCTP association 574 with SGP. 576 M-SCTP_RELEASE indication 577 Direction: M2UA -> LM 578 Purpose: SGP informs LM that ASP has released an SCTP association. 580 M-SCTP_RESTART indication 581 Direction: M2UA -> LM 582 Purpose: M2UA informs LM that a SCTP Restart indication has 583 been received. 585 M-SCTP_STATUS request 586 Direction: LM -> M2UA 587 Purpose: LM requests M2UA to report status of SCTP association. 589 M-SCTP_STATUS indication 590 Direction: M2UA -> LM 591 Purpose: M2UA reports status of SCTP association. 593 M-ASP_STATUS request 594 Direction: LM -> M2UA 595 Purpose: LM requests SGP to report status of remote ASP. 597 M-ASP_STATUS indication 598 Direction: M2UA -> LM 599 Purpose: SGP reports status of remote ASP. 601 M-AS_STATUS request 602 Direction: LM -> M2UA 603 Purpose: LM requests SG to report status of AS. 605 M-AS_STATUS indication 606 Direction: M2UA -> LM 607 Purpose: SG reports status of AS. 609 M-NOTIFY indication 610 Direction: M2UA -> LM 611 Purpose: ASP reports that it has received a NOTIFY message 612 from its peer. 614 M-ERROR indication 615 Direction: M2UA -> LM 616 Purpose: ASP or SGP reports that it has received an ERROR 617 message from its peer. 619 M-ASP_UP request 620 Direction: LM -> M2UA 621 Purpose: LM requests ASP to start its operation and send an ASP UP 622 message to the SGP. 624 M-ASP_UP confirm 625 Direction: M2UA -> LM 626 Purpose: ASP reports that it has received an ASP UP Acknowledgement 627 message from the SGP. 629 M-ASP_DOWN request 630 Direction: LM -> M2UA 631 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 632 message to the SGP. 634 M-ASP_DOWN confirm 635 Direction: M2UA -> LM 636 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 637 message from the SGP. 639 M-ASP_ACTIVE request 640 Direction: LM -> M2UA 641 Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP. 643 M-ASP_ACTIVE confirm 644 Direction: M2UA -> LM 645 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 646 message from the SGP. 648 M-ASP_INACTIVE request 649 Direction: LM -> M2UA 650 Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP. 652 M-ASP_INACTIVE confirm 653 Direction: M2UA -> LM 654 Purpose: ASP reports that is has received an ASP INACTIVE 655 Acknowledgement message from the SGP. 657 M-LINK_KEY_REG Request 658 Direction: LM -> M2UA 659 Purpose: LM requests ASP to register Link Key with SG by sending REG 660 REQ message. 662 M-LINK_KEY_REG Confirm 663 Direction: M2UA -> LM 664 Purpose: ASP reports to LM that it has successfully received a REG 665 RSP message from SG. 667 M-LINK_KEY_REG Indication 668 Direction: M2UA -> LM 669 Purpose: SG reports to LM that it has successfully processed an 670 incoming REG REQ message from ASP. 672 M-LINK_KEY_DEREG Request 673 Direction: LM -> M2UA 674 Purpose: LM requests ASP to de-register Link Key with SG by sending 675 DEREG REQ message. 677 M-LINK_KEY_DEREG Confirm 678 Direction: M2UA -> LM 679 Purpose: ASP reports to LM that it has successfully received a 680 DEREG RSP message from SG. 682 M-LINK_KEY_DEREG Indication 683 Direction: M2UA -> LM 684 Purpose: SG reports to LM that it has successfully processed an 685 incoming DEREG REQ message from ASP. 687 2.0 Conventions 689 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 690 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 691 in this document, are to be interpreted as described in [RFC2119]. 693 3.0 Protocol Elements 695 This section describes the format of various messages used in this 696 protocol. 698 3.1 Common Message Header 700 The protocol messages for MTP2-User Adaptation require a message 701 structure which contains a version, message class, message type, message 702 length, and message contents. This message header is common among all 703 signalling protocol adaptation layers: 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Version | Spare | Message Class | Message Type | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Message Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 2 Common Message Header 715 All fields in an M2UA message MUST be transmitted in the network byte 716 order, unless otherwise stated. 718 3.1.1 Version 720 The version field (vers) contains the version of the M2UA adaptation 721 layer. The supported versions are: 723 Value Version 724 ----- ------- 725 1 Release 1.0 727 3.1.2 Spare 729 The Spare field is 8-bits. It SHOULD be set to all '0's by the sender 730 and ignored by the receiver. 732 3.1.3 Message Class 734 The following List contains the valid Message Classes: 736 Message Class: 8 bits (unsigned integer) 738 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 739 1 Transfer Messages [M3UA] 740 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 741 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 742 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 743 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) 744 Messages [IUA] 745 6 MTP2 User Adaptation (MAUP) Messages [M2UA] 746 7 Connectionless Messages [SUA] 747 8 Connection-Oriented Messages [SUA] 748 9 Routing Key Management (RKM) Messages (M3UA) 749 10 Interface Identifier Management (IIM) Messages (M2UA) 750 11 to 127 Reserved by the IETF 751 128 to 255 Reserved for IETF-Defined Message Class extensions 753 3.1.4 Message Type 755 The following List contains the Message Types for the valid Message 756 Classes: 758 MTP2 User Adaptatation (MAUP) Messages 760 0 Reserved 761 1 Data 762 2 Establish Request 763 3 Establish Confirm 764 4 Release Request 765 5 Release Confirm 766 6 Release Indication 767 7 State Request 768 8 State Confirm 769 9 State Indication 770 10 Data Retrieval Request 771 11 Data Retrieval Confirm 772 12 Data Retrieval Indication 773 13 Data Retrieval Complete Indication 774 14 Congestion Indication 775 15 Data Acknowledge 776 16 to 127 Reserved by the IETF 777 128 to 255 Reserved for IETF-Defined MAUP extensions 778 Application Server Process State Maintenance (ASPSM) messages 780 0 Reserved 781 1 ASP Up (UP) 782 2 ASP Down (DOWN) 783 3 Heartbeat (BEAT) 784 4 ASP Up Ack (UP ACK) 785 5 ASP Down Ack (DOWN ACK) 786 6 Heartbeat Ack (BEAT ACK) 787 7 to 127 Reserved by the IETF 788 128 to 255 Reserved for IETF-Defined ASPSM extensions 790 Application Server Process Traffic Maintenance (ASPTM) messages 792 0 Reserved 793 1 ASP Active (ACTIVE) 794 2 ASP Inactive (INACTIVE) 795 3 ASP Active Ack (ACTIVE ACK) 796 4 ASP Inactive Ack (INACTIVE ACK) 797 5 to 127 Reserved by the IETF 798 128 to 255 Reserved for IETF-Defined ASPTM extensions 800 Management (MGMT) Messages 802 0 Error (ERR) 803 1 Notify (NTFY) 804 2 to 127 Reserved by the IETF 805 128 to 255 Reserved for IETF-Defined MGMT extensions 807 Interface Identifier Management (IIM) Messages 809 0 Reserved 810 1 Registration Request (REG REQ) 811 2 Registration Response (REG RSP) 812 3 Deregistration Request (DEREG REQ) 813 4 Deregistration Response (DEREG RSP) 814 5 to 127 Reserved by the IETF 815 128 to 255 Reserved for IETF-Defined IIM extensions 817 3.1.5 Message Length 819 The Message Length defines the length of the message in octets, 820 including the header. The Message Length MUST include parameter 821 padding bytes, if any. The Message Length MUST NOT be longer 822 than a MTP3 message [2] [3] plus the length of the common and 823 M2UA message headers. 825 3.1.6 Variable-Length Parameter Format 827 M2UA messages consist of a Common Header followed by zero or more 828 variable-length parameters, as defined by the message type. The 829 variable-length parameters contained in a message are defined in a 830 Tag-Length-Value format as shown below. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Parameter Tag | Parameter Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 \ \ 838 / Parameter Value / 839 \ \ 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Mandatory parameters MUST be placed before optional parameters in a 843 message. 845 Parameter Tag: 16 bits (unsigned integer) 847 The Type field is a 16 bit identifier of the type of parameter. It 848 takes a value of 0 to 65534. The common parameters used by adaptation 849 layers are in the range of 0x00 to 0xff. The M2UA specific parameters 850 have Tags in the range 0x300 to 0x3ff. 852 The common parameter tags (used by all User Adaptation layers) that 853 M2UA uses are defined below: 855 Parameter Value Parameter Name 856 --------------- -------------- 857 0 (0x00) Reserved 858 1 (0x01) Interface Identifier (Integer) 859 2 (0x02) Unused 860 3 (0x03) Interface Identifier (Text) 861 4 (0x04) Info String 862 5 (0x05) Unused 863 6 (0x06) Unused 864 7 (0x07) Diagnostic Information 865 8 (0x08) Interface Identifier (Integer Range) 866 9 (0x09) Heartbeat Data 867 10 (0x0a) Unused 868 11 (0x0b) Traffic Mode Type 869 12 (0x0c) Error Code 870 13 (0x0d) Status Type/Information 871 14 (0x0e) Unused 872 15 (0x0f) Unused 873 16 (0x10) Unused 874 17 (0x11) ASP Identifier 875 18 (0x12) Unused 876 19 (0x13) Correlation Id 877 18-255 Reserved 879 The M2UA specific parameter Tags defined are as follows: 881 Parameter Value Parameter Name 882 --------------- -------------- 883 768 (0x0300) Protocol Data 1 884 769 (0x0301) Protocol Data 2 (TTC) 885 770 (0x0302) State Request 886 771 (0x0303) State Event 887 772 (0x0304) Congestion Status 888 773 (0x0305) Discard Status 889 774 (0x0306) Action 890 775 (0x0307) Sequence Number 891 776 (0x0308) Retrieval Result 892 777 (0x0309) Link Key 893 778 (0x030a) Local-LK-Identifier 894 779 (0x030b) Signalling Data Terminal (SDT) Identifier 895 780 (0x030c) Signailng Data Link (SDL) Identifier 896 781 (0x030d) Registration Result 897 782 (0x030e) Registration Status 898 783 (0x030f) De-Registration Result 899 784 (0x0310) De-Registration Status 901 Parameter Length: 16 bits (unsigned integer) 903 The Parameter Length field contains the size of the parameter in 904 bytes, including the Parameter Tag, Parameter Length, and Parameter 905 Value fields. Thus, a parameter with a zero-length Parameter Value 906 field would have a Length field of 4. The Parameter Length does not 907 include any padding bytes. 909 Parameter Value: variable-length. 911 The Parameter Value field contains the actual information to be 912 transferred in the parameter. 914 The total length of a parameter (including Tag, Parameter Length and 915 Value fields) MUST be a multiple of 4 bytes. If the length of the 916 parameter is not a multiple of 4 bytes, the sender pads the Parameter 917 at the end (i.e., after the Parameter Value field) with all zero 918 bytes. The length of the padding is NOT included in the parameter 919 length field. A sender MUST NOT pad with more than 3 bytes. The 920 receiver MUST ignore the padding bytes. 922 3.2 M2UA Message Header 924 In addition to the common message header, there will be a M2UA 925 specific message header. The M2UA specific message header will 926 immediately follow the common message header, but will only be used 927 with MAUP messages. 929 This message header will contain the Interface Identifier. The 930 Interface Identifier identifies the physical interface at the SG for 931 which the signalling messages are sent/received. The format of the 932 Interface Identifier parameter can be text or integer, the values of 933 which are assigned according to network operator policy. The values 934 used are of local significance only, coordinated between the SG and 935 ASP. 937 The integer formatted Interface Identifier MUST be supported. The 938 text formatted Interface Identifier MAY optionally be supported. 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Tag (0x1) | Length=8 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Interface Identifier (integer) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure 3 M2UA Message Header (Integer-based Interface Identifier) 950 The Tag value for Integer-based Interface Identifier is 0x1. The 951 length is always set to a value of 8. 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Tag (0x3) | Length | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Interface Identifier (text) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 4 M2UA Message Header (Text-based Interface Identifier) 965 The Tag value for the Text-based Interface Identifier is 0x3. The 966 length is equal to the string length of the Interface Identifier 967 name plus four bytes for the Tag and Length fields. 969 3.3 M2UA Messages 971 The following section defines the messages and parameter contents. 972 The M2UA messages will use the common message header (Figure 2) and 973 the M2UA message header (Figure 3). 975 3.3.1 MTP2 User Adaptation Messages 977 3.3.1.1 Data 979 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). 980 The Data message contains the following parameter: 982 Protocol Data (mandatory) 983 Correlation Id (optional) 985 The format for the Data Message parameters is as follows: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Tag (0x300) | Length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 / \ 993 \ Protocol Data / 994 / \ 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Tag (0x311) | Length = 8 | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Correlation Id | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 The Protocol Data field contains the MTP2-User application message in 1002 network byte order starting with the Signalling Information Octet (SIO). 1003 The Correlation Id parameter uniquely identifies the MSU carried in the 1004 Protocol Data within an AS. This Correlation Id parameter is assigned 1005 by the sending M2UA. The purpose of the Correlation Id is to permit 1006 the newly active ASP to synchronize its processing of the traffic in 1007 each ordered stream with other ASPs in the broadcast group. 1009 The format for a Data Message with TTC PDU parameters is as follows: 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Tag (0x301) | Length | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 / \ 1017 \ Protocol Data / 1018 / \ 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Tag (0x13) | Length = 8 | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Correlation Id | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 The Protocol Data field contains the MTP2-User application message in 1026 network byte order starting with the Length Indicator (LI) octet. 1027 The Japanese TTC variant uses the spare bits of the LI octet for 1028 priority. The length of the Protocol Data MUST NOT exceed the length 1029 of a MTP2-User application message [2] [3]. 1031 3.3.1.2 Data Acknowledge Message 1033 The Data Acknowledge message contains the Correlation Id of the Data 1034 message which the sending M2UA is acknowledging as successfully 1035 processed to the peer M2UA. 1037 The Data Acknowledge message contains the following parameter: 1039 Correlation Id Mandatory 1041 The following format MUST be used for the Data Ack Message: 1043 0 1 2 3 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Tag (0x13) | Length = 8 | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Correlation Id | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 The Correlation Id parameter of the Data message and the Data Ack 1052 message provide a mechanism, for those SG implementations capable for 1053 taking advantage of them, to obtain an acknowledgement that the MSU 1054 has been transferred to the M2UA peer before acknowleding the MSU to 1055 the SS7 peer, removing the risk of losing messages due to association 1056 failure or SCTP congestion. 1058 The Data Ack message MUST be sent if a Correlation Id parameter is 1059 received from the peer. Otherwise the Data Ack message SHOULD NOT be 1060 sent. 1062 If the Data Acknowledge is not sent for Correlation Id(s) or is sent 1063 with Invalid Correlation Id(s), the SS7 link will eventually fail 1064 dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs. 1066 3.3.1.3 Establish (Request, Confirmation) 1068 The Establish Request message is used to establish the SS7 link or to 1069 indicate that the channel has been established. The MGC controls the 1070 state of the SS7 link. When the MGC desires the SS7 link to be 1071 in-service, it will send the Establish Request message. Note that 1072 the SGP MAY already have the SS7 link established at its layer. 1073 If so, upon receipt of an Establish Request, the SGP takes no action 1074 except to send an Establish Confirm. 1076 When the MGC sends an M2UA Establish Request message, the MGC MAY 1077 start a timer. This timer would be stopped upon receipt of an M2UA 1078 Establish Confirm. If the timer expires, the MGC would resend the 1079 M2UA Establish Request message and restart the timer. In other words, 1080 the MGC MAY continue to request the establishment of the datalink 1081 on periodic basis until the desired state is achieved or take some 1082 other action (notify the Management Layer). 1084 The mode (Normal or Emergency) for bringing the SS7 link in service is 1085 defaulted to Normal. The State Request (described in Section 3.3.1.5 1086 below) can be used to change the mode to Emergency. 1088 3.3.1.4 Release (Request, Indication, Confirmation) 1090 This Release Request message is used to release the channel. The 1091 Release Confirm and Indication messages are used to indicate that the 1092 channel has been released. 1094 3.3.1.5 State Request 1096 The State Request message can be sent from a MGC to cause an action 1097 on a particular SS7 link supported by the Signalling Gateway Process. 1098 The SGP sends a State Confirm to the MGC if the action has been 1099 successfully completed. The State Confirm reflects that state value 1100 received in the State Request message. 1102 The State Request message contains the following parameter: 1104 State (mandatory) 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Tag (0x302) | Length = 8 | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | State | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 The valid values for State are shown in the following table. 1116 Define Value Description 1117 STATUS_LPO_SET 0x0 Request local processor outage 1118 STATUS_LPO_CLEAR 0x1 Request local processor outage 1119 recovered 1120 STATUS_EMER_SET 0x2 Request emergency alignment 1121 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1122 emergency) 1123 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1124 and retransmit queues 1125 STATUS_CONTINUE 0x5 Continue or Resume 1126 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1127 STATUS_AUDIT 0x7 Audit state of link 1128 STATUS_CONG_CLEAR 0x8 Congestion cleared 1129 STATUS_CONG_ACCEPT 0x9 Congestion accept 1130 STATUS_CONG_DISCARD 0xa Congestion discard 1132 3.3.1.6 State Confirm 1134 The State Confirm message will be sent by the SGP in response to a State 1135 Request from the MGC. The State Confirm reflects that state value 1136 received in the State Request message. 1138 The State Confirm message contains the following parameter: 1140 State (mandatory) 1142 0 1 2 3 1143 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 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Tag (0x302) | Length = 8 | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | State | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 The valid values for State are shown in the following table. The value 1151 of the State field should reflect the value received in the State 1152 Request message. 1154 Define Value Description 1155 STATUS_LPO_SET 0x0 Request local processor outage 1156 STATUS_LPO_CLEAR 0x1 Request local processor outage 1157 recovered 1158 STATUS_EMER_SET 0x2 Request emergency alignment 1159 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1160 emergency) 1161 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1162 and retransmit queues 1163 STATUS_CONTINUE 0x5 Continue or Resume 1164 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1165 STATUS_AUDIT 0x7 Audit state of link 1166 STATUS_CONG_CLEAR 0x8 Congestion cleared 1167 STATUS_CONG_ACCEPT 0x9 Congestion accept 1168 STATUS_CONG_DISCARD 0xa Congestion discard 1170 3.3.1.7 State Indication 1172 The MTP2 State Indication message can be sent from a SGP to an ASP to 1173 indicate a condition on a SS7 link. 1175 The State Indication message contains the following parameter: 1177 Event (mandatory) 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Tag (0x303) | Length = 8 | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Event | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 The valid values for Event are shown in the following table. 1189 Define Value Description 1190 EVENT_RPO_ENTER 0x1 Remote entered processor outage 1191 EVENT_RPO_EXIT 0x2 Remote exited processor outage 1192 EVENT_LPO_ENTER 0x3 Link entered processor outage 1193 EVENT_LPO_EXIT 0x4 Link exited processor outage 1195 3.3.1.8 Congestion Indication 1197 The Congestion Indication message can be sent from a Signalling Gateway 1198 Process to an ASP to indicate the congestion status and discard status 1199 of a SS7 link. When the MSU buffer fill increases above an Onset 1200 threshold or decreases below an Abatement threshold or crosses a Discard 1201 threshold in either direction, the SGP SHALL send a congestion indication 1202 message. 1204 The SGP SHALL send the message only when there is actually a change 1205 in either the discard level or the congestion level to report, 1206 meaning it is different from the previously sent message. In addition, 1207 the SGP SHALL use an implementation dependent algorithm to limit the 1208 frequency of congestion indication messages. 1210 An implementation may optionally send Congestion Indication messages on 1211 a "high priority" stream in order to potentially reduce delay (Refer to 1212 [12] for more details). 1214 The Congestion Indication message contains the following parameters: 1216 Congestion Status (mandatory) 1217 Discard Status (optional) 1218 0 1 2 3 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Tag (0x304) | Length = 8 | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Congestion Status | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Tag (0x305) | Length = 8 | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Discard Status | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 The valid values for Congestion Status and Discard Status are shown in 1231 the following table. 1233 Define Value Description 1234 LEVEL_NONE 0x0 No congestion 1235 LEVEL_1 0x1 Congestion Level 1 1236 LEVEL_2 0x2 Congestion Level 2 1237 LEVEL_3 0x3 Congestion Level 3 1239 For SS7 networks that do not support multiple levels of congestion, only 1240 the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that 1241 support multiple levels of congestion, it is possible for all values to 1242 be used. Refer to [2], [3] and [9] for more details on the Congestion 1243 and Discard Status of SS7 signalling links. 1245 3.3.1.9 Retrieval Request 1247 The MTP2 Retrieval Request message is used during the MTP Level 3 1248 changeover procedure to request the BSN, to retrieve PDUs from the 1249 transmit and retransmit queues or to flush PDUs from the retransmit 1250 queue. Examples of the use of Retrieval Request for SS7 Link 1251 Changeover are provided in Section 5.3.6. 1253 The Retrieval Request message contains the following parameters: 1255 Action (mandatory) 1256 Sequence Number (optional) 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Tag (0x306) | Length = 8 | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Action | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Tag (0x307) | Length = 8 | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Sequence Number | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 The valid values for Action are shown in the following table. 1272 Define Value Description 1273 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1274 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit 1275 and retransmit queues 1277 In the Retrieval Request message, the Sequence Number field SHOULD NOT 1278 be present if the Action field is ACTION_RTRV_BSN. The Sequence Number 1279 field contains the Forward Sequence Number (FSN) of the far end if the 1280 Action is ACTION_RTRV_MSGS. 1282 3.3.1.10 Retrieval Confirm 1284 The MTP2 Retrieval Confirm message is sent by the Signalling Gateway 1285 in response to a Retrieval Request message. Examples of the use of 1286 Retrieval Confirm for SS7 Link Changeover are provided in Section 1287 5.3.6. 1289 The Retrieval Confirm message contains the following parameters: 1291 Action (mandatory) 1292 Result (mandatory) 1293 Sequence Number (optional) 1295 0 1 2 3 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Tag (0x306) | Length = 8 | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Action | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Tag (0x308) | Length = 8 | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Result | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Tag (0x307) | Length = 8 | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Sequence Number | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 The valid values for Action are the same as in Retrieval Request. 1313 The values for Result are shown below: in the following table. 1315 Define Value Description 1316 RESULT_SUCCESS 0x0 Action successful 1317 RESULT_FAILURE 0x1 Action failed 1319 When the Signalling Gateway Process sends a Retrieval Confirm to a 1320 Retrieval Request, it echos the Action field. If the Action was 1321 ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP 1322 will put the Backward Sequence Number (BSN) in the Sequence Number 1323 field and will indicate a success in the Result field. If the BSN 1324 could not be retrieved, the Sequence Number field will not be included 1325 and the Result field will indicate failure. 1327 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of 1328 the Result field will indicate success or failure. A failure means 1329 that the buffers could not be retrieved. The Sequence Number field is 1330 not used with ACTION_RTRV_MSGS. 1332 3.3.1.11 Retrieval Indication 1334 The Retrieval Indication message is sent by the Signalling Gateway with 1335 a PDU from the transmit or retransmit queue. The Retrieval Indication 1336 message does not contain the Action or seq_num fields, just a MTP3 1337 Protocol Data Unit (PDU) from the transmit or retransmit queue. 1338 Examples of the use of Retrieval Indication for SS7 Link Changeover are 1339 provided in Section 5.3.6. 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Tag (0x300) | Length | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 / \ 1347 \ Protocol Data / 1348 / \ 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 For TTC Data messages, the following parameter will be used to indicate 1352 a TTC PDU which starts at LI. 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Tag (0x301) | Length | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 / \ 1360 \ TTC Protocol Data / 1361 / \ 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 The M2UA implementation MAY consider the use of the bundling feature 1365 of SCTP for Retrieval Indication messages. 1367 3.3.1.12 Retrieval Complete Indication 1369 The MTP2 Retrieval Complete Indication message is exactly the same as 1370 the MTP2 Retrieval Indication message except that it also indicates 1371 that retrieval is complete. In addition, it MAY contain a PDU (which 1372 must be the last PDU) from the transmit or retransmit queue. 1374 3.3.2 Application Server Process Maintenance (ASPM) Messages 1376 The ASPM messages will only use the common message header. 1378 3.3.2.1 ASP Up (ASPUP) 1380 The ASP Up (ASPUP) message is used to indicate to a remote M2UA peer 1381 that the Adaptation layer is ready to receive traffic or maintenance 1382 messages. 1384 The ASPUP message contains the following parameters 1386 ASP Identifier (optional) 1387 Info String (optional) 1389 Note: The ASP Identifier MUST be used where the SGP cannot 1390 identify the ASP by pre-configured address/port number 1391 information (e.g., where an ASP is resident on a Host using 1392 dynamic address/port number assignment). 1394 The format for ASPUP Message parameters is as follows: 1396 0 1 2 3 1397 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 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Tag (0xe) | Length | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | ASP Identifier* | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | Tag (0x4) | Length | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 / \ 1406 \ INFO String* / 1407 / \ 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 The optional ASP Identifier parameter would contain a unique value 1411 that is locally significant among the ASPs that support an AS. The 1412 SGP should save the ASP Identifier to be used, if necessary, with the 1413 Notify message (see Section 3.3.3.2). 1415 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1416 character string along with the message. Length of the INFO String 1417 parameter is from 0 to 255 characters. No procedures are presently 1418 identified for its use but the INFO String MAY be used for debugging 1419 purposes. 1421 3.3.2.2 ASP Up Ack 1423 The ASP Up Ack message is used to acknowledge an ASP Up message 1424 received from a remote M2UA peer. 1426 The ASPUP Ack message contains the following parameters: 1428 INFO String (optional) 1430 The format for ASPUP Ack Message parameters is as follows: 1432 0 1 2 3 1433 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 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Tag (0x4) | Length | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 / \ 1438 \ INFO String* / 1439 / \ 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 The format and description of the optional Info String parameter is the 1443 same as for the ASP UP message (See Section 3.3.2.1). 1445 3.3.2.3 ASP Down (ASPDN) 1447 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1448 that the adaptation layer is not ready to receive traffic or 1449 maintenance messages. 1451 The ASPDN message contains the following parameters 1453 INFO String (optional) 1455 The format for the ASPDN message parameters is as follows: 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Tag (0x4) | Length | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 / \ 1463 \ INFO String* / 1464 / \ 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 The format and description of the optional Info String parameter is the 1468 same as for the ASP Up message (See Section 3.3.2.1). 1470 3.3.2.4 ASP Down Ack 1472 The ASP Down Ack message is used to acknowledge an ASP Down message 1473 received from a remote M2UA peer. 1475 The ASP Down Ack message contains the following parameters: 1477 INFO String (optional) 1479 The format for the ASPDN Ack message parameters is as follows: 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Tag (0x4) | Length | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 / \ 1487 \ INFO String* / 1488 / \ 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 The format and description of the optional Info String parameter is the 1492 same as for the ASP UP message (See Section 3.3.2.1). 1494 3.3.2.5 Heartbeat (BEAT) 1496 The Heartbeat message is optionally used to ensure that the M2UA 1497 peers are still available to each other. 1499 The BEAT message contains the following parameter: 1501 Heartbeat Data Optional 1503 The format for the BEAT message is as follows: 1505 0 1 2 3 1506 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 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Tag = 0x0009 | Length | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 / Heartbeat Data / 1511 \ \ 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 The sending node defines the Heartbeat Data field contents. It may 1515 include a Heartbeat Sequence Number and/or Timestamp, or other 1516 implementation specific details. 1518 The receiver of a Heartbeat message does not process this field as 1519 it is only of significance to the sender. The receiver echoes the 1520 content of the Heartbeat Data in a BEAT ACK message. 1522 3.3.2.6 Heartbeat Ack (BEAT ACK) 1524 The Heartbeat ACK message is sent in response to a BEAT message. A 1525 peer MUST send a BEAT ACK in response to a BEAT message. It includes 1526 all the parameters of the received Heartbeat message, without any 1527 change. 1529 The BEAT ACK message contains the following parameter: 1531 Heartbeat Data Optional 1533 The format for the BEAT ACK message is as follows: 1535 0 1 2 3 1536 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 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Tag = 0x0009 | Length | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 / Heartbeat Data / 1541 \ \ 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 The sending node defines the Heartbeat Data field contents. It may 1545 include a Heartbeat Sequence Number and/or Timestamp, or other 1546 implementation specific details. 1548 The receiver of a Heartbeat message does not process this field as 1549 it is only of significance to the sender. The receiver echoes the 1550 content of the Heartbeat Data in a BEAT ACK message. 1552 3.3.2.7 ASP Active (ASPAC) 1554 The ASPAC message is sent by an ASP to indicate to an SGP that it is 1555 Active and ready to be used. 1557 The ASPAC message contains the following parameters: 1559 Traffic Mode Type (optional) 1560 Interface Identifier (optional) 1561 - Combination of integer and integer ranges, OR 1562 - string (text formatted) 1563 INFO String (optional) 1565 The format for the ASPAC message using integer formatted Interface 1566 Identifiers is as follows: 1568 0 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Tag (0xb) | Length | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | Traffic Mode Type | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Tag (0x1=integer) | Length | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 / \ 1578 \ Interface Identifiers* / 1579 / \ 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | Tag (0x8=integer range) | Length | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | Interface Identifier Start1* | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Interface Identifier Stop1* | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Interface Identifier Start2* | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Interface Identifier Stop2* | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 . . 1592 . . 1593 . . 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Interface Identifier StartN* | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Interface Identifier StopN* | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 / \ 1600 \ Additional Interface Identifiers / 1601 / of Tag Type 0x1 or 0x8 \ 1602 \ / 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Tag (0x4) | Length | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 / \ 1607 \ INFO String* / 1608 / \ 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 The format for the ASPAC message using text formatted (string) 1612 Interface Identifiers is as follows: 1614 0 1 2 3 1615 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 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Tag (0xb) | Length | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | Traffic Mode Type | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Tag (0x3=string) | Length | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 / \ 1624 \ Interface Identifier* / 1625 / \ 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 / \ 1628 \ Additional Interface Identifiers / 1629 / of Tag Type 0x3 \ 1630 \ / 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Tag (0x4) | Length | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 / \ 1635 \ INFO String* / 1636 / \ 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 The Traffic Mode Type parameter identifies the traffic mode of 1640 operation of the ASP within an AS. The valid values for Type are 1641 shown in the following table: 1643 Value Description 1644 0x1 Override 1645 0x2 Load-share 1646 0x3 Broadcast 1648 Within a particular AS, only one Traffic Mode Type can be used. 1649 The Override value indicates that the ASP is operating in Override 1650 mode, where the ASP takes over all traffic in an Application Server 1651 (i.e., primary/backup operation), over-riding any currently active 1652 ASPs in the AS. In Load-share mode, the ASP will share in the traffic 1653 distribution with any other currently active ASPs. In Broadcast mode, 1654 all of the Active ASPs receive all message traffic in the Application 1655 Server. 1657 The optional Interface Identifiers parameter contains a list of 1658 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1659 (Type 0x3)indexing the Application Server traffic that the sending 1660 ASP is configured/registered to receive. If integer formatted 1661 Interface Identifiers are being used, the ASP can also send ranges of 1662 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1663 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1664 formatted Interface Identifiers (0x3) cannot be used with either 1665 Integer (0x1) or Integer Range (0x8) types. 1667 If no Interface Identifiers are included, the message is for all 1668 provisioned Interface Identifiers within the AS(s) in which the 1669 ASP is provisioned. If only a subset of Interface Identifiers for an 1670 AS are included, the ASP is noted as Active for all the Interface 1671 Identifiers provisioned for that AS. 1673 Note: If the optional Interface Identifier parameter is present, the 1674 integer formatted Interface Identifier MUST be supported, while the 1675 text formatted Interface Identifier MAY be supported. 1677 An SGP that receives an ASPAC with an incorrect or unsupported Traffic 1678 Mode Type for a particular Interface Identifier will respond with an 1679 Error Message (Cause: Unsupported Traffic Handling Mode). 1681 The format and description of the optional Info String parameter is the 1682 same as for the ASP UP message (See Section 3.3.2.1). 1684 3.3.2.8 ASP Active Ack 1686 The ASP Active (ASPAC) Ack message is used to acknowledge an ASP Active 1687 message received from a remote M2UA peer. 1689 The ASPAC Ack message contains the following parameters: 1691 Traffic Mode Type (optional) 1692 Interface Identifier (optional) 1693 - Combination of integer and integer ranges, OR 1694 - string (text formatted) 1695 INFO String (optional) 1697 The format for the ASPAC Ack message with Integer-formatted Interface 1698 Identifiers is as follows: 1700 0 1 2 3 1701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Tag (0xb) | Length | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Traffic Mode Type | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Tag (0x1=integer) | Length | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 / \ 1710 \ Interface Identifiers* / 1711 / \ 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Tag (0x8=integer range) | Length | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Interface Identifier Start1* | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Interface Identifier Stop1* | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Interface Identifier Start2* | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Interface Identifier Stop2* | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 . . 1724 . . 1725 . . 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | Interface Identifier StartN* | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Interface Identifier StopN* | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 / \ 1732 \ Additional Interface Identifiers / 1733 / of Tag Type 0x1 or 0x8 \ 1734 \ / 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Tag (0x4) | Length | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 / \ 1739 \ INFO String* / 1740 / \ 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 The format for the ASP Active Ack message using text formatted (string) 1744 Interface Identifiers is as follows: 1746 0 1 2 3 1747 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 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Tag (0xb) | Length | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Traffic Mode Type | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Tag (0x3=string) | Length | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 / \ 1756 \ Interface Identifier* / 1757 / \ 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 / \ 1760 \ Additional Interface Identifiers / 1761 / of Tag Type 0x3 \ 1762 \ / 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Tag (0x4) | Length | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 / \ 1767 \ INFO String* / 1768 / \ 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 The format and description of the optional Info String parameter is the 1772 same as for the ASP Up message (See Section 3.3.2.1). 1774 The format of the Traffic Mode Type and Interface Identifier parameters 1775 is the same as for the ASP Active message (See Section 3.3.2.5). 1777 3.3.2.9 ASP Inactive (ASPIA) 1779 The ASP Inactive (ASPIA) message is sent by an ASP to indicate to an 1780 SGP that it is no longer an active ASP to be used from within a list 1781 of ASPs. The SGP will respond with an ASPIA Ack message and either 1782 discard incoming messages or buffer for a timed period and then 1783 discard. 1785 The ASPIA message contains the following parameters: 1787 Interface Identifiers (optional) 1788 - Combination of integer and integer ranges, OR 1789 - string (text formatted) 1790 INFO String (optional) 1792 The format for the ASP Inactive message parameters using Integer 1793 formatted Interface Identifiers is as follows: 1795 0 1 2 3 1796 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 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Tag (0x1=integer) | Length | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 / \ 1801 \ Interface Identifiers* / 1802 / \ 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Tag (0x8=integer range) | Length | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Interface Identifier Start1* | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Interface Identifier Stop1* | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Interface Identifier Start2* | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Interface Identifier Stop2* | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 . . 1815 . . 1816 . . 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | Interface Identifier StartN* | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Interface Identifier StopN* | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 / \ 1823 \ Additional Interface Identifiers / 1824 / of Tag Type 0x1 or 0x8 \ 1825 \ / 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Tag (0x4) | Length | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 / \ 1830 \ INFO String* / 1831 / \ 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 The format for the ASP Inactive message using text formatted (string) 1835 Interface Identifiers is as follows: 1837 0 1 2 3 1838 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 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Tag (0x3=string) | Length | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 / \ 1843 \ Interface Identifier* / 1844 / \ 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 / \ 1847 \ Additional Interface Identifiers / 1848 / of Tag Type 0x3 \ 1849 \ / 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Tag (0x4) | Length | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 / \ 1854 \ INFO String* / 1855 / \ 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 The format and description of the optional Interface Identifiers and 1859 Info String parameters is the same as for the ASP Active message (See 1860 Section 3.3.2.3). 1862 The optional Interface Identifiers parameter contains a list of 1863 Interface Identifier integers indexing the Application Server traffic 1864 that the sending ASP is configured/registered to receive, but does not 1865 want to receive at this time. 1867 3.3.2.10 ASP Inactive Ack 1869 The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP 1870 Inactive message received from a remote M2UA peer. 1872 The ASPIA Ack message contains the following parameters: 1874 Interface Identifiers (optional) 1875 - Combination of integer and integer ranges, OR 1876 - string (text formatted) 1877 INFO String (optional) 1879 The format for the ASPIA Ack message is as follows: 1881 0 1 2 3 1882 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 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Tag (0x1=integer) | Length | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 / \ 1887 \ Interface Identifiers* / 1888 / \ 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Tag (0x8=integer range) | Length | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Interface Identifier Start1* | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Interface Identifier Stop1* | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Interface Identifier Start2* | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Interface Identifier Stop2* | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 . . 1901 . . 1902 . . 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Interface Identifier StartN* | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Interface Identifier StopN* | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 / \ 1909 \ Additional Interface Identifiers / 1910 / of Tag Type 0x1 or 0x8 \ 1911 \ / 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Tag (0x4) | Length | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 / \ 1916 \ INFO String* / 1917 / \ 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 The format for the ASP Inactive Ack message using text formatted 1921 (string) Interface Identifiers is as follows: 1923 0 1 2 3 1924 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 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Tag (0x3=string) | Length | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 / \ 1929 \ Interface Identifier* / 1930 / \ 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 / \ 1933 \ Additional Interface Identifiers / 1934 / of Tag Type 0x3 \ 1935 \ / 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Tag (0x4) | Length | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 / \ 1940 \ INFO String* / 1941 / \ 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 The format of the Interface Identifier parameter is the same as for 1945 the ASP Inactive message (See Section 3.3.2.7). 1947 The format and description of the optional Info String parameter is 1948 the same as for the ASP Up message (See Section 3.3.2.1). 1950 3.3.3 Layer Management (MGMT) Messages 1952 3.3.3.1 Error (ERR) 1954 The Error (ERR) message is used to notify a peer of an error event 1955 associated with an incoming message. For example, the message type 1956 might be unexpected given the current state, or a parameter value might 1957 be invalid. 1959 The ERR message contains the following parameters: 1961 Error Code (mandatory) 1962 Interface Identifier (optional) 1963 Diagnostic Information (optional) 1965 The format for the ERR message is as follows: 1967 0 1 2 3 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Tag (0xc) | Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Error Code | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Tag (0x1, 0x3, or 0x8) | Length | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 / \ 1977 \ Interface Identifier(s)* / 1978 / \ 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Tag (0x7) | Length | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 / \ 1983 \ Diagnostic Information* / 1984 / \ 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 The Error Code parameter indicates the reason for the Error Message. 1988 The Error parameter value can be one of the following values: 1990 Invalid Version 0x1 1991 Invalid Interface Identifier 0x2 1992 Unsupported Message Class 0x3 1993 Unsupported Message Type 0x4 1994 Unsupported Traffic Handling Mode 0x5 1995 Unexpected Message 0x6 1996 Protocol Error 0x7 1997 Unsupported Interface Identifier Type 0x8 1998 Invalid Stream Identifier 0x9 1999 Not Used in M2UA 0xa 2000 Not Used in M2UA 0xb 2001 Not Used in M2UA 0xc 2002 Refused - Management Blocking 0xd 2003 ASP Identifier Required 0xe 2004 Invalid ASP Identifier 0xf 2005 ASP Active for Interface Identifier(s) 0x10 2006 Invalid Parameter Value 0x11 2007 Parameter Field Error 0x12 2008 Unexpected Parameter 0x13 2010 The "Invalid Version" error would be sent if a message was 2011 received with an invalid or unsupported version. The Error message 2012 would contain the supported version in the Common header. The 2013 Error message could optionally provide the supported version in 2014 the Diagnostic Information area. 2016 The "Invalid Interface Identifier" error would be sent by a SGP if 2017 an ASP sends a message (i.e. an ASP Active message) with an invalid 2018 (unconfigured) Interface Identifier value. One of the optional 2019 Interface Identifier parameters (Integer-based, text-based or integer 2020 range) MUST be used with this error code to identify the invalid 2021 Interface Identifier(s) received. 2023 The "Unsupported Traffic Handling Mode" error would be sent by a SGP 2024 if an ASP sends an ASP Active with an unsupported Traffic Handling 2025 Mode. An example would be a case in which the SGP did not support 2026 load-sharing. One of the optional Interface Identifier parameters 2027 (Integer-based, text-based or integer range) MAY be used with this 2028 error code to identify the Interface Identifier(s). 2030 The "Unexpected Message" error would be sent by an ASP if it received 2031 a MAUP message from an SGP while it was in the Inactive state. 2033 The "Protocol Error" error would be sent for any protocol anomaly 2034 (i.e. a bogus message). 2036 The "Invalid Stream Identifier" error would be sent if a message 2037 was received on an unexpected SCTP stream (i.e. a MGMT message 2038 was received on a stream other than "0"). 2040 The "Unsupported Interface Identifier Type" error would be sent by 2041 a SGP if an ASP sends a Text formatted Interface Identifier and the 2042 SGP only supports Integer formatted Interface Identifiers. When 2043 the ASP receives this error, it will need to resend its message with 2044 an Integer formatted Interface Identifier. 2046 The "Unsupported Message Class" error would be sent if a message with 2047 an unexpected or unsupported Message Class is received. 2049 The "Refused - Management Blocking" error is sent when an ASP Up or 2050 ASP Active message is received and the request is refused for 2051 management reasons (e.g., management lock-out"). 2053 The "ASP Identifier Required" is sent by a SGP in response 2054 to an ASPUP message which does not contain an ASP Identifier 2055 parameter when the SGP requires one. The ASP should resend the 2056 ASPUP message with a ASP Identifier. 2058 The "Invalid ASP Identifier" is send by a SGP in response to an 2059 ASPUP message with an invalid (i.e. non-unique) ASP Identifier. 2061 The "ASP Currently Active for Interface Identifier(s)" error is 2062 sent by a SGP when a Deregistration request is received from an ASP 2063 that is active for Interface Identifier(s) specified in the 2064 Deregistration request. One of the optional Interface Identifier 2065 parameters (Integer-based, text-based or integer range) MAY be used 2066 with this error code to identify the Interface Identifier(s). 2068 The "Invalid Parameter Value " error is sent if a message is received 2069 with an invalid parameter value (e.g., a State Request with an 2070 an undefined State). 2072 The "Parameter Field Error" would be sent if a message with a 2073 parameter that has a wrong length field. 2075 The "Unexpected Parameter" error would be sent if a message contains 2076 an invalid parameter. 2078 The optional Diagnostic information can be any information germane to 2079 the error condition, to assist in identification of the error condition. 2080 In the case of an Invalid Version Error Code the Diagnostic information 2081 includes the supported Version parameter. In the other cases, the 2082 Diagnostic information SHOULD be the first 40 bytes of the offending 2083 message. 2085 3.3.3.2 Notify (NTFY) 2087 The Notify message is used to provide an autonomous indication of M2UA 2088 events to an M2UA peer. 2090 The NTFY message contains the following parameters: 2092 Status Type (mandatory) 2093 Status Information (mandatory) 2094 ASP Identifier (optional) 2095 Interface Identifiers (optional) 2096 INFO String (optional) 2098 The format for the Notify message with Integer-formatted Interface 2099 Identifiers is as follows: 2101 0 1 2 3 2102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Tag (0xd) | Length | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Status Type | Status Information | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Tag (0xe) | Length | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 | ASP Identifier* | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Tag (0x1=integer) | Length | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 / \ 2115 \ Interface Identifiers* / 2116 / \ 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Tag (0x8=integer range) | Length | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 | Interface Identifier Start1* | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | Interface Identifier Stop1* | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Interface Identifier Start2* | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Interface Identifier Stop2* | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 . . 2129 . . 2130 . . 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Interface Identifier StartN* | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Interface Identifier StopN* | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 / \ 2137 \ Additional Interface Identifiers / 2138 / of Tag Type 0x1 or 0x8 \ 2139 \ / 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Tag (0x4) | Length | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 / \ 2144 \ INFO String* / 2145 / \ 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 The format for the Notify message with Text-formatted Interface 2149 Identifiers is as follows: 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Tag (0xd) | Length | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | Status Type | Status Information | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Tag (0xe) | Length | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | ASP Identifier* | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Tag (0x3=string) | Length | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 / \ 2165 \ Interface Identifier* / 2166 / \ 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 / \ 2169 \ Additional Interface Identifiers / 2170 / of Tag Type 0x3 \ 2171 \ / 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Tag (0x4) | Length | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 / \ 2176 \ INFO String* / 2177 / \ 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 The Status Type parameter identifies the type of the Notify message. 2181 The following are the valid Status Type values: 2183 Value Description 2184 0x1 Application Server state change (AS_State_Change) 2185 0x2 Other 2187 The Status Information parameter contains more detailed information 2188 for the notification, based on the value of the Status Type. If the 2189 Status Type is AS_State_Change the following Status Information values 2190 are used: 2192 Value Description 2193 1 Application Server Down (AS_Down) 2194 2 Application Server Inactive (AS_Inactive) 2195 3 Application Server Active (AS_Active) 2196 4 Application Server Pending (AS_Pending) 2198 These notifications are sent from an SGP to an ASP upon a change in 2199 status of a particular Application Server. The value reflects the 2200 new state of the Application Server. The Interface Identifiers of 2201 the AS MAY be placed in the message if desired. 2203 If the Status Type is Other, then the following Status Information 2204 values are defined: 2206 Value Description 2207 1 Insufficient ASP resources active in AS 2208 2 Alternate ASP Active 2209 3 ASP Failure 2211 In the Insufficient ASP Resources case, the SGP is indicating to an 2212 ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to 2213 handle the load of the AS (Load-sharing mode). For the Alternate ASP 2214 Active case, the formerly Active ASP is informed when an alternate 2215 ASP transitions to the ASP Active state in Override mode. The ASP 2216 Identifier (if available) of the Alternate ASP MUST be placed in the 2217 message. For the ASP Failure case, the SGP is indicating to ASP(s) 2218 in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP 2219 Identifier (if available) of the failed ASP MUST be placed in the 2220 message. 2222 For each of the Status Information values in Status Type Other, the 2223 Interface Identifiers of the affected AS MAY be placed in the message 2224 if desired. 2226 The format and description of the optional Interface Identifiers and 2227 Info String parameters is the same as for the ASP Active message 2228 (See Section 3.3.2.3). 2230 3.3.4 Interface Identifier Management (IIM) Messages 2232 The Interface Identifier Management messages are optional. They are 2233 used to support automatic allocation of Signalling Terminals or 2234 Signalling Data Links [2][3]. 2236 3.3.4.1 Registration Request (REG REQ) 2238 The REG REQ message is sent by an ASP to indicate to a remote M2UA 2239 peer that it wishes to register one or more given Link Keys with the 2240 remote peer. Typically, an ASP would send this message to an SGP, 2241 and expect to receive a REG RSP in return with an associated 2242 Interface Identifier value. 2244 The REG REQ message contains the following parameter: 2246 Link Key (mandatory) 2248 The format for the REG REQ message is as follows 2249 0 1 2 3 2250 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 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Tag = 0x0309 | Length | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 \ \ 2255 / Link Key 1 / 2256 \ \ 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 \ \ 2259 / ... / 2260 \ \ 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Tag = 0x0309 | Length | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 \ \ 2265 / Link Key n / 2266 \ \ 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 Link Key: fixed length 2271 The Link Key parameter is mandatory. The sender of this message 2272 expects the receiver of this message will create a Link Key entry 2273 and assign a unique Interface Identifier value to it, if the Link 2274 Key entry does not yet exist. 2276 The Link Key parameter may be present multiple times in the same 2277 message. This is used to allow the registration of multiple Link 2278 Keys in a single message. 2280 The format of the Link Key parameter is as follows: 2282 0 1 2 3 2283 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 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | Local-LK-Identifier | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Signalling Data Terminal Identifier | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | Signalling Data Link Identifier | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 Local-LK-Identifier: 32-bit integer 2294 The mandatory Local-LK-Identifier field is used to uniquely 2295 (between ASP and SGP) identify the registration request. The 2296 Identifier value is assigned by the ASP, and is used to correlate 2297 the response in a REG RSP message with the original registration 2298 request. The Identifier value must remain unique until the REG 2299 RSP is received. 2301 The format of the Local-LK-Identifier field is as follows: 2303 0 1 2 3 2304 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 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | Tag = 0x030a | Length = 8 | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Local-LK-Identifier value | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 Signalling Data Terminal Identifier 2313 The Signalling Data Terminal Identifier parameter is mandatory. 2314 It identifies the Signalling Data Terminal associated with the 2315 SS7 link for which the ASP is registering. The format is as 2316 follows: 2318 0 1 2 3 2319 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 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Tag = 0x030b | Length = 8 | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | Reserved | SDT Identifier | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 The SDT Identifier is a 32-bit unsigned value which may only be 2327 significant to 12 or 14 bits depending on the SS7 variant which 2328 is supported by the MTP Level 3 at the ASP. Insignificant SDTI 2329 bits are coded 0. 2331 Signalling Data Link Identifier 2333 The Signalling Data Link Identifier parameter is mandatory. It 2334 identifies the Signalling Data Link Identifier associated with 2335 the SS7 link for which the ASP is registering. The format is as 2336 follows: 2338 0 1 2 3 2339 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 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | Tag = 0x030c | Length = 8 | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Reserved | SDL Identifier | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 The SDL Identifier is a 32-bit unsigned value which may only be 2347 significant to 12 or 14 bits depending on the SS7 variant which 2348 is supported by the MTP Level 3 at the ASP. Insignificant SDLI 2349 bits are coded 0. 2351 3.3.4.2 Registration Response (REG RSP) 2353 The REG RSP message is used as a response to the REG REQ message 2354 from a remote M2UA peer. It contains indications of success/failure 2355 for registration requests and returns a unique Interface Identifier 2356 value for successful registration requests, to be used in subsequent 2357 M2UA Traffic Management protocol. 2359 The REG RSP message contains the following parameter: 2361 Registration Results (mandatory) 2363 The format for the REG RSP message is as follows: 2365 0 1 2 3 2366 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 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | Tag = 0x030d | Length | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 \ \ 2371 / Registration Result 1 / 2372 \ \ 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 \ \ 2375 / ... / 2376 \ \ 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | Tag = 0x030d | Length | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 \ \ 2381 / Registration Result n / 2382 \ \ 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 Registration Results: fixed length 2387 The Registration Results parameter contains one or more results, 2388 each containing the registration status for a single Link Key in 2389 the REG REQ message. The number of results in a single REG RSP 2390 message MAY match the number of Link Key parameters found in the 2391 corresponding REG REQ message. The format of each result is as 2392 follows: 2394 0 1 2 3 2395 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 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Local-LK-Identifier | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Registration Status | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Interface Identifier | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 Local-LK-Identifier: 32-bit integer 2406 The Local-LK-Identifier contains the same value as found in the 2407 matching Link Key parameter found in the REG REQ message. The 2408 format of the Local-LK-Identifier is shown in Section 3.3.4.1. 2410 Registration Status: 32-bit integer 2412 The Registration Result Status field indicates the success or the 2413 reason for failure of a registration request. 2415 Its values may be one of the following: 2417 0 Successfully Registered 2418 1 Error - Unknown 2419 2 Error - Invalid SDLI 2420 3 Error - Invalid SDTI 2421 4 Error - Invalid Link Key 2422 5 Error - Permission Denied 2423 6 Error - Overlapping (Non-unique) Link Key 2424 7 Error - Link Key not Provisioned 2425 8 Error - Insufficient Resources 2427 The format of the Registration Status field is as follows: 2429 0 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Tag = 0x030e | Length = 8 | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Registration Status | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 Interface Identifier: 32-bit integer 2439 The Interface Identifier field contains the Interface Identifier 2440 for the associated Link Key if the registration is successful. 2441 It is set to "0" if the registration was not successful. The 2442 format of integer-based and text-based Interface Identifier 2443 parameters are shown in Section 3.2. 2445 3.3.4.3 De-Registration Request (DEREG REQ) 2447 The DEREG REQ message is sent by an ASP to indicate to a remote M2UA 2448 peer that it wishes to de-register a given Interface Identifier. 2449 Typically, an ASP would send this message to an SGP, and expects to 2450 receive a DEREG RSP in return reflecting the Interface Identifier 2451 and containing a de-registration status. 2453 The DEREG REQ message contains the following parameter: 2455 Interface Identifier (mandatory) 2457 The format for the DEREG REQ message is as follows: 2459 0 1 2 3 2460 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 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | Tag = 0x1 or 0x3 | Length | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 \ \ 2465 / Interface Identifier 1 / 2466 \ \ 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 \ \ 2469 / ... / 2470 \ \ 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Tag = 0x1 or 0x3 | Length | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 \ \ 2475 / Interface Identifier n / 2476 \ \ 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 Interface Identifier 2481 The Interface Identifier parameter contains a Interface Identifier 2482 indexing the Application Server traffic that the sending ASP is 2483 currently registered to receive from the SGP but now wishes to 2484 de-register. The format of integer-based and text-based Interface 2485 Identifier parameters are shown in Section 3.2. 2487 3.3.4.4 De-Registration Response (DEREG RSP) 2489 The DEREG RSP message is used as a response to the DEREG REQ message 2490 from a remote M2UA peer. 2492 The DEREG RSP message contains the following parameter: 2494 De-Registration Results (mandatory) 2496 The format for the DEREG RSP message is as follows: 2498 0 1 2 3 2499 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 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | Tag = 0x030f | Length | 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 \ \ 2504 / De-Registration Result 1 / 2505 \ \ 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 \ \ 2508 / ... / 2509 \ \ 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | Tag = 0x030f | Length | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 \ \ 2514 / De-Registration Result n / 2515 \ \ 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 De-Registration Results: fixed length 2520 The De-Registration Results parameter contains one or more results, 2521 each containing the de-registration status for a single Interface 2522 Identifier in the DEREG REQ message. The number of results in a 2523 single DEREG RSP message MAY match the number of Interface Identifier 2524 parameters found in the corresponding DEREG REQ message. The format 2525 of each result is as follows: 2527 0 1 2 3 2528 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 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Interface Identifier | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | De-Registration Status | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Interface Identifier: 32-bit integer 2537 The Interface Identifier field contains the Interface Identifier 2538 value of the matching Link Key to de-register, as found in the 2539 DEREG REQ. The format of integer-based and text-based Interface 2540 Identifier parameters are shown in Section 3.2. 2542 De-Registration Status: 32-bit integer 2544 The De-Registration Result Status field indicates the success or 2545 the reason for failure of the de-registration. 2547 Its values may be one of the following: 2549 0 Successfully De-registered 2550 1 Error - Unknown 2551 2 Error - Invalid Interface Identifier 2552 3 Error - Permission Denied 2553 4 Error - Not Registered 2555 The format of the De-Registration Status field is as follows: 2557 0 1 2 3 2558 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 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Tag = 0x0310 | Length = 8 | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | De-Registration Status | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 4.0 Procedures 2567 The M2UA layer needs to respond to various primitives it receives from 2568 other layers as well as messages it receives from the peer-to-peer 2569 messages. This section describes various procedures involved in 2570 response to these events. 2572 4.1 Procedures to Support the M2UA-User Layer 2574 These procedures achieve the M2UA layer "Transport of MTP Level 2 / 2575 MTP Level 3 boundary" service. 2577 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 2579 On receiving a primitive from the local upper layer, the M2UA layer 2580 will send the corresponding MAUP message (see Section 3) to its peer. 2581 The M2UA layer MUST fill in various fields of the common and specific 2582 headers correctly. In addition the message SHOULD be sent on the SCTP 2583 stream that corresponds to the SS7 link. 2585 4.1.2 MAUP Message Procedures 2587 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 2588 SG or MGC needs to invoke the corresponding layer primitives to the 2589 local MTP Level 2 or MTP Level 3 layer. 2591 4.2 Receipt of Primitives from the Layer Management 2593 On receiving primitives from the local Layer Management, the M2UA layer 2594 will take the requested action and provide an appropriate response 2595 primitive to Layer Management. 2597 An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP 2598 will initiate the establishment of an SCTP association. The M2UA 2599 layer will attempt to establish an SCTP association with the remote 2600 M2UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP 2601 layer. 2603 When an SCTP association has been successfully established, the SCTP 2604 will send an SCTP-COMMUNICATION_UP notification primitive to the local 2605 M2UA layer. At the SGP that initiated the request, the M2UA layer will 2606 send an M-SCTP_ESTABLISH confirm primitive to Layer Management when 2607 the association setup is complete. At the peer M2UA layer, an 2608 M-SCTP_ESTABLISH indication primitive is sent to Layer Management 2609 upon successful completion of an incoming SCTP association setup. 2611 An M-SCTP_RELEASE request primitive from Layer Management initates the 2612 shutdown of an SCTP association. The M2UA layer accomplishes a 2613 graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN 2614 primitive to the SCTP layer. 2616 When the graceful shutdown of the SCTP association has been 2617 accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE 2618 notification primitive to the local M2UA layer. At the M2UA Layer that 2619 initiated the request, the M2UA layer will send an M-SCTP_RELEASE 2620 confirm primitive to Layer Management when the association shutdown is 2621 complete. At the peer M2UA Layer, an M-SCTP_RELEASE indication 2622 primitive is sent to Layer Management upon abort or successful 2623 shutdown of an SCTP association. 2625 An M-SCTP_STATUS request primitive supports a Layer Management query 2626 of the local status of a particular SCTP association. The M2UA layer 2627 simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS 2628 primitive to the SCTP layer. When the SCTP responds, the M2UA layer 2629 maps the association status information to an M-SCTP_STATUS confirm 2630 primitive. No peer protocol is invoked. 2632 Similar LM-to-M2UA-to-SCTP and/or SCTP-to-M2UA-to-LM primitive mappings 2633 can be described for the various other SCTP Upper Layer primitives in 2634 RFC2960 [13] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, 2635 REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL 2636 PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS 2637 CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status 2638 as well) can be considered for modeling purposes as a Layer Management 2639 interaction directly with the SCTP Layer. 2641 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 2642 Management the notification or error information contained in a 2643 received M2UA Notify or Error message respectively. These indications 2644 can also be generated based on local M2UA events. 2646 An M-ASP_STATUS request primitive supports a Layer Management query of 2647 the status of a particular local or remote ASP. The M2UA layer 2648 responds with the status in an M-ASP_STATUS confirm primitive. No M2UA 2649 peer protocol is invoked. 2651 An M-AS_STATUS request supports a Layer Management query of the status 2652 of a particular AS. The M2UA responds with an M-AS_STATUS confirm 2653 primitive. No M2UA peer protocol is invoked. 2655 M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_ 2656 INACTIVE request primitives allow Layer Management at an ASP to 2657 initiate state changes. Upon successful completion, a corresponding 2658 confirm primitive is provided by the M2UA layer to Layer Management. 2659 If an invocation is unsuccessful, an Error indication primitive is 2660 provided in the primitive. These requests result in outgoing ASP Up, 2661 ASP Down, ASP Active and ASP Inactive messages to the remote M2UA peer 2662 at an SGP. 2664 4.2.1 Receipt of M2UA Peer Management Messages 2666 Upon successful state changes resulting from reception of ASP Up, 2667 ASP Down, ASP Active and ASP Inactive messages from a peer M2UA, the 2668 M2UA layer SHOULD invoke corresponding M-ASP_UP, M-ASP_DOWN, M- 2669 ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M- 2670 AS_DOWN indication primitives to the local Layer Management. 2672 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 2673 Management the notification or error information contained in a 2674 received M2UA Notify or Error message. These indications can also be 2675 generated based on local M2UA events. 2677 All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with 2678 sequenced delivery to ensure ordering. All MGMT messages, with the 2679 exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP 2680 stream '0'. All ASPTM messages SHOULD be sent on the stream which 2681 normally carries the data traffic to which the message applies. BEAT 2682 and BEAT Ack messages MAY be sent using out-of-order delivery, and 2683 MAY be sent on any stream. 2685 4.3 AS and ASP State Maintenance 2687 The M2UA layer on the SGP maintains the state of each remote ASP, in 2688 each Application Server that the ASP is configured to receive traffic, 2689 as input to the M2UA message distribution function. 2691 4.3.1 ASP States 2693 The state of each remote ASP, in each AS that it is configured to 2694 operate, is maintained in the M2UA layer in the SGP. The state of a 2695 particular ASP in a particular AS changes due to events. The events 2696 include: 2698 * Reception of messages from the peer M2UA layer at the ASP; 2699 * Reception of some messages from the peer M2UA layer at other ASPs 2700 in the AS (e.g., ASP Active message indicating "Override"); 2701 * Reception of indications from the SCTP layer; or 2702 * Local Management intervention. 2704 The ASP state transition diagram is shown in Figure 5. The possible 2705 states of an ASP are: 2707 ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the 2708 related SCTP association is down. Initially all ASPs will be in this 2709 state. An ASP in this state SHOULD NOT be sent any M2UA messages, with 2710 the exception of Heartbeat messages. 2712 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 2713 related SCTP association is up) but application traffic is stopped. 2714 In this state the ASP MAY be sent any non-MAUP M2UA messages. 2716 ASP-ACTIVE: The remote M2UA peer at the ASP is available and 2717 application traffic is active (for a particular Interface Identifier 2718 or set of Interface Identifiers). 2720 Figure 5: ASP State Transition Diagram 2722 +--------------+ 2723 | ASP-ACTIVE | 2724 +----------------------| | 2725 | Other +-------| | 2726 | ASP in AS | +--------------+ 2727 | Overrides | ^ | 2728 | | ASP | | ASP 2729 | | Active | | Inactive 2730 | | | v 2731 | | +--------------+ 2732 | | | | 2733 | +------>| ASP-INACTIVE | 2734 | +--------------+ 2735 | ^ | 2736 ASP Down/ | ASP | | ASP Down / 2737 SCTP CDI/ | Up | | SCTP CDI/ 2738 SCTP RI | | v SCTP RI 2739 | +--------------+ 2740 | | | 2741 +--------------------->| ASP-DOWN | 2742 | | 2743 +--------------+ 2745 SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication 2746 Down Indication to the Upper Layer Protocol (M2UA) on an SGP. The local 2747 SCTP layer will send this indication when it detects the loss of 2748 connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as 2749 either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 2750 notification from the SCTP layer. 2752 SCTP RI: The local SCTP layer's Restart indication to the upper layer 2753 protocol (M2UA) on an SG. The local SCTP will send this indication when 2754 it detects a restart from the ASP's peer SCTP layer. 2756 4.3.2 AS States 2758 The state of the AS is maintained in the M2UA layer on the SGP. The 2759 state of an AS changes due to events. These events include: 2761 * ASP state transitions 2762 * Recovery timer triggers 2764 The possible states of an AS are: 2766 AS-DOWN: The Application Server is unavailable. This state implies 2767 that all related ASPs are in the ASP-DOWN state for this AS. Initially 2768 the AS will be in this state. An Application Server MUST be in the AS- 2769 DOWN state before it can be removed from a configuration. 2771 AS-INACTIVE: The Application Server is available but no application 2772 traffic is active (i.e., one or more related ASPs are in the ASP- 2773 INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer 2774 T(r) is not running or has expired. 2776 AS-ACTIVE: The Application Server is available and application traffic 2777 is active. This state implies that at least one ASP is in the ASP- 2778 ACTIVE state. 2780 AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN 2781 and it was the last remaining active ASP in the AS. A recovery timer 2782 T(r) SHOULD be started and all incoming signalling messages SHOULD be 2783 queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, 2784 the AS is moved to the AS-ACTIVE state and all the queued messages will 2785 be sent to the ASP. 2787 If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing 2788 messages and discards all previously queued messages. The AS will move 2789 to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state, 2790 otherwise it will move to AS-DOWN state. 2792 Figure 6 shows an example AS state machine for the case where the 2793 AS/ASP data is pre-configured. For other cases where the AS/ASP 2794 configuration data is created dynamically, there would be differences 2795 in the state machine, especially at creation of the AS. 2797 For example, where the AS/ASP configuration data is not created until 2798 Registration of the first ASP, the AS-INACTIVE state is entered 2799 directly upon the first successful REG REQ from an ASP. Another 2800 example is where the AS/ASP configuration data is not created until the 2801 first ASP successfully enters the ASP-ACTIVE state. In this case the 2802 AS-ACTIVE state is entered directly. 2804 Figure 6: AS State Transition Diagram 2806 +----------+ one ASP trans to ACTIVE +-------------+ 2807 | AS- |---------------------------->| AS- | 2808 | INACTIVE | | ACTIVE | 2809 | |<--- | | 2810 +----------+ \ +-------------+ 2811 ^ | \ Tr Expiry, ^ | 2812 | | \ at least one | | 2813 | | \ ASP in ASP-INACTIVE | | 2814 | | \ | | 2815 | | \ | | 2816 | | \ | | 2817 one ASP | | all ASP \ one ASP | | Last ACTIVE 2818 trans | | trans to \ trans to | | ASP trans to 2819 to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE 2820 ASP- | | \ ACTIVE | | or ASP-DOWN 2821 INACTIVE| | \ | | (start Tr) 2822 | | \ | | 2823 | | \ | | 2824 | v \ | v 2825 +----------+ \ +-------------+ 2826 | | --| | 2827 | AS-DOWN | | AS-PENDING | 2828 | | | (queueing) | 2829 | |<----------------------------| | 2830 +----------+ Tr Expiry and no ASP +-------------+ 2831 in ASP-INACTIVE state 2833 Tr = Recovery Timer 2835 4.3.3 M2UA Management Procedures for Primitives 2837 Before the establishment of an SCTP association the ASP state at both 2838 the SGP and ASP is assumed to be in the state ASP-DOWN. 2840 Once the SCTP association is established (see Section 4.2.1) and 2841 assuming that the local M2UA-User is ready, the local M2UA ASP 2842 Maintenance (ASPM) function will initiate the relevant procedures, 2843 using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey 2844 the ASP state to the SGP (see Section 4.4.3). 2846 If the M2UA layer subsequently receives an SCTP-COMMUNICATION_DOWN 2847 or SCTP-RESTART indication primitive from the underlying SCTP layer, 2848 it will inform the Layer Management by invoking the M-SCTP_STATUS 2849 indication primitive. The state of the ASP will be moved to ASP-DOWN. 2851 In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re- 2852 establish the SCTP association. This MAY be done by the M2UA layer 2853 automatically, or Layer Management MAY re-establish using the 2854 M-SCTP_ESTABLISH request primitive. 2856 In the case of an SCTP-RESTART indication at an ASP, the ASP is now 2857 considered by its M2UA peer to be in the ASP-DOWN state. The ASP, if 2858 it is to recover, must begin any recovery with the ASP-Up procedure. 2860 4.3.4 ASPM Procedures for Peer-to-Peer Messages 2862 4.3.4.1 ASP Up Procedures 2864 After an ASP has successfully established an SCTP association to an 2865 SGP, the SGP waits for the ASP to send an ASP Up message, indicating 2866 that the ASP M2UA peer is available. The ASP is always the initiator 2867 of the ASP Up message. This action MAY be initiated at the ASP by an 2868 M-ASP_UP request primitive from Layer Management or MAY be initiated 2869 automatically by an M2UA management function. 2871 When an ASP Up message is received at an SGP and internally the remote 2872 ASP is in the ASP-DOWN state and not considered locked-out for local 2873 management reasons, the SGP marks the remote ASP in the state ASP- 2874 INACTIVE and informs Layer Management with an M-ASP_Up indication 2875 primitive. If the SGP is aware, via current configuration data, which 2876 Application Servers the ASP is configured to operate in, the SGP 2877 updates the ASP state to ASP-INACTIVE in each AS that it is a member. 2879 Alternatively, the SGP may move the ASP into a pool of Inactive ASPs 2880 available for future configuration within Application Server(s), 2881 determined in a subsequent Registration Request or ASP Active 2882 procedure. If the ASP Up message contains an ASP Identifier, the SGP 2883 should save the ASP Identifier for that ASP. The SGP MUST send an 2884 ASP Up Ack message in response to a received ASP Up message even if 2885 the ASP is already marked as ASP-INACTIVE at the SGP. 2887 If for any local reason (e.g., management lock-out) the SGP cannot 2888 respond with an ASP Up Ack message, the SGP responds to an ASP Up 2889 message with an Error message with Reason "Refused - Management 2890 Blocking". 2892 At the ASP, the ASP Up Ack message received is not acknowledged. Layer 2893 Management is informed with an M-ASP_UP confirm primitive. When an ASP 2894 enters the ASP-INACTIVE state from the ASP-DOWN state towards an SGP 2895 the M2UA MUST mark all SS7 destinations configured to be reachable via 2896 this SGP as available. 2898 When the ASP sends an ASP Up message it starts timer T(ack). If the 2899 ASP does not receive a response to an ASP Up message within T(ack), the 2900 ASP MAY restart T(ack) and resend ASP Up messages until it receives an 2901 ASP Up Ack message. T(ack) is provisionable, with a default of 2 2902 seconds. Alternatively, retransmission of ASP Up messages MAY be put 2903 under control of Layer Management. In this method, expiry of T(ack) 2904 results in an M-ASP_UP confirm primitive carrying a negative 2905 indication. 2907 The ASP MUST wait for the ASP Up Ack message before sending any other 2908 M2UA messages (e.g., ASP Active or REG REQ). If the SGP receives any 2909 other M2UA messages before an ASP Up message is received, the SGP 2910 SHOULD discard them. 2912 If an ASP Up message is received and internally the remote ASP is in 2913 the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as 2914 an Error message ("Unexpected Message), and the remote ASP state is 2915 changed to ASP-INACTIVE in all relevant Application Servers. 2917 If an ASP Up message is received and internally the remote ASP is 2918 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 2919 and no further action is taken. 2921 4.3.4.1.1 M2UA Version Control 2923 If an ASP Up message with an unsupported version is received, the 2924 receiving end responds with an Error message, indicating the version 2925 the receiving node supports and notifies Layer Management. 2927 This is useful when protocol version upgrades are being performed in a 2928 network. A node upgraded to a newer version should support the older 2929 versions used on other nodes it is communicating with. Because ASPs 2930 initiate the ASP Up procedure it is assumed that the Error message 2931 would normally come from the SGP. 2933 4.3.4.2 ASP Down Procedures 2935 The ASP will send an ASP Down message to an SGP when the ASP wishes to 2936 be removed from service in all Application Servers that it is a member 2937 and no longer receive any MAUP or ASPTM messages. This action MAY be 2938 initiated at the ASP by an M-ASP_DOWN request primitive from Layer 2939 Management or MAY be initiated automatically by an M2UA management 2940 function. 2942 Whether the ASP is permanently removed from any AS is a function of 2943 configuration management. In the case where the ASP previously used 2944 the Registration procedures (see Section 4.3.5) to register within 2945 Application Servers but has not deregistered from all of them prior to 2946 sending the ASP Down message, the SGP MUST consider the ASP as 2947 Deregistered in all Application Servers that it is still a member. 2949 The SGP marks the ASP as ASP-DOWN, informs Layer Management with an 2950 M-ASP_Down indication primitive, and returns an ASP Down Ack message 2951 to the ASP. 2953 The SGP MUST send an ASP Down Ack message in response to a received ASP 2954 Down message from the ASP even if the ASP is already marked as ASP-DOWN 2955 at the SGP. 2957 At the ASP, the ASP Down Ack message received is not acknowledged. 2958 Layer Management is informed with an M-ASP_DOWN confirm primitive. If 2959 the ASP receives an ASP Down Ack without having sent an ASP Down 2960 message, the ASP should now consider itself as in the ASP-DOWN state. 2961 If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the 2962 ASP should then initiate procedures to return itself to its previous 2963 state. 2965 When the ASP sends an ASP Down message it starts timer T(ack). If the 2966 ASP does not receive a response to an ASP Down message within T(ack), 2967 the ASP MAY restart T(ack) and resend ASP Down messages until it 2968 receives an ASP Down Ack message. T(ack) is provisionable, with a 2969 default of 2 seconds. Alternatively, retransmission of ASP Down 2970 messages MAY be put under control of Layer Management. In this method, 2971 expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a 2972 negative indication. 2974 4.3.4.4 ASP Active Procedures 2976 Anytime after the ASP has received an ASP Up Ack message from the SGP, 2977 the ASP MAY send an ASP Active message to the SGP indicating that 2978 the ASP is ready to start processing traffic. This action MAY be 2979 initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer 2980 Management or MAY be initiated automatically by a M2UA management 2981 function. In the case where an ASP wishes to process the traffic for 2982 more than one Application Server across a common SCTP association, the 2983 ASP Active message(s) SHOULD contain a list of one or more Interface 2984 Identifiers to indicate for which Application Servers the ASP Active 2985 message applies. It is not necessary for the ASP to include any 2986 Interface Identifiers of interest in a single ASP Active message, 2987 thus requesting to become active in all Interface Identifiers at the 2988 same time. Multiple ASP Active messages MAY be used to activate 2989 within the Application Servers independently, or in sets. In the 2990 case where an ASP Active message does not contain a Interface 2991 Identifier parameter, the receiver must know, via configuration data, 2992 which Application Server(s) the ASP is a member. 2994 For the Application Servers that the ASP can successfully activate, 2995 the SGP responds with one or more ASP Active Ack messages, including 2996 the associated Interface Identifier(s) and reflecting any Traffic Mode 2997 Type value present in the related ASP Active message. The Interface 2998 Identifier parameter MUST be included in the ASP Active Ack message(s) 2999 if the received ASP Active message contained any Interface Identifiers. 3000 Depending on any Traffic Mode Type request in the ASP Active message 3001 or local configuration data if there is no request, the SGP moves the 3002 ASP to the correct ASP traffic state within the associated Application 3003 Server(s). Layer Management is informed with an M-ASP_Active 3004 indication. If the SGP receives any Data messages before an ASP Active 3005 message is received, the SGP MAY discard them. By sending an ASP 3006 Active Ack message, the SGP is now ready to receive and send traffic 3007 for the related Interface Identifier(s). The ASP SHOULD NOT send MAUP 3008 messages for the related Interface Identifier(s) before receiving an 3009 ASP Active Ack message, or it will risk message loss. 3011 Multiple ASP Active Ack messages MAY be used in response to an ASP 3012 Active message containing multiple Interface Identifiers, allowing 3013 the SGP to independently acknowledge the ASP Active message for 3014 different (sets of) Interface Identifiers. The SGP MUST send 3015 an Error message ("Invalid Interface Identifier") for each Interface 3016 Identifier value that cannot be successfully activated. 3018 In the case where an "out-of-the-blue" ASP Active message is received 3019 (i.e., the ASP has not registered with the SG or the SG has no static 3020 configuration data for the ASP), the message MAY be silently discarded. 3022 The SGP MUST send an ASP Active Ack message in response to a received 3023 ASP Active message from the ASP, if the ASP is already marked in the 3024 ASP-ACTIVE state at the SGP. 3026 At the ASP, the ASP Active Ack message received is not acknowledged. 3027 Layer Management is informed with an M-ASP_ACTIVE confirm primitive. 3028 It is possible for the ASP to receive Data message(s) before the ASP 3029 Active Ack message as the ASP Active Ack and Data messages from an SG 3030 may be sent on different SCTP streams. Message loss is possible as 3031 the ASP does not consider itself in the ASP-ACTIVE state until 3032 reception of the ASP Active Ack message. 3034 When the ASP sends an ASP Active message it starts timer T(ack). If 3035 the ASP does not receive a response to an ASP Active message within 3036 T(ack), the ASP MAY restart T(ack) and resend ASP Active message(s) 3037 until it receives an ASP Active Ack message. T(ack) is provisionable, 3038 with a default of 2 seconds. Alternatively, retransmission of ASP 3039 Active messages MAY be put under control of Layer Management. In 3040 this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm 3041 primitive carrying a negative indication. 3043 There are three modes of Application Server traffic handling in the SGP 3044 M2UA layer: Override, Loadshare and Broadcast. When included, the 3045 Traffic Mode Type parameter in the ASP Active message indicates the 3046 traffic handling mode to be used in a particular Application Server. 3047 If the SGP determines that the mode indicated in an ASP Active message 3048 is unsupported or incompatible with the mode currently configured for 3049 the AS, the SGP responds with an Error message ("Unsupported / Invalid 3050 Traffic Handling Mode"). If the traffic handling mode of the 3051 Application Server is not already known via configuration data, then 3052 the traffic handling mode indicated in the first ASP Active message 3053 causing the transition of the Application Server state to AS-ACTIVE MAY 3054 be used to set the mode. 3056 In the case of an 0verride mode AS, reception of an ASP Active message 3057 at an SGP causes the (re)direction of all traffic for the AS to the ASP 3058 that sent the ASP Active message. Any previously active ASP in the AS 3059 is now considered to be in state ASP-INACTIVE and SHOULD no longer 3060 receive traffic from the SGP within the AS. The SGP then MUST send a 3061 Notify message ("Alternate ASP Active") to the previously active ASP 3062 in the AS, and SHOULD stop traffic to/from that ASP. The ASP receiving 3063 this Notify MUST consider itself now in the ASP-INACTIVE state, if it 3064 is not already aware of this via inter-ASP communication with the 3065 Overriding ASP. 3067 In the case of a Load-share mode AS, reception of an ASP Active 3068 message at an SGP causes the direction of traffic to the ASP sending 3069 the ASP Active message, in addition to all the other ASPs that are 3070 currently active in the AS. The algorithm at the SGP for load-sharing 3071 traffic within an AS to all the active ASPs is implementation 3072 dependent. The algorithm could, for example be round-robin or based 3073 on information in the Data message (e.g., such as the SLS in the 3074 Routing Label). 3076 An SGP, upon reception of an ASP Active message for the first ASP in 3077 a Loadshare AS, MAY choose not to direct traffic to a newly active ASP 3078 until it determines that there are sufficient resources to handle the 3079 expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in 3080 the AS). 3082 All ASPs within a load-sharing mode AS must be able to process any 3083 Data message received for the AS, to accommodate any potential 3084 fail-over or rebalancing of the offered load. 3086 In the case of a Broadcast mode AS, reception of an ASP Active message 3087 at an SGP causes the direction of traffic to the ASP sending the ASP 3088 Active message, in addition to all the other ASPs that are currently 3089 active in the AS. The algorithm at the SGP for broadcasting 3090 traffic within an AS to all the active ASPs is a simple broadcast 3091 algorithm, where every message is sent to each of the active ASPs. 3093 An SGP, upon reception of an ASP Active message for the first 3094 ASP in a Broadcast AS, MAY choose not to direct traffic to a newly 3095 active ASP until it determines that there are sufficient resources to 3096 handle the expected load (e.g., until there are "n" ASPs in state 3097 ASP-ACTIVE in the AS). 3099 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP 3100 MUST tag the first DATA message broadcast in each SCTP stream with a 3101 unique Correlation Id parameter. The purpose of this Correlation Id 3102 is to permit the newly active ASP to synchronize its processing of 3103 traffic in each ordered stream with the other ASPs in the broadcast 3104 group. 3106 4.3.4.5 ASP Inactive Procedures 3108 When an ASP wishes to withdraw from receiving traffic within an AS, the 3109 ASP sends an ASP Inactive message to the SGP. This action MAY be 3110 initiated at the ASP by an M-ASP_INACTIVE request primitive from 3111 Layer Management or MAY be initiated automatically by an M2UA 3112 management function. In the case where an ASP is processing the 3113 traffic for more than one Application Server across a common SCTP 3114 association, the ASP Inactive message contains one or more Interface 3115 Identifiers to indicate for which Application Servers the ASP Inactive 3116 message applies. In the case where an ASP Inactive message does not 3117 contain a Interface Identifier parameter, the receiver must know, via 3118 configuration data, which Application Servers the ASP is a member and 3119 move the ASP to the ASP-INACTIVE state in all Application Servers. 3120 In the case of an Override mode AS, where another ASP has already 3121 taken over the traffic within the AS with an ASP Active ("Override") 3122 message, the ASP that sends the ASP Inactive message is already 3123 considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive 3124 Ack message is sent to the ASP, after ensuring that all traffic is 3125 stopped to the ASP. 3127 In the case of a Load-share mode AS, the SGP moves the ASP to the ASP- 3128 INACTIVE state and the AS traffic is re-allocated across the remaining 3129 ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm 3130 currently used within the AS. A Notify message ("Insufficient ASP 3131 resources active in AS") MAY be sent to all inactive ASPs, if required. 3132 An ASP Inactive Ack message is sent to the ASP after all traffic 3133 is halted and Layer Management is informed with an M-ASP_INACTIVE 3134 indication primitive. 3136 In the case of a Broadcast mode AS, the SGP moves the ASP to the 3137 ASP-INACTIVE state and the AS traffic is broadcast only to the 3138 remaining ASPs in the state ASP-ACTIVE. A Notify message 3139 ("Insufficient ASP resources active in AS") MAY be sent to all 3140 inactive ASPs, if required. An ASP Inactive Ack message is sent to 3141 the ASP after all traffic is halted and Layer Management is informed 3142 with an M-ASP_INACTIVE indication primitive. 3144 Multiple ASP Inactive Ack messages MAY be used in response to an 3145 ASP Inactive message containing multiple Interface Identifers, 3146 allowing the SGP to independently acknowledge for different (sets 3147 of) Interface Identifiers. The SGP sends an Error message ("Invalid 3148 Interface Identifier") message for each invalid or unconfigured 3149 Interface Identifer value in a received ASP Inactive message. 3151 The SGP MUST send an ASP Inactive Ack message in response to a received 3152 ASP Inactive message from the ASP and the ASP is already marked as ASP- 3153 INACTIVE at the SGP. 3155 At the ASP, the ASP Inactive Ack message received is not acknowledged. 3156 Layer Management is informed with an M-ASP_INACTIVE confirm primitive. 3157 If the ASP receives an ASP Inactive Ack without having sent an ASP 3158 Inactive message, the ASP should now consider itself as in the 3159 ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE 3160 state, the ASP should then initiate procedures to return itself to 3161 its previous state. 3163 When the ASP sends an ASP Inactive message it starts timer T(ack). 3164 If the ASP does not receive a response to an ASP Inactive message 3165 within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive 3166 messages until it receives an ASP Inactive Ack message. T(ack) is 3167 provisionable, with a default of 2 seconds. Alternatively, 3168 retransmission of ASP Inactive messages MAY be put under control of 3169 Layer Management. In this method, expiry of T(ack) results in a M- 3170 ASP_Inactive confirm primitive carrying a negative indication. 3172 If no other ASPs in the Application Server are in the state ASP-ACTIVE, 3173 the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs 3174 in the AS which are in the state ASP-INACTIVE. The SGP SHOULD start 3175 buffering the incoming messages for T(r)seconds, after which messages 3176 MAY be discarded. T(r) is configurable by the network operator. If 3177 the SGP receives an ASP Active message from an ASP in the AS before 3178 expiry of T(r), the buffered traffic is directed to that ASP and the 3179 timer is cancelled. If T(r) expires, the AS is moved to the 3180 AS-INACTIVE state. 3182 4.3.4.6 Notify Procedures 3184 A Notify message reflecting a change in the AS state MUST be sent to 3185 all ASPs in the AS, except those in the ASP-DOWN state, with 3186 appropriate Status Information and any ASP Identifier of the failed 3187 ASP. At the ASP, Layer Management is informed with an M-NOTIFY 3188 indication primitive. The Notify message MUST be sent whether the 3189 AS state change was a result of an ASP failure or reception of an 3190 ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message. 3191 In the second case, the Notify message MUST be sent after any related 3192 acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active 3193 Ack, or ASP Inactive Ack). 3195 In the case where a Notify ("AS-PENDING") message is sent by an 3196 SGP that now has no ASPs active to service the traffic, or where a 3197 Notify ("Insufficient ASP resources active in AS") message MUST be sent 3198 in the Loadshare or Broadcast mode, the Notify message does not 3199 explicitly compel the ASP(s) receiving the message to become active. 3200 The ASPs remain in control of what (and when) traffic action is taken. 3202 In the case where a Notify message does not contain a Interface 3203 Identifier parameter, the receiver must know, via configuration data, 3204 of which Application Servers the ASP is a member and take the 3205 appropriate action in each AS. 3207 4.3.4.7 Heartbeat Procedures 3209 The optional Heartbeat procedures MAY be used when operating over 3210 transport layers that do not have their own heartbeat mechanism for 3211 detecting loss of the transport association (i.e., other than SCTP). 3213 Either M2UA peer may optionally send Heartbeat messages periodically, 3214 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 3215 message, the M2UA peer MUST respond with a Heartbeat Ack message. 3217 If no Heartbeat Ack message (or any other M2UA message) is received 3218 from the M2UA peer within 2*T(beat), the remote M2UA peer is considered 3219 unavailable. Transmission of Heartbeat messages is stopped and the 3220 signalling process SHOULD attempt to re-establish communication if it 3221 is configured as the client for the disconnected M2UA peer. 3223 The Heartbeat message may optionally contain an opaque Heartbeat Data 3224 parameter that MUST be echoed back unchanged in the related Heartbeat 3225 Ack message. The sender, upon examining the contents of the returned 3226 Heartbeat Ack message, MAY choose to consider the remote M2UA peer as 3227 unavailable. The contents/format of the Heartbeat Data parameter is 3228 implementation-dependent and only of local interest to the original 3229 sender. The contents may be used, for example, to support a Heartbeat 3230 sequence algorithm (to detect missing Heartbeats), and/or a timestamp 3231 mechanism (to evaluate delays). 3233 Note: Heartbeat related events are not shown in Figure 5 "ASP state 3234 transition diagram". 3236 4.4 Link Key Management Procedures 3238 The Interface Identifier Management procedures are optional. They can 3239 be used to support automatic allocation of Signalling Terminals or 3240 Signalling Data Links [2][3]. 3242 4.4.1 Registration 3244 An ASP MAY dynamically register with an SGP as an ASP within an 3245 Application Server for individual Interface Identifier(s) using 3246 the REG REQ message. A Link Key parameter in the REG REQ specifies 3247 the parameters associated with the Link Key. 3249 The SGP examines the contents of the received Link Key parameters (SDLI 3250 and SDTI) and compares them with the currently provisioned Interface 3251 Identifiers. If the received Link Key matches an existing SGP Link Key 3252 entry, and the ASP is not currently included in the list of ASPs for 3253 the related Application Server, the SGP MAY authorize the ASP to be 3254 added to the AS. Or, if the Link Key does not currently exist and the 3255 received Link Key data is valid and unique, an SGP supporting dynamic 3256 configuration MAY authorize the creation of a new Interface Identifier 3257 and related Application Server and add the ASP to the new AS. In either 3258 case, the SGP returns a Registration Response message to the ASP, 3259 containing the same Local-LK-Identifier as provided in the initial 3260 request, a Registration Result "Successfully Registered" and the 3261 Interface Identifier. A unique method of Interface Identifier valid 3262 assignment at the SG/SGP is implementation dependent but must be 3263 guaranteed to be unique for each Application server or Link Key 3264 served by SGP. 3266 If the SGP determines that the received Link Key data is invalid, or 3267 contains invalid parameter values, the SGP returns a Registration 3268 Response message to the ASP, containing a Registration Result "Error 3269 - Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI" 3270 as appropriate. 3272 If the SGP determins that the Link Key parameter overlaps with an 3273 existing Link Key entry, the SGP returns a Registration Response 3274 message to the ASP, with a Registration Status of "Error - 3275 Overlapping (Non-Unique) Link Key". An incoming signalling message 3276 received at an SGP cannot match against more than one Link Key. 3278 If the SGP does not authorize the registration request, the SGP 3279 returns a REG RSP message to the ASP containing the Registration 3280 Result "Error - Permission Denied". 3282 If an SGP determines that a received Link Key does not currently 3283 exist and the SGP does not support dynamic configuration, the SGP 3284 returns a Registration Response message to the ASP, containing a 3285 Registration Result "Error - Link Key not Provisioned". 3287 If an SGP determines that a received Link Key does not currently 3288 exist and the SGP supports dynamic reconfiguration but does not have 3289 the capacity to add new Link Key and Application Server entries, the 3290 SGP returns a Registration Response message to the ASP, containing a 3291 Registration Result "Error - Insufficient Resources". 3293 An ASP MAY register multiple Link Keys at once by including a number 3294 of Link Key parameters in a single REG REQ message. The SGP MAY 3295 response to each registration request in a single REG RSP message, 3296 indicating the success or failure result for each Link Key in a 3297 separate Registration Result parameter. Alternatively, the SGP MAY 3298 respond with multiple REG RSP messages, each with one or more 3299 Registration Result parameters. The ASP uses the Local-LK-Identifier 3300 parameter to correlate the requests with the responses. 3302 4.4.2 Deregistration 3304 An ASP MAY dynamically de-register with an SGP as an ASP within an 3305 Application Server for individual Interface Identifier(s) using 3306 the DEREG REQ message. A Interface Identifier parameter in the 3307 DEREG REQ specifies which Interface Identifier to de-register. 3309 The SGP examines the contents of the received Interface Identifier 3310 parameter and validates that the ASP is currently registered in the 3311 Application Server(s) related to the included Interface 3312 Identifier(s). If validated, the ASP is de-registered as an ASP in 3313 the related Application Server. 3315 The deregistration procedure does not necessarily imply the deletion 3316 of Link Key and Application Server configuration data at the SGP. 3317 Other ASPs may continue to be associated with the Application 3318 Server, in which case the Link Key data CANNOT be deleted. If a 3319 Deregistration results in no more ASPs in an Application Server, an 3320 SGP MAY delete the Link Key data. 3322 The SGP acknowledges the de-registration requires by returning a DEREG 3323 RSP to the requesting ASP. The result of the de-registration is 3324 found in the Deregistration Result parameter, indicating success or 3325 failure with cause. 3327 An ASP MAY de-register multiple Interface Identifiers at once by 3328 including a number of Interface Identifiers in a single DEREG REQ 3329 message. The SGP MUST response to each deregistration request in a 3330 single DEREG RSP message, indicating the success or failure result 3331 for each Interface Identifier in a separate Deregistration Result 3332 parameter. 3334 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 3336 5.1 Establishment of associations between SGP and MGC examples 3338 5.1.1 Single ASP in an Application Server (1+0 sparing) 3340 This scenario shows the example M2UA message flows for the establishment 3341 of traffic between an SGP and an ASP, where only one ASP is configured 3342 within an AS (no backup). It is assumed that the SCTP association is 3343 already set-up. 3345 SGP ASP1 3346 | 3347 |<---------ASP Up----------| 3348 |--------ASP Up Ack------->| 3349 | | 3350 |<-------ASP Active--------| 3351 |------ASP Active Ack----->| 3352 | | 3353 |------NTFY(AS-ACTIVE)---->| 3355 5.1.2 Single ASP in an Application Server (1+0 sparing) with Dynamic 3356 Registration 3358 This scenario is the same as the one shown in Section 5.1.1 except 3359 with a dynamic registration (automatic allocation) of Interface 3360 Identifier(s). 3362 SGP ASP1 3363 | 3364 |<---------ASP Up----------| 3365 |--------ASP Up Ack------->| 3366 | | 3367 |<--------REG REQ----------| 3368 |------REG REQ RESP------->| 3369 | | 3370 |<-------ASP Active--------| 3371 |------ASP Active Ack----->| 3372 | | 3373 |------NTFY(AS-ACTIVE)---->| 3375 5.1.3 Two ASPs in Application Server (1+1 sparing) 3377 This scenario shows the example M2UA message flows for the establishment 3378 of traffic between an SGP and two ASPs in the same Application Server, 3379 where ASP1 is configured to be active and ASP2 to be standby in the event 3380 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 3381 act as a hot, warm, or cold standby depending on the extent to which ASP1 3382 and ASP2 share call/transaction state or can communicate call state under 3383 failure/withdrawal events. 3385 SGP ASP1 ASP2 3386 | | | 3387 |<--------ASP Up----------| | 3388 |-------ASP Up Ack------->| | 3389 | | | 3390 |<-----------------------------ASP Up----------------| 3391 |----------------------------ASP Up Ack------------->| 3392 | | | 3393 | | | 3394 |<-------ASP Active-------| | 3395 |-----ASP Active Ack----->| | 3396 | | | 3397 | | | 3398 |-----NTFY(AS-ACTIVE)---->| | 3399 | | | 3400 |------------------NTFY(AS-ACTIVE)------------------>| 3402 5.2 ASP Traffic Fail-over Examples 3404 5.2.1 (1+1 Sparing, withdrawal of ASP, backup Override) 3406 Following on from the example in Section 5.1.2, and ASP withdraws from 3407 service: 3409 SGP ASP1 ASP2 3410 | | | 3411 |<-----ASP Inactive-------| | 3412 |----ASP Inactive Ack---->| | 3413 | | | 3414 |------------------NTFY(AS-PENDING)----------------->| 3415 | | | 3416 |<------------------------------ ASP Active----------| 3417 |-----------------------------ASP Active Ack-------->| 3418 | | | 3419 |------------------NTFY(AS-ACTIVE)------------------>| 3420 | | | 3422 In this case, the SGP notifies ASP2 that the AS has moved to the 3423 AS-PENDING state. ASP2 sends ASP Active to bring the AS back to 3424 the AS-ACTIVE state. If ASP2 did not send the ASP Active message 3425 before T(r) expired, the SGP would send a NOTIFY (AS-DOWN). 3427 Note: If the SGP detects loss of the M2UA peer (through a detection 3428 of SCTP failure), the initial SGP-ASP1 ASP Inactive message exchange 3429 would not occur. 3431 SGP ASP1 ASP2 3432 | | | 3433 (detects SCTP failure) 3434 |------------------NTFY(AS-PENDING)----------------->| 3435 | | | 3436 |<------------------------------ ASP Active----------| 3437 |-----------------------------ASP Active Ack-------->| 3438 | | | 3439 |------------------NTFY(AS-ACTIVE)------------------>| 3440 | | | 3442 5.2.2 (1+1 Sparing, backup Override) 3444 Following on from the example in Section 5.1.2, and ASP2 wishes to 3445 override ASP1 and take over the traffic: 3447 SGP ASP1 ASP2 3448 | | | 3449 |<-------------------------------ASP Active----------| 3450 |-----------------------------ASP Active Ack-------->| 3451 |----NTFY(Alt ASP-Act)--->| | 3452 | | | 3454 In this case, the SGP notifies ASP1 that an alternative ASP has 3455 overridden it. 3457 5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 3459 When the M2UA layer on the ASP has a MAUP message to send to the SGP, it 3460 will do the following: 3462 - Determine the correct SGP 3464 - Find the SCTP association to the chosen SGP 3466 - Determine the correct stream in the SCTP association based on 3467 the SS7 link 3469 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3470 Common Header 3472 - Send the MAUP message to the remote M2UA peer in the SGP, over the 3473 SCTP association 3475 When the M2UA layer on the SGP has a MAUP message to send to the ASP, it 3476 will do the following: 3478 - Determine the AS for the Interface Identifier 3480 - Determine the Active ASP (SCTP association) within the AS 3482 - Determine the correct stream in the SCTP association based on 3483 the SS7 link 3485 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3486 Common Header 3488 - Send the MAUP message to the remote M2UA peer in the ASP, over the 3489 SCTP association 3491 5.3.1 SS7 Link Alignment 3493 The MGC can request that a SS7 link be brought into alignment using the 3494 normal or emergency procedure [2][3]. An example of the message flow 3495 to bring a SS7 link in-service using the normal alignment procedure is 3496 shown below. 3498 MTP2 M2UA M2UA MTP3 3499 SGP SGP ASP ASP 3501 <----Start Req---|<---Establish Req----|<----Start Req------ 3503 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 3505 An example of the message flow to bring a SS7 link in-service using the 3506 emergency alignment procedure. 3508 MTP2 M2UA M2UA MTP3 3509 SGP SGP ASP ASP 3511 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 3513 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 3515 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 3517 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 3519 5.3.2 SS7 Link Release 3521 The MGC can request that a SS7 link be taken out-of-service. It uses 3522 the Release Request message as shown below. 3524 MTP2 M2UA M2UA MTP3 3525 SGP SGP ASP ASP 3527 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 3529 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 3531 The SGP can autonomously indicate that a SS7 link has gone out-of- 3532 service as shown below. 3534 MTP2 M2UA M2UA MTP3 3535 SGP SGP ASP ASP 3537 --Out of Serv->|----Release Ind----->|--Out of Serv--> 3539 5.3.3 Set and Clear Local Processor Outage 3541 The MGC can set a Local Processor Outage condition. It uses the 3542 State Request message as shown below. 3544 MTP2 M2UA M2UA MTP3 3545 SGP SGP ASP ASP 3547 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 3549 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 3551 The MGC can clear a Local Processor Outage condition. It uses the 3552 State Request message as shown below. 3554 MTP2 M2UA M2UA MTP3 3555 SGP SGP ASP ASP 3557 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 3559 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 3561 5.3.4 Notification of Remote Processor Outage 3563 The SGP can indicate Remote has entered or exited the Processor Outage 3564 condition for a SS7 link. It uses the State Indication message as shown 3565 below. 3567 MTP2 M2UA M2UA MTP3 3568 SGP SGP ASP ASP 3570 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 3572 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 3574 5.3.5 Notification of SS7 Link Congestion 3576 The SGP can indicate that a SS7 link has become congested. It uses the 3577 Congestion Indication message as shown below. 3579 MTP2 M2UA M2UA MTP3 3580 SGP SGP ASP ASP 3582 ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> 3584 -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> 3586 5.3.6 SS7 Link Changeover 3588 An example of the message flow for an error free changeover is shown 3589 below. In this example, there were three messages in the retransmission 3590 queue that needed to be retrieved. 3592 MTP2 M2UA M2UA MTP3 3593 SGP SGP ASP ASP 3595 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3596 (seq_num = 0) 3598 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3599 (seq_num = BSN) 3601 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3602 (seq_num = FSN) 3604 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3605 (seq_num = 0) 3607 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3608 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3609 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3611 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 3613 Note: The number of Retrieval Indication is dependent on the number of 3614 messages in the retransmit queue that have been requested. Only one 3615 Retrieval Complete Indication SHOULD be sent. 3617 An example of a message flow with an error retrieving the BSN is shown 3618 below. 3620 MTP2 M2UA M2UA MTP3 3621 SGP SGP ASP ASP 3623 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3625 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 3626 (seq_num = -1) 3628 An example of a message flow with an error retrieving the messages is 3629 shown below. 3631 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3633 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3634 (seq_num = BSN) 3636 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3637 (seq_num = FSN) 3639 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3640 (seq_num = -1) 3642 An example of a message flow for a request to drop messages (clear 3643 retransmission buffers) is shown below. 3645 MTP2 M2UA M2UA MTP3 3646 SGP SGP ASP ASP 3648 -Clr RTB Req----|<-StateReq (STATUS_CLEAR_RTB)--|<--Clr RTB Req----- 3650 -Clr RTB Req--->|-StateCfm (STATUS_CLEAR_RTB)-->|---Clr RTB Req----> 3652 5.3.7 Flush and Continue 3654 The following message flow shows a request to flush buffers. 3656 MTP2 M2UA M2UA MTP3 3657 SGP SGP ASP ASP 3659 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 3661 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 3663 The following message flow shows a request to continue. 3665 MTP2 M2UA M2UA MTP3 3666 SGP SGP ASP ASP 3668 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 3670 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 3672 5.3.8 Auditing of SS7 link state 3674 It may be necessary for the ASP to audit the current state of a SS7 link. 3675 The flows below show an example of the request and all the potential 3676 responses. 3678 Below is an example in which the SS7 link is out-of-service. 3680 MTP2 M2UA M2UA MGMT 3681 SGP SGP ASP ASP 3683 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3685 MTP3 3686 ASP 3688 |-----------Release Ind---------->|-Out of Serv Ind-> 3690 MGMT 3691 ASP 3693 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3695 Below is an example in which the SS7 link is in-service. 3697 MTP2 M2UA M2UA MGMT 3698 SGP SGP ASP ASP 3700 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3702 MTP3 3703 ASP 3705 |-----------Establish Cfm-------->|---In Serv Ind--> 3707 MGMT 3708 ASP 3710 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3712 Below is an example in which the SS7 link is in-service, but congested. 3714 MTP2 M2UA M2UA MGMT 3715 SGP SGP ASP ASP 3717 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3719 MTP3 3720 ASP 3722 |-----------Establish Cfm-------->|---In Serv Ind--> 3724 |----------Congestion Ind-------->|---Cong Ind-----> 3726 MGMT 3727 ASP 3729 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3731 Below is an example in which the SS7 link is in-service, but in Remote 3732 Processor Outage. 3734 MTP2 M2UA M2UA MGMT 3735 SGP SGP ASP ASP 3737 |<----State Req (STATUS_AUDIT)----|<---Audit Req---- 3739 MTP3 3740 ASP 3742 |-----------Establish Ind-------->|---In Serv Ind--> 3744 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter---> 3746 MGMT 3747 ASP 3749 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3751 6.0 Timer Values 3753 The recommended default values for M2UA timers are: 3755 T(r) 2 seconds 3756 T(ack) 2 seconds 3757 T(beat) Heartbeat Timer 30 seconds 3759 7.0 Security Considerations 3761 M2UA is designed to carry signalling messages for telephony services. 3762 As such, M2UA MUST involve the security needs of several parties: the 3763 end users of the services; the network providers and the applications 3764 involved. Additional requirements MAY come from local regulation. 3765 While having some overlapping security needs, any security solution 3766 SHOULD fulfill all of the different parties' needs. 3768 7.1 Threats 3770 There is no quick fix, one-size-fits-all solution for security. As a 3771 transport protocol, M2UA has the following security objectives: 3773 * Availability of reliable and timely user data transport. 3774 * Integrity of user data transport. 3775 * Confidentiality of user data. 3777 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 3778 security features, such as: 3780 * Blind Denial of Service Attacks 3781 * Flooding 3782 * Masquerade 3783 * Improper Monopolization of Services 3785 When M2UA is running in professionally managed corporate or service 3786 provider network, it is reasonable to expect that this network includes 3787 an appropriate security policy framework. The "Site Security Handbook" 3788 [10] SHOULD be consulted for guidance. 3790 When the network in which M2UA runs in involves more than one party, it 3791 MAY NOT be reasonable to expect that all parties have implemented 3792 security in a sufficient manner. In such a case, it is recommended that 3793 IPSEC is used to ensure confidentiality of user payload. Consult [11] 3794 for more information on configuring IPSEC services. 3796 7.2 Protecting Confidentiality 3798 Particularly for mobile users, the requirement for confidentiality MAY 3799 include the masking of IP addresses and ports. In this case application 3800 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 3801 Regardless of which level performs the encryption, the IPSEC ISAKMP 3802 service SHOULD be used for key management. 3804 8.0 IANA Considerations 3806 8.1 SCTP Payload Protocol Identifier 3808 A request will be made to IANA to assign an M2UA value for the Payload 3809 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 3810 Payload Protocol Identifier will be registered: 3812 M2UA "2" 3814 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 3815 to indicate which protocol the SCTP is carrying. This Payload Protocol 3816 Identifier is not directly used by SCTP but MAY be used by certain 3817 network entities to identify the type of information being carried in a 3818 Data chunk. 3820 The User Adaptation peer MAY use the Payload Protocol Identifier as a 3821 way of determining additional information about the data being presented 3822 to it by SCTP. 3824 8.2 M2UA Protocol Extensions 3826 This protocol may also be extended through IANA in three ways: 3828 -- through definition of additional message classes, 3829 -- through definition of additional message types, and 3830 -- through definition of additional message parameters. 3832 The definition and use of new message classes, types and parameters is 3833 an integral part of SIGTRAN adaptation layers. Thus, these extensions 3834 are assigned by IANA through an IETF Consensus action as defined in 3835 [RFC2434]. 3837 The proposed extension must in no way adversely affect the general 3838 working of the protocol. 3840 8.2.1 IETF Defined Message Classes 3842 The documentation for a new message class MUST include the following 3843 information: 3845 (a) A long and short name for the message class. 3846 (b) A detailed description of the purpose of the message class. 3848 8.2.2 IETF Defined Message Types 3850 Documentation of the message type MUST contain the following 3851 information: 3853 (a) A long and short name for the new message type. 3854 (b) A detailed description of the structure of the message. 3855 (c) A detailed definition and description of intended use of each field 3856 within the message. 3857 (d) A detailed procedural description of the use of the new message 3858 type within the operation of the protocol. 3859 (e) A detailed description of error conditions when receiving this 3860 message type. 3862 When an implementation receives a message type which it does not support, 3863 it MUST respond with an Error (ERR) message with an Error Code of 3864 Unsupported Message Type. 3866 8.2.3 IETF-defined TLV Parameter Extension 3868 Documentation of the message parameter MUST contain the following 3869 information: 3871 (a) Name of the parameter type. 3872 (b) Detailed description of the structure of the parameter field. This 3873 structure MUST conform to the general type-length-value format 3874 described in Section 3.1.5. 3875 (c) Detailed definition of each component of the parameter value. 3876 (d) Detailed description of the intended use of this parameter type, 3877 and an indication of whether and under what circumstances 3878 multiple instances of this parameter type may be found within the 3879 same message type. 3881 9.0 Acknowledgements 3883 The authors would like to thank John Loughney, Neil Olson, Michael 3884 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 3885 Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark 3886 Kobine, Nitin Tomar, Harsh Bhondwe and Karen King for their valuable 3887 comments and suggestions. 3889 10.0 References 3891 10.1 Normative 3893 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 3894 System No. 7 (SS7)' 3896 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 3897 Message Transfer Part (MTP)' 3899 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 3901 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 3902 of Signalling System Number 7', Volume 1, December 1995 3904 10.2 Informative 3906 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 3908 [6] Architectural Framework for Signalling Transport, RFC 2719, 3909 October 1999 3911 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', 3912 February 1995 3914 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 3915 functions and messages using the services of ITU-T 3916 Recommendation Q.2140', August 1995 3918 [9] ITU-T Recommendation Q.751.1, 'Network Element Management 3919 Information Model for the Message Transfer Part', October 1995 3921 [10] Site Security Handbook, RFC 2196, September 1997 3923 [11] Security Architecture for the Internet Protocol, RFC 2401 3925 [12] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip- 3926 sctp-00.txt, Work In Progress 3928 11.0 Author's Addresses 3930 Ken Morneault Tel: +1-703-484-3323 3931 Cisco Systems Inc. EMail: kmorneau@cisco.com 3932 13615 Dulles Technology Drive 3933 Herndon, VA. 20171 3934 USA 3936 Ram Dantu, Ph.D. Tel +1-214-291-1111 3937 NetRake Corporation EMail rdantu@netrake.com 3938 3000 Technology Drive 3939 Plano, TX 75074 3940 USA 3942 Greg Sidebottom EMail: gregside@home.com 3943 gregside consulting 3944 Kanata, Ontario 3945 Canada 3947 Tom George Tel: +1-972-519-3168 3948 Alcatel USA EMail: tom.george@usa.alcatel.com 3949 1000 Coit Road 3950 Plano, TX 74075 3951 USA 3953 Brian Bidulock Tel +1-972-839-4489 3954 OpenSS7 Project EMail: bidulock@openss7.org 3955 c/o #424, 4701 Preston Park Blvd. 3956 Plano, TX 75093 3957 USA 3959 Jacob Heitz Tek +1-510-747-2917 3960 Lucent Technologies Email: jheitz@lucent.com 3961 1701 Harbor Bay Parkway 3962 Alameda, CA, 94502 3963 USA 3964 Appendix A: Signalling Network Architecture 3966 A Signalling Gateway will support the transport of MTP2-User signalling 3967 traffic received from the SS7 network to one or more distributed ASPs 3968 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 3969 meet any performance and reliability requirements for such transport. 3970 A physical network architecture is required, with data on the 3971 availability and transfer performance of the physical nodes involved in 3972 any particular exchange of information. However, the M2UA protocol is 3973 flexible enough allow its operation and management in a variety of 3974 physical configurations that will enable Network Operators to meet 3975 their performance and reliability requirements. 3977 To meet the stringent SS7 signalling reliability and performance 3978 requirements for carrier grade networks, these Network Operators should 3979 ensure that there is no single point of failure provisioned in the end- 3980 to-end network architecture between an SS7 node and an IP ASP. 3982 Depending of course on the reliability of the SGP and ASP functional 3983 elements, this can typically be met by the spreading SS7 links in a 3984 SS7 linkset [1] across SGPs or SGs, the provision of redundant 3985 QoS-bounded IP network paths for SCTP Associations between SCTP End 3986 Points, and redundant Hosts. The distribution of ASPs within the 3987 available Hosts is also important. For a particular Application 3988 Server, the related ASPs MAY be distributed over at least two Hosts. 3990 An example logical network architecture relevant to carrier-grade 3991 operation in the IP network domain is shown in Figure 7 below: 3993 ************** ************** 3994 * ********__*______________________________*__******** * Host1 3995 SG1 * * SGP1 *__*________________ _______*__* ASP1 * * 3996 * ******** * | | * ******** * 3997 * . * | | * * 3998 * . * | | ************** 3999 ************** | | 4000 | | 4001 ************** | | 4002 * ********__*______________________| 4003 SG2 * * SGP2 *__*________ | 4004 * ******** * | | 4005 * . * | | 4006 * . * | | 4007 ************** | | ************** 4008 | |_____________*__******** * Host2 4009 |_____________________*__* ASP2 * * 4010 . * ******** * 4011 . SCTP Associations * * 4012 . ************** 4013 . 4014 . 4015 . 4017 Figure 7: Logical Model Example 4019 To avoid a single point of failure, it is recommended that a minimum 4020 of two ASPs be configured in an AS list, resident in separate hosts 4021 and, therefore, available over different SCTP associations. For 4022 example, in the network shown in Figure 7, all messages for the 4023 Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in 4024 Host2. The AS list at SGP1 might look like the following: 4026 Interface Identifiers - Application Server #1 4027 ASP1/Host1 - State = Active 4028 ASP2/Host2 - State = Inactive 4030 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 4031 message for the Interface Identifiers registered. ASP2 in Host2 would 4032 normally be brought to the active state upon failure of ASP1/Host1. 4033 In this example, both ASPs are Inactive or Active, meaning that the 4034 related SCTP association and far-end M2UA peer is ready. 4036 For carrier grade networks, Operators should ensure that under failure 4037 or isolation of a particular ASP, stable calls or transactions are not 4038 lost. This implies that ASPs need, in some cases, to share the call/- 4039 transaction state or be able to pass the call/transaction state between 4040 each other. Also, in the case of ASPs performing call processing, 4041 coordination MAY be required with the related Media Gateway to transfer 4042 the MGC control for a particular trunk termination. However, this 4043 sharing or communication is outside the scope of this document.