idnits 2.17.1 draft-ietf-sigtran-m2ua-05.txt: -(2341): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 19) being 430 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 47 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 21: '... that other groups MAY also distribute...' RFC 2119 keyword, line 25: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 87: '...mechanism SHOULD meet the following cr...' RFC 2119 keyword, line 144: '...ver Process. Fail-back MAY apply upon...' RFC 2119 keyword, line 221: '...Note: STPs MAY be present in the SS7 p...' (75 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 350 has weird spacing: '...e hosts and t...' == Line 2054 has weird spacing: '...ges and disca...' == Line 2260 has weird spacing: '...PIA Ack messa...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the network in which M2UA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [9] for more information on configuring IPSEC services. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 2000) is 8563 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 727 == Unused Reference: '1' is defined on line 2620, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2636, 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' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '8') ** Obsolete normative reference: RFC 2401 (ref. '9') (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Ram Dantu 3 Cisco Systems 4 Mallesh Kalla 5 Telcordia 6 Greg Sidebottom 7 Nortel Networks 8 Tom George 9 Alcatel 11 Expires in six months Nov 2000 13 SS7 MTP2-User Adaptation Layer 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC 2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups MAY also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and MAY be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as 'work in progress'. 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To learn the current status of any Internet-Draft, please check the 36 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 37 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 38 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 Abstract 43 This Internet Draft defines a protocol for backhauling of SS7 MTP2 44 User signaling messages over IP using the Stream Control 45 Transmission Protocol (SCTP). This protocol would be used between a 46 Signaling Gateway (SG) and Media Gateway Controller (MGC). It is 47 assumed that the SG receives SS7 signaling over a standard SS7 48 interface using the SS7 Message Transfer Part (MTP) to provide 49 transport. The Signaling Gateway would act as a Signaling Link 50 Terminal. 52 TABLE OF CONTENTS 54 1. Introduction..............................................2 55 1.1 Scope..................................................2 56 1.2 Terminology............................................3 57 1.3 Signaling Transport Architecture.......................3 58 1.4 Services Provide by the M2UA Adaptation Layer..........6 59 1.5 Function Provided by the M2UA Layer....................8 60 1.6 Definition of the M2UA Boundaries......................9 61 2. Conventions...............................................9 62 3. Protocol Elements.........................................9 63 3.1 Common Message Header.................................10 64 3.2 M2UA Message Header...................................11 65 3.3 M2UA Messages.........................................11 66 4. Procedures...............................................20 67 4.1 Procedures to Support Service in Section 1.4.1........20 68 4.2 Procedures to Support Service in Section 1.4.2........21 69 4.3 Procedures to Support Service in Section 1.4.3........21 70 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 71 5.1 Establishment of associations between SG and MGC......26 72 examples 73 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 74 5.3 Layer Management Communication Examples...............29 75 6. Security.................................................30 76 7. IANA Considerations......................................31 77 8. Acknowledgements.........................................31 78 9. References...............................................32 79 10. Author's Addresses.......................................33 80 1. Introduction 82 1.1 Scope 84 There is a need for Switched Circuit Network SCN signaling protocol 85 delivery from an Signaling Gateway (SG) to a Media Gateway 86 Controller (MGC) or IP Signaling Point (IPSP). The delivery 87 mechanism SHOULD meet the following criteria: 89 * Support for MTP Level 2 / MTP Level 3 interface boundary 90 * Support for communication between Layer Management modules on SG 91 and MGC 92 * Support for management of active associations between the SG and MGC 94 In other words, the Signaling Gateway will transport MTP Level 3 95 messages to a Media Gateway Controller (MGC) or IP Signaling Point 96 (IPSP). In the case of delivery from an SG to an IPSP, both the SG and 97 IPSP function as traditional SS7 nodes using the IP network as a new 98 type of SS7 link. This allows for full MTP Level 3 message handling 99 and network management capabilities. 101 1.2 Terminology 103 MTP2-User - A protocol that normally uses the services of MTP Level 2 104 (i.e. MTP3). 106 Interface - For the purposes of this document, an interface is a SS7 107 signaling link. 109 Backhaul - Refers to the transport of signaling from the point of 110 interface for the associated data stream (i.e., SG function in the MGU) 111 back to the point of call processing (i.e., the MGCU), if this is not 112 local [4]. 114 Association - An association refers to a SCTP association. The 115 association will provide the transport for the delivery of protocol 116 data units for one or more interfaces. 118 Stream - A stream refers to an SCTP stream; a uni-directional logical 119 channel established from one SCTP endpoint to another associated SCTP 120 endpoint, within which all user messages are delivered in-sequence 121 except for those submitted to the un-ordered delivery service. 123 Interface Identifier - The Interface Identifier identifies the physical 124 interface at the SG for which the signaling messages are sent/received. 125 The format of the Interface Identifier parameter can be text or integer, 126 the values of which are assigned according to network operator policy. 127 The values used are of local significance only, coordinated between the 128 SG and ASP. 130 Application Server (AS) - A logical entity serving a specific application 131 instance. An example of an Application Server is a MGC handling the 132 MTP Level 3 and call processing for SS7 links terminated by the 133 Signaling Gateways. Practically speaking, an AS is modeled at the SG 134 as an ordered list of one or more related Application Server Processes 135 (e.g., primary, secondary, tertiary, ...). 137 Application Server Process (ASP) - A process instance of an Application 138 Server. Examples of Application Server Processes are primary or backup 139 MGC instances. 141 Fail-over - The capability to re-route signaling traffic as required 142 to an alternate Application Server Process, or group of ASPs, within 143 an Application Server in the event of failure or unavailability of a 144 currently used Application Server Process. Fail-back MAY apply upon 145 the return to service of a previously unavailable Application Server 146 Process. 148 Signaling Link Terminal (SLT) - Refers to the means of performing all 149 of the functions defined at MTP level 2 regardless of their 150 implementation [2]. 152 Layer Management - Layer Management is a nodal function in an SG or 153 ASP that handles the inputs and outputs between the M2UA layer and a 154 local management entity. 156 Network Byte Order: Most significant byte first, a.k.a Big Endian. 158 Host - The computing platform that the ASP process is running on. 160 1.3 M2UA Overview 162 The framework architecture that has been defined for SCN signaling 163 transport over IP [6] uses multiple components, including a signaling 164 common transport protocol and an adaptation module to support the 165 services expected by a particular SCN signaling protocol from its 166 underlying protocol layer. 168 Within this framework architecture, this document defines a SCN 169 adaptation module that is suitable for the transport of SS7 MTP2 User 170 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 171 of the Stream Control Transmission Protocol [5] as the underlying 172 reliable signaling common transport protocol. 174 In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling 175 is transmitted and received from the PSTN over a standard SS7 network 176 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 177 to provide reliable transport of the MTP3-User signaling messages to and 178 from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). 179 The SG then provides a functional inter-working of transport functions 180 with the IP transport, in order to transfer the MTP2-User signaling 181 messages to and from an Application Server Process where the peer MTP2- 182 User protocol layer exists. 184 1.3.1 Example - SG to MGC 186 In a Signaling Gateway, it is expected that the SS7 signaling is 187 received over a standard SS7 network termination, using the SS7 Message 188 Transfer Part (MTP) to provide transport of SS7 signaling messages to 189 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 190 Point (STP). In other words, the SG acts as a Signaling Link Terminal 191 (SLT) [2]. The SG then provides interworking of transport functions 192 with IP Signaling Transport, in order to transport the MTP3 signaling 193 messages to the MGC where the peer MTP3 protocol layer exists, as shown 194 below: 196 ****** SS7 ****** IP ******* 197 *SEP *-----------* SG *-------------* MGC * 198 ****** ****** ******* 200 +----+ +----+ 201 |S7UP| |S7UP| 202 +----+ +----+ 203 |MTP + |MTP | 204 | L3 | (NIF) |L3 | 205 +----+ +----+----+ +----+ 206 |MTP | |MTP |M2UA| |M2UA| 207 | | | +----+ +----+ 208 |L2 | |L2 |SCTP| |SCTP| 209 |L1 | |L1 +----+ +----+ 210 | | | |IP | |IP | 211 +----+ +---------+ +----+ 213 NIF - Nodal Interworking Function 214 SEP - SS7 Signaling Endpoint 215 IP - Internet Protocol 216 SCTP - Stream Control Transmission Protocol 217 (Refer to Reference [5]) 219 Figure 1 M2UA in the SG to MGC Application 221 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 223 It is recommended that the M2UA use the services of the Stream 224 Control Transmission Protocol (SCTP) as the underlying reliable 225 common signaling transport protocol. The use of SCTP provides 226 the following features: 228 - explicit packet-oriented delivery (not stream-oriented) 229 - sequenced delivery of user messages within multiple streams, 230 with an option for order-of-arrival delivery of individual 231 user messages, 232 - optional multiplexing of user messages into SCTP datagrams, 233 - network-level fault tolerance through support of multi-homing 234 at either or both ends of an association, 235 - resistance to flooding and masquerade attacks, and 236 - data segmentation to conform to discovered path MTU size 238 There are scenarios without redundancy requirements and 239 scenarios in which redundancy is supported below the transport 240 layer. In these cases, the SCTP functions above MAY NOT be a 241 requirement and TCP can be used as the underlying common 242 transport protocol. 244 1.3.2 Support for the management of SCTP associations between the SG 245 and ASPs 247 The M2UA layer at the SG maintains the availability state of all 248 dynamically registered remote ASPs, in order to manage the SCTP 249 Associations and the traffic between the SG and ASPs. As well, the 250 active/inactive state of remote ASP(s) are also maintained. Active 251 ASPs are those currently receiving traffic from the SG. 253 The M2UA layer MAY be instructed by local management to establish an 254 SCTP association to a peer M2UA node. This can be achieved using the M- 255 SCTP ESTABLISH primitive to request, indicate and confirm the 256 establishment of an SCTP association with a peer M2UA node. 258 The M2UA layer MAY also need to inform local management of the status of 259 the underlying SCTP associations using the M-SCTP STATUS request and 260 indication primitive. For example, the M2UA MAY inform local management 261 of the reason for the release of an SCTP association, determined either 262 locally within the M2UA layer or by a primitive from the SCTP. 264 1.3.3 Signaling Network Architecture 266 A Signaling Gateway will support the transport of MTP2-User signaling 267 traffic received from the SS7 network to one or more distributed ASPs 268 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 269 meet any performance and reliability requirements for such transport. 270 A physical network architecture is required, with data on the 271 availability and transfer performance of the physical nodes involved in 272 any particular exchange of information. However, the M2UA protocol MUST 273 be flexible enough allow its operation and management in a variety of 274 physical configurations that will enable Network Operators to meet 275 their performance and reliability requirements. 277 To meet the stringent SS7 signaling reliability and performance 278 requirements for carrier grade networks, these Network Operators SHOULD 279 ensure that there is no single point of failure provisioned in the end- 280 to-end network architecture between an SS7 node and an IP ASP. 282 Depending of course on the reliability of the SG and ASP functional 283 elements, this can typically be met by the spreading links in a linkset 284 across SGs, the provision of redundant QOS-bounded IP network paths for 285 SCTP Associations between SCTP End Points, and redundant Hosts. The 286 distribution of ASPs within the available Hosts is also important. For a 287 particular Application Server, the related ASPs SHOULD be distributed over 288 at least two Hosts. 290 An example physical network architecture relevant to carrier-grade 291 operation in the IP network domain is shown in Figure 2 below: 293 ******** ************** 294 * *_________________________________________* ******** * Host1 295 * * _________* * ASP1 * * 296 * SG1 * SCTP Associations | * ******** * 297 * *_______________________ | * * 298 ******** | | ************** 299 | | 300 ******** | | 301 * *_______________________________| 302 * * | 303 * SG2 * SCTP Associations | 304 * *____________ | 305 * * | | 306 ******** | | ************** 307 | |_________________* ******** * Host2 308 |____________________________* * ASP1 * * 309 * ******** * 310 * * 311 ************** 312 . 313 . 314 . 316 Figure 2 - Physical Model Example 318 For carrier grade networks, Operators SHOULD ensure that under failure 319 or isolation of a particular ASP, stable calls or transactions are not 320 lost. This implies that ASPs need, in some cases, to share the call/- 321 transaction state or be able to pass the call/transaction state between 322 each other. Also, in the case of ASPs performing call processing, 323 coordination MAY be required with the related Media Gateway to transfer 324 the MGC control for a particular trunk termination. However, this 325 sharing or communication is outside the scope of this document. 327 1.3.4 ASP Fail-over Model and Terminology 329 The M2UA layer supports ASP fail-over functions in order to support a 330 high availability of call and transaction processing capability. All 331 MTP2-User messages incoming to an SG from the SS7 network are assigned 332 to a unique Application Server, based on the Interface Identifier of 333 the message. 335 The Application Server is in practical terms a list of all ASPs currently 336 registered to process MTP2-User messages from certain Interface 337 Identifiers. One or more ASPs in the list are normally active (i.e., 338 handling traffic) while any others MAY be unavailable or inactive, to be 339 possibly used in the event of failure or unavailability of the active 340 ASP(s). 342 The fail-over model supports an n+k redundancy model, where n ASPs 343 is the minimum number of redundant ASPs required to handle traffic and 344 k ASPs are available to take over for a failed or unavailable ASP. 345 Note that 1+1 active/standby redundancy is a subset of this model. 346 A simplex 1+0 model is also supported as a subset, with no ASP 347 redundancy. 349 To avoid a single point of failure, it is recommended that a minimum of 350 two ASPs be in the list, resident in separate hosts and therefore 351 available over different SCTP Associations. For example, in the 352 network shown in Figure 2, all messages to DPC x could be sent to ASP1 353 in Host1 or ASP1 in Host2. The AS list at SG1 might look like this: 355 Interface Identiers - Application Server #1 356 ASP1/Host1 - State = Active 357 ASP1/Host2 - State = Inactive 359 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 360 message for the Interface Identifiers registered. ASP1 in Host2 would 361 normally be brought to the active state upon failure of, or loss of 362 connectivity to, ASP1/Host1. In this example, both ASPs are Inactive 363 or Active, meaning that the related SCTP association and far-end M2UA 364 peer is ready. 366 In the process of fail-over or fail-back, it is recommended that in the 367 case of ASPs supporting call processing, stable calls do not get released. 368 It is possible that calls in transition MAY fail, although measures of 369 communication between the ASPs involved can be used to mitigate this. 370 For example, the two ASPs MAY share call state via shared memory, or MAY 371 use an ASP to ASP protocol to pass call state information. The ASP to ASP 372 protocol is outside the scope of this document. 374 1.3.5 Client/Server Model 376 It is recommended that the SG and ASP be able to support both client 377 and server operation. The peer endpoints using M2UA SHOULD be 378 configured so that one always takes on the role of client and the 379 other the role of server for initiating SCTP associations. The 380 default orientation would be for the SG to take on the role of server 381 while the ASP is the client. In this case, ASPs SHOULD initiate the 382 SCTP association to the SG. 384 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA 385 is 2904. 387 1.4 Services Provided by the M2UA Adaptation Layer 389 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 390 point in the IP network, so that the M2UA protocol layer is required to 391 provide the equivalent set of services to its users as provided by the 392 MTP Level 2 to MTP Level 3. 394 This includes the following services: 396 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 398 Also provision is made for protocol elements that enable a seamless, or 399 as seamless as possible, operation of the MTP2-User peers in the SS7 and 400 IP domains. This includes 402 Data 404 Provides the ability to transport MTP2 User information (in this case, 405 MTP Level 3 PDUs). 407 Link Establish 409 Provides the ability to request MTP Level 2 to bring SS7 links 410 in-service. 412 Link Release 414 Provides the ability to request MTP Level 2 to take SS7 links out-of- 415 service. Also, provides mechanism for MTP2 to autonomously indicate 416 that SS7 link(s) have gone out-of-service. 418 Link State 420 Provides the ability to request state change or information on a 421 per link basis. Some examples would be the forcing of Local Processor 422 Outage or flushing buffers. 424 Link Status 426 Provides a means for asynchronous notification of link state changes to 427 be reported to the upper layer (MTP Level 3). An example would be the 428 reporting of remote processor outage event. 430 Data Retrieval 432 Provides a mechanism to perform SS7 link changeover procedure in 433 the case of a SS7 link failure. 435 1.4.2 Support for communication between Layer Management modules 436 on SG and MGC 438 It is envisioned that the M2UA layer needs to provide some messages that 439 will facilitate communication between Layer Management modules on the SG 440 and MGC. These primitives are shown below: 442 To facilitate reporting of errors that arise because of backhauling MTP 443 Level 3 scenario, the following primitive is defined: 445 M-ERROR 447 The M-ERROR message is used to indicate an error with a received 448 M2UA message (e.g., interface identifier value is not known to the SG). 450 1.4.3 Support for management of active associations between SG and MGC 452 The M2UA layer on the SG keeps the state of various ASPs it is associated 453 with. A set of primitives between M2UA layer and the Layer Management 454 are defined below to help the Layer Management manage the association(s) 455 between the SG and the MGC. The M2UA layer can be instructed 456 by the Layer Management to establish a SCTP association to a peer M2UA 457 node. This procedure can be achieved using the M-SCTP ESTABLISH 458 primitive. 460 M-SCTP ESTABLISH 462 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 463 the establishment of a SCTP association to a peer M2UA node. 465 M-SCTP RELEASE 467 The M-SCTP RELEASE primitives are used to request, indicate, and 468 confirm the release of a SCTP association to a peer M2UA node. 470 The M2UA layer MAY also need to inform the status of the SCTP 471 associations to the Layer Management. This can be achieved using 472 the M-SCTP STATUS primitive. 474 The M2UA layer MAY also need to inform the status of the SCTP 475 association(s) to the Layer Management. This can be achieved using 476 the following primitive. 478 M-SCTP STATUS 480 The M-SCTP STATUS primitive is used to request and indicate the status 481 of underlying SCTP association(s). 483 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 484 status (i.e., failure, active, etc.), so that messages can be exchanged 485 between M2UA layer peers to stop traffic to the local M2UA user. This 486 can be achieved using the following primitive. 488 M-ASP STATUS 490 The ASP status is stored inside M2UA layer on both the SG and MGC 491 sides. The M-ASP STATUS primitive can be used by Layer Management to 492 request the status of the Application Server Process from the M2UA 493 layer. This primitive can also be used to indicate the status of the 494 Application Server Process. 496 M-ASP MODIFY 498 The M-ASP MODIFY primitive can be used by Layer Management to modify 499 the status of the Application Server Process. In other words, the 500 Layer Management on the ASP side uses this primitive to initiate 501 the ASPM procedures. 503 M-AS STATUS 505 The M-AS STATUS primitive can be used by Layer Management to request 506 the status of the Application Server. This primitive can also be 507 used to indicate the status of the Application Server. 509 1.5 Functions Provided by the M2UA Layer 511 1.5.1 Mapping 513 The M2UA layer MUST maintain a map of a Interface ID to a physical 514 interface on the Signaling Gateway. A physical interface would be a 515 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 516 MUST also maintain a map of Interface Identifier to SCTP association 517 and to the related stream within the association. 519 The SG maps an Interface Identifier to an SCTP association/stream 520 only when an ASP sends an ASP Active message for a particular Interface 521 Identifier. It MUST be noted, however, that this mapping is dynamic 522 and could change at any time due to a change of ASP state. This mapping 523 could even temporarily be invalid, for example during failover of one 524 ASP to another. Therefore, the SG MUST maintain the states of AS/ASP 525 and reference them during the routing of an messages to an AS/ASP. 527 An example of the logical view of relationship between SS7 link, 528 Interface Identifier, AS and ASP in the SG is shown below: 530 /---------------------------------------------------+ 531 / /------------------------------------------------|--+ 532 / / v | 533 / / +----+ act+-----+ +-------+ -+--+-|+--+- 534 SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v 535 / +----+ | +----+ | +-----+ +-------+ -+--+--+--+- 536 / +->| AS |--+ Streams 537 / +----+ | +----+ stb+-----+ 538 SS7 link2-------->|IID |-+ | ASP | 539 +----+ +-----+ 541 where IID = Interface Identifier 543 1.5.2 Status of ASPs 545 The M2UA layer on the SG MUST maintain the state of the ASPs it is 546 supporting. The state of an ASP changes because of reception of 547 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 548 or reception of indications from the local SCTP association. ASP 549 state transition procedures are described in Section 4.3.1. 551 At a SG, an Application Server list MAY contain active and inactive 552 ASPs to support ASP fail-over procedures. When, for example, both 553 a primary and a back-up ASP are available, M2UA peer protocol is 554 required to control which ASP is currently active. The ordered 555 list of ASPs within a logical Application Server is kept updated in 556 the SG to reflect the active Application Server Process(es). 558 Also the M2UA layer MAY need to inform the local management of the 559 change in status of an ASP or AS. This can be achieved using the M-ASP 560 STATUS or M-AS STATUS primitives. 562 1.5.3 SCTP Stream Management 564 SCTP allows user specified number of streams to be opened during the 565 initialization. It is the responsibility of the M2UA layer to ensure 566 proper management of these streams. Because of the unidirectional 567 nature of streams, M2UA layers are not aware of the stream information 568 from the peer M2UA layers. Instead, the Interface Identifier is 569 in the M2UA message header. 571 The use of SCTP streams within M2UA is recommended in order to minimize 572 transmission and buffering delay, therefore improving the overall 573 performance and reliability of the signaling elements. It is 574 recommended that a separate SCTP stream is used for each SS7 link. 576 1.5.4 Seamless SS7 Network Management Interworking 578 The M2UA layer on the SG SHOULD pass an indication of unavailability of 579 the M2UA-User (MTP3) to the local Layer Management, if the currently 580 active ASP moves from the ACTIVE state. If the AS moves to the DOWN 581 state while SS7 links are in-service, the SG SHOULD follow the MTP 2 582 processor outage procedures [2]. 584 1.5.5 Flow Control / Congestion 586 It is possible for the M2UA layer to be informed of IP network congestion 587 by means of an implementation-dependent function (i.e. an indication 588 from the SCTP). If the M2UA layer receives this indication, the action(s) 589 taken are implementation dependent. 591 1.6 Definition of the M2UA Boundaries 593 1.6.1 Definition of the M2UA / MTP Level 3 boundary 595 DATA 596 ESTABLISH 597 RELEASE 598 STATE 599 STATUS 600 RETRIEVAL 601 DATA RETRIEVAL 602 DATA RETRIEVAL COMPLETE 604 1.6.2 Definition of the M2UA / MTP Level 2 boundary 606 DATA 607 ESTABLISH 608 RELEASE 609 STATE 610 STATUS 611 RETRIEVAL 612 DATA RETRIEVAL 613 DATA RETRIEVAL COMPLETE 615 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 617 The upper layer and layer management primitives provided by SCTP are 618 provided in Reference [5] Section 9. 620 1.6.4 Definition of Layer Management / M2UA Boundary 622 M-SCTP ESTABLISH request 623 Direction: LM -> M2UA 624 Purpose: LM requests ASP to establish an SCTP association with an SG. 626 M-STCP ESTABLISH confirm 627 Direction: M2UA -> LM 628 Purpose: ASP confirms to LM that it has established an SCTP 629 association with an SG. 631 M-SCTP ESTABLISH indication 632 Direction: M2UA -> LM 633 Purpose: SG informs LM that an ASP has established an SCTP 634 association. 636 M-SCTP RELEASE request 637 Direction: LM -> M2UA 638 Purpose: LM requests ASP to release an SCTP association with SG. 640 M-SCTP RELEASE confirm 641 Direction: M2UA -> LM 642 Purpose: ASP confirms to LM that it has released SCTP association 643 with SG. 645 M-SCTP RELEASE indication 646 Direction: M2UA -> LM 647 Purpose: SG or IPSP informs LM that ASP has released an SCTP 648 association. 650 M-SCTP STATUS request 651 Direction: LM -> M2UA 652 Purpose: LM requests M2UA to report status of SCTP association. 654 M-SCTP STATUS indication 655 Direction: M2UA -> LM 656 Purpose: M2UA reports status of SCTP association. 658 M-ASP STATUS request 659 Direction: LM -> M2UA 660 Purpose: LM requests SG to report status of remote ASP. 662 M-ASP STATUS indication 663 Direction: M2UA -> LM 664 Purpose: SG reports status of remote ASP. 666 M-AS-STATUS request 667 Direction: LM -> M2UA 668 Purpose: LM requests SG to report status of AS. 670 M-AS-STATUS indication 671 Direction: M2UA -> LM 672 Purpose: SG reports status of AS. 674 M-NOTIFY indication 675 Direction: M2UA -> LM 676 Purpose: ASP reports that it has received a NOTIFY message 677 from its peer. 679 M-ERROR indication 680 Direction: M2UA -> LM 681 Purpose: ASP or SG reports that it has received an ERROR 682 message from its peer. 684 M-ASP-UP request 685 Direction: LM -> M2UA 686 Purpose: LM requests ASP to start its operation and send an ASP UP 687 message to the SG. 689 M-ASP-UP confirm 690 Direction: M2UA -> LM 691 Purpose: ASP reports that is has received an ASP UP Acknowledgement 692 message from the SG. 694 M-ASP-DOWN request 695 Direction: LM -> M2UA 696 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 697 message to the SG. 699 M-ASP-DOWN confirm 700 Direction: M2UA -> LM 701 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 702 message from the SG. 704 M-ASP-ACTIVE request 705 Direction: LM -> M2UA 706 Purpose: LM requests ASP to send an ASP ACTIVE message to the SG. 708 M-ASP-ACTIVE confirm 709 Direction: M2UA -> LM 710 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 711 message from the SG. 713 M-ASP-INACTIVE request 714 Direction: LM -> M2UA 715 Purpose: LM requests ASP to send an ASP INACTIVE message to the SG. 717 M-ASP-INACTIVE confirm 718 Direction: M2UA -> LM 719 Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement 720 message from the SG. 722 2.0 Conventions 724 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 725 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 726 in this document, are to be interpreted as described in [RFC2119]. 728 3.0 Protocol Elements 730 This section describes the format of various messages used in this 731 protocol. 733 3.1 Common Message Header 735 The protocol messages for MTP2-User Adaptation require a message 736 structure which contains a version, message class, message type, message 737 length, and message contents. This message header is common among all 738 signaling protocol adaptation layers: 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Version | Spare | Message Class | Message Type | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Message Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 Figure 3 Common Message Header 750 All fields in an M2UA message MUST be transmitted in the network byte 751 order, unless otherwise stated. 753 3.1.1 Version 755 The version field (vers) contains the version of the M2UA adapation 756 layer. The supported versions are: 758 Value Version 759 ----- ------- 760 1 Release 1.0 762 3.1.2 Message Type 764 The following List contains the valid Message Classes: 766 Message Class: 8 bits (unsigned integer) 768 0 Management (MGMT) Message 769 1 Reserved 770 2 Reserved 771 3 ASP State Maintenance (ASPSM) Messages 772 4 ASP Traffic Maintenance (ASPTM) Messages 773 5 Reserved 774 6 MTP2 User Adaptation (MAUP) Messages 775 Messages 776 7 to 255 Reserved 778 The following list contains the message types for the defined messages. 780 MTP2 User Adaptatation (MAUP) Messages 782 0 Reserved 783 1 Data 784 2 Establish Request 785 3 Establish Confirm 786 4 Release Request 787 5 Release Confirm 788 6 Release Indication 789 7 State Request 790 8 State Confirm 791 9 State Indication 792 10 Data Retrieval Request 793 11 Data Retrieval Confirm 794 12 Data Retrieval Indication 795 13 Data Retrieval Complete Indication 796 14 to 255 Reserved for MAUP Messages 797 Application Server Process State Maintenance (ASPSM) messages 799 0 Reserved 800 1 ASP Up (UP) 801 2 ASP Down (DOWN) 802 3 Heartbeat (BEAT) 803 4 ASP Up Ack (UP ACK) 804 5 ASP Down Ack (DOWN ACK) 805 6 Heatbeat Ack (BEAT ACK) 806 7 to 255 Reserved for ASPSM Messages 808 Application Server Process Traffic Maintenance (ASTM) messages 810 0 Reserved 811 1 ASP Active (ACTIVE) 812 2 ASP Inactive (INACTIVE) 813 3 ASP Active Ack (ACTIVE ACK) 814 4 ASP Inactive Ack (INACTIVE ACK) 815 5 to 255 Reserved for ASPTM Messages 817 Management (MGMT) Messages 819 0 Error (ERR) 820 1 Notify (NTFY) 821 2 to 255 Reserved for Management Messages 823 3.1.3 Reserved 825 The Reserved field is 8-bits. It SHOULD be set to all '0's and 826 ignored by the receiver. 828 3.1.4 Message Length 830 The Message length defines the length of the message in octets, 831 including the header. 833 3.1.5 Variable-Length Parameter Format 835 M2UA messages consist of a Common Header followed by zero or more 836 variable-length parameters, as defined by the message type. The 837 variable-length parameters contained in a message are defined in a 838 Tag-Length-Value format as shown below. 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Parameter Tag | Parameter Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 \ \ 846 / Parameter Value / 847 \ \ 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Parameter Tag: 16 bits (unsigned integer) 852 The Type field is a 16 bit identifier of the type of parameter. It takes 853 a value of 0 to 65534. 855 The value of 65535 is reserved for IETF-defined extensions. Values 856 other than those defined in specific parameter description are reserved 857 for use by the IETF. 859 Parameter Length: 16 bits (unsigned integer) 861 The Parameter Length field contains the size of the parameter in bytes, 862 including the Parameter Tag, Parameter Length, and Parameter Value 863 fields. The Parameter Length does not include any padding bytes. 865 Parameter Value: variable-length. 867 The Parameter Value field contains the actual information to be 868 transferred in the parameter. 870 The total length of a parameter (including Tag, Parameter Length and Value 871 fields) MUST be a multiple of 4 bytes. If the length of the parameter is 872 not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., 873 after the Parameter Value field) with all zero bytes. The length of the 874 padding is NOT included in the parameter length field. A sender SHOULD 875 NOT pad with more than 3 bytes. The receiver MUST ignore the padding 876 bytes. 878 3.2 M2UA Message Header 880 In addition to the common message header, there will be a M2UA specific 881 message header. The M2UA specific message header will immediately 882 follow the common message header, but will only be used with MAUP 883 messages. 885 This message header will contain the Interface Identifier. The 886 Interface Identifier identifies the physical interface at the SG for 887 which the signaling messages are sent/received. The format of the 888 Interface Identifier parameter can be text or integer, the values of which 889 are assigned according to network operator policy. The values used are of 890 local significance only, coordinated between the SG and ASP. 892 The integer formatted Interface Identifier MUST be supported. The 893 text formatted Interface Identifier MAY optionally be supported. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Tag (0x1) | Length=8 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Interface Identifier (integer) | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 Figure 4 M2UA Message Header (Integer-based Interface Identifier) 905 The Tag value for Integer-based Interface Identifier is 0x1. The length is 906 always set to a value of 8. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Tag (0x3) | Length | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Interface Identifier (text) | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 5 M2UA Message Header (Text-based Interface Identifier) 920 The Tag value for the Text-based Interface Identifier is 0x3. The 921 length is variable. 923 3.3 M2UA Messages 925 The following section defines the messages and parameter contents. The 926 M2UA messages will use the common message header (Figure 3) and the 927 M2UA message header (Figure 4). 929 3.3.1 MTP2 User Adaptation Messages 931 3.3.1.1 Data 933 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 934 Data message contains the protocol data. 936 The format for the Data Message parameters is as follows: 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Protocol Data | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 The Protocol Data field contains the MTP2-User application message in 947 network byte order starting with the Signaling Information Octet (SIO). 949 3.3.1.2 Establish (Request, Confirmation) 951 The Establish Request message is used to establish the link or to 952 indicate that the channel has been established. The MGC controls the state of the 953 SS7 link. When the MGC desires the SS7 link to be in-service, 954 it will send the Establish Request message. Note that the gateway 955 MAY already have the SS7 link established at its layer. If so, upon 956 receipt of an Establish Request, the gateway takes no action except to 957 send an Establish Confirm. 959 When the MGC sends an M2UA Establish Request message, the MGC MAY 960 start a timer. This timer would be stopped upon receipt of an M2UA 961 Establish Confirm. If the timer expires, the MGC would re-send the 962 M2UA Establish Request message and restart the timer. In other words, 963 the MGC MAY continue to request the establishment of the data link 964 on periodic basis until the desired state is achieved or take some 965 other action (notify the Management Layer). 967 The mode (Normal of Emergency) for bringing the link in service is 968 defaulted to Normal. The State Request (described in Section 3.3.1.4 969 below) can be used to change the mode to Emergency. 971 3.3.1.3 Release (Request, Indication, Confirmation) 973 This Release Request message is used to release the channel. The 974 Release Confirm and Indication messages are used to indicate that the 975 channel has been released. 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Reason | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 The valid values for Reason are shown in the following table. 985 Define Value Description 986 RELEASE_MGMT 0x0 Management layer generated release 987 RELEASE_PHYS 0x1 Physical layer alarm generated release 988 RELEASE_SIOS 0x2 Receipt of SIOS 989 RELEASE_T6 0x3 Release due to expiration of Timer T6 990 RELEASE_T7 0x4 Release due to expiration of Timer T7 991 RELEASE_BSN 0x5 Release due to invalid BSN (2 of 3) 992 RELEASE_FIB 0x6 Release due to invalid FIB (2 of 3) 993 RELEASE_SUERM 0x7 Release due to failure reported by SUERM 994 RELEASE_IAC 0x8 Release due to initial alignment failed 995 RELEASE_OTHER 0x9 Other reason SS7 link out-of-service 997 For the Release Request, the only valid Reason is RELEASE_MGMT. For 998 Release Confirm, the Reason field would also be RELEASE_MGMT (a 999 reflection of Release Request). The other valid values for Reason 1000 would be used for Release Indication. 1002 3.3.1.4 State (Request, Confirm) 1004 The State Request message can be sent from a MGC to cause an action 1005 on a particular SS7 link supported by the Signaling Gateway. The 1006 gateway sends a State Confirm to the MGC if the action has been success- 1007 fully completed. The State Confirm reflects that state value received 1008 in the State Request message. 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | State | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 The valid values for State are shown in the following table. 1018 Define Value Description 1019 STATUS_LPO_SET 0x0 Request local processor outage 1020 STATUS_LPO_CLEAR 0x1 Request local processor outage 1021 recovered 1022 STATUS_EMER_SET 0x2 Request emergency alignment 1023 procedure 1024 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1025 emergency) procedure 1026 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit 1027 buffers 1028 STATUS_CONTINUE 0x5 Continue 1030 3.3.1.5 State Indication 1032 The MTP2 State Indication message can be sent from a gateway to an 1033 ASP to indicate a condition on a link. 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | State | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 The valid values for State are shown in the following table. 1043 Define Value Description 1044 EVENT_ENTER_LPO 0x0 Entered local processor outage 1045 EVENT_EXIT_LPO 0x1 Exited local processor outage 1046 EVENT_ENTER_CONG 0x2 Entered a congested state 1047 EVENT_EXIT_CONG 0x3 Exited a congested state 1048 EVENT_PHYS_UP 0x4 Physical interface up 1049 EVENT_PHYS_DOWN 0x5 Physical interface down 1050 EVENT_PROTOCOL_ERR 0x6 Protocol error occurred 1051 EVENT_REM_ENTER_CONG 0xc Remote entered congestion 1052 EVENT_REM_EXIT_CONG 0xd Remote exited congestion 1053 EVENT_REM_ENTER_PO 0xe Remote entered processor outage 1054 EVENT_REM_EXIT_PO 0xf Remote exited processor outage 1056 3.3.1.6 Retrieval (Request, Confirm) 1058 The MTP2 Retrieval Request message is used during the MTP Level 3 1059 changeover procedure to request the BSN, to retrieve PDUs from the 1060 retransmit queue or to flush PDUs from the retransmit queue. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Action | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | fsn_bsn | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 The valid values for Action are shown in the following table. 1072 Define Value Description 1073 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1074 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 1075 queue 1076 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue 1078 In the Retrieval Request message, the fsn_bsn field SHOULD be ignored if 1079 the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The fsn_bsn 1080 field contains the FSN of the far end if the Action is ACTION_RTRV_MSGS. 1082 When the Signaling Gateway sends a Retrieval Confirm to this request, 1083 it echos the action and puts the BSN in the fsn_bsn field if the action 1084 was ACTION_RTRV_BSN. If there is a failure in retrieving the BSN, the 1085 fsn_bsn SHOULD contain a -1 (0xffffffff). For a Retrieval Confirm with 1086 Action of ACTION_RTRV_MSGS or ACTION_DROP_MSGS, the value received in 1087 the fsn_bsn field in the Request message will be sent. 1089 3.3.1.7 Retrieval Indication 1091 The Retrieval Indication message is sent by the Signaling Gateway 1092 with a PDU from the retransmit queue. The Retrieval Indication 1093 message does not contain the Action or fsn_bsn fields, just a MTP3 1094 Protocol Data Unit (PDU) from the retransmit queue. 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | PDU from retransmit queue | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 3.3.1.8 Retrieval Complete Indication 1106 The MTP2 Retrieval Complete Indication message is exactly the same as 1107 the MTP2 Retrieval Indication message except that it also indicates that 1108 it contains the last PDU from the retransmit queue. 1110 3.3.2 Application Server Process Maintenance (ASPM) Messages 1112 The ASPM messages will only use the common message header. 1114 3.3.2.1 ASP UP (ASPUP) 1116 The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer 1117 that the Adaptation layer is ready to receive traffic or maintenance 1118 messages. 1120 The ASPUP message contains the following parameters 1122 Info String (optional) 1124 The format for ASPUP Message parameters is as follows: 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Tag (0x4) | Length | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | INFO String* | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1137 character string along with the message. Length of the INFO String 1138 parameter is from 0 to 255 characters. No procedures are presently 1139 identified for its use but the INFO String MAY be used for debugging 1140 purposes. 1142 3.3.2.2 ASP Up Ack 1144 The ASP UP Ack message is used to acknowledge an ASP Up message received 1145 from a remote M2UA peer. 1147 The ASPUP Ack message contains the following parameters: 1149 INFO String (optional) 1151 The format for ASPUP Ack Message parameters is as follows: 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Tag (0x2) | Length | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Adaptation Layer Identifier* | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Tag (0x4) | Length | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | INFO String* | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 The format and description of the optional Info String parameter is the 1170 same as for the ASP UP message (See Section 3.3.2.1.) 1172 3.3.2.3 ASP Down (ASPDN) 1174 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1175 that the adaptation layer is not ready to receive traffic or 1176 maintenance messages. 1178 The ASPDN message contains the following parameters 1180 Reason 1181 INFO String (Optional) 1183 The format for the ASPDN message parameters is as follows: 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Reason | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Tag (0x4) | Length | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | INFO String* | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 The format and description of the optional Info String parameter is the 1198 same as for the ASP Up message (See Section 3.3.2.1.) 1200 The Reason parameter indicates the reason that the remote M2UA 1201 adaptation layer is unavailable. The valid values for Reason are shown 1202 in the following table. 1204 Value Description 1205 0x1 Management 1207 3.3.2.4 ASP Down Ack 1209 The ASP Down Ack message is used to acknowledge an ASP Down message 1210 received from a remote M2UA peer. 1212 The ASP Down Ack message contains the following parameters: 1214 Reason 1215 INFO String (Optional) 1217 The format for the ASPDN Ack message parameters is as follows: 1219 0 1 2 3 1220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Reason | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Tag (0x4) | Length | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | INFO String* | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 The format and description of the optional Info String parameter is the 1232 same as for the ASP UP message (See Section 3.3.2.1.) 1234 The format of the Reason parameter is the same as for the ASP Down message 1235 (See Section 3.3.2.3). 1237 3.3.2.5 ASP Active (ASPAC) 1239 The ASPAC message is sent by an ASP to indicate to an SG that it is 1240 Active and ready to be used. 1242 The ASPAC message contains the following parameters 1244 Traffic Mode Type (Mandatory) 1245 Interface Identifier (Optional) 1246 - Combination of integer and integer ranges, OR 1247 - string (text formatted) 1248 INFO String (Optional) 1250 The format for the ASPAC message using integer formatted Interface 1251 Identifiers is as follows: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Traffic Mode Type | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Tag (0x1=integer) | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Interface Identifiers* | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Tag (0x8=integer range) | Length | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Interface Identifier Start1* | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Interface Identifier Stop1* | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Interface Identifier Start2* | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Interface Identifier Stop2* | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 . . 1275 . . 1276 . . 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Interface Identifier StartN* | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Interface Identifier StopN* | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Additional Interface Identifiers | 1284 | of Tag Type 0x1 or 0x8 | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Tag (0x4) | Length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | INFO String* | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 The format for the ASPAC message using text formatted (string) 1295 Interface Identifiers is as follows: 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Traffic Mode Type | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Tag (0x3=string) | Length | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Interface Identifier* | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Additional Interface Identifiers | 1310 | of Tag Type 0x3 | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Tag (0x4) | Length | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | INFO String* | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 The Traffic Mode Type parameter identifies the traffic mode of 1321 operation of the ASP within an AS. The valid values for Type are 1322 shown in the following table: 1324 Value Description 1325 0x1 Over-ride 1327 Within a particular Interface Identifier, only one Type can be used. 1328 The Over-ride value indicates that the ASP is operating in Over-ride 1329 mode, where the ASP takes over all traffic in an Application Server 1330 (i.e., primary/back-up operation), over-riding any currently active 1331 ASPs in the AS. 1333 The optional Interface Identifiers parameter contains a list of 1334 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1335 (Type 0x3)indexing the Application Server traffic that the sending 1336 ASP is configured/registered to receive. If integer formatted 1337 Interface Identifiers are being used, the ASP can also send ranges of 1338 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1339 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1340 formatted Interface Identifiers (0x3) cannot be used with either 1341 Integer (0x1) or Integer Range (0x8) types. 1343 If no Interface Identifiers are included, the message is for all 1344 provisioned Interface Identifiers within the AS. If only a subset 1345 of Interface Identifiers are includes, the ASP is noted as Active 1346 for all the Interface Identifiers provisioned for the AS. 1348 Note: If the optional Interface Identifier parameter is present, the 1349 integer formatted Interface Identifier MUST be supported, while the 1350 text formatted Interface Identifier MAY be supported. 1352 An SG that receives an ASPAC with an incorrect Traffic Mode Type for 1353 a particular Interface Identifier will respond with an Error Message 1354 (Cause: Unsupported Traffic Handling Mode). 1356 The format and description of the optional Info String parameter is the 1357 same as for the ASP UP message (See Section 3.3.2.1.). 1359 3.3.2.6 ASP Active Ack 1361 The ASPAC Ack message is used to acknowledge an ASP-Active message 1362 received from a remote M2UA peer. 1364 The ASPAC Ack message contains the following parameters: 1366 Traffic Mode Type (Mandatory) 1367 Interface Identifier (Optional) 1368 - Combination of integer and integer ranges, OR 1369 - string (text formatted) 1370 INFO String (Optional) 1372 The format for the ASPAC Ack message with Integer-formatted Interface 1373 Identifiers is as follows: 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Traffic Mode Type | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | Tag (0x1=integer) | Length | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Interface Identifiers* | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Tag (0x8=integer range) | Length | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Interface Identifier Start1* | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Interface Identifier Stop1* | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Interface Identifier Start2* | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Interface Identifier Stop2* | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 . . 1397 . . 1398 . . 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Interface Identifier StartN* | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Interface Identifier StopN* | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Additional Interface Identifiers | 1406 | of Tag Type 0x1 or 0x8 | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Tag (0x4) | Length | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | INFO String* | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 The format for the ASP Active Ack message using text formatted (string) 1417 Interface Identifiers is as follows: 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Traffic Mode Type | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Tag (0x3=string) | Length | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Interface Identifier* | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Additional Interface Identifiers | 1432 | of Tag Type 0x3 | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Tag (0x4) | Length | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | INFO String* | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 The format and description of the optional Info String parameter is the 1443 same as for the ASP UP message (See Section 3.3.2.1.) 1445 The format of the Type and Interface Identifier parameters is the same 1446 as for the ASP Active message (See Section 3.3.2.5). 1448 3.3.2.7 ASP Inactive (ASPIA) 1450 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1451 longer an active ASP to be used from within a list of ASPs. The SG will 1452 respond with an ASPIA Ack message and either discard incoming messages 1453 or buffer for a timed period and then discard. 1455 The ASPIA message contains the following parameters 1457 Traffic Mode Type (Mandatory) 1458 Interface Identifiers (Optional) 1459 - Combination of integer and integer ranges, OR 1460 - string (text formatted) 1461 INFO String (Optional) 1463 The format for the ASP Inactive message parameters using Integer 1464 formatted Interface Identifiers is as follows: 1466 0 1 2 3 1467 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 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Traffic Mode Type | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Tag (0x1=integer) | Length | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Interface Identifiers* | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Tag (0x8=integer range) | Length | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Interface Identifier Start1* | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Interface Identifier Stop1* | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Interface Identifier Start2* | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Interface Identifier Stop2* | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 . . 1488 . . 1489 . . 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Interface Identifier StartN* | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Interface Identifier StopN* | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Additional Interface Identifiers | 1497 | of Tag Type 0x1 or 0x8 | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Tag (0x4) | Length | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | INFO String* | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 The format for the ASP Inactive message using text formatted (string) 1508 Interface Identifiers is as follows: 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Traffic Mode Type | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Tag (0x3=string) | Length | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Interface Identifier* | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Additional Interface Identifiers | 1523 | of Tag Type 0x3 | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Tag (0x4) | Length | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | INFO String* | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 The Traffic Mode Type parameter identifies the traffic mode of 1534 operation of the ASP within an AS. The valid values for Traffic Mode 1535 Type are shown in the following table: 1537 Value Description 1538 0x1 Over-ride 1540 The format and description of the optional Interface Identifiers and 1541 Info String parameters is the same as for the ASP Active message (See 1542 Section 3.3.2.3.) 1544 The optional Interface Identifiers parameter contains a list of 1545 Interface Identifier integers indexing the Application Server traffic 1546 that the sending ASP is configured/registered to receive, but does not 1547 want to receive at this time. 1549 3.3.2.8 ASP Inactive Ack 1551 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 1552 received from a remote M2UA peer. 1554 The ASPIA Ack message contains the following parameters: 1556 Traffic Mode Type (Mandatory) 1557 Interface Identifiers (Optional) 1558 - Combination of integer and integer ranges, OR 1559 - string (text formatted) 1560 INFO String (Optional) 1562 The format for the ASPIA Ack message is as follows: 1564 0 1 2 3 1565 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 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Traffic Mode Type | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | Tag (0x1=integer) | Length | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Interface Identifiers* | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Tag (0x8=integer range) | Length | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Interface Identifier Start1* | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Interface Identifier Stop1* | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | Interface Identifier Start2* | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | Interface Identifier Stop2* | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 . . 1586 . . 1587 . . 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Interface Identifier StartN* | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Interface Identifier StopN* | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | Additional Interface Identifiers | 1595 | of Tag Type 0x1 or 0x8 | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Tag (0x4) | Length | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | INFO String* | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 The format for the ASP Inactive Ack message using text formatted 1606 (string) Interface Identifiers is as follows: 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Traffic Mode Type | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Tag (0x3=string) | Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Interface Identifier* | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Additional Interface Identifiers | 1621 | of Tag Type 0x3 | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Tag (0x4) | Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | INFO String* | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 The format of the Traffic Mode Type and Interface Identifier 1632 parameters is the same as for the ASP Inactive message 1633 (See Section 3.3.2.7). 1635 The format and description of the optional Info String parameter is 1636 the same as for the ASP Up message (See Section 3.3.2.1). 1638 3.3.2.9 Heartbeat (BEAT) 1640 The Heartbeat message is optionally used to ensure that the M2UA peers 1641 are still available to each other. It is recommended for use when 1642 the M2AU runs over a transport layer other than the SCTP, which has its 1643 own heartbeat. 1645 The BEAT message contains the following parameters: 1647 Heartbeat Data Optional 1649 The format for the BEAT message is as follows: 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Tag = 9 | Length | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 \ \ 1657 | Heartbeat Data * | 1658 \ \ 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 The Heartbeat Data parameter contents are defined by the sending node. 1662 The Heartbeat Data could include, for example, a Heartbeat Sequence 1663 Number and, or Timestamp. The receiver of a Heartbeat message does 1664 not process this field as it is only of significance to the sender. 1665 The receiver MUST respond with a Heartbeat Ack message. 1667 3.3.2.10 Heartbeat Ack (BEAT-Ack) 1669 The Heartbeat Ack message is sent in response to a received Heartbeat 1670 message. It includes all the parameters of the received Heartbeat 1671 message, without any change. 1673 3.3.3 Layer Management (MGMT) Messages 1675 3.3.3.1 Error (ERR) 1677 The Error message is used to notify a peer of an error event 1678 associated with an incoming message. For example, the message type 1679 might be unexpected given the current state, or a parameter value might 1680 be invalid. 1682 The ERR message contains the following parameters: 1684 Error Code 1685 Diagnostic Information (optional) 1687 The format for the ERR message is as follows: 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Error Code | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Tag (0x7) | Length | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | Diagnostic Information* | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 The Error Code parameter indicates the reason for the Error Message. 1702 The Error parameter value can be one of the following values: 1704 Invalid Version 0x1 1705 Invalid Interface Identifier 0x2 1706 Invalid Adaptation Layer Identifier 0x3 1707 Invalid Message Type 0x4 1708 Unsupported Traffic Handling Mode 0x5 1709 Unexpected Message 0x6 1710 Protocol Error 0x7 1711 Invalid Stream Identifier 0x8 1713 The "Invalid Version" error would be sent if a message was 1714 received with an invalid or unsupported version. The Error message 1715 would contain the supported version in the Common header. The 1716 Error message could optionally provide the supported version in 1717 the Diagnostic Information area. 1719 The "Invalid Interface Identifier" error would be sent by a SG if 1720 an ASP sends a message with an invalid (unconfigured) Interface 1721 Identifier value. 1723 The "Unsupported Traffic Handling Mode" error would be sent by a SG 1724 if an ASP sends an ASP Active with an unsupported Traffic Handling 1725 Mode. An example would be a case in which the SG did not support 1726 load-sharing. 1728 The "Unexpected Message" error would be sent by an ASP if it received 1729 a MAUP message from an SG while it was in the Inactive state. 1731 The "Protocol Error" error would be sent for any protocol anomaly 1732 (i.e. a bogus message). 1734 The "Invalid Stream Identifier" error would be sent if a message 1735 was received on an unexpected SCTP stream (i.e. a stream that did 1736 not have an Interface Identifier associated with it). 1738 The "Unsupported Interface Identifier Type" error would be sent by 1739 a SG if an ASP sends a Text formatted Interface Identifier and the 1740 SG only supports Integer formatted Interface Identifiers. When 1741 the ASP receives this error, it will need to resend its message with 1742 an Integer formatted Interface Identifier. 1744 The optional Diagnostic information can be any information germain to 1745 the error condition, to assist in identification of the error condition. 1746 In the case of an Invalid Version Error Code the Diagnostic information 1747 includes the supported Version parameter. In the other cases, the 1748 Diagnostic information MAY be the first 40 bytes of the offending message. 1750 3.3.3.2 Notify (NTFY) 1752 The Notify message used to provide an autonomous indication of M2UA 1753 events to an M2UA peer. 1755 The NTFY message contains the following parameters: 1757 Status Type 1758 Status Identification 1759 Interface Identifiers (Optional) 1760 INFO String (Optional) 1762 The format for the Notify message with Integer-formatted Interface 1763 Identifiers is as follows: 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Status Type | Status Identification | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Tag (0x1=integer) | Length | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Interface Identifiers* | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Tag (0x8=integer range) | Length | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Interface Identifier Start1* | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Interface Identifier Stop1* | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Interface Identifier Start2* | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Interface Identifier Stop2* | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 . . 1787 . . 1788 . . 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Interface Identifier StartN* | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Interface Identifier StopN* | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Additional Interface Identifiers | 1796 | of Tag Type 0x1 or 0x8 | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Tag (0x4) | Length | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | INFO String* | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 The format for the Notify message with Text-formatted Interface 1807 Identifiers is as follows: 1809 0 1 2 3 1810 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 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Status Type | Status Identification | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Tag (0x3=string) | Length | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Interface Identifier* | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Additional Interface Identifiers | 1822 | of Tag Type 0x3 | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Tag (0x4) | Length | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | INFO String* | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 The Status Type parameter identifies the type of the Notify message. 1833 The following are the valid Status Type values: 1835 Value Description 1836 0x1 Application Server state change (AS_State_Change) 1837 0x2 Other 1839 The Status Information parameter contains more detailed information for 1840 the notification, based on the value of the Status Type. If the Status 1841 Type is AS_State_Change the following Status Information values are used: 1843 Value Description 1844 1 Application Server Down (AS_Down) 1845 2 Application Server Inactive (AS_Inactive) 1846 3 Application Server Active (AS_Active) 1847 4 Application Server Pending (AS_Pending) 1849 These notifications are sent from an SG to an ASP upon a change in status 1850 of a particular Application Server. The value reflects the new state of 1851 the Application Server. 1853 If the Status Type is Other, then the following Status Information values 1854 are defined: 1856 Value Description 1857 1 Insufficient ASP resources active in AS 1858 2 Alternate ASP Active 1860 This notification is not based on the SG reporting the state change of an 1861 ASP or AS. In the Insufficient ASP Resources case, the SG is 1862 indicating to an "Inactive" ASP(s) in the AS that another ASP is 1863 required in order to handle the load of the AS (Load-sharing mode). 1864 For the Alternate ASP Active case, an ASP is informed when an alternate 1865 ASP transitions to the ASP-Active state in Over-ride mode. 1867 The format and description of the optional Interface Identifiers and 1868 Info String parameters is the same as for the ASP Active message 1869 (See Section 3.3.2.3.) 1870 4.0 Procedures 1872 The M2UA layers needs to respond to various primitives it receives from 1873 other layers as well as messages it receives from the peer-to-peer 1874 messages. This section describes various procedures involved in 1875 response to these events. 1877 4.1 Procedures to Support Service in Section 1.4.1 1879 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 1880 MTP Level 3 boundary" service. 1882 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 1884 On receiving a primitive from the local upper layer, the M2UA layer will 1885 send the corresponding MAUP message (see Section 2) to its peer. The 1886 M2UA layer MUST fill in various fields of the common and specific headers 1887 correctly. In addition the message needs to be sent on the SCTP stream 1888 that corresponds to the SS7 link. 1890 4.1.2 MAUP Message Procedures 1892 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 1893 SG or MGC needs to invoke the corresponding layer primitives to the 1894 local MTP Level 2 or MTP Level 3 layer. 1896 4.2 Procedures to Support Service in Section 1.4.2 1898 These procedures achieve the M2UA layer's "Support for Communication 1899 between Layer Managements" service. 1901 4.2.1 Layer Management Primitives Procedure 1903 On receiving these primitives from the local layer, the M2UA layer will 1904 send the corresponding MGMT message (Error) to its peer. The M2UA layer 1905 MUST fill in the various fields of the common and specific headers 1906 correctly. 1908 An M-SCTP ESTABLISH request from Layer Management will initiate the 1909 establishment of an SCTP association. An M-SCTP ESTABLISH confirm 1910 will be sent to Layer Management when the initiated association set-up 1911 is complete. An M-SCTP ESTABLISH indication is sent to Layer 1912 Management upon successful completion of an incoming SCTP association 1913 set-up from a peer M2UA node 1915 An M-SCTP RELEASE request from Layer Management will initiate the 1916 tear-down of an SCTP association. An M-SCTP RELEASE confirm will 1917 be sent by Layer Management when the association teardown is complete. 1918 An M-SCTP RELEASE indication is sent to Layer Management upon 1919 successful tear-down of an SCTP association initiated by a peer M2UA. 1921 M-SCTP STATUS request and indication support a Layer Management 1922 query of the local status of a particular SCTP association. 1924 M-NOTIFY indication and M-ERROR indication indicate to Layer 1925 Management the notification or error information contained in a 1926 received M2UA Notify or Error message respectively. These indications 1927 can also be generated based on local M2UA events. 1929 M-ASP STATUS request/indication and M-AS-STATUS request/indication 1930 support a Layer Management query of the local status of a particular 1931 ASP or AS. No M2UA peer protocol is invoked. 1933 M-ASP Up request, M-ASP Down request, M-ASP-INACTIVE request and 1934 M-ASP-ACTIVE request allow Layer Management at an ASP to initiate 1935 state changes. These requests result in outgoing M2UA ASP UP, 1936 ASP DOWN, ASP INACTIVE and ASP ACTIVE messages. 1938 M-ASP Up confirmation, M-ASP Down confirmation, M-ASP-INACTIVE 1939 confirmation and M-ASP-ACTIVE confirmation indicate to Layer 1940 Management that the previous request has been confirmed. 1942 All MGMT messages are sent on a sequenced stream to ensure ordering. 1943 SCTP stream '0' SHOULD be used. 1945 4.2.2 MGMT message procedures 1947 Upon receipt of MGMT messages the M2UA layer MUST invoke the corresponding 1948 Layer Management primitives indications (e.g., M-AS Status ind., M-ASP 1949 Status ind., M-ERROR ind...) to the local layer management. 1951 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 1952 the notification or error information contained in a received M2UA 1953 Notify or Error message. These indications can also be generated 1954 based on local M2UA events. 1956 All MGMT messages are sent on a sequenced stream to ensure ordering. 1957 SCTP stream '0' SHOULD be used. 1959 4.3 Procedures to Support Service in Section 1.4.3 1961 These procedures achieve the M2UA layer's "Support for management of 1962 active associations between SG and MGC" service. 1964 4.3.1 State Maintenance 1966 The M2UA layer on the SG maintains the state of each AS, in each 1967 Appliction Server that it is configured to receive traffic. 1969 4.3.1.1 ASP States 1971 The state of the each ASP, in each AS that it is configured, is 1972 maintained in the M2UA layer on the SG. The state of an ASP changes 1973 due to events. The events include 1975 * Reception of messages from peer M2UA layer at that ASP 1976 * Reception of some messages from the peer M2UA layer at other 1977 ASPs in the AS 1978 * Reception of indications from SCTP layer 1980 The ASP state transition diagram is shown in Figure 6. The possible 1981 states of an ASP are the following: 1983 ASP Down: Application Server Process is unavailable and/or the related 1984 SCTP association is down. Initially all ASPs will be in this state. 1985 An ASP in this state SHOULD NOT not be sent any M2UA messages. 1987 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 1988 related SCTP association is up) but application traffic is stopped. 1989 In this state the ASP can be sent any non-MAUP M2UA messages. 1991 ASP-ACTIVE The remote M2UA peer at the ASP is available and 1992 application traffic is active. 1994 Figure 6 ASP State Transition Diagram 1996 +-------------+ 1997 +----------------------| | 1998 | Alternate +-------| ASP-ACTIVE | 1999 | ASP | +-------------+ 2000 | Takeover | ^ | 2001 | | ASP | | ASP 2002 | | Active | | Inactive 2003 | | | v 2004 | | +-------------+ 2005 | | | | 2006 | +------>| ASP-INACT | 2007 | +-------------+ 2008 | ^ | 2009 ASP Down/ | ASP | | ASP Down / 2010 SCTP CDI | Up | | SCTP CDI 2011 | | v 2012 | +-------------+ 2013 +--------------------->| | 2014 | ASP Down | 2015 +-------------+ 2017 SCTP CDI The local SCTP layer's Communication Down Indication to the 2018 Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this 2019 indication when it detects the loss of connectivity to the ASP's peer 2020 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 2021 notification and COMMUNICATION LOST notification from the SCTP. 2023 4.3.1.2 AS States 2025 The state of the AS is maintained in the M2UA layer on the SG. 2027 The state of an AS changes due to events. These events include the 2028 following: 2030 * ASP state transitions 2031 * Recovery timer triggers 2033 The possible states of an AS are the following: 2035 AS-DOWN: The Application Server is unavailable. This state implies 2036 that all related ASPs are in the ASP Down state for this AS. 2037 Initially the AS will be in this state. 2039 AS-INACTIVE: The Application Server is available but no application traffic 2040 is active (i.e., one or more related ASPs are in the ASP-Inactive state, 2041 but none in the ASP-Active state). 2043 AS-ACTIVE: The Application Server is available and application traffic 2044 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2046 AS-PENDING: An active ASP has transitioned from active to inactive or 2047 down and it was the last remaining active ASP in the AS. A recovery 2048 timer T(r) will be started and all incoming SCN messages will be 2049 queued by the SG. If an ASP becomes active before T(r) expires, the 2050 AS will move to AS-ACTIVE state and all the queued messages will be 2051 sent to the active ASP. 2053 If T(r) expires before an ASP becomes active, the SG stops queuing 2054 messages and discards all previously queued messages. The AS will move 2055 to AS-Inactive if at least one ASP is in ASP-Inactive state, otherwise it 2056 will move to AS-DOWN state. 2058 Figure 7 AS State Transition Diagram 2060 +----------+ one ASP trans ACTIVE +-------------+ 2061 | |------------------------>| | 2062 | AS-INACT | | AS-ACTIVE | 2063 | | | | 2064 | |< | | 2065 +----------+ \ +-------------+ 2066 ^ | \ Tr Trigger ^ | 2067 | | \ at least one | | 2068 | | \ ASP in UP | | 2069 | | \ | | 2070 | | \ | | 2071 | | \ | | 2072 one ASP | | \ one ASP | | Last ACTIVE ASP 2073 trans | | all ASP \------\ trans to | | trans to INACT 2074 to | | trans to \ ACTIVE | | or DOWN 2075 INACT | | DOWN \ | | (start Tr timer) 2076 | | \ | | 2077 | | \ | | 2078 | | \ | | 2079 | v \ | v 2080 +----------+ \ +-------------+ 2081 | | -| | 2082 | AS-DOWN | | AS-PENDING | 2083 | | | (queueing) | 2084 | |<------------------------| | 2085 +----------+ Tr Expiry and no +-------------+ 2086 ASP in INACTIVE state 2088 Tr = Recovery Timer 2090 4.3.2 ASPM procedures for primitives 2092 Before the establishment of an SCTP association the ASP state at both 2093 the SG and ASP is assumed to be "Down". 2095 As the ASP is responsible for initiating the setup of an SCTP 2096 association to an SG, the M2UA layer at an ASP receives an M-SCTP 2097 ESTABLISH request primitive from the Layer Management, the M2UA layer 2098 will try to establish an SCTP association with the remote M2UA peer at 2099 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2100 primitive from the SCTP, the M2UA layer will invoke the primitive 2101 M-SCTP ESTABLISH confirm to the Layer Management. 2103 At the SG, the M2UA layer will receive an SCTP Communication Up 2104 indication primitive from the SCTP. The M2UA layer will then invoke 2105 the primitive M-SCTP ESTABLISH indication to the Layer Management. 2107 Once the SCTP association is establishedand assuming that the local 2108 M2UA-User is ready, the local ASP M2UA Application Server Process 2109 Maintenance (ASPM) function will initiate the ASPM procedures, using 2110 the ASP Up/-Down/-Active/-Inactive messages to convey the ASP-state to 2111 the SG - see Section 4.3.3. 2113 The Layer Management and the M2UA layer on SG can communicate the 2114 status of the application server using the M-AS STATUS primitives. 2115 The Layer Managements and the M2UA layers on both the SG and ASP 2116 can communicate the status of an SCTP association using the 2117 M-SCTP STATUS primitives. 2119 If the Layer Management on SG or ASP wants to bring down an SCTP 2120 association for management reasons, they would send M-SCTP RELEASE 2121 request primitive to the local M2UA layer. The M2UA layer would release 2122 the SCTP association and upon receiving the SCTP Communication Down 2123 indication from the underlying SCTP layer, it would inform the local 2124 Layer Management using M-SCTP RELEASE confirm primitive. 2126 If the M2UA layer receives an SCTP-Communication Down indication 2127 from the underlying SCTP layer, it will inform the Layer 2128 Management by invoking the M-SCTP RELEASE indication primitive. The 2129 state of the ASP will be moved to "Down" at both the SG and ASP. 2131 At an ASP, the Layer Management MAY try to reestablish the SCTP 2132 association using M-SCTP ESTABLISH request primitive. 2134 4.3.3 ASPM procedures for peer-to-peer messages 2136 All ASPM messages are sent on a sequenced stream to ensure ordering. 2137 SCTP stream '0' SHOULD is used. 2139 4.3.3.1 ASP-Inactive 2141 After an ASP has successfully established an SCTP association to an SG, 2142 the SG waits for the ASP to send an ASP Up message, indicating that the 2143 ASP M2UA peer is available. The ASP is always the initiator of the 2144 ASP Up exchange. 2146 When an ASP Up message is received at an SG and internally the ASP is 2147 not considered locked-out for local management reasons, the SG marks 2148 the remote ASP as Inactive. The SG responds with an ASP Up Ack message 2149 in acknowledgement. The SG sends an-Up Ack message in response to a 2150 received ASP Up message even if the ASP is already marked as "Inactive" 2151 at the SG. 2153 If for any local reason the SG cannot respond with an ASP Up, the SG 2154 responds to a ASP Up with a ASP Down Ack message. 2156 At the ASP, the ASP Up Ack message received from the SG is not 2157 acknowledged by the ASP. If the ASP does not receive a response from 2158 the SG, or an ASP Down is received, the ASP MAY resend ASP Up messages 2159 every 2 seconds until it receives a ASP Up Ack message from the 2160 SG. The ASP MAY decide to reduce the frequency (say to every 5 2161 seconds) if an ASP Up Ack is not received after a few tries. 2163 The ASP MUST wait for the ASP Up Ack message from the SG before 2164 sending any ASP traffic control messages (ASPAC or ASPIA) or Data 2165 messages or it will risk message loss. If the SG receives Data 2166 messages before an ASP Up is received, the SG SHOULD discard. 2168 4.3.3.2 ASP Down 2170 The ASP will send an ASP Down to an SG when the ASP is to be removed 2171 from the list of ASPs in all Application Servers that it is a member 2172 and no longer receive any M2UA traffic or management messages. 2174 Whether the ASP is permanently removed from an AS is a function of 2175 configuration management. 2177 The SG marks the ASP as "Down" and returns an ASP Down Ack message to 2178 the ASP if one of the following events occur: 2180 - an ASP Down message is received from the ASP, 2181 - another ASPM message is received from the ASP and the SG has 2182 locked out the ASP for management reasons. 2184 The SG sends anASP Down Ack message in response to a received ASP Down 2185 message from the ASP even if the ASP is already marked as "Down" at 2186 the SG. 2188 If the ASP does not receive a response from the SG, the ASP MAY send 2189 ASP Down messages every 2 seconds until it receives an ASP Down Ack 2190 message from the SG or the SCTP association goes down. The ASP MAY 2191 decide to reduce the frequency (say to every 5 seconds) if an ASP Down 2192 Ack is not received after a few tries. 2194 4.3.3.3 M2UA Version Control 2196 If a ASP Up message with an unsupported version is received, the 2197 receiving end responds with an Error message, indicating the version the 2198 receiving node supports. 2200 This is useful when protocol version upgrades are being performed in a 2201 network. A node upgraded to a newer version SHOULD support the older 2202 versions used on other nodes it is communicating with. Because ASPs 2203 initiate the ASP Up procedure it is assumed that the Error message would 2204 normally come from the SG. 2206 4.3.3.4 ASP-Active 2208 Any time after the ASP has received a ASP Up Ack from the SG, the ASP 2209 sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready 2210 to start processing traffic. In the case where an ASP is configured/- 2211 registered to process the traffic for more than one Application Server 2212 across an SCTP association, the ASPAC contains one or more Interface 2213 Identifiers to indicate for which Application Servers the ASPAC applies. 2215 When an ASP Active (ASPAC) message is received, the SG responds to the 2216 ASP with a ASPAC Ack message acknowledging that the ASPAC was received 2217 and starts sending traffic for the associated Application Server(s) 2218 to that ASP. 2220 The ASP MUST wait for the ASP-Active Ack message from the SG before 2221 sending any Data messages or it will risk message loss. If the SG 2222 receives MAUP messages before an ASP Active is received, the SG SHOULD 2223 discard these messages. 2225 There is one mode of Application Server traffic handling in the SG 2226 M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the 2227 mode used in a particular Application Server. If the SG determines that 2228 the mode indicates in an ASPAC is incompatible with the traffic handling 2229 mode currently used in the AS, the SG responds with an Error message 2230 indicating Unsupported Traffic Handling Mode. 2232 For Over-ride mode AS, the reception of an ASPAC message at an SG causes 2233 the redirection of all traffic for the AS to the ASP that sent the ASPAC. 2234 The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. 2235 Any previously active ASP in the AS is now considered Inactive and will 2236 no longer receive traffic from the SG within the AS. The SG sends a 2237 Notify (Alternate ASP-Active) to the previously active ASP in the AS, 2238 after stopping all traffic to that ASP. 2240 4.3.3.5 ASP Inactive 2242 When an ASP wishes to withdraw from receiving traffic within an AS, 2243 the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where 2244 an ASP is configured/registered to process the traffic for more than 2245 one Application Server across an SCTP association, the ASPIA contains 2246 one or more Interface Ids to indicate for which Application Servers 2247 the ASPIA applies. 2249 There is one mode of Application Server traffic handling in the SG 2250 M2UA when withdrawing an ASP from service - Over-ride. The Type 2251 parameter in the ASPIA messge indicates the mode used in a particular 2252 Application Server. If the SG determines that the mode indicates in an 2253 ASPAC is incompatible with the traffic handling mode currently used in 2254 the AS, the SG responds with an Error message indicating Unsupported 2255 Traffic Handling Mode. 2257 In the case of an Over-ride mode AS, where normally another ASP has 2258 already taken over the traffic within the AS with an Over-ride ASPAC, 2259 the ASP which sends the ASPIA is already considered by the SG to be 2260 "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is 2261 sent to the ASP, after ensuring that all traffic is stopped to the ASP. 2263 If no other ASPs are Active in the Application Server, the SG either 2264 discards all incoming messages for the AS or starts buffering the 2265 incoming messages for T(r)seconds, after which messages will be 2266 discarded. T(r) is configurable by the network operator. If the SG 2267 receives an ASPAC from an ASP in the AS before expiry of T(r), the 2268 buffered traffic is directed to the ASP and the timer is cancelled. 2269 If T(r) expires, the AS is moved to the "Down" state. 2271 4.3.3.6 Notify 2273 A Notify message reflecting a change in the AS state is sent to all 2274 ASPs in the AS, except those in the "Down" state, with appropriate 2275 Status Identification. 2277 In the case where a Notify (AS-Pending) message is sent by an SG 2278 that now has no ASPs active to service the traffic, the Notify does 2279 not explicitly force the ASP(s) receiving the message to become 2280 active. The ASPs remain in control of what (and when) action is 2281 taken. 2283 4.3.3.6 Heartbeat 2285 The optional Heartbeat procedures MAY be used when operating over 2286 transport layers that do not have their own heartbeat mechanism for 2287 detecting loss of the transport association (i.e., other than the 2288 SCTP). 2290 After receiving an ASP Up Ack message from the SG in response to an 2291 ASP Up message, the ASP MAY optionally send Beat messages periodically, 2292 subject to a provisionable timer T(beat). The SG M2UA, upon receiving 2293 a BEAT message from the ASP, responds with a BEAT ACK message. If no 2294 BEAT message (or any other M2UA message) is received from the ASP 2295 within the timer 2*T(beat), the SG will consider the remote M2UA as 2296 "Down". The SG will also send an ASP Down Ack message to the ASP. 2298 At the ASP, if no BEAT ACK message (or any other M2UA message) is 2299 received from the SG within 2*T(beat), the SG is considered 2300 unavailable. Transmission of BEAT messages is stopped and ASP Up 2301 procedures are used to re-establish communication with the SG M2UA 2302 peer. 2304 The BEAT message MAY optionally contain an opaque Heartbeat Data 2305 parameter that MUST be echoed back unchanged in the related Beat 2306 Ack message. The ASP upon examining the contents of the returned 2307 BEAT Ack message MAY choose to consider the remote ASP as 2308 unavailable. The contents/format of the Heartbeat Data parameter is 2309 implementation-dependent and only of local interest to the original 2310 sender. The contents MAY be used, for example, to support a 2311 Heartbeat sequence algorithm (to detect missing Heartbeats), and/or 2312 a timestamp mechanism (to evaluate delays). 2314 Note: Heartbeat related events are not shown in Figure 4 "ASP state 2315 transition diagram". 2317 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 2319 5.1 Establishment of associations between SG and MGC examples 2321 5.1.1 Single ASP in an Application Server (1+0 sparing) 2323 This scenario shows the example M2UA message flows for the establishment 2324 of traffic between an SG and an ASP, where only one ASP is configured 2325 within an AS (no backup). It is assumed that the SCTP association is 2326 already set-up. 2328 SG ASP1 2329 | 2330 |<---------ASP Up----------| 2331 |--------ASP Up Ack------->| 2332 | | 2333 |<-------ASP Active--------| 2334 |------ASP_Active Ack----->| 2335 | | 2337 5.1.2 Two ASPs in Application Server (1+1 sparing) 2339 This scenario shows the example M2UA message flows for the establishment 2340 of traffic between an SG and two ASPs in the same Application Server, 2341 where ASP1 is configured to be �active� and ASP2 a standby in the event 2342 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 2343 act as a hot, warm, or cold standby depending on the extent to which ASP1 2344 and ASP2 share call/transaction state or can communicate call state under 2345 failure/withdrawal events. 2347 SG ASP1 ASP2 2348 | | | 2349 |<--------ASP Up----------| | 2350 |-------ASP Up Ack------->| | 2351 | | | 2352 |<-----------------------------ASP Up----------------| 2353 |----------------------------ASP Up Ack------------->| 2354 | | | 2355 | | | 2356 |<-------ASP Active-------| | 2357 |-----ASP-Active Ack----->| | 2358 | | | 2360 5.2 ASP Traffic Fail-over Examples 2362 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2364 Following on from the example in Section 5.1.2, and ASP withdraws from 2365 service: 2367 SG ASP1 ASP2 2368 | | | 2369 |<-----ASP Inactive-------| | 2370 |----ASP Inactive Ack---->| | 2371 |--------------------NTFY(AS-Down) (Optional)------->| 2372 | | | 2373 |<------------------------------ ASP Active----------| 2374 |-----------------------------ASP-Active Ack)------->| 2375 | | 2377 In this case, the SG notifies ASP2 that the AS has moved to the 2378 Down state. The SG could have also (optionally) sent a Notify 2379 message when the AS moved to the Pending state. 2381 Note: If the SG detects loss of the M2UA peer (M2UA heartbeat loss or 2382 detection of SCTP failure), the initial SG-ASP1 ASP Inactive message 2383 exchange would not occur. 2385 5.2.2 (1+1 Sparing, Back-up Over-ride) 2387 Following on from the example in Section 5.1.2, and ASP2 wishes to over- 2388 ride ASP1 and take over the traffic: 2390 SG ASP1 ASP2 2391 | | | 2392 |<------------------------------ ASP Active----------| 2393 |-----------------------------ASP-Active Ack-------->| 2394 |----NTFY( Alt ASP-Act)-->| 2395 | (optional) | | 2397 In this case, the SG notifies ASP1 that an alternative ASP has 2398 overridden it. 2400 5.3 SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 2402 When the M2UA layer on the ASP has a MAUP message to send to the SG, it 2403 will do the following: 2405 - Determine the correct SG 2407 - Find the SCTP association to the chosen SG 2409 - Determine the correct stream in the SCTP association based on 2410 the SS7 link 2412 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2413 Common Header 2415 - Send the MAUP message to the remote M2UA peer in the SG, over the 2416 SCTP association 2418 When the M2UA layer on the SG has a MAUP message to send to the ASP, it 2419 will do the following: 2421 - Determine the AS for the Interface Identifier 2423 - Determine the Active ASP (SCTP association) within the AS 2425 - Determine the correct stream in the SCTP association based on 2426 the SS7 link 2428 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2429 Common Header 2431 - Send the MAUP message to the remote M2UA peer in the ASP, over the 2432 SCTP association 2434 5.3.1 SS7 Link Alignment 2436 The MGC can request that a SS7 link be brought into alignment using the 2437 normal or emergency procedure. An example of the message flow to bring 2438 a SS7 link in-service using the normal alignment procedure is shown 2439 below. 2441 SG ASP 2442 | | 2443 |<---------Establish Req--------------| 2444 | | 2445 |----------Establish Cfm------------->| 2446 | | 2448 An example of the message flow to bring a SS7 link in-service using the 2449 emergency alignment procedure. 2451 SG ASP 2452 | | 2453 |<----State Req (STATUS_EMER_SET)-----| 2454 | | 2455 |-----State Cfm (STATUS_EMER_SET)---->| 2456 | | 2457 |<---------Establish Req--------------| 2458 | | 2459 |----------Establish Cfm------------->| 2460 | | 2462 5.3.2 SS7 Link Release 2464 The MGC can request that a SS7 link be taken out-of-service. It uses 2465 the Release Request message as shown below. 2467 SG ASP 2468 | | 2469 |<-----Release Req (RELEASE_MGMT)-----| 2470 | | 2471 |------------Release Cfm------------->| 2472 | | 2474 The SG can autonomously indicate that a SS7 link has gone out-of-service 2475 as shown below. 2477 SG ASP 2478 | | 2479 |------Release Ind (RELEASE_PHYS)---->| 2480 | | 2482 5.3.3 Set and Clear Local Processor Outage 2484 The MGC can set a Local Processor Outage condition. It uses the 2485 State Request message as shown below. 2487 SG ASP 2488 | | 2489 |<-----State Req (STATUS_LPO_SET)-----| 2490 | | 2491 |------State Cfm (STATUS_LPO_SET)---->| 2492 | | 2494 The MGC can clear a Local Processor Outage condition. It uses the 2495 State Request message as shown below. 2497 SG ASP 2498 | | 2499 |<----State Req (STATUS_LPO_CLEAR)----| 2500 | | 2501 |-----State Cfm (STATUS_LPO_CLEAR)--->| 2502 | | 2504 5.3.4 Notification of Processor Outage (local or remote) 2506 The SG can indicate a Local or Remote Processor Outage condition. It 2507 uses the State Indication message as shown below. 2509 SG ASP 2510 | | 2511 |-----State Ind (EVENT_ENTER_LPO)---->| 2512 | | 2513 |-----State Ind (EVENT_EXIT_LPO)----->| 2514 | | 2516 SG ASP 2517 | | 2518 |-----State Ind (EVENT_ENTER_RPO)---->| 2519 | | 2520 |-----State Ind (EVENT_EXIT_RPO)----->| 2521 | | 2523 5.3.5 SS7 Link Changeover 2525 An example of the message flow for a changeover is shown below. In this 2526 example, there were three messages in the retransmission queue that 2527 needed to be retrieved. 2529 SG ASP 2530 | | 2531 |<---Retrieval Req (MTP2_RTRV_BSN)----| 2532 | | 2533 |------Retrieval Cfm (with BSN)------>| 2534 | | 2535 |<--Retrieval Req (MTP2_RTRV_MSGS)----| 2536 | with FSN | 2537 | | 2538 |-----------Retrieval Cfm------------>| 2539 | | 2540 |-----------Retrieval Ind------------>| 2541 |-----------Retrieval Ind------------>| 2542 |-------Retrieval Complete Ind------->| 2543 | | 2545 Note: The number of Retrieval Indication is dependent on the number of 2546 messages in the retransmit queue that have been requested. Only one 2547 Retrieval Complete Indication SHOULD be sent. 2549 6.0 Security 2551 M2UA is designed to carry signaling messages for telephony services. As such, 2552 M2UA MUST involve the security needs of several parties: the end users 2553 of the services; the network providers and the applications involved. 2554 Additional requirements MAY come from local regulation. While having some 2555 overlapping security needs, any security solution SHOULD fulfill all of the 2556 different parties' needs. 2558 6.1 Threats 2560 There is no quick fix, one-size-fits-all solution for security. As a 2561 transport protocol, M2UA has the following security objectives: 2563 * Availability of reliable and timely user data transport. 2564 * Integrity of user data transport. 2565 * Confidentiality of user data. 2567 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 2568 security features, such as: 2570 * Blind Denial of Service Attacks 2571 * Flooding 2572 * Masquerade 2573 * Improper Monopolization of Services 2575 When M2UA is running in professionally managed corporate or service 2576 provider network, it is reasonable to expect that this network includes 2577 an appropriate security policy framework. The "Site Security Handbook" [8] 2578 SHOULD be consulted for guidance. 2580 When the network in which M2UA runs in involves more than one party, it 2581 MAY NOT be reasonable to expect that all parties have implemented security 2582 in a sufficient manner. In such a case, it is recommended that IPSEC is 2583 used to ensure confidentiality of user payload. Consult [9] for more 2584 information on configuring IPSEC services. 2586 6.2 Protecting Confidentiality 2588 Particularly for mobile users, the requirement for confidentiality MAY 2589 include the masking of IP addresses and ports. In this case application 2590 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 2591 Regardless of which level performs the encryption, the IPSEC ISAKMP 2592 service SHOULD be used for key management. 2594 7.0 IANA Considerations 2596 A request will be made to IANA to assign an M2UA value for the Payload 2597 Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload 2598 Protocol Identifier will be registered: 2600 M2UA 0x10 2602 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 2603 to indicate which protocol the SCTP is carrying. This Payload Protocol 2604 Identifier is not directly used by SCTP but MAY be used by certain network 2605 entities to identify the type of information being carried in a Data chunk. 2607 The User Adaptation peer MAY use the Payload Protocol Identifier as a way 2608 of determining additional information about the data being presented to it 2609 by SCTP. 2611 8.0 Acknowledgements 2613 The authors would like to thank John Loughney, Neil Olson, Michael 2614 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 2615 Prantner, Barry Nagelberg, Naoto Makinae for their valuable comments 2616 and suggestions. 2618 9.0 References 2620 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 2621 System No. 7 (SS7)' 2623 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 2624 Message Transfer Part (MTP)' 2626 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 2628 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 2629 of Signaling System Number 7', Volume 1, December 1995 2631 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 2633 [6] Architectural Framework for Signaling Transport, RFC 2719 , 2634 October 1999 2636 [7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 2637 functions and messages using the services of ITU-T 2638 Recommendation Q.2140' 2640 [8] Site Security Handbook, RFC 2196, September 1997 2642 [9] Security Architecture for the Internet Protocol, RFC 2401 2643 10.0 Author's Addresses 2645 Ken Morneault Tel: +1-703-484-3323 2646 Cisco Systems Inc. EMail: kmorneau@cisco.com 2647 13615 Dulles Technology Drive 2648 Herndon, VA. 20171 2649 USA 2651 Ram Dantu, Ph.D. Tel +1-469-255-0716 2652 Cisco Systems EMail rdantu@cisco.com 2653 17919 Waterview 2654 Dallas, TX 75252 2655 USA 2657 Malleswar Kalla Tel: +1-973-829-5212 2658 Telcordia Technologies EMail: kalla@research.telcordia.com 2659 MCC 1J211R 2660 445 South Street 2661 Morristown, NJ 07960 2662 USA 2664 Greg Sidebottom Tel: +1-613-763-7305 2665 Nortel Networks EMail: gregside@nortelnetworks.com 2666 3685 Richmond Rd, 2667 Nepean, Ontario 2668 Canada K2H5B7 2670 Tom George Tel: +1-972-519-3168 2671 Alcatel USA EMail: tom.george@usa.alcatel.com 2672 1000 Coit Road 2673 Plano, TX 74075 2674 USA 2676 This Internet Draft expires April 2001.