idnits 2.17.1 draft-ietf-sigtran-m2ua-06.txt: -(2335): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 19) being 455 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 21: '... that other groups MAY also distribute...' RFC 2119 keyword, line 25: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 89: '...mechanism SHOULD meet the following cr...' RFC 2119 keyword, line 146: '...ver Process. Fail-back MAY apply upon...' RFC 2119 keyword, line 223: '...Note: STPs MAY be present in the SS7 p...' (80 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 352 has weird spacing: '...e hosts and t...' == Line 2048 has weird spacing: '...ges and disca...' == Line 2254 has weird spacing: '...PIA Ack messa...' -- 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 [10] for more information on configuring IPSEC services. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 2000) is 8561 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 688 -- Looks like a reference, but probably isn't: 'M3UA' on line 730 -- Looks like a reference, but probably isn't: 'IUA' on line 735 -- Looks like a reference, but probably isn't: 'M2UA' on line 736 -- Looks like a reference, but probably isn't: 'SUA' on line 738 -- Looks like a reference, but probably isn't: 'RFC2434' on line 2683 == Unused Reference: '1' is defined on line 2737, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2756, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '9') ** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC 4301) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Ram Dantu 3 Cisco Systems 4 Mallesh Kalla 5 Telcordia 6 Greg Sidebottom 7 Nortel Networks 8 Tom George 9 Alcatel 11 Expires in six months Nov 2000 13 SS7 MTP2-User Adaptation Layer 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC 2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups MAY also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and MAY be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as 'work in progress'. 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To learn the current status of any Internet-Draft, please check the 36 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 37 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 38 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 Abstract 43 This Internet Draft defines a protocol for backhauling of SS7 MTP2 44 User signaling messages over IP using the Stream Control 45 Transmission Protocol (SCTP). This protocol would be used between a 46 Signaling Gateway (SG) and Media Gateway Controller (MGC). It is 47 assumed that the SG receives SS7 signaling over a standard SS7 48 interface using the SS7 Message Transfer Part (MTP) to provide 49 transport. The Signaling Gateway would act as a Signaling Link 50 Terminal. 52 TABLE OF CONTENTS 54 1. Introduction..............................................2 55 1.1 Scope..................................................2 56 1.2 Terminology............................................3 57 1.3 Signaling Transport Architecture.......................3 58 1.4 Services Provide by the M2UA Adaptation Layer..........6 59 1.5 Function Provided by the M2UA Layer....................8 60 1.6 Definition of the M2UA Boundaries......................9 61 2. Conventions...............................................9 62 3. Protocol Elements.........................................9 63 3.1 Common Message Header.................................10 64 3.2 M2UA Message Header...................................11 65 3.3 M2UA Messages.........................................11 66 4. Procedures...............................................20 67 4.1 Procedures to Support Service in Section 1.4.1........20 68 4.2 Procedures to Support Service in Section 1.4.2........21 69 4.3 Procedures to Support Service in Section 1.4.3........21 70 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 71 5.1 Establishment of associations between SG and MGC......26 72 examples 73 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 74 5.3 Layer Management Communication Examples...............29 75 6. Security.................................................30 76 7. IANA Considerations......................................31 77 7.1 SCTP Payload Protocol Identifier.......................31 78 7.2 IUA Protocol Extensions................................31 79 8. Acknowledgements.........................................31 80 9. References...............................................32 81 10. Author's Addresses.......................................33 82 1. Introduction 84 1.1 Scope 86 There is a need for Switched Circuit Network SCN signaling protocol 87 delivery from an Signaling Gateway (SG) to a Media Gateway 88 Controller (MGC) or IP Signaling Point (IPSP). The delivery 89 mechanism SHOULD meet the following criteria: 91 * Support for MTP Level 2 / MTP Level 3 interface boundary 92 * Support for communication between Layer Management modules on SG 93 and MGC 94 * Support for management of active associations between the SG and MGC 96 In other words, the Signaling Gateway will transport MTP Level 3 97 messages to a Media Gateway Controller (MGC) or IP Signaling Point 98 (IPSP). In the case of delivery from an SG to an IPSP, both the SG and 99 IPSP function as traditional SS7 nodes using the IP network as a new 100 type of SS7 link. This allows for full MTP Level 3 message handling 101 and network management capabilities. 103 1.2 Terminology 105 MTP2-User - A protocol that normally uses the services of MTP Level 2 106 (i.e. MTP3). 108 Interface - For the purposes of this document, an interface is a SS7 109 signaling link. 111 Backhaul - Refers to the transport of signaling from the point of 112 interface for the associated data stream (i.e., SG function in the MGU) 113 back to the point of call processing (i.e., the MGCU), if this is not 114 local [4]. 116 Association - An association refers to a SCTP association. The 117 association will provide the transport for the delivery of protocol 118 data units for one or more interfaces. 120 Stream - A stream refers to an SCTP stream; a uni-directional logical 121 channel established from one SCTP endpoint to another associated SCTP 122 endpoint, within which all user messages are delivered in-sequence 123 except for those submitted to the un-ordered delivery service. 125 Interface Identifier - The Interface Identifier identifies the physical 126 interface at the SG for which the signaling messages are sent/received. 127 The format of the Interface Identifier parameter can be text or integer, 128 the values of which are assigned according to network operator policy. 129 The values used are of local significance only, coordinated between the 130 SG and ASP. 132 Application Server (AS) - A logical entity serving a specific application 133 instance. An example of an Application Server is a MGC handling the 134 MTP Level 3 and call processing for SS7 links terminated by the 135 Signaling Gateways. Practically speaking, an AS is modeled at the SG 136 as an ordered list of one or more related Application Server Processes 137 (e.g., primary, secondary, tertiary, ...). 139 Application Server Process (ASP) - A process instance of an Application 140 Server. Examples of Application Server Processes are primary or backup 141 MGC instances. 143 Fail-over - The capability to re-route signaling traffic as required 144 to an alternate Application Server Process, or group of ASPs, within 145 an Application Server in the event of failure or unavailability of a 146 currently used Application Server Process. Fail-back MAY apply upon 147 the return to service of a previously unavailable Application Server 148 Process. 150 Signaling Link Terminal (SLT) - Refers to the means of performing all 151 of the functions defined at MTP level 2 regardless of their 152 implementation [2]. 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 Network Byte Order: Most significant byte first, a.k.a Big Endian. 160 Host - The computing platform that the ASP process is running on. 162 1.3 M2UA Overview 164 The framework architecture that has been defined for SCN signaling 165 transport over IP [6] uses multiple components, including a signaling 166 common transport protocol and an adaptation module to support the 167 services expected by a particular SCN signaling protocol from its 168 underlying protocol layer. 170 Within this framework architecture, this document defines a SCN 171 adaptation module that is suitable for the transport of SS7 MTP2 User 172 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 173 of the Stream Control Transmission Protocol [5] as the underlying 174 reliable signaling common transport protocol. 176 In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling 177 is transmitted and received from the PSTN over a standard SS7 network 178 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 179 to provide reliable transport of the MTP3-User signaling messages to and 180 from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). 181 The SG then provides a functional inter-working of transport functions 182 with the IP transport, in order to transfer the MTP2-User signaling 183 messages to and from an Application Server Process where the peer MTP2- 184 User protocol layer exists. 186 1.3.1 Example - SG to MGC 188 In a Signaling Gateway, it is expected that the SS7 signaling is 189 received over a standard SS7 network termination, using the SS7 Message 190 Transfer Part (MTP) to provide transport of SS7 signaling messages to 191 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 192 Point (STP). In other words, the SG acts as a Signaling Link Terminal 193 (SLT) [2]. The SG then provides interworking of transport functions 194 with IP Signaling Transport, in order to transport the MTP3 signaling 195 messages to the MGC where the peer MTP3 protocol layer exists, as shown 196 below: 198 ****** SS7 ****** IP ******* 199 *SEP *-----------* SG *-------------* MGC * 200 ****** ****** ******* 202 +----+ +----+ 203 |S7UP| |S7UP| 204 +----+ +----+ 205 |MTP + |MTP | 206 | L3 | (NIF) |L3 | 207 +----+ +----+----+ +----+ 208 |MTP | |MTP |M2UA| |M2UA| 209 | | | +----+ +----+ 210 |L2 | |L2 |SCTP| |SCTP| 211 |L1 | |L1 +----+ +----+ 212 | | | |IP | |IP | 213 +----+ +---------+ +----+ 215 NIF - Nodal Interworking Function 216 SEP - SS7 Signaling Endpoint 217 IP - Internet Protocol 218 SCTP - Stream Control Transmission Protocol 219 (Refer to Reference [5]) 221 Figure 1 M2UA in the SG to MGC Application 223 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 225 It is recommended that the M2UA use the services of the Stream 226 Control Transmission Protocol (SCTP) as the underlying reliable 227 common signaling transport protocol. The use of SCTP provides 228 the following features: 230 - explicit packet-oriented delivery (not stream-oriented) 231 - sequenced delivery of user messages within multiple streams, 232 with an option for order-of-arrival delivery of individual 233 user messages, 234 - optional multiplexing of user messages into SCTP datagrams, 235 - network-level fault tolerance through support of multi-homing 236 at either or both ends of an association, 237 - resistance to flooding and masquerade attacks, and 238 - data segmentation to conform to discovered path MTU size 240 There are scenarios without redundancy requirements and 241 scenarios in which redundancy is supported below the transport 242 layer. In these cases, the SCTP functions above MAY NOT be a 243 requirement and TCP can be used as the underlying common 244 transport protocol. 246 1.3.2 Support for the management of SCTP associations between the SG 247 and ASPs 249 The M2UA layer at the SG maintains the availability state of all 250 dynamically registered remote ASPs, in order to manage the SCTP 251 Associations and the traffic between the SG and ASPs. As well, the 252 active/inactive state of remote ASP(s) are also maintained. Active 253 ASPs are those currently receiving traffic from the SG. 255 The M2UA layer MAY be instructed by local management to establish an 256 SCTP association to a peer M2UA node. This can be achieved using the M- 257 SCTP ESTABLISH primitive to request, indicate and confirm the 258 establishment of an SCTP association with a peer M2UA node. 260 The M2UA layer MAY also need to inform local management of the status of 261 the underlying SCTP associations using the M-SCTP STATUS request and 262 indication primitive. For example, the M2UA MAY inform local management 263 of the reason for the release of an SCTP association, determined either 264 locally within the M2UA layer or by a primitive from the SCTP. 266 1.3.3 Signaling Network Architecture 268 A Signaling Gateway will support the transport of MTP2-User signaling 269 traffic received from the SS7 network to one or more distributed ASPs 270 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 271 meet any performance and reliability requirements for such transport. 272 A physical network architecture is required, with data on the 273 availability and transfer performance of the physical nodes involved in 274 any particular exchange of information. However, the M2UA protocol MUST 275 be flexible enough allow its operation and management in a variety of 276 physical configurations that will enable Network Operators to meet 277 their performance and reliability requirements. 279 To meet the stringent SS7 signaling reliability and performance 280 requirements for carrier grade networks, these Network Operators SHOULD 281 ensure that there is no single point of failure provisioned in the end- 282 to-end network architecture between an SS7 node and an IP ASP. 284 Depending of course on the reliability of the SG and ASP functional 285 elements, this can typically be met by the spreading links in a linkset 286 across SGs, the provision of redundant QOS-bounded IP network paths for 287 SCTP Associations between SCTP End Points, and redundant Hosts. The 288 distribution of ASPs within the available Hosts is also important. For a 289 particular Application Server, the related ASPs SHOULD be distributed over 290 at least two Hosts. 292 An example logical network architecture relevant to carrier-grade 293 operation in the IP network domain is shown in Figure 2 below: 295 ******** ************** 296 * *_________________________________________* ******** * Host1 297 * * _________* * ASP1 * * 298 * SG1 * SCTP Associations | * ******** * 299 * *_______________________ | * * 300 ******** | | ************** 301 | | 302 ******** | | 303 * *_______________________________| 304 * * | 305 * SG2 * SCTP Associations | 306 * *____________ | 307 * * | | 308 ******** | | ************** 309 | |_________________* ******** * Host2 310 |____________________________* * ASP1 * * 311 * ******** * 312 * * 313 ************** 314 . 315 . 316 . 318 Figure 2 - Logical Model Example 320 For carrier grade networks, Operators SHOULD ensure that under failure 321 or isolation of a particular ASP, stable calls or transactions are not 322 lost. This implies that ASPs need, in some cases, to share the call/- 323 transaction state or be able to pass the call/transaction state between 324 each other. Also, in the case of ASPs performing call processing, 325 coordination MAY be required with the related Media Gateway to transfer 326 the MGC control for a particular trunk termination. However, this 327 sharing or communication is outside the scope of this document. 329 1.3.4 ASP Fail-over Model and Terminology 331 The M2UA layer supports ASP fail-over functions in order to support a 332 high availability of call and transaction processing capability. All 333 MTP2-User messages incoming to an SG from the SS7 network are assigned 334 to a unique Application Server, based on the Interface Identifier of 335 the message. 337 The Application Server is in practical terms a list of all ASPs currently 338 registered to process MTP2-User messages from certain Interface 339 Identifiers. One or more ASPs in the list are normally active (i.e., 340 handling traffic) while any others MAY be unavailable or inactive, to be 341 possibly used in the event of failure or unavailability of the active 342 ASP(s). 344 The fail-over model supports an n+k redundancy model, where n ASPs 345 is the minimum number of redundant ASPs required to handle traffic and 346 k ASPs are available to take over for a failed or unavailable ASP. 347 Note that 1+1 active/standby redundancy is a subset of this model. 348 A simplex 1+0 model is also supported as a subset, with no ASP 349 redundancy. 351 To avoid a single point of failure, it is recommended that a minimum of 352 two ASPs be in the list, resident in separate hosts and therefore 353 available over different SCTP Associations. For example, in the 354 network shown in Figure 2, all messages for the Interface Identifiers 355 could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1 356 might look like the following: 358 Interface Identiers - Application Server #1 359 ASP1/Host1 - State = Active 360 ASP1/Host2 - State = Inactive 362 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 363 message for the Interface Identifiers registered. ASP1 in Host2 would 364 normally be brought to the active state upon failure of, or loss of 365 connectivity to, ASP1/Host1. In this example, both ASPs are Inactive 366 or Active, meaning that the related SCTP association and far-end M2UA 367 peer is ready. 369 The two ASPs MAY share state information via shared memory, or MAY 370 use an ASP to ASP protocol to pass state information. The ASP to ASP 371 protocol is outside the scope of this document. 373 1.3.5 Client/Server Model 375 It is recommended that the SG and ASP be able to support both client 376 and server operation. The peer endpoints using M2UA SHOULD be 377 configured so that one always takes on the role of client and the 378 other the role of server for initiating SCTP associations. The 379 default orientation would be for the SG to take on the role of server 380 while the ASP is the client. In this case, ASPs SHOULD initiate the 381 SCTP association to the SG. 383 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA 384 is 2904. 386 1.4 Services Provided by the M2UA Adaptation Layer 388 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 389 point in the IP network, so that the M2UA protocol layer is required to 390 provide the equivalent set of services to its users as provided by the 391 MTP Level 2 to MTP Level 3. 393 This includes the following services: 395 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 397 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 398 a seamless, or as seamless as possible, operation of the MTP2-User peers 399 in the SS7 and IP domains. An example of the primitives that must be 400 supported can be found in [7]. 402 1.4.2 Support for communication between Layer Management modules 403 on SG and MGC 405 It is envisioned that the M2UA layer needs to provide some messages that 406 will facilitate communication between Layer Management modules on the SG 407 and MGC. These primitives are shown below: 409 To facilitate reporting of errors that arise because of backhauling MTP 410 Level 3 scenario, the following primitive is defined: 412 M-ERROR 414 The M-ERROR message is used to indicate an error with a received 415 M2UA message (e.g., interface identifier value is not known to the SG). 417 1.4.3 Support for management of active associations between SG and MGC 419 The M2UA layer on the SG keeps the state of various ASPs it is associated 420 with. A set of primitives between M2UA layer and the Layer Management 421 are defined below to help the Layer Management manage the association(s) 422 between the SG and the MGC. The M2UA layer can be instructed 423 by the Layer Management to establish a SCTP association to a peer M2UA 424 node. This procedure can be achieved using the M-SCTP ESTABLISH 425 primitive. 427 M-SCTP ESTABLISH 429 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 430 the establishment of a SCTP association to a peer M2UA node. 432 M-SCTP RELEASE 434 The M-SCTP RELEASE primitives are used to request, indicate, and 435 confirm the release of a SCTP association to a peer M2UA node. 437 The M2UA layer MAY also need to inform the status of the SCTP 438 association(s) to the Layer Management. This can be achieved using 439 the following primitive. 441 M-SCTP STATUS 443 The M-SCTP STATUS primitive is used to request and indicate the status 444 of underlying SCTP association(s). 446 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 447 status (i.e., failure, active, etc.), so that messages can be exchanged 448 between M2UA layer peers to stop traffic to the local M2UA user. This 449 can be achieved using the following primitive. 451 M-ASP STATUS 453 The ASP status is stored inside M2UA layer on both the SG and MGC 454 sides. The M-ASP STATUS primitive can be used by Layer Management to 455 request the status of the Application Server Process from the M2UA 456 layer. This primitive can also be used to indicate the status of the 457 Application Server Process. 459 M-ASP MODIFY 461 The M-ASP MODIFY primitive can be used by Layer Management to modify 462 the status of the Application Server Process. In other words, the 463 Layer Management on the ASP side uses this primitive to initiate 464 the ASPM procedures. 466 M-AS STATUS 468 The M-AS STATUS primitive can be used by Layer Management to request 469 the status of the Application Server. This primitive can also be 470 used to indicate the status of the Application Server. 472 1.5 Functions Provided by the M2UA Layer 474 1.5.1 Mapping 476 The M2UA layer MUST maintain a map of a Interface ID to a physical 477 interface on the Signaling Gateway. A physical interface would be a 478 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 479 MUST also maintain a map of Interface Identifier to SCTP association 480 and to the related stream within the association. 482 The SG maps an Interface Identifier to an SCTP association/stream 483 only when an ASP sends an ASP Active message for a particular Interface 484 Identifier. It MUST be noted, however, that this mapping is dynamic 485 and could change at any time due to a change of ASP state. This mapping 486 could even temporarily be invalid, for example during failover of one 487 ASP to another. Therefore, the SG MUST maintain the states of AS/ASP 488 and reference them during the routing of an messages to an AS/ASP. 490 An example of the logical view of relationship between SS7 link, 491 Interface Identifier, AS and ASP in the SG is shown below: 493 /---------------------------------------------------+ 494 / /------------------------------------------------|--+ 495 / / v | 496 / / +----+ act+-----+ +-------+ -+--+-|+--+- 497 SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v 498 / +----+ | +----+ | +-----+ +-------+ -+--+--+--+- 499 / +->| AS |--+ Streams 500 / +----+ | +----+ stb+-----+ 501 SS7 link2-------->|IID |-+ | ASP | 502 +----+ +-----+ 504 where IID = Interface Identifier 506 Note that an ASP can be in more than one AS. 508 1.5.2 Status of ASPs 510 The M2UA layer on the SG MUST maintain the state of the ASPs it is 511 supporting. The state of an ASP changes because of reception of 512 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 513 or reception of indications from the local SCTP association. ASP 514 state transition procedures are described in Section 4.3.1. 516 At a SG, an Application Server list MAY contain active and inactive 517 ASPs to support ASP fail-over procedures. When, for example, both 518 a primary and a back-up ASP are available, M2UA peer protocol is 519 required to control which ASP is currently active. The ordered 520 list of ASPs within a logical Application Server is kept updated in 521 the SG to reflect the active Application Server Process(es). 523 Also the M2UA layer MAY need to inform the local management of the 524 change in status of an ASP or AS. This can be achieved using the M-ASP 525 STATUS or M-AS STATUS primitives. 527 1.5.3 SCTP Stream Management 529 SCTP allows user specified number of streams to be opened during the 530 initialization. It is the responsibility of the M2UA layer to ensure 531 proper management of these streams. Because of the unidirectional 532 nature of streams, M2UA layers are not aware of the stream information 533 from the peer M2UA layers. Instead, the Interface Identifier is 534 in the M2UA message header. 536 The use of SCTP streams within M2UA is recommended in order to minimize 537 transmission and buffering delay, therefore improving the overall 538 performance and reliability of the signaling elements. It is 539 recommended that a separate SCTP stream is used for each SS7 link. 541 1.5.4 Seamless SS7 Network Management Interworking 543 The M2UA layer on the SG SHOULD pass an indication of unavailability of 544 the M2UA-User (MTP3) to the local Layer Management, if the currently 545 active ASP moves from the ACTIVE state. If the AS moves to the DOWN 546 state while SS7 links are in-service, the SG SHOULD follow the MTP 2 547 processor outage procedures [2]. 549 1.5.5 Flow Control / Congestion 551 It is possible for the M2UA layer to be informed of IP network congestion 552 by means of an implementation-dependent function (i.e. an indication 553 from the SCTP). If the M2UA layer receives this indication, the action(s) 554 taken are implementation dependent. 556 1.6 Definition of the M2UA Boundaries 558 1.6.1 Definition of the M2UA / MTP Level 3 boundary 560 DATA 561 ESTABLISH 562 RELEASE 563 STATE 564 DATA RETRIEVAL 565 DATA RETRIEVAL COMPLETE 567 1.6.2 Definition of the M2UA / MTP Level 2 boundary 569 DATA 570 ESTABLISH 571 RELEASE 572 STATE 573 DATA RETRIEVAL 574 DATA RETRIEVAL COMPLETE 576 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 578 The upper layer and layer management primitives provided by SCTP are 579 provided in Reference [5] Section 9. 581 1.6.4 Definition of Layer Management / M2UA Boundary 583 M-SCTP ESTABLISH request 584 Direction: LM -> M2UA 585 Purpose: LM requests ASP to establish an SCTP association with an SG. 587 M-STCP ESTABLISH confirm 588 Direction: M2UA -> LM 589 Purpose: ASP confirms to LM that it has established an SCTP 590 association with an SG. 592 M-SCTP ESTABLISH indication 593 Direction: M2UA -> LM 594 Purpose: SG informs LM that an ASP has established an SCTP 595 association. 597 M-SCTP RELEASE request 598 Direction: LM -> M2UA 599 Purpose: LM requests ASP to release an SCTP association with SG. 601 M-SCTP RELEASE confirm 602 Direction: M2UA -> LM 603 Purpose: ASP confirms to LM that it has released SCTP association 604 with SG. 606 M-SCTP RELEASE indication 607 Direction: M2UA -> LM 608 Purpose: SG or IPSP informs LM that ASP has released an SCTP 609 association. 611 M-SCTP STATUS request 612 Direction: LM -> M2UA 613 Purpose: LM requests M2UA to report status of SCTP association. 615 M-SCTP STATUS indication 616 Direction: M2UA -> LM 617 Purpose: M2UA reports status of SCTP association. 619 M-ASP STATUS request 620 Direction: LM -> M2UA 621 Purpose: LM requests SG to report status of remote ASP. 623 M-ASP STATUS indication 624 Direction: M2UA -> LM 625 Purpose: SG reports status of remote ASP. 627 M-AS-STATUS request 628 Direction: LM -> M2UA 629 Purpose: LM requests SG to report status of AS. 631 M-AS-STATUS indication 632 Direction: M2UA -> LM 633 Purpose: SG reports status of AS. 635 M-NOTIFY indication 636 Direction: M2UA -> LM 637 Purpose: ASP reports that it has received a NOTIFY message 638 from its peer. 640 M-ERROR indication 641 Direction: M2UA -> LM 642 Purpose: ASP or SG reports that it has received an ERROR 643 message from its peer. 645 M-ASP-UP request 646 Direction: LM -> M2UA 647 Purpose: LM requests ASP to start its operation and send an ASP UP 648 message to the SG. 650 M-ASP-UP confirm 651 Direction: M2UA -> LM 652 Purpose: ASP reports that is has received an ASP UP Acknowledgement 653 message from the SG. 655 M-ASP-DOWN request 656 Direction: LM -> M2UA 657 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 658 message to the SG. 660 M-ASP-DOWN confirm 661 Direction: M2UA -> LM 662 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 663 message from the SG. 665 M-ASP-ACTIVE request 666 Direction: LM -> M2UA 667 Purpose: LM requests ASP to send an ASP ACTIVE message to the SG. 669 M-ASP-ACTIVE confirm 670 Direction: M2UA -> LM 671 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 672 message from the SG. 674 M-ASP-INACTIVE request 675 Direction: LM -> M2UA 676 Purpose: LM requests ASP to send an ASP INACTIVE message to the SG. 678 M-ASP-INACTIVE confirm 679 Direction: M2UA -> LM 680 Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement 681 message from the SG. 683 2.0 Conventions 685 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 686 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 687 in this document, are to be interpreted as described in [RFC2119]. 689 3.0 Protocol Elements 691 This section describes the format of various messages used in this 692 protocol. 694 3.1 Common Message Header 696 The protocol messages for MTP2-User Adaptation require a message 697 structure which contains a version, message class, message type, message 698 length, and message contents. This message header is common among all 699 signaling protocol adaptation layers: 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Version | Spare | Message Class | Message Type | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Message Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Figure 3 Common Message Header 711 All fields in an M2UA message MUST be transmitted in the network byte 712 order, unless otherwise stated. 714 3.1.1 Version 716 The version field (vers) contains the version of the M2UA adapation 717 layer. The supported versions are: 719 Value Version 720 ----- ------- 721 1 Release 1.0 723 3.1.2 Message Type 725 The following List contains the valid Message Classes: 727 Message Class: 8 bits (unsigned integer) 729 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 730 1 Transfer Messages [M3UA] 731 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 732 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 733 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 734 5 Q.921/Q.931 Boundary Primitives Tranport (QPTM) 735 Messages [IUA] 736 6 MTP2 User Adaptatation (MAUP) Messages [M2UA] 737 7 Connectionless Messages [SUA] 738 8 Connection-Oriented Messages [SUA] 739 9 to 127 Reserved by the IETF 740 128 to 255 Reserved for IETF-Defined Message Class extensions 742 The following list contains the message types for the defined messages. 744 MTP2 User Adaptatation (MAUP) Messages 746 0 Reserved 747 1 Data 748 2 Establish Request 749 3 Establish Confirm 750 4 Release Request 751 5 Release Confirm 752 6 Release Indication 753 7 State Request 754 8 State Confirm 755 9 State Indication 756 10 Data Retrieval Request 757 11 Data Retrieval Confirm 758 12 Data Retrieval Indication 759 13 Data Retrieval Complete Indication 760 14 to 127 Reserved by the IETF 761 128 to 255 Reserved for IETF-Defined MAUP extensions 762 Application Server Process State Maintenance (ASPSM) messages 764 0 Reserved 765 1 ASP Up (UP) 766 2 ASP Down (DOWN) 767 3 Heartbeat (BEAT) 768 4 ASP Up Ack (UP ACK) 769 5 ASP Down Ack (DOWN ACK) 770 6 Heatbeat Ack (BEAT ACK) 771 7 to 127 Reserved by the IETF 772 128 to 255 Reserved for IETF-Defined ASPSM extensions 774 Application Server Process Traffic Maintenance (ASTM) messages 776 0 Reserved 777 1 ASP Active (ACTIVE) 778 2 ASP Inactive (INACTIVE) 779 3 ASP Active Ack (ACTIVE ACK) 780 4 ASP Inactive Ack (INACTIVE ACK) 781 5 to 127 Reserved by the IETF 782 128 to 255 Reserved for IETF-Defined ASTM extensions 784 Management (MGMT) Messages 786 0 Error (ERR) 787 1 Notify (NTFY) 788 2 to 127 Reserved by the IETF 789 128 to 255 Reserved for IETF-Defined MGMT extensions 791 3.1.3 Reserved 793 The Reserved field is 8-bits. It SHOULD be set to all '0's and 794 ignored by the receiver. 796 3.1.4 Message Length 798 The Message length defines the length of the message in octets, 799 including the header. 801 3.1.5 Variable-Length Parameter Format 803 M2UA messages consist of a Common Header followed by zero or more 804 variable-length parameters, as defined by the message type. The 805 variable-length parameters contained in a message are defined in a 806 Tag-Length-Value format as shown below. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Parameter Tag | Parameter Length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 \ \ 814 / Parameter Value / 815 \ \ 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Parameter Tag: 16 bits (unsigned integer) 820 The Type field is a 16 bit identifier of the type of parameter. It takes 821 a value of 0 to 65534. 823 The value of 65535 is reserved for IETF-defined extensions. Values 824 other than those defined in specific parameter description are reserved 825 for use by the IETF. 827 Parameter Length: 16 bits (unsigned integer) 829 The Parameter Length field contains the size of the parameter in bytes, 830 including the Parameter Tag, Parameter Length, and Parameter Value 831 fields. The Parameter Length does not include any padding bytes. 833 Parameter Value: variable-length. 835 The Parameter Value field contains the actual information to be 836 transferred in the parameter. 838 The total length of a parameter (including Tag, Parameter Length and Value 839 fields) MUST be a multiple of 4 bytes. If the length of the parameter is 840 not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., 841 after the Parameter Value field) with all zero bytes. The length of the 842 padding is NOT included in the parameter length field. A sender SHOULD 843 NOT pad with more than 3 bytes. The receiver MUST ignore the padding 844 bytes. 846 3.2 M2UA Message Header 848 In addition to the common message header, there will be a M2UA specific 849 message header. The M2UA specific message header will immediately 850 follow the common message header, but will only be used with MAUP 851 messages. 853 This message header will contain the Interface Identifier. The 854 Interface Identifier identifies the physical interface at the SG for 855 which the signaling messages are sent/received. The format of the 856 Interface Identifier parameter can be text or integer, the values of which 857 are assigned according to network operator policy. The values used are of 858 local significance only, coordinated between the SG and ASP. 860 The integer formatted Interface Identifier MUST be supported. The 861 text formatted Interface Identifier MAY optionally be supported. 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Tag (0x1) | Length=8 | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Interface Identifier (integer) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 4 M2UA Message Header (Integer-based Interface Identifier) 873 The Tag value for Integer-based Interface Identifier is 0x1. The length is 874 always set to a value of 8. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Tag (0x3) | Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Interface Identifier (text) | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 5 M2UA Message Header (Text-based Interface Identifier) 888 The Tag value for the Text-based Interface Identifier is 0x3. The 889 length is variable. 891 3.3 M2UA Messages 893 The following section defines the messages and parameter contents. The 894 M2UA messages will use the common message header (Figure 3) and the 895 M2UA message header (Figure 4). 897 3.3.1 MTP2 User Adaptation Messages 899 3.3.1.1 Data 901 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 902 Data message contains the protocol data. 904 The format for the Data Message parameters is as follows: 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Tag (0xe) | Length | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Protocol Data | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 The Protocol Data field contains the MTP2-User application message in 917 network byte order starting with the Signaling Information Octet (SIO). 919 3.3.1.2 Establish (Request, Confirmation) 921 The Establish Request message is used to establish the link or to 922 indicate that the channel has been established. The MGC controls the 923 state of the SS7 link. When the MGC desires the SS7 link to be 924 in-service, it will send the Establish Request message. Note that the 925 gateway MAY already have the SS7 link established at its layer. If so, 926 upon receipt of an Establish Request, the gateway takes no action except 927 to send an Establish Confirm. 929 When the MGC sends an M2UA Establish Request message, the MGC MAY 930 start a timer. This timer would be stopped upon receipt of an M2UA 931 Establish Confirm. If the timer expires, the MGC would re-send the 932 M2UA Establish Request message and restart the timer. In other words, 933 the MGC MAY continue to request the establishment of the data link 934 on periodic basis until the desired state is achieved or take some 935 other action (notify the Management Layer). 937 The mode (Normal of Emergency) for bringing the link in service is 938 defaulted to Normal. The State Request (described in Section 3.3.1.4 939 below) can be used to change the mode to Emergency. 941 3.3.1.3 Release (Request, Indication, Confirmation) 943 This Release Request message is used to release the channel. The 944 Release Confirm and Indication messages are used to indicate that the 945 channel has been released. 947 3.3.1.4 State (Request, Confirm) 949 The State Request message can be sent from a MGC to cause an action 950 on a particular SS7 link supported by the Signaling Gateway. The 951 gateway sends a State Confirm to the MGC if the action has been success- 952 fully completed. The State Confirm reflects that state value received 953 in the State Request message. 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Tag (0x10) | Length | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | State | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 The valid values for State are shown in the following table. 965 Define Value Description 966 STATUS_LPO_SET 0x0 Request local processor outage 967 STATUS_LPO_CLEAR 0x1 Request local processor outage 968 recovered 969 STATUS_EMER_SET 0x2 Request emergency alignment 970 procedure 971 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 972 emergency) procedure 973 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit 974 buffers 975 STATUS_CONTINUE 0x5 Continue 977 3.3.1.5 State Indication 979 The MTP2 State Indication message can be sent from a gateway to an 980 ASP to indicate a condition on a link. 982 0 1 2 3 983 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 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Tag (0x11) | Length | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Event | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Tag (0x15) | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Cong Level | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 The valid values for Event are shown in the following table. 996 Define Value Description 997 EVENT_CONG_ENTER 0x1 Link Congestion Entered 998 EVENT_CONG_EXIT 0x2 Link Congestion Exited 999 EVENT_RPO_ENTER 0x3 Remote entered processor outage 1000 EVENT_RPO_EXIT 0x4 Remote exited processor outage 1002 The Cong Level parameter would only be used with a link congestion 1003 event. The Cong Level parameter would be used for National Networks 1004 that make use of multiple congestion levels [2]. 1006 3.3.1.6 Retrieval (Request, Confirm) 1008 The MTP2 Retrieval Request message is used during the MTP Level 3 1009 changeover procedure to request the BSN, to retrieve PDUs from the 1010 retransmit queue or to flush PDUs from the retransmit queue. 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 (0x12) | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Action | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Tag (0x13) | Length | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | seq_num | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 The valid values for Action are shown in the following table. 1026 Define Value Description 1027 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1028 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 1029 queue 1030 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue 1032 In the Retrieval Request message, the seq_num field SHOULD be ignored if 1033 the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The seq_num 1034 field contains the Forward Sequnce Number (FSN) of the far end if the 1035 Action is ACTION_RTRV_MSGS. 1037 When the Signaling Gateway sends a Retrieval Confirm to this request, 1038 it echos the action and puts the Backward Sequence Number (BSN) in the 1039 seq_num field if the action was ACTION_RTRV_BSN. If there is a failure 1040 in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff). 1041 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of 1042 of seq_num will be set to zero for success or -1 (0xffffffff) for failure. 1043 A failure means that the buffers could not be retrieved. For a Retrieval 1044 Confirm with an Action of ACTION_DROP_MSGS, the value received in the 1045 seq_num field will be ignored. 1047 3.3.1.7 Retrieval Indication 1049 The Retrieval Indication message is sent by the Signaling Gateway 1050 with a PDU from the retransmit queue. The Retrieval Indication 1051 message does not contain the Action or seq_num fields, just a MTP3 1052 Protocol Data Unit (PDU) from the retransmit queue. 1054 The M2UA implementation MAY consider the use of the bundling feature 1055 of SCTP for Retrieval Indication messages. 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Tag (0x14) | Length | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | PDU from retransmit queue | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 3.3.1.8 Retrieval Complete Indication 1069 The MTP2 Retrieval Complete Indication message is exactly the same as 1070 the MTP2 Retrieval Indication message except that it also indicates that 1071 it contains the last PDU from the retransmit queue. 1073 3.3.2 Application Server Process Maintenance (ASPM) Messages 1075 The ASPM messages will only use the common message header. 1077 3.3.2.1 ASP UP (ASPUP) 1079 The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer 1080 that the Adaptation layer is ready to receive traffic or maintenance 1081 messages. 1083 The ASPUP message contains the following parameters 1085 Info String (optional) 1087 The format for ASPUP Message parameters is as follows: 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Tag (0x4) | Length | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | INFO String* | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1100 character string along with the message. Length of the INFO String 1101 parameter is from 0 to 255 characters. No procedures are presently 1102 identified for its use but the INFO String MAY be used for debugging 1103 purposes. 1105 3.3.2.2 ASP Up Ack 1107 The ASP UP Ack message is used to acknowledge an ASP Up message received 1108 from a remote M2UA peer. 1110 The ASPUP Ack message contains the following parameters: 1112 INFO String (optional) 1114 The format for ASPUP Ack Message parameters is as follows: 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Tag (0x4) | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | INFO String* | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 The format and description of the optional Info String parameter is the 1127 same as for the ASP UP message (See Section 3.3.2.1.) 1129 3.3.2.3 ASP Down (ASPDN) 1131 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1132 that the adaptation layer is not ready to receive traffic or 1133 maintenance messages. 1135 The ASPDN message contains the following parameters 1137 Reason 1138 INFO String (Optional) 1140 The format for the ASPDN message parameters is as follows: 1142 0 1 2 3 1143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Tag (0xa) | Length | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Reason | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Tag (0x4) | Length | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | INFO String* | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 The format and description of the optional Info String parameter is the 1157 same as for the ASP Up message (See Section 3.3.2.1.). 1159 The Reason parameter indicates the reason that the remote M2UA 1160 adaptation layer is unavailable. The valid values for Reason are shown 1161 in the following table. 1163 Value Description 1164 0x1 Management 1166 3.3.2.4 ASP Down Ack 1168 The ASP Down Ack message is used to acknowledge an ASP Down message 1169 received from a remote M2UA peer. 1171 The ASP Down Ack message contains the following parameters: 1173 Reason 1174 INFO String (Optional) 1176 The format for the ASPDN Ack message parameters is as follows: 1178 0 1 2 3 1179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Tag (0xa) | Length | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Reason | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Tag (0x4) | Length | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | INFO String* | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 The format and description of the optional Info String parameter is the 1193 same as for the ASP UP message (See Section 3.3.2.1.) 1195 The format of the Reason parameter is the same as for the ASP Down message 1196 (See Section 3.3.2.3). 1198 3.3.2.5 ASP Active (ASPAC) 1200 The ASPAC message is sent by an ASP to indicate to an SG that it is 1201 Active and ready to be used. 1203 The ASPAC message contains the following parameters 1205 Traffic Mode Type (Mandatory) 1206 Interface Identifier (Optional) 1207 - Combination of integer and integer ranges, OR 1208 - string (text formatted) 1209 INFO String (Optional) 1211 The format for the ASPAC message using integer formatted Interface 1212 Identifiers is as follows: 1214 0 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Tag (0xb) | Length | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Traffic Mode Type | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Tag (0x1=integer) | Length | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Interface Identifiers* | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Tag (0x8=integer range) | Length | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Interface Identifier Start1* | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Interface Identifier Stop1* | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Interface Identifier Start2* | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Interface Identifier Stop2* | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 . . 1238 . . 1239 . . 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Interface Identifier StartN* | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Interface Identifier StopN* | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Additional Interface Identifiers | 1247 | of Tag Type 0x1 or 0x8 | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Tag (0x4) | Length | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | INFO String* | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 The format for the ASPAC message using text formatted (string) 1258 Interface Identifiers is as follows: 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Tag (0xb) | Length | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Traffic Mode Type | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Tag (0x3=string) | Length | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Interface Identifier* | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Additional Interface Identifiers | 1275 | of Tag Type 0x3 | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Tag (0x4) | Length | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | INFO String* | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 The Traffic Mode Type parameter identifies the traffic mode of 1286 operation of the ASP within an AS. The valid values for Type are 1287 shown in the following table: 1289 Value Description 1290 0x1 Over-ride 1292 Within a particular Interface Identifier, only one Type can be used. 1293 The Over-ride value indicates that the ASP is operating in Over-ride 1294 mode, where the ASP takes over all traffic in an Application Server 1295 (i.e., primary/back-up operation), over-riding any currently active 1296 ASPs in the AS. 1298 The optional Interface Identifiers parameter contains a list of 1299 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1300 (Type 0x3)indexing the Application Server traffic that the sending 1301 ASP is configured/registered to receive. If integer formatted 1302 Interface Identifiers are being used, the ASP can also send ranges of 1303 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1304 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1305 formatted Interface Identifiers (0x3) cannot be used with either 1306 Integer (0x1) or Integer Range (0x8) types. 1308 If no Interface Identifiers are included, the message is for all 1309 provisioned Interface Identifiers within the AS(s) in which the 1310 ASP is provisioned. If only a subset of Interface Identifiers are 1311 included, the ASP is noted as Active for all the Interface Identifiers 1312 provisioned for that AS. 1314 Note: If the optional Interface Identifier parameter is present, the 1315 integer formatted Interface Identifier MUST be supported, while the 1316 text formatted Interface Identifier MAY be supported. 1318 An SG that receives an ASPAC with an incorrect Traffic Mode Type for 1319 a particular Interface Identifier will respond with an Error Message 1320 (Cause: Unsupported Traffic Handling Mode). 1322 The format and description of the optional Info String parameter is the 1323 same as for the ASP UP message (See Section 3.3.2.1.). 1325 3.3.2.6 ASP Active Ack 1327 The ASPAC Ack message is used to acknowledge an ASP-Active message 1328 received from a remote M2UA peer. 1330 The ASPAC Ack message contains the following parameters: 1332 Traffic Mode Type (Mandatory) 1333 Interface Identifier (Optional) 1334 - Combination of integer and integer ranges, OR 1335 - string (text formatted) 1336 INFO String (Optional) 1338 The format for the ASPAC Ack message with Integer-formatted Interface 1339 Identifiers is as follows: 1341 0 1 2 3 1342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Tag (0xb) | Length | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Traffic Mode Type | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Tag (0x1=integer) | Length | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Interface Identifiers* | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Tag (0x8=integer range) | Length | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Interface Identifier Start1* | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Interface Identifier Stop1* | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Interface Identifier Start2* | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Interface Identifier Stop2* | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 . . 1365 . . 1366 . . 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Interface Identifier StartN* | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Interface Identifier StopN* | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Additional Interface Identifiers | 1374 | of Tag Type 0x1 or 0x8 | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Tag (0x4) | Length | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | INFO String* | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 The format for the ASP Active Ack message using text formatted (string) 1385 Interface Identifiers is as follows: 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Tag (0xb) | Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Traffic Mode Type | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Tag (0x3=string) | Length | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Interface Identifier* | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Additional Interface Identifiers | 1402 | of Tag Type 0x3 | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Tag (0x4) | Length | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | INFO String* | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 The format and description of the optional Info String parameter is the 1413 same as for the ASP UP message (See Section 3.3.2.1.) 1415 The format of the Type and Interface Identifier parameters is the same 1416 as for the ASP Active message (See Section 3.3.2.5). 1418 3.3.2.7 ASP Inactive (ASPIA) 1420 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1421 longer an active ASP to be used from within a list of ASPs. The SG will 1422 respond with an ASPIA Ack message and either discard incoming messages 1423 or buffer for a timed period and then discard. 1425 The ASPIA message contains the following parameters 1427 Traffic Mode Type (Mandatory) 1428 Interface Identifiers (Optional) 1429 - Combination of integer and integer ranges, OR 1430 - string (text formatted) 1431 INFO String (Optional) 1433 The format for the ASP Inactive message parameters using Integer 1434 formatted Interface Identifiers is as follows: 1436 0 1 2 3 1437 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 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Tag (0xb) | Length | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Traffic Mode Type | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | Tag (0x1=integer) | Length | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Interface Identifiers* | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Tag (0x8=integer range) | Length | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Interface Identifier Start1* | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Interface Identifier Stop1* | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Interface Identifier Start2* | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Interface Identifier Stop2* | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 . . 1460 . . 1461 . . 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Interface Identifier StartN* | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Interface Identifier StopN* | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Additional Interface Identifiers | 1469 | of Tag Type 0x1 or 0x8 | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Tag (0x4) | Length | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | INFO String* | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 The format for the ASP Inactive message using text formatted (string) 1480 Interface Identifiers 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 (0xb) | Length | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Traffic Mode Type | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Tag (0x3=string) | Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Interface Identifier* | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Additional Interface Identifiers | 1497 | of Tag Type 0x3 | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Tag (0x4) | Length | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | INFO String* | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 The Traffic Mode Type parameter identifies the traffic mode of 1508 operation of the ASP within an AS. The valid values for Traffic Mode 1509 Type are shown in the following table: 1511 Value Description 1512 0x1 Over-ride 1514 The format and description of the optional Interface Identifiers and 1515 Info String parameters is the same as for the ASP Active message (See 1516 Section 3.3.2.3.) 1518 The optional Interface Identifiers parameter contains a list of 1519 Interface Identifier integers indexing the Application Server traffic 1520 that the sending ASP is configured/registered to receive, but does not 1521 want to receive at this time. 1523 3.3.2.8 ASP Inactive Ack 1525 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 1526 received from a remote M2UA peer. 1528 The ASPIA Ack message contains the following parameters: 1530 Traffic Mode Type (Mandatory) 1531 Interface Identifiers (Optional) 1532 - Combination of integer and integer ranges, OR 1533 - string (text formatted) 1534 INFO String (Optional) 1536 The format for the ASPIA Ack message is as follows: 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Tag (0xb) | Length | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Traffic Mode Type | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Tag (0x1=integer) | Length | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Interface Identifiers* | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Tag (0x8=integer range) | Length | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Interface Identifier Start1* | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Interface Identifier Stop1* | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Interface Identifier Start2* | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Interface Identifier Stop2* | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 . . 1562 . . 1563 . . 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | Interface Identifier StartN* | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Interface Identifier StopN* | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Additional Interface Identifiers | 1571 | of Tag Type 0x1 or 0x8 | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Tag (0x4) | Length | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | INFO String* | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 The format for the ASP Inactive Ack message using text formatted 1582 (string) Interface Identifiers is as follows: 1584 0 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Tag (0xb) | Length | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Traffic Mode Type | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Tag (0x3=string) | Length | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Interface Identifier* | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Additional Interface Identifiers | 1599 | of Tag Type 0x3 | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | Tag (0x4) | Length | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | INFO String* | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 The format of the Traffic Mode Type and Interface Identifier 1610 parameters is the same as for the ASP Inactive message 1611 (See Section 3.3.2.7). 1613 The format and description of the optional Info String parameter is 1614 the same as for the ASP Up message (See Section 3.3.2.1). 1616 3.3.2.9 Heartbeat (BEAT) 1618 The Heartbeat message is optionally used to ensure that the M2UA peers 1619 are still available to each other. It is recommended for use when 1620 the M2AU runs over a transport layer other than the SCTP, which has its 1621 own heartbeat. 1623 The BEAT message contains the following parameters: 1625 Heartbeat Data Optional 1627 The format for the BEAT message is as follows: 1629 0 1 2 3 1630 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 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Tag = 9 | Length | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 \ \ 1635 | Heartbeat Data * | 1636 \ \ 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 The Heartbeat Data parameter contents are defined by the sending node. 1640 The Heartbeat Data could include, for example, a Heartbeat Sequence 1641 Number and, or Timestamp. The receiver of a Heartbeat message does 1642 not process this field as it is only of significance to the sender. 1643 The receiver MUST respond with a Heartbeat Ack message. 1645 3.3.2.10 Heartbeat Ack (BEAT-Ack) 1647 The Heartbeat Ack message is sent in response to a received Heartbeat 1648 message. It includes all the parameters of the received Heartbeat 1649 message, without any change. 1651 3.3.3 Layer Management (MGMT) Messages 1653 3.3.3.1 Error (ERR) 1655 The Error message is used to notify a peer of an error event 1656 associated with an incoming message. For example, the message type 1657 might be unexpected given the current state, or a parameter value might 1658 be invalid. 1660 The ERR message contains the following parameters: 1662 Error Code 1663 Diagnostic Information (optional) 1665 The format for the ERR message is as follows: 1667 0 1 2 3 1668 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 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Tag (0xc) | Length | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | Error Code | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Tag (0x7) | Length | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Diagnostic Information* | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 The Error Code parameter indicates the reason for the Error Message. 1682 The Error parameter value can be one of the following values: 1684 Invalid Version 0x1 1685 Invalid Interface Identifier 0x2 1686 Unsupported Message Class 0x3 1687 Unsupported Message Type 0x4 1688 Unsupported Traffic Handling Mode 0x5 1689 Unexpected Message 0x6 1690 Protocol Error 0x7 1691 Invalid Stream Identifier 0x8 1692 Unsupported Interface Identifier Type 0x9 1694 The "Invalid Version" error would be sent if a message was 1695 received with an invalid or unsupported version. The Error message 1696 would contain the supported version in the Common header. The 1697 Error message could optionally provide the supported version in 1698 the Diagnostic Information area. 1700 The "Invalid Interface Identifier" error would be sent by a SG if 1701 an ASP sends a message with an invalid (unconfigured) Interface 1702 Identifier value. 1704 The "Unsupported Traffic Handling Mode" error would be sent by a SG 1705 if an ASP sends an ASP Active with an unsupported Traffic Handling 1706 Mode. An example would be a case in which the SG did not support 1707 load-sharing. 1709 The "Unexpected Message" error would be sent by an ASP if it received 1710 a MAUP message from an SG while it was in the Inactive state. 1712 The "Protocol Error" error would be sent for any protocol anomaly 1713 (i.e. a bogus message). 1715 The "Invalid Stream Identifier" error would be sent if a message 1716 was received on an unexpected SCTP stream (i.e. i.e. a MGMT message 1717 was received on a stream other than "0").). 1719 The "Unsupported Interface Identifier Type" error would be sent by 1720 a SG if an ASP sends a Text formatted Interface Identifier and the 1721 SG only supports Integer formatted Interface Identifiers. When 1722 the ASP receives this error, it will need to resend its message with 1723 an Integer formatted Interface Identifier. 1725 The "Unsupported Message Class" error would be sent if a message with 1726 an unexpected or unsupported Message Class is received. 1728 The "Unsupported Interface Identifier Type" error would be sent by 1729 a SG if an ASP sends a Text formatted Interface Identifier and the 1730 SG only supports Integer formatted Interface Identifiers. When 1731 the ASP receives this error, it will need to resend its message with 1732 an Integer formatted Interface Identifier. 1734 The optional Diagnostic information can be any information germain to 1735 the error condition, to assist in identification of the error condition. 1736 In the case of an Invalid Version Error Code the Diagnostic information 1737 includes the supported Version parameter. In the other cases, the 1738 Diagnostic information MAY be the first 40 bytes of the offending message. 1740 3.3.3.2 Notify (NTFY) 1742 The Notify message used to provide an autonomous indication of M2UA 1743 events to an M2UA peer. 1745 The NTFY message contains the following parameters: 1747 Status Type 1748 Status Identification 1749 Interface Identifiers (Optional) 1750 INFO String (Optional) 1752 The format for the Notify message with Integer-formatted Interface 1753 Identifiers is as follows: 1755 0 1 2 3 1756 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 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Tag (0xd) | Length | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Status Type | Status Identification | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Tag (0x1=integer) | Length | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Interface Identifiers* | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Tag (0x8=integer range) | Length | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Interface Identifier Start1* | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Interface Identifier Stop1* | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Interface Identifier Start2* | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Interface Identifier Stop2* | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 . . 1779 . . 1780 . . 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Interface Identifier StartN* | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Interface Identifier StopN* | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | Additional Interface Identifiers | 1788 | of Tag Type 0x1 or 0x8 | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Tag (0x4) | Length | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | INFO String* | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 The format for the Notify message with Text-formatted Interface 1799 Identifiers is as follows: 1801 0 1 2 3 1802 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 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Tag (0xd) | Length | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Status Type | Status Identification | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Tag (0x3=string) | Length | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Interface Identifier* | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Additional Interface Identifiers | 1816 | of Tag Type 0x3 | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Tag (0x4) | Length | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | INFO String* | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 The Status Type parameter identifies the type of the Notify message. 1827 The following are the valid Status Type values: 1829 Value Description 1830 0x1 Application Server state change (AS_State_Change) 1831 0x2 Other 1833 The Status Information parameter contains more detailed information for 1834 the notification, based on the value of the Status Type. If the Status 1835 Type is AS_State_Change the following Status Information values are used: 1837 Value Description 1838 1 Application Server Down (AS_Down) 1839 2 Application Server Inactive (AS_Inactive) 1840 3 Application Server Active (AS_Active) 1841 4 Application Server Pending (AS_Pending) 1843 These notifications are sent from an SG to an ASP upon a change in status 1844 of a particular Application Server. The value reflects the new state of 1845 the Application Server. 1847 If the Status Type is Other, then the following Status Information values 1848 are defined: 1850 Value Description 1851 1 Insufficient ASP resources active in AS 1852 2 Alternate ASP Active 1854 This notification is not based on the SG reporting the state change of an 1855 ASP or AS. In the Insufficient ASP Resources case, the SG is 1856 indicating to an "Inactive" ASP(s) in the AS that another ASP is 1857 required in order to handle the load of the AS (Load-sharing mode). 1858 For the Alternate ASP Active case, an ASP is informed when an alternate 1859 ASP transitions to the ASP-Active state in Over-ride mode. 1861 The format and description of the optional Interface Identifiers and 1862 Info String parameters is the same as for the ASP Active message 1863 (See Section 3.3.2.3.) 1864 4.0 Procedures 1866 The M2UA layers needs to respond to various primitives it receives from 1867 other layers as well as messages it receives from the peer-to-peer 1868 messages. This section describes various procedures involved in 1869 response to these events. 1871 4.1 Procedures to Support Service in Section 1.4.1 1873 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 1874 MTP Level 3 boundary" service. 1876 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 1878 On receiving a primitive from the local upper layer, the M2UA layer will 1879 send the corresponding MAUP message (see Section 2) to its peer. The 1880 M2UA layer MUST fill in various fields of the common and specific headers 1881 correctly. In addition the message needs to be sent on the SCTP stream 1882 that corresponds to the SS7 link. 1884 4.1.2 MAUP Message Procedures 1886 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 1887 SG or MGC needs to invoke the corresponding layer primitives to the 1888 local MTP Level 2 or MTP Level 3 layer. 1890 4.2 Procedures to Support Service in Section 1.4.2 1892 These procedures achieve the M2UA layer's "Support for Communication 1893 between Layer Managements" service. 1895 4.2.1 Layer Management Primitives Procedure 1897 On receiving these primitives from the local layer, the M2UA layer will 1898 send the corresponding MGMT message (Error) to its peer. The M2UA layer 1899 MUST fill in the various fields of the common and specific headers 1900 correctly. 1902 An M-SCTP ESTABLISH request from Layer Management will initiate the 1903 establishment of an SCTP association. An M-SCTP ESTABLISH confirm 1904 will be sent to Layer Management when the initiated association set-up 1905 is complete. An M-SCTP ESTABLISH indication is sent to Layer 1906 Management upon successful completion of an incoming SCTP association 1907 set-up from a peer M2UA node 1909 An M-SCTP RELEASE request from Layer Management will initiate the 1910 tear-down of an SCTP association. An M-SCTP RELEASE confirm will 1911 be sent by Layer Management when the association teardown is complete. 1912 An M-SCTP RELEASE indication is sent to Layer Management upon 1913 successful tear-down of an SCTP association initiated by a peer M2UA. 1915 M-SCTP STATUS request and indication support a Layer Management 1916 query of the local status of a particular SCTP association. 1918 M-NOTIFY indication and M-ERROR indication indicate to Layer 1919 Management the notification or error information contained in a 1920 received M2UA Notify or Error message respectively. These indications 1921 can also be generated based on local M2UA events. 1923 M-ASP STATUS request/indication and M-AS-STATUS request/indication 1924 support a Layer Management query of the local status of a particular 1925 ASP or AS. No M2UA peer protocol is invoked. 1927 M-ASP Up request, M-ASP Down request, M-ASP-INACTIVE request and 1928 M-ASP-ACTIVE request allow Layer Management at an ASP to initiate 1929 state changes. These requests result in outgoing M2UA ASP UP, 1930 ASP DOWN, ASP INACTIVE and ASP ACTIVE messages. 1932 M-ASP Up confirmation, M-ASP Down confirmation, M-ASP-INACTIVE 1933 confirmation and M-ASP-ACTIVE confirmation indicate to Layer 1934 Management that the previous request has been confirmed. 1936 All MGMT messages are sent on a sequenced stream to ensure ordering. 1937 SCTP stream '0' SHOULD be used. 1939 4.2.2 MGMT message procedures 1941 Upon receipt of MGMT messages the M2UA layer MUST invoke the corresponding 1942 Layer Management primitives indications (e.g., M-AS Status ind., M-ASP 1943 Status ind., M-ERROR ind...) to the local layer management. 1945 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 1946 the notification or error information contained in a received M2UA 1947 Notify or Error message. These indications can also be generated 1948 based on local M2UA events. 1950 All MGMT messages are sent on a sequenced stream to ensure ordering. 1951 SCTP stream '0' SHOULD be used. 1953 4.3 Procedures to Support Service in Section 1.4.3 1955 These procedures achieve the M2UA layer's "Support for management of 1956 active associations between SG and MGC" service. 1958 4.3.1 State Maintenance 1960 The M2UA layer on the SG maintains the state of each AS, in each 1961 Appliction Server that it is configured to receive traffic. 1963 4.3.1.1 ASP States 1965 The state of the each ASP, in each AS that it is configured, is 1966 maintained in the M2UA layer on the SG. The state of an ASP changes 1967 due to events. The events include 1969 * Reception of messages from peer M2UA layer at that ASP 1970 * Reception of some messages from the peer M2UA layer at other 1971 ASPs in the AS 1972 * Reception of indications from SCTP layer 1974 The ASP state transition diagram is shown in Figure 6. The possible 1975 states of an ASP are the following: 1977 ASP Down: Application Server Process is unavailable and/or the related 1978 SCTP association is down. Initially all ASPs will be in this state. 1979 An ASP in this state SHOULD NOT not be sent any M2UA messages. 1981 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 1982 related SCTP association is up) but application traffic is stopped. 1983 In this state the ASP can be sent any non-MAUP M2UA messages. 1985 ASP-ACTIVE The remote M2UA peer at the ASP is available and 1986 application traffic is active. 1988 Figure 6 ASP State Transition Diagram 1990 +-------------+ 1991 +----------------------| | 1992 | Alternate +-------| ASP-ACTIVE | 1993 | ASP | +-------------+ 1994 | Takeover | ^ | 1995 | | ASP | | ASP 1996 | | Active | | Inactive 1997 | | | v 1998 | | +-------------+ 1999 | | | | 2000 | +------>| ASP-INACT | 2001 | +-------------+ 2002 | ^ | 2003 ASP Down/ | ASP | | ASP Down / 2004 SCTP CDI | Up | | SCTP CDI 2005 | | v 2006 | +-------------+ 2007 +--------------------->| | 2008 | ASP Down | 2009 +-------------+ 2011 SCTP CDI The local SCTP layer's Communication Down Indication to the 2012 Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this 2013 indication when it detects the loss of connectivity to the ASP's peer 2014 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 2015 notification and COMMUNICATION LOST notification from the SCTP. 2017 4.3.1.2 AS States 2019 The state of the AS is maintained in the M2UA layer on the SG. 2021 The state of an AS changes due to events. These events include the 2022 following: 2024 * ASP state transitions 2025 * Recovery timer triggers 2027 The possible states of an AS are the following: 2029 AS-DOWN: The Application Server is unavailable. This state implies 2030 that all related ASPs are in the ASP Down state for this AS. 2031 Initially the AS will be in this state. 2033 AS-INACTIVE: The Application Server is available but no application traffic 2034 is active (i.e., one or more related ASPs are in the ASP-Inactive state, 2035 but none in the ASP-Active state). 2037 AS-ACTIVE: The Application Server is available and application traffic 2038 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2040 AS-PENDING: An active ASP has transitioned from active to inactive or 2041 down and it was the last remaining active ASP in the AS. A recovery 2042 timer T(r) will be started and all incoming SCN messages will be 2043 queued by the SG. If an ASP becomes active before T(r) expires, the 2044 AS will move to AS-ACTIVE state and all the queued messages will be 2045 sent to the active ASP. 2047 If T(r) expires before an ASP becomes active, the SG stops queuing 2048 messages and discards all previously queued messages. The AS will move 2049 to AS-Inactive if at least one ASP is in ASP-Inactive state, otherwise it 2050 will move to AS-DOWN state. 2052 Figure 7 AS State Transition Diagram 2054 +----------+ one ASP trans ACTIVE +-------------+ 2055 | |------------------------>| | 2056 | AS-INACT | | AS-ACTIVE | 2057 | | | | 2058 | |< | | 2059 +----------+ \ +-------------+ 2060 ^ | \ Tr Trigger ^ | 2061 | | \ at least one | | 2062 | | \ ASP in UP | | 2063 | | \ | | 2064 | | \ | | 2065 | | \ | | 2066 one ASP | | \ one ASP | | Last ACTIVE ASP 2067 trans | | all ASP \------\ trans to | | trans to INACT 2068 to | | trans to \ ACTIVE | | or DOWN 2069 INACT | | DOWN \ | | (start Tr timer) 2070 | | \ | | 2071 | | \ | | 2072 | | \ | | 2073 | v \ | v 2074 +----------+ \ +-------------+ 2075 | | -| | 2076 | AS-DOWN | | AS-PENDING | 2077 | | | (queueing) | 2078 | |<------------------------| | 2079 +----------+ Tr Expiry and no +-------------+ 2080 ASP in INACTIVE state 2082 Tr = Recovery Timer 2084 4.3.2 ASPM procedures for primitives 2086 Before the establishment of an SCTP association the ASP state at both 2087 the SG and ASP is assumed to be "Down". 2089 As the ASP is responsible for initiating the setup of an SCTP 2090 association to an SG, the M2UA layer at an ASP receives an M-SCTP 2091 ESTABLISH request primitive from the Layer Management, the M2UA layer 2092 will try to establish an SCTP association with the remote M2UA peer at 2093 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2094 primitive from the SCTP, the M2UA layer will invoke the primitive 2095 M-SCTP ESTABLISH confirm to the Layer Management. 2097 At the SG, the M2UA layer will receive an SCTP Communication Up 2098 indication primitive from the SCTP. The M2UA layer will then invoke 2099 the primitive M-SCTP ESTABLISH indication to the Layer Management. 2101 Once the SCTP association is establishedand assuming that the local 2102 M2UA-User is ready, the local ASP M2UA Application Server Process 2103 Maintenance (ASPM) function will initiate the ASPM procedures, using 2104 the ASP Up/-Down/-Active/-Inactive messages to convey the ASP-state to 2105 the SG - see Section 4.3.3. 2107 The Layer Management and the M2UA layer on SG can communicate the 2108 status of the application server using the M-AS STATUS primitives. 2109 The Layer Managements and the M2UA layers on both the SG and ASP 2110 can communicate the status of an SCTP association using the 2111 M-SCTP STATUS primitives. 2113 If the Layer Management on SG or ASP wants to bring down an SCTP 2114 association for management reasons, they would send M-SCTP RELEASE 2115 request primitive to the local M2UA layer. The M2UA layer would release 2116 the SCTP association and upon receiving the SCTP Communication Down 2117 indication from the underlying SCTP layer, it would inform the local 2118 Layer Management using M-SCTP RELEASE confirm primitive. 2120 If the M2UA layer receives an SCTP-Communication Down indication 2121 from the underlying SCTP layer, it will inform the Layer 2122 Management by invoking the M-SCTP RELEASE indication primitive. The 2123 state of the ASP will be moved to "Down" at both the SG and ASP. 2125 At an ASP, the Layer Management MAY try to reestablish the SCTP 2126 association using M-SCTP ESTABLISH request primitive. 2128 4.3.3 ASPM procedures for peer-to-peer messages 2130 All ASPM messages are sent on a sequenced stream to ensure ordering. 2131 SCTP stream '0' SHOULD is used. 2133 4.3.3.1 ASP-Inactive 2135 After an ASP has successfully established an SCTP association to an SG, 2136 the SG waits for the ASP to send an ASP Up message, indicating that the 2137 ASP M2UA peer is available. The ASP is always the initiator of the 2138 ASP Up exchange. 2140 When an ASP Up message is received at an SG and internally the ASP is 2141 not considered locked-out for local management reasons, the SG marks 2142 the remote ASP as Inactive. The SG responds with an ASP Up Ack message 2143 in acknowledgement. The SG sends an-Up Ack message in response to a 2144 received ASP Up message even if the ASP is already marked as "Inactive" 2145 at the SG. 2147 If for any local reason the SG cannot respond with an ASP Up, the SG 2148 responds to a ASP Up with a ASP Down Ack message. 2150 At the ASP, the ASP Up Ack message received from the SG is not 2151 acknowledged by the ASP. If the ASP does not receive a response from 2152 the SG, or an ASP Down is received, the ASP MAY resend ASP Up messages 2153 every 2 seconds until it receives a ASP Up Ack message from the 2154 SG. The ASP MAY decide to reduce the frequency (say to every 5 2155 seconds) if an ASP Up Ack is not received after a few tries. 2157 The ASP MUST wait for the ASP Up Ack message from the SG before 2158 sending any ASP traffic control messages (ASPAC or ASPIA) or Data 2159 messages or it will risk message loss. If the SG receives Data 2160 messages before an ASP Up is received, the SG SHOULD discard. 2162 4.3.3.2 ASP Down 2164 The ASP will send an ASP Down to an SG when the ASP is to be removed 2165 from the list of ASPs in all Application Servers that it is a member 2166 and no longer receive any M2UA traffic or management messages. 2168 Whether the ASP is permanently removed from an AS is a function of 2169 configuration management. 2171 The SG marks the ASP as "Down" and returns an ASP Down Ack message to 2172 the ASP if one of the following events occur: 2174 - an ASP Down message is received from the ASP, 2175 - another ASPM message is received from the ASP and the SG has 2176 locked out the ASP for management reasons. 2178 The SG sends anASP Down Ack message in response to a received ASP Down 2179 message from the ASP even if the ASP is already marked as "Down" at 2180 the SG. 2182 If the ASP does not receive a response from the SG, the ASP MAY send 2183 ASP Down messages every 2 seconds until it receives an ASP Down Ack 2184 message from the SG or the SCTP association goes down. The ASP MAY 2185 decide to reduce the frequency (say to every 5 seconds) if an ASP Down 2186 Ack is not received after a few tries. 2188 4.3.3.3 M2UA Version Control 2190 If a ASP Up message with an unsupported version is received, the 2191 receiving end responds with an Error message, indicating the version the 2192 receiving node supports. 2194 This is useful when protocol version upgrades are being performed in a 2195 network. A node upgraded to a newer version SHOULD support the older 2196 versions used on other nodes it is communicating with. Because ASPs 2197 initiate the ASP Up procedure it is assumed that the Error message would 2198 normally come from the SG. 2200 4.3.3.4 ASP-Active 2202 Any time after the ASP has received a ASP Up Ack from the SG, the ASP 2203 sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready 2204 to start processing traffic. In the case where an ASP is configured/- 2205 registered to process the traffic for more than one Application Server 2206 across an SCTP association, the ASPAC contains one or more Interface 2207 Identifiers to indicate for which Application Servers the ASPAC applies. 2209 When an ASP Active (ASPAC) message is received, the SG responds to the 2210 ASP with a ASPAC Ack message acknowledging that the ASPAC was received 2211 and starts sending traffic for the associated Application Server(s) 2212 to that ASP. 2214 The ASP MUST wait for the ASP-Active Ack message from the SG before 2215 sending any Data messages or it will risk message loss. If the SG 2216 receives MAUP messages before an ASP Active is received, the SG SHOULD 2217 discard these messages. 2219 There is one mode of Application Server traffic handling in the SG 2220 M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the 2221 mode used in a particular Application Server. If the SG determines that 2222 the mode indicates in an ASPAC is incompatible with the traffic handling 2223 mode currently used in the AS, the SG responds with an Error message 2224 indicating Unsupported Traffic Handling Mode. 2226 For Over-ride mode AS, the reception of an ASPAC message at an SG causes 2227 the redirection of all traffic for the AS to the ASP that sent the ASPAC. 2228 The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. 2229 Any previously active ASP in the AS is now considered Inactive and will 2230 no longer receive traffic from the SG within the AS. The SG sends a 2231 Notify (Alternate ASP-Active) to the previously active ASP in the AS, 2232 after stopping all traffic to that ASP. 2234 4.3.3.5 ASP Inactive 2236 When an ASP wishes to withdraw from receiving traffic within an AS, 2237 the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where 2238 an ASP is configured/registered to process the traffic for more than 2239 one Application Server across an SCTP association, the ASPIA contains 2240 one or more Interface Ids to indicate for which Application Servers 2241 the ASPIA applies. 2243 There is one mode of Application Server traffic handling in the SG 2244 M2UA when withdrawing an ASP from service - Over-ride. The Type 2245 parameter in the ASPIA messge indicates the mode used in a particular 2246 Application Server. If the SG determines that the mode indicates in an 2247 ASPAC is incompatible with the traffic handling mode currently used in 2248 the AS, the SG responds with an Error message indicating Unsupported 2249 Traffic Handling Mode. 2251 In the case of an Over-ride mode AS, where normally another ASP has 2252 already taken over the traffic within the AS with an Over-ride ASPAC, 2253 the ASP which sends the ASPIA is already considered by the SG to be 2254 "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is 2255 sent to the ASP, after ensuring that all traffic is stopped to the ASP. 2257 If no other ASPs are Active in the Application Server, the SG either 2258 discards all incoming messages for the AS or starts buffering the 2259 incoming messages for T(r)seconds, after which messages will be 2260 discarded. T(r) is configurable by the network operator. If the SG 2261 receives an ASPAC from an ASP in the AS before expiry of T(r), the 2262 buffered traffic is directed to the ASP and the timer is cancelled. 2263 If T(r) expires, the AS is moved to the "Down" state. 2265 4.3.3.6 Notify 2267 A Notify message reflecting a change in the AS state is sent to all 2268 ASPs in the AS, except those in the "Down" state, with appropriate 2269 Status Identification. 2271 In the case where a Notify (AS-Pending) message is sent by an SG 2272 that now has no ASPs active to service the traffic, the Notify does 2273 not explicitly force the ASP(s) receiving the message to become 2274 active. The ASPs remain in control of what (and when) action is 2275 taken. 2277 4.3.3.6 Heartbeat 2279 The optional Heartbeat procedures MAY be used when operating over 2280 transport layers that do not have their own heartbeat mechanism for 2281 detecting loss of the transport association (i.e., other than the 2282 SCTP). 2284 After receiving an ASP Up Ack message from the SG in response to an 2285 ASP Up message, the ASP MAY optionally send Beat messages periodically, 2286 subject to a provisionable timer T(beat). The SG M2UA, upon receiving 2287 a BEAT message from the ASP, responds with a BEAT ACK message. If no 2288 BEAT message (or any other M2UA message) is received from the ASP 2289 within the timer 2*T(beat), the SG will consider the remote M2UA as 2290 "Down". The SG will also send an ASP Down Ack message to the ASP. 2292 At the ASP, if no BEAT ACK message (or any other M2UA message) is 2293 received from the SG within 2*T(beat), the SG is considered 2294 unavailable. Transmission of BEAT messages is stopped and ASP Up 2295 procedures are used to re-establish communication with the SG M2UA 2296 peer. 2298 The BEAT message MAY optionally contain an opaque Heartbeat Data 2299 parameter that MUST be echoed back unchanged in the related Beat 2300 Ack message. The ASP upon examining the contents of the returned 2301 BEAT Ack message MAY choose to consider the remote ASP as 2302 unavailable. The contents/format of the Heartbeat Data parameter is 2303 implementation-dependent and only of local interest to the original 2304 sender. The contents MAY be used, for example, to support a 2305 Heartbeat sequence algorithm (to detect missing Heartbeats), and/or 2306 a timestamp mechanism (to evaluate delays). 2308 Note: Heartbeat related events are not shown in Figure 4 "ASP state 2309 transition diagram". 2311 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 2313 5.1 Establishment of associations between SG and MGC examples 2315 5.1.1 Single ASP in an Application Server (1+0 sparing) 2317 This scenario shows the example M2UA message flows for the establishment 2318 of traffic between an SG and an ASP, where only one ASP is configured 2319 within an AS (no backup). It is assumed that the SCTP association is 2320 already set-up. 2322 SG ASP1 2323 | 2324 |<---------ASP Up----------| 2325 |--------ASP Up Ack------->| 2326 | | 2327 |<-------ASP Active--------| 2328 |------ASP_Active Ack----->| 2329 | | 2331 5.1.2 Two ASPs in Application Server (1+1 sparing) 2333 This scenario shows the example M2UA message flows for the establishment 2334 of traffic between an SG and two ASPs in the same Application Server, 2335 where ASP1 is configured to be �active� and ASP2 a standby in the event 2336 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 2337 act as a hot, warm, or cold standby depending on the extent to which ASP1 2338 and ASP2 share call/transaction state or can communicate call state under 2339 failure/withdrawal events. 2341 SG ASP1 ASP2 2342 | | | 2343 |<--------ASP Up----------| | 2344 |-------ASP Up Ack------->| | 2345 | | | 2346 |<-----------------------------ASP Up----------------| 2347 |----------------------------ASP Up Ack------------->| 2348 | | | 2349 | | | 2350 |<-------ASP Active-------| | 2351 |-----ASP-Active Ack----->| | 2352 | | | 2354 5.2 ASP Traffic Fail-over Examples 2356 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2358 Following on from the example in Section 5.1.2, and ASP withdraws from 2359 service: 2361 SG ASP1 ASP2 2362 | | | 2363 |<-----ASP Inactive-------| | 2364 |----ASP Inactive Ack---->| | 2365 |--------------------NTFY(AS-Down) (Optional)------->| 2366 | | | 2367 |<------------------------------ ASP Active----------| 2368 |-----------------------------ASP-Active Ack)------->| 2369 | | 2371 In this case, the SG notifies ASP2 that the AS has moved to the 2372 Down state. The SG could have also (optionally) sent a Notify 2373 message when the AS moved to the Pending state. 2375 Note: If the SG detects loss of the M2UA peer (M2UA heartbeat loss or 2376 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 2377 exchange would not occur. 2379 5.2.2 (1+1 Sparing, Back-up Over-ride) 2381 Following on from the example in Section 5.1.2, and ASP2 wishes to over- 2382 ride ASP1 and take over the traffic: 2384 SG ASP1 ASP2 2385 | | | 2386 |<------------------------------ ASP Active----------| 2387 |-----------------------------ASP-Active Ack-------->| 2388 |----NTFY( Alt ASP-Act)-->| 2389 | (optional) | | 2391 In this case, the SG notifies ASP1 that an alternative ASP has 2392 overridden it. 2394 5.3 SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 2396 When the M2UA layer on the ASP has a MAUP message to send to the SG, it 2397 will do the following: 2399 - Determine the correct SG 2401 - Find the SCTP association to the chosen SG 2403 - Determine the correct stream in the SCTP association based on 2404 the SS7 link 2406 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2407 Common Header 2409 - Send the MAUP message to the remote M2UA peer in the SG, over the 2410 SCTP association 2412 When the M2UA layer on the SG has a MAUP message to send to the ASP, it 2413 will do the following: 2415 - Determine the AS for the Interface Identifier 2417 - Determine the Active ASP (SCTP association) within the AS 2419 - Determine the correct stream in the SCTP association based on 2420 the SS7 link 2422 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2423 Common Header 2425 - Send the MAUP message to the remote M2UA peer in the ASP, over the 2426 SCTP association 2428 5.3.1 SS7 Link Alignment 2430 The MGC can request that a SS7 link be brought into alignment using the 2431 normal or emergency procedure. An example of the message flow to bring 2432 a SS7 link in-service using the normal alignment procedure is shown 2433 below. 2435 MTP2 M2UA M2UA MTP3 2436 SG SG ASP ASP 2438 <----Start Req---|<---Establish Req----|<----Start Req------ 2440 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 2442 An example of the message flow to bring a SS7 link in-service using the 2443 emergency alignment procedure. 2445 MTP2 M2UA M2UA MTP3 2446 SG SG ASP ASP 2448 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 2450 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 2452 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 2454 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 2456 5.3.2 SS7 Link Release 2458 The MGC can request that a SS7 link be taken out-of-service. It uses 2459 the Release Request message as shown below. 2461 MTP2 M2UA M2UA MTP3 2462 SG SG ASP ASP 2464 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 2466 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 2468 The SG can autonomously indicate that a SS7 link has gone out-of-service 2469 as shown below. 2471 MTP2 M2UA M2UA MTP3 2472 SG SG ASP ASP 2474 --Out of Serv->|----Release Ind----->|--Out of Serv--> 2476 5.3.3 Set and Clear Local Processor Outage 2478 The MGC can set a Local Processor Outage condition. It uses the 2479 State Request message as shown below. 2481 MTP2 M2UA M2UA MTP3 2482 SG SG ASP ASP 2484 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 2486 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 2488 The MGC can clear a Local Processor Outage condition. It uses the 2489 State Request message as shown below. 2491 MTP2 M2UA M2UA MTP3 2492 SG SG ASP ASP 2494 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 2496 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 2498 5.3.4 Notification of Remote Processor Outage 2500 The SG can indicate Remote has entered or exited the Processor Outage 2501 condition. It uses the State Indication message as shown below. 2503 MTP2 M2UA M2UA MTP3 2504 SG SG ASP ASP 2506 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 2508 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 2510 5.3.5 Notification of Link Congestion 2512 The SG can indicate that a link has become congested. It uses the State 2513 Indication message as shown below. 2515 MTP2 M2UA M2UA MTP3 2516 SG SG ASP ASP 2518 ----Cong Ind---->|--State Ind (EVENT_CONG_ENTER)->|----Cong Ind----> 2520 -Cong Cease Ind->|--State Ind (EVENT_CONG_EXIT)-->|-Cong Cease Ind-> 2522 5.3.6 SS7 Link Changeover 2524 An example of the message flow for an error free changeover is shown 2525 below. In this example, there were three messages in the retransmission 2526 queue that needed to be retrieved. 2528 MTP2 M2UA M2UA MTP3 2529 SG SG ASP ASP 2531 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2532 (seq_num = 0) 2534 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2535 (seq_num = BSN) 2537 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2538 (seq_num = FSN) 2540 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2541 (seq_num = 0) 2543 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2544 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2545 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2547 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 2549 Note: The number of Retrieval Indication is dependent on the number of 2550 messages in the retransmit queue that have been requested. Only one 2551 Retrieval Complete Indication SHOULD be sent. 2553 An example of a message flow with an error retrieving the BSN is shown 2554 below. 2556 MTP2 M2UA M2UA MTP3 2557 SG SG ASP ASP 2559 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2561 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 2562 (seq_num = -1) 2564 An example of a message flow with an error retrieving the messages is 2565 shown below. 2567 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2569 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2570 (seq_num = BSN) 2572 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2573 (seq_num = FSN) 2575 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2576 (seq_num = -1) 2578 An example of a message flow for a request to drop messages (clear 2579 retransmission buffers) is shown below. 2581 MTP2 M2UA M2UA MTP3 2582 SG SG ASP ASP 2584 <-Clr RTB Req-|<--Rtrv Req (ACTION_DROP_MSGS)--|<--Clr RTB Req--- 2586 -Clr RTB Ind->|---Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr RTB Ind--> 2588 5.3.7 Flush and Continue 2590 The following message flow shows a request to flush buffers. 2592 MTP2 M2UA M2UA MTP3 2593 SG SG ASP ASP 2595 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 2597 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 2599 The following message flow shows a request to continue. 2601 MTP2 M2UA M2UA MTP3 2602 SG SG ASP ASP 2604 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 2606 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 2608 6.0 Security 2610 M2UA is designed to carry signaling messages for telephony services. As such, 2611 M2UA MUST involve the security needs of several parties: the end users 2612 of the services; the network providers and the applications involved. 2613 Additional requirements MAY come from local regulation. While having some 2614 overlapping security needs, any security solution SHOULD fulfill all of the 2615 different parties' needs. 2617 6.1 Threats 2619 There is no quick fix, one-size-fits-all solution for security. As a 2620 transport protocol, M2UA has the following security objectives: 2622 * Availability of reliable and timely user data transport. 2623 * Integrity of user data transport. 2624 * Confidentiality of user data. 2626 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 2627 security features, such as: 2629 * Blind Denial of Service Attacks 2630 * Flooding 2631 * Masquerade 2632 * Improper Monopolization of Services 2634 When M2UA is running in professionally managed corporate or service 2635 provider network, it is reasonable to expect that this network includes 2636 an appropriate security policy framework. The "Site Security Handbook" [9] 2637 SHOULD be consulted for guidance. 2639 When the network in which M2UA runs in involves more than one party, it 2640 MAY NOT be reasonable to expect that all parties have implemented security 2641 in a sufficient manner. In such a case, it is recommended that IPSEC is 2642 used to ensure confidentiality of user payload. Consult [10] for more 2643 information on configuring IPSEC services. 2645 6.2 Protecting Confidentiality 2647 Particularly for mobile users, the requirement for confidentiality MAY 2648 include the masking of IP addresses and ports. In this case application 2649 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 2650 Regardless of which level performs the encryption, the IPSEC ISAKMP 2651 service SHOULD be used for key management. 2653 7.0 IANA Considerations 2655 7.1 SCTP Payload Protocol Identifier 2657 A request will be made to IANA to assign an M2UA value for the Payload 2658 Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload 2659 Protocol Identifier will be registered: 2661 M2UA 0x10 2663 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 2664 to indicate which protocol the SCTP is carrying. This Payload Protocol 2665 Identifier is not directly used by SCTP but MAY be used by certain network 2666 entities to identify the type of information being carried in a Data chunk. 2668 The User Adaptation peer MAY use the Payload Protocol Identifier as a way 2669 of determining additional information about the data being presented to it 2670 by SCTP. 2672 7.2 M2UA Protocol Extensions 2674 This protocol may also be extended through IANA in three ways: 2676 -- through definition of additional message classes, 2677 -- through definition of additional message types, and 2678 -- through definition of additional message parameters. 2680 The definition and use of new message classes, types and parameters is 2681 an integral part of SIGTRAN adaptation layers. Thus, these extensions 2682 are assigned by IANA through an IETF Consensus action as defined in 2683 [RFC2434]. 2685 The proposed extension must in no way adversely affect the general 2686 working of the protocol. 2688 7.2.1 IETF Defined Message Classes 2690 The documentation for a new message class MUST include the following 2691 information: 2693 (a) A long and short name for the message class. 2694 (b) A detailed description of the purpose of the message class. 2696 7.2.2 IETF Defined Message Types 2698 Documentation of the message type MUST contain the following information: 2700 (a) A long and short name for the new message type. 2701 (b) A detailed description of the structure of the message. 2702 (c) A detailed definition and description of intended use of each field 2703 within the message. 2704 (d) A detailed procedural description of the use of the new message type 2705 within the operation of the protocol. 2706 (e) A detailed description of error conditions when receiving this message 2707 type. 2709 When an implementation receives a message type which it does not support, 2710 it MUST respond with an Error (ERR) message with an Error Code of 2711 Unsupported Message Type. 2713 7.2.3 IETF-defined TLV Parameter Extension 2715 Documentation of the message parameter MUST contain the following 2716 information: 2718 (a) Name of the parameter type. 2719 (b) Detailed description of the structure of the parameter field. This 2720 structure MUST conform to the general type-length-value format 2721 described in Section 3.1.5. 2722 (c) Detailed definition of each component of the parameter value. 2723 (d) Detailed description of the intended use of this parameter type, 2724 and an indication of whether and under what circumstances 2725 multiple instances of this parameter type may be found within the 2726 same message type. 2728 8.0 Acknowledgements 2730 The authors would like to thank John Loughney, Neil Olson, Michael 2731 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 2732 Prantner, Barry Nagelberg, Naoto Makinae and Brian Bidulock for their 2733 valuable comments and suggestions. 2735 9.0 References 2737 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 2738 System No. 7 (SS7)' 2740 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 2741 Message Transfer Part (MTP)' 2743 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 2745 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 2746 of Signaling System Number 7', Volume 1, December 1995 2748 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 2750 [6] Architectural Framework for Signaling Transport, RFC 2719, 2751 October 1999 2753 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February 2754 1995 2756 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 2757 functions and messages using the services of ITU-T 2758 Recommendation Q.2140', August 1995 2760 [9] Site Security Handbook, RFC 2196, September 1997 2762 [10] Security Architecture for the Internet Protocol, RFC 2401 2764 10.0 Issues To Be Addressed 2766 1. SCTP failure (what does M2UA on SG and MGC do) 2768 2. SCTP congestion (what does M2UA on SG and MGC do) 2770 3. PRI/LI octet for TTC 2772 4. auditing of link state 2774 5. M2UA loses connectivity with MTP2 on SG 2776 a. autonomously sends LPO to MTP3, or 2778 b. sends LPO to MTP3 in response to Release Req (Stop) 2780 6. How to indicate failure to perform State Request 2781 (vs. current method of not sending State Confirm) 2783 7. Use of "high priority" stream for link state 2784 messages (i.e. congestion) 2786 9. Adding text for T(ack) timer for ASP UP message 2788 9. Response in reply to Indication messages? 2789 10.0 Author's Addresses 2791 Ken Morneault Tel: +1-703-484-3323 2792 Cisco Systems Inc. EMail: kmorneau@cisco.com 2793 13615 Dulles Technology Drive 2794 Herndon, VA. 20171 2795 USA 2797 Ram Dantu, Ph.D. Tel +1-469-255-0716 2798 Cisco Systems EMail rdantu@cisco.com 2799 17919 Waterview 2800 Dallas, TX 75252 2801 USA 2803 Malleswar Kalla Tel: +1-973-829-5212 2804 Telcordia Technologies EMail: kalla@research.telcordia.com 2805 MCC 1J211R 2806 445 South Street 2807 Morristown, NJ 07960 2808 USA 2810 Greg Sidebottom Tel: +1-613-763-7305 2811 Nortel Networks EMail: gregside@nortelnetworks.com 2812 3685 Richmond Rd, 2813 Nepean, Ontario 2814 Canada K2H5B7 2816 Tom George Tel: +1-972-519-3168 2817 Alcatel USA EMail: tom.george@usa.alcatel.com 2818 1000 Coit Road 2819 Plano, TX 74075 2820 USA 2822 This Internet Draft expires April 2001.