idnits 2.17.1 draft-ietf-sigtran-m2ua-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 19) being 417 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 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 59 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 23: '... that other groups MAY also distribute...' RFC 2119 keyword, line 27: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 91: '...mechanism SHOULD meet the following cr...' RFC 2119 keyword, line 148: '...ver Process. Fail-back MAY apply upon...' RFC 2119 keyword, line 231: '...Note: STPs MAY be present in the SS7 p...' (87 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 360 has weird spacing: '...e hosts and t...' == Line 2311 has weird spacing: '...essages until...' == Line 2353 has weird spacing: '...essages until...' == Line 2395 has weird spacing: '...PIA Ack messa...' == Line 2400 has weird spacing: '...essages until...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the network in which M2UA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [11] for more information on configuring IPSEC services. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 2001) is 8471 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 728 -- Looks like a reference, but probably isn't: 'M3UA' on line 770 -- Looks like a reference, but probably isn't: 'IUA' on line 775 -- Looks like a reference, but probably isn't: 'M2UA' on line 776 -- Looks like a reference, but probably isn't: 'SUA' on line 778 -- Looks like a reference, but probably isn't: 'RFC2434' on line 2865 == Unused Reference: '1' is defined on line 2919, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2938, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '10') ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) -- Possible downref: Normative reference to a draft: ref. '12' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Ram Dantu 3 Cisco Systems 4 Greg Sidebottom 5 Nortel Networks 6 Tom George 7 Alcatel 8 Brian Bidulock 9 OpenSS7 10 Jacob Heitz 11 Lucent 13 Expires in six months Feb 2001 15 SS7 MTP2-User Adaptation Layer 16 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC 2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups MAY also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and MAY be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as 'work in progress'. 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To learn the current status of any Internet-Draft, please check the 38 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 39 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Abstract 45 This Internet Draft defines a protocol for backhauling of SS7 MTP2 46 User signaling messages over IP using the Stream Control 47 Transmission Protocol (SCTP). This protocol would be used between a 48 Signaling Gateway (SG) and Media Gateway Controller (MGC). It is 49 assumed that the SG receives SS7 signaling over a standard SS7 50 interface using the SS7 Message Transfer Part (MTP) to provide 51 transport. The Signaling Gateway would act as a Signaling Link 52 Terminal. 54 TABLE OF CONTENTS 56 1. Introduction..............................................2 57 1.1 Scope..................................................2 58 1.2 Terminology............................................3 59 1.3 Signaling Transport Architecture.......................3 60 1.4 Services Provide by the M2UA Adaptation Layer..........6 61 1.5 Function Provided by the M2UA Layer....................8 62 1.6 Definition of the M2UA Boundaries......................9 63 2. Conventions...............................................9 64 3. Protocol Elements.........................................9 65 3.1 Common Message Header.................................10 66 3.2 M2UA Message Header...................................11 67 3.3 M2UA Messages.........................................11 68 4. Procedures...............................................20 69 4.1 Procedures to Support Service in Section 1.4.1........20 70 4.2 Procedures to Support Service in Section 1.4.2........21 71 4.3 Procedures to Support Service in Section 1.4.3........21 72 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 73 5.1 Establishment of associations between SG and MGC......26 74 examples 75 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 76 5.3 Layer Management Communication Examples...............29 77 6. Security.................................................30 78 7. IANA Considerations......................................31 79 7.1 SCTP Payload Protocol Identifier.......................31 80 7.2 IUA Protocol Extensions................................31 81 8. Acknowledgements.........................................31 82 9. References...............................................32 83 10. Author's Addresses.......................................33 84 1. Introduction 86 1.1 Scope 88 There is a need for Switched Circuit Network SCN signaling protocol 89 delivery from an Signaling Gateway (SG) to a Media Gateway 90 Controller (MGC) or IP Signaling Point (IPSP). The delivery 91 mechanism SHOULD meet the following criteria: 93 * Support for MTP Level 2 / MTP Level 3 interface boundary 94 * Support for communication between Layer Management modules on SG 95 and MGC 96 * Support for management of active associations between the SG and MGC 98 In other words, the Signaling Gateway will transport MTP Level 3 99 messages to a Media Gateway Controller (MGC) or IP Signaling Point 100 (IPSP). In the case of delivery from an SG to an IPSP, both the SG and 101 IPSP function as traditional SS7 nodes using the IP network as a new 102 type of SS7 link. This allows for full MTP Level 3 message handling 103 and network management capabilities. 105 1.2 Terminology 107 MTP2-User - A protocol that normally uses the services of MTP Level 2 108 (i.e. MTP3). 110 Interface - For the purposes of this document, an interface is a SS7 111 signaling link. 113 Backhaul - Refers to the transport of signaling from the point of 114 interface for the associated data stream (i.e., SG function in the MGU) 115 back to the point of call processing (i.e., the MGCU), if this is not 116 local [4]. 118 Association - An association refers to a SCTP association. The 119 association will provide the transport for the delivery of protocol 120 data units for one or more interfaces. 122 Stream - A stream refers to an SCTP stream; a uni-directional logical 123 channel established from one SCTP endpoint to another associated SCTP 124 endpoint, within which all user messages are delivered in-sequence 125 except for those submitted to the un-ordered delivery service. 127 Interface Identifier - The Interface Identifier identifies the physical 128 interface at the SG for which the signaling messages are sent/received. 129 The format of the Interface Identifier parameter can be text or integer, 130 the values of which are assigned according to network operator policy. 131 The values used are of local significance only, coordinated between the 132 SG and ASP. 134 Application Server (AS) - A logical entity serving a specific application 135 instance. An example of an Application Server is a MGC handling the 136 MTP Level 3 and call processing for SS7 links terminated by the 137 Signaling Gateways. Practically speaking, an AS is modeled at the SG 138 as an ordered list of one or more related Application Server Processes 139 (e.g., primary, secondary, tertiary, ...). 141 Application Server Process (ASP) - A process instance of an Application 142 Server. Examples of Application Server Processes are primary or backup 143 MGC instances. 145 Fail-over - The capability to re-route signaling traffic as required 146 to an alternate Application Server Process, or group of ASPs, within 147 an Application Server in the event of failure or unavailability of a 148 currently used Application Server Process. Fail-back MAY apply upon 149 the return to service of a previously unavailable Application Server 150 Process. 152 Signaling Link Terminal (SLT) - Refers to the means of performing all 153 of the functions defined at MTP level 2 regardless of their 154 implementation [2]. 156 Layer Management - Layer Management is a nodal function in an SG or 157 ASP that handles the inputs and outputs between the M2UA layer and a 158 local management entity. 160 MTP - The Message Transfer Part of the SS7 protocol. 162 MTP2 - MTP Level 2, the signalling datalink layer of SS7 164 MTP3 - MTP Level 3, the signalling network layer of SS7 166 Network Byte Order: Most significant byte first, a.k.a Big Endian. 168 Host - The computing platform that the ASP process is running on. 170 1.3 M2UA Overview 172 The framework architecture that has been defined for SCN signaling 173 transport over IP [6] uses multiple components, including a signaling 174 common transport protocol and an adaptation module to support the 175 services expected by a particular SCN signaling protocol from its 176 underlying protocol layer. 178 Within this framework architecture, this document defines a SCN 179 adaptation module that is suitable for the transport of SS7 MTP2 User 180 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 181 of the Stream Control Transmission Protocol [5] as the underlying 182 reliable signaling common transport protocol. 184 In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling 185 is transmitted and received from the PSTN over a standard SS7 network 186 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 187 to provide reliable transport of the MTP3-User signaling messages to and 188 from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). 189 The SG then provides a functional inter-working of transport functions 190 with the IP transport, in order to transfer the MTP2-User signaling 191 messages to and from an Application Server Process where the peer MTP2- 192 User protocol layer exists. 194 1.3.1 Example - SG to MGC 196 In a Signaling Gateway, it is expected that the SS7 signaling is 197 received over a standard SS7 network termination, using the SS7 Message 198 Transfer Part (MTP) to provide transport of SS7 signaling messages to 199 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 200 Point (STP). In other words, the SG acts as a Signaling Link Terminal 201 (SLT) [2]. The SG then provides interworking of transport functions 202 with IP Signaling Transport, in order to transport the MTP3 signaling 203 messages to the MGC where the peer MTP3 protocol layer exists, as shown 204 below: 206 ****** SS7 ****** IP ******* 207 *SEP *-----------* SG *-------------* MGC * 208 ****** ****** ******* 210 +----+ +----+ 211 |S7UP| |S7UP| 212 +----+ +----+ 213 |MTP + |MTP | 214 | L3 | (NIF) |L3 | 215 +----+ +----+----+ +----+ 216 |MTP | |MTP |M2UA| |M2UA| 217 | | | +----+ +----+ 218 |L2 | |L2 |SCTP| |SCTP| 219 |L1 | |L1 +----+ +----+ 220 | | | |IP | |IP | 221 +----+ +---------+ +----+ 223 NIF - Nodal Interworking Function 224 SEP - SS7 Signaling Endpoint 225 IP - Internet Protocol 226 SCTP - Stream Control Transmission Protocol 227 (Refer to Reference [5]) 229 Figure 1 M2UA in the SG to MGC Application 231 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 233 It is recommended that the M2UA use the services of the Stream 234 Control Transmission Protocol (SCTP) as the underlying reliable 235 common signaling transport protocol. The use of SCTP provides 236 the following features: 238 - explicit packet-oriented delivery (not stream-oriented) 239 - sequenced delivery of user messages within multiple streams, 240 with an option for order-of-arrival delivery of individual 241 user messages, 242 - optional multiplexing of user messages into SCTP datagrams, 243 - network-level fault tolerance through support of multi-homing 244 at either or both ends of an association, 245 - resistance to flooding and masquerade attacks, and 246 - data segmentation to conform to discovered path MTU size 248 There are scenarios without redundancy requirements and 249 scenarios in which redundancy is supported below the transport 250 layer. In these cases, the SCTP functions above MAY NOT be a 251 requirement and TCP can be used as the underlying common 252 transport protocol. 254 1.3.2 Support for the management of SCTP associations between the SG 255 and ASPs 257 The M2UA layer at the SG maintains the availability state of all 258 dynamically registered remote ASPs, in order to manage the SCTP 259 Associations and the traffic between the SG and ASPs. As well, the 260 active/inactive state of remote ASP(s) are also maintained. Active 261 ASPs are those currently receiving traffic from the SG. 263 The M2UA layer MAY be instructed by local management to establish an 264 SCTP association to a peer M2UA node. This can be achieved using the M- 265 SCTP ESTABLISH primitive to request, indicate and confirm the 266 establishment of an SCTP association with a peer M2UA node. 268 The M2UA layer MAY also need to inform local management of the status of 269 the underlying SCTP associations using the M-SCTP STATUS request and 270 indication primitive. For example, the M2UA MAY inform local management 271 of the reason for the release of an SCTP association, determined either 272 locally within the M2UA layer or by a primitive from the SCTP. 274 1.3.3 Signaling Network Architecture 276 A Signaling Gateway will support the transport of MTP2-User signaling 277 traffic received from the SS7 network to one or more distributed ASPs 278 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 279 meet any performance and reliability requirements for such transport. 280 A physical network architecture is required, with data on the 281 availability and transfer performance of the physical nodes involved in 282 any particular exchange of information. However, the M2UA protocol MUST 283 be flexible enough allow its operation and management in a variety of 284 physical configurations that will enable Network Operators to meet 285 their performance and reliability requirements. 287 To meet the stringent SS7 signaling reliability and performance 288 requirements for carrier grade networks, these Network Operators SHOULD 289 ensure that there is no single point of failure provisioned in the end- 290 to-end network architecture between an SS7 node and an IP ASP. 292 Depending of course on the reliability of the SG and ASP functional 293 elements, this can typically be met by the spreading links in a linkset 294 across SGs, the provision of redundant QOS-bounded IP network paths for 295 SCTP Associations between SCTP End Points, and redundant Hosts. The 296 distribution of ASPs within the available Hosts is also important. For a 297 particular Application Server, the related ASPs SHOULD be distributed over 298 at least two Hosts. 300 An example logical network architecture relevant to carrier-grade 301 operation in the IP network domain is shown in Figure 2 below: 303 ******** ************** 304 * *_________________________________________* ******** * Host1 305 * * _________* * ASP1 * * 306 * SG1 * SCTP Associations | * ******** * 307 * *_______________________ | * * 308 ******** | | ************** 309 | | 310 ******** | | 311 * *_______________________________| 312 * * | 313 * SG2 * SCTP Associations | 314 * *____________ | 315 * * | | 316 ******** | | ************** 317 | |_________________* ******** * Host2 318 |____________________________* * ASP1 * * 319 * ******** * 320 * * 321 ************** 322 . 323 . 324 . 326 Figure 2 - Logical Model Example 328 For carrier grade networks, Operators SHOULD ensure that under failure 329 or isolation of a particular ASP, stable calls or transactions are not 330 lost. This implies that ASPs need, in some cases, to share the call/- 331 transaction state or be able to pass the call/transaction state between 332 each other. Also, in the case of ASPs performing call processing, 333 coordination MAY be required with the related Media Gateway to transfer 334 the MGC control for a particular trunk termination. However, this 335 sharing or communication is outside the scope of this document. 337 1.3.4 ASP Fail-over Model and Terminology 339 The M2UA layer supports ASP fail-over functions in order to support a 340 high availability of call and transaction processing capability. All 341 MTP2-User messages incoming to an SG from the SS7 network are assigned 342 to a unique Application Server, based on the Interface Identifier of 343 the message. 345 The Application Server is in practical terms a list of all ASPs currently 346 registered to process MTP2-User messages from certain Interface 347 Identifiers. One or more ASPs in the list are normally active (i.e., 348 handling traffic) while any others MAY be unavailable or inactive, to be 349 possibly used in the event of failure or unavailability of the active 350 ASP(s). 352 The M2UA fail-over model supports an 1+k redundancy model, where 1 ASPs 353 is the minimum number of redundant ASPs required to handle traffic and 354 k ASPs are available to take over for a failed or unavailable ASP. 355 Note that 1+1 active/standby redundancy is a subset of this model. 356 A simplex 1+0 model is also supported as a subset, with no ASP 357 redundancy. 359 To avoid a single point of failure, it is recommended that a minimum of 360 two ASPs be in the list, resident in separate hosts and therefore 361 available over different SCTP Associations. For example, in the 362 network shown in Figure 2, all messages for the Interface Identifiers 363 could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1 364 might look like the following: 366 Interface Identiers - Application Server #1 367 ASP1/Host1 - State = Active 368 ASP1/Host2 - State = Inactive 370 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 371 message for the Interface Identifiers registered. ASP1 in Host2 would 372 normally be brought to the active state upon failure of, or loss of 373 connectivity to, ASP1/Host1. In this example, both ASPs are Inactive 374 or Active, meaning that the related SCTP association and far-end M2UA 375 peer is ready. 377 The two ASPs MAY share state information via shared memory, or MAY 378 use an ASP to ASP protocol to pass state information. The ASP to ASP 379 protocol is outside the scope of this document. 381 1.3.5 Client/Server Model 383 It is recommended that the SG and ASP be able to support both client 384 and server operation. The peer endpoints using M2UA SHOULD be 385 configured so that one always takes on the role of client and the 386 other the role of server for initiating SCTP associations. The 387 default orientation would be for the SG to take on the role of server 388 while the ASP is the client. In this case, ASPs SHOULD initiate the 389 SCTP association to the SG. 391 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA 392 is 2904. 394 1.4 Services Provided by the M2UA Adaptation Layer 396 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 397 point in the IP network, so that the M2UA protocol layer is required to 398 provide the equivalent set of services to its users as provided by the 399 MTP Level 2 to MTP Level 3. 401 This includes the following services: 403 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 405 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 406 a seamless, or as seamless as possible, operation of the MTP2-User peers 407 in the SS7 and IP domains. An example of the primitives that must be 408 supported can be found in [7]. 410 1.4.2 Support for communication between Layer Management modules 411 on SG and MGC 413 It is envisioned that the M2UA layer needs to provide some messages that 414 will facilitate communication between Layer Management modules on the SG 415 and MGC. These primitives are shown below: 417 To facilitate reporting of errors that arise because of backhauling MTP 418 Level 3 scenario, the following primitive is defined: 420 M-ERROR 422 The M-ERROR message is used to indicate an error with a received 423 M2UA message (e.g., interface identifier value is not known to the SG). 425 1.4.3 Support for management of active associations between SG and MGC 427 The M2UA layer on the SG keeps the state of various ASPs it is associated 428 with. A set of primitives between M2UA layer and the Layer Management 429 are defined below to help the Layer Management manage the association(s) 430 between the SG and the MGC. The M2UA layer can be instructed 431 by the Layer Management to establish a SCTP association to a peer M2UA 432 node. This procedure can be achieved using the M-SCTP ESTABLISH 433 primitive. 435 M-SCTP ESTABLISH 437 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 438 the establishment of a SCTP association to a peer M2UA node. 440 M-SCTP RELEASE 442 The M-SCTP RELEASE primitives are used to request, indicate, and 443 confirm the release of a SCTP association to a peer M2UA node. 445 The M2UA layer MAY also need to inform the status of the SCTP 446 association(s) to the Layer Management. This can be achieved using 447 the following primitive. 449 M-SCTP STATUS 451 The M-SCTP STATUS primitive is used to request and indicate the status 452 of underlying SCTP association(s). 454 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 455 status (i.e., failure, active, etc.), so that messages can be exchanged 456 between M2UA layer peers to stop traffic to the local M2UA user. This 457 can be achieved using the following primitive. 459 M-ASP STATUS 461 The ASP status is stored inside M2UA layer on both the SG and MGC 462 sides. The M-ASP STATUS primitive can be used by Layer Management to 463 request the status of the Application Server Process from the M2UA 464 layer. This primitive can also be used to indicate the status of the 465 Application Server Process. 467 M-ASP MODIFY 469 The M-ASP MODIFY primitive can be used by Layer Management to modify 470 the status of the Application Server Process. In other words, the 471 Layer Management on the ASP side uses this primitive to initiate 472 the ASPM procedures. 474 M-AS STATUS 476 The M-AS STATUS primitive can be used by Layer Management to request 477 the status of the Application Server. This primitive can also be 478 used to indicate the status of the Application Server. 480 1.5 Functions Provided by the M2UA Layer 482 1.5.1 Mapping 484 The M2UA layer MUST maintain a map of a Interface ID to a physical 485 interface on the Signaling Gateway. A physical interface would be a 486 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 487 MUST also maintain a map of Interface Identifier to SCTP association 488 and to the related stream within the association. 490 The SG maps an Interface Identifier to an SCTP association/stream 491 only when an ASP sends an ASP Active message for a particular Interface 492 Identifier. It MUST be noted, however, that this mapping is dynamic 493 and could change at any time due to a change of ASP state. This mapping 494 could even temporarily be invalid, for example during failover of one 495 ASP to another. Therefore, the SG MUST maintain the states of AS/ASP 496 and reference them during the routing of an messages to an AS/ASP. 498 An example of the logical view of relationship between SS7 link, 499 Interface Identifier, AS and ASP in the SG is shown below: 501 /---------------------------------------------------+ 502 / /------------------------------------------------|--+ 503 / / v | 504 / / +----+ act+-----+ +-------+ -+--+-|+--+- 505 SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v 506 / +----+ | +----+ | +-----+ +-------+ -+--+--+--+- 507 / +->| AS |--+ Streams 508 / +----+ | +----+ stb+-----+ 509 SS7 link2-------->|IID |-+ | ASP | 510 +----+ +-----+ 512 where IID = Interface Identifier 514 Note that an ASP can be in more than one AS. 516 1.5.2 Status of ASPs 518 The M2UA layer on the SG MUST maintain the state of the ASPs it is 519 supporting. The state of an ASP changes because of reception of 520 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 521 or reception of indications from the local SCTP association. ASP 522 state transition procedures are described in Section 4.3.1. 524 At a SG, an Application Server list MAY contain active and inactive 525 ASPs to support ASP fail-over procedures. When, for example, both 526 a primary and a back-up ASP are available, M2UA peer protocol is 527 required to control which ASP is currently active. The ordered 528 list of ASPs within a logical Application Server is kept updated in 529 the SG to reflect the active Application Server Process(es). 531 Also the M2UA layer MAY need to inform the local management of the 532 change in status of an ASP or AS. This can be achieved using the M-ASP 533 STATUS or M-AS STATUS primitives. 535 1.5.3 SCTP Specifics 537 1.5.3.1 SCTP Stream Management 539 SCTP allows user specified number of streams to be opened during the 540 initialization. It is the responsibility of the M2UA layer to ensure 541 proper management of these streams. Because of the unidirectional 542 nature of streams, M2UA layers are not aware of the stream information 543 from the peer M2UA layers. Instead, the Interface Identifier is 544 in the M2UA message header. 546 The use of SCTP streams within M2UA is recommended in order to minimize 547 transmission and buffering delay, therefore improving the overall 548 performance and reliability of the signaling elements. It is 549 recommended that a separate SCTP stream is used for each SS7 link. 551 1.5.3.2 SCTP Send Primitive 553 M2UA shall set the lifetime parameter in the SEND primitive to SCTP 554 when sending a message. When SCTP times out a message, M2UA shall 555 abort the SCTP association and follow the same procedure as for a 556 failed SCTP association. 558 The default value for the lifetime shall be 2 seconds. Some messages, 559 like STATUS_FLUSH_BUFFERS may need a shorter lifetime. This is for 560 further study. 562 1.5.4 Seamless SS7 Network Management Interworking 564 The M2UA layer on the SG SHOULD pass an indication of unavailability of 565 the M2UA-User (MTP3) to the local Layer Management, if the currently 566 active ASP moves from the ACTIVE state. If the AS moves to the DOWN 567 state while SS7 links are in-service, the SG SHOULD follow the MTP 2 568 processor outage procedures [2]. 570 1.5.5 Flow Control / Congestion 572 It is possible for the M2UA layer to be informed of IP network congestion 573 onset and abatement by means of an implementation-dependent function 574 (i.e. an indication from the SCTP). 576 If the M2UA layer on the SG receives an IP network congestion onset 577 indication, the M2UA layer SHOULD inform the MTP2 layer of a Local 578 Processor Outage. When the M2UA layer on the SG receives an IP network 579 congestion abate indication, the M2UA layer SHOULD inform the MTP2 layer 580 of a Local Processor Outage condition has been cleared. 582 If the M2UA layer on the ASP receives an IP network congestion onset 583 indication, the M2UA layer SHOULD inform the MTP3 layer of a Local 584 Processor Outage. When the M2UA layer on the ASP receives an IP network 585 congestion abate indication, the M2UA layer SHOULD inform the MTP3 layer 586 of a Local Processor Outage condition has been cleared. 588 1.5.6 Audit of Link State 590 After a failover of one ASP to another ASP, it may be necessary for the 591 M2UA on the ASP to audit the current SS7 link state to ensure consistency. 592 The M2UA on the SG would respond to the audit request with information 593 regarding the current state of the link (i.e. in-service, out-of-service, 594 congestion state, LPO/RPO state). 596 1.6 Definition of the M2UA Boundaries 598 1.6.1 Definition of the M2UA / MTP Level 3 boundary 600 DATA 601 ESTABLISH 602 RELEASE 603 STATE 604 DATA RETRIEVAL 605 DATA RETRIEVAL COMPLETE 607 1.6.2 Definition of the M2UA / MTP Level 2 boundary 609 DATA 610 ESTABLISH 611 RELEASE 612 STATE 613 DATA RETRIEVAL 614 DATA RETRIEVAL COMPLETE 616 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 618 The upper layer and layer management primitives provided by SCTP are 619 provided in Reference [5] Section 9. 621 1.6.4 Definition of Layer Management / M2UA Boundary 623 M-SCTP ESTABLISH request 624 Direction: LM -> M2UA 625 Purpose: LM requests ASP to establish an SCTP association with an SG. 627 M-STCP ESTABLISH confirm 628 Direction: M2UA -> LM 629 Purpose: ASP confirms to LM that it has established an SCTP 630 association with an SG. 632 M-SCTP ESTABLISH indication 633 Direction: M2UA -> LM 634 Purpose: SG informs LM that an ASP has established an SCTP 635 association. 637 M-SCTP RELEASE request 638 Direction: LM -> M2UA 639 Purpose: LM requests ASP to release an SCTP association with SG. 641 M-SCTP RELEASE confirm 642 Direction: M2UA -> LM 643 Purpose: ASP confirms to LM that it has released SCTP association 644 with SG. 646 M-SCTP RELEASE indication 647 Direction: M2UA -> LM 648 Purpose: SG or IPSP informs LM that ASP has released an SCTP 649 association. 651 M-SCTP STATUS request 652 Direction: LM -> M2UA 653 Purpose: LM requests M2UA to report status of SCTP association. 655 M-SCTP STATUS indication 656 Direction: M2UA -> LM 657 Purpose: M2UA reports status of SCTP association. 659 M-ASP STATUS request 660 Direction: LM -> M2UA 661 Purpose: LM requests SG to report status of remote ASP. 663 M-ASP STATUS indication 664 Direction: M2UA -> LM 665 Purpose: SG reports status of remote ASP. 667 M-AS-STATUS request 668 Direction: LM -> M2UA 669 Purpose: LM requests SG to report status of AS. 671 M-AS-STATUS indication 672 Direction: M2UA -> LM 673 Purpose: SG reports status of AS. 675 M-NOTIFY indication 676 Direction: M2UA -> LM 677 Purpose: ASP reports that it has received a NOTIFY message 678 from its peer. 680 M-ERROR indication 681 Direction: M2UA -> LM 682 Purpose: ASP or SG reports that it has received an ERROR 683 message from its peer. 685 M-ASP-UP request 686 Direction: LM -> M2UA 687 Purpose: LM requests ASP to start its operation and send an ASP UP 688 message to the SG. 690 M-ASP-UP confirm 691 Direction: M2UA -> LM 692 Purpose: ASP reports that is has received an ASP UP Acknowledgement 693 message from the SG. 695 M-ASP-DOWN request 696 Direction: LM -> M2UA 697 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 698 message to the SG. 700 M-ASP-DOWN confirm 701 Direction: M2UA -> LM 702 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 703 message from the SG. 705 M-ASP-ACTIVE request 706 Direction: LM -> M2UA 707 Purpose: LM requests ASP to send an ASP ACTIVE message to the SG. 709 M-ASP-ACTIVE confirm 710 Direction: M2UA -> LM 711 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 712 message from the SG. 714 M-ASP-INACTIVE request 715 Direction: LM -> M2UA 716 Purpose: LM requests ASP to send an ASP INACTIVE message to the SG. 718 M-ASP-INACTIVE confirm 719 Direction: M2UA -> LM 720 Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement 721 message from the SG. 723 2.0 Conventions 725 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 726 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 727 in this document, are to be interpreted as described in [RFC2119]. 729 3.0 Protocol Elements 731 This section describes the format of various messages used in this 732 protocol. 734 3.1 Common Message Header 736 The protocol messages for MTP2-User Adaptation require a message 737 structure which contains a version, message class, message type, message 738 length, and message contents. This message header is common among all 739 signaling protocol adaptation layers: 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Version | Spare | Message Class | Message Type | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Message Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 3 Common Message Header 751 All fields in an M2UA message MUST be transmitted in the network byte 752 order, unless otherwise stated. 754 3.1.1 Version 756 The version field (vers) contains the version of the M2UA adapation 757 layer. The supported versions are: 759 Value Version 760 ----- ------- 761 1 Release 1.0 763 3.1.2 Message Type 765 The following List contains the valid Message Classes: 767 Message Class: 8 bits (unsigned integer) 769 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 770 1 Transfer Messages [M3UA] 771 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 772 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 773 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 774 5 Q.921/Q.931 Boundary Primitives Tranport (QPTM) 775 Messages [IUA] 776 6 MTP2 User Adaptatation (MAUP) Messages [M2UA] 777 7 Connectionless Messages [SUA] 778 8 Connection-Oriented Messages [SUA] 779 9 to 127 Reserved by the IETF 780 128 to 255 Reserved for IETF-Defined Message Class extensions 782 The following list contains the message types for the defined messages. 784 MTP2 User Adaptatation (MAUP) Messages 786 0 Reserved 787 1 Data 788 2 Establish Request 789 3 Establish Confirm 790 4 Release Request 791 5 Release Confirm 792 6 Release Indication 793 7 State Request 794 8 State Confirm 795 9 State Indication 796 10 Data Retrieval Request 797 11 Data Retrieval Confirm 798 12 Data Retrieval Indication 799 13 Data Retrieval Complete Indication 800 14 Congestion Indication 801 15 TTC Data 802 16 to 127 Reserved by the IETF 803 128 to 255 Reserved for IETF-Defined MAUP extensions 804 Application Server Process State Maintenance (ASPSM) messages 806 0 Reserved 807 1 ASP Up (UP) 808 2 ASP Down (DOWN) 809 3 Reserved 810 4 ASP Up Ack (UP ACK) 811 5 ASP Down Ack (DOWN ACK) 812 6 Reserved 813 7 to 127 Reserved by the IETF 814 128 to 255 Reserved for IETF-Defined ASPSM extensions 816 Application Server Process Traffic Maintenance (ASPTM) messages 818 0 Reserved 819 1 ASP Active (ACTIVE) 820 2 ASP Inactive (INACTIVE) 821 3 ASP Active Ack (ACTIVE ACK) 822 4 ASP Inactive Ack (INACTIVE ACK) 823 5 to 127 Reserved by the IETF 824 128 to 255 Reserved for IETF-Defined ASPTM extensions 826 Management (MGMT) Messages 828 0 Error (ERR) 829 1 Notify (NTFY) 830 2 to 127 Reserved by the IETF 831 128 to 255 Reserved for IETF-Defined MGMT extensions 833 3.1.3 Reserved 835 The Reserved field is 8-bits. It SHOULD be set to all '0's and 836 ignored by the receiver. 838 3.1.4 Message Length 840 The Message Length defines the length of the message in octets, 841 including the header. The Message Length includes parameter 842 padding bytes, if any. 844 3.1.5 Variable-Length Parameter Format 846 M2UA messages consist of a Common Header followed by zero or more 847 variable-length parameters, as defined by the message type. The 848 variable-length parameters contained in a message are defined in a 849 Tag-Length-Value format as shown below. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Parameter Tag | Parameter Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 \ \ 857 / Parameter Value / 858 \ \ 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Parameter Tag: 16 bits (unsigned integer) 863 The Type field is a 16 bit identifier of the type of parameter. It takes 864 a value of 0 to 65534. 866 The value of 65535 is reserved for IETF-defined extensions. Values 867 other than those defined in specific parameter description are reserved 868 for use by the IETF. 870 Parameter Length: 16 bits (unsigned integer) 872 The Parameter Length field contains the size of the parameter in bytes, 873 including the Parameter Tag, Parameter Length, and Parameter Value 874 fields. The Parameter Length does not include any padding bytes. 876 Parameter Value: variable-length. 878 The Parameter Value field contains the actual information to be 879 transferred in the parameter. 881 The total length of a parameter (including Tag, Parameter Length and Value 882 fields) MUST be a multiple of 4 bytes. If the length of the parameter is 883 not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., 884 after the Parameter Value field) with all zero bytes. The length of the 885 padding is NOT included in the parameter length field. A sender SHOULD 886 NOT pad with more than 3 bytes. The receiver MUST ignore the padding 887 bytes. 889 3.2 M2UA Message Header 891 In addition to the common message header, there will be a M2UA specific 892 message header. The M2UA specific message header will immediately 893 follow the common message header, but will only be used with MAUP 894 messages. 896 This message header will contain the Interface Identifier. The 897 Interface Identifier identifies the physical interface at the SG for 898 which the signaling messages are sent/received. The format of the 899 Interface Identifier parameter can be text or integer, the values of which 900 are assigned according to network operator policy. The values used are of 901 local significance only, coordinated between the SG and ASP. 903 The integer formatted Interface Identifier MUST be supported. The 904 text formatted Interface Identifier MAY optionally be supported. 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 (0x1) | Length=8 | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Interface Identifier (integer) | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 4 M2UA Message Header (Integer-based Interface Identifier) 916 The Tag value for Integer-based Interface Identifier is 0x1. The length is 917 always set to a value of 8. 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Tag (0x3) | Length | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Interface Identifier (text) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Figure 5 M2UA Message Header (Text-based Interface Identifier) 931 The Tag value for the Text-based Interface Identifier is 0x3. The 932 length is variable. 934 3.3 M2UA Messages 936 The following section defines the messages and parameter contents. The 937 M2UA messages will use the common message header (Figure 3) and the 938 M2UA message header (Figure 4). 940 3.3.1 MTP2 User Adaptation Messages 942 3.3.1.1 Data 944 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 945 Data message contains the following parameter: 947 Protocol Data (Mandatory) 949 The format for the Data Message parameters is as follows: 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Tag (0xe) | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Protocol Data | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 The Protocol Data field contains the MTP2-User application message in 962 network byte order starting with the Signaling Information Octet (SIO). 964 3.3.1.2 TTC Data 966 The TTC Data message contains a TTC SS7 MTP2-User Protocol Data Unit 967 (PDU). The TTC Data message contains the following parameter: 969 Protocol Data (Mandatory) 971 The format for the TTC Data Message parameters is as follows: 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Tag (0xf) | Length | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Protocol Data | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 The Protocol Data field contains the MTP2-User application message in 984 network byte order starting with the Length Indicator (LI) octet. 985 The Japanese TTC variant uses the spare bits of the LI octet for 986 priority. 988 3.3.1.3 Establish (Request, Confirmation) 990 The Establish Request message is used to establish the link or to 991 indicate that the channel has been established. The MGC controls the 992 state of the SS7 link. When the MGC desires the SS7 link to be 993 in-service, it will send the Establish Request message. Note that the 994 gateway MAY already have the SS7 link established at its layer. If so, 995 upon receipt of an Establish Request, the gateway takes no action except 996 to send an Establish Confirm. 998 When the MGC sends an M2UA Establish Request message, the MGC MAY 999 start a timer. This timer would be stopped upon receipt of an M2UA 1000 Establish Confirm. If the timer expires, the MGC would re-send the 1001 M2UA Establish Request message and restart the timer. In other words, 1002 the MGC MAY continue to request the establishment of the data link 1003 on periodic basis until the desired state is achieved or take some 1004 other action (notify the Management Layer). 1006 The mode (Normal of Emergency) for bringing the link in service is 1007 defaulted to Normal. The State Request (described in Section 3.3.1.4 1008 below) can be used to change the mode to Emergency. 1010 3.3.1.4 Release (Request, Indication, Confirmation) 1012 This Release Request message is used to release the channel. The 1013 Release Confirm and Indication messages are used to indicate that the 1014 channel has been released. 1016 3.3.1.5 State Request 1018 The State Request message can be sent from a MGC to cause an action 1019 on a particular SS7 link supported by the Signaling Gateway. The 1020 gateway sends a State Confirm to the MGC if the action has been success- 1021 fully completed. The State Confirm reflects that state value received 1022 in the State Request message. 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Tag (0x10) | Length | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | State | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 The valid values for State are shown in the following table. 1034 Define Value Description 1035 STATUS_LPO_SET 0x0 Request local processor outage 1036 STATUS_LPO_CLEAR 0x1 Request local processor outage 1037 recovered 1038 STATUS_EMER_SET 0x2 Request emergency alignment 1039 procedure 1040 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1041 emergency) procedure 1042 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit 1043 buffers 1044 STATUS_CONTINUE 0x5 Continue 1045 STATUS_AUDIT 0x6 Audit state of link 1047 3.3.1.5 State Confirm 1049 The State Confirm message will be sent by the SG in response to a State 1050 Request from the MGC. The State Confirm reflects that state value 1051 received in the State Request message. There is also a field to indicate 1052 whether or not the the State Request was successfully completed. 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Tag (0x16) | Length | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | State | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Result | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 The valid values for State are shown in the following table. The value 1065 of the State field should reflect the value received in the State Request 1066 message. 1068 Define Value Description 1069 STATUS_LPO_SET 0x0 Request local processor outage 1070 STATUS_LPO_CLEAR 0x1 Request local processor outage 1071 recovered 1072 STATUS_EMER_SET 0x2 Request emergency alignment 1073 procedure 1074 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1075 emergency) procedure 1076 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit 1077 buffers 1078 STATUS_CONTINUE 0x5 Continue 1079 STATUS_AUDIT 0x6 Audit state of link 1081 The valid values for the Result field are shown in the following table. 1083 Define Value Description 1084 STATUS_SUCCESS 0x0 Successfully completed Request 1085 STATUS_FAILURE 0x1 Failed to complete Request 1087 3.3.1.6 State Indication 1089 The MTP2 State Indication message can be sent from a gateway to an 1090 ASP to indicate a condition on a link. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Tag (0x11) | Length | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Event | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 The valid values for Event are shown in the following table. 1102 Define Value Description 1103 EVENT_RPO_ENTER 0x1 Remote entered processor outage 1104 EVENT_RPO_EXIT 0x2 Remote exited processor outage 1106 3.3.1.7 Congestion Indication 1108 The Congestion Indication message can be sent from a gateway to an ASP 1109 to indicate the congestion status and discard status of a link. When 1110 the MSU buffer fill increases above an Onset threshold or decreases below 1111 an Abatement threshold or crosses a Discard threshold in either 1112 direction, the SG SHALL send a congestion indication message. 1113 The SG shall send the message only when there is actually a change 1114 in either the discard level or the congestion level to report, 1115 meaning it is different from the previously sent message. In addition, 1116 the SG SHALL use an implementation dependent algorithm to limit the 1117 frequency of congestion indication messages. 1119 An implementation may optionally send Congestion Indication messages on 1120 a "high priority" stream in order to potentially reduce delay (Refer to 1121 [12] for more details). 1123 The Congestion Indication message contains the following parameters: 1125 Congestion Status (Mandatory) 1126 Discard Status (Optional) 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Tag (0x15) | Length | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Congestion Status | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Discard Status | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 The valid values for Congestion Status and Discard Status are shown in 1139 the following table. 1141 Define Value Description 1142 LEVEL_NONE 0x0 No congestion. 1143 LEVEL_1 0x1 Congestion Level 1 1144 LEVEL_2 0x2 Congestion Level 2 1145 LEVEL_3 0x3 Congestion Level 3 1147 For networks that do not support multiple levels of congestion, only the 1148 LEVEL_NONE and LEVEL_1 values will be used. For networks that support 1149 multiple levels of congestion, it is possible for all values to be used. 1150 Refer to [2] and [9] for more details. 1152 3.3.1.8 Retrieval (Request, Confirm) 1154 The MTP2 Retrieval Request message is used during the MTP Level 3 1155 changeover procedure to request the BSN, to retrieve PDUs from the 1156 retransmit queue or to flush PDUs from the retransmit queue. 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Tag (0x12) | Length | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Action | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Tag (0x13) | Length | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | seq_num | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 The valid values for Action are shown in the following table. 1172 Define Value Description 1173 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1174 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 1175 queue 1176 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue 1178 In the Retrieval Request message, the seq_num field SHOULD be ignored if 1179 the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The seq_num 1180 field contains the Forward Sequnce Number (FSN) of the far end if the 1181 Action is ACTION_RTRV_MSGS. 1183 When the Signaling Gateway sends a Retrieval Confirm to this request, 1184 it echos the action and puts the Backward Sequence Number (BSN) in the 1185 seq_num field if the action was ACTION_RTRV_BSN. If there is a failure 1186 in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff). 1187 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of 1188 of seq_num will be set to zero for success or -1 (0xffffffff) for failure. 1189 A failure means that the buffers could not be retrieved. For a Retrieval 1190 Confirm with an Action of ACTION_DROP_MSGS, the value received in the 1191 seq_num field will be ignored. 1193 3.3.1.9 Retrieval Indication 1195 The Retrieval Indication message is sent by the Signaling Gateway 1196 with a PDU from the retransmit queue. The Retrieval Indication 1197 message does not contain the Action or seq_num fields, just a MTP3 1198 Protocol Data Unit (PDU) from the retransmit queue. 1200 The M2UA implementation MAY consider the use of the bundling feature 1201 of SCTP for Retrieval Indication messages. 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Tag (0x14) | Length | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | PDU from retransmit queue | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 3.3.1.10 Retrieval Complete Indication 1215 The MTP2 Retrieval Complete Indication message is exactly the same as 1216 the MTP2 Retrieval Indication message except that it also indicates that 1217 it contains the last PDU from the retransmit queue. 1219 3.3.2 Application Server Process Maintenance (ASPM) Messages 1221 The ASPM messages will only use the common message header. 1223 3.3.2.1 ASP UP (ASPUP) 1225 The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer 1226 that the Adaptation layer is ready to receive traffic or maintenance 1227 messages. 1229 The ASPUP message contains the following parameters 1231 Info String (optional) 1233 The format for ASPUP Message parameters is as follows: 1235 0 1 2 3 1236 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 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Tag (0x4) | Length | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | INFO String* | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1246 character string along with the message. Length of the INFO String 1247 parameter is from 0 to 255 characters. No procedures are presently 1248 identified for its use but the INFO String MAY be used for debugging 1249 purposes. 1251 3.3.2.2 ASP Up Ack 1253 The ASP UP Ack message is used to acknowledge an ASP Up message received 1254 from a remote M2UA peer. 1256 The ASPUP Ack message contains the following parameters: 1258 INFO String (optional) 1260 The format for ASPUP Ack Message parameters is as follows: 1262 0 1 2 3 1263 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 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Tag (0x4) | Length | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | INFO String* | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 The format and description of the optional Info String parameter is the 1273 same as for the ASP UP message (See Section 3.3.2.1.) 1275 3.3.2.3 ASP Down (ASPDN) 1277 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1278 that the adaptation layer is not ready to receive traffic or 1279 maintenance messages. 1281 The ASPDN message contains the following parameters 1283 Reason 1284 INFO String (Optional) 1286 The format for the ASPDN message parameters is as follows: 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Tag (0xa) | Length | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Reason | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Tag (0x4) | Length | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | INFO String* | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 The format and description of the optional Info String parameter is the 1303 same as for the ASP Up message (See Section 3.3.2.1.). 1305 The Reason parameter indicates the reason that the remote M2UA 1306 adaptation layer is unavailable. The valid values for Reason are shown 1307 in the following table. 1309 Value Description 1310 0x1 Management 1312 3.3.2.4 ASP Down Ack 1314 The ASP Down Ack message is used to acknowledge an ASP Down message 1315 received from a remote M2UA peer. 1317 The ASP Down Ack message contains the following parameters: 1319 Reason 1320 INFO String (Optional) 1322 The format for the ASPDN Ack message parameters is as follows: 1324 0 1 2 3 1325 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 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Tag (0xa) | Length | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Reason | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Tag (0x4) | Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | INFO String* | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 The format and description of the optional Info String parameter is the 1339 same as for the ASP UP message (See Section 3.3.2.1.) 1341 The format of the Reason parameter is the same as for the ASP Down message 1342 (See Section 3.3.2.3). 1344 3.3.2.5 ASP Active (ASPAC) 1346 The ASPAC message is sent by an ASP to indicate to an SG that it is 1347 Active and ready to be used. 1349 The ASPAC message contains the following parameters 1351 Traffic Mode Type (Mandatory) 1352 Interface Identifier (Optional) 1353 - Combination of integer and integer ranges, OR 1354 - string (text formatted) 1355 INFO String (Optional) 1357 The format for the ASPAC message using integer formatted Interface 1358 Identifiers is as follows: 1360 0 1 2 3 1361 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 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Tag (0xb) | Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Traffic Mode Type | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Tag (0x1=integer) | Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Interface Identifiers* | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Tag (0x8=integer range) | Length | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Interface Identifier Start1* | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Interface Identifier Stop1* | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Interface Identifier Start2* | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Interface Identifier Stop2* | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 . . 1384 . . 1385 . . 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Interface Identifier StartN* | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Interface Identifier StopN* | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Additional Interface Identifiers | 1393 | of Tag Type 0x1 or 0x8 | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Tag (0x4) | Length | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | INFO String* | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 The format for the ASPAC message using text formatted (string) 1404 Interface Identifiers is as follows: 1406 0 1 2 3 1407 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 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Tag (0xb) | Length | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Traffic Mode Type | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Tag (0x3=string) | Length | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Interface Identifier* | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Additional Interface Identifiers | 1421 | of Tag Type 0x3 | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Tag (0x4) | Length | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | INFO String* | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 The Traffic Mode Type parameter identifies the traffic mode of 1432 operation of the ASP within an AS. The valid values for Type are 1433 shown in the following table: 1435 Value Description 1436 0x1 Over-ride 1438 Within a particular Interface Identifier, only one Type can be used. 1439 The Over-ride value indicates that the ASP is operating in Over-ride 1440 mode, where the ASP takes over all traffic in an Application Server 1441 (i.e., primary/back-up operation), over-riding any currently active 1442 ASPs in the AS. 1444 The optional Interface Identifiers parameter contains a list of 1445 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1446 (Type 0x3)indexing the Application Server traffic that the sending 1447 ASP is configured/registered to receive. If integer formatted 1448 Interface Identifiers are being used, the ASP can also send ranges of 1449 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1450 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1451 formatted Interface Identifiers (0x3) cannot be used with either 1452 Integer (0x1) or Integer Range (0x8) types. 1454 If no Interface Identifiers are included, the message is for all 1455 provisioned Interface Identifiers within the AS(s) in which the 1456 ASP is provisioned. If only a subset of Interface Identifiers are 1457 included, the ASP is noted as Active for all the Interface Identifiers 1458 provisioned for that AS. 1460 Note: If the optional Interface Identifier parameter is present, the 1461 integer formatted Interface Identifier MUST be supported, while the 1462 text formatted Interface Identifier MAY be supported. 1464 An SG that receives an ASPAC with an incorrect Traffic Mode Type for 1465 a particular Interface Identifier will respond with an Error Message 1466 (Cause: Unsupported Traffic Handling Mode). 1468 The format and description of the optional Info String parameter is the 1469 same as for the ASP UP message (See Section 3.3.2.1.). 1471 3.3.2.6 ASP Active Ack 1473 The ASPAC Ack message is used to acknowledge an ASP-Active message 1474 received from a remote M2UA peer. 1476 The ASPAC Ack message contains the following parameters: 1478 Traffic Mode Type (Mandatory) 1479 Interface Identifier (Optional) 1480 - Combination of integer and integer ranges, OR 1481 - string (text formatted) 1482 INFO String (Optional) 1484 The format for the ASPAC Ack message with Integer-formatted Interface 1485 Identifiers is as follows: 1487 0 1 2 3 1488 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 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Tag (0xb) | Length | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Traffic Mode Type | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Tag (0x1=integer) | Length | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Interface Identifiers* | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Tag (0x8=integer range) | Length | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Interface Identifier Start1* | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Interface Identifier Stop1* | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Interface Identifier Start2* | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Interface Identifier Stop2* | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 . . 1511 . . 1512 . . 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Interface Identifier StartN* | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Interface Identifier StopN* | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Additional Interface Identifiers | 1520 | of Tag Type 0x1 or 0x8 | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Tag (0x4) | Length | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | INFO String* | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 The format for the ASP Active Ack message using text formatted (string) 1531 Interface Identifiers is as follows: 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Tag (0xb) | Length | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Traffic Mode Type | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Tag (0x3=string) | Length | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Interface Identifier* | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Additional Interface Identifiers | 1548 | of Tag Type 0x3 | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Tag (0x4) | Length | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | INFO String* | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 The format and description of the optional Info String parameter is the 1559 same as for the ASP UP message (See Section 3.3.2.1.) 1561 The format of the Type and Interface Identifier parameters is the same 1562 as for the ASP Active message (See Section 3.3.2.5). 1564 3.3.2.7 ASP Inactive (ASPIA) 1566 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1567 longer an active ASP to be used from within a list of ASPs. The SG will 1568 respond with an ASPIA Ack message and either discard incoming messages 1569 or buffer for a timed period and then discard. 1571 The ASPIA message contains the following parameters 1573 Traffic Mode Type (Mandatory) 1574 Interface Identifiers (Optional) 1575 - Combination of integer and integer ranges, OR 1576 - string (text formatted) 1577 INFO String (Optional) 1579 The format for the ASP Inactive message parameters using Integer 1580 formatted Interface Identifiers is as follows: 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Tag (0xb) | Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Traffic Mode Type | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Tag (0x1=integer) | Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Interface Identifiers* | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Tag (0x8=integer range) | Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Interface Identifier Start1* | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Interface Identifier Stop1* | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Interface Identifier Start2* | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Interface Identifier Stop2* | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 . . 1606 . . 1607 . . 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Interface Identifier StartN* | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Interface Identifier StopN* | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Additional Interface Identifiers | 1615 | of Tag Type 0x1 or 0x8 | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Tag (0x4) | Length | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | INFO String* | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 The format for the ASP Inactive message using text formatted (string) 1626 Interface Identifiers is as follows: 1628 0 1 2 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Tag (0xb) | Length | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Traffic Mode Type | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Tag (0x3=string) | Length | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Interface Identifier* | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Additional Interface Identifiers | 1643 | of Tag Type 0x3 | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Tag (0x4) | Length | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | INFO String* | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 The Traffic Mode Type parameter identifies the traffic mode of 1654 operation of the ASP within an AS. The valid values for Traffic Mode 1655 Type are shown in the following table: 1657 Value Description 1658 0x1 Over-ride 1660 The format and description of the optional Interface Identifiers and 1661 Info String parameters is the same as for the ASP Active message (See 1662 Section 3.3.2.3.) 1664 The optional Interface Identifiers parameter contains a list of 1665 Interface Identifier integers indexing the Application Server traffic 1666 that the sending ASP is configured/registered to receive, but does not 1667 want to receive at this time. 1669 3.3.2.8 ASP Inactive Ack 1671 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 1672 received from a remote M2UA peer. 1674 The ASPIA Ack message contains the following parameters: 1676 Traffic Mode Type (Mandatory) 1677 Interface Identifiers (Optional) 1678 - Combination of integer and integer ranges, OR 1679 - string (text formatted) 1680 INFO String (Optional) 1682 The format for the ASPIA Ack message is as follows: 1684 0 1 2 3 1685 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 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Tag (0xb) | Length | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Traffic Mode Type | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Tag (0x1=integer) | Length | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Interface Identifiers* | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | Tag (0x8=integer range) | Length | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Interface Identifier Start1* | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | Interface Identifier Stop1* | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Interface Identifier Start2* | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Interface Identifier Stop2* | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 . . 1708 . . 1709 . . 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Interface Identifier StartN* | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Interface Identifier StopN* | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Additional Interface Identifiers | 1717 | of Tag Type 0x1 or 0x8 | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Tag (0x4) | Length | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | INFO String* | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 The format for the ASP Inactive Ack message using text formatted 1728 (string) Interface Identifiers is as follows: 1730 0 1 2 3 1731 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 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Tag (0xb) | Length | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Traffic Mode Type | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | Tag (0x3=string) | Length | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Interface Identifier* | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Additional Interface Identifiers | 1745 | of Tag Type 0x3 | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Tag (0x4) | Length | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | INFO String* | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 The format of the Traffic Mode Type and Interface Identifier 1756 parameters is the same as for the ASP Inactive message 1757 (See Section 3.3.2.7). 1759 The format and description of the optional Info String parameter is 1760 the same as for the ASP Up message (See Section 3.3.2.1). 1762 3.3.3 Layer Management (MGMT) Messages 1764 3.3.3.1 Error (ERR) 1766 The Error message is used to notify a peer of an error event 1767 associated with an incoming message. For example, the message type 1768 might be unexpected given the current state, or a parameter value might 1769 be invalid. 1771 The ERR message contains the following parameters: 1773 Error Code 1774 Diagnostic Information (optional) 1776 The format for the ERR message is as follows: 1778 0 1 2 3 1779 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 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Tag (0xc) | Length | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | Error Code | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 | Tag (0x7) | Length | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Diagnostic Information* | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 The Error Code parameter indicates the reason for the Error Message. 1793 The Error parameter value can be one of the following values: 1795 Invalid Version 0x1 1796 Invalid Interface Identifier 0x2 1797 Unsupported Message Class 0x3 1798 Unsupported Message Type 0x4 1799 Unsupported Traffic Handling Mode 0x5 1800 Unexpected Message 0x6 1801 Protocol Error 0x7 1802 Invalid Stream Identifier 0x8 1803 Unsupported Interface Identifier Type 0x9 1805 The "Invalid Version" error would be sent if a message was 1806 received with an invalid or unsupported version. The Error message 1807 would contain the supported version in the Common header. The 1808 Error message could optionally provide the supported version in 1809 the Diagnostic Information area. 1811 The "Invalid Interface Identifier" error would be sent by a SG if 1812 an ASP sends a message with an invalid (unconfigured) Interface 1813 Identifier value. 1815 The "Unsupported Traffic Handling Mode" error would be sent by a SG 1816 if an ASP sends an ASP Active with an unsupported Traffic Handling 1817 Mode. An example would be a case in which the SG did not support 1818 load-sharing. 1820 The "Unexpected Message" error would be sent by an ASP if it received 1821 a MAUP message from an SG while it was in the Inactive state. 1823 The "Protocol Error" error would be sent for any protocol anomaly 1824 (i.e. a bogus message). 1826 The "Invalid Stream Identifier" error would be sent if a message 1827 was received on an unexpected SCTP stream (i.e. i.e. a MGMT message 1828 was received on a stream other than "0").). 1830 The "Unsupported Interface Identifier Type" error would be sent by 1831 a SG if an ASP sends a Text formatted Interface Identifier and the 1832 SG only supports Integer formatted Interface Identifiers. When 1833 the ASP receives this error, it will need to resend its message with 1834 an Integer formatted Interface Identifier. 1836 The "Unsupported Message Class" error would be sent if a message with 1837 an unexpected or unsupported Message Class is received. 1839 The "Unsupported Interface Identifier Type" error would be sent by 1840 a SG if an ASP sends a Text formatted Interface Identifier and the 1841 SG only supports Integer formatted Interface Identifiers. When 1842 the ASP receives this error, it will need to resend its message with 1843 an Integer formatted Interface Identifier. 1845 The optional Diagnostic information can be any information germain to 1846 the error condition, to assist in identification of the error condition. 1847 In the case of an Invalid Version Error Code the Diagnostic information 1848 includes the supported Version parameter. In the other cases, the 1849 Diagnostic information MAY be the first 40 bytes of the offending message. 1851 3.3.3.2 Notify (NTFY) 1853 The Notify message used to provide an autonomous indication of M2UA 1854 events to an M2UA peer. 1856 The NTFY message contains the following parameters: 1858 Status Type 1859 Status Identification 1860 Interface Identifiers (Optional) 1861 INFO String (Optional) 1863 The format for the Notify message with Integer-formatted Interface 1864 Identifiers is as follows: 1866 0 1 2 3 1867 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 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Tag (0xd) | Length | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Status Type | Status Identification | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Tag (0x1=integer) | Length | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | Interface Identifiers* | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Tag (0x8=integer range) | Length | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Interface Identifier Start1* | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Interface Identifier Stop1* | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Interface Identifier Start2* | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Interface Identifier Stop2* | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 . . 1890 . . 1891 . . 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Interface Identifier StartN* | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Interface Identifier StopN* | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Additional Interface Identifiers | 1899 | of Tag Type 0x1 or 0x8 | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Tag (0x4) | Length | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | INFO String* | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 The format for the Notify message with Text-formatted Interface 1910 Identifiers is as follows: 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Tag (0xd) | Length | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Status Type | Status Identification | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Tag (0x3=string) | Length | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Interface Identifier* | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Additional Interface Identifiers | 1927 | of Tag Type 0x3 | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Tag (0x4) | Length | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | INFO String* | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 The Status Type parameter identifies the type of the Notify message. 1938 The following are the valid Status Type values: 1940 Value Description 1941 0x1 Application Server state change (AS_State_Change) 1942 0x2 Other 1944 The Status Information parameter contains more detailed information for 1945 the notification, based on the value of the Status Type. If the Status 1946 Type is AS_State_Change the following Status Information values are used: 1948 Value Description 1949 1 Application Server Down (AS_Down) 1950 2 Application Server Inactive (AS_Inactive) 1951 3 Application Server Active (AS_Active) 1952 4 Application Server Pending (AS_Pending) 1954 These notifications are sent from an SG to an ASP upon a change in status 1955 of a particular Application Server. The value reflects the new state of 1956 the Application Server. 1958 If the Status Type is Other, then the following Status Information values 1959 are defined: 1961 Value Description 1962 1 Insufficient ASP resources active in AS 1963 2 Alternate ASP Active 1965 This notification is not based on the SG reporting the state change of an 1966 ASP or AS. In the Insufficient ASP Resources case, the SG is 1967 indicating to an "Inactive" ASP(s) in the AS that another ASP is 1968 required in order to handle the load of the AS (Load-sharing mode). 1969 For the Alternate ASP Active case, an ASP is informed when an alternate 1970 ASP transitions to the ASP-Active state in Over-ride mode. 1972 The format and description of the optional Interface Identifiers and 1973 Info String parameters is the same as for the ASP Active message 1974 (See Section 3.3.2.3.) 1975 4.0 Procedures 1977 The M2UA layers needs to respond to various primitives it receives from 1978 other layers as well as messages it receives from the peer-to-peer 1979 messages. This section describes various procedures involved in 1980 response to these events. 1982 4.1 Procedures to Support Service in Section 1.4.1 1984 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 1985 MTP Level 3 boundary" service. 1987 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 1989 On receiving a primitive from the local upper layer, the M2UA layer will 1990 send the corresponding MAUP message (see Section 2) to its peer. The 1991 M2UA layer MUST fill in various fields of the common and specific headers 1992 correctly. In addition the message needs to be sent on the SCTP stream 1993 that corresponds to the SS7 link. 1995 4.1.2 MAUP Message Procedures 1997 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 1998 SG or MGC needs to invoke the corresponding layer primitives to the 1999 local MTP Level 2 or MTP Level 3 layer. 2001 4.2 Procedures to Support Service in Section 1.4.2 2003 These procedures achieve the M2UA layer's "Support for Communication 2004 between Layer Managements" service. 2006 4.2.1 Layer Management Primitives Procedure 2008 On receiving these primitives from the local layer, the M2UA layer will 2009 send the corresponding MGMT message (Error) to its peer. The M2UA layer 2010 MUST fill in the various fields of the common and specific headers 2011 correctly. 2013 An M-SCTP ESTABLISH request from Layer Management will initiate the 2014 establishment of an SCTP association. An M-SCTP ESTABLISH confirm 2015 will be sent to Layer Management when the initiated association set-up 2016 is complete. An M-SCTP ESTABLISH indication is sent to Layer 2017 Management upon successful completion of an incoming SCTP association 2018 set-up from a peer M2UA node 2020 An M-SCTP RELEASE request from Layer Management will initiate the 2021 tear-down of an SCTP association. An M-SCTP RELEASE confirm will 2022 be sent by Layer Management when the association teardown is complete. 2023 An M-SCTP RELEASE indication is sent to Layer Management upon 2024 successful tear-down of an SCTP association initiated by a peer M2UA. 2026 M-SCTP STATUS request and indication support a Layer Management 2027 query of the local status of a particular SCTP association. 2029 M-NOTIFY indication and M-ERROR indication indicate to Layer 2030 Management the notification or error information contained in a 2031 received M2UA Notify or Error message respectively. These indications 2032 can also be generated based on local M2UA events. 2034 M-ASP STATUS request/indication and M-AS-STATUS request/indication 2035 support a Layer Management query of the local status of a particular 2036 ASP or AS. No M2UA peer protocol is invoked. 2038 M-ASP Up request, M-ASP Down request, M-ASP-INACTIVE request and 2039 M-ASP-ACTIVE request allow Layer Management at an ASP to initiate 2040 state changes. These requests result in outgoing M2UA ASP UP, 2041 ASP DOWN, ASP INACTIVE and ASP ACTIVE messages. 2043 M-ASP Up confirmation, M-ASP Down confirmation, M-ASP-INACTIVE 2044 confirmation and M-ASP-ACTIVE confirmation indicate to Layer 2045 Management that the previous request has been confirmed. 2047 All MGMT messages are sent on a sequenced stream to ensure ordering. 2048 SCTP stream '0' SHOULD be used. 2050 4.2.2 MGMT message procedures 2052 Upon receipt of MGMT messages the M2UA layer MUST invoke the corresponding 2053 Layer Management primitives indications (e.g., M-AS Status ind., M-ASP 2054 Status ind., M-ERROR ind...) to the local layer management. 2056 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 2057 the notification or error information contained in a received M2UA 2058 Notify or Error message. These indications can also be generated 2059 based on local M2UA events. 2061 All MGMT messages are sent on a sequenced stream to ensure ordering. 2062 SCTP stream '0' SHOULD be used. 2064 4.3 Procedures to Support Service in Section 1.4.3 2066 These procedures achieve the M2UA layer's "Support for management of 2067 active associations between SG and MGC" service. 2069 4.3.1 State Maintenance 2071 The M2UA layer on the SG maintains the state of each AS, in each 2072 Appliction Server that it is configured to receive traffic. 2074 4.3.1.1 ASP States 2076 The state of the each ASP, in each AS that it is configured, is 2077 maintained in the M2UA layer on the SG. The state of an ASP changes 2078 due to events. The events include 2080 * Reception of messages from peer M2UA layer at that ASP 2081 * Reception of some messages from the peer M2UA layer at other 2082 ASPs in the AS 2083 * Reception of indications from SCTP layer 2085 The ASP state transition diagram is shown in Figure 6. The possible 2086 states of an ASP are the following: 2088 ASP Down: Application Server Process is unavailable and/or the related 2089 SCTP association is down. Initially all ASPs will be in this state. 2090 An ASP in this state SHOULD NOT not be sent any M2UA messages. 2092 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 2093 related SCTP association is up) but application traffic is stopped. 2094 In this state the ASP can be sent any non-MAUP M2UA messages. 2096 ASP-ACTIVE The remote M2UA peer at the ASP is available and 2097 application traffic is active. 2099 Figure 6 ASP State Transition Diagram 2101 +-------------+ 2102 +----------------------| | 2103 | Alternate +-------| ASP-ACTIVE | 2104 | ASP | +-------------+ 2105 | Takeover | ^ | 2106 | | ASP | | ASP 2107 | | Active | | Inactive 2108 | | | v 2109 | | +-------------+ 2110 | | | | 2111 | +------>| ASP-INACT | 2112 | +-------------+ 2113 | ^ | 2114 ASP Down/ | ASP | | ASP Down / 2115 SCTP CDI | Up | | SCTP CDI 2116 | | v 2117 | +-------------+ 2118 +--------------------->| | 2119 | ASP Down | 2120 +-------------+ 2122 SCTP CDI: The local SCTP layer's Communication Down Indication to the 2123 Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this 2124 indication when it detects the loss of connectivity to the ASP's peer 2125 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 2126 notification and COMMUNICATION LOST notification from the SCTP. 2128 When an SCTP association fails at the SG, M2UA shall change the states 2129 of all ASPs reached through the aborted SCTP association to ASP-DOWN. 2130 When an SCTP association fails at the ASP, M2UA shall either cause other 2131 ASPs to become active or send link-out-of-service primitives to MTP3. 2133 4.3.1.2 AS States 2135 The state of the AS is maintained in the M2UA layer on the SG. 2137 The state of an AS changes due to events. These events include the 2138 following: 2140 * ASP state transitions 2141 * Recovery timer triggers 2143 The possible states of an AS are the following: 2145 AS-DOWN: The Application Server is unavailable. This state implies 2146 that all related ASPs are in the ASP Down state for this AS. When 2147 the AS transitions to the AS-DOWN state, all of the SS7 links (Interface 2148 Identifiers) for this AS should be taken out-of-service. Initially the 2149 AS will be in this state. 2151 AS-INACTIVE: The Application Server is available but no application 2152 traffic is active (i.e., one or more related ASPs are in the ASP-Inactive 2153 state, but none in the ASP-Active state). 2155 AS-ACTIVE: The Application Server is available and application traffic 2156 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2158 AS-PENDING: An active ASP has transitioned from active to inactive or 2159 down and it was the last remaining active ASP in the AS. A recovery 2160 timer T(r) will be started and all incoming SCN messages will be 2161 queued by the SG. If an ASP becomes active before T(r) expires, the 2162 AS will move to AS-ACTIVE state and all the queued messages will be 2163 sent to the active ASP. 2165 If T(r) expires before an ASP becomes active, the SG stops queueing 2166 messages and discards all previously queued messages. In addition, 2167 the SG SHALL send the Stop primitive to MTP2 to take the link out of 2168 service. The AS will move to AS-Inactive if at least one ASP is in 2169 ASP-Inactive state, otherwise it will move to AS-DOWN state. 2171 If an ASP transitions to the ASP-DOWN state and all ASPs in the AS are 2172 in the ASP-DOWN state, then the SG SHALL send the Stop primitive to MTP2 2173 to take the link out of service and moves the AS to the AS-DOWN state. 2175 Figure 7 AS State Transition Diagram 2177 +----------+ one ASP trans ACTIVE +-------------+ 2178 | |------------------------>| | 2179 | AS-INACT | | AS-ACTIVE | 2180 | | | | 2181 | |< | | 2182 +----------+ \ +-------------+ 2183 ^ | \ Tr Expires ^ | 2184 | | \ at least one | | 2185 | | \ ASP in UP | | 2186 | | \ | | 2187 | | \ | | 2188 | | \ | | 2189 one ASP | | \ one ASP | | Last ACTIVE ASP 2190 trans | | all ASP \------\ trans to | | trans to INACT 2191 to | | trans to \ ACTIVE | | or DOWN 2192 INACT | | DOWN \ | | (start Tr timer) 2193 | | \ | | 2194 | | \ | | 2195 | | \ | | 2196 | v \ | v 2197 +----------+ \ +-------------+ 2198 | | -| | 2199 | AS-DOWN | | AS-PENDING | 2200 | | | (queueing) | 2201 | |<------------------------| | 2202 +----------+ Tr Expiry and no +-------------+ 2203 ASP in INACTIVE state 2205 Tr = Recovery Timer 2207 4.3.2 ASPM procedures for primitives 2209 Before the establishment of an SCTP association the ASP state at both 2210 the SG and ASP is assumed to be "Down". 2212 As the ASP is responsible for initiating the setup of an SCTP 2213 association to an SG, the M2UA layer at an ASP receives an M-SCTP 2214 ESTABLISH request primitive from the Layer Management, the M2UA layer 2215 will try to establish an SCTP association with the remote M2UA peer at 2216 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2217 primitive from the SCTP, the M2UA layer will invoke the primitive 2218 M-SCTP ESTABLISH confirm to the Layer Management. 2220 At the SG, the M2UA layer will receive an SCTP Communication Up 2221 indication primitive from the SCTP. The M2UA layer will then invoke 2222 the primitive M-SCTP ESTABLISH indication to the Layer Management. 2224 Once the SCTP association is established and assuming that the local 2225 M2UA-User is ready, the local ASP M2UA Application Server Process 2226 Maintenance (ASPM) function will initiate the ASPM procedures, using 2227 the ASP Up/-Down/-Active/-Inactive messages to convey the ASP-state to 2228 the SG - see Section 4.3.3. 2230 The Layer Management and the M2UA layer on SG can communicate the 2231 status of the application server using the M-AS STATUS primitives. 2232 The Layer Managements and the M2UA layers on both the SG and ASP 2233 can communicate the status of an SCTP association using the 2234 M-SCTP STATUS primitives. 2236 If the Layer Management on SG or ASP wants to bring down an SCTP 2237 association for management reasons, they would send M-SCTP RELEASE 2238 request primitive to the local M2UA layer. The M2UA layer would release 2239 the SCTP association and upon receiving the SCTP Communication Down 2240 indication from the underlying SCTP layer, it would inform the local 2241 Layer Management using M-SCTP RELEASE confirm primitive. 2243 If the M2UA layer receives an SCTP-Communication Down indication 2244 from the underlying SCTP layer, it will inform the Layer 2245 Management by invoking the M-SCTP RELEASE indication primitive. The 2246 state of the ASP will be moved to "Down" at both the SG and ASP. 2248 At an ASP, the Layer Management MAY try to reestablish the SCTP 2249 association using M-SCTP ESTABLISH request primitive. 2251 4.3.3 ASPM procedures for peer-to-peer messages 2253 All ASPM messages are sent on a sequenced stream to ensure ordering. 2254 SCTP stream '0' SHOULD is used. 2256 4.3.3.1 ASP-Inactive 2258 After an ASP has successfully established an SCTP association to an SG, 2259 the SG waits for the ASP to send an ASP Up message, indicating that the 2260 ASP M2UA peer is available. The ASP is always the initiator of the 2261 ASP Up exchange. 2263 When an ASP Up message is received at an SG and internally the ASP is 2264 not considered locked-out for local management reasons, the SG marks 2265 the remote ASP as Inactive. The SG responds with an ASP Up Ack message 2266 in acknowledgement. The SG sends an-Up Ack message in response to a 2267 received ASP Up message even if the ASP is already marked as "Inactive" 2268 at the SG. 2270 If for any local reason the SG cannot respond with an ASP Up, the SG 2271 responds to a ASP Up with a ASP Down Ack message. 2273 When the ASP sends an ASP Up it starts timer T(ack). If the ASP does 2274 not receive a response to an ASP Up within T(ack), the ASP MAY restart 2275 T(ack) and resend ASP Up messages until it receives an ASP Up Ack 2276 message. T(ack) SHOULD be provisionable, with a default of 2 seconds. 2277 Alternatively, retransmission of ASP Up messages MAY be put under 2278 control of Layer Management. In this method, expiry of T(ack) results 2279 in a M-ASP-Up confirmation carrying a negative indication. 2281 The ASP MUST wait for the ASP Up Ack message from the SG before 2282 sending any ASP traffic control messages (ASPAC or ASPIA) or Data 2283 messages or it will risk message loss. If the SG receives Data 2284 messages before an ASP Up is received, the SG SHOULD discard. 2286 4.3.3.2 ASP Down 2288 The ASP will send an ASP Down to an SG when the ASP is to be removed 2289 from the list of ASPs in all Application Servers that it is a member 2290 and no longer receive any M2UA traffic or management messages. 2292 Whether the ASP is permanently removed from an AS is a function of 2293 configuration management. 2295 The SG marks the ASP as "Down" and returns an ASP Down Ack message to 2296 the ASP if one of the following events occur: 2298 - an ASP Down message is received from the ASP, 2299 - another ASPM message is received from the ASP and the SG has 2300 locked out the ASP for management reasons. 2302 The SG sends an ASP Down Ack message in response to a received ASP Down 2303 message from the ASP even if the ASP is already marked as "Down" at 2304 the SG. 2306 At the ASP, the ASP Down Ack message received is not acknowledged. 2307 Layer Management is informed with an M-ASP Down confirm primitive. 2309 When the ASP sends an ASP Down it starts timer T(ack). If the ASP does 2310 not receive a response to an ASP Down within T(ack), the ASP MAY 2311 restart T(ack) and resend ASP Down messages until it receives an 2312 ASP Down Ack message. T(ack) SHOULD be provisionable, with a default 2313 of 2 seconds. Alternatively, retransmission of ASP Down messages MAY 2314 be put under control of Layer Management. In this method, expiry of 2315 T(ack) results in a M-ASP-Down confirmation carrying a negative 2316 indication. 2318 4.3.3.3 M2UA Version Control 2320 If a ASP Up message with an unsupported version is received, the 2321 receiving end responds with an Error message, indicating the version the 2322 receiving node supports. 2324 This is useful when protocol version upgrades are being performed in a 2325 network. A node upgraded to a newer version SHOULD support the older 2326 versions used on other nodes it is communicating with. Because ASPs 2327 initiate the ASP Up procedure it is assumed that the Error message would 2328 normally come from the SG. 2330 4.3.3.4 ASP-Active 2332 Any time after the ASP has received a ASP Up Ack from the SG, the ASP 2333 sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready 2334 to start processing traffic. In the case where an ASP is configured/- 2335 registered to process the traffic for more than one Application Server 2336 across an SCTP association, the ASPAC contains one or more Interface 2337 Identifiers to indicate for which Application Servers the ASPAC applies. 2339 When an ASP Active (ASPAC) message is received, the SG responds to the 2340 ASP with a ASPAC Ack message acknowledging that the ASPAC was received 2341 and starts sending traffic for the associated Application Server(s) 2342 to that ASP. Note that the SG sends an ASP Active Ack message in 2343 response to a received ASP Active message even if the ASP is already 2344 marked as "Active" at the SG. 2346 The ASP MUST wait for the ASP Active Ack message from the SG before 2347 sending any Data messages or it will risk message loss. If the SG 2348 receives MAUP messages before an ASP Active is received, the SG SHOULD 2349 discard these messages. 2351 When the ASP sends an ASP Active it starts timer T(ack). If 2352 the ASP does not receive a response to an ASP Active within T(ack), the 2353 ASP MAY restart T(ack) and resend ASP Active messages until it 2354 receives an ASP Active Ack message. T(ack) SHOULD be provisionable, with 2355 a default of 2 seconds. Alternatively, retransmission of ASP Active 2356 messages may be put under control of Layer Management. In this method, 2357 expiry of T(ack) results in a M-ASP-Active confirmation carrying a 2358 negative indication. 2360 There is one mode of Application Server traffic handling in the SG 2361 M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the 2362 mode used in a particular Application Server. If the SG determines that 2363 the mode indicates in an ASPAC is incompatible with the traffic handling 2364 mode currently used in the AS, the SG responds with an Error message 2365 indicating Unsupported Traffic Handling Mode. 2367 For Over-ride mode AS, the reception of an ASPAC message at an SG causes 2368 the redirection of all traffic for the AS to the ASP that sent the ASPAC. 2369 The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. 2370 Any previously active ASP in the AS is now considered Inactive and will 2371 no longer receive traffic from the SG within the AS. The SG sends a 2372 Notify (Alternate ASP-Active) to the previously active ASP in the AS, 2373 after stopping all traffic to that ASP. 2375 4.3.3.5 ASP Inactive 2377 When an ASP wishes to withdraw from receiving traffic within an AS, 2378 the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where 2379 an ASP is configured/registered to process the traffic for more than 2380 one Application Server across an SCTP association, the ASPIA contains 2381 one or more Interface Ids to indicate for which Application Servers 2382 the ASPIA applies. 2384 There is one mode of Application Server traffic handling in the SG 2385 M2UA when withdrawing an ASP from service - Over-ride. The Type 2386 parameter in the ASPIA messge indicates the mode used in a particular 2387 Application Server. If the SG determines that the mode indicates in an 2388 ASPAC is incompatible with the traffic handling mode currently used in 2389 the AS, the SG responds with an Error message indicating Unsupported 2390 Traffic Handling Mode. 2392 In the case of an Over-ride mode AS, where normally another ASP has 2393 already taken over the traffic within the AS with an Over-ride ASPAC, 2394 the ASP which sends the ASPIA is already considered by the SG to be 2395 "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is 2396 sent to the ASP, after ensuring that all traffic is stopped to the ASP. 2398 When the ASP sends an ASP Inactive it starts timer T(ack). If the ASP 2399 does not receive a response to an ASP Inactive within T(ack), the ASP 2400 MAY restart T(ack) and resend ASP Inactive messages until it receives 2401 an ASP Inactive Ack message. T(ack) SHOULD be provisionable, with a 2402 default of 2 seconds. Alternatively, retransmission of ASP Inactive 2403 messages may be put under control of Layer Management. In this method, 2404 expiry of T(ack) results in a M-ASP-Inactive confirmation carrying a 2405 negative indication. 2407 If no other ASPs are Active in the Application Server, the SG either 2408 discards all incoming messages for the AS or starts buffering the 2409 incoming messages for T(r) seconds, after which messages will be 2410 discarded. T(r) is configurable by the network operator. If the SG 2411 receives an ASPAC from an ASP in the AS before expiry of T(r), the 2412 buffered traffic is directed to the ASP and the timer is cancelled. 2414 4.3.3.6 Notify 2416 A Notify message reflecting a change in the AS state is sent to all 2417 ASPs in the AS, except those in the "Down" state, with appropriate 2418 Status Identification. 2420 In the case where a Notify (AS-Pending) message is sent by an SG 2421 that now has no ASPs active to service the traffic, the Notify does 2422 not explicitly force the ASP(s) receiving the message to become 2423 active. The ASPs remain in control of what (and when) action is 2424 taken. 2426 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 2428 5.1 Establishment of associations between SG and MGC examples 2430 5.1.1 Single ASP in an Application Server (1+0 sparing) 2432 This scenario shows the example M2UA message flows for the establishment 2433 of traffic between an SG and an ASP, where only one ASP is configured 2434 within an AS (no backup). It is assumed that the SCTP association is 2435 already set-up. 2437 SG ASP1 2438 | 2439 |<---------ASP Up----------| 2440 |--------ASP Up Ack------->| 2441 | | 2442 |<-------ASP Active--------| 2443 |------ASP_Active Ack----->| 2444 | | 2446 5.1.2 Two ASPs in Application Server (1+1 sparing) 2448 This scenario shows the example M2UA message flows for the establishment 2449 of traffic between an SG and two ASPs in the same Application Server, 2450 where ASP1 is configured to be active and ASP2 to be standby in the event 2451 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 2452 act as a hot, warm, or cold standby depending on the extent to which ASP1 2453 and ASP2 share call/transaction state or can communicate call state under 2454 failure/withdrawal events. 2456 SG ASP1 ASP2 2457 | | | 2458 |<--------ASP Up----------| | 2459 |-------ASP Up Ack------->| | 2460 | | | 2461 |<-----------------------------ASP Up----------------| 2462 |----------------------------ASP Up Ack------------->| 2463 | | | 2464 | | | 2465 |<-------ASP Active-------| | 2466 |-----ASP-Active Ack----->| | 2467 | | | 2469 5.2 ASP Traffic Fail-over Examples 2471 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2473 Following on from the example in Section 5.1.2, and ASP withdraws from 2474 service: 2476 SG ASP1 ASP2 2477 | | | 2478 |<-----ASP Inactive-------| | 2479 |----ASP Inactive Ack---->| | 2480 |--------------------NTFY(AS-Down) (Optional)------->| 2481 | | | 2482 |<------------------------------ ASP Active----------| 2483 |-----------------------------ASP-Active Ack)------->| 2484 | | 2486 In this case, the SG notifies ASP2 that the AS has moved to the 2487 Down state. The SG could have also (optionally) sent a Notify 2488 message when the AS moved to the Pending state. 2490 Note: If the SG detects loss of the M2UA peer (through a detection 2491 of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange 2492 would not occur. 2494 5.2.2 (1+1 Sparing, Back-up Over-ride) 2496 Following on from the example in Section 5.1.2, and ASP2 wishes to over- 2497 ride ASP1 and take over the traffic: 2499 SG ASP1 ASP2 2500 | | | 2501 |<------------------------------ ASP Active----------| 2502 |-----------------------------ASP-Active Ack-------->| 2503 |----NTFY( Alt ASP-Act)-->| 2504 | (optional) | | 2506 In this case, the SG notifies ASP1 that an alternative ASP has 2507 overridden it. 2509 5.3 SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 2511 When the M2UA layer on the ASP has a MAUP message to send to the SG, it 2512 will do the following: 2514 - Determine the correct SG 2516 - Find the SCTP association to the chosen SG 2518 - Determine the correct stream in the SCTP association based on 2519 the SS7 link 2521 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2522 Common Header 2524 - Send the MAUP message to the remote M2UA peer in the SG, over the 2525 SCTP association 2527 When the M2UA layer on the SG has a MAUP message to send to the ASP, it 2528 will do the following: 2530 - Determine the AS for the Interface Identifier 2532 - Determine the Active ASP (SCTP association) within the AS 2534 - Determine the correct stream in the SCTP association based on 2535 the SS7 link 2537 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2538 Common Header 2540 - Send the MAUP message to the remote M2UA peer in the ASP, over the 2541 SCTP association 2543 5.3.1 SS7 Link Alignment 2545 The MGC can request that a SS7 link be brought into alignment using the 2546 normal or emergency procedure. An example of the message flow to bring 2547 a SS7 link in-service using the normal alignment procedure is shown 2548 below. 2550 MTP2 M2UA M2UA MTP3 2551 SG SG ASP ASP 2553 <----Start Req---|<---Establish Req----|<----Start Req------ 2555 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 2557 An example of the message flow to bring a SS7 link in-service using the 2558 emergency alignment procedure. 2560 MTP2 M2UA M2UA MTP3 2561 SG SG ASP ASP 2563 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 2565 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 2567 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 2569 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 2571 5.3.2 SS7 Link Release 2573 The MGC can request that a SS7 link be taken out-of-service. It uses 2574 the Release Request message as shown below. 2576 MTP2 M2UA M2UA MTP3 2577 SG SG ASP ASP 2579 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 2581 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 2583 The SG can autonomously indicate that a SS7 link has gone out-of-service 2584 as shown below. 2586 MTP2 M2UA M2UA MTP3 2587 SG SG ASP ASP 2589 --Out of Serv->|----Release Ind----->|--Out of Serv--> 2591 5.3.3 Set and Clear Local Processor Outage 2593 The MGC can set a Local Processor Outage condition. It uses the 2594 State Request message as shown below. 2596 MTP2 M2UA M2UA MTP3 2597 SG SG ASP ASP 2599 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 2601 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 2603 The MGC can clear a Local Processor Outage condition. It uses the 2604 State Request message as shown below. 2606 MTP2 M2UA M2UA MTP3 2607 SG SG ASP ASP 2609 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 2611 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 2613 5.3.4 Notification of Remote Processor Outage 2615 The SG can indicate Remote has entered or exited the Processor Outage 2616 condition. It uses the State Indication message as shown below. 2618 MTP2 M2UA M2UA MTP3 2619 SG SG ASP ASP 2621 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 2623 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 2625 5.3.5 Notification of Link Congestion 2627 The SG can indicate that a link has become congested. It uses the 2628 Congestion Indication message as shown below. 2630 MTP2 M2UA M2UA MTP3 2631 SG SG ASP ASP 2633 ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> 2635 -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> 2637 5.3.6 SS7 Link Changeover 2639 An example of the message flow for an error free changeover is shown 2640 below. In this example, there were three messages in the retransmission 2641 queue that needed to be retrieved. 2643 MTP2 M2UA M2UA MTP3 2644 SG SG ASP ASP 2646 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2647 (seq_num = 0) 2649 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2650 (seq_num = BSN) 2652 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2653 (seq_num = FSN) 2655 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2656 (seq_num = 0) 2658 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2659 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2660 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2662 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 2664 Note: The number of Retrieval Indication is dependent on the number of 2665 messages in the retransmit queue that have been requested. Only one 2666 Retrieval Complete Indication SHOULD be sent. 2668 An example of a message flow with an error retrieving the BSN is shown 2669 below. 2671 MTP2 M2UA M2UA MTP3 2672 SG SG ASP ASP 2674 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2676 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 2677 (seq_num = -1) 2679 An example of a message flow with an error retrieving the messages is 2680 shown below. 2682 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2684 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2685 (seq_num = BSN) 2687 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2688 (seq_num = FSN) 2690 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2691 (seq_num = -1) 2693 An example of a message flow for a request to drop messages (clear 2694 retransmission buffers) is shown below. 2696 MTP2 M2UA M2UA MTP3 2697 SG SG ASP ASP 2699 <-Clr RTB Req-|<--Rtrv Req (ACTION_DROP_MSGS)--|<--Clr RTB Req--- 2701 -Clr RTB Ind->|---Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr RTB Ind--> 2703 5.3.7 Flush and Continue 2705 The following message flow shows a request to flush buffers. 2707 MTP2 M2UA M2UA MTP3 2708 SG SG ASP ASP 2710 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 2712 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 2714 The following message flow shows a request to continue. 2716 MTP2 M2UA M2UA MTP3 2717 SG SG ASP ASP 2719 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 2721 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 2723 5.3.8 Auditing of SS7 link state 2725 It may be necessary for the ASP to audit the current state of a SS7 link. 2726 The flows below show an example of the request and all the potential 2727 responses. 2729 Below is an example in which the SS7 link is out-of-service. 2731 MTP2 M2UA M2UA MGMT 2732 SG SG ASP ASP 2734 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2736 |-----State Cfm (STATUS_AUDIT)--->| 2738 MTP3 2739 ASP 2741 |-----------Release Ind---------->|-Out of Serv Ind -> 2743 Below is an example in which the SS7 link is in-service. 2745 MTP2 M2UA M2UA MGMT 2746 SG SG ASP ASP 2748 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2750 |-----State Cfm (STATUS_AUDIT)--->| 2752 MTP3 2753 ASP 2755 |-----------Establish Cfm-------->|---In Serv Ind --> 2757 Below is an example in which the SS7 link is in-service, but congested. 2759 MTP2 M2UA M2UA MGMT 2760 SG SG ASP ASP 2762 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2764 |-----State Cfm (STATUS_AUDIT)--->| 2766 MTP3 2767 ASP 2769 |-----------Establish Ind-------->|---In Serv Ind --> 2771 |----------Congestion Ind-------->|---Cong Ind -----> 2773 Below is an example in which the SS7 link is in-service, but in Remote 2774 Processor Outage. 2776 MTP2 M2UA M2UA MGMT 2777 SG SG ASP ASP 2779 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2781 |-----State Cfm (STATUS_AUDIT)--->| 2783 MTP3 2784 ASP 2786 |-----------Establish Ind-------->|---In Serv Ind --> 2788 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter ---> 2790 6.0 Security 2792 M2UA is designed to carry signaling messages for telephony services. As such, 2793 M2UA MUST involve the security needs of several parties: the end users 2794 of the services; the network providers and the applications involved. 2795 Additional requirements MAY come from local regulation. While having some 2796 overlapping security needs, any security solution SHOULD fulfill all of the 2797 different parties' needs. 2799 6.1 Threats 2801 There is no quick fix, one-size-fits-all solution for security. As a 2802 transport protocol, M2UA has the following security objectives: 2804 * Availability of reliable and timely user data transport. 2805 * Integrity of user data transport. 2806 * Confidentiality of user data. 2808 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 2809 security features, such as: 2811 * Blind Denial of Service Attacks 2812 * Flooding 2813 * Masquerade 2814 * Improper Monopolization of Services 2816 When M2UA is running in professionally managed corporate or service 2817 provider network, it is reasonable to expect that this network includes 2818 an appropriate security policy framework. The "Site Security Handbook" 2819 [10] SHOULD be consulted for guidance. 2821 When the network in which M2UA runs in involves more than one party, it 2822 MAY NOT be reasonable to expect that all parties have implemented security 2823 in a sufficient manner. In such a case, it is recommended that IPSEC is 2824 used to ensure confidentiality of user payload. Consult [11] for more 2825 information on configuring IPSEC services. 2827 6.2 Protecting Confidentiality 2829 Particularly for mobile users, the requirement for confidentiality MAY 2830 include the masking of IP addresses and ports. In this case application 2831 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 2832 Regardless of which level performs the encryption, the IPSEC ISAKMP 2833 service SHOULD be used for key management. 2835 7.0 IANA Considerations 2837 7.1 SCTP Payload Protocol Identifier 2839 A request will be made to IANA to assign an M2UA value for the Payload 2840 Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload 2841 Protocol Identifier will be registered: 2843 M2UA 0x10 2845 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 2846 to indicate which protocol the SCTP is carrying. This Payload Protocol 2847 Identifier is not directly used by SCTP but MAY be used by certain network 2848 entities to identify the type of information being carried in a Data chunk. 2850 The User Adaptation peer MAY use the Payload Protocol Identifier as a way 2851 of determining additional information about the data being presented to it 2852 by SCTP. 2854 7.2 M2UA Protocol Extensions 2856 This protocol may also be extended through IANA in three ways: 2858 -- through definition of additional message classes, 2859 -- through definition of additional message types, and 2860 -- through definition of additional message parameters. 2862 The definition and use of new message classes, types and parameters is 2863 an integral part of SIGTRAN adaptation layers. Thus, these extensions 2864 are assigned by IANA through an IETF Consensus action as defined in 2865 [RFC2434]. 2867 The proposed extension must in no way adversely affect the general 2868 working of the protocol. 2870 7.2.1 IETF Defined Message Classes 2872 The documentation for a new message class MUST include the following 2873 information: 2875 (a) A long and short name for the message class. 2876 (b) A detailed description of the purpose of the message class. 2878 7.2.2 IETF Defined Message Types 2880 Documentation of the message type MUST contain the following information: 2882 (a) A long and short name for the new message type. 2883 (b) A detailed description of the structure of the message. 2884 (c) A detailed definition and description of intended use of each field 2885 within the message. 2886 (d) A detailed procedural description of the use of the new message type 2887 within the operation of the protocol. 2888 (e) A detailed description of error conditions when receiving this message 2889 type. 2891 When an implementation receives a message type which it does not support, 2892 it MUST respond with an Error (ERR) message with an Error Code of 2893 Unsupported Message Type. 2895 7.2.3 IETF-defined TLV Parameter Extension 2897 Documentation of the message parameter MUST contain the following 2898 information: 2900 (a) Name of the parameter type. 2901 (b) Detailed description of the structure of the parameter field. This 2902 structure MUST conform to the general type-length-value format 2903 described in Section 3.1.5. 2904 (c) Detailed definition of each component of the parameter value. 2905 (d) Detailed description of the intended use of this parameter type, 2906 and an indication of whether and under what circumstances 2907 multiple instances of this parameter type may be found within the 2908 same message type. 2910 8.0 Acknowledgements 2912 The authors would like to thank John Loughney, Neil Olson, Michael 2913 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 2914 Prantner, Barry Nagelberg, Naoto Makinae and Brian Bidulock for their 2915 valuable comments and suggestions. 2917 9.0 References 2919 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 2920 System No. 7 (SS7)' 2922 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 2923 Message Transfer Part (MTP)' 2925 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 2927 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 2928 of Signaling System Number 7', Volume 1, December 1995 2930 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 2932 [6] Architectural Framework for Signaling Transport, RFC 2719, 2933 October 1999 2935 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February 2936 1995 2938 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 2939 functions and messages using the services of ITU-T 2940 Recommendation Q.2140', August 1995 2942 [9] ITU-T Recommendation Q.751.1, 'Network Element Management Information 2943 Model for the Messsage Transfer Part', October 1995 2945 [10] Site Security Handbook, RFC 2196, September 1997 2947 [11] Security Architecture for the Internet Protocol, RFC 2401 2949 [12] draft-stewart-srwnd-sctp-sigtran-01.txt, SCTP Stream Based Flow 2950 Control, November 2000 2952 10.0 Issues To Be Addressed 2954 1. SCTP congestion (what does M2UA on SG and MGC do) 2955 10.0 Author's Addresses 2957 Ken Morneault Tel: +1-703-484-3323 2958 Cisco Systems Inc. EMail: kmorneau@cisco.com 2959 13615 Dulles Technology Drive 2960 Herndon, VA. 20171 2961 USA 2963 Ram Dantu, Ph.D. Tel +1-469-255-0716 2964 Cisco Systems EMail rdantu@cisco.com 2965 17919 Waterview 2966 Dallas, TX 75252 2967 USA 2969 Greg Sidebottom Tel: +1-613-763-7305 2970 Nortel Networks EMail: gregside@nortelnetworks.com 2971 3685 Richmond Rd, 2972 Nepean, Ontario 2973 Canada K2H5B7 2975 Tom George Tel: +1-972-519-3168 2976 Alcatel USA EMail: tom.george@usa.alcatel.com 2977 1000 Coit Road 2978 Plano, TX 74075 2979 USA 2981 Brian Bidulock Tel +1-972-839-4489 2982 OpenSS7 Project EMail: bidulock@openss7.org 2983 c/o #424, 4701 Preston Park Blvd. 2984 Dallas, TX 75093 2985 USA 2987 Jacob Heitz Tek +1-510-747-2917 2988 Lucent Technologies Email: jheitz@lucent.com 2989 1701 Harbor Bay Parkway 2990 Alameda, CA, 94502 2991 USA 2993 This Internet Draft expires April 2001.