idnits 2.17.1 draft-ietf-sigtran-m2ua-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 10) being 87 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 76 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 21 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 25: '... that other groups MAY also distribute...' RFC 2119 keyword, line 29: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 139: '...cess. Fail-back MAY apply upon the re...' RFC 2119 keyword, line 257: '...Note: STPs MAY be present in the SS7 p...' RFC 2119 keyword, line 276: '... the SCTP functions above MAY NOT be a...' (161 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2908 has weird spacing: '...imitive carry...' == Line 3170 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 [14] 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 (Feb 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 692 -- Looks like a reference, but probably isn't: 'M3UA' on line 739 -- Looks like a reference, but probably isn't: 'IUA' on line 744 -- Looks like a reference, but probably isn't: 'M2UA' on line 745 -- Looks like a reference, but probably isn't: 'SUA' on line 747 -- Looks like a reference, but probably isn't: 'RFC2434' on line 3839 == Unused Reference: '11' is defined on line 3928, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '8') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '14') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 17 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 June 2002 Feb 2002 16 Signaling System 7 (SS7) Message Transfer Part (MTP) 2 - 17 User Adaptation Layer 18 20 Status of This Memo 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC 2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups MAY also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and MAY be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as 'work in progress'. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 To learn the current status of any Internet-Draft, please check the 40 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 41 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 42 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 43 ftp.isi.edu (US West Coast). 45 Abstract 47 This Internet Draft defines a protocol for backhauling of SS7 MTP2 48 User signalling messages over IP using the Stream Control 49 Transmission Protocol (SCTP). This protocol would be used between a 50 Signalling Gateway (SG) and Media Gateway Controller (MGC). It is 51 assumed that the SG receives SS7 signalling over a standard SS7 52 interface using the SS7 Message Transfer Part (MTP) to provide 53 transport. The Signalling Gateway would act as a Signalling Link 54 Terminal. 56 TABLE OF CONTENTS 58 1. Introduction..............................................3 59 1.1 Scope..................................................3 60 1.2 Terminology............................................3 61 1.3 Signalling Transport Architecture......................5 62 1.4 Services Provide by the M2UA Adaptation Layer..........7 63 1.5 Function Provided by the M2UA Layer....................9 64 1.6 Definition of the M2UA Boundaries.....................11 65 2. Conventions..............................................13 66 3. Protocol Elements........................................13 67 3.1 Common Message Header.................................13 68 3.2 M2UA Message Header...................................17 69 3.3 M2UA Messages.........................................18 70 4. Procedures...............................................48 71 4.1 Procedures to Support the M2UA-User Layer.............49 72 4.2 Receipt of Primitives from the Layer Management.......49 73 4.3 AS and ASP State Maintenance..........................51 74 4.4 Link Key Management Procedures........................62 75 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......63 76 5.1 Establishment of associations between SG and MGC......63 77 examples 78 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........66 79 5.3 Layer Management Communication Examples...............66 80 6. Timers...................................................71 81 7. Security Considerations..................................71 82 7.1 Threats................................................71 83 7.2 Protecting Confidentiality.............................72 84 8. IANA Considerations......................................72 85 8.1 SCTP Payload Protocol Identifier.......................72 86 8.2 IUA Protocol Extensions................................72 87 9. Acknowledgements.........................................74 88 10. References...............................................74 89 11. Author's Addresses.......................................75 90 1. Introduction 92 This draft defines a protocol for the backhauling of SS7 [1] MTP2 User 93 [2] [3] [4] (i.e. MTP3) signalling messages over IP using the Stream Control 94 Transmission Protocol (SCTP) [8]. This protocol would be used between 95 a Signalling Gateway (SG) and Media Gateway Controller (MGC). 97 1.1 Scope 99 There is a need for Switched Circuit Network (SCN) signalling protocol 100 delivery from an Signalling Gateway (SG) to a Media Gateway 101 Controller (MGC) [9]. The delivery mechanism addresses the following 102 objectives: 104 * Support for MTP Level 2 / MTP Level 3 interface boundary 105 * Support for communication between Layer Management modules on SG 106 and MGC 107 * Support for management of SCTP active associations between the SG and 108 MGC 110 The SG will terminate up to MTP Level 2 and the MGC will terminate 111 MTP Level 3 and above. In other words, the SG will transport MTP 112 Level 3 messages over an IP network to a MGC. 114 1.2 Terminology 116 Application Server (AS) - A logical entity serving a specific application 117 instance. An example of an Application Server is a MGC handling the 118 MTP Level 3 and call processing for SS7 links terminated by the 119 Signalling Gateways. Practically speaking, an AS is modeled at the SG 120 as an ordered list of one or more related Application Server Processes 121 (e.g., primary, secondary, tertiary, ...). 123 Application Server Process (ASP) - A process instance of an Application 124 Server. Examples of Application Server Processes are active or standby 125 MGC instances. 127 Association - An association refers to a SCTP association. The 128 association will provide the transport for the delivery of protocol 129 data units for one or more interfaces. 131 Backhaul - Refers to the transport of signalling from the point of 132 interface for the associated data stream (i.e., SG function in the MGU) 133 back to the point of call processing (i.e., the MGCU), if this is not 134 local [9]. 136 Fail-over - The capability to reroute signalling traffic as required 137 to an alternate Application Server Process within an Application Server 138 in the event of failure or unavailability of a currently used Application 139 Server Process. Fail-back MAY apply upon the return to service of a 140 previously unavailable Application Server Process. 142 Host - The computing platform that the ASP process is running on. 144 Interface - For the purposes of this document, an interface is a SS7 145 signalling link. 147 Interface Identifier - The Interface Identifier identifies the physical 148 interface at the SG for which the signalling messages are sent/received. 149 The format of the Interface Identifier parameter can be text or integer, 150 the values of which are assigned according to network operator policy. 151 The values used are of local significance only, coordinated between the 152 SG and ASP. 154 Layer Management - Layer Management is a nodal function in an SG or 155 ASP that handles the inputs and outputs between the M2UA layer and a 156 local management entity. 158 Link Key - The link key is a locally unique (between ASP and SG) 159 value that identifies a registration request for a particular 160 Signalling Data Link and Signalling Terminal pair. 162 MTP - The Message Transfer Part of the SS7 protocol 164 MTP2 - MTP Level 2, the signalling datalink layer of SS7 166 MTP3 - MTP Level 3, the signalling network layer of SS7 168 MTP2-User - A protocol that uses the services of MTP Level 2 169 (i.e. MTP3). 171 Network Byte Order: Most significant byte first, a.k.a Big Endian. 173 Signalling Data Link - An SDL refers to a specific communications 174 facility that connects two Signalling Link Terminals. 176 Signalling Gateway (SG) - An SG is a signalling agent at the edge of 177 the IP network. An SG appears to the SS7 as one or more Signalling 178 Link Terminals that are connected to one or more Signalling Data Links 179 in the SS7 network. An SG contains a set of one or more unique 180 Signalling Gateway Processes, on which one or more is normally 181 actively processing traffic. Where an SG contains more than one SGP, 182 the SG is a logical entity. 184 Signalling Gateway Process (SGP) - A process instance that uses M2UA to 185 communicate to and from a Signalling Link Terminal. It serves as an 186 active, backup or load-sharing proces of a Signalling Gateway. 188 Signalling Link Terminal (SLT) - Refers to the means of performing all 189 of the functions defined at MTP level 2 regardless of their 190 implementation [2]. 192 Stream - A stream refers to an SCTP stream; a unidirectional logical 193 channel established from one SCTP endpoint to another associated SCTP 194 endpoint, within which all user messages are delivered in-sequence 195 except for those submitted to the unordered delivery service. 197 1.3 M2UA Overview 199 The framework architecture that has been defined for SCN signalling 200 transport over IP [9] uses two components: a signalling common 201 transport protocol and an adaptation module to support the services 202 expected by a particular SCN signalling protocol from its underlying 203 protocol layer. 205 Within this framework architecture, this document defines a SCN 206 adaptation module that is suitable for the transport of SS7 MTP2 User 207 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 208 of the Stream Control Transmission Protocol [8] as the underlying 209 reliable signalling common transport protocol. 211 In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling 212 is transmitted and received from the PSTN over a standard SS7 network 213 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 214 to provide reliable transport of the MTP3-User signalling messages to and 215 from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). 216 The SG then provides a interworking of transport functions 217 with the IP transport, in order to transfer the MTP2-User signalling 218 messages to and from an Application Server Process where the peer MTP2- 219 User protocol layer exists. 221 1.3.1 Example - SG to MGC 223 In a Signalling Gateway, it is expected that the SS7 signalling is 224 received over a standard SS7 network termination, using the SS7 Message 225 Transfer Part (MTP) to provide transport of SS7 signalling messages to 226 and from an SS7 Signalling End Point (SEP) or SS7 Signalling Transfer 227 Point (STP). In other words, the SG acts as a Signalling Link Terminal 228 (SLT) [2]. The SG then provides interworking of transport functions 229 with IP Signalling Transport, in order to transport the MTP3 signalling 230 messages to the MGC where the peer MTP3 protocol layer exists, as shown 231 below: 233 ****** SS7 ****** IP ******* 234 *SEP *-----------* SG *-------------* MGC * 235 ****** ****** ******* 237 +----+ +----+ 238 |S7UP| |S7UP| 239 +----+ +----+ 240 |MTP + |MTP | 241 | L3 | (NIF) |L3 | 242 +----+ +----+----+ +----+ 243 |MTP | |MTP |M2UA| |M2UA| 244 | | | +----+ +----+ 245 |L2 | |L2 |SCTP| |SCTP| 246 |L1 | |L1 +----+ +----+ 247 | | | |IP | |IP | 248 +----+ +---------+ +----+ 250 NIF - Nodal Interworking Function 251 SEP - SS7 Signalling Endpoint 252 IP - Internet Protocol 253 SCTP - Stream Control Transmission Protocol (Reference [8]) 255 Figure 1 M2UA in the SG to MGC Application 257 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 259 It is recommended that the M2UA use the services of the Stream 260 Control Transmission Protocol (SCTP) as the underlying reliable 261 common signalling transport protocol. The use of SCTP provides 262 the following features: 264 - explicit packet-oriented delivery (not stream-oriented) 265 - sequenced delivery of user messages within multiple streams, 266 with an option for order-of-arrival delivery of individual 267 user messages, 268 - optional multiplexing of user messages into SCTP datagrams, 269 - network-level fault tolerance through support of multi-homing 270 at either or both ends of an association, 271 - resistance to flooding and masquerade attacks, and 272 - data segmentation to conform to discovered path MTU size 274 There are scenarios without redundancy requirements and 275 scenarios in which redundancy is supported below the transport 276 layer. In these cases, the SCTP functions above MAY NOT be a 277 requirement and TCP can be used as the underlying common 278 transport protocol. 280 1.3.2 ASP Fail-over Model and Terminology 282 The M2UA layer supports ASP fail-over functions in order to support a 283 high availability of call and transaction processing capability. All 284 MTP2-User messages incoming to a SGP from the SS7 network are assigned 285 to the unique Application Server, based on the Interface Identifier of 286 the message. 288 The M2UA layer supports a n+k redundancy model (active-standby, 289 loadsharing, broadcast) where n is the minimum number of redundant 290 ASPs required to handle traffic and k ASPs are available to take over 291 for a failed or unavailable ASP. Note that 1+1 active/standby 292 redundancy is a subset of this model. A simplex 1+0 model is also 293 supported as a subset, with no ASP redundancy. 295 1.3.3 Client/Server Model 297 It is recommended that the SGP and ASP be able to support both client 298 and server operation. The peer endpoints using M2UA SHOULD be 299 configured so that one always takes on the role of client and the 300 other the role of server for initiating SCTP associations. The 301 default orientation would be for the SGP to take on the role of server 302 while the ASP is the client. In this case, ASPs SHOULD initiate the 303 SCTP association to the SGP. 305 The SCTP and TCP Registered User Port Number Assignment for M2UA 306 is 2904. 308 1.4 Services Provided by the M2UA Adaptation Layer 310 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 311 point in the IP network, so that the M2UA protocol layer is required to 312 provide the equivalent set of services to its users as provided by the 313 MTP Level 2 to MTP Level 3. 315 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 317 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 318 a seamless, or as seamless as possible, operation of the MTP2-User peers 319 in the SS7 and IP domains. An example of the primitives that need to be 320 supported can be found in [10]. 322 1.4.2 Support for communication between Layer Management modules 323 on SG and MGC 325 The M2UA layer needs to provide some messages that will facilitate 326 communication between Layer Management modules on the SG and MGC. 328 To facilitate reporting of errors that arise because of backhauling MTP 329 Level 3 scenario, the following primitive is defined: 331 M-ERROR 333 The M-ERROR message is used to indicate an error with a received 334 M2UA message (e.g., an interface identifier value is not known to the 335 SG). 337 1.4.3 Support for management of active associations between SG and MGC 339 The M2UA layer on the SG keeps the state of the configured ASPs. A set 340 of primitives between M2UA layer and the Layer Management are defined 341 below to help the Layer Management manage the association(s) between 342 the SG and the MGC. The M2UA layer can be instructed by the Layer 343 Management to establish a SCTP association to a peer M2UA node. This 344 procedure can be achieved using the M-SCTP ESTABLISH primitive. 346 M-SCTP_ESTABLISH 348 The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm 349 the establishment of a SCTP association to a peer M2UA node. 351 M-SCTP_RELEASE 353 The M-SCTP_RELEASE primitives are used to request, indicate, and 354 confirm the release of a SCTP association to a peer M2UA node. 356 The M2UA layer MAY also need to inform the status of the SCTP 357 association(s) to the Layer Management. This can be achieved using 358 the following primitive. 360 M-SCTP_STATUS 362 The M-SCTP_STATUS primitive is used to request and indicate the status 363 of underlying SCTP association(s). 365 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 366 status (i.e., failure, active, etc.), so that messages can be exchanged 367 between M2UA layer peers to stop traffic to the local M2UA user. This 368 can be achieved using the following primitive. 370 M-ASP_STATUS 372 The ASP status is stored inside M2UA layer on both the SG and MGC 373 sides. The M-ASP_STATUS primitive can be used by Layer Management to 374 request the status of the Application Server Process from the M2UA 375 layer. This primitive can also be used to indicate the status of the 376 Application Server Process. 378 M-ASP_MODIFY 380 The M-ASP_MODIFY primitive can be used by Layer Management to modify 381 the status of the Application Server Process. In other words, the 382 Layer Management on the ASP side uses this primitive to initiate 383 the ASPM procedures. 385 M-AS_STATUS 387 The M-AS_STATUS primitive can be used by Layer Management to request 388 the status of the Application Server. This primitive can also be 389 used to indicate the status of the Application Server. 391 1.5 Functions Provided by the M2UA Layer 393 1.5.1 Mapping 395 The M2UA layer MUST maintain a map of a Interface ID to a physical 396 interface on the Signalling Gateway. A physical interface would be a 397 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 398 MUST also maintain a map of Interface Identifier to SCTP association 399 and to the related stream within the association. 401 The SGP maps an Interface Identifier to an SCTP association/stream 402 only when an ASP sends an ASP Active message for a particular Interface 403 Identifier. It must be noted, however, that this mapping is dynamic 404 and could change at any time due to a change of ASP state. This mapping 405 could even temporarily be invalid, for example during failover of one 406 ASP to another. Therefore, the SGP MUST maintain the states of AS/ASP 407 and reference them during the routing of an messages to an AS/ASP. 409 Note that only one SGP SHOULD provide Signalling Link Terminal 410 services to an SS7 link. Therefore, within an SG, an Application 411 Server SHOULD be active for only one SGP at any given point in time. 413 An example of the logical view of relationship between SS7 link, 414 Interface Identifier, AS and ASP in an SGP is shown below: 416 /-------------------------------------------------+ 417 / /----------------------------------------------|--+ 418 / / v | 419 / / +----+ act+-----+ +-------+ -+--+|-+- 420 SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v 421 / +----+ | +----+ | +-----+ +-------+ -+--+--+- 422 / +->| AS |--+ Streams 423 / +----+ | +----+ stb+-----+ 424 SS7 link2-------->|IID |-+ | ASP | 425 +----+ +-----+ 427 where IID = Interface Identifier 429 A SGP MAY support more than one AS. An AS MAY support more than 430 one Interface Identifier. 432 1.5.2 Support for the management of SCTP associations between the 433 SGPs and ASPs 435 The M2UA layer at the SG maintains the availability state of all 436 configured ASPs, in order to manage the SCTP associations and the 437 traffic between the SG and ASPs. As well, the active/inactive state 438 of remote ASP(s) are also maintained. The Active ASP(s) are the 439 one(s) currently receiving traffic from the SG. 441 The M2UA layer MAY be instructed by local management to establish an 442 SCTP association to a peer M2UA node. This can be achieved using the 443 M-SCTP_ESTABLISH primitive to request, indicate and confirm the 444 establishment of an SCTP association with a peer M2UA node. 446 The M2UA layer MAY also need to inform local management of the status of 447 the underlying SCTP associations using the M-SCTP_STATUS request and 448 indication primitive. For example, the M2UA MAY inform local management 449 of the reason for the release of an SCTP association, determined either 450 locally within the M2UA layer or by a primitive from the SCTP. 452 Also the M2UA layer may need to inform the local management of the 453 change in status of an ASP or AS. This may be achieved using the M-ASP 454 STATUS request or M-AS_STATUS request primitives. 456 1.5.3 Status of ASPs 458 The M2UA layer on the SG MUST maintain the state of the ASPs it is 459 supporting. The state of an ASP changes because of reception of 460 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 461 or reception of indications from the local SCTP association. ASP 462 state transition procedures are described in Section 4.3.1. 464 At a SGP, an Application Server list MAY contain active and inactive 465 ASPs to support ASP fail-over procedures. When, for example, both 466 a primary and a backup ASP are available, M2UA peer protocol is 467 required to control which ASP is currently active. The ordered 468 list of ASPs within a logical Application Server is kept updated in 469 the SGP to reflect the active Application Server Process. 471 Also the M2UA layer MAY need to inform the local management of the 472 change in status of an ASP or AS. This can be achieved using the M-ASP 473 STATUS or M-AS_STATUS primitives. 475 1.5.4 SCTP Specifics 477 1.5.4.1 SCTP Stream Management 479 SCTP allows a user specified number of streams to be opened during 480 initialization of the association. It is the responsibility of the 481 M2UA layer to ensure proper management of these streams. Because of 482 the unidirectional nature of streams, a M2UA layer is not aware of the 483 stream information from its peer M2UA layer. Instead, the Interface 484 Identifier is in the M2UA message header. 486 The use of SCTP streams within M2UA is recommended in order to minimize 487 transmission and buffering delay, therefore improving the overall 488 performance and reliability of the signalling elements. A separate 489 SCTP stream can be used for each SS7 link. Or, an implementation may 490 choose to split the SS7 link across several streams based on SLS. 491 This method may be of particular interest for high speed SS7 links 492 (MTP3b) since high speed links have a 24-bit sequence number and the 493 stream sequence number is 16-bits. 495 SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) 496 messages (see Section 3) since stream '0' SHOULD only be used for ASP 497 Management (ASPM) messages (see Section 4.3.3). 499 1.5.5 Seamless SS7 Network Management Interworking 501 The M2UA layer on the SGP SHOULD pass an indication of unavailability 502 of the M2UA-User (MTP3) to the local Layer Management, if the 503 currently active ASP moves from the ACTIVE state. The actions taken by 504 M2UAon the SGP with regards to MTP Level 2 should be in accordance 505 with the appropriate MTP specifications. 507 1.5.6 Flow Control / Congestion 509 It is possible for the M2UA layer to be informed of IP network 510 congestion onset and abatement by means of an implementation dependent 511 function (i.e. an indication from the SCTP). The handling of 512 this congestion indication by M2UA is implementation dependent. 513 However, the actions taken by the SG should be accordance with the 514 appropriate MTP specification and should enable SS7 functionality 515 (e.g. flow control) to be correctly maintained. 517 1.5.7 Audit of SS7 Link State 519 After a failover of one ASP to another ASP, it may be necessary for the 520 M2UA on the ASP to audit the current SS7 link state to ensure consistency. 521 The M2UA on the SGP would respond to the audit request with information 522 regarding the current state of the SS7 link (i.e. in-service, 523 out-of-service, congestion state, LPO/RPO state). 525 1.6 Definition of the M2UA Boundaries 527 1.6.1 Definition of the M2UA / MTP Level 3 boundary 529 DATA 530 ESTABLISH 531 RELEASE 532 STATE 533 DATA RETRIEVAL 534 DATA RETRIEVAL COMPLETE 536 1.6.2 Definition of the M2UA / MTP Level 2 boundary 538 DATA 539 ESTABLISH 540 RELEASE 541 STATE 542 DATA RETRIEVAL 543 DATA RETRIEVAL COMPLETE 545 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 547 The upper layer and layer management primitives provided by SCTP are 548 provided in Reference [8] Section 9. 550 1.6.4 Definition of Layer Management / M2UA Boundary 552 M-SCTP_ESTABLISH request 553 Direction: LM -> M2UA 554 Purpose: LM requests ASP to establish an SCTP association with an 555 SGP. 557 M-SCTP_ESTABLISH confirm 558 Direction: M2UA -> LM 559 Purpose: ASP confirms to LM that it has established an SCTP 560 association with an SGP. 562 M-SCTP_ESTABLISH indication 563 Direction: M2UA -> LM 564 Purpose: SGP informs LM that an ASP has established an SCTP 565 association. 567 M-SCTP_RELEASE request 568 Direction: LM -> M2UA 569 Purpose: LM requests ASP to release an SCTP association with SGP. 571 M-SCTP_RELEASE confirm 572 Direction: M2UA -> LM 573 Purpose: ASP confirms to LM that it has released SCTP association 574 with SGP. 576 M-SCTP_RELEASE indication 577 Direction: M2UA -> LM 578 Purpose: SGP informs LM that ASP has released an SCTP association. 580 M-SCTP_RESTART indication 581 Direction: M2UA -> LM 582 Purpose: M2UA informs LM that a SCTP Restart indication has 583 been received. 585 M-SCTP_STATUS request 586 Direction: LM -> M2UA 587 Purpose: LM requests M2UA to report status of SCTP association. 589 M-SCTP_STATUS indication 590 Direction: M2UA -> LM 591 Purpose: M2UA reports status of SCTP association. 593 M-ASP_STATUS request 594 Direction: LM -> M2UA 595 Purpose: LM requests SGP to report status of remote ASP. 597 M-ASP_STATUS indication 598 Direction: M2UA -> LM 599 Purpose: SGP reports status of remote ASP. 601 M-AS_STATUS request 602 Direction: LM -> M2UA 603 Purpose: LM requests SG to report status of AS. 605 M-AS_STATUS indication 606 Direction: M2UA -> LM 607 Purpose: SG reports status of AS. 609 M-NOTIFY indication 610 Direction: M2UA -> LM 611 Purpose: ASP reports that it has received a NOTIFY message 612 from its peer. 614 M-ERROR indication 615 Direction: M2UA -> LM 616 Purpose: ASP or SGP reports that it has received an ERROR 617 message from its peer. 619 M-ASP_UP request 620 Direction: LM -> M2UA 621 Purpose: LM requests ASP to start its operation and send an ASP UP 622 message to the SGP. 624 M-ASP_UP confirm 625 Direction: M2UA -> LM 626 Purpose: ASP reports that it has received an ASP UP Acknowledgement 627 message from the SGP. 629 M-ASP_DOWN request 630 Direction: LM -> M2UA 631 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 632 message to the SGP. 634 M-ASP_DOWN confirm 635 Direction: M2UA -> LM 636 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 637 message from the SGP. 639 M-ASP_ACTIVE request 640 Direction: LM -> M2UA 641 Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP. 643 M-ASP_ACTIVE confirm 644 Direction: M2UA -> LM 645 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 646 message from the SGP. 648 M-ASP_INACTIVE request 649 Direction: LM -> M2UA 650 Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP. 652 M-ASP_INACTIVE confirm 653 Direction: M2UA -> LM 654 Purpose: ASP reports that is has received an ASP INACTIVE 655 Acknowledgement message from the SGP. 657 M-LINK_KEY_REG Request 658 Direction: LM -> M2UA 659 Purpose: LM requests ASP to register Link Key with SG by sending REG 660 REQ message. 662 M-LINK_KEY_REG Confirm 663 Direction: M2UA -> LM 664 Purpose: ASP reports to LM that it has successfully received a REG 665 RSP message from SG. 667 M-LINK_KEY_REG Indication 668 Direction: M2UA -> LM 669 Purpose: SG reports to LM that it has successfully processed an 670 incoming REG REQ message from ASP. 672 M-LINK_KEY_DEREG Request 673 Direction: LM -> M2UA 674 Purpose: LM requests ASP to de-register Link Key with SG by sending 675 DEREG REQ message. 677 M-LINK_KEY_DEREG Confirm 678 Direction: M2UA -> LM 679 Purpose: ASP reports to LM that it has successfully received a 680 DEREG RSP message from SG. 682 M-LINK_KEY_DEREG Indication 683 Direction: M2UA -> LM 684 Purpose: SG reports to LM that it has successfully processed an 685 incoming DEREG REQ message from ASP. 687 2.0 Conventions 689 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 690 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 691 in this document, are to be interpreted as described in [RFC2119]. 693 3.0 Protocol Elements 695 This section describes the format of various messages used in this 696 protocol. 698 3.1 Common Message Header 700 The protocol messages for MTP2-User Adaptation require a message 701 structure which contains a version, message class, message type, message 702 length, and message contents. This message header is common among all 703 signalling protocol adaptation layers: 705 0 1 2 3 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Version | Spare | Message Class | Message Type | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Message Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 2 Common Message Header 715 All fields in an M2UA message MUST be transmitted in the network byte 716 order, unless otherwise stated. 718 3.1.1 Version 720 The version field (vers) contains the version of the M2UA adaptation 721 layer. The supported versions are: 723 Value Version 724 ----- ------- 725 1 Release 1.0 727 3.1.2 Spare 729 The Spare field is 8-bits. It SHOULD be set to all '0's by the sender 730 and ignored by the receiver. 732 3.1.3 Message Class 734 The following List contains the valid Message Classes: 736 Message Class: 8 bits (unsigned integer) 738 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 739 1 Transfer Messages [M3UA] 740 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 741 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 742 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 743 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) 744 Messages [IUA] 745 6 MTP2 User Adaptation (MAUP) Messages [M2UA] 746 7 Connectionless Messages [SUA] 747 8 Connection-Oriented Messages [SUA] 748 9 Routing Key Management (RKM) Messages (M3UA) 749 10 Interface Identifier Management (IIM) Messages (M2UA) 750 11 to 127 Reserved by the IETF 751 128 to 255 Reserved for IETF-Defined Message Class extensions 753 3.1.4 Message Type 755 The following List contains the Message Types for the valid Message 756 Classes: 758 MTP2 User Adaptatation (MAUP) Messages 760 0 Reserved 761 1 Data 762 2 Establish Request 763 3 Establish Confirm 764 4 Release Request 765 5 Release Confirm 766 6 Release Indication 767 7 State Request 768 8 State Confirm 769 9 State Indication 770 10 Data Retrieval Request 771 11 Data Retrieval Confirm 772 12 Data Retrieval Indication 773 13 Data Retrieval Complete Indication 774 14 Congestion Indication 775 15 Data Acknowledge 776 16 to 127 Reserved by the IETF 777 128 to 255 Reserved for IETF-Defined MAUP extensions 778 Application Server Process State Maintenance (ASPSM) messages 780 0 Reserved 781 1 ASP Up (UP) 782 2 ASP Down (DOWN) 783 3 Heartbeat (BEAT) 784 4 ASP Up Ack (UP ACK) 785 5 ASP Down Ack (DOWN ACK) 786 6 Heartbeat Ack (BEAT ACK) 787 7 to 127 Reserved by the IETF 788 128 to 255 Reserved for IETF-Defined ASPSM extensions 790 Application Server Process Traffic Maintenance (ASPTM) messages 792 0 Reserved 793 1 ASP Active (ACTIVE) 794 2 ASP Inactive (INACTIVE) 795 3 ASP Active Ack (ACTIVE ACK) 796 4 ASP Inactive Ack (INACTIVE ACK) 797 5 to 127 Reserved by the IETF 798 128 to 255 Reserved for IETF-Defined ASPTM extensions 800 Management (MGMT) Messages 802 0 Error (ERR) 803 1 Notify (NTFY) 804 2 to 127 Reserved by the IETF 805 128 to 255 Reserved for IETF-Defined MGMT extensions 807 Interface Identifier Management (IIM) Messages 809 0 Reserved 810 1 Registration Request (REG REQ) 811 2 Registration Response (REG RSP) 812 3 Deregistration Request (DEREG REQ) 813 4 Deregistration Response (DEREG RSP) 814 5 to 127 Reserved by the IETF 815 128 to 255 Reserved for IETF-Defined IIM extensions 817 3.1.5 Message Length 819 The Message Length defines the length of the message in octets, 820 including the header. The Message Length MUST include parameter 821 padding bytes, if any. The Message Length MUST NOT be longer 822 than a MTP3 message [2] [3] [5] plus the length of the common and 823 M2UA message headers. 825 3.1.6 Variable-Length Parameter Format 827 M2UA messages consist of a Common Header followed by zero or more 828 variable-length parameters, as defined by the message type. The 829 variable-length parameters contained in a message are defined in a 830 Tag-Length-Value format as shown below. 832 0 1 2 3 833 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Parameter Tag | Parameter Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 \ \ 838 / Parameter Value / 839 \ \ 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Mandatory parameters MUST be placed before optional parameters in a 843 message. 845 Parameter Tag: 16 bits (unsigned integer) 847 The Type field is a 16 bit identifier of the type of parameter. It 848 takes a value of 0 to 65534. The common parameters used by adaptation 849 layers are in the range of 0x00 to 0xff. The M2UA specific parameters 850 have Tags in the range 0x300 to 0x3ff. 852 The common parameter tags (used by all User Adaptation layers) that 853 M2UA uses are defined below: 855 Parameter Value Parameter Name 856 --------------- -------------- 857 0 (0x00) Reserved 858 1 (0x01) Interface Identifier (Integer) 859 2 (0x02) Unused 860 3 (0x03) Interface Identifier (Text) 861 4 (0x04) Info String 862 5 (0x05) Unused 863 6 (0x06) Unused 864 7 (0x07) Diagnostic Information 865 8 (0x08) Interface Identifier (Integer Range) 866 9 (0x09) Heartbeat Data 867 10 (0x0a) Unused 868 11 (0x0b) Traffic Mode Type 869 12 (0x0c) Error Code 870 13 (0x0d) Status Type/Information 871 14 (0x0e) Unused 872 15 (0x0f) Unused 873 16 (0x10) Unused 874 17 (0x11) ASP Identifier 875 18 (0x12) Unused 876 19 (0x13) Correlation Id 877 18-255 Reserved 879 The M2UA specific parameter Tags defined are as follows: 881 Parameter Value Parameter Name 882 --------------- -------------- 883 768 (0x0300) Protocol Data 1 884 769 (0x0301) Protocol Data 2 (TTC) 885 770 (0x0302) State Request 886 771 (0x0303) State Event 887 772 (0x0304) Congestion Status 888 773 (0x0305) Discard Status 889 774 (0x0306) Action 890 775 (0x0307) Sequence Number 891 776 (0x0308) Retrieval Result 892 777 (0x0309) Link Key 893 778 (0x030a) Local-LK-Identifier 894 779 (0x030b) Signalling Data Terminal (SDT) Identifier 895 780 (0x030c) Signailng Data Link (SDL) Identifier 896 781 (0x030d) Registration Result 897 782 (0x030e) Registration Status 898 783 (0x030f) De-Registration Result 899 784 (0x0310) De-Registration Status 901 Parameter Length: 16 bits (unsigned integer) 903 The Parameter Length field contains the size of the parameter in 904 bytes, including the Parameter Tag, Parameter Length, and Parameter 905 Value fields. Thus, a parameter with a zero-length Parameter Value 906 field would have a Length field of 4. The Parameter Length does not 907 include any padding bytes. 909 Parameter Value: variable-length. 911 The Parameter Value field contains the actual information to be 912 transferred in the parameter. 914 The total length of a parameter (including Tag, Parameter Length and 915 Value fields) MUST be a multiple of 4 bytes. If the length of the 916 parameter is not a multiple of 4 bytes, the sender pads the Parameter 917 at the end (i.e., after the Parameter Value field) with all zero 918 bytes. The length of the padding is NOT included in the parameter 919 length field. A sender MUST NOT pad with more than 3 bytes. The 920 receiver MUST ignore the padding bytes. 922 3.2 M2UA Message Header 924 In addition to the common message header, there will be a M2UA 925 specific message header. The M2UA specific message header will 926 immediately follow the common message header, but will only be used 927 with MAUP messages. 929 This message header will contain the Interface Identifier. The 930 Interface Identifier identifies the physical interface at the SG for 931 which the signalling messages are sent/received. The format of the 932 Interface Identifier parameter can be text or integer, the values of 933 which are assigned according to network operator policy. The values 934 used are of local significance only, coordinated between the SG and 935 ASP. 937 The integer formatted Interface Identifier MUST be supported. The 938 text formatted Interface Identifier MAY optionally be supported. 940 0 1 2 3 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Tag (0x1) | Length=8 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Interface Identifier (integer) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure 3 M2UA Message Header (Integer-based Interface Identifier) 950 The Tag value for Integer-based Interface Identifier is 0x1. The 951 length is always set to a value of 8. 953 0 1 2 3 954 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Tag (0x3) | Length | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Interface Identifier (text) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 4 M2UA Message Header (Text-based Interface Identifier) 965 The Tag value for the Text-based [7] Interface Identifier is 0x3. The 966 length is equal to the string length of the Interface Identifier 967 name plus four bytes for the Tag and Length fields. The maximum 968 length of the text-based Interface Identifier is 255 octets. 970 3.3 M2UA Messages 972 The following section defines the messages and parameter contents. 973 The M2UA messages will use the common message header (Figure 2) and 974 the M2UA message header (Figure 3). 976 3.3.1 MTP2 User Adaptation Messages 978 3.3.1.1 Data 980 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). 981 The Data message contains the following parameter: 983 Protocol Data (mandatory) 984 Correlation Id (optional) 986 The format for the Data Message parameters is as follows: 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Tag (0x300) | Length | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 / \ 994 \ Protocol Data / 995 / \ 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Tag (0x311) | Length = 8 | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Correlation Id | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 The Protocol Data field contains the MTP2-User application message in 1003 network byte order starting with the Signalling Information Octet (SIO). 1004 The Correlation Id parameter uniquely identifies the MSU carried in the 1005 Protocol Data within an AS. This Correlation Id parameter is assigned 1006 by the sending M2UA. The purpose of the Correlation Id is to permit 1007 the newly active ASP to synchronize its processing of the traffic in 1008 each ordered stream with other ASPs in the broadcast group. 1010 The format for a Data Message with TTC PDU parameters is as follows: 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Tag (0x301) | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 / \ 1018 \ Protocol Data / 1019 / \ 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Tag (0x13) | Length = 8 | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Correlation Id | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 The Protocol Data field contains the MTP2-User application message in 1027 network byte order starting with the Length Indicator (LI) octet. 1028 The Japanese TTC variant uses the spare bits of the LI octet for 1029 priority. The length of the Protocol Data MUST NOT exceed the length 1030 of a MTP2-User application message [2] [3]. 1032 3.3.1.2 Data Acknowledge Message 1034 The Data Acknowledge message contains the Correlation Id of the Data 1035 message which the sending M2UA is acknowledging as successfully 1036 processed to the peer M2UA. 1038 The Data Acknowledge message contains the following parameter: 1040 Correlation Id Mandatory 1042 The following format MUST be used for the Data Ack Message: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Tag (0x13) | Length = 8 | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Correlation Id | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 The Correlation Id parameter of the Data message and the Data Ack 1053 message provide a mechanism, for those SG implementations capable for 1054 taking advantage of them, to obtain an acknowledgement that the MSU 1055 has been transferred to the M2UA peer before acknowleding the MSU to 1056 the SS7 peer, removing the risk of losing messages due to association 1057 failure or SCTP congestion. 1059 The Data Ack message MUST be sent if a Correlation Id parameter is 1060 received from the peer. Otherwise, the Data Ack message MUST NOT be 1061 sent. 1063 If the Data Acknowledge is not sent for Correlation Id(s) or is sent 1064 with Invalid Correlation Id(s), the SS7 link will eventually fail 1065 dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs. 1067 3.3.1.3 Establish (Request, Confirmation) 1069 The Establish Request message is used to establish the SS7 link or to 1070 indicate that the channel has been established. The MGC controls the 1071 state of the SS7 link. When the MGC desires the SS7 link to be 1072 in-service, it will send the Establish Request message. Note that 1073 the SGP MAY already have the SS7 link established at its layer. 1074 If so, upon receipt of an Establish Request, the SGP takes no action 1075 except to send an Establish Confirm. 1077 When the MGC sends an M2UA Establish Request message, the MGC MAY 1078 start a timer. This timer would be stopped upon receipt of an M2UA 1079 Establish Confirm. If the timer expires, the MGC would resend the 1080 M2UA Establish Request message and restart the timer. In other words, 1081 the MGC MAY continue to request the establishment of the datalink 1082 on periodic basis until the desired state is achieved or take some 1083 other action (notify the Management Layer). 1085 The mode (Normal or Emergency) for bringing the SS7 link in service is 1086 defaulted to Normal. The State Request (described in Section 3.3.1.5 1087 below) can be used to change the mode to Emergency. 1089 3.3.1.4 Release (Request, Indication, Confirmation) 1091 This Release Request message is used to release the channel. The 1092 Release Confirm and Indication messages are used to indicate that the 1093 channel has been released. 1095 3.3.1.5 State Request 1097 The State Request message can be sent from a MGC to cause an action 1098 on a particular SS7 link supported by the Signalling Gateway Process. 1099 The SGP sends a State Confirm to the MGC if the action has been 1100 successfully completed. The State Confirm reflects that state value 1101 received in the State Request message. 1103 The State Request message contains the following parameter: 1105 State (mandatory) 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Tag (0x302) | Length = 8 | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | State | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 The valid values for State are shown in the following table. 1117 Define Value Description 1118 STATUS_LPO_SET 0x0 Request local processor outage 1119 STATUS_LPO_CLEAR 0x1 Request local processor outage 1120 recovered 1121 STATUS_EMER_SET 0x2 Request emergency alignment 1122 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1123 emergency) 1124 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1125 and retransmit queues 1126 STATUS_CONTINUE 0x5 Continue or Resume 1127 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1128 STATUS_AUDIT 0x7 Audit state of link 1129 STATUS_CONG_CLEAR 0x8 Congestion cleared 1130 STATUS_CONG_ACCEPT 0x9 Congestion accept 1131 STATUS_CONG_DISCARD 0xa Congestion discard 1133 3.3.1.6 State Confirm 1135 The State Confirm message will be sent by the SGP in response to a State 1136 Request from the MGC. The State Confirm reflects that state value 1137 received in the State Request message. 1139 The State Confirm message contains the following parameter: 1141 State (mandatory) 1143 0 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Tag (0x302) | Length = 8 | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | State | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 The valid values for State are shown in the following table. The value 1152 of the State field SHOULD reflect the value received in the State 1153 Request message. 1155 Define Value Description 1156 STATUS_LPO_SET 0x0 Request local processor outage 1157 STATUS_LPO_CLEAR 0x1 Request local processor outage 1158 recovered 1159 STATUS_EMER_SET 0x2 Request emergency alignment 1160 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1161 emergency) 1162 STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit 1163 and retransmit queues 1164 STATUS_CONTINUE 0x5 Continue or Resume 1165 STATUS_CLEAR_RTB 0x6 Clear the retransmit queue 1166 STATUS_AUDIT 0x7 Audit state of link 1167 STATUS_CONG_CLEAR 0x8 Congestion cleared 1168 STATUS_CONG_ACCEPT 0x9 Congestion accept 1169 STATUS_CONG_DISCARD 0xa Congestion discard 1171 3.3.1.7 State Indication 1173 The MTP2 State Indication message can be sent from a SGP to an ASP to 1174 indicate a condition on a SS7 link. 1176 The State Indication message contains the following parameter: 1178 Event (mandatory) 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Tag (0x303) | Length = 8 | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Event | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 The valid values for Event are shown in the following table. 1190 Define Value Description 1191 EVENT_RPO_ENTER 0x1 Remote entered processor outage 1192 EVENT_RPO_EXIT 0x2 Remote exited processor outage 1193 EVENT_LPO_ENTER 0x3 Link entered processor outage 1194 EVENT_LPO_EXIT 0x4 Link exited processor outage 1196 3.3.1.8 Congestion Indication 1198 The Congestion Indication message can be sent from a Signalling Gateway 1199 Process to an ASP to indicate the congestion status and discard status 1200 of a SS7 link. When the MSU buffer fill increases above an Onset 1201 threshold or decreases below an Abatement threshold or crosses a Discard 1202 threshold in either direction, the SGP SHALL send a congestion indication 1203 message when it supports SS7 MTP2 variants that support multiple congestion 1204 levels. 1206 The SGP SHALL send the message only when there is actually a change 1207 in either the discard level or the congestion level to report, 1208 meaning it is different from the previously sent message. In addition, 1209 the SGP SHALL use an implementation dependent algorithm to limit the 1210 frequency of congestion indication messages. 1212 An implementation may optionally send Congestion Indication messages on 1213 a "high priority" stream in order to potentially reduce delay. 1215 The Congestion Indication message contains the following parameters: 1217 Congestion Status (mandatory) 1218 Discard Status (optional) 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Tag (0x304) | Length = 8 | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Congestion Status | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Tag (0x305) | Length = 8 | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Discard Status | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 The valid values for Congestion Status and Discard Status are shown in 1232 the following table. 1234 Define Value Description 1235 LEVEL_NONE 0x0 No congestion 1236 LEVEL_1 0x1 Congestion Level 1 1237 LEVEL_2 0x2 Congestion Level 2 1238 LEVEL_3 0x3 Congestion Level 3 1240 For SS7 networks that do not support multiple levels of congestion, only 1241 the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that 1242 support multiple levels of congestion, it is possible for all values to 1243 be used. Refer to [2], [3] and [12] for more details on the Congestion 1244 and Discard Status of SS7 signalling links. 1246 3.3.1.9 Retrieval Request 1248 The MTP2 Retrieval Request message is used during the MTP Level 3 1249 changeover procedure to request the BSN, to retrieve PDUs from the 1250 transmit and retransmit queues or to flush PDUs from the retransmit 1251 queue. Examples of the use of Retrieval Request for SS7 Link 1252 Changeover are provided in Section 5.3.6. 1254 The Retrieval Request message contains the following parameters: 1256 Action (mandatory) 1257 Sequence Number (optional) 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Tag (0x306) | Length = 8 | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Action | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Tag (0x307) | Length = 8 | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Sequence Number | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 The valid values for Action are shown in the following table. 1273 Define Value Description 1274 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1275 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit 1276 and retransmit queues 1278 In the Retrieval Request message, the Sequence Number field SHOULD NOT 1279 be present if the Action field is ACTION_RTRV_BSN. The Sequence Number 1280 field contains the Forward Sequence Number (FSN) of the far end if the 1281 Action is ACTION_RTRV_MSGS. 1283 3.3.1.10 Retrieval Confirm 1285 The MTP2 Retrieval Confirm message is sent by the Signalling Gateway 1286 in response to a Retrieval Request message. Examples of the use of 1287 Retrieval Confirm for SS7 Link Changeover are provided in Section 1288 5.3.6. 1290 The Retrieval Confirm message contains the following parameters: 1292 Action (mandatory) 1293 Result (mandatory) 1294 Sequence Number (optional) 1296 0 1 2 3 1297 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 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Tag (0x306) | Length = 8 | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Action | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Tag (0x308) | Length = 8 | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Result | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Tag (0x307) | Length = 8 | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Sequence Number | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 The valid values for Action are the same as in Retrieval Request. 1314 The values for Result are shown below: in the following table. 1316 Define Value Description 1317 RESULT_SUCCESS 0x0 Action successful 1318 RESULT_FAILURE 0x1 Action failed 1320 When the Signalling Gateway Process sends a Retrieval Confirm to a 1321 Retrieval Request, it echos the Action field. If the Action was 1322 ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP 1323 will put the Backward Sequence Number (BSN) in the Sequence Number 1324 field and will indicate a success in the Result field. If the BSN 1325 could not be retrieved, the Sequence Number field will not be included 1326 and the Result field will indicate failure. 1328 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of 1329 the Result field will indicate success or failure. A failure means 1330 that the buffers could not be retrieved. The Sequence Number field is 1331 not used with ACTION_RTRV_MSGS. 1333 3.3.1.11 Retrieval Indication 1335 The Retrieval Indication message is sent by the Signalling Gateway with 1336 a PDU from the transmit or retransmit queue. The Retrieval Indication 1337 message does not contain the Action or seq_num fields, just a MTP3 1338 Protocol Data Unit (PDU) from the transmit or retransmit queue. 1339 Examples of the use of Retrieval Indication for SS7 Link Changeover are 1340 provided in Section 5.3.6. 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Tag (0x300) | Length | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 / \ 1348 \ Protocol Data / 1349 / \ 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 For TTC Data messages, the following parameter will be used to indicate 1353 a TTC PDU which starts at LI. 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Tag (0x301) | Length | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 / \ 1361 \ TTC Protocol Data / 1362 / \ 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 The M2UA implementation MAY consider the use of the bundling feature 1366 of SCTP for Retrieval Indication messages. 1368 3.3.1.12 Retrieval Complete Indication 1370 The MTP2 Retrieval Complete Indication message is exactly the same as 1371 the MTP2 Retrieval Indication message except that it also indicates 1372 that retrieval is complete. In addition, it MAY contain a PDU (which 1373 MUST be the last PDU) from the transmit or retransmit queue. 1375 3.3.2 Application Server Process Maintenance (ASPM) Messages 1377 The ASPM messages will only use the common message header. 1379 3.3.2.1 ASP Up (ASPUP) 1381 The ASP Up (ASPUP) message is used to indicate to a remote M2UA peer 1382 that the Adaptation layer is ready to receive traffic or maintenance 1383 messages. 1385 The ASPUP message contains the following parameters 1387 ASP Identifier (optional) 1388 Info String (optional) 1390 Note: The ASP Identifier MUST be used where the SGP cannot 1391 identify the ASP by pre-configured address/port number 1392 information (e.g., where an ASP is resident on a Host using 1393 dynamic address/port number assignment). 1395 The format for ASPUP Message parameters is as follows: 1397 0 1 2 3 1398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Tag (0xe) | Length | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | ASP Identifier* | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Tag (0x4) | Length | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 / \ 1407 \ INFO String* / 1408 / \ 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 The optional ASP Identifier parameter would contain a unique value 1412 that is locally significant among the ASPs that support an AS. The 1413 SGP should save the ASP Identifier to be used, if necessary, with the 1414 Notify message (see Section 3.3.3.2). 1416 The optional INFO String parameter can carry any meaningful UTF-8 [6] 1417 character string along with the message. Length of the INFO String 1418 parameter is from 0 to 255 octets. No procedures are presently 1419 identified for its use but the INFO String MAY be used for debugging 1420 purposes. 1422 3.3.2.2 ASP Up Ack 1424 The ASP Up Ack message is used to acknowledge an ASP Up message 1425 received from a remote M2UA peer. 1427 The ASPUP Ack message contains the following parameters: 1429 INFO String (optional) 1431 The format for ASPUP Ack Message parameters is as follows: 1433 0 1 2 3 1434 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 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Tag (0x4) | Length | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 / \ 1439 \ INFO String* / 1440 / \ 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 The format and description of the optional Info String parameter is the 1444 same as for the ASP UP message (See Section 3.3.2.1). 1446 3.3.2.3 ASP Down (ASPDN) 1448 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1449 that the adaptation layer is not ready to receive traffic or 1450 maintenance messages. 1452 The ASPDN message contains the following parameters 1454 INFO String (optional) 1456 The format for the ASPDN message parameters is as follows: 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Tag (0x4) | Length | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 / \ 1464 \ INFO String* / 1465 / \ 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 The format and description of the optional Info String parameter is the 1469 same as for the ASP Up message (See Section 3.3.2.1). 1471 3.3.2.4 ASP Down Ack 1473 The ASP Down Ack message is used to acknowledge an ASP Down message 1474 received from a remote M2UA peer. 1476 The ASP Down Ack message contains the following parameters: 1478 INFO String (optional) 1480 The format for the ASPDN Ack message parameters is as follows: 1482 0 1 2 3 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Tag (0x4) | Length | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 / \ 1488 \ INFO String* / 1489 / \ 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 The format and description of the optional Info String parameter is the 1493 same as for the ASP UP message (See Section 3.3.2.1). 1495 3.3.2.5 Heartbeat (BEAT) 1497 The Heartbeat message is optionally used to ensure that the M2UA 1498 peers are still available to each other. 1500 The BEAT message contains the following parameter: 1502 Heartbeat Data Optional 1504 The format for the BEAT message is as follows: 1506 0 1 2 3 1507 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 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Tag = 0x0009 | Length | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 / Heartbeat Data / 1512 \ \ 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 The sending node defines the Heartbeat Data field contents. It may 1516 include a Heartbeat Sequence Number and/or Timestamp, or other 1517 implementation specific details. 1519 The receiver of a Heartbeat message does not process this field as 1520 it is only of significance to the sender. The receiver echoes the 1521 content of the Heartbeat Data in a BEAT ACK message. 1523 3.3.2.6 Heartbeat Ack (BEAT ACK) 1525 The Heartbeat ACK message is sent in response to a BEAT message. A 1526 peer MUST send a BEAT ACK in response to a BEAT message. It includes 1527 all the parameters of the received Heartbeat message, without any 1528 change. 1530 The BEAT ACK message contains the following parameter: 1532 Heartbeat Data Optional 1534 The format for the BEAT ACK message is as follows: 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Tag = 0x0009 | Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 / Heartbeat Data / 1542 \ \ 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 The sending node defines the Heartbeat Data field contents. It may 1546 include a Heartbeat Sequence Number and/or Timestamp, or other 1547 implementation specific details. 1549 The receiver of a Heartbeat message does not process this field as 1550 it is only of significance to the sender. The receiver echoes the 1551 content of the Heartbeat Data in a BEAT ACK message. 1553 3.3.2.7 ASP Active (ASPAC) 1555 The ASPAC message is sent by an ASP to indicate to an SGP that it is 1556 Active and ready to be used. 1558 The ASPAC message contains the following parameters: 1560 Traffic Mode Type (optional) 1561 Interface Identifier (optional) 1562 - Combination of integer and integer ranges, OR 1563 - string (text formatted) 1564 INFO String (optional) 1566 The format for the ASPAC message using integer formatted Interface 1567 Identifiers is as follows: 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Tag (0xb) | Length | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Traffic Mode Type | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Tag (0x1=integer) | Length | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 / \ 1579 \ Interface Identifiers* / 1580 / \ 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Tag (0x8=integer range) | Length | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Interface Identifier Start1* | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Interface Identifier Stop1* | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Interface Identifier Start2* | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Interface Identifier Stop2* | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 . . 1593 . . 1594 . . 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Interface Identifier StartN* | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Interface Identifier StopN* | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 / \ 1601 \ Additional Interface Identifiers / 1602 / of Tag Type 0x1 or 0x8 \ 1603 \ / 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Tag (0x4) | Length | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 / \ 1608 \ INFO String* / 1609 / \ 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 The format for the ASPAC message using text formatted (string) 1613 Interface Identifiers is as follows: 1615 0 1 2 3 1616 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 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Tag (0xb) | Length | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Traffic Mode Type | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | Tag (0x3=string) | Length | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 / \ 1625 \ Interface Identifier* / 1626 / \ 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 / \ 1629 \ Additional Interface Identifiers / 1630 / of Tag Type 0x3 \ 1631 \ / 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Tag (0x4) | Length | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 / \ 1636 \ INFO String* / 1637 / \ 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 The Traffic Mode Type parameter identifies the traffic mode of 1641 operation of the ASP within an AS. The valid values for Type are 1642 shown in the following table: 1644 Value Description 1645 0x1 Override 1646 0x2 Load-share 1647 0x3 Broadcast 1649 Within a particular AS, only one Traffic Mode Type can be used. 1650 The Override value indicates that the ASP is operating in Override 1651 mode, where the ASP takes over all traffic in an Application Server 1652 (i.e., primary/backup operation), over-riding any currently active 1653 ASPs in the AS. In Load-share mode, the ASP will share in the traffic 1654 distribution with any other currently active ASPs. In Broadcast mode, 1655 all of the Active ASPs receive all message traffic in the Application 1656 Server. 1658 The optional Interface Identifiers parameter contains a list of 1659 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1660 (Type 0x3)indexing the Application Server traffic that the sending 1661 ASP is configured/registered to receive. If integer formatted 1662 Interface Identifiers are being used, the ASP can also send ranges of 1663 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1664 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1665 formatted Interface Identifiers (0x3) cannot be used with either 1666 Integer (0x1) or Integer Range (0x8) types. 1668 If no Interface Identifiers are included, the message is for all 1669 provisioned Interface Identifiers within the AS(s) in which the 1670 ASP is provisioned. If only a subset of Interface Identifiers for an 1671 AS are included, the ASP is noted as Active for all the Interface 1672 Identifiers provisioned for that AS. 1674 Note: If the optional Interface Identifier parameter is present, the 1675 integer formatted Interface Identifier MUST be supported, while the 1676 text formatted Interface Identifier MAY be supported. 1678 An SGP that receives an ASPAC with an incorrect or unsupported Traffic 1679 Mode Type for a particular Interface Identifier will respond with an 1680 Error Message (Cause: Unsupported Traffic Handling Mode). 1682 The format and description of the optional Info String parameter is the 1683 same as for the ASP UP message (See Section 3.3.2.1). 1685 3.3.2.8 ASP Active Ack 1687 The ASP Active (ASPAC) Ack message is used to acknowledge an ASP Active 1688 message received from a remote M2UA peer. 1690 The ASPAC Ack message contains the following parameters: 1692 Traffic Mode Type (optional) 1693 Interface Identifier (optional) 1694 - Combination of integer and integer ranges, OR 1695 - string (text formatted) 1696 INFO String (optional) 1698 The format for the ASPAC Ack message with Integer-formatted Interface 1699 Identifiers is as follows: 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Tag (0xb) | Length | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Traffic Mode Type | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Tag (0x1=integer) | Length | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 / \ 1711 \ Interface Identifiers* / 1712 / \ 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Tag (0x8=integer range) | Length | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Interface Identifier Start1* | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Interface Identifier Stop1* | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Interface Identifier Start2* | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Interface Identifier Stop2* | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 . . 1725 . . 1726 . . 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Interface Identifier StartN* | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Interface Identifier StopN* | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 / \ 1733 \ Additional Interface Identifiers / 1734 / of Tag Type 0x1 or 0x8 \ 1735 \ / 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | Tag (0x4) | Length | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 / \ 1740 \ INFO String* / 1741 / \ 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 The format for the ASP Active Ack message using text formatted (string) 1745 Interface Identifiers is as follows: 1747 0 1 2 3 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Tag (0xb) | Length | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Traffic Mode Type | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Tag (0x3=string) | Length | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 / \ 1757 \ Interface Identifier* / 1758 / \ 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 / \ 1761 \ Additional Interface Identifiers / 1762 / of Tag Type 0x3 \ 1763 \ / 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Tag (0x4) | Length | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 / \ 1768 \ INFO String* / 1769 / \ 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 The format and description of the optional Info String parameter is the 1773 same as for the ASP Up message (See Section 3.3.2.1). 1775 The format of the Traffic Mode Type and Interface Identifier parameters 1776 is the same as for the ASP Active message (See Section 3.3.2.5). 1778 3.3.2.9 ASP Inactive (ASPIA) 1780 The ASP Inactive (ASPIA) message is sent by an ASP to indicate to an 1781 SGP that it is no longer an active ASP to be used from within a list 1782 of ASPs. The SGP will respond with an ASPIA Ack message and either 1783 discard incoming messages or buffer for a timed period and then 1784 discard. 1786 The ASPIA message contains the following parameters: 1788 Interface Identifiers (optional) 1789 - Combination of integer and integer ranges, OR 1790 - string (text formatted) 1791 INFO String (optional) 1793 The format for the ASP Inactive message parameters using Integer 1794 formatted Interface Identifiers is as follows: 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Tag (0x1=integer) | Length | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 / \ 1802 \ Interface Identifiers* / 1803 / \ 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Tag (0x8=integer range) | Length | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Interface Identifier Start1* | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Interface Identifier Stop1* | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Interface Identifier Start2* | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Interface Identifier Stop2* | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 . . 1816 . . 1817 . . 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Interface Identifier StartN* | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Interface Identifier StopN* | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 / \ 1824 \ Additional Interface Identifiers / 1825 / of Tag Type 0x1 or 0x8 \ 1826 \ / 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Tag (0x4) | Length | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 / \ 1831 \ INFO String* / 1832 / \ 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 The format for the ASP Inactive message using text formatted (string) 1836 Interface Identifiers is as follows: 1838 0 1 2 3 1839 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 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | Tag (0x3=string) | Length | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 / \ 1844 \ Interface Identifier* / 1845 / \ 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 / \ 1848 \ Additional Interface Identifiers / 1849 / of Tag Type 0x3 \ 1850 \ / 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Tag (0x4) | Length | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 / \ 1855 \ INFO String* / 1856 / \ 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 The format and description of the optional Interface Identifiers and 1860 Info String parameters is the same as for the ASP Active message (See 1861 Section 3.3.2.3). 1863 The optional Interface Identifiers parameter contains a list of 1864 Interface Identifier integers indexing the Application Server traffic 1865 that the sending ASP is configured/registered to receive, but does not 1866 want to receive at this time. 1868 3.3.2.10 ASP Inactive Ack 1870 The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP 1871 Inactive message received from a remote M2UA peer. 1873 The ASPIA Ack message contains the following parameters: 1875 Interface Identifiers (optional) 1876 - Combination of integer and integer ranges, OR 1877 - string (text formatted) 1878 INFO String (optional) 1880 The format for the ASPIA Ack message is as follows: 1882 0 1 2 3 1883 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 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Tag (0x1=integer) | Length | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 / \ 1888 \ Interface Identifiers* / 1889 / \ 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Tag (0x8=integer range) | Length | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Interface Identifier Start1* | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Interface Identifier Stop1* | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Interface Identifier Start2* | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Interface Identifier Stop2* | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 . . 1902 . . 1903 . . 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Interface Identifier StartN* | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Interface Identifier StopN* | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 / \ 1910 \ Additional Interface Identifiers / 1911 / of Tag Type 0x1 or 0x8 \ 1912 \ / 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | Tag (0x4) | Length | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 / \ 1917 \ INFO String* / 1918 / \ 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 The format for the ASP Inactive Ack message using text formatted 1922 (string) Interface Identifiers is as follows: 1924 0 1 2 3 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Tag (0x3=string) | Length | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 / \ 1930 \ Interface Identifier* / 1931 / \ 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 / \ 1934 \ Additional Interface Identifiers / 1935 / of Tag Type 0x3 \ 1936 \ / 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | Tag (0x4) | Length | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 / \ 1941 \ INFO String* / 1942 / \ 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 The format of the Interface Identifier parameter is the same as for 1946 the ASP Inactive message (See Section 3.3.2.7). 1948 The format and description of the optional Info String parameter is 1949 the same as for the ASP Up message (See Section 3.3.2.1). 1951 3.3.3 Layer Management (MGMT) Messages 1953 3.3.3.1 Error (ERR) 1955 The Error (ERR) message is used to notify a peer of an error event 1956 associated with an incoming message. For example, the message type 1957 might be unexpected given the current state, or a parameter value might 1958 be invalid. 1960 The ERR message contains the following parameters: 1962 Error Code (mandatory) 1963 Interface Identifier (optional) 1964 Diagnostic Information (optional) 1966 The format for the ERR message is as follows: 1968 0 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Tag (0xc) | Length | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Error Code | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Tag (0x1, 0x3, or 0x8) | Length | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 / \ 1978 \ Interface Identifier(s)* / 1979 / \ 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Tag (0x7) | Length | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 / \ 1984 \ Diagnostic Information* / 1985 / \ 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 The Error Code parameter indicates the reason for the Error Message. 1989 The Error parameter value can be one of the following values: 1991 Invalid Version 0x1 1992 Invalid Interface Identifier 0x2 1993 Unsupported Message Class 0x3 1994 Unsupported Message Type 0x4 1995 Unsupported Traffic Handling Mode 0x5 1996 Unexpected Message 0x6 1997 Protocol Error 0x7 1998 Unsupported Interface Identifier Type 0x8 1999 Invalid Stream Identifier 0x9 2000 Not Used in M2UA 0xa 2001 Not Used in M2UA 0xb 2002 Not Used in M2UA 0xc 2003 Refused - Management Blocking 0xd 2004 ASP Identifier Required 0xe 2005 Invalid ASP Identifier 0xf 2006 ASP Active for Interface Identifier(s) 0x10 2007 Invalid Parameter Value 0x11 2008 Parameter Field Error 0x12 2009 Unexpected Parameter 0x13 2010 Not Used in M2UA 0x14 2011 Not Used in M2UA 0x15 2012 Missing Parameter 0x16 2014 The "Invalid Version" error would be sent if a message was 2015 received with an invalid or unsupported version. The Error message 2016 would contain the supported version in the Common header. The 2017 Error message could optionally provide the supported version in 2018 the Diagnostic Information area. 2020 The "Invalid Interface Identifier" error would be sent by a SGP if 2021 an ASP sends a message (i.e. an ASP Active message) with an invalid 2022 (unconfigured) Interface Identifier value. One of the optional 2023 Interface Identifier parameters (Integer-based, text-based or integer 2024 range) MUST be used with this error code to identify the invalid 2025 Interface Identifier(s) received. 2027 The "Unsupported Traffic Handling Mode" error would be sent by a SGP 2028 if an ASP sends an ASP Active with an unsupported Traffic Handling 2029 Mode. An example would be a case in which the SGP did not support 2030 load-sharing. One of the optional Interface Identifier parameters 2031 (Integer-based, text-based or integer range) MAY be used with this 2032 error code to identify the Interface Identifier(s). 2034 The "Unexpected Message" error would be sent by an ASP if it received 2035 a MAUP message from an SGP while it was in the Inactive state. 2037 The "Protocol Error" error would be sent for any protocol anomaly 2038 (i.e. a bogus message). 2040 The "Invalid Stream Identifier" error would be sent if a message 2041 was received on an unexpected SCTP stream (i.e. a MGMT message 2042 was received on a stream other than "0"). 2044 The "Unsupported Interface Identifier Type" error would be sent by 2045 a SGP if an ASP sends a Text formatted Interface Identifier and the 2046 SGP only supports Integer formatted Interface Identifiers. When 2047 the ASP receives this error, it will need to resend its message with 2048 an Integer formatted Interface Identifier. 2050 The "Unsupported Message Class" error would be sent if a message with 2051 an unexpected or unsupported Message Class is received. 2053 The "Refused - Management Blocking" error is sent when an ASP Up or 2054 ASP Active message is received and the request is refused for 2055 management reasons (e.g., management lock-out"). 2057 The "ASP Identifier Required" is sent by a SGP in response 2058 to an ASPUP message which does not contain an ASP Identifier 2059 parameter when the SGP requires one. The ASP SHOULD resend the 2060 ASPUP message with an ASP Identifier. 2062 The "Invalid ASP Identifier" is send by a SGP in response to an 2063 ASPUP message with an invalid (i.e. non-unique) ASP Identifier. 2065 The "ASP Currently Active for Interface Identifier(s)" error is 2066 sent by a SGP when a Deregistration request is received from an ASP 2067 that is active for Interface Identifier(s) specified in the 2068 Deregistration request. One of the optional Interface Identifier 2069 parameters (Integer-based, text-based or integer range) MAY be used 2070 with this error code to identify the Interface Identifier(s). 2072 The "Invalid Parameter Value " error is sent if a message is received 2073 with an invalid parameter value (e.g., a State Request with an 2074 an undefined State). 2076 The "Parameter Field Error" would be sent if a message with a 2077 parameter that has a wrong length field. 2079 The "Unexpected Parameter" error would be sent if a message contains 2080 an invalid parameter. 2082 The "Missing Parameter" error would be sent if a mandatory parameter 2083 were not included in a message. 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 reserved 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 [8] 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, ASP Down Ack and Error 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.3.4). 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. 2902 When the ASP sends an ASP Up message it starts timer T(ack). If the 2903 ASP does not receive a response to an ASP Up message within T(ack), the 2904 ASP MAY restart T(ack) and resend ASP Up messages until it receives an 2905 ASP Up Ack message. T(ack) is provisionable, with a default of 2 2906 seconds. Alternatively, retransmission of ASP Up messages MAY be put 2907 under control of Layer Management. In this method, expiry of T(ack) 2908 results in an M-ASP_UP confirm primitive carrying a negative 2909 indication. 2911 The ASP MUST wait for the ASP Up Ack message before sending any other 2912 M2UA messages (e.g., ASP Active or REG REQ). If the SGP receives any 2913 other M2UA messages before an ASP Up message is received (other than 2914 ASP Down - see Section 4.3.4.2), the SGP MAY discard them. 2916 If an ASP Up message is received and internally the remote ASP is in 2917 the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as 2918 an Error message ("Unexpected Message), and the remote ASP state is 2919 changed to ASP-INACTIVE in all relevant Application Servers. 2921 If an ASP Up message is received and internally the remote ASP is 2922 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 2923 and no further action is taken. 2925 4.3.4.1.1 M2UA Version Control 2927 If an ASP Up message with an unsupported version is received, the 2928 receiving end responds with an Error message, indicating the version 2929 the receiving node supports and notifies Layer Management. 2931 This is useful when protocol version upgrades are being performed in a 2932 network. A node upgraded to a newer version SHOULD support the older 2933 versions used on other nodes it is communicating with. Because ASPs 2934 initiate the ASP Up procedure it is assumed that the Error message 2935 would normally come from the SGP. 2937 4.3.4.2 ASP Down Procedures 2939 The ASP will send an ASP Down message to an SGP when the ASP wishes to 2940 be removed from service in all Application Servers that it is a member 2941 and no longer receive any MAUP or ASPTM messages. This action MAY be 2942 initiated at the ASP by an M-ASP_DOWN request primitive from Layer 2943 Management or MAY be initiated automatically by an M2UA management 2944 function. 2946 Whether the ASP is permanently removed from any AS is a function of 2947 configuration management. In the case where the ASP previously used 2948 the Registration procedures (see Section 4.4) to register within 2949 Application Servers but has not deregistered from all of them prior to 2950 sending the ASP Down message, the SGP MUST consider the ASP as 2951 Deregistered in all Application Servers that it is still a member. 2953 The SGP marks the ASP as ASP-DOWN, informs Layer Management with an 2954 M-ASP_Down indication primitive, and returns an ASP Down Ack message 2955 to the ASP. 2957 The SGP MUST send an ASP Down Ack message in response to a received ASP 2958 Down message from the ASP even if the ASP is already marked as ASP-DOWN 2959 at the SGP. 2961 At the ASP, the ASP Down Ack message received is not acknowledged. 2962 Layer Management is informed with an M-ASP_DOWN confirm primitive. If 2963 the ASP receives an ASP Down Ack without having sent an ASP Down 2964 message, the ASP SHOULD now consider itself as in the ASP-DOWN state. 2965 If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the 2966 ASP SHOULD then initiate procedures to return itself to its previous 2967 state. 2969 When the ASP sends an ASP Down message it starts timer T(ack). If the 2970 ASP does not receive a response to an ASP Down message within T(ack), 2971 the ASP MAY restart T(ack) and resend ASP Down messages until it 2972 receives an ASP Down Ack message. T(ack) is provisionable, with a 2973 default of 2 seconds. Alternatively, retransmission of ASP Down 2974 messages MAY be put under control of Layer Management. In this method, 2975 expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a 2976 negative indication. 2978 4.3.4.4 ASP Active Procedures 2980 Anytime after the ASP has received an ASP Up Ack message from the SGP, 2981 the ASP MAY send an ASP Active message to the SGP indicating that 2982 the ASP is ready to start processing traffic. This action MAY be 2983 initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer 2984 Management or MAY be initiated automatically by a M2UA management 2985 function. In the case where an ASP wishes to process the traffic for 2986 more than one Application Server across a common SCTP association, the 2987 ASP Active message(s) SHOULD contain a list of one or more Interface 2988 Identifiers to indicate for which Application Servers the ASP Active 2989 message applies. It is not necessary for the ASP to include any 2990 Interface Identifiers of interest in a single ASP Active message, 2991 thus requesting to become active in all Interface Identifiers at the 2992 same time. Multiple ASP Active messages MAY be used to activate 2993 within the Application Servers independently, or in sets. In the 2994 case where an ASP Active message does not contain a Interface 2995 Identifier parameter, the receiver must know, via configuration data, 2996 which Application Server(s) the ASP is a member. 2998 For the Application Servers that the ASP can successfully activate, 2999 the SGP responds with one or more ASP Active Ack messages, including 3000 the associated Interface Identifier(s) and reflecting any Traffic Mode 3001 Type value present in the related ASP Active message. The Interface 3002 Identifier parameter MUST be included in the ASP Active Ack message(s) 3003 if the received ASP Active message contained any Interface Identifiers. 3004 Depending on any Traffic Mode Type request in the ASP Active message 3005 or local configuration data if there is no request, the SGP moves the 3006 ASP to the correct ASP traffic state within the associated Application 3007 Server(s). Layer Management is informed with an M-ASP_Active 3008 indication. If the SGP receives any Data messages before an ASP Active 3009 message is received, the SGP MAY discard them. By sending an ASP 3010 Active Ack message, the SGP is now ready to receive and send traffic 3011 for the related Interface Identifier(s). The ASP SHOULD NOT send MAUP 3012 messages for the related Interface Identifier(s) before receiving an 3013 ASP Active Ack message, or it will risk message loss. 3015 Multiple ASP Active Ack messages MAY be used in response to an ASP 3016 Active message containing multiple Interface Identifiers, allowing 3017 the SGP to independently acknowledge the ASP Active message for 3018 different (sets of) Interface Identifiers. The SGP MUST send 3019 an Error message ("Invalid Interface Identifier") for each Interface 3020 Identifier value that cannot be successfully activated. 3022 In the case where an "out-of-the-blue" ASP Active message is received 3023 (i.e., the ASP has not registered with the SG or the SG has no static 3024 configuration data for the ASP), the message MAY be silently discarded. 3026 The SGP MUST send an ASP Active Ack message in response to a received 3027 ASP Active message from the ASP, if the ASP is already marked in the 3028 ASP-ACTIVE state at the SGP. 3030 At the ASP, the ASP Active Ack message received is not acknowledged. 3031 Layer Management is informed with an M-ASP_ACTIVE confirm primitive. 3032 It is possible for the ASP to receive Data message(s) before the ASP 3033 Active Ack message as the ASP Active Ack and Data messages from an SG 3034 may be sent on different SCTP streams. Message loss is possible as 3035 the ASP does not consider itself in the ASP-ACTIVE state until 3036 reception of the ASP Active Ack message. 3038 When the ASP sends an ASP Active message it starts timer T(ack). If 3039 the ASP does not receive a response to an ASP Active message within 3040 T(ack), the ASP MAY restart T(ack) and resend ASP Active message(s) 3041 until it receives an ASP Active Ack message. T(ack) is provisionable, 3042 with a default of 2 seconds. Alternatively, retransmission of ASP 3043 Active messages MAY be put under control of Layer Management. In 3044 this method, expiry of T(ack) results in an M-ASP_ACTIVE confirm 3045 primitive carrying a negative indication. 3047 There are three modes of Application Server traffic handling in the SGP 3048 M2UA layer: Override, Loadshare and Broadcast. When included, the 3049 Traffic Mode Type parameter in the ASP Active message indicates the 3050 traffic handling mode to be used in a particular Application Server. 3051 If the SGP determines that the mode indicated in an ASP Active message 3052 is unsupported or incompatible with the mode currently configured for 3053 the AS, the SGP responds with an Error message ("Unsupported / Invalid 3054 Traffic Handling Mode"). If the traffic handling mode of the 3055 Application Server is not already known via configuration data, then 3056 the traffic handling mode indicated in the first ASP Active message 3057 causing the transition of the Application Server state to AS-ACTIVE MAY 3058 be used to set the mode. 3060 In the case of an 0verride mode AS, reception of an ASP Active message 3061 at an SGP causes the (re)direction of all traffic for the AS to the ASP 3062 that sent the ASP Active message. Any previously active ASP in the AS 3063 is now considered to be in state ASP-INACTIVE and SHOULD no longer 3064 receive traffic from the SGP within the AS. The SGP then MUST send a 3065 Notify message ("Alternate ASP Active") to the previously active ASP 3066 in the AS, and SHOULD stop traffic to/from that ASP. The ASP receiving 3067 this Notify MUST consider itself now in the ASP-INACTIVE state, if it 3068 is not already aware of this via inter-ASP communication with the 3069 Overriding ASP. 3071 In the case of a Load-share mode AS, reception of an ASP Active 3072 message at an SGP causes the direction of traffic to the ASP sending 3073 the ASP Active message, in addition to all the other ASPs that are 3074 currently active in the AS. The algorithm at the SGP for load-sharing 3075 traffic within an AS to all the active ASPs is implementation 3076 dependent. The algorithm could, for example be round-robin or based 3077 on information in the Data message (e.g., such as the SLS in the 3078 Routing Label). 3080 An SGP, upon reception of an ASP Active message for the first ASP in 3081 a Loadshare AS, MAY choose not to direct traffic to a newly active ASP 3082 until it determines that there are sufficient resources to handle the 3083 expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in 3084 the AS). 3086 All ASPs within a load-sharing mode AS must be able to process any 3087 Data message received for the AS, to accommodate any potential 3088 fail-over or rebalancing of the offered load. 3090 In the case of a Broadcast mode AS, reception of an ASP Active message 3091 at an SGP causes the direction of traffic to the ASP sending the ASP 3092 Active message, in addition to all the other ASPs that are currently 3093 active in the AS. The algorithm at the SGP for broadcasting 3094 traffic within an AS to all the active ASPs is a simple broadcast 3095 algorithm, where every message is sent to each of the active ASPs. 3097 An SGP, upon reception of an ASP Active message for the first 3098 ASP in a Broadcast AS, MAY choose not to direct traffic to a newly 3099 active ASP until it determines that there are sufficient resources to 3100 handle the expected load (e.g., until there are "n" ASPs in state 3101 ASP-ACTIVE in the AS). 3103 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP 3104 MUST tag the first DATA message broadcast in each SCTP stream with a 3105 unique Correlation Id parameter. The purpose of this Correlation Id 3106 is to permit the newly active ASP to synchronize its processing of 3107 traffic in each ordered stream with the other ASPs in the broadcast 3108 group. 3110 4.3.4.5 ASP Inactive Procedures 3112 When an ASP wishes to withdraw from receiving traffic within an AS, the 3113 ASP sends an ASP Inactive message to the SGP. This action MAY be 3114 initiated at the ASP by an M-ASP_INACTIVE request primitive from 3115 Layer Management or MAY be initiated automatically by an M2UA 3116 management function. In the case where an ASP is processing the 3117 traffic for more than one Application Server across a common SCTP 3118 association, the ASP Inactive message contains one or more Interface 3119 Identifiers to indicate for which Application Servers the ASP Inactive 3120 message applies. In the case where an ASP Inactive message does not 3121 contain a Interface Identifier parameter, the receiver must know, via 3122 configuration data, which Application Servers the ASP is a member and 3123 move the ASP to the ASP-INACTIVE state in all Application Servers. 3124 In the case of an Override mode AS, where another ASP has already 3125 taken over the traffic within the AS with an ASP Active ("Override") 3126 message, the ASP that sends the ASP Inactive message is already 3127 considered by the SGP to be in state ASP-INACTIVE. An ASP Inactive 3128 Ack message is sent to the ASP, after ensuring that all traffic is 3129 stopped to the ASP. 3131 In the case of a Load-share mode AS, the SGP moves the ASP to the ASP- 3132 INACTIVE state and the AS traffic is re-allocated across the remaining 3133 ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm 3134 currently used within the AS. A Notify message ("Insufficient ASP 3135 resources active in AS") MAY be sent to all inactive ASPs, if required. 3136 An ASP Inactive Ack message is sent to the ASP after all traffic 3137 is halted and Layer Management is informed with an M-ASP_INACTIVE 3138 indication primitive. 3140 In the case of a Broadcast mode AS, the SGP moves the ASP to the 3141 ASP-INACTIVE state and the AS traffic is broadcast only to the 3142 remaining ASPs in the state ASP-ACTIVE. A Notify message 3143 ("Insufficient ASP resources active in AS") MAY be sent to all 3144 inactive ASPs, if required. An ASP Inactive Ack message is sent to 3145 the ASP after all traffic is halted and Layer Management is informed 3146 with an M-ASP_INACTIVE indication primitive. 3148 Multiple ASP Inactive Ack messages MAY be used in response to an 3149 ASP Inactive message containing multiple Interface Identifers, 3150 allowing the SGP to independently acknowledge for different (sets 3151 of) Interface Identifiers. The SGP sends an Error message ("Invalid 3152 Interface Identifier") message for each invalid or unconfigured 3153 Interface Identifer value in a received ASP Inactive message. 3155 The SGP MUST send an ASP Inactive Ack message in response to a received 3156 ASP Inactive message from the ASP and the ASP is already marked as ASP- 3157 INACTIVE at the SGP. 3159 At the ASP, the ASP Inactive Ack message received is not acknowledged. 3160 Layer Management is informed with an M-ASP_INACTIVE confirm primitive. 3161 If the ASP receives an ASP Inactive Ack without having sent an ASP 3162 Inactive message, the ASP SHOULD now consider itself as in the 3163 ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE 3164 state, the ASP SHOULD then initiate procedures to return itself to 3165 its previous state. 3167 When the ASP sends an ASP Inactive message it starts timer T(ack). 3168 If the ASP does not receive a response to an ASP Inactive message 3169 within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive 3170 messages until it receives an ASP Inactive Ack message. T(ack) is 3171 provisionable, with a default of 2 seconds. Alternatively, 3172 retransmission of ASP Inactive messages MAY be put under control of 3173 Layer Management. In this method, expiry of T(ack) results in a M- 3174 ASP_Inactive confirm primitive carrying a negative indication. 3176 If no other ASPs in the Application Server are in the state ASP-ACTIVE, 3177 the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs 3178 in the AS which are in the state ASP-INACTIVE. The SGP SHOULD start 3179 buffering the incoming messages for T(r)seconds, after which messages 3180 MAY be discarded. T(r) is configurable by the network operator. If 3181 the SGP receives an ASP Active message from an ASP in the AS before 3182 expiry of T(r), the buffered traffic is directed to that ASP and the 3183 timer is cancelled. If T(r) expires, the AS is moved to the 3184 AS-INACTIVE state. 3186 4.3.4.6 Notify Procedures 3188 A Notify message reflecting a change in the AS state MUST be sent to 3189 all ASPs in the AS, except those in the ASP-DOWN state, with 3190 appropriate Status Information and any ASP Identifier of the failed 3191 ASP. At the ASP, Layer Management is informed with an M-NOTIFY 3192 indication primitive. The Notify message MUST be sent whether the 3193 AS state change was a result of an ASP failure or reception of an 3194 ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message. 3195 In the second case, the Notify message MUST be sent after any related 3196 acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active 3197 Ack, or ASP Inactive Ack). 3199 In the case where a Notify ("AS-PENDING") message is sent by an 3200 SGP that now has no ASPs active to service the traffic, or where a 3201 Notify ("Insufficient ASP resources active in AS") message MUST be sent 3202 in the Loadshare or Broadcast mode, the Notify message does not 3203 explicitly compel the ASP(s) receiving the message to become active. 3204 The ASPs remain in control of what (and when) traffic action is taken. 3206 In the case where a Notify message does not contain a Interface 3207 Identifier parameter, the receiver must know, via configuration data, 3208 of which Application Servers the ASP is a member and take the 3209 appropriate action in each AS. 3211 4.3.4.7 Heartbeat Procedures 3213 The optional Heartbeat procedures MAY be used when operating over 3214 transport layers that do not have their own heartbeat mechanism for 3215 detecting loss of the transport association (i.e., other than SCTP). 3217 Either M2UA peer may optionally send Heartbeat messages periodically, 3218 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 3219 message, the M2UA peer MUST respond with a Heartbeat Ack message. 3221 If no Heartbeat Ack message (or any other M2UA message) is received 3222 from the M2UA peer within 2*T(beat), the remote M2UA peer is considered 3223 unavailable. Transmission of Heartbeat messages is stopped and the 3224 signalling process SHOULD attempt to re-establish communication if it 3225 is configured as the client for the disconnected M2UA peer. 3227 The Heartbeat message may optionally contain an opaque Heartbeat Data 3228 parameter that MUST be echoed back unchanged in the related Heartbeat 3229 Ack message. The sender, upon examining the contents of the returned 3230 Heartbeat Ack message, MAY choose to consider the remote M2UA peer as 3231 unavailable. The contents/format of the Heartbeat Data parameter is 3232 implementation-dependent and only of local interest to the original 3233 sender. The contents may be used, for example, to support a Heartbeat 3234 sequence algorithm (to detect missing Heartbeats), and/or a timestamp 3235 mechanism (to evaluate delays). 3237 Note: Heartbeat related events are not shown in Figure 5 "ASP state 3238 transition diagram". 3240 4.4 Link Key Management Procedures 3242 The Interface Identifier Management procedures are optional. They can 3243 be used to support automatic allocation of Signalling Terminals or 3244 Signalling Data Links [2][3]. 3246 4.4.1 Registration 3248 An ASP MAY dynamically register with an SGP as an ASP within an 3249 Application Server for individual Interface Identifier(s) using 3250 the REG REQ message. A Link Key parameter in the REG REQ specifies 3251 the parameters associated with the Link Key. 3253 The SGP examines the contents of the received Link Key parameters (SDLI 3254 and SDTI) and compares them with the currently provisioned Interface 3255 Identifiers. If the received Link Key matches an existing SGP Link Key 3256 entry, and the ASP is not currently included in the list of ASPs for 3257 the related Application Server, the SGP MAY authorize the ASP to be 3258 added to the AS. Or, if the Link Key does not currently exist and the 3259 received Link Key data is valid and unique, an SGP supporting dynamic 3260 configuration MAY authorize the creation of a new Interface Identifier 3261 and related Application Server and add the ASP to the new AS. In either 3262 case, the SGP returns a Registration Response message to the ASP, 3263 containing the same Local-LK-Identifier as provided in the initial 3264 request, a Registration Result "Successfully Registered" and the 3265 Interface Identifier. A unique method of Interface Identifier valid 3266 assignment at the SG/SGP is implementation dependent but MUST be 3267 guaranteed to be unique for each Application server or Link Key 3268 served by SGP. 3270 If the SGP determines that the received Link Key data is invalid, or 3271 contains invalid parameter values, the SGP returns a Registration 3272 Response message to the ASP, containing a Registration Result "Error 3273 - Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI" 3274 as appropriate. 3276 If the SGP determins that the Link Key parameter overlaps with an 3277 existing Link Key entry, the SGP returns a Registration Response 3278 message to the ASP, with a Registration Status of "Error - 3279 Overlapping (Non-Unique) Link Key". An incoming signalling message 3280 received at an SGP cannot match against more than one Link Key. 3282 If the SGP does not authorize the registration request, the SGP 3283 returns a REG RSP message to the ASP containing the Registration 3284 Result "Error - Permission Denied". 3286 If an SGP determines that a received Link Key does not currently 3287 exist and the SGP does not support dynamic configuration, the SGP 3288 returns a Registration Response message to the ASP, containing a 3289 Registration Result "Error - Link Key not Provisioned". 3291 If an SGP determines that a received Link Key does not currently 3292 exist and the SGP supports dynamic reconfiguration but does not have 3293 the capacity to add new Link Key and Application Server entries, the 3294 SGP returns a Registration Response message to the ASP, containing a 3295 Registration Result "Error - Insufficient Resources". 3297 An ASP MAY register multiple Link Keys at once by including a number 3298 of Link Key parameters in a single REG REQ message. The SGP MAY 3299 response to each registration request in a single REG RSP message, 3300 indicating the success or failure result for each Link Key in a 3301 separate Registration Result parameter. Alternatively, the SGP MAY 3302 respond with multiple REG RSP messages, each with one or more 3303 Registration Result parameters. The ASP uses the Local-LK-Identifier 3304 parameter to correlate the requests with the responses. 3306 4.4.2 Deregistration 3308 An ASP MAY dynamically de-register with an SGP as an ASP within an 3309 Application Server for individual Interface Identifier(s) using 3310 the DEREG REQ message. A Interface Identifier parameter in the 3311 DEREG REQ specifies which Interface Identifier to de-register. 3313 The SGP examines the contents of the received Interface Identifier 3314 parameter and validates that the ASP is currently registered in the 3315 Application Server(s) related to the included Interface 3316 Identifier(s). If validated, the ASP is de-registered as an ASP in 3317 the related Application Server. 3319 The deregistration procedure does not necessarily imply the deletion 3320 of Link Key and Application Server configuration data at the SGP. 3321 Other ASPs may continue to be associated with the Application 3322 Server, in which case the Link Key data CANNOT be deleted. If a 3323 Deregistration results in no more ASPs in an Application Server, an 3324 SGP MAY delete the Link Key data. 3326 The SGP acknowledges the de-registration requires by returning a DEREG 3327 RSP to the requesting ASP. The result of the de-registration is 3328 found in the Deregistration Result parameter, indicating success or 3329 failure with cause. 3331 An ASP MAY de-register multiple Interface Identifiers at once by 3332 including a number of Interface Identifiers in a single DEREG REQ 3333 message. The SGP MUST response to each deregistration request in a 3334 single DEREG RSP message, indicating the success or failure result 3335 for each Interface Identifier in a separate Deregistration Result 3336 parameter. 3338 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 3340 5.1 Establishment of associations between SGP and MGC examples 3342 5.1.1 Single ASP in an Application Server (1+0 sparing) 3344 This scenario shows the example M2UA message flows for the establishment 3345 of traffic between an SGP and an ASP, where only one ASP is configured 3346 within an AS (no backup). It is assumed that the SCTP association is 3347 already set-up. 3349 SGP ASP1 3350 | 3351 |<---------ASP Up----------| 3352 |--------ASP Up Ack------->| 3353 | | 3354 |<-------ASP Active--------| 3355 |------ASP Active Ack----->| 3356 | | 3357 |------NTFY(AS-ACTIVE)---->| 3359 5.1.2 Single ASP in an Application Server (1+0 sparing) with Dynamic 3360 Registration 3362 This scenario is the same as the one shown in Section 5.1.1 except 3363 with a dynamic registration (automatic allocation) of Interface 3364 Identifier(s). 3366 SGP ASP1 3367 | 3368 |<---------ASP Up----------| 3369 |--------ASP Up Ack------->| 3370 | | 3371 |<--------REG REQ----------| 3372 |------REG REQ RESP------->| 3373 | | 3374 |<-------ASP Active--------| 3375 |------ASP Active Ack----->| 3376 | | 3377 |------NTFY(AS-ACTIVE)---->| 3379 5.1.3 Two ASPs in Application Server (1+1 sparing) 3381 This scenario shows the example M2UA message flows for the establishment 3382 of traffic between an SGP and two ASPs in the same Application Server, 3383 where ASP1 is configured to be active and ASP2 to be standby in the event 3384 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 3385 act as a hot, warm, or cold standby depending on the extent to which ASP1 3386 and ASP2 share call/transaction state or can communicate call state under 3387 failure/withdrawal events. 3389 SGP ASP1 ASP2 3390 | | | 3391 |<--------ASP Up----------| | 3392 |-------ASP Up Ack------->| | 3393 | | | 3394 |<-----------------------------ASP Up----------------| 3395 |----------------------------ASP Up Ack------------->| 3396 | | | 3397 | | | 3398 |<-------ASP Active-------| | 3399 |-----ASP Active Ack----->| | 3400 | | | 3401 | | | 3402 |-----NTFY(AS-ACTIVE)---->| | 3403 | | | 3404 |------------------NTFY(AS-ACTIVE)------------------>| 3406 5.2 ASP Traffic Fail-over Examples 3408 5.2.1 (1+1 Sparing, withdrawal of ASP, backup Override) 3410 Following on from the example in Section 5.1.2, and ASP withdraws from 3411 service: 3413 SGP ASP1 ASP2 3414 | | | 3415 |<-----ASP Inactive-------| | 3416 |----ASP Inactive Ack---->| | 3417 | | | 3418 |------------------NTFY(AS-PENDING)----------------->| 3419 | | | 3420 |<------------------------------ ASP Active----------| 3421 |-----------------------------ASP Active Ack-------->| 3422 | | | 3423 |------------------NTFY(AS-ACTIVE)------------------>| 3424 | | | 3426 In this case, the SGP notifies ASP2 that the AS has moved to the 3427 AS-PENDING state. ASP2 sends ASP Active to bring the AS back to 3428 the AS-ACTIVE state. If ASP2 did not send the ASP Active message 3429 before T(r) expired, the SGP would send a NOTIFY (AS-DOWN). 3431 Note: If the SGP detects loss of the M2UA peer (through a detection 3432 of SCTP failure), the initial SGP-ASP1 ASP Inactive message exchange 3433 would not occur. 3435 SGP ASP1 ASP2 3436 | | | 3437 (detects SCTP failure) 3438 |------------------NTFY(AS-PENDING)----------------->| 3439 | | | 3440 |<------------------------------ ASP Active----------| 3441 |-----------------------------ASP Active Ack-------->| 3442 | | | 3443 |------------------NTFY(AS-ACTIVE)------------------>| 3444 | | | 3446 5.2.2 (1+1 Sparing, backup Override) 3448 Following on from the example in Section 5.1.2, and ASP2 wishes to 3449 override ASP1 and take over the traffic: 3451 SGP ASP1 ASP2 3452 | | | 3453 |<-------------------------------ASP Active----------| 3454 |-----------------------------ASP Active Ack-------->| 3455 |----NTFY(Alt ASP-Act)--->| | 3456 | | | 3458 In this case, the SGP notifies ASP1 that an alternative ASP has 3459 overridden it. 3461 5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 3463 When the M2UA layer on the ASP has a MAUP message to send to the SGP, it 3464 will do the following: 3466 - Determine the correct SGP 3468 - Find the SCTP association to the chosen SGP 3470 - Determine the correct stream in the SCTP association based on 3471 the SS7 link 3473 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3474 Common Header 3476 - Send the MAUP message to the remote M2UA peer in the SGP, over the 3477 SCTP association 3479 When the M2UA layer on the SGP has a MAUP message to send to the ASP, it 3480 will do the following: 3482 - Determine the AS for the Interface Identifier 3484 - Determine the Active ASP (SCTP association) within the AS 3486 - Determine the correct stream in the SCTP association based on 3487 the SS7 link 3489 - Fill in the MAUP message, fill in M2UA Message Header, fill in 3490 Common Header 3492 - Send the MAUP message to the remote M2UA peer in the ASP, over the 3493 SCTP association 3495 5.3.1 SS7 Link Alignment 3497 The MGC can request that a SS7 link be brought into alignment using the 3498 normal or emergency procedure [2][3]. An example of the message flow 3499 to bring a SS7 link in-service using the normal alignment procedure is 3500 shown below. 3502 MTP2 M2UA M2UA MTP3 3503 SGP SGP ASP ASP 3505 <----Start Req---|<---Establish Req----|<----Start Req------ 3507 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 3509 An example of the message flow to bring a SS7 link in-service using the 3510 emergency alignment procedure. 3512 MTP2 M2UA M2UA MTP3 3513 SGP SGP ASP ASP 3515 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 3517 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 3519 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 3521 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 3523 5.3.2 SS7 Link Release 3525 The MGC can request that a SS7 link be taken out-of-service. It uses 3526 the Release Request message as shown below. 3528 MTP2 M2UA M2UA MTP3 3529 SGP SGP ASP ASP 3531 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 3533 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 3535 The SGP can autonomously indicate that a SS7 link has gone out-of- 3536 service as shown below. 3538 MTP2 M2UA M2UA MTP3 3539 SGP SGP ASP ASP 3541 --Out of Serv->|----Release Ind----->|--Out of Serv--> 3543 5.3.3 Set and Clear Local Processor Outage 3545 The MGC can set a Local Processor Outage condition. It uses the 3546 State Request message as shown below. 3548 MTP2 M2UA M2UA MTP3 3549 SGP SGP ASP ASP 3551 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 3553 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 3555 The MGC can clear a Local Processor Outage condition. It uses the 3556 State Request message as shown below. 3558 MTP2 M2UA M2UA MTP3 3559 SGP SGP ASP ASP 3561 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 3563 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 3565 5.3.4 Notification of Remote Processor Outage 3567 The SGP can indicate Remote has entered or exited the Processor Outage 3568 condition for a SS7 link. It uses the State Indication message as shown 3569 below. 3571 MTP2 M2UA M2UA MTP3 3572 SGP SGP ASP ASP 3574 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 3576 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 3578 5.3.5 Notification of SS7 Link Congestion 3580 The SGP can indicate that a SS7 link has become congested. It uses the 3581 Congestion Indication message as shown below. 3583 MTP2 M2UA M2UA MTP3 3584 SGP SGP ASP ASP 3586 ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> 3588 -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> 3590 5.3.6 SS7 Link Changeover 3592 An example of the message flow for an error free changeover is shown 3593 below. In this example, there were three messages in the retransmission 3594 queue that needed to be retrieved. 3596 MTP2 M2UA M2UA MTP3 3597 SGP SGP ASP ASP 3599 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3600 (seq_num = 0) 3602 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3603 (seq_num = BSN) 3605 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3606 (seq_num = FSN) 3608 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3609 (seq_num = 0) 3611 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3612 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3613 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 3615 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 3617 Note: The number of Retrieval Indication is dependent on the number of 3618 messages in the retransmit queue that have been requested. Only one 3619 Retrieval Complete Indication SHOULD be sent. 3621 An example of a message flow with an error retrieving the BSN is shown 3622 below. 3624 MTP2 M2UA M2UA MTP3 3625 SGP SGP ASP ASP 3627 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3629 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 3630 (seq_num = -1) 3632 An example of a message flow with an error retrieving the messages is 3633 shown below. 3635 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 3637 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 3638 (seq_num = BSN) 3640 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 3641 (seq_num = FSN) 3643 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 3644 (seq_num = -1) 3646 An example of a message flow for a request to drop messages (clear 3647 retransmission buffers) is shown below. 3649 MTP2 M2UA M2UA MTP3 3650 SGP SGP ASP ASP 3652 -Clr RTB Req----|<-StateReq (STATUS_CLEAR_RTB)--|<--Clr RTB Req----- 3654 -Clr RTB Req--->|-StateCfm (STATUS_CLEAR_RTB)-->|---Clr RTB Req----> 3656 5.3.7 Flush and Continue 3658 The following message flow shows a request to flush buffers. 3660 MTP2 M2UA M2UA MTP3 3661 SGP SGP ASP ASP 3663 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 3665 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 3667 The following message flow shows a request to continue. 3669 MTP2 M2UA M2UA MTP3 3670 SGP SGP ASP ASP 3672 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 3674 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 3676 5.3.8 Auditing of SS7 link state 3678 It may be necessary for the ASP to audit the current state of a SS7 link. 3679 The flows below show an example of the request and all the potential 3680 responses. 3682 Below is an example in which the SS7 link is out-of-service. 3684 MTP2 M2UA M2UA MGMT 3685 SGP SGP ASP ASP 3687 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3689 MTP3 3690 ASP 3692 |-----------Release Ind---------->|-Out of Serv Ind-> 3694 MGMT 3695 ASP 3697 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3699 Below is an example in which the SS7 link is in-service. 3701 MTP2 M2UA M2UA MGMT 3702 SGP SGP ASP ASP 3704 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3706 MTP3 3707 ASP 3709 |-----------Establish Cfm-------->|---In Serv Ind--> 3711 MGMT 3712 ASP 3714 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3716 Below is an example in which the SS7 link is in-service, but congested. 3718 MTP2 M2UA M2UA MGMT 3719 SGP SGP ASP ASP 3721 |<----State Req (STATUS_AUDIT)----|<----Audit------- 3723 MTP3 3724 ASP 3726 |-----------Establish Cfm-------->|---In Serv Ind--> 3728 |----------Congestion Ind-------->|---Cong Ind-----> 3730 MGMT 3731 ASP 3733 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3735 Below is an example in which the SS7 link is in-service, but in Remote 3736 Processor Outage. 3738 MTP2 M2UA M2UA MGMT 3739 SGP SGP ASP ASP 3741 |<----State Req (STATUS_AUDIT)----|<---Audit Req---- 3743 MTP3 3744 ASP 3746 |-----------Establish Ind-------->|---In Serv Ind--> 3748 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter---> 3750 MGMT 3751 ASP 3753 |-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm---> 3755 6.0 Timer Values 3757 The recommended default values for M2UA timers are: 3759 T(r) 2 seconds 3760 T(ack) 2 seconds 3761 T(beat) Heartbeat Timer 30 seconds 3763 7.0 Security Considerations 3765 M2UA is designed to carry signalling messages for telephony services. 3766 As such, M2UA MUST involve the security needs of several parties: the 3767 end users of the services; the network providers and the applications 3768 involved. Additional requirements MAY come from local regulation. 3769 While having some overlapping security needs, any security solution 3770 SHOULD fulfill all of the different parties' needs. 3772 7.1 Threats 3774 There is no quick fix, one-size-fits-all solution for security. As a 3775 transport protocol, M2UA has the following security objectives: 3777 * Availability of reliable and timely user data transport. 3778 * Integrity of user data transport. 3779 * Confidentiality of user data. 3781 M2UA runs on top of SCTP. SCTP [8] provides certain transport related 3782 security features, such as: 3784 * Blind Denial of Service Attacks 3785 * Flooding 3786 * Masquerade 3787 * Improper Monopolization of Services 3789 When M2UA is running in professionally managed corporate or service 3790 provider network, it is reasonable to expect that this network includes 3791 an appropriate security policy framework. The "Site Security Handbook" 3792 [13] SHOULD be consulted for guidance. 3794 When the network in which M2UA runs in involves more than one party, it 3795 MAY NOT be reasonable to expect that all parties have implemented 3796 security in a sufficient manner. In such a case, it is recommended that 3797 IPSEC is used to ensure confidentiality of user payload. Consult [14] 3798 for more information on configuring IPSEC services. 3800 7.2 Protecting Confidentiality 3802 Particularly for mobile users, the requirement for confidentiality MAY 3803 include the masking of IP addresses and ports. In this case application 3804 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 3805 Regardless of which level performs the encryption, the IPSEC ISAKMP 3806 service SHOULD be used for key management. 3808 8.0 IANA Considerations 3810 8.1 SCTP Payload Protocol Identifier 3812 A request will be made to IANA to assign an M2UA value for the Payload 3813 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 3814 Payload Protocol Identifier has been registered: 3816 M2UA "2" 3818 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 3819 to indicate which protocol the SCTP is carrying. This Payload Protocol 3820 Identifier is not directly used by SCTP but MAY be used by certain 3821 network entities to identify the type of information being carried in a 3822 Data chunk. 3824 The User Adaptation peer MAY use the Payload Protocol Identifier as a 3825 way of determining additional information about the data being presented 3826 to it by SCTP. 3828 8.2 M2UA Protocol Extensions 3830 This protocol may also be extended through IANA in three ways: 3832 -- through definition of additional message classes, 3833 -- through definition of additional message types, and 3834 -- through definition of additional message parameters. 3836 The definition and use of new message classes, types and parameters is 3837 an integral part of SIGTRAN adaptation layers. Thus, these extensions 3838 are assigned by IANA through an IETF Consensus action as defined in 3839 [RFC2434]. 3841 The proposed extension must in no way adversely affect the general 3842 working of the protocol. 3844 8.2.1 IETF Defined Message Classes 3846 The documentation for a new message class MUST include the following 3847 information: 3849 (a) A long and short name for the message class. 3850 (b) A detailed description of the purpose of the message class. 3852 8.2.2 IETF Defined Message Types 3854 Documentation of the message type MUST contain the following 3855 information: 3857 (a) A long and short name for the new message type. 3858 (b) A detailed description of the structure of the message. 3859 (c) A detailed definition and description of intended use of each field 3860 within the message. 3861 (d) A detailed procedural description of the use of the new message 3862 type within the operation of the protocol. 3863 (e) A detailed description of error conditions when receiving this 3864 message type. 3866 When an implementation receives a message type which it does not support, 3867 it MUST respond with an Error (ERR) message with an Error Code of 3868 Unsupported Message Type. 3870 8.2.3 IETF-defined TLV Parameter Extension 3872 Documentation of the message parameter MUST contain the following 3873 information: 3875 (a) Name of the parameter type. 3876 (b) Detailed description of the structure of the parameter field. This 3877 structure MUST conform to the general type-length-value format 3878 described in Section 3.1.5. 3879 (c) Detailed definition of each component of the parameter value. 3880 (d) Detailed description of the intended use of this parameter type, 3881 and an indication of whether and under what circumstances 3882 multiple instances of this parameter type may be found within the 3883 same message type. 3885 9.0 Acknowledgements 3887 The authors would like to thank John Loughney, Neil Olson, Michael 3888 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 3889 Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark 3890 Kobine, Nitin Tomar, Harsh Bhondwe and Karen King for their valuable 3891 comments and suggestions. 3893 10.0 References 3895 10.1 Normative 3897 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 3898 System No. 7 (SS7)' 3900 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 3901 Message Transfer Part (MTP)' 3903 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 3905 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 3906 of Signalling System Number 7', Volume 1, December 1995 3908 [5] Telecommunication Technology Committee (TTC) Standard JT-Q704, 3909 Message Transfer Part Signaling Network Functions, 3910 April 28, 1992. 3912 [6] UTF-8, a transformation format of ISO 10646, RFC 2279, January 3913 1998 3915 [7] Coded Character Set--7-Bit American Standard Code for 3916 Information Interchange, ANSI X3.4-1986. 3918 10.2 Informative 3920 [8] Stream Control Transmission Protocol, RFC 2960, October 2000 3922 [9] Architectural Framework for Signalling Transport, RFC 2719, 3923 October 1999 3925 [10] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', 3926 February 1995 3928 [11] ITU-T Recommendation Q.2210, 'Message transfer part level 3 3929 functions and messages using the services of ITU-T 3930 Recommendation Q.2140', August 1995 3932 [12] ITU-T Recommendation Q.751.1, 'Network Element Management 3933 Information Model for the Message Transfer Part', October 1995 3935 [13] Site Security Handbook, RFC 2196, September 1997 3937 [14] Security Architecture for the Internet Protocol, RFC 2401 3938 11.0 Author's Addresses 3940 Ken Morneault Tel: +1-703-484-3323 3941 Cisco Systems Inc. EMail: kmorneau@cisco.com 3942 13615 Dulles Technology Drive 3943 Herndon, VA. 20171 3944 USA 3946 Ram Dantu, Ph.D. Tel +1-214-291-1111 3947 NetRake Corporation EMail rdantu@netrake.com 3948 3000 Technology Drive 3949 Plano, TX 75074 3950 USA 3952 Greg Sidebottom EMail: gregside@home.com 3953 gregside consulting 3954 Kanata, Ontario 3955 Canada 3957 Tom George Tel: +1-972-519-3168 3958 Alcatel USA EMail: tom.george@usa.alcatel.com 3959 1000 Coit Road 3960 Plano, TX 74075 3961 USA 3963 Brian Bidulock Tel +1-972-839-4489 3964 OpenSS7 Project EMail: bidulock@openss7.org 3965 c/o #424, 4701 Preston Park Blvd. 3966 Plano, TX 75093 3967 USA 3969 Jacob Heitz Tek +1-510-747-2917 3970 Lucent Technologies Email: jheitz@lucent.com 3971 1701 Harbor Bay Parkway 3972 Alameda, CA, 94502 3973 USA 3974 Appendix A: Signalling Network Architecture 3976 A Signalling Gateway will support the transport of MTP2-User signalling 3977 traffic received from the SS7 network to one or more distributed ASPs 3978 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 3979 meet any performance and reliability requirements for such transport. 3980 A physical network architecture is required, with data on the 3981 availability and transfer performance of the physical nodes involved in 3982 any particular exchange of information. However, the M2UA protocol is 3983 flexible enough allow its operation and management in a variety of 3984 physical configurations that will enable Network Operators to meet 3985 their performance and reliability requirements. 3987 To meet the stringent SS7 signalling reliability and performance 3988 requirements for carrier grade networks, these Network Operators should 3989 ensure that there is no single point of failure provisioned in the end- 3990 to-end network architecture between an SS7 node and an IP ASP. 3992 Depending of course on the reliability of the SGP and ASP functional 3993 elements, this can typically be met by the spreading SS7 links in a 3994 SS7 linkset [1] across SGPs or SGs, the provision of redundant 3995 QoS-bounded IP network paths for SCTP Associations between SCTP End 3996 Points, and redundant Hosts. The distribution of ASPs within the 3997 available Hosts is also important. For a particular Application 3998 Server, the related ASPs MAY be distributed over at least two Hosts. 4000 An example logical network architecture relevant to carrier-grade 4001 operation in the IP network domain is shown in Figure 7 below: 4003 ************** ************** 4004 * ********__*______________________________*__******** * Host1 4005 SG1 * * SGP1 *__*________________ _______*__* ASP1 * * 4006 * ******** * | | * ******** * 4007 * . * | | * * 4008 * . * | | ************** 4009 ************** | | 4010 | | 4011 ************** | | 4012 * ********__*______________________| 4013 SG2 * * SGP2 *__*________ | 4014 * ******** * | | 4015 * . * | | 4016 * . * | | 4017 ************** | | ************** 4018 | |_____________*__******** * Host2 4019 |_____________________*__* ASP2 * * 4020 . * ******** * 4021 . SCTP Associations * * 4022 . ************** 4023 . 4024 . 4025 . 4027 Figure 7: Logical Model Example 4029 To avoid a single point of failure, it is recommended that a minimum 4030 of two ASPs be configured in an AS list, resident in separate hosts 4031 and, therefore, available over different SCTP associations. For 4032 example, in the network shown in Figure 7, all messages for the 4033 Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in 4034 Host2. The AS list at SGP1 might look like the following: 4036 Interface Identifiers - Application Server #1 4037 ASP1/Host1 - State = Active 4038 ASP2/Host2 - State = Inactive 4040 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 4041 message for the Interface Identifiers registered. ASP2 in Host2 would 4042 normally be brought to the active state upon failure of ASP1/Host1. 4043 In this example, both ASPs are Inactive or Active, meaning that the 4044 related SCTP association and far-end M2UA peer is ready. 4046 For carrier grade networks, Operators should ensure that under failure 4047 or isolation of a particular ASP, stable calls or transactions are not 4048 lost. This implies that ASPs need, in some cases, to share the call/- 4049 transaction state or be able to pass the call/transaction state between 4050 each other. Also, in the case of ASPs performing call processing, 4051 coordination MAY be required with the related Media Gateway to transfer 4052 the MGC control for a particular trunk termination. However, this 4053 sharing or communication is outside the scope of this document.