idnits 2.17.1 draft-ietf-sigtran-m2ua-11.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 60 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 24: '... that other groups MAY also distribute...' RFC 2119 keyword, line 28: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 138: '...cess. Fail-back MAY apply upon the re...' RFC 2119 keyword, line 256: '...Note: STPs MAY be present in the SS7 p...' RFC 2119 keyword, line 275: '... the SCTP functions above MAY NOT be a...' (153 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2911 has weird spacing: '...imitive carry...' == Line 3173 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 (Nov 2001) is 8190 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 691 -- Looks like a reference, but probably isn't: 'M3UA' on line 738 -- Looks like a reference, but probably isn't: 'IUA' on line 743 -- Looks like a reference, but probably isn't: 'M2UA' on line 744 -- Looks like a reference, but probably isn't: 'SUA' on line 746 == Missing Reference: '13' is mentioned on line 2641, but not defined -- Looks like a reference, but probably isn't: 'RFC2434' on line 3842 == Unused Reference: '8' is defined on line 3917, 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 normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '10') ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-00 Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 16 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 Nov 2001 16 SS7 MTP2-User Adaptation Layer 17 19 Status of This Memo 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of RFC 2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups MAY also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and MAY be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as 'work in progress'. 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 To learn the current status of any Internet-Draft, please check the 39 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 40 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 41 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 42 ftp.isi.edu (US West Coast). 44 Abstract 46 This Internet Draft defines a protocol for backhauling of SS7 MTP2 47 User signalling messages over IP using the Stream Control 48 Transmission Protocol (SCTP). This protocol would be used between a 49 Signalling Gateway (SG) and Media Gateway Controller (MGC). It is 50 assumed that the SG receives SS7 signalling over a standard SS7 51 interface using the SS7 Message Transfer Part (MTP) to provide 52 transport. The Signalling Gateway would act as a Signalling Link 53 Terminal. 55 TABLE OF CONTENTS 57 1. Introduction..............................................3 58 1.1 Scope..................................................3 59 1.2 Terminology............................................3 60 1.3 Signalling Transport Architecture......................5 61 1.4 Services Provide by the M2UA Adaptation Layer..........7 62 1.5 Function Provided by the M2UA Layer....................9 63 1.6 Definition of the M2UA Boundaries.....................11 64 2. Conventions..............................................13 65 3. Protocol Elements........................................13 66 3.1 Common Message Header.................................13 67 3.2 M2UA Message Header...................................17 68 3.3 M2UA Messages.........................................18 69 4. Procedures...............................................48 70 4.1 Procedures to Support the M2UA-User Layer.............49 71 4.2 Receipt of Primitives from the Layer Management.......49 72 4.3 AS and ASP State Maintenance..........................51 73 4.4 Link Key Management Procedures........................62 74 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......63 75 5.1 Establishment of associations between SG and MGC......63 76 examples 77 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........66 78 5.3 Layer Management Communication Examples...............66 79 6. Timers...................................................71 80 7. Security Considerations..................................71 81 7.1 Threats................................................71 82 7.2 Protecting Confidentiality.............................72 83 8. IANA Considerations......................................72 84 8.1 SCTP Payload Protocol Identifier.......................72 85 8.2 IUA Protocol Extensions................................72 86 9. Acknowledgements.........................................74 87 10. References...............................................74 88 11. Author's Addresses.......................................75 89 1. Introduction 91 This draft defines a protocol for the backhauling of SS7 [1] MTP2 User 92 [2] [3] (i.e. MTP3) signalling messages over IP using the Stream Control 93 Transmission Protocol (SCTP) [5]. This protocol would be used between 94 a Signalling Gateway (SG) and Media Gateway Controller (MGC). 96 1.1 Scope 98 There is a need for Switched Circuit Network (SCN) signalling protocol 99 delivery from an Signalling Gateway (SG) to a Media Gateway 100 Controller (MGC) [6]. The delivery mechanism addresses the following 101 objectives: 103 * Support for MTP Level 2 / MTP Level 3 interface boundary 104 * Support for communication between Layer Management modules on SG 105 and MGC 106 * Support for management of SCTP active associations between the SG and 107 MGC 109 The SG will terminate up to MTP Level 2 and the MGC will terminate 110 MTP Level 3 and above. In other words, the SG will transport MTP 111 Level 3 messages over an IP network to a MGC. 113 1.2 Terminology 115 Application Server (AS) - A logical entity serving a specific application 116 instance. An example of an Application Server is a MGC handling the 117 MTP Level 3 and call processing for SS7 links terminated by the 118 Signalling Gateways. Practically speaking, an AS is modeled at the SG 119 as an ordered list of one or more related Application Server Processes 120 (e.g., primary, secondary, tertiary, ...). 122 Application Server Process (ASP) - A process instance of an Application 123 Server. Examples of Application Server Processes are active or standby 124 MGC instances. 126 Association - An association refers to a SCTP association. The 127 association will provide the transport for the delivery of protocol 128 data units for one or more interfaces. 130 Backhaul - Refers to the transport of signalling from the point of 131 interface for the associated data stream (i.e., SG function in the MGU) 132 back to the point of call processing (i.e., the MGCU), if this is not 133 local [4]. 135 Fail-over - The capability to reroute signalling traffic as required 136 to an alternate Application Server Process within an Application Server 137 in the event of failure or unavailability of a currently used Application 138 Server Process. Fail-back MAY apply upon the return to service of a 139 previously unavailable Application Server Process. 141 Host - The computing platform that the ASP process is running on. 143 Interface - For the purposes of this document, an interface is a SS7 144 signalling link. 146 Interface Identifier - The Interface Identifier identifies the physical 147 interface at the SG for which the signalling messages are sent/received. 148 The format of the Interface Identifier parameter can be text or integer, 149 the values of which are assigned according to network operator policy. 150 The values used are of local significance only, coordinated between the 151 SG and ASP. 153 Layer Management - Layer Management is a nodal function in an SG or 154 ASP that handles the inputs and outputs between the M2UA layer and a 155 local management entity. 157 Link Key - The link key is a locally unique (between ASP and SG) 158 value that identifies a registration request for a particular 159 Signalling Data Link and Signalling Terminal pair. 161 MTP - The Message Transfer Part of the SS7 protocol 163 MTP2 - MTP Level 2, the signalling datalink layer of SS7 165 MTP3 - MTP Level 3, the signalling network layer of SS7 167 MTP2-User - A protocol that uses the services of MTP Level 2 168 (i.e. MTP3). 170 Network Byte Order: Most significant byte first, a.k.a Big Endian. 172 Signalling Data Link - An SDL refers to a specific communications 173 facility that connects two Signalling Link Terminals. 175 Signalling Gateway (SG) - An SG is a signalling agent at the edge of 176 the IP network. An SG appears to the SS7 as one or more Signalling 177 Link Terminals that are connected to one or more Signalling Data Links 178 in the SS7 network. An SG contains a set of one or more unique 179 Signalling Gateway Processes, on which one or more is normally 180 actively processing traffic. Where an SG contains more than one SGP, 181 the SG is a logical entity. 183 Signalling Gateway Process (SGP) - A process instance that uses M2UA to 184 communicate to and from a Signalling Link Terminal. It serves as an 185 active, backup or load-sharing proces of a Signalling Gateway. 187 Signalling Link Terminal (SLT) - Refers to the means of performing all 188 of the functions defined at MTP level 2 regardless of their 189 implementation [2]. 191 Stream - A stream refers to an SCTP stream; a unidirectional logical 192 channel established from one SCTP endpoint to another associated SCTP 193 endpoint, within which all user messages are delivered in-sequence 194 except for those submitted to the unordered delivery service. 196 1.3 M2UA Overview 198 The framework architecture that has been defined for SCN signalling 199 transport over IP [6] uses two components: a signalling common 200 transport protocol and an adaptation module to support the services 201 expected by a particular SCN signalling protocol from its underlying 202 protocol layer. 204 Within this framework architecture, this document defines a SCN 205 adaptation module that is suitable for the transport of SS7 MTP2 User 206 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 207 of the Stream Control Transmission Protocol [5] as the underlying 208 reliable signalling common transport protocol. 210 In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling 211 is transmitted and received from the PSTN over a standard SS7 network 212 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 213 to provide reliable transport of the MTP3-User signalling messages to and 214 from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). 215 The SG then provides a interworking of transport functions 216 with the IP transport, in order to transfer the MTP2-User signalling 217 messages to and from an Application Server Process where the peer MTP2- 218 User protocol layer exists. 220 1.3.1 Example - SG to MGC 222 In a Signalling Gateway, it is expected that the SS7 signalling is 223 received over a standard SS7 network termination, using the SS7 Message 224 Transfer Part (MTP) to provide transport of SS7 signalling messages to 225 and from an SS7 Signalling End Point (SEP) or SS7 Signalling Transfer 226 Point (STP). In other words, the SG acts as a Signalling Link Terminal 227 (SLT) [2]. The SG then provides interworking of transport functions 228 with IP Signalling Transport, in order to transport the MTP3 signalling 229 messages to the MGC where the peer MTP3 protocol layer exists, as shown 230 below: 232 ****** SS7 ****** IP ******* 233 *SEP *-----------* SG *-------------* MGC * 234 ****** ****** ******* 236 +----+ +----+ 237 |S7UP| |S7UP| 238 +----+ +----+ 239 |MTP + |MTP | 240 | L3 | (NIF) |L3 | 241 +----+ +----+----+ +----+ 242 |MTP | |MTP |M2UA| |M2UA| 243 | | | +----+ +----+ 244 |L2 | |L2 |SCTP| |SCTP| 245 |L1 | |L1 +----+ +----+ 246 | | | |IP | |IP | 247 +----+ +---------+ +----+ 249 NIF - Nodal Interworking Function 250 SEP - SS7 Signalling Endpoint 251 IP - Internet Protocol 252 SCTP - Stream Control Transmission Protocol (Reference [5]) 254 Figure 1 M2UA in the SG to MGC Application 256 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 258 It is recommended that the M2UA use the services of the Stream 259 Control Transmission Protocol (SCTP) as the underlying reliable 260 common signalling transport protocol. The use of SCTP provides 261 the following features: 263 - explicit packet-oriented delivery (not stream-oriented) 264 - sequenced delivery of user messages within multiple streams, 265 with an option for order-of-arrival delivery of individual 266 user messages, 267 - optional multiplexing of user messages into SCTP datagrams, 268 - network-level fault tolerance through support of multi-homing 269 at either or both ends of an association, 270 - resistance to flooding and masquerade attacks, and 271 - data segmentation to conform to discovered path MTU size 273 There are scenarios without redundancy requirements and 274 scenarios in which redundancy is supported below the transport 275 layer. In these cases, the SCTP functions above MAY NOT be a 276 requirement and TCP can be used as the underlying common 277 transport protocol. 279 1.3.2 ASP Fail-over Model and Terminology 281 The M2UA layer supports ASP fail-over functions in order to support a 282 high availability of call and transaction processing capability. All 283 MTP2-User messages incoming to a SGP from the SS7 network are assigned 284 to the unique Application Server, based on the Interface Identifier of 285 the message. 287 The M2UA layer supports a n+k redundancy model (active-standby, 288 loadsharing, broadcast) where n is the minimum number of redundant 289 ASPs required to handle traffic and k ASPs are available to take over 290 for a failed or unavailable ASP. Note that 1+1 active/standby 291 redundancy is a subset of this model. A simplex 1+0 model is also 292 supported as a subset, with no ASP redundancy. 294 1.3.3 Client/Server Model 296 It is recommended that the SGP and ASP be able to support both client 297 and server operation. The peer endpoints using M2UA SHOULD be 298 configured so that one always takes on the role of client and the 299 other the role of server for initiating SCTP associations. The 300 default orientation would be for the SGP to take on the role of server 301 while the ASP is the client. In this case, ASPs SHOULD initiate the 302 SCTP association to the SGP. 304 The SCTP and TCP Registered User Port Number Assignment for M2UA 305 is 2904. 307 1.4 Services Provided by the M2UA Adaptation Layer 309 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 310 point in the IP network, so that the M2UA protocol layer is required to 311 provide the equivalent set of services to its users as provided by the 312 MTP Level 2 to MTP Level 3. 314 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 316 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 317 a seamless, or as seamless as possible, operation of the MTP2-User peers 318 in the SS7 and IP domains. An example of the primitives that need to be 319 supported can be found in [7]. 321 1.4.2 Support for communication between Layer Management modules 322 on SG and MGC 324 The M2UA layer needs to provide some messages that will facilitate 325 communication between Layer Management modules on the SG and MGC. 327 To facilitate reporting of errors that arise because of backhauling MTP 328 Level 3 scenario, the following primitive is defined: 330 M-ERROR 332 The M-ERROR message is used to indicate an error with a received 333 M2UA message (e.g., an interface identifier value is not known to the 334 SG). 336 1.4.3 Support for management of active associations between SG and MGC 338 The M2UA layer on the SG keeps the state of the configured ASPs. A set 339 of primitives between M2UA layer and the Layer Management are defined 340 below to help the Layer Management manage the association(s) between 341 the SG and the MGC. The M2UA layer can be instructed by the Layer 342 Management to establish a SCTP association to a peer M2UA node. This 343 procedure can be achieved using the M-SCTP ESTABLISH primitive. 345 M-SCTP_ESTABLISH 347 The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm 348 the establishment of a SCTP association to a peer M2UA node. 350 M-SCTP_RELEASE 352 The M-SCTP_RELEASE primitives are used to request, indicate, and 353 confirm the release of a SCTP association to a peer M2UA node. 355 The M2UA layer MAY also need to inform the status of the SCTP 356 association(s) to the Layer Management. This can be achieved using 357 the following primitive. 359 M-SCTP_STATUS 361 The M-SCTP_STATUS primitive is used to request and indicate the status 362 of underlying SCTP association(s). 364 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 365 status (i.e., failure, active, etc.), so that messages can be exchanged 366 between M2UA layer peers to stop traffic to the local M2UA user. This 367 can be achieved using the following primitive. 369 M-ASP_STATUS 371 The ASP status is stored inside M2UA layer on both the SG and MGC 372 sides. The M-ASP_STATUS primitive can be used by Layer Management to 373 request the status of the Application Server Process from the M2UA 374 layer. This primitive can also be used to indicate the status of the 375 Application Server Process. 377 M-ASP_MODIFY 379 The M-ASP_MODIFY primitive can be used by Layer Management to modify 380 the status of the Application Server Process. In other words, the 381 Layer Management on the ASP side uses this primitive to initiate 382 the ASPM procedures. 384 M-AS_STATUS 386 The M-AS_STATUS primitive can be used by Layer Management to request 387 the status of the Application Server. This primitive can also be 388 used to indicate the status of the Application Server. 390 1.5 Functions Provided by the M2UA Layer 392 1.5.1 Mapping 394 The M2UA layer MUST maintain a map of a Interface ID to a physical 395 interface on the Signalling Gateway. A physical interface would be a 396 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 397 MUST also maintain a map of Interface Identifier to SCTP association 398 and to the related stream within the association. 400 The SGP maps an Interface Identifier to an SCTP association/stream 401 only when an ASP sends an ASP Active message for a particular Interface 402 Identifier. It MUST be noted, however, that this mapping is dynamic 403 and could change at any time due to a change of ASP state. This mapping 404 could even temporarily be invalid, for example during failover of one 405 ASP to another. Therefore, the SGP MUST maintain the states of AS/ASP 406 and reference them during the routing of an messages to an AS/ASP. 408 Note that only one SGP SHOULD provide Signalling Link Terminal 409 services to an SS7 link. Therefore, within an SG, an Application 410 Server MUST be active for only one SGP at any given point in time. 412 An example of the logical view of relationship between SS7 link, 413 Interface Identifier, AS and ASP in an SGP is shown below: 415 /-------------------------------------------------+ 416 / /----------------------------------------------|--+ 417 / / v | 418 / / +----+ act+-----+ +-------+ -+--+|-+- 419 SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v 420 / +----+ | +----+ | +-----+ +-------+ -+--+--+- 421 / +->| AS |--+ Streams 422 / +----+ | +----+ stb+-----+ 423 SS7 link2-------->|IID |-+ | ASP | 424 +----+ +-----+ 426 where IID = Interface Identifier 428 A SGP MAY support more than one AS. An AS MAY support more than 429 one Interface Identifier. 431 1.5.2 Support for the management of SCTP associations between the 432 SGPs and ASPs 434 The M2UA layer at the SG maintains the availability state of all 435 configured ASPs, in order to manage the SCTP associations and the 436 traffic between the SG and ASPs. As well, the active/inactive state 437 of remote ASP(s) are also maintained. The Active ASP(s) are the 438 one(s) currently receiving traffic from the SG. 440 The M2UA layer MAY be instructed by local management to establish an 441 SCTP association to a peer M2UA node. This can be achieved using the 442 M-SCTP_ESTABLISH primitive to request, indicate and confirm the 443 establishment of an SCTP association with a peer M2UA node. 445 The M2UA layer MAY also need to inform local management of the status of 446 the underlying SCTP associations using the M-SCTP_STATUS request and 447 indication primitive. For example, the M2UA MAY inform local management 448 of the reason for the release of an SCTP association, determined either 449 locally within the M2UA layer or by a primitive from the SCTP. 451 Also the M2UA layer may need to inform the local management of the 452 change in status of an ASP or AS. This may be achieved using the M-ASP 453 STATUS request or M-AS_STATUS request primitives. 455 1.5.3 Status of ASPs 457 The M2UA layer on the SG MUST maintain the state of the ASPs it is 458 supporting. The state of an ASP changes because of reception of 459 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 460 or reception of indications from the local SCTP association. ASP 461 state transition procedures are described in Section 4.3.1. 463 At a SGP, an Application Server list MAY contain active and inactive 464 ASPs to support ASP fail-over procedures. When, for example, both 465 a primary and a backup ASP are available, M2UA peer protocol is 466 required to control which ASP is currently active. The ordered 467 list of ASPs within a logical Application Server is kept updated in 468 the SGP to reflect the active Application Server Process. 470 Also the M2UA layer MAY need to inform the local management of the 471 change in status of an ASP or AS. This can be achieved using the M-ASP 472 STATUS or M-AS_STATUS primitives. 474 1.5.4 SCTP Specifics 476 1.5.4.1 SCTP Stream Management 478 SCTP allows a user specified number of streams to be opened during 479 initialization of the association. It is the responsibility of the 480 M2UA layer to ensure proper management of these streams. Because of 481 the unidirectional nature of streams, a M2UA layer is not aware of the 482 stream information from its peer M2UA layer. Instead, the Interface 483 Identifier is in the M2UA message header. 485 The use of SCTP streams within M2UA is recommended in order to minimize 486 transmission and buffering delay, therefore improving the overall 487 performance and reliability of the signalling elements. A separate 488 SCTP stream can be used for each SS7 link. Or, an implementation may 489 choose to split the SS7 link across several streams based on SLS. 490 This method may be of particular interest for high speed SS7 links 491 (MTP3b) since high speed links have a 24-bit sequence number and the 492 stream sequence number is 16-bits. 494 SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) 495 messages (see Section 3) since stream '0' SHOULD only be used for ASP 496 Management (ASPM) messages (see Section 4.3.3). 498 1.5.5 Seamless SS7 Network Management Interworking 500 The M2UA layer on the SGP SHOULD pass an indication of unavailability 501 of the M2UA-User (MTP3) to the local Layer Management, if the 502 currently active ASP moves from the ACTIVE state. The actions taken by 503 M2UAon the SGP with regards to MTP Level 2 should be in accordance 504 with the appropriate MTP specifications. 506 1.5.6 Flow Control / Congestion 508 It is possible for the M2UA layer to be informed of IP network 509 congestion onset and abatement by means of an implementation dependent 510 function (i.e. an indication from the SCTP). The handling of 511 this congestion indication by M2UA is implementation dependent. 512 However, the actions taken by the SG should be accordance with the 513 appropriate MTP specification and should enable SS7 functionality 514 (e.g. flow control) to be correctly maintained. 516 1.5.7 Audit of SS7 Link State 518 After a failover of one ASP to another ASP, it may be necessary for the 519 M2UA on the ASP to audit the current SS7 link state to ensure consistency. 520 The M2UA on the SGP would respond to the audit request with information 521 regarding the current state of the SS7 link (i.e. in-service, 522 out-of-service, congestion state, LPO/RPO state). 524 1.6 Definition of the M2UA Boundaries 526 1.6.1 Definition of the M2UA / MTP Level 3 boundary 528 DATA 529 ESTABLISH 530 RELEASE 531 STATE 532 DATA RETRIEVAL 533 DATA RETRIEVAL COMPLETE 535 1.6.2 Definition of the M2UA / MTP Level 2 boundary 537 DATA 538 ESTABLISH 539 RELEASE 540 STATE 541 DATA RETRIEVAL 542 DATA RETRIEVAL COMPLETE 544 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 546 The upper layer and layer management primitives provided by SCTP are 547 provided in Reference [5] Section 9. 549 1.6.4 Definition of Layer Management / M2UA Boundary 551 M-SCTP_ESTABLISH request 552 Direction: LM -> M2UA 553 Purpose: LM requests ASP to establish an SCTP association with an 554 SGP. 556 M-SCTP_ESTABLISH confirm 557 Direction: M2UA -> LM 558 Purpose: ASP confirms to LM that it has established an SCTP 559 association with an SGP. 561 M-SCTP_ESTABLISH indication 562 Direction: M2UA -> LM 563 Purpose: SGP informs LM that an ASP has established an SCTP 564 association. 566 M-SCTP_RELEASE request 567 Direction: LM -> M2UA 568 Purpose: LM requests ASP to release an SCTP association with SGP. 570 M-SCTP_RELEASE confirm 571 Direction: M2UA -> LM 572 Purpose: ASP confirms to LM that it has released SCTP association 573 with SGP. 575 M-SCTP_RELEASE indication 576 Direction: M2UA -> LM 577 Purpose: SGP informs LM that ASP has released an SCTP association. 579 M-SCTP_RESTART indication 580 Direction: M2UA -> LM 581 Purpose: M2UA informs LM that a SCTP Restart indication has 582 been received. 584 M-SCTP_STATUS request 585 Direction: LM -> M2UA 586 Purpose: LM requests M2UA to report status of SCTP association. 588 M-SCTP_STATUS indication 589 Direction: M2UA -> LM 590 Purpose: M2UA reports status of SCTP association. 592 M-ASP_STATUS request 593 Direction: LM -> M2UA 594 Purpose: LM requests SGP to report status of remote ASP. 596 M-ASP_STATUS indication 597 Direction: M2UA -> LM 598 Purpose: SGP reports status of remote ASP. 600 M-AS_STATUS request 601 Direction: LM -> M2UA 602 Purpose: LM requests SG to report status of AS. 604 M-AS_STATUS indication 605 Direction: M2UA -> LM 606 Purpose: SG reports status of AS. 608 M-NOTIFY indication 609 Direction: M2UA -> LM 610 Purpose: ASP reports that it has received a NOTIFY message 611 from its peer. 613 M-ERROR indication 614 Direction: M2UA -> LM 615 Purpose: ASP or SGP reports that it has received an ERROR 616 message from its peer. 618 M-ASP_UP request 619 Direction: LM -> M2UA 620 Purpose: LM requests ASP to start its operation and send an ASP UP 621 message to the SGP. 623 M-ASP_UP confirm 624 Direction: M2UA -> LM 625 Purpose: ASP reports that it has received an ASP UP Acknowledgement 626 message from the SGP. 628 M-ASP_DOWN request 629 Direction: LM -> M2UA 630 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 631 message to the SGP. 633 M-ASP_DOWN confirm 634 Direction: M2UA -> LM 635 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 636 message from the SGP. 638 M-ASP_ACTIVE request 639 Direction: LM -> M2UA 640 Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP. 642 M-ASP_ACTIVE confirm 643 Direction: M2UA -> LM 644 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 645 message from the SGP. 647 M-ASP_INACTIVE request 648 Direction: LM -> M2UA 649 Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP. 651 M-ASP_INACTIVE confirm 652 Direction: M2UA -> LM 653 Purpose: ASP reports that is has received an ASP INACTIVE 654 Acknowledgement message from the SGP. 656 M-LINK_KEY_REG Request 657 Direction: LM -> M2UA 658 Purpose: LM requests ASP to register Link Key with SG by sending REG 659 REQ message. 661 M-LINK_KEY_REG Confirm 662 Direction: M2UA -> LM 663 Purpose: ASP reports to LM that it has successfully received a REG 664 RSP message from SG. 666 M-LINK_KEY_REG Indication 667 Direction: M2UA -> LM 668 Purpose: SG reports to LM that it has successfully processed an 669 incoming REG REQ message from ASP. 671 M-LINK_KEY_DEREG Request 672 Direction: LM -> M2UA 673 Purpose: LM requests ASP to de-register Link Key with SG by sending 674 DEREG REQ message. 676 M-LINK_KEY_DEREG Confirm 677 Direction: M2UA -> LM 678 Purpose: ASP reports to LM that it has successfully received a 679 DEREG RSP message from SG. 681 M-LINK_KEY_DEREG Indication 682 Direction: M2UA -> LM 683 Purpose: SG reports to LM that it has successfully processed an 684 incoming DEREG REQ message from ASP. 686 2.0 Conventions 688 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 689 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 690 in this document, are to be interpreted as described in [RFC2119]. 692 3.0 Protocol Elements 694 This section describes the format of various messages used in this 695 protocol. 697 3.1 Common Message Header 699 The protocol messages for MTP2-User Adaptation require a message 700 structure which contains a version, message class, message type, message 701 length, and message contents. This message header is common among all 702 signalling protocol adaptation layers: 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Version | Spare | Message Class | Message Type | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Message Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 2 Common Message Header 714 All fields in an M2UA message MUST be transmitted in the network byte 715 order, unless otherwise stated. 717 3.1.1 Version 719 The version field (vers) contains the version of the M2UA adaptation 720 layer. The supported versions are: 722 Value Version 723 ----- ------- 724 1 Release 1.0 726 3.1.2 Spare 728 The Spare field is 8-bits. It SHOULD be set to all '0's by the sender 729 and ignored by the receiver. 731 3.1.3 Message Class 733 The following List contains the valid Message Classes: 735 Message Class: 8 bits (unsigned integer) 737 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 738 1 Transfer Messages [M3UA] 739 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 740 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 741 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 742 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) 743 Messages [IUA] 744 6 MTP2 User Adaptation (MAUP) Messages [M2UA] 745 7 Connectionless Messages [SUA] 746 8 Connection-Oriented Messages [SUA] 747 9 Routing Key Management (RKM) Messages (M3UA) 748 10 Interface Identifier Management (IIM) Messages (M2UA) 749 11 to 127 Reserved by the IETF 750 128 to 255 Reserved for IETF-Defined Message Class extensions 752 3.1.4 Message Type 754 The following List contains the Message Types for the valid Message 755 Classes: 757 MTP2 User Adaptatation (MAUP) Messages 759 0 Reserved 760 1 Data 761 2 Establish Request 762 3 Establish Confirm 763 4 Release Request 764 5 Release Confirm 765 6 Release Indication 766 7 State Request 767 8 State Confirm 768 9 State Indication 769 10 Data Retrieval Request 770 11 Data Retrieval Confirm 771 12 Data Retrieval Indication 772 13 Data Retrieval Complete Indication 773 14 Congestion Indication 774 15 Data Acknowledge 775 16 to 127 Reserved by the IETF 776 128 to 255 Reserved for IETF-Defined MAUP extensions 777 Application Server Process State Maintenance (ASPSM) messages 779 0 Reserved 780 1 ASP Up (UP) 781 2 ASP Down (DOWN) 782 3 Heartbeat (BEAT) 783 4 ASP Up Ack (UP ACK) 784 5 ASP Down Ack (DOWN ACK) 785 6 Heartbeat Ack (BEAT ACK) 786 7 to 127 Reserved by the IETF 787 128 to 255 Reserved for IETF-Defined ASPSM extensions 789 Application Server Process Traffic Maintenance (ASPTM) messages 791 0 Reserved 792 1 ASP Active (ACTIVE) 793 2 ASP Inactive (INACTIVE) 794 3 ASP Active Ack (ACTIVE ACK) 795 4 ASP Inactive Ack (INACTIVE ACK) 796 5 to 127 Reserved by the IETF 797 128 to 255 Reserved for IETF-Defined ASPTM extensions 799 Management (MGMT) Messages 801 0 Error (ERR) 802 1 Notify (NTFY) 803 2 to 127 Reserved by the IETF 804 128 to 255 Reserved for IETF-Defined MGMT extensions 806 Interface Identifier Management (IIM) Messages 808 0 Reserved 809 1 Registration Request (REG REQ) 810 2 Registration Response (REG RSP) 811 3 Deregistration Request (DEREG REQ) 812 4 Deregistration Response (DEREG RSP) 813 5 to 127 Reserved by the IETF 814 128 to 255 Reserved for IETF-Defined IIM extensions 816 3.1.5 Message Length 818 The Message Length defines the length of the message in octets, 819 including the header. The Message Length MUST include parameter 820 padding bytes, if any. The Message Length MUST NOT be longer 821 than a MTP3 message [2] [3] plus the length of the common and 822 M2UA message headers. 824 3.1.6 Variable-Length Parameter Format 826 M2UA messages consist of a Common Header followed by zero or more 827 variable-length parameters, as defined by the message type. The 828 variable-length parameters contained in a message are defined in a 829 Tag-Length-Value format as shown below. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Parameter Tag | Parameter Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 \ \ 837 / Parameter Value / 838 \ \ 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Mandatory parameters MUST be placed before optional parameters in a 842 message. 844 Parameter Tag: 16 bits (unsigned integer) 846 The Type field is a 16 bit identifier of the type of parameter. It 847 takes a value of 0 to 65534. The common parameters used by adaptation 848 layers are in the range of 0x00 to 0xff. The M2UA specific parameters 849 have Tags in the range 0x300 to 0x3ff. 851 The common parameter tags (used by all User Adaptation layers) that 852 M2UA uses are defined below: 854 Parameter Value Parameter Name 855 --------------- -------------- 856 0 (0x00) Reserved 857 1 (0x01) Interface Identifier (Integer) 858 2 (0x02) Unused 859 3 (0x03) Interface Identifier (Text) 860 4 (0x04) Info String 861 5 (0x05) Unused 862 6 (0x06) Unused 863 7 (0x07) Diagnostic Information 864 8 (0x08) Interface Identifier (Integer Range) 865 9 (0x09) Heartbeat Data 866 10 (0x0a) Unused 867 11 (0x0b) Traffic Mode Type 868 12 (0x0c) Error Code 869 13 (0x0d) Status Type/Information 870 14 (0x0e) Unused 871 15 (0x0f) Unused 872 16 (0x10) Unused 873 17 (0x11) ASP Identifier 874 18-255 Reserved 876 The M2UA specific parameter Tags defined are as follows: 878 Parameter Value Parameter Name 879 --------------- -------------- 880 768 (0x0300) Protocol Data 1 881 769 (0x0301) Protocol Data 2 (TTC) 882 770 (0x0302) State Request 883 771 (0x0303) State Event 884 772 (0x0304) Congestion Status 885 773 (0x0305) Discard Status 886 774 (0x0306) Action 887 775 (0x0307) Sequence Number 888 776 (0x0308) Retrieval Result 889 777 (0x0309) Link Key 890 778 (0x030a) Local-LK-Identifier 891 779 (0x030b) Signalling Data Terminal (SDT) Identifier 892 780 (0x030c) Signailng Data Link (SDL) Identifier 893 781 (0x030d) Registration Result 894 782 (0x030e) Registration Status 895 783 (0x030f) De-Registration Result 896 784 (0x0310) De-Registration Status 897 785 (0x0311) Correlation Id 898 786 (0x0312) Correlation Id Ack 900 Parameter Length: 16 bits (unsigned integer) 902 The Parameter Length field contains the size of the parameter in 903 bytes, including the Parameter Tag, Parameter Length, and Parameter 904 Value fields. Thus, a parameter with a zero-length Parameter Value 905 field would have a Length field of 4. The Parameter Length does not 906 include any padding bytes. 908 Parameter Value: variable-length. 910 The Parameter Value field contains the actual information to be 911 transferred in the parameter. 913 The total length of a parameter (including Tag, Parameter Length and 914 Value fields) MUST be a multiple of 4 bytes. If the length of the 915 parameter is not a multiple of 4 bytes, the sender pads the Parameter 916 at the end (i.e., after the Parameter Value field) with all zero 917 bytes. The length of the padding is NOT included in the parameter 918 length field. A sender MUST NOT pad with more than 3 bytes. The 919 receiver MUST ignore the padding bytes. 921 3.2 M2UA Message Header 923 In addition to the common message header, there will be a M2UA 924 specific message header. The M2UA specific message header will 925 immediately follow the common message header, but will only be used 926 with MAUP messages. 928 This message header will contain the Interface Identifier. The 929 Interface Identifier identifies the physical interface at the SG for 930 which the signalling messages are sent/received. The format of the 931 Interface Identifier parameter can be text or integer, the values of 932 which are assigned according to network operator policy. The values 933 used are of local significance only, coordinated between the SG and 934 ASP. 936 The integer formatted Interface Identifier MUST be supported. The 937 text formatted Interface Identifier MAY optionally be supported. 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Tag (0x1) | Length=8 | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Interface Identifier (integer) | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 Figure 3 M2UA Message Header (Integer-based Interface Identifier) 949 The Tag value for Integer-based Interface Identifier is 0x1. The 950 length is always set to a value of 8. 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Tag (0x3) | Length | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Interface Identifier (text) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Figure 4 M2UA Message Header (Text-based Interface Identifier) 964 The Tag value for the Text-based Interface Identifier is 0x3. The 965 length is equal to the string length of the Interface Identifier 966 name plus four bytes for the Tag and Length fields. 968 3.3 M2UA Messages 970 The following section defines the messages and parameter contents. 971 The M2UA messages will use the common message header (Figure 2) and 972 the M2UA message header (Figure 3). 974 3.3.1 MTP2 User Adaptation Messages 976 3.3.1.1 Data 978 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). 979 The Data message contains the following parameter: 981 Protocol Data (mandatory) 982 Correlation Id (optional) 984 The format for the Data Message parameters is as follows: 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Tag (0x300) | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 / \ 992 \ Protocol Data / 993 / \ 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Tag (0x311) | Length = 8 | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Correlation Id | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 The Protocol Data field contains the MTP2-User application message in 1001 network byte order starting with the Signalling Information Octet (SIO). 1002 The Correlation Id parameter uniquely identifies the MSU carried in the 1003 Protocol Data within an AS. This Correlation Id parameter is assigned 1004 by the sending M2UA. The purpose of the Correlation Id is to permit 1005 the newly active ASP to synchronize its processing of the traffic in 1006 each ordered stream with other ASPs in the broadcast group. 1008 The format for a Data Message with TTC PDU parameters is as follows: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Tag (0x301) | Length | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 / \ 1016 \ Protocol Data / 1017 / \ 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Tag (0x311) | Length = 8 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Correlation Id | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 The Protocol Data field contains the MTP2-User application message in 1025 network byte order starting with the Length Indicator (LI) octet. 1026 The Japanese TTC variant uses the spare bits of the LI octet for 1027 priority. The length of the Protocol Data MUST NOT exceed the length 1028 of a MTP2-User application message [2] [3]. 1030 3.3.1.2 Data Acknowledge Message 1032 The Data Acknowledge message contains the Correlation Id of the Data 1033 message which the sending M2UA is acknowledging as successfully 1034 processed to the peer M2UA. 1036 The Data Acknowledge message contains the following parameter: 1038 Correlation Id Mandatory 1040 The following format MUST be used for the Data Ack Message: 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Tag (0x312) | Length = 8 | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Correlation Id | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 The Correlation Id parameter of the Data message and the Data Ack 1051 message provide a mechanism, for those SG implementations capable for 1052 taking advantage of them, to obtain an acknowledgement that the MSU 1053 has been transferred to the M2UA peer before acknowleding the MSU to 1054 the SS7 peer, removing the risk of losing messages due to association 1055 failure or SCTP congestion. 1057 The Data Ack message MUST be sent if a Correlation Id parameter is 1058 received from the peer. Otherwise the Data Ack message SHOULD NOT be 1059 sent. 1061 If the Data Acknowledge is not sent for Correlation Id(s) or is sent 1062 with Invalid Correlation Id(s), the SS7 link will eventually fail 1063 dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs. 1065 3.3.1.3 Establish (Request, Confirmation) 1067 The Establish Request message is used to establish the SS7 link or to 1068 indicate that the channel has been established. The MGC controls the 1069 state of the SS7 link. When the MGC desires the SS7 link to be 1070 in-service, it will send the Establish Request message. Note that 1071 the SGP MAY already have the SS7 link established at its layer. 1072 If so, upon receipt of an Establish Request, the SGP takes no action 1073 except to send an Establish Confirm. 1075 When the MGC sends an M2UA Establish Request message, the MGC MAY 1076 start a timer. This timer would be stopped upon receipt of an M2UA 1077 Establish Confirm. If the timer expires, the MGC would resend the 1078 M2UA Establish Request message and restart the timer. In other words, 1079 the MGC MAY continue to request the establishment of the datalink 1080 on periodic basis until the desired state is achieved or take some 1081 other action (notify the Management Layer). 1083 The mode (Normal or Emergency) for bringing the SS7 link in service is 1084 defaulted to Normal. The State Request (described in Section 3.3.1.5 1085 below) can be used to change the mode to Emergency. 1087 3.3.1.4 Release (Request, Indication, Confirmation) 1089 This Release Request message is used to release the channel. The 1090 Release Confirm and Indication messages are used to indicate that the 1091 channel has been released. 1093 3.3.1.5 State Request 1095 The State Request message can be sent from a MGC to cause an action 1096 on a particular SS7 link supported by the Signalling Gateway Process. 1097 The SGP sends a State Confirm to the MGC if the action has been 1098 successfully completed. The State Confirm reflects that state value 1099 received in the State Request message. 1101 The State Request message contains the following parameter: 1103 State (mandatory) 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Tag (0x302) | Length = 8 | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | State | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 The valid values for State are shown in the following table. 1115 Define Value Description 1116 STATUS_LPO_SET 0x0 Request local processor outage 1117 STATUS_LPO_CLEAR 0x1 Request local processor outage 1118 recovered 1119 STATUS_EMER_SET 0x2 Request emergency alignment 1120 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1121 emergency) 1122 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1123 and retransmit queues 1124 STATUS_CONTINUE 0x5 Continue or Resume 1125 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1126 STATUS_AUDIT 0x7 Audit state of link 1127 STATUS_CONG_CLEAR 0x8 Congestion cleared 1128 STATUS_CONG_ACCEPT 0x9 Congestion accept 1129 STATUS_CONG_DISCARD 0xa Congestion discard 1131 3.3.1.6 State Confirm 1133 The State Confirm message will be sent by the SGP in response to a State 1134 Request from the MGC. The State Confirm reflects that state value 1135 received in the State Request message. 1137 The State Confirm message contains the following parameter: 1139 State (mandatory) 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Tag (0x302) | Length = 8 | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | State | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 The valid values for State are shown in the following table. The value 1150 of the State field should reflect the value received in the State 1151 Request message. 1153 Define Value Description 1154 STATUS_LPO_SET 0x0 Request local processor outage 1155 STATUS_LPO_CLEAR 0x1 Request local processor outage 1156 recovered 1157 STATUS_EMER_SET 0x2 Request emergency alignment 1158 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1159 emergency) 1160 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1161 and retransmit queues 1162 STATUS_CONTINUE 0x5 Continue or Resume 1163 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1164 STATUS_AUDIT 0x7 Audit state of link 1165 STATUS_CONG_CLEAR 0x8 Congestion cleared 1166 STATUS_CONG_ACCEPT 0x9 Congestion accept 1167 STATUS_CONG_DISCARD 0xa Congestion discard 1169 3.3.1.7 State Indication 1171 The MTP2 State Indication message can be sent from a SGP to an ASP to 1172 indicate a condition on a SS7 link. 1174 The State Indication message contains the following parameter: 1176 Event (mandatory) 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Tag (0x303) | Length = 8 | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Event | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 The valid values for Event are shown in the following table. 1188 Define Value Description 1189 EVENT_RPO_ENTER 0x1 Remote entered processor outage 1190 EVENT_RPO_EXIT 0x2 Remote exited processor outage 1191 EVENT_LPO_ENTER 0x3 Link entered processor outage 1192 EVENT_LPO_EXIT 0x4 Link exited processor outage 1194 3.3.1.8 Congestion Indication 1196 The Congestion Indication message can be sent from a Signalling Gateway 1197 Process to an ASP to indicate the congestion status and discard status 1198 of a SS7 link. When the MSU buffer fill increases above an Onset 1199 threshold or decreases below an Abatement threshold or crosses a Discard 1200 threshold in either direction, the SGP SHALL send a congestion indication 1201 message. 1203 The SGP SHALL send the message only when there is actually a change 1204 in either the discard level or the congestion level to report, 1205 meaning it is different from the previously sent message. In addition, 1206 the SGP SHALL use an implementation dependent algorithm to limit the 1207 frequency of congestion indication messages. 1209 An implementation may optionally send Congestion Indication messages on 1210 a "high priority" stream in order to potentially reduce delay (Refer to 1211 [12] for more details). 1213 The Congestion Indication message contains the following parameters: 1215 Congestion Status (mandatory) 1216 Discard Status (optional) 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Tag (0x304) | Length = 8 | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Congestion Status | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Tag (0x305) | Length = 8 | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Discard Status | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 The valid values for Congestion Status and Discard Status are shown in 1230 the following table. 1232 Define Value Description 1233 LEVEL_NONE 0x0 No congestion 1234 LEVEL_1 0x1 Congestion Level 1 1235 LEVEL_2 0x2 Congestion Level 2 1236 LEVEL_3 0x3 Congestion Level 3 1238 For SS7 networks that do not support multiple levels of congestion, only 1239 the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that 1240 support multiple levels of congestion, it is possible for all values to 1241 be used. Refer to [2], [3] and [9] for more details on the Congestion 1242 and Discard Status of SS7 signalling links. 1244 3.3.1.9 Retrieval Request 1246 The MTP2 Retrieval Request message is used during the MTP Level 3 1247 changeover procedure to request the BSN, to retrieve PDUs from the 1248 transmit and retransmit queues or to flush PDUs from the retransmit 1249 queue. Examples of the use of Retrieval Request for SS7 Link 1250 Changeover are provided in Section 5.3.6. 1252 The Retrieval Request message contains the following parameters: 1254 Action (mandatory) 1255 Sequence Number (optional) 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Tag (0x306) | Length = 8 | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Action | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Tag (0x307) | Length = 8 | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Sequence Number | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 The valid values for Action are shown in the following table. 1271 Define Value Description 1272 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1273 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit 1274 and retransmit queues 1276 In the Retrieval Request message, the Sequence Number field SHOULD NOT 1277 be present if the Action field is ACTION_RTRV_BSN. The Sequence Number 1278 field contains the Forward Sequence Number (FSN) of the far end if the 1279 Action is ACTION_RTRV_MSGS. 1281 3.3.1.10 Retrieval Confirm 1283 The MTP2 Retrieval Confirm message is sent by the Signalling Gateway 1284 in response to a Retrieval Request message. Examples of the use of 1285 Retrieval Confirm for SS7 Link Changeover are provided in Section 1286 5.3.6. 1288 The Retrieval Confirm message contains the following parameters: 1290 Action (mandatory) 1291 Result (mandatory) 1292 Sequence Number (optional) 1294 0 1 2 3 1295 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 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Tag (0x306) | Length = 8 | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Action | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Tag (0x308) | Length = 8 | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Result | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Tag (0x307) | Length = 8 | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Sequence Number | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 The valid values for Action are the same as in Retrieval Request. 1312 The values for Result are shown below: in the following table. 1314 Define Value Description 1315 RESULT_SUCCESS 0x0 Action successful 1316 RESULT_FAILURE 0x1 Action failed 1318 When the Signalling Gateway Process sends a Retrieval Confirm to a 1319 Retrieval Request, it echos the Action field. If the Action was 1320 ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP 1321 will put the Backward Sequence Number (BSN) in the Sequence Number 1322 field and will indicate a success in the Result field. If the BSN 1323 could not be retrieved, the Sequence Number field will not be included 1324 and the Result field will indicate failure. 1326 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of 1327 the Result field will indicate success or failure. A failure means 1328 that the buffers could not be retrieved. The Sequence Number field is 1329 not used with ACTION_RTRV_MSGS. 1331 3.3.1.11 Retrieval Indication 1333 The Retrieval Indication message is sent by the Signalling Gateway with 1334 a PDU from the transmit or retransmit queue. The Retrieval Indication 1335 message does not contain the Action or seq_num fields, just a MTP3 1336 Protocol Data Unit (PDU) from the transmit or retransmit queue. 1337 Examples of the use of Retrieval Indication for SS7 Link Changeover are 1338 provided in Section 5.3.6. 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Tag (0x300) | Length | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 / \ 1346 \ Protocol Data / 1347 / \ 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 For TTC Data messages, the following parameter will be used to indicate 1351 a TTC PDU which starts at LI. 1353 0 1 2 3 1354 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 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Tag (0x301) | Length | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 / \ 1359 \ TTC Protocol Data / 1360 / \ 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 The M2UA implementation MAY consider the use of the bundling feature 1364 of SCTP for Retrieval Indication messages. 1366 3.3.1.12 Retrieval Complete Indication 1368 The MTP2 Retrieval Complete Indication message is exactly the same as 1369 the MTP2 Retrieval Indication message except that it also indicates 1370 that retrieval is complete. In addition, it MAY contain a PDU (which 1371 must be the last PDU) from the transmit or retransmit queue. 1373 3.3.2 Application Server Process Maintenance (ASPM) Messages 1375 The ASPM messages will only use the common message header. 1377 3.3.2.1 ASP Up (ASPUP) 1379 The ASP Up (ASPUP) message is used to indicate to a remote M2UA peer 1380 that the Adaptation layer is ready to receive traffic or maintenance 1381 messages. 1383 The ASPUP message contains the following parameters 1385 ASP Identifier (optional) 1386 Info String (optional) 1388 Note: The ASP Identifier MUST be used where the SGP cannot 1389 identify the ASP by pre-configured address/port number 1390 information (e.g., where an ASP is resident on a Host using 1391 dynamic address/port number assignment). 1393 The format for ASPUP Message parameters is as follows: 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Tag (0xe) | Length | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | ASP Identifier* | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Tag (0x4) | Length | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 / \ 1405 \ INFO String* / 1406 / \ 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 The optional ASP Identifier parameter would contain a unique value 1410 that is locally significant among the ASPs that support an AS. The 1411 SGP should save the ASP Identifier to be used, if necessary, with the 1412 Notify message (see Section 3.3.3.2). 1414 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1415 character string along with the message. Length of the INFO String 1416 parameter is from 0 to 255 characters. No procedures are presently 1417 identified for its use but the INFO String MAY be used for debugging 1418 purposes. 1420 3.3.2.2 ASP Up Ack 1422 The ASP Up Ack message is used to acknowledge an ASP Up message 1423 received from a remote M2UA peer. 1425 The ASPUP Ack message contains the following parameters: 1427 ASP Identifier (optional) 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 (0xe) | Length | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | ASP Identifier* | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Tag (0x4) | Length | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 / \ 1442 \ INFO String* / 1443 / \ 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 If the ASPUP message contains an ASP Identifer, the ASPUP Ack will 1447 reflect the ASP Identifier back to the ASP. 1449 The format and description of the optional Info String parameter is the 1450 same as for the ASP UP message (See Section 3.3.2.1). 1452 3.3.2.3 ASP Down (ASPDN) 1454 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1455 that the adaptation layer is not ready to receive traffic or 1456 maintenance messages. 1458 The ASPDN message contains the following parameters 1460 INFO String (optional) 1462 The format for the ASPDN message parameters is as follows: 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Tag (0x4) | Length | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 / \ 1470 \ INFO String* / 1471 / \ 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 The format and description of the optional Info String parameter is the 1475 same as for the ASP Up message (See Section 3.3.2.1). 1477 3.3.2.4 ASP Down Ack 1479 The ASP Down Ack message is used to acknowledge an ASP Down message 1480 received from a remote M2UA peer. 1482 The ASP Down Ack message contains the following parameters: 1484 INFO String (optional) 1486 The format for the ASPDN Ack message parameters is as follows: 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Tag (0x4) | Length | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 / \ 1494 \ INFO String* / 1495 / \ 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 The format and description of the optional Info String parameter is the 1499 same as for the ASP UP message (See Section 3.3.2.1). 1501 3.3.2.5 Heartbeat (BEAT) 1503 The Heartbeat message is optionally used to ensure that the M2UA 1504 peers are still available to each other. 1506 The BEAT message contains the following parameter: 1508 Heartbeat Data Optional 1510 The format for the BEAT message is as follows: 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Tag = 0x0009 | Length | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 / Heartbeat Data / 1518 \ \ 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 The sending node defines the Heartbeat Data field contents. It may 1522 include a Heartbeat Sequence Number and/or Timestamp, or other 1523 implementation specific details. 1525 The receiver of a Heartbeat message does not process this field as 1526 it is only of significance to the sender. The receiver echoes the 1527 content of the Heartbeat Data in a BEAT ACK message. 1529 3.3.2.6 Heartbeat Ack (BEAT ACK) 1531 The Heartbeat ACK message is sent in response to a BEAT message. A 1532 peer MUST send a BEAT ACK in response to a BEAT message. It includes 1533 all the parameters of the received Heartbeat message, without any 1534 change. 1536 The BEAT ACK message contains the following parameter: 1538 Heartbeat Data Optional 1540 The format for the BEAT ACK message is as follows: 1542 0 1 2 3 1543 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 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Tag = 0x0009 | Length | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 / Heartbeat Data / 1548 \ \ 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 The sending node defines the Heartbeat Data field contents. It may 1552 include a Heartbeat Sequence Number and/or Timestamp, or other 1553 implementation specific details. 1555 The receiver of a Heartbeat message does not process this field as 1556 it is only of significance to the sender. The receiver echoes the 1557 content of the Heartbeat Data in a BEAT ACK message. 1559 3.3.2.7 ASP Active (ASPAC) 1561 The ASPAC message is sent by an ASP to indicate to an SGP that it is 1562 Active and ready to be used. 1564 The ASPAC message contains the following parameters: 1566 Traffic Mode Type (optional) 1567 Interface Identifier (optional) 1568 - Combination of integer and integer ranges, OR 1569 - string (text formatted) 1570 INFO String (optional) 1572 The format for the ASPAC message using integer formatted Interface 1573 Identifiers is as follows: 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Tag (0xb) | Length | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Traffic Mode Type | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Tag (0x1=integer) | Length | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 / \ 1585 \ Interface Identifiers* / 1586 / \ 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Tag (0x8=integer range) | Length | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Interface Identifier Start1* | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Interface Identifier Stop1* | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Interface Identifier Start2* | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Interface Identifier Stop2* | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 . . 1599 . . 1600 . . 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Interface Identifier StartN* | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Interface Identifier StopN* | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 / \ 1607 \ Additional Interface Identifiers / 1608 / of Tag Type 0x1 or 0x8 \ 1609 \ / 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Tag (0x4) | Length | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 / \ 1614 \ INFO String* / 1615 / \ 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 The format for the ASPAC message using text formatted (string) 1619 Interface Identifiers is as follows: 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Tag (0xb) | Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Traffic Mode Type | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Tag (0x3=string) | Length | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 / \ 1631 \ Interface Identifier* / 1632 / \ 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 / \ 1635 \ Additional Interface Identifiers / 1636 / of Tag Type 0x3 \ 1637 \ / 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Tag (0x4) | Length | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 / \ 1642 \ INFO String* / 1643 / \ 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 The Traffic Mode Type parameter identifies the traffic mode of 1647 operation of the ASP within an AS. The valid values for Type are 1648 shown in the following table: 1650 Value Description 1651 0x1 Override 1652 0x2 Load-share 1653 0x3 Broadcast 1655 Within a particular AS, only one Traffic Mode Type can be used. 1656 The Override value indicates that the ASP is operating in Override 1657 mode, where the ASP takes over all traffic in an Application Server 1658 (i.e., primary/backup operation), over-riding any currently active 1659 ASPs in the AS. In Load-share mode, the ASP will share in the traffic 1660 distribution with any other currently active ASPs. In Broadcast mode, 1661 all of the Active ASPs receive all message traffic in the Application 1662 Server. 1664 The optional Interface Identifiers parameter contains a list of 1665 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1666 (Type 0x3)indexing the Application Server traffic that the sending 1667 ASP is configured/registered to receive. If integer formatted 1668 Interface Identifiers are being used, the ASP can also send ranges of 1669 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1670 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1671 formatted Interface Identifiers (0x3) cannot be used with either 1672 Integer (0x1) or Integer Range (0x8) types. 1674 If no Interface Identifiers are included, the message is for all 1675 provisioned Interface Identifiers within the AS(s) in which the 1676 ASP is provisioned. If only a subset of Interface Identifiers for an 1677 AS are included, the ASP is noted as Active for all the Interface 1678 Identifiers provisioned for that AS. 1680 Note: If the optional Interface Identifier parameter is present, the 1681 integer formatted Interface Identifier MUST be supported, while the 1682 text formatted Interface Identifier MAY be supported. 1684 An SGP that receives an ASPAC with an incorrect or unsupported Traffic 1685 Mode Type for a particular Interface Identifier will respond with an 1686 Error Message (Cause: Unsupported Traffic Handling Mode). 1688 The format and description of the optional Info String parameter is the 1689 same as for the ASP UP message (See Section 3.3.2.1). 1691 3.3.2.8 ASP Active Ack 1693 The ASP Active (ASPAC) Ack message is used to acknowledge an ASP Active 1694 message received from a remote M2UA peer. 1696 The ASPAC Ack message contains the following parameters: 1698 Traffic Mode Type (mandatory) 1699 Interface Identifier (optional) 1700 - Combination of integer and integer ranges, OR 1701 - string (text formatted) 1702 INFO String (optional) 1704 The format for the ASPAC Ack message with Integer-formatted Interface 1705 Identifiers is as follows: 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Tag (0xb) | Length | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Traffic Mode Type | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Tag (0x1=integer) | Length | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 / \ 1717 \ Interface Identifiers* / 1718 / \ 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Tag (0x8=integer range) | Length | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Interface Identifier Start1* | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Interface Identifier Stop1* | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Interface Identifier Start2* | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Interface Identifier Stop2* | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 . . 1731 . . 1732 . . 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Interface Identifier StartN* | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Interface Identifier StopN* | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 / \ 1739 \ Additional Interface Identifiers / 1740 / of Tag Type 0x1 or 0x8 \ 1741 \ / 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Tag (0x4) | Length | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 / \ 1746 \ INFO String* / 1747 / \ 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 The format for the ASP Active Ack message using text formatted (string) 1751 Interface Identifiers is as follows: 1753 0 1 2 3 1754 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 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Tag (0xb) | Length | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Traffic Mode Type | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Tag (0x3=string) | Length | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 / \ 1763 \ Interface Identifier* / 1764 / \ 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 / \ 1767 \ Additional Interface Identifiers / 1768 / of Tag Type 0x3 \ 1769 \ / 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Tag (0x4) | Length | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 / \ 1774 \ INFO String* / 1775 / \ 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 The format and description of the optional Info String parameter is the 1779 same as for the ASP Up message (See Section 3.3.2.1). 1781 The format of the Type and Interface Identifier parameters is the same 1782 as for the ASP Active message (See Section 3.3.2.5). 1784 3.3.2.9 ASP Inactive (ASPIA) 1786 The ASP Inactive (ASPIA) message is sent by an ASP to indicate to an 1787 SGP that it is no longer an active ASP to be used from within a list 1788 of ASPs. The SGP will respond with an ASPIA Ack message and either 1789 discard incoming messages or buffer for a timed period and then 1790 discard. 1792 The ASPIA message contains the following parameters: 1794 Interface Identifiers (optional) 1795 - Combination of integer and integer ranges, OR 1796 - string (text formatted) 1797 INFO String (optional) 1799 The format for the ASP Inactive message parameters using Integer 1800 formatted Interface Identifiers is as follows: 1802 0 1 2 3 1803 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 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Tag (0x1=integer) | Length | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 / \ 1808 \ Interface Identifiers* / 1809 / \ 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Tag (0x8=integer range) | Length | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Interface Identifier Start1* | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Interface Identifier Stop1* | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Interface Identifier Start2* | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Interface Identifier Stop2* | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 . . 1822 . . 1823 . . 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Interface Identifier StartN* | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Interface Identifier StopN* | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 / \ 1830 \ Additional Interface Identifiers / 1831 / of Tag Type 0x1 or 0x8 \ 1832 \ / 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Tag (0x4) | Length | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 / \ 1837 \ INFO String* / 1838 / \ 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 The format for the ASP Inactive message using text formatted (string) 1842 Interface Identifiers is as follows: 1844 0 1 2 3 1845 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 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | Tag (0x3=string) | Length | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 / \ 1850 \ Interface Identifier* / 1851 / \ 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 / \ 1854 \ Additional Interface Identifiers / 1855 / of Tag Type 0x3 \ 1856 \ / 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Tag (0x4) | Length | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 / \ 1861 \ INFO String* / 1862 / \ 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 The format and description of the optional Interface Identifiers and 1866 Info String parameters is the same as for the ASP Active message (See 1867 Section 3.3.2.3). 1869 The optional Interface Identifiers parameter contains a list of 1870 Interface Identifier integers indexing the Application Server traffic 1871 that the sending ASP is configured/registered to receive, but does not 1872 want to receive at this time. 1874 3.3.2.10 ASP Inactive Ack 1876 The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP 1877 Inactive message received from a remote M2UA peer. 1879 The ASPIA Ack message contains the following parameters: 1881 Interface Identifiers (optional) 1882 - Combination of integer and integer ranges, OR 1883 - string (text formatted) 1884 INFO String (optional) 1886 The format for the ASPIA Ack message is as follows: 1888 0 1 2 3 1889 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 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Tag (0x1=integer) | Length | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 / \ 1894 \ Interface Identifiers* / 1895 / \ 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Tag (0x8=integer range) | Length | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Interface Identifier Start1* | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Interface Identifier Stop1* | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Interface Identifier Start2* | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Interface Identifier Stop2* | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 . . 1908 . . 1909 . . 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Interface Identifier StartN* | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Interface Identifier StopN* | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 / \ 1916 \ Additional Interface Identifiers / 1917 / of Tag Type 0x1 or 0x8 \ 1918 \ / 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Tag (0x4) | Length | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 / \ 1923 \ INFO String* / 1924 / \ 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 The format for the ASP Inactive Ack message using text formatted 1928 (string) Interface Identifiers is as follows: 1930 0 1 2 3 1931 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 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | Tag (0x3=string) | Length | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 / \ 1936 \ Interface Identifier* / 1937 / \ 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 / \ 1940 \ Additional Interface Identifiers / 1941 / of Tag Type 0x3 \ 1942 \ / 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Tag (0x4) | Length | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 / \ 1947 \ INFO String* / 1948 / \ 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 The format of the Interface Identifier parameter is the same as for 1952 the ASP Inactive message (See Section 3.3.2.7). 1954 The format and description of the optional Info String parameter is 1955 the same as for the ASP Up message (See Section 3.3.2.1). 1957 3.3.3 Layer Management (MGMT) Messages 1959 3.3.3.1 Error (ERR) 1961 The Error (ERR) message is used to notify a peer of an error event 1962 associated with an incoming message. For example, the message type 1963 might be unexpected given the current state, or a parameter value might 1964 be invalid. 1966 The ERR message contains the following parameters: 1968 Error Code (mandatory) 1969 Interface Identifier (optional) 1970 Diagnostic Information (optional) 1972 The format for the ERR message is as follows: 1974 0 1 2 3 1975 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 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Tag (0xc) | Length | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Error Code | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Tag (0x1, 0x3, or 0x8) | Length | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 / \ 1984 \ Interface Identifier(s)* / 1985 / \ 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Tag (0x7) | Length | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 / \ 1990 \ Diagnostic Information* / 1991 / \ 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 The Error Code parameter indicates the reason for the Error Message. 1995 The Error parameter value can be one of the following values: 1997 Invalid Version 0x1 1998 Invalid Interface Identifier 0x2 1999 Unsupported Message Class 0x3 2000 Unsupported Message Type 0x4 2001 Unsupported Traffic Handling Mode 0x5 2002 Unexpected Message 0x6 2003 Protocol Error 0x7 2004 Unsupported Interface Identifier Type 0x8 2005 Invalid Stream Identifier 0x9 2006 Not Used in M2UA 0xa 2007 Not Used in M2UA 0xb 2008 Not Used in M2UA 0xc 2009 Refused - Management Blocking 0xd 2010 ASP Identifier Required 0xe 2011 Invalid ASP Identifier 0xf 2012 ASP Active for Interface Identifier(s) 0x10 2013 Invalid Parameter Value 0x11 2014 Parameter Field Error 0x12 2015 Unexpected Parameter 0x13 2017 The "Invalid Version" error would be sent if a message was 2018 received with an invalid or unsupported version. The Error message 2019 would contain the supported version in the Common header. The 2020 Error message could optionally provide the supported version in 2021 the Diagnostic Information area. 2023 The "Invalid Interface Identifier" error would be sent by a SGP if 2024 an ASP sends a message (i.e. an ASP Active message) with an invalid 2025 (unconfigured) Interface Identifier value. One of the optional 2026 Interface Identifier parameters (Integer-based, text-based or integer 2027 range) MUST be used with this error code to identify the invalid 2028 Interface Identifier(s) received. 2030 The "Unsupported Traffic Handling Mode" error would be sent by a SGP 2031 if an ASP sends an ASP Active with an unsupported Traffic Handling 2032 Mode. An example would be a case in which the SGP did not support 2033 load-sharing. One of the optional Interface Identifier parameters 2034 (Integer-based, text-based or integer range) MAY be used with this 2035 error code to identify the Interface Identifier(s). 2037 The "Unexpected Message" error would be sent by an ASP if it received 2038 a MAUP message from an SGP while it was in the Inactive state. 2040 The "Protocol Error" error would be sent for any protocol anomaly 2041 (i.e. a bogus message). 2043 The "Invalid Stream Identifier" error would be sent if a message 2044 was received on an unexpected SCTP stream (i.e. a MGMT message 2045 was received on a stream other than "0"). 2047 The "Unsupported Interface Identifier Type" error would be sent by 2048 a SGP if an ASP sends a Text formatted Interface Identifier and the 2049 SGP only supports Integer formatted Interface Identifiers. When 2050 the ASP receives this error, it will need to resend its message with 2051 an Integer formatted Interface Identifier. 2053 The "Unsupported Message Class" error would be sent if a message with 2054 an unexpected or unsupported Message Class is received. 2056 The "Refused - Management Blocking" error is sent when an ASP Up or 2057 ASP Active message is received and the request is refused for 2058 management reasons (e.g., management lock-out"). 2060 The "ASP Identifier Required" is sent by a SGP in response 2061 to an ASPUP message which does not contain an ASP Identifier 2062 parameter when the SGP requires one. The ASP should resend the 2063 ASPUP message with a ASP Identifier. 2065 The "Invalid ASP Identifier" is send by a SGP in response to an 2066 ASPUP message with an invalid (i.e. non-unique) ASP Identifier. 2068 The "ASP Currently Active for Interface Identifier(s)" error is 2069 sent by a SGP when a Deregistration request is received from an ASP 2070 that is active for Interface Identifier(s) specified in the 2071 Deregistration request. One of the optional Interface Identifier 2072 parameters (Integer-based, text-based or integer range) MAY be used 2073 with this error code to identify the Interface Identifier(s). 2075 The "Invalid Parameter Value " error is sent if a message is received 2076 with an invalid parameter value (e.g., a State Request with an 2077 an undefined State). 2079 The "Parameter Field Error" would be sent if a message with a 2080 parameter that has a wrong length field. 2082 The "Unexpected Parameter" error would be sent if a message contains 2083 an invalid parameter. 2085 The optional Diagnostic information can be any information germane to 2086 the error condition, to assist in identification of the error condition. 2087 In the case of an Invalid Version Error Code the Diagnostic information 2088 includes the supported Version parameter. In the other cases, the 2089 Diagnostic information SHOULD be the first 40 bytes of the offending 2090 message. 2092 3.3.3.2 Notify (NTFY) 2094 The Notify message is used to provide an autonomous indication of M2UA 2095 events to an M2UA peer. 2097 The NTFY message contains the following parameters: 2099 Status Type (mandatory) 2100 Status Information (mandatory) 2101 ASP Identifier (optional) 2102 Interface Identifiers (optional) 2103 INFO String (optional) 2105 The format for the Notify message with Integer-formatted Interface 2106 Identifiers is as follows: 2108 0 1 2 3 2109 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 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Tag (0xd) | Length | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Status Type | Status Information | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | Tag (0xe) | Length | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | ASP Identifier* | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Tag (0x1=integer) | Length | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 / \ 2122 \ Interface Identifiers* / 2123 / \ 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | Tag (0x8=integer range) | Length | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Interface Identifier Start1* | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Interface Identifier Stop1* | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | Interface Identifier Start2* | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | Interface Identifier Stop2* | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 . . 2136 . . 2137 . . 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Interface Identifier StartN* | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Interface Identifier StopN* | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 / \ 2144 \ Additional Interface Identifiers / 2145 / of Tag Type 0x1 or 0x8 \ 2146 \ / 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Tag (0x4) | Length | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 / \ 2151 \ INFO String* / 2152 / \ 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 The format for the Notify message with Text-formatted Interface 2156 Identifiers is as follows: 2158 0 1 2 3 2159 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 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 | Tag (0xd) | Length | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | Status Type | Status Information | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Tag (0xe) | Length | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | ASP Identifier* | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Tag (0x3=string) | Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 / \ 2172 \ Interface Identifier* / 2173 / \ 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 / \ 2176 \ Additional Interface Identifiers / 2177 / of Tag Type 0x3 \ 2178 \ / 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | Tag (0x4) | Length | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 / \ 2183 \ INFO String* / 2184 / \ 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 The Status Type parameter identifies the type of the Notify message. 2188 The following are the valid Status Type values: 2190 Value Description 2191 0x1 Application Server state change (AS_State_Change) 2192 0x2 Other 2194 The Status Information parameter contains more detailed information 2195 for the notification, based on the value of the Status Type. If the 2196 Status Type is AS_State_Change the following Status Information values 2197 are used: 2199 Value Description 2200 1 Application Server Down (AS_Down) 2201 2 Application Server Inactive (AS_Inactive) 2202 3 Application Server Active (AS_Active) 2203 4 Application Server Pending (AS_Pending) 2205 These notifications are sent from an SGP to an ASP upon a change in 2206 status of a particular Application Server. The value reflects the 2207 new state of the Application Server. The Interface Identifiers of 2208 the AS MAY be placed in the message if desired. 2210 If the Status Type is Other, then the following Status Information 2211 values are defined: 2213 Value Description 2214 1 Insufficient ASP resources active in AS 2215 2 Alternate ASP Active 2216 3 ASP Failure 2218 In the Insufficient ASP Resources case, the SGP is indicating to an 2219 ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to 2220 handle the load of the AS (Load-sharing mode). For the Alternate ASP 2221 Active case, the formerly Active ASP is informed when an alternate 2222 ASP transitions to the ASP Active state in Override mode. The ASP 2223 Identifier (if available) of the Alternate ASP MUST be placed in the 2224 message. For the ASP Failure case, the SGP is indicating to ASP(s) 2225 in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP 2226 Identifier (if available) of the failed ASP MUST be placed in the 2227 message. 2229 For each of the Status Information values in Status Type Other, the 2230 Interface Identifiers of the affected AS MAY be placed in the message 2231 if desired. 2233 The format and description of the optional Interface Identifiers and 2234 Info String parameters is the same as for the ASP Active message 2235 (See Section 3.3.2.3). 2237 3.3.4 Interface Identifier Management (IIM) Messages 2239 The Interface Identifier Management messages are optional. They are 2240 used to support automatic allocation of Signalling Terminals or 2241 Signalling Data Links [2][3]. 2243 3.3.4.1 Registration Request (REG REQ) 2245 The REG REQ message is sent by an ASP to indicate to a remote M2UA 2246 peer that it wishes to register one or more given Link Keys with the 2247 remote peer. Typically, an ASP would send this message to an SGP, 2248 and expect to receive a REG RSP in return with an associated 2249 Interface Identifier value. 2251 The REG REQ message contains the following parameter: 2253 Link Key (mandatory) 2255 The format for the REG REQ message is as follows 2256 0 1 2 3 2257 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 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | Tag = 0x0309 | Length | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 \ \ 2262 / Link Key 1 / 2263 \ \ 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 \ \ 2266 / ... / 2267 \ \ 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Tag = 0x0309 | Length | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 \ \ 2272 / Link Key n / 2273 \ \ 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Link Key: fixed length 2278 The Link Key parameter is mandatory. The sender of this message 2279 expects the receiver of this message will create a Link Key entry 2280 and assign a unique Interface Identifier value to it, if the Link 2281 Key entry does not yet exist. 2283 The Link Key parameter may be present multiple times in the same 2284 message. This is used to allow the registration of multiple Link 2285 Keys in a single message. 2287 The format of the Link Key parameter is as follows: 2289 0 1 2 3 2290 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 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | Local-LK-Identifier | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | Signalling Data Terminal Identifier | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | Signalling Data Link Identifier | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 Local-LK-Identifier: 32-bit integer 2301 The mandatory Local-LK-Identifier field is used to uniquely 2302 (between ASP and SGP) identify the registration request. The 2303 Identifier value is assigned by the ASP, and is used to correlate 2304 the response in a REG RSP message with the original registration 2305 request. The Identifier value must remain unique until the REG 2306 RSP is received. 2308 The format of the Local-LK-Identifier field is as follows: 2310 0 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Tag = 0x030a | Length = 8 | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | Local-LK-Identifier value | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 Signalling Data Terminal Identifier 2320 The Signalling Data Terminal Identifier parameter is mandatory. 2321 It identifies the Signalling Data Terminal associated with the 2322 SS7 link for which the ASP is registering. The format is as 2323 follows: 2325 0 1 2 3 2326 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 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Tag = 0x030b | Length = 8 | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Reserved | SDT Identifier | 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 The SDT Identifier is a 32-bit unsigned value which may only be 2334 significant to 12 or 14 bits depending on the SS7 variant which 2335 is supported by the MTP Level 3 at the ASP. Insignificant SDTI 2336 bits are coded 0. 2338 Signalling Data Link Identifier 2340 The Signalling Data Link Identifier parameter is mandatory. It 2341 identifies the Signalling Data Link Identifier associated with 2342 the SS7 link for which the ASP is registering. The format is as 2343 follows: 2345 0 1 2 3 2346 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 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Tag = 0x030c | Length = 8 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Reserved | SDL Identifier | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 The SDL Identifier is a 32-bit unsigned value which may only be 2354 significant to 12 or 14 bits depending on the SS7 variant which 2355 is supported by the MTP Level 3 at the ASP. Insignificant SDLI 2356 bits are coded 0. 2358 3.3.4.2 Registration Response (REG RSP) 2360 The REG RSP message is used as a response to the REG REQ message 2361 from a remote M2UA peer. It contains indications of success/failure 2362 for registration requests and returns a unique Interface Identifier 2363 value for successful registration requests, to be used in subsequent 2364 M2UA Traffic Management protocol. 2366 The REG RSP message contains the following parameter: 2368 Registration Results (mandatory) 2370 The format for the REG RSP message is as follows: 2372 0 1 2 3 2373 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 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Tag = 0x030d | Length | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 \ \ 2378 / Registration Result 1 / 2379 \ \ 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 \ \ 2382 / ... / 2383 \ \ 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Tag = 0x030d | Length | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 \ \ 2388 / Registration Result n / 2389 \ \ 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 Registration Results: fixed length 2394 The Registration Results parameter contains one or more results, 2395 each containing the registration status for a single Link Key in 2396 the REG REQ message. The number of results in a single REG RSP 2397 message MAY match the number of Link Key parameters found in the 2398 corresponding REG REQ message. The format of each result is as 2399 follows: 2401 0 1 2 3 2402 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 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | Local-LK-Identifier | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 | Registration Status | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | Interface Identifier | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 Local-LK-Identifier: 32-bit integer 2413 The Local-LK-Identifier contains the same value as found in the 2414 matching Link Key parameter found in the REG REQ message. The 2415 format of the Local-LK-Identifier is shown in Section 3.3.4.1. 2417 Registration Status: 32-bit integer 2419 The Registration Result Status field indicates the success or the 2420 reason for failure of a registration request. 2422 Its values may be one of the following: 2424 0 Successfully Registered 2425 1 Error - Unknown 2426 2 Error - Invalid SDLI 2427 3 Error - Invalid SDTI 2428 4 Error - Invalid Link Key 2429 5 Error - Permission Denied 2430 6 Error - Overlapping (Non-unique) Link Key 2431 7 Error - Link Key not Provisioned 2432 8 Error - Insufficient Resources 2434 The format of the Registration Status field is as follows: 2436 0 1 2 3 2437 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 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | Tag = 0x030e | Length = 8 | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | Registration Status | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 Interface Identifier: 32-bit integer 2446 The Interface Identifier field contains the Interface Identifier 2447 for the associated Link Key if the registration is successful. 2448 It is set to "0" if the registration was not successful. The 2449 format of integer-based and text-based Interface Identifier 2450 parameters are shown in Section 3.2. 2452 3.3.4.3 De-Registration Request (DEREG REQ) 2454 The DEREG REQ message is sent by an ASP to indicate to a remote M2UA 2455 peer that it wishes to de-register a given Interface Identifier. 2456 Typically, an ASP would send this message to an SGP, and expects to 2457 receive a DEREG RSP in return reflecting the Interface Identifier 2458 and containing a de-registration status. 2460 The DEREG REQ message contains the following parameter: 2462 Interface Identifier (mandatory) 2464 The format for the DEREG REQ message is as follows: 2466 0 1 2 3 2467 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 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | Tag = 0x1 or 0x3 | Length | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 \ \ 2472 / Interface Identifier 1 / 2473 \ \ 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 \ \ 2476 / ... / 2477 \ \ 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | Tag = 0x1 or 0x3 | Length | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 \ \ 2482 / Interface Identifier n / 2483 \ \ 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 Interface Identifier 2488 The Interface Identifier parameter contains a Interface Identifier 2489 indexing the Application Server traffic that the sending ASP is 2490 currently registered to receive from the SGP but now wishes to 2491 de-register. The format of integer-based and text-based Interface 2492 Identifier parameters are shown in Section 3.2. 2494 3.3.4.4 De-Registration Response (DEREG RSP) 2496 The DEREG RSP message is used as a response to the DEREG REQ message 2497 from a remote M2UA peer. 2499 The DEREG RSP message contains the following parameter: 2501 De-Registration Results (mandatory) 2503 The format for the DEREG RSP message is as follows: 2505 0 1 2 3 2506 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 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | Tag = 0x030f | Length | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 \ \ 2511 / De-Registration Result 1 / 2512 \ \ 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 \ \ 2515 / ... / 2516 \ \ 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | Tag = 0x030f | Length | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 \ \ 2521 / De-Registration Result n / 2522 \ \ 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 De-Registration Results: fixed length 2527 The De-Registration Results parameter contains one or more results, 2528 each containing the de-registration status for a single Interface 2529 Identifier in the DEREG REQ message. The number of results in a 2530 single DEREG RSP message MAY match the number of Interface Identifier 2531 parameters found in the corresponding DEREG REQ message. The format 2532 of each result is as follows: 2534 0 1 2 3 2535 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 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | Interface Identifier | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | De-Registration Status | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 Interface Identifier: 32-bit integer 2544 The Interface Identifier field contains the Interface Identifier 2545 value of the matching Link Key to de-register, as found in the 2546 DEREG REQ. The format of integer-based and text-based Interface 2547 Identifier parameters are shown in Section 3.2. 2549 De-Registration Status: 32-bit integer 2551 The De-Registration Result Status field indicates the success or 2552 the reason for failure of the de-registration. 2554 Its values may be one of the following: 2556 0 Successfully De-registered 2557 1 Error - Unknown 2558 2 Error - Invalid Interface Identifier 2559 3 Error - Permission Denied 2560 4 Error - Not Registered 2562 The format of the De-Registration Status field is as follows: 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | Tag = 0x0310 | Length = 8 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | De-Registration Status | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 4.0 Procedures 2574 The M2UA layer needs to respond to various primitives it receives from 2575 other layers as well as messages it receives from the peer-to-peer 2576 messages. This section describes various procedures involved in 2577 response to these events. 2579 4.1 Procedures to Support the M2UA-User Layer 2581 These procedures achieve the M2UA layer "Transport of MTP Level 2 / 2582 MTP Level 3 boundary" service. 2584 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 2586 On receiving a primitive from the local upper layer, the M2UA layer 2587 will send the corresponding MAUP message (see Section 3) to its peer. 2588 The M2UA layer MUST fill in various fields of the common and specific 2589 headers correctly. In addition the message SHOULD be sent on the SCTP 2590 stream that corresponds to the SS7 link. 2592 4.1.2 MAUP Message Procedures 2594 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 2595 SG or MGC needs to invoke the corresponding layer primitives to the 2596 local MTP Level 2 or MTP Level 3 layer. 2598 4.2 Receipt of Primitives from the Layer Management 2600 On receiving primitives from the local Layer Management, the M2UA layer 2601 will take the requested action and provide an appropriate response 2602 primitive to Layer Management. 2604 An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP 2605 will initiate the establishment of an SCTP association. The M2UA 2606 layer will attempt to establish an SCTP association with the remote 2607 M2UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP 2608 layer. 2610 When an SCTP association has been successfully established, the SCTP 2611 will send an SCTP-COMMUNICATION_UP notification primitive to the local 2612 M2UA layer. At the SGP that initiated the request, the M2UA layer will 2613 send an M-SCTP_ESTABLISH confirm primitive to Layer Management when 2614 the association setup is complete. At the peer M2UA layer, an 2615 M-SCTP_ESTABLISH indication primitive is sent to Layer Management 2616 upon successful completion of an incoming SCTP association setup. 2618 An M-SCTP_RELEASE request primitive from Layer Management initates the 2619 shutdown of an SCTP association. The M2UA layer accomplishes a 2620 graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN 2621 primitive to the SCTP layer. 2623 When the graceful shutdown of the SCTP association has been 2624 accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE 2625 notification primitive to the local M2UA layer. At the M2UA Layer that 2626 initiated the request, the M2UA layer will send an M-SCTP_RELEASE 2627 confirm primitive to Layer Management when the association shutdown is 2628 complete. At the peer M2UA Layer, an M-SCTP_RELEASE indication 2629 primitive is sent to Layer Management upon abort or successful 2630 shutdown of an SCTP association. 2632 An M-SCTP_STATUS request primitive supports a Layer Management query 2633 of the local status of a particular SCTP association. The M2UA layer 2634 simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS 2635 primitive to the SCTP layer. When the SCTP responds, the M2UA layer 2636 maps the association status information to an M-SCTP_STATUS confirm 2637 primitive. No peer protocol is invoked. 2639 Similar LM-to-M2UA-to-SCTP and/or SCTP-to-M2UA-to-LM primitive mappings 2640 can be described for the various other SCTP Upper Layer primitives in 2641 RFC2960 [13] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, 2642 REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL 2643 PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS 2644 CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status 2645 as well) can be considered for modeling purposes as a Layer Management 2646 interaction directly with the SCTP Layer. 2648 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 2649 Management the notification or error information contained in a 2650 received M2UA Notify or Error message respectively. These indications 2651 can also be generated based on local M2UA events. 2653 An M-ASP_STATUS request primitive supports a Layer Management query of 2654 the status of a particular local or remote ASP. The M2UA layer 2655 responds with the status in an M-ASP_STATUS confirm primitive. No M2UA 2656 peer protocol is invoked. 2658 An M-AS_STATUS request supports a Layer Management query of the status 2659 of a particular AS. The M2UA responds with an M-AS_STATUS confirm 2660 primitive. No M2UA peer protocol is invoked. 2662 M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_ 2663 INACTIVE request primitives allow Layer Management at an ASP to 2664 initiate state changes. Upon successful completion, a corresponding 2665 confirm primitive is provided by the M2UA layer to Layer Management. 2666 If an invocation is unsuccessful, an Error indication primitive is 2667 provided in the primitive. These requests result in outgoing ASP Up, 2668 ASP Down, ASP Active and ASP Inactive messages to the remote M2UA peer 2669 at an SGP. 2671 4.2.1 Receipt of M2UA Peer Management Messages 2673 Upon successful state changes resulting from reception of ASP Up, 2674 ASP Down, ASP Active and ASP Inactive messages from a peer M2UA, the 2675 M2UA layer SHOULD invoke corresponding M-ASP_UP, M-ASP_DOWN, M- 2676 ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M- 2677 AS_DOWN indication primitives to the local Layer Management. 2679 M-NOTIFY indication and M-ERROR indication primitives indicate to Layer 2680 Management the notification or error information contained in a 2681 received M2UA Notify or Error message. These indications can also be 2682 generated based on local M2UA events. 2684 All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with 2685 sequenced delivery to ensure ordering. All MGMT messages, with the 2686 exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP 2687 stream '0'. All ASPTM messages SHOULD be sent on the stream which 2688 normally carries the data traffic to which the message applies. BEAT 2689 and BEAT Ack messages MAY be sent using out-of-order delivery, and 2690 MAY be sent on any stream. 2692 4.3 AS and ASP State Maintenance 2694 The M2UA layer on the SGP maintains the state of each remote ASP, in 2695 each Application Server that the ASP is configured to receive traffic, 2696 as input to the M2UA message distribution function. 2698 4.3.1 ASP States 2700 The state of each remote ASP, in each AS that it is configured to 2701 operate, is maintained in the M2UA layer in the SGP. The state of a 2702 particular ASP in a particular AS changes due to events. The events 2703 include: 2705 * Reception of messages from the peer M2UA layer at the ASP; 2706 * Reception of some messages from the peer M2UA layer at other ASPs 2707 in the AS (e.g., ASP Active message indicating "Override"); 2708 * Reception of indications from the SCTP layer; or 2709 * Local Management intervention. 2711 The ASP state transition diagram is shown in Figure 5. The possible 2712 states of an ASP are: 2714 ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the 2715 related SCTP association is down. Initially all ASPs will be in this 2716 state. An ASP in this state SHOULD NOT be sent any M2UA messages, with 2717 the exception of Heartbeat messages. 2719 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 2720 related SCTP association is up) but application traffic is stopped. 2721 In this state the ASP MAY be sent any non-MAUP M2UA messages. 2723 ASP-ACTIVE: The remote M2UA peer at the ASP is available and 2724 application traffic is active (for a particular Interface Identifier 2725 or set of Interface Identifiers). 2727 Figure 5: ASP State Transition Diagram 2729 +--------------+ 2730 | ASP-ACTIVE | 2731 +----------------------| | 2732 | Other +-------| | 2733 | ASP in AS | +--------------+ 2734 | Overrides | ^ | 2735 | | ASP | | ASP 2736 | | Active | | Inactive 2737 | | | v 2738 | | +--------------+ 2739 | | | | 2740 | +------>| ASP-INACTIVE | 2741 | +--------------+ 2742 | ^ | 2743 ASP Down/ | ASP | | ASP Down / 2744 SCTP CDI/ | Up | | SCTP CDI/ 2745 SCTP RI | | v SCTP RI 2746 | +--------------+ 2747 | | | 2748 +--------------------->| ASP-DOWN | 2749 | | 2750 +--------------+ 2752 SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication 2753 Down Indication to the Upper Layer Protocol (M2UA) on an SGP. The local 2754 SCTP layer will send this indication when it detects the loss of 2755 connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as 2756 either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 2757 notification from the SCTP layer. 2759 SCTP RI: The local SCTP layer's Restart indication to the upper layer 2760 protocol (M2UA) on an SG. The local SCTP will send this indication when 2761 it detects a restart from the ASP's peer SCTP layer. 2763 4.3.2 AS States 2765 The state of the AS is maintained in the M2UA layer on the SGP. The 2766 state of an AS changes due to events. These events include: 2768 * ASP state transitions 2769 * Recovery timer triggers 2771 The possible states of an AS are: 2773 AS-DOWN: The Application Server is unavailable. This state implies 2774 that all related ASPs are in the ASP-DOWN state for this AS. Initially 2775 the AS will be in this state. An Application Server MUST be in the AS- 2776 DOWN state before it can be removed from a configuration. 2778 AS-INACTIVE: The Application Server is available but no application 2779 traffic is active (i.e., one or more related ASPs are in the ASP- 2780 INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer 2781 T(r) is not running or has expired. 2783 AS-ACTIVE: The Application Server is available and application traffic 2784 is active. This state implies that at least one ASP is in the ASP- 2785 ACTIVE state. 2787 AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN 2788 and it was the last remaining active ASP in the AS. A recovery timer 2789 T(r) SHOULD be started and all incoming signalling messages SHOULD be 2790 queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, 2791 the AS is moved to the AS-ACTIVE state and all the queued messages will 2792 be sent to the ASP. 2794 If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing 2795 messages and discards all previously queued messages. The AS will move 2796 to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state, 2797 otherwise it will move to AS-DOWN state. 2799 Figure 6 shows an example AS state machine for the case where the 2800 AS/ASP data is pre-configured. For other cases where the AS/ASP 2801 configuration data is created dynamically, there would be differences 2802 in the state machine, especially at creation of the AS. 2804 For example, where the AS/ASP configuration data is not created until 2805 Registration of the first ASP, the AS-INACTIVE state is entered 2806 directly upon the first successful REG REQ from an ASP. Another 2807 example is where the AS/ASP configuration data is not created until the 2808 first ASP successfully enters the ASP-ACTIVE state. In this case the 2809 AS-ACTIVE state is entered directly. 2811 Figure 6: AS State Transition Diagram 2813 +----------+ one ASP trans to ACTIVE +-------------+ 2814 | AS- |---------------------------->| AS- | 2815 | INACTIVE | | ACTIVE | 2816 | |<--- | | 2817 +----------+ \ +-------------+ 2818 ^ | \ Tr Expiry, ^ | 2819 | | \ at least one | | 2820 | | \ ASP in ASP-INACTIVE | | 2821 | | \ | | 2822 | | \ | | 2823 | | \ | | 2824 one ASP | | all ASP \ one ASP | | Last ACTIVE 2825 trans | | trans to \ trans to | | ASP trans to 2826 to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE 2827 ASP- | | \ ACTIVE | | or ASP-DOWN 2828 INACTIVE| | \ | | (start Tr) 2829 | | \ | | 2830 | | \ | | 2831 | v \ | v 2832 +----------+ \ +-------------+ 2833 | | --| | 2834 | AS-DOWN | | AS-PENDING | 2835 | | | (queueing) | 2836 | |<----------------------------| | 2837 +----------+ Tr Expiry and no ASP +-------------+ 2838 in ASP-INACTIVE state 2840 Tr = Recovery Timer 2842 4.3.3 M2UA Management Procedures for Primitives 2844 Before the establishment of an SCTP association the ASP state at both 2845 the SGP and ASP is assumed to be in the state ASP-DOWN. 2847 Once the SCTP association is established (see Section 4.2.1) and 2848 assuming that the local M2UA-User is ready, the local M2UA ASP 2849 Maintenance (ASPM) function will initiate the relevant procedures, 2850 using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey 2851 the ASP state to the SGP (see Section 4.4.3). 2853 If the M2UA layer subsequently receives an SCTP-COMMUNICATION_DOWN 2854 or SCTP-RESTART indication primitive from the underlying SCTP layer, 2855 it will inform the Layer Management by invoking the M-SCTP_STATUS 2856 indication primitive. The state of the ASP will be moved to ASP-DOWN. 2858 In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re- 2859 establish the SCTP association. This MAY be done by the M2UA layer 2860 automatically, or Layer Management MAY re-establish using the 2861 M-SCTP_ESTABLISH request primitive. 2863 In the case of an SCTP-RESTART indication at an ASP, the ASP is now 2864 considered by its M2UA peer to be in the ASP-DOWN state. The ASP, if 2865 it is to recover, must begin any recovery with the ASP-Up procedure. 2867 4.3.4 ASPM Procedures for Peer-to-Peer Messages 2869 4.3.4.1 ASP Up Procedures 2871 After an ASP has successfully established an SCTP association to an 2872 SGP, the SGP waits for the ASP to send an ASP Up message, indicating 2873 that the ASP M2UA peer is available. The ASP is always the initiator 2874 of the ASP Up message. This action MAY be initiated at the ASP by an 2875 M-ASP_UP request primitive from Layer Management or MAY be initiated 2876 automatically by an M2UA management function. 2878 When an ASP Up message is received at an SGP and internally the remote 2879 ASP is in the ASP-DOWN state and not considered locked-out for local 2880 management reasons, the SGP marks the remote ASP in the state ASP- 2881 INACTIVE and informs Layer Management with an M-ASP_Up indication 2882 primitive. If the SGP is aware, via current configuration data, which 2883 Application Servers the ASP is configured to operate in, the SGP 2884 updates the ASP state to ASP-INACTIVE in each AS that it is a member. 2886 Alternatively, the SGP may move the ASP into a pool of Inactive ASPs 2887 available for future configuration within Application Server(s), 2888 determined in a subsequent Registration Request or ASP Active 2889 procedure. If the ASP Up message contains an ASP Identifier, the SGP 2890 should save the ASP Identifier for that ASP. The SGP MUST send an 2891 ASP Up Ack message in response to a received ASP Up message even if 2892 the ASP is already marked as ASP-INACTIVE at the SGP. 2894 If for any local reason (e.g., management lock-out) the SGP cannot 2895 respond with an ASP Up Ack message, the SGP responds to an ASP Up 2896 message with an Error message with Reason "Refused - Management 2897 Blocking". 2899 At the ASP, the ASP Up Ack message received is not acknowledged. Layer 2900 Management is informed with an M-ASP_UP confirm primitive. When an ASP 2901 enters the ASP-INACTIVE state from the ASP-DOWN state towards an SGP 2902 the M2UA MUST mark all SS7 destinations configured to be reachable via 2903 this SGP as available. 2905 When the ASP sends an ASP Up message it starts timer T(ack). If the 2906 ASP does not receive a response to an ASP Up message within T(ack), the 2907 ASP MAY restart T(ack) and resend ASP Up messages until it receives an 2908 ASP Up Ack message. T(ack) is provisionable, with a default of 2 2909 seconds. Alternatively, retransmission of ASP Up messages MAY be put 2910 under control of Layer Management. In this method, expiry of T(ack) 2911 results in an M-ASP_UP confirm primitive carrying a negative 2912 indication. 2914 The ASP MUST wait for the ASP Up Ack message before sending any other 2915 M2UA messages (e.g., ASP Active or REG REQ). If the SGP receives any 2916 other M2UA messages before an ASP Up message is received, the SGP 2917 SHOULD discard them. 2919 If an ASP Up message is received and internally the remote ASP is in 2920 the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as 2921 an Error message ("Unexpected Message), and the remote ASP state is 2922 changed to ASP-INACTIVE in all relevant Application Servers. 2924 If an ASP Up message is received and internally the remote ASP is 2925 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 2926 and no further action is taken. 2928 4.3.4.1.1 M2UA Version Control 2930 If an ASP Up message with an unsupported version is received, the 2931 receiving end responds with an Error message, indicating the version 2932 the receiving node supports and notifies Layer Management. 2934 This is useful when protocol version upgrades are being performed in a 2935 network. A node upgraded to a newer version should support the older 2936 versions used on other nodes it is communicating with. Because ASPs 2937 initiate the ASP Up procedure it is assumed that the Error message 2938 would normally come from the SGP. 2940 4.3.4.2 ASP Down Procedures 2942 The ASP will send an ASP Down message to an SGP when the ASP wishes to 2943 be removed from service in all Application Servers that it is a member 2944 and no longer receive any MAUP or ASPTM messages. This action MAY be 2945 initiated at the ASP by an M-ASP_DOWN request primitive from Layer 2946 Management or MAY be initiated automatically by an M2UA management 2947 function. 2949 Whether the ASP is permanently removed from any AS is a function of 2950 configuration management. In the case where the ASP previously used 2951 the Registration procedures (see Section 4.3.5) to register within 2952 Application Servers but has not deregistered from all of them prior to 2953 sending the ASP Down message, the SGP MUST consider the ASP as 2954 Deregistered in all Application Servers that it is still a member. 2956 The SGP marks the ASP as ASP-DOWN, informs Layer Management with an 2957 M-ASP_Down indication primitive, and returns an ASP Down Ack message 2958 to the ASP. 2960 The SGP MUST send an ASP Down Ack message in response to a received ASP 2961 Down message from the ASP even if the ASP is already marked as ASP-DOWN 2962 at the SGP. 2964 At the ASP, the ASP Down Ack message received is not acknowledged. 2965 Layer Management is informed with an M-ASP_DOWN confirm primitive. If 2966 the ASP receives an ASP Down Ack without having sent an ASP Down 2967 message, the ASP should now consider itself as in the ASP-DOWN state. 2968 If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the 2969 ASP should then initiate procedures to return itself to its previous 2970 state. 2972 When the ASP sends an ASP Down message it starts timer T(ack). If the 2973 ASP does not receive a response to an ASP Down message within T(ack), 2974 the ASP MAY restart T(ack) and resend ASP Down messages until it 2975 receives an ASP Down Ack message. T(ack) is provisionable, with a 2976 default of 2 seconds. Alternatively, retransmission of ASP Down 2977 messages MAY be put under control of Layer Management. In this method, 2978 expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a 2979 negative indication. 2981 4.3.4.4 ASP Active Procedures 2983 Anytime after the ASP has received an ASP Up Ack message from the SGP, 2984 the ASP MAY send an ASP Active message to the SGP indicating that 2985 the ASP is ready to start processing traffic. This action MAY be 2986 initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer 2987 Management or MAY be initiated automatically by a M2UA management 2988 function. In the case where an ASP wishes to process the traffic for 2989 more than one Application Server across a common SCTP association, the 2990 ASP Active message(s) SHOULD contain a list of one or more Interface 2991 Identifiers to indicate for which Application Servers the ASP Active 2992 message applies. It is not necessary for the ASP to include any 2993 Interface Identifiers of interest in a single ASP Active message, 2994 thus requesting to become active in all Interface Identifiers at the 2995 same time. Multiple ASP Active messages MAY be used to activate 2996 within the Application Servers independently, or in sets. In the 2997 case where an ASP Active message does not contain a Interface 2998 Identifier parameter, the receiver must know, via configuration data, 2999 which Application Server(s) the ASP is a member. 3001 For the Application Servers that the ASP can successfully activate, 3002 the SGP responds with one or more ASP Active Ack messages, including 3003 the associated Interface Identifier(s) and reflecting any Traffic Mode 3004 Type value present in the related ASP Active message. The Interface 3005 Identifier parameter MUST be included in the ASP Active Ack message(s) 3006 if the received ASP Active message contained any Interface Identifiers. 3007 Depending on any Traffic Mode Type request in the ASP Active message 3008 or local configuration data if there is no request, the SGP moves the 3009 ASP to the correct ASP traffic state within the associated Application 3010 Server(s). Layer Management is informed with an M-ASP_Active 3011 indication. If the SGP receives any Data messages before an ASP Active 3012 message is received, the SGP MAY discard them. By sending an ASP 3013 Active Ack message, the SGP is now ready to receive and send traffic 3014 for the related Interface Identifier(s). The ASP SHOULD NOT send MAUP 3015 messages for the related Interface Identifier(s) before receiving an 3016 ASP Active Ack message, or it will risk message loss. 3018 Multiple ASP Active Ack messages MAY be used in response to an ASP 3019 Active message containing multiple Interface Identifiers, allowing 3020 the SGP to independently acknowledge the ASP Active message for 3021 different (sets of) Interface Identifiers. The SGP MUST send 3022 an Error message ("Invalid Interface Identifier") for each Interface 3023 Identifier value that cannot be successfully activated. 3025 In the case where an "out-of-the-blue" ASP Active message is received 3026 (i.e., the ASP has not registered with the SG or the SG has no static 3027 configuration data for the ASP), the message MAY be silently discarded. 3029 The SGP MUST send an ASP Active Ack message in response to a received 3030 ASP Active message from the ASP, if the ASP is already marked in the 3031 ASP-ACTIVE state at the SGP. 3033 At the ASP, the ASP Active Ack message received is not acknowledged. 3034 Layer Management is informed with an M-ASP_ACTIVE confirm primitive. 3035 It is possible for the ASP to receive Data message(s) before the ASP 3036 Active Ack message as the ASP Active Ack and Data messages from an SG 3037 may be sent on different SCTP streams. Message loss is possible as 3038 the ASP does not consider itself in the ASP-ACTIVE state until 3039 reception of the ASP Active Ack message. 3041 When the ASP sends an ASP Active message it starts timer T(ack). If 3042 the ASP does not receive a response to an ASP Active message within 3043 T(ack), the ASP MAY restart T(ack) and resend ASP Active message(s) 3044 until it receives an ASP Active Ack message. T(ack) is provisionable, 3045 with a default of 2 seconds. Alternatively, retransmission of ASP 3046 Active messages MAY be put under control of Layer Management. In 3047 this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm 3048 primitive carrying a negative indication. 3050 There are three modes of Application Server traffic handling in the SGP 3051 M2UA layer: Override, Loadshare and Broadcast. When included, the 3052 Traffic Mode Type parameter in the ASP Active message indicates the 3053 traffic handling mode to be used in a particular Application Server. 3054 If the SGP determines that the mode indicated in an ASP Active message 3055 is unsupported or incompatible with the mode currently configured for 3056 the AS, the SGP responds with an Error message ("Unsupported / Invalid 3057 Traffic Handling Mode"). If the traffic handling mode of the 3058 Application Server is not already known via configuration data, then 3059 the traffic handling mode indicated in the first ASP Active message 3060 causing the transition of the Application Server state to AS-ACTIVE MAY 3061 be used to set the mode. 3063 In the case of an 0verride mode AS, reception of an ASP Active message 3064 at an SGP causes the (re)direction of all traffic for the AS to the ASP 3065 that sent the ASP Active message. Any previously active ASP in the AS 3066 is now considered to be in state ASP-INACTIVE and SHOULD no longer 3067 receive traffic from the SGP within the AS. The SGP then MUST send a 3068 Notify message ("Alternate ASP Active") to the previously active ASP 3069 in the AS, and SHOULD stop traffic to/from that ASP. The ASP receiving 3070 this Notify MUST consider itself now in the ASP-INACTIVE state, if it 3071 is not already aware of this via inter-ASP communication with the 3072 Overriding ASP. 3074 In the case of a Load-share mode AS, reception of an ASP Active 3075 message at an SGP causes the direction of traffic to the ASP sending 3076 the ASP Active message, in addition to all the other ASPs that are 3077 currently active in the AS. The algorithm at the SGP for load-sharing 3078 traffic within an AS to all the active ASPs is implementation 3079 dependent. The algorithm could, for example be round-robin or based 3080 on information in the Data message (e.g., such as the SLS in the 3081 Routing Label). 3083 An SGP, upon reception of an ASP Active message for the first ASP in 3084 a Loadshare AS, MAY choose not to direct traffic to a newly active ASP 3085 until it determines that there are sufficient resources to handle the 3086 expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in 3087 the AS). 3089 All ASPs within a load-sharing mode AS must be able to process any 3090 Data message received for the AS, to accommodate any potential 3091 fail-over or rebalancing of the offered load. 3093 In the case of a Broadcast mode AS, reception of an ASP Active message 3094 at an SGP causes the direction of traffic to the ASP sending the ASP 3095 Active message, in addition to all the other ASPs that are currently 3096 active in the AS. The algorithm at the SGP for broadcasting 3097 traffic within an AS to all the active ASPs is a simple broadcast 3098 algorithm, where every message is sent to each of the active ASPs. 3100 An SGP, upon reception of an ASP Active message for the first 3101 ASP in a Broadcast AS, MAY choose not to direct traffic to a newly 3102 active ASP until it determines that there are sufficient resources to 3103 handle the expected load (e.g., until there are "n" ASPs in state 3104 ASP-ACTIVE in the AS). 3106 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP 3107 MUST tag the first DATA message broadcast in each SCTP stream with a 3108 unique Correlation Id parameter. The purpose of this Correlation Id 3109 is to permit the newly active ASP to synchronize its processing of 3110 traffic in each ordered stream with the other ASPs in the broadcast 3111 group. 3113 4.3.4.5 ASP Inactive Procedures 3115 When an ASP wishes to withdraw from receiving traffic within an AS, the 3116 ASP sends an ASP Inactive message to the SGP. This action MAY be 3117 initiated at the ASP by an M-ASP_INACTIVE request primitive from 3118 Layer Management or MAY be initiated automatically by an M2UA 3119 management function. In the case where an ASP is processing the 3120 traffic for more than one Application Server across a common SCTP 3121 association, the ASP Inactive message contains one or more Interface 3122 Identifiers to indicate for which Application Servers the ASP Inactive 3123 message applies. In the case where an ASP Inactive message does not 3124 contain a Interface Identifier parameter, the receiver must know, via 3125 configuration data, which Application Servers the ASP is a member and 3126 move the ASP to the ASP-INACTIVE state in all Application Servers. 3127 In the case of an Override mode AS, where another ASP has already 3128 taken over the traffic within the AS with an ASP Active ("Override") 3129 message, the ASP that sends the ASP Inactive message is already 3130 considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive 3131 Ack message is sent to the ASP, after ensuring that all traffic is 3132 stopped to the ASP. 3134 In the case of a Load-share mode AS, the SGP moves the ASP to the ASP- 3135 INACTIVE state and the AS traffic is re-allocated across the remaining 3136 ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm 3137 currently used within the AS. A Notify message ("Insufficient ASP 3138 resources active in AS") MAY be sent to all inactive ASPs, if required. 3139 An ASP Inactive Ack message is sent to the ASP after all traffic 3140 is halted and Layer Management is informed with an M-ASP_INACTIVE 3141 indication primitive. 3143 In the case of a Broadcast mode AS, the SGP moves the ASP to the 3144 ASP-INACTIVE state and the AS traffic is broadcast only to the 3145 remaining ASPs in the state ASP-ACTIVE. A Notify message 3146 ("Insufficient ASP resources active in AS") MAY be sent to all 3147 inactive ASPs, if required. An ASP Inactive Ack message is sent to 3148 the ASP after all traffic is halted and Layer Management is informed 3149 with an M-ASP_INACTIVE indication primitive. 3151 Multiple ASP Inactive Ack messages MAY be used in response to an 3152 ASP Inactive message containing multiple Interface Identifers, 3153 allowing the SGP to independently acknowledge for different (sets 3154 of) Interface Identifiers. The SGP sends an Error message ("Invalid 3155 Interface Identifier") message for each invalid or unconfigured 3156 Interface Identifer value in a received ASP Inactive message. 3158 The SGP MUST send an ASP Inactive Ack message in response to a received 3159 ASP Inactive message from the ASP and the ASP is already marked as ASP- 3160 INACTIVE at the SGP. 3162 At the ASP, the ASP Inactive Ack message received is not acknowledged. 3163 Layer Management is informed with an M-ASP_INACTIVE confirm primitive. 3164 If the ASP receives an ASP Inactive Ack without having sent an ASP 3165 Inactive message, the ASP should now consider itself as in the 3166 ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE 3167 state, the ASP should then initiate procedures to return itself to 3168 its previous state. 3170 When the ASP sends an ASP Inactive message it starts timer T(ack). 3171 If the ASP does not receive a response to an ASP Inactive message 3172 within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive 3173 messages until it receives an ASP Inactive Ack message. T(ack) is 3174 provisionable, with a default of 2 seconds. Alternatively, 3175 retransmission of ASP Inactive messages MAY be put under control of 3176 Layer Management. In this method, expiry of T(ack) results in a M- 3177 ASP_Inactive confirm primitive carrying a negative indication. 3179 If no other ASPs in the Application Server are in the state ASP-ACTIVE, 3180 the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs 3181 in the AS which are in the state ASP-INACTIVE. The SGP SHOULD start 3182 buffering the incoming messages for T(r)seconds, after which messages 3183 MAY be discarded. T(r) is configurable by the network operator. If 3184 the SGP receives an ASP Active message from an ASP in the AS before 3185 expiry of T(r), the buffered traffic is directed to that ASP and the 3186 timer is cancelled. If T(r) expires, the AS is moved to the 3187 AS-INACTIVE state. 3189 4.3.4.6 Notify Procedures 3191 A Notify message reflecting a change in the AS state MUST be sent to 3192 all ASPs in the AS, except those in the ASP-DOWN state, with 3193 appropriate Status Information and any ASP Identifier of the failed 3194 ASP. At the ASP, Layer Management is informed with an M-NOTIFY 3195 indication primitive. The Notify message MUST be sent whether the 3196 AS state change was a result of an ASP failure or reception of an 3197 ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message. 3198 In the second case, the Notify message MUST be sent after any related 3199 acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active 3200 Ack, or ASP Inactive Ack). 3202 In the case where a Notify ("AS-PENDING") message is sent by an 3203 SGP that now has no ASPs active to service the traffic, or where a 3204 Notify ("Insufficient ASP resources active in AS") message MUST be sent 3205 in the Loadshare or Broadcast mode, the Notify message does not 3206 explicitly compel the ASP(s) receiving the message to become active. 3207 The ASPs remain in control of what (and when) traffic action is taken. 3209 In the case where a Notify message does not contain a Interface 3210 Identifier parameter, the receiver must know, via configuration data, 3211 of which Application Servers the ASP is a member and take the 3212 appropriate action in each AS. 3214 4.3.4.7 Heartbeat Procedures 3216 The optional Heartbeat procedures MAY be used when operating over 3217 transport layers that do not have their own heartbeat mechanism for 3218 detecting loss of the transport association (i.e., other than SCTP). 3220 Either M2UA peer may optionally send Heartbeat messages periodically, 3221 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 3222 message, the M2UA peer MUST respond with a Heartbeat Ack message. 3224 If no Heartbeat Ack message (or any other M2UA message) is received 3225 from the M2UA peer within 2*T(beat), the remote M2UA peer is considered 3226 unavailable. Transmission of Heartbeat messages is stopped and the 3227 signalling process SHOULD attempt to re-establish communication if it 3228 is configured as the client for the disconnected M2UA peer. 3230 The Heartbeat message may optionally contain an opaque Heartbeat Data 3231 parameter that MUST be echoed back unchanged in the related Heartbeat 3232 Ack message. The sender, upon examining the contents of the returned 3233 Heartbeat Ack message, MAY choose to consider the remote M2UA peer as 3234 unavailable. The contents/format of the Heartbeat Data parameter is 3235 implementation-dependent and only of local interest to the original 3236 sender. The contents may be used, for example, to support a Heartbeat 3237 sequence algorithm (to detect missing Heartbeats), and/or a timestamp 3238 mechanism (to evaluate delays). 3240 Note: Heartbeat related events are not shown in Figure 5 "ASP state 3241 transition diagram". 3243 4.4 Link Key Management Procedures 3245 The Interface Identifier Management procedures are optional. They can 3246 be used to support automatic allocation of Signalling Terminals or 3247 Signalling Data Links [2][3]. 3249 4.4.1 Registration 3251 An ASP MAY dynamically register with an SGP as an ASP within an 3252 Application Server for individual Interface Identifier(s) using 3253 the REG REQ message. A Link Key parameter in the REG REQ specifies 3254 the parameters associated with the Link Key. 3256 The SGP examines the contents of the received Link Key parameters (SDLI 3257 and SDTI) and compares them with the currently provisioned Interface 3258 Identifiers. If the received Link Key matches an existing SGP Link Key 3259 entry, and the ASP is not currently included in the list of ASPs for 3260 the related Application Server, the SGP MAY authorize the ASP to be 3261 added to the AS. Or, if the Link Key does not currently exist and the 3262 received Link Key data is valid and unique, an SGP supporting dynamic 3263 configuration MAY authorize the creation of a new Interface Identifier 3264 and related Application Server and add the ASP to the new AS. In either 3265 case, the SGP returns a Registration Response message to the ASP, 3266 containing the same Local-LK-Identifier as provided in the initial 3267 request, a Registration Result "Successfully Registered" and the 3268 Interface Identifier. A unique method of Interface Identifier valid 3269 assignment at the SG/SGP is implementation dependent but must be 3270 guaranteed to be unique for each Application server or Link Key 3271 served by SGP. 3273 If the SGP determines that the received Link Key data is invalid, or 3274 contains invalid parameter values, the SGP returns a Registration 3275 Response message to the ASP, containing a Registration Result "Error 3276 - Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI" 3277 as appropriate. 3279 If the SGP determins that the Link Key parameter overlaps with an 3280 existing Link Key entry, the SGP returns a Registration Response 3281 message to the ASP, with a Registration Status of "Error - 3282 Overlapping (Non-Unique) Link Key". An incoming signalling message 3283 received at an SGP cannot match against more than one Link Key. 3285 If the SGP does not authorize the registration request, the SGP 3286 returns a REG RSP message to the ASP containing the Registration 3287 Result "Error - Permission Denied". 3289 If an SGP determines that a received Link Key does not currently 3290 exist and the SGP does not support dynamic configuration, the SGP 3291 returns a Registration Response message to the ASP, containing a 3292 Registration Result "Error - Link Key not Provisioned". 3294 If an SGP determines that a received Link Key does not currently 3295 exist and the SGP supports dynamic reconfiguration but does not have 3296 the capacity to add new Link Key and Application Server entries, the 3297 SGP returns a Registration Response message to the ASP, containing a 3298 Registration Result "Error - Insufficient Resources". 3300 An ASP MAY register multiple Link Keys at once by including a number 3301 of Link Key parameters in a single REG REQ message. The SGP MAY 3302 response to each registration request in a single REG RSP message, 3303 indicating the success or failure result for each Link Key in a 3304 separate Registration Result parameter. Alternatively, the SGP MAY 3305 respond with multiple REG RSP messages, each with one or more 3306 Registration Result parameters. The ASP uses the Local-LK-Identifier 3307 parameter to correlate the requests with the responses. 3309 4.4.2 Deregistration 3311 An ASP MAY dynamically de-register with an SGP as an ASP within an 3312 Application Server for individual Interface Identifier(s) using 3313 the DEREG REQ message. A Interface Identifier parameter in the 3314 DEREG REQ specifies which Interface Identifier to de-register. 3316 The SGP examines the contents of the received Interface Identifier 3317 parameter and validates that the ASP is currently registered in the 3318 Application Server(s) related to the included Interface 3319 Identifier(s). If validated, the ASP is de-registered as an ASP in 3320 the related Application Server. 3322 The deregistration procedure does not necessarily imply the deletion 3323 of Link Key and Application Server configuration data at the SGP. 3324 Other ASPs may continue to be associated with the Application 3325 Server, in which case the Link Key data CANNOT be deleted. If a 3326 Deregistration results in no more ASPs in an Application Server, an 3327 SGP MAY delete the Link Key data. 3329 The SGP acknowledges the de-registration requires by returning a DEREG 3330 RSP to the requesting ASP. The result of the de-registration is 3331 found in the Deregistration Result parameter, indicating success or 3332 failure with cause. 3334 An ASP MAY de-register multiple Interface Identifiers at once by 3335 including a number of Interface Identifiers in a single DEREG REQ 3336 message. The SGP MUST response to each deregistration request in a 3337 single DEREG RSP message, indicating the success or failure result 3338 for each Interface Identifier in a separate Deregistration Result 3339 parameter. 3341 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 3343 5.1 Establishment of associations between SGP and MGC examples 3345 5.1.1 Single ASP in an Application Server (1+0 sparing) 3347 This scenario shows the example M2UA message flows for the establishment 3348 of traffic between an SGP and an ASP, where only one ASP is configured 3349 within an AS (no backup). It is assumed that the SCTP association is 3350 already set-up. 3352 SGP ASP1 3353 | 3354 |<---------ASP Up----------| 3355 |--------ASP Up Ack------->| 3356 | | 3357 |<-------ASP Active--------| 3358 |------ASP Active Ack----->| 3359 | | 3360 |------NTFY(AS-ACTIVE)---->| 3362 5.1.2 Single ASP in an Application Server (1+0 sparing) with Dynamic 3363 Registration 3365 This scenario is the same as the one shown in Section 5.1.1 except 3366 with a dynamic registration (automatic allocation) of Interface 3367 Identifier(s). 3369 SGP ASP1 3370 | 3371 |<---------ASP Up----------| 3372 |--------ASP Up Ack------->| 3373 | | 3374 |<--------REG REQ----------| 3375 |------REG REQ RESP------->| 3376 | | 3377 |<-------ASP Active--------| 3378 |------ASP Active Ack----->| 3379 | | 3380 |------NTFY(AS-ACTIVE)---->| 3382 5.1.3 Two ASPs in Application Server (1+1 sparing) 3384 This scenario shows the example M2UA message flows for the establishment 3385 of traffic between an SGP and two ASPs in the same Application Server, 3386 where ASP1 is configured to be active and ASP2 to be standby in the event 3387 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 3388 act as a hot, warm, or cold standby depending on the extent to which ASP1 3389 and ASP2 share call/transaction state or can communicate call state under 3390 failure/withdrawal events. 3392 SGP ASP1 ASP2 3393 | | | 3394 |<--------ASP Up----------| | 3395 |-------ASP Up Ack------->| | 3396 | | | 3397 |<-----------------------------ASP Up----------------| 3398 |----------------------------ASP Up Ack------------->| 3399 | | | 3400 | | | 3401 |<-------ASP Active-------| | 3402 |-----ASP Active Ack----->| | 3403 | | | 3404 | | | 3405 |-----NTFY(AS-ACTIVE)---->| | 3406 | | | 3407 |------------------NTFY(AS-ACTIVE)------------------>| 3409 5.2 ASP Traffic Fail-over Examples 3411 5.2.1 (1+1 Sparing, withdrawal of ASP, backup Override) 3413 Following on from the example in Section 5.1.2, and ASP withdraws from 3414 service: 3416 SGP ASP1 ASP2 3417 | | | 3418 |<-----ASP Inactive-------| | 3419 |----ASP Inactive Ack---->| | 3420 | | | 3421 |------------------NTFY(AS-PENDING)----------------->| 3422 | | | 3423 |<------------------------------ ASP Active----------| 3424 |-----------------------------ASP Active Ack-------->| 3425 | | | 3426 |------------------NTFY(AS-ACTIVE)------------------>| 3427 | | | 3429 In this case, the SGP notifies ASP2 that the AS has moved to the 3430 AS-PENDING state. ASP2 sends ASP Active to bring the AS back to 3431 the AS-ACTIVE state. If ASP2 did not send the ASP Active message 3432 before T(r) expired, the SGP would send a NOTIFY (AS-DOWN). 3434 Note: If the SGP detects loss of the M2UA peer (through a detection 3435 of SCTP failure), the initial SGP-ASP1 ASP Inactive message exchange 3436 would not occur. 3438 SGP ASP1 ASP2 3439 | | | 3440 (detects SCTP failure) 3441 |------------------NTFY(AS-PENDING)----------------->| 3442 | | | 3443 |<------------------------------ ASP Active----------| 3444 |-----------------------------ASP Active Ack-------->| 3445 | | | 3446 |------------------NTFY(AS-ACTIVE)------------------>| 3447 | | | 3449 5.2.2 (1+1 Sparing, backup Override) 3451 Following on from the example in Section 5.1.2, and ASP2 wishes to 3452 override ASP1 and take over the traffic: 3454 SGP ASP1 ASP2 3455 | | | 3456 |<-------------------------------ASP Active----------| 3457 |-----------------------------ASP Active Ack-------->| 3458 |----NTFY(Alt ASP-Act)--->| | 3459 | | | 3461 In this case, the SGP notifies ASP1 that an alternative ASP has 3462 overridden it. 3464 5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 3466 When the M2UA layer on the ASP has a MAUP message to send to the SGP, it 3467 will do the following: 3469 - Determine the correct SGP 3471 - Find the SCTP association to the chosen SGP 3473 - Determine the correct stream in the SCTP association based on 3474 the SS7 link 3476 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3477 Common Header 3479 - Send the MAUP message to the remote M2UA peer in the SGP, over the 3480 SCTP association 3482 When the M2UA layer on the SGP has a MAUP message to send to the ASP, it 3483 will do the following: 3485 - Determine the AS for the Interface Identifier 3487 - Determine the Active ASP (SCTP association) within the AS 3489 - Determine the correct stream in the SCTP association based on 3490 the SS7 link 3492 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3493 Common Header 3495 - Send the MAUP message to the remote M2UA peer in the ASP, over the 3496 SCTP association 3498 5.3.1 SS7 Link Alignment 3500 The MGC can request that a SS7 link be brought into alignment using the 3501 normal or emergency procedure [2][3]. An example of the message flow 3502 to bring a SS7 link in-service using the normal alignment procedure is 3503 shown below. 3505 MTP2 M2UA M2UA MTP3 3506 SGP SGP ASP ASP 3508 <----Start Req---|<---Establish Req----|<----Start Req------ 3510 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 3512 An example of the message flow to bring a SS7 link in-service using the 3513 emergency alignment procedure. 3515 MTP2 M2UA M2UA MTP3 3516 SGP SGP ASP ASP 3518 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 3520 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 3522 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 3524 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 3526 5.3.2 SS7 Link Release 3528 The MGC can request that a SS7 link be taken out-of-service. It uses 3529 the Release Request message as shown below. 3531 MTP2 M2UA M2UA MTP3 3532 SGP SGP ASP ASP 3534 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 3536 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 3538 The SGP can autonomously indicate that a SS7 link has gone out-of- 3539 service as shown below. 3541 MTP2 M2UA M2UA MTP3 3542 SGP SGP ASP ASP 3544 --Out of Serv->|----Release Ind----->|--Out of Serv--> 3546 5.3.3 Set and Clear Local Processor Outage 3548 The MGC can set a Local Processor Outage condition. It uses the 3549 State Request message as shown below. 3551 MTP2 M2UA M2UA MTP3 3552 SGP SGP ASP ASP 3554 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 3556 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 3558 The MGC can clear a Local Processor Outage condition. It uses the 3559 State Request message as shown below. 3561 MTP2 M2UA M2UA MTP3 3562 SGP SGP ASP ASP 3564 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 3566 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 3568 5.3.4 Notification of Remote Processor Outage 3570 The SGP can indicate Remote has entered or exited the Processor Outage 3571 condition for a SS7 link. It uses the State Indication message as shown 3572 below. 3574 MTP2 M2UA M2UA MTP3 3575 SGP SGP ASP ASP 3577 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 3579 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 3581 5.3.5 Notification of SS7 Link Congestion 3583 The SGP can indicate that a SS7 link has become congested. It uses the 3584 Congestion Indication message as shown below. 3586 MTP2 M2UA M2UA MTP3 3587 SGP SGP ASP ASP 3589 ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> 3591 -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> 3593 5.3.6 SS7 Link Changeover 3595 An example of the message flow for an error free changeover is shown 3596 below. In this example, there were three messages in the retransmission 3597 queue that needed to be retrieved. 3599 MTP2 M2UA M2UA MTP3 3600 SGP SGP ASP ASP 3602 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3603 (seq_num = 0) 3605 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3606 (seq_num = BSN) 3608 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3609 (seq_num = FSN) 3611 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3612 (seq_num = 0) 3614 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3615 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3616 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3618 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 3620 Note: The number of Retrieval Indication is dependent on the number of 3621 messages in the retransmit queue that have been requested. Only one 3622 Retrieval Complete Indication SHOULD be sent. 3624 An example of a message flow with an error retrieving the BSN is shown 3625 below. 3627 MTP2 M2UA M2UA MTP3 3628 SGP SGP ASP ASP 3630 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3632 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 3633 (seq_num = -1) 3635 An example of a message flow with an error retrieving the messages is 3636 shown below. 3638 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3640 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3641 (seq_num = BSN) 3643 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3644 (seq_num = FSN) 3646 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3647 (seq_num = -1) 3649 An example of a message flow for a request to drop messages (clear 3650 retransmission buffers) is shown below. 3652 MTP2 M2UA M2UA MTP3 3653 SGP SGP ASP ASP 3655 <-Clr TB/RTB Req-|<-Rtrv Req (ACTION_DROP_MSGS)-|<--Clr TB/RTB Req--- 3657 -Clr TB/RTB Ind->|-Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr TB/RTB Ind--> 3659 5.3.7 Flush and Continue 3661 The following message flow shows a request to flush buffers. 3663 MTP2 M2UA M2UA MTP3 3664 SGP SGP ASP ASP 3666 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 3668 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 3670 The following message flow shows a request to continue. 3672 MTP2 M2UA M2UA MTP3 3673 SGP SGP ASP ASP 3675 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 3677 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 3679 5.3.8 Auditing of SS7 link state 3681 It may be necessary for the ASP to audit the current state of a SS7 link. 3682 The flows below show an example of the request and all the potential 3683 responses. 3685 Below is an example in which the SS7 link is out-of-service. 3687 MTP2 M2UA M2UA MGMT 3688 SGP SGP ASP ASP 3690 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3692 MTP3 3693 ASP 3695 |-----------Release Ind---------->|-Out of Serv Ind-> 3697 MGMT 3698 ASP 3700 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3702 Below is an example in which the SS7 link is in-service. 3704 MTP2 M2UA M2UA MGMT 3705 SGP SGP ASP ASP 3707 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3709 MTP3 3710 ASP 3712 |-----------Establish Cfm-------->|---In Serv Ind--> 3714 MGMT 3715 ASP 3717 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3719 Below is an example in which the SS7 link is in-service, but congested. 3721 MTP2 M2UA M2UA MGMT 3722 SGP SGP ASP ASP 3724 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3726 MTP3 3727 ASP 3729 |-----------Establish Cfm-------->|---In Serv Ind--> 3731 |----------Congestion Ind-------->|---Cong Ind-----> 3733 MGMT 3734 ASP 3736 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3738 Below is an example in which the SS7 link is in-service, but in Remote 3739 Processor Outage. 3741 MTP2 M2UA M2UA MGMT 3742 SGP SGP ASP ASP 3744 |<----State Req (STATUS_AUDIT)----|<---Audit Req---- 3746 MTP3 3747 ASP 3749 |-----------Establish Ind-------->|---In Serv Ind--> 3751 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter---> 3753 MGMT 3754 ASP 3756 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3758 6.0 Timer Values 3760 The recommended default values for M2UA timers are: 3762 T(r) 2 seconds 3763 T(ack) 2 seconds 3764 T(beat) Heartbeat Timer 30 seconds 3766 7.0 Security Considerations 3768 M2UA is designed to carry signalling messages for telephony services. 3769 As such, M2UA MUST involve the security needs of several parties: the 3770 end users of the services; the network providers and the applications 3771 involved. Additional requirements MAY come from local regulation. 3772 While having some overlapping security needs, any security solution 3773 SHOULD fulfill all of the different parties' needs. 3775 7.1 Threats 3777 There is no quick fix, one-size-fits-all solution for security. As a 3778 transport protocol, M2UA has the following security objectives: 3780 * Availability of reliable and timely user data transport. 3781 * Integrity of user data transport. 3782 * Confidentiality of user data. 3784 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 3785 security features, such as: 3787 * Blind Denial of Service Attacks 3788 * Flooding 3789 * Masquerade 3790 * Improper Monopolization of Services 3792 When M2UA is running in professionally managed corporate or service 3793 provider network, it is reasonable to expect that this network includes 3794 an appropriate security policy framework. The "Site Security Handbook" 3795 [10] SHOULD be consulted for guidance. 3797 When the network in which M2UA runs in involves more than one party, it 3798 MAY NOT be reasonable to expect that all parties have implemented 3799 security in a sufficient manner. In such a case, it is recommended that 3800 IPSEC is used to ensure confidentiality of user payload. Consult [11] 3801 for more information on configuring IPSEC services. 3803 7.2 Protecting Confidentiality 3805 Particularly for mobile users, the requirement for confidentiality MAY 3806 include the masking of IP addresses and ports. In this case application 3807 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 3808 Regardless of which level performs the encryption, the IPSEC ISAKMP 3809 service SHOULD be used for key management. 3811 8.0 IANA Considerations 3813 8.1 SCTP Payload Protocol Identifier 3815 A request will be made to IANA to assign an M2UA value for the Payload 3816 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 3817 Payload Protocol Identifier will be registered: 3819 M2UA "2" 3821 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 3822 to indicate which protocol the SCTP is carrying. This Payload Protocol 3823 Identifier is not directly used by SCTP but MAY be used by certain 3824 network entities to identify the type of information being carried in a 3825 Data chunk. 3827 The User Adaptation peer MAY use the Payload Protocol Identifier as a 3828 way of determining additional information about the data being presented 3829 to it by SCTP. 3831 8.2 M2UA Protocol Extensions 3833 This protocol may also be extended through IANA in three ways: 3835 -- through definition of additional message classes, 3836 -- through definition of additional message types, and 3837 -- through definition of additional message parameters. 3839 The definition and use of new message classes, types and parameters is 3840 an integral part of SIGTRAN adaptation layers. Thus, these extensions 3841 are assigned by IANA through an IETF Consensus action as defined in 3842 [RFC2434]. 3844 The proposed extension must in no way adversely affect the general 3845 working of the protocol. 3847 8.2.1 IETF Defined Message Classes 3849 The documentation for a new message class MUST include the following 3850 information: 3852 (a) A long and short name for the message class. 3853 (b) A detailed description of the purpose of the message class. 3855 8.2.2 IETF Defined Message Types 3857 Documentation of the message type MUST contain the following 3858 information: 3860 (a) A long and short name for the new message type. 3861 (b) A detailed description of the structure of the message. 3862 (c) A detailed definition and description of intended use of each field 3863 within the message. 3864 (d) A detailed procedural description of the use of the new message 3865 type within the operation of the protocol. 3866 (e) A detailed description of error conditions when receiving this 3867 message type. 3869 When an implementation receives a message type which it does not support, 3870 it MUST respond with an Error (ERR) message with an Error Code of 3871 Unsupported Message Type. 3873 8.2.3 IETF-defined TLV Parameter Extension 3875 Documentation of the message parameter MUST contain the following 3876 information: 3878 (a) Name of the parameter type. 3879 (b) Detailed description of the structure of the parameter field. This 3880 structure MUST conform to the general type-length-value format 3881 described in Section 3.1.5. 3882 (c) Detailed definition of each component of the parameter value. 3883 (d) Detailed description of the intended use of this parameter type, 3884 and an indication of whether and under what circumstances 3885 multiple instances of this parameter type may be found within the 3886 same message type. 3888 9.0 Acknowledgements 3890 The authors would like to thank John Loughney, Neil Olson, Michael 3891 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 3892 Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark 3893 Kobine, Nitin Tomar, Harsh Bhondwe and Karen King for their valuable 3894 comments and suggestions. 3896 10.0 References 3898 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 3899 System No. 7 (SS7)' 3901 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 3902 Message Transfer Part (MTP)' 3904 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 3906 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 3907 of Signalling System Number 7', Volume 1, December 1995 3909 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 3911 [6] Architectural Framework for Signalling Transport, RFC 2719, 3912 October 1999 3914 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', 3915 February 1995 3917 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 3918 functions and messages using the services of ITU-T 3919 Recommendation Q.2140', August 1995 3921 [9] ITU-T Recommendation Q.751.1, 'Network Element Management 3922 Information Model for the Message Transfer Part', October 1995 3924 [10] Site Security Handbook, RFC 2196, September 1997 3926 [11] Security Architecture for the Internet Protocol, RFC 2401 3928 [12] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip- 3929 sctp-00.txt, Work In Progress 3931 11.0 Author's Addresses 3933 Ken Morneault Tel: +1-703-484-3323 3934 Cisco Systems Inc. EMail: kmorneau@cisco.com 3935 13615 Dulles Technology Drive 3936 Herndon, VA. 20171 3937 USA 3939 Ram Dantu, Ph.D. Tel +1-214-291-1111 3940 NetRake Corporation EMail rdantu@netrake.com 3941 3000 Technology Drive 3942 Plano, TX 75074 3943 USA 3945 Greg Sidebottom EMail: gregside@home.com 3946 gregside consulting 3947 Kanata, Ontario 3948 Canada 3950 Tom George Tel: +1-972-519-3168 3951 Alcatel USA EMail: tom.george@usa.alcatel.com 3952 1000 Coit Road 3953 Plano, TX 74075 3954 USA 3956 Brian Bidulock Tel +1-972-839-4489 3957 OpenSS7 Project EMail: bidulock@openss7.org 3958 c/o #424, 4701 Preston Park Blvd. 3959 Plano, TX 75093 3960 USA 3962 Jacob Heitz Tek +1-510-747-2917 3963 Lucent Technologies Email: jheitz@lucent.com 3964 1701 Harbor Bay Parkway 3965 Alameda, CA, 94502 3966 USA 3967 Appendix A: Signalling Network Architecture 3969 A Signalling Gateway will support the transport of MTP2-User signalling 3970 traffic received from the SS7 network to one or more distributed ASPs 3971 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 3972 meet any performance and reliability requirements for such transport. 3973 A physical network architecture is required, with data on the 3974 availability and transfer performance of the physical nodes involved in 3975 any particular exchange of information. However, the M2UA protocol is 3976 flexible enough allow its operation and management in a variety of 3977 physical configurations that will enable Network Operators to meet 3978 their performance and reliability requirements. 3980 To meet the stringent SS7 signalling reliability and performance 3981 requirements for carrier grade networks, these Network Operators should 3982 ensure that there is no single point of failure provisioned in the end- 3983 to-end network architecture between an SS7 node and an IP ASP. 3985 Depending of course on the reliability of the SGP and ASP functional 3986 elements, this can typically be met by the spreading SS7 links in a 3987 SS7 linkset [1] across SGPs or SGs, the provision of redundant 3988 QoS-bounded IP network paths for SCTP Associations between SCTP End 3989 Points, and redundant Hosts. The distribution of ASPs within the 3990 available Hosts is also important. For a particular Application 3991 Server, the related ASPs MAY be distributed over at least two Hosts. 3993 An example logical network architecture relevant to carrier-grade 3994 operation in the IP network domain is shown in Figure 7 below: 3996 ************** ************** 3997 * ********__*______________________________*__******** * Host1 3998 SG1 * * SGP1 *__*________________ _______*__* ASP1 * * 3999 * ******** * | | * ******** * 4000 * . * | | * * 4001 * . * | | ************** 4002 ************** | | 4003 | | 4004 ************** | | 4005 * ********__*______________________| 4006 SG2 * * SGP2 *__*________ | 4007 * ******** * | | 4008 * . * | | 4009 * . * | | 4010 ************** | | ************** 4011 | |_____________*__******** * Host2 4012 |_____________________*__* ASP2 * * 4013 . * ******** * 4014 . SCTP Associations * * 4015 . ************** 4016 . 4017 . 4018 . 4020 Figure 7: Logical Model Example 4022 To avoid a single point of failure, it is recommended that a minimum 4023 of two ASPs be configured in an AS list, resident in separate hosts 4024 and, therefore, available over different SCTP associations. For 4025 example, in the network shown in Figure 7, all messages for the 4026 Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in 4027 Host2. The AS list at SGP1 might look like the following: 4029 Interface Identifiers - Application Server #1 4030 ASP1/Host1 - State = Active 4031 ASP2/Host2 - State = Inactive 4033 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 4034 message for the Interface Identifiers registered. ASP2 in Host2 would 4035 normally be brought to the active state upon failure of ASP1/Host1. 4036 In this example, both ASPs are Inactive or Active, meaning that the 4037 related SCTP association and far-end M2UA peer is ready. 4039 For carrier grade networks, Operators should ensure that under failure 4040 or isolation of a particular ASP, stable calls or transactions are not 4041 lost. This implies that ASPs need, in some cases, to share the call/- 4042 transaction state or be able to pass the call/transaction state between 4043 each other. Also, in the case of ASPs performing call processing, 4044 coordination MAY be required with the related Media Gateway to transfer 4045 the MGC control for a particular trunk termination. However, this 4046 sharing or communication is outside the scope of this document.