idnits 2.17.1 draft-ietf-sigtran-m2ua-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 19) being 417 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 23: '... that other groups MAY also distribute...' RFC 2119 keyword, line 27: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 92: '...mechanism SHOULD meet the following cr...' RFC 2119 keyword, line 147: '...cess. Fail-back MAY apply upon the re...' RFC 2119 keyword, line 229: '...Note: STPs MAY be present in the SS7 p...' (88 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2427 has weird spacing: '...essages until...' == Line 2469 has weird spacing: '...essages until...' == Line 2519 has weird spacing: '...PIA Ack messa...' == Line 2540 has weird spacing: '...essages until...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: There are scenarios without redundancy requirements and scenarios in which redundancy is supported below the transport layer. In these cases, the SCTP functions above MAY NOT be a requirement and TCP can be used as the underlying common transport protocol. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SCTP Stream '0' SHOULD not be used for MTP2 User Adaptation (MAUP) messages (see Section 3) since stream '0' SHOULD onlt be used for ASP Management (ASPM) messages (see Section 4.3.3). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the network in which M2UA runs in involves more than one party, it MAY NOT be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [11] for more information on configuring IPSEC services. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2001) is 8344 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 707 -- Looks like a reference, but probably isn't: 'M3UA' on line 749 -- Looks like a reference, but probably isn't: 'IUA' on line 754 -- Looks like a reference, but probably isn't: 'M2UA' on line 755 -- Looks like a reference, but probably isn't: 'SUA' on line 757 -- Looks like a reference, but probably isn't: 'RFC2434' on line 3017 == Unused Reference: '1' is defined on line 3071, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 3090, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '10') ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-00 Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Ram Dantu 3 Cisco Systems 4 Greg Sidebottom 5 Nortel Networks 6 Tom George 7 Alcatel 8 Brian Bidulock 9 OpenSS7 10 Jacob Heitz 11 Lucent 13 Expires in six months June 2001 15 SS7 MTP2-User Adaptation Layer 16 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC 2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups MAY also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and MAY be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as 'work in progress'. 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To learn the current status of any Internet-Draft, please check the 38 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 39 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Abstract 45 This Internet Draft defines a protocol for backhauling of SS7 MTP2 46 User signaling messages over IP using the Stream Control 47 Transmission Protocol (SCTP). This protocol would be used between a 48 Signaling Gateway (SG) and Media Gateway Controller (MGC). It is 49 assumed that the SG receives SS7 signaling over a standard SS7 50 interface using the SS7 Message Transfer Part (MTP) to provide 51 transport. The Signaling Gateway would act as a Signaling Link 52 Terminal. 54 TABLE OF CONTENTS 56 1. Introduction..............................................2 57 1.1 Scope..................................................2 58 1.2 Terminology............................................3 59 1.3 Signaling Transport Architecture.......................3 60 1.4 Services Provide by the M2UA Adaptation Layer..........6 61 1.5 Function Provided by the M2UA Layer....................8 62 1.6 Definition of the M2UA Boundaries......................9 63 2. Conventions...............................................9 64 3. Protocol Elements.........................................9 65 3.1 Common Message Header.................................10 66 3.2 M2UA Message Header...................................11 67 3.3 M2UA Messages.........................................11 68 4. Procedures...............................................20 69 4.1 Procedures to Support Service in Section 1.4.1........20 70 4.2 Procedures to Support Service in Section 1.4.2........21 71 4.3 Procedures to Support Service in Section 1.4.3........21 72 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 73 5.1 Establishment of associations between SG and MGC......26 74 examples 75 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 76 5.3 Layer Management Communication Examples...............29 77 6. Timers...................................................30 78 7. Security.................................................30 79 8. IANA Considerations......................................31 80 8.1 SCTP Payload Protocol Identifier.......................31 81 8.2 IUA Protocol Extensions................................31 82 9. Acknowledgements.........................................31 83 10. References...............................................32 84 11. Author's Addresses.......................................33 85 1. Introduction 87 1.1 Scope 89 There is a need for Switched Circuit Network SCN signaling protocol 90 delivery from an Signaling Gateway (SG) to a Media Gateway 91 Controller (MGC) or IP Signaling Point (IPSP). The delivery 92 mechanism SHOULD meet the following criteria: 94 * Support for MTP Level 2 / MTP Level 3 interface boundary 95 * Support for communication between Layer Management modules on SG 96 and MGC 97 * Support for management of SCTP active associations between the SG and 98 MGC 100 The SG will terminate up to MTP Level 2 and the MGC will terminate 101 MTP Level 3 and above. In other words, the SG will transport MTP 102 Level 3 messages over an IP network to a MGC or IPSP. 104 1.2 Terminology 106 MTP2-User - A protocol that uses the services of MTP Level 2 107 (i.e. MTP3). 109 Interface - For the purposes of this document, an interface is a SS7 110 signaling link. 112 Backhaul - Refers to the transport of signaling from the point of 113 interface for the associated data stream (i.e., SG function in the MGU) 114 back to the point of call processing (i.e., the MGCU), if this is not 115 local [4]. 117 Association - An association refers to a SCTP association. The 118 association will provide the transport for the delivery of protocol 119 data units for one or more interfaces. 121 Stream - A stream refers to an SCTP stream; a uni-directional logical 122 channel established from one SCTP endpoint to another associated SCTP 123 endpoint, within which all user messages are delivered in-sequence 124 except for those submitted to the un-ordered delivery service. 126 Interface Identifier - The Interface Identifier identifies the physical 127 interface at the SG for which the signaling messages are sent/received. 128 The format of the Interface Identifier parameter can be text or integer, 129 the values of which are assigned according to network operator policy. 130 The values used are of local significance only, coordinated between the 131 SG and ASP. 133 Application Server (AS) - A logical entity serving a specific application 134 instance. An example of an Application Server is a MGC handling the 135 MTP Level 3 and call processing for SS7 links terminated by the 136 Signaling Gateways. Practically speaking, an AS is modeled at the SG 137 as an ordered list of one or more related Application Server Processes 138 (e.g., primary, secondary, tertiary, ...). 140 Application Server Process (ASP) - A process instance of an Application 141 Server. Examples of Application Server Processes are primary or backup 142 MGC instances. 144 Fail-over - The capability to re-route signaling traffic as required 145 to an alternate Application Server Process within an Application Server 146 in the event of failure or unavailability of a currently used Application 147 Server Process. Fail-back MAY apply upon the return to service of a 148 previously unavailable Application Server Process. 150 Signaling Link Terminal (SLT) - Refers to the means of performing all 151 of the functions defined at MTP level 2 regardless of their 152 implementation [2]. 154 Layer Management - Layer Management is a nodal function in an SG or 155 ASP that handles the inputs and outputs between the M2UA layer and a 156 local management entity. 158 MTP - The Message Transfer Part of the SS7 protocol. 160 MTP2 - MTP Level 2, the signalling datalink layer of SS7 162 MTP3 - MTP Level 3, the signalling network layer of SS7 164 Network Byte Order: Most significant byte first, a.k.a Big Endian. 166 Host - The computing platform that the ASP process is running on. 168 1.3 M2UA Overview 170 The framework architecture that has been defined for SCN signaling 171 transport over IP [6] uses two components: a signaling common 172 transport protocol and an adaptation module to support the services 173 expected by a particular SCN signaling protocol from its underlying 174 protocol layer. 176 Within this framework architecture, this document defines a SCN 177 adaptation module that is suitable for the transport of SS7 MTP2 User 178 messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services 179 of the Stream Control Transmission Protocol [5] as the underlying 180 reliable signaling common transport protocol. 182 In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling 183 is transmitted and received from the PSTN over a standard SS7 network 184 interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] 185 to provide reliable transport of the MTP3-User signaling messages to and 186 from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). 187 The SG then provides a inter-working of transport functions 188 with the IP transport, in order to transfer the MTP2-User signaling 189 messages to and from an Application Server Process where the peer MTP2- 190 User protocol layer exists. 192 1.3.1 Example - SG to MGC 194 In a Signaling Gateway, it is expected that the SS7 signaling is 195 received over a standard SS7 network termination, using the SS7 Message 196 Transfer Part (MTP) to provide transport of SS7 signaling messages to 197 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 198 Point (STP). In other words, the SG acts as a Signaling Link Terminal 199 (SLT) [2]. The SG then provides interworking of transport functions 200 with IP Signaling Transport, in order to transport the MTP3 signaling 201 messages to the MGC where the peer MTP3 protocol layer exists, as shown 202 below: 204 ****** SS7 ****** IP ******* 205 *SEP *-----------* SG *-------------* MGC * 206 ****** ****** ******* 208 +----+ +----+ 209 |S7UP| |S7UP| 210 +----+ +----+ 211 |MTP + |MTP | 212 | L3 | (NIF) |L3 | 213 +----+ +----+----+ +----+ 214 |MTP | |MTP |M2UA| |M2UA| 215 | | | +----+ +----+ 216 |L2 | |L2 |SCTP| |SCTP| 217 |L1 | |L1 +----+ +----+ 218 | | | |IP | |IP | 219 +----+ +---------+ +----+ 221 NIF - Nodal Interworking Function 222 SEP - SS7 Signaling Endpoint 223 IP - Internet Protocol 224 SCTP - Stream Control Transmission Protocol 225 (Refer to Reference [5]) 227 Figure 1 M2UA in the SG to MGC Application 229 Note: STPs MAY be present in the SS7 path between the SEP and the SG. 231 It is recommended that the M2UA use the services of the Stream 232 Control Transmission Protocol (SCTP) as the underlying reliable 233 common signaling transport protocol. The use of SCTP provides 234 the following features: 236 - explicit packet-oriented delivery (not stream-oriented) 237 - sequenced delivery of user messages within multiple streams, 238 with an option for order-of-arrival delivery of individual 239 user messages, 240 - optional multiplexing of user messages into SCTP datagrams, 241 - network-level fault tolerance through support of multi-homing 242 at either or both ends of an association, 243 - resistance to flooding and masquerade attacks, and 244 - data segmentation to conform to discovered path MTU size 246 There are scenarios without redundancy requirements and 247 scenarios in which redundancy is supported below the transport 248 layer. In these cases, the SCTP functions above MAY NOT be a 249 requirement and TCP can be used as the underlying common 250 transport protocol. 252 1.3.2 Support for the management of SCTP associations between the SG 253 and ASPs 255 The M2UA layer at the SG maintains the availability state of all 256 configured ASPs, in order to manage the SCTP associations and the 257 traffic between the SG and ASPs. As well, the active/inactive state 258 of remote ASP(s) are also maintained. The Active ASP(s) are the one(s) 259 currently receiving traffic from the SG. 261 The M2UA layer MAY be instructed by local management to establish an 262 SCTP association to a peer M2UA node. This can be achieved using the 263 M-SCTP ESTABLISH primitive to request, indicate and confirm the 264 establishment of an SCTP association with a peer M2UA node. 266 The M2UA layer MAY also need to inform local management of the status of 267 the underlying SCTP associations using the M-SCTP STATUS request and 268 indication primitive. For example, the M2UA MAY inform local management 269 of the reason for the release of an SCTP association, determined either 270 locally within the M2UA layer or by a primitive from the SCTP. 272 Also the M3UA layer may need to inform the local management of the 273 change in status of an ASP or AS. This may be achieved using the M-ASP 274 STATUS request or M-AS STATUS request primitives. 276 1.3.3 Signaling Network Architecture 278 A Signaling Gateway will support the transport of MTP2-User signaling 279 traffic received from the SS7 network to one or more distributed ASPs 280 (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself 281 meet any performance and reliability requirements for such transport. 282 A physical network architecture is required, with data on the 283 availability and transfer performance of the physical nodes involved in 284 any particular exchange of information. However, the M2UA protocol MUST 285 be flexible enough allow its operation and management in a variety of 286 physical configurations that will enable Network Operators to meet 287 their performance and reliability requirements. 289 To meet the stringent SS7 signaling reliability and performance 290 requirements for carrier grade networks, these Network Operators SHOULD 291 ensure that there is no single point of failure provisioned in the end- 292 to-end network architecture between an SS7 node and an IP ASP. 294 Depending of course on the reliability of the SG and ASP functional 295 elements, this can typically be met by the spreading links in a linkset 296 across SGs, the provision of redundant QoS-bounded IP network paths for 297 SCTP Associations between SCTP End Points, and redundant Hosts. The 298 distribution of ASPs within the available Hosts is also important. For 299 a particular Application Server, the related ASPs SHOULD be distributed 300 over at least two Hosts. 302 An example logical network architecture relevant to carrier-grade 303 operation in the IP network domain is shown in Figure 2 below: 305 ******** ************** 306 * *_________________________________________* ******** * Host1 307 * * _________* * ASP1 * * 308 * SG1 * SCTP Associations | * ******** * 309 * *_______________________ | * * 310 ******** | | ************** 311 | | 312 ******** | | 313 * *_______________________________| 314 * * | 315 * SG2 * SCTP Associations | 316 * *____________ | 317 * * | | 318 ******** | | ************** 319 | |_________________* ******** * Host2 320 |____________________________* * ASP2 * * 321 * ******** * 322 * * 323 ************** 324 . 325 . 326 . 328 Figure 2 - Logical Model Example 330 For carrier grade networks, Operators SHOULD ensure that under failure 331 or isolation of a particular ASP, stable calls or transactions are not 332 lost. This implies that ASPs need, in some cases, to share the call/- 333 transaction state or be able to pass the call/transaction state between 334 each other. Also, in the case of ASPs performing call processing, 335 coordination MAY be required with the related Media Gateway to transfer 336 the MGC control for a particular trunk termination. However, this 337 sharing or communication is outside the scope of this document. 339 1.3.4 ASP Fail-over Model and Terminology 341 The M2UA layer supports ASP fail-over functions in order to support a 342 high availability of call and transaction processing capability. All 343 MTP2-User messages incoming to a SG from the SS7 network are assigned 344 to the unique Application Server, based on the Interface Identifier of 345 the message. 347 The M2UA layer supports a n+k redundancy model (active-standby, 348 loadsharing, broadcast) where 1 ASP is the minimum number of redundant 349 ASPs required to handle traffic and k ASPs are available to take over 350 for a failed or unavailable ASP. Note that 1+1 active/standby redundancy 351 is a subset of this model. A simplex 1+0 model is also supported as a 352 subset, with no ASP redundancy. 354 To avoid a single point of failure, it is recommended that a minimum of 355 two ASPs be configured in an AS list, resident in separate hosts and, 356 therefore, available over different SCTP associations. For example, in 357 the network shown in Figure 2, all messages for the Interface Identifiers 358 could be sent to ASP1 in Host1 or ASP2 in Host2. The AS list at SG1 359 might look like the following: 361 Interface Identiers - Application Server #1 362 ASP1/Host1 - State = Active 363 ASP2/Host2 - State = Inactive 365 In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming 366 message for the Interface Identifiers registered. ASP2 in Host2 would 367 normally be brought to the active state upon failure of ASP1/Host1. 368 In this example, both ASPs are Inactive or Active, meaning that the 369 related SCTP association and far-end M2UA peer is ready. 371 The two ASPs MAY share state information via shared memory, or MAY 372 use an ASP to ASP protocol to pass state information. The ASP to ASP 373 protocol is outside the scope of this document. 375 1.3.5 Client/Server Model 377 It is recommended that the SG and ASP be able to support both client 378 and server operation. The peer endpoints using M2UA SHOULD be 379 configured so that one always takes on the role of client and the 380 other the role of server for initiating SCTP associations. The 381 default orientation would be for the SG to take on the role of server 382 while the ASP is the client. In this case, ASPs SHOULD initiate the 383 SCTP association to the SG. 385 The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA 386 is 2904. 388 1.4 Services Provided by the M2UA Adaptation Layer 390 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 391 point in the IP network, so that the M2UA protocol layer is required to 392 provide the equivalent set of services to its users as provided by the 393 MTP Level 2 to MTP Level 3. 395 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 397 M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables 398 a seamless, or as seamless as possible, operation of the MTP2-User peers 399 in the SS7 and IP domains. An example of the primitives that need to be 400 supported can be found in [7]. 402 1.4.2 Support for communication between Layer Management modules 403 on SG and MGC 405 The M2UA layer needs to provide some messages that will facilitate 406 communication between Layer Management modules on the SG and MGC. 408 To facilitate reporting of errors that arise because of backhauling MTP 409 Level 3 scenario, the following primitive is defined: 411 M-ERROR 413 The M-ERROR message is used to indicate an error with a received 414 M2UA message (e.g., an interface identifier value is not known to the 415 SG). 417 1.4.3 Support for management of active associations between SG and MGC 419 As discussed in Section 1.3.2, the M2UA layer on the SG keeps the state 420 of the configured ASPs. A set of primitives between M2UA layer and the 421 Layer Management are defined below to help the Layer Management manage 422 the association(s) between the SG and the MGC. The M2UA layer can be 423 instructed by the Layer Management to establish a SCTP association to 424 a peer M2UA node. This procedure can be achieved using the M-SCTP 425 ESTABLISH primitive. 427 M-SCTP ESTABLISH 429 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 430 the establishment of a SCTP association to a peer M2UA node. 432 M-SCTP RELEASE 434 The M-SCTP RELEASE primitives are used to request, indicate, and 435 confirm the release of a SCTP association to a peer M2UA node. 437 The M2UA layer MAY also need to inform the status of the SCTP 438 association(s) to the Layer Management. This can be achieved using 439 the following primitive. 441 M-SCTP STATUS 443 The M-SCTP STATUS primitive is used to request and indicate the status 444 of underlying SCTP association(s). 446 The Layer Management MAY need to inform the M2UA layer of an AS/ASP 447 status (i.e., failure, active, etc.), so that messages can be exchanged 448 between M2UA layer peers to stop traffic to the local M2UA user. This 449 can be achieved using the following primitive. 451 M-ASP STATUS 453 The ASP status is stored inside M2UA layer on both the SG and MGC 454 sides. The M-ASP STATUS primitive can be used by Layer Management to 455 request the status of the Application Server Process from the M2UA 456 layer. This primitive can also be used to indicate the status of the 457 Application Server Process. 459 M-ASP MODIFY 461 The M-ASP MODIFY primitive can be used by Layer Management to modify 462 the status of the Application Server Process. In other words, the 463 Layer Management on the ASP side uses this primitive to initiate 464 the ASPM procedures. 466 M-AS STATUS 468 The M-AS STATUS primitive can be used by Layer Management to request 469 the status of the Application Server. This primitive can also be 470 used to indicate the status of the Application Server. 472 1.5 Functions Provided by the M2UA Layer 474 1.5.1 Mapping 476 The M2UA layer MUST maintain a map of a Interface ID to a physical 477 interface on the Signaling Gateway. A physical interface would be a 478 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 479 MUST also maintain a map of Interface Identifier to SCTP association 480 and to the related stream within the association. 482 The SG maps an Interface Identifier to an SCTP association/stream 483 only when an ASP sends an ASP Active message for a particular Interface 484 Identifier. It MUST be noted, however, that this mapping is dynamic 485 and could change at any time due to a change of ASP state. This mapping 486 could even temporarily be invalid, for example during failover of one 487 ASP to another. Therefore, the SG MUST maintain the states of AS/ASP 488 and reference them during the routing of an messages to an AS/ASP. 490 An example of the logical view of relationship between SS7 link, 491 Interface Identifier, AS and ASP in the SG is shown below: 493 /-------------------------------------------------+ 494 / /----------------------------------------------|--+ 495 / / v | 496 / / +----+ act+-----+ +-------+ -+--+|-+- 497 SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v 498 / +----+ | +----+ | +-----+ +-------+ -+--+--+- 499 / +->| AS |--+ Streams 500 / +----+ | +----+ stb+-----+ 501 SS7 link2-------->|IID |-+ | ASP | 502 +----+ +-----+ 504 where IID = Interface Identifier 506 A SG can support more than one AS. An AS can support more than 507 one Interface Identifier. 509 1.5.2 Status of ASPs 511 The M2UA layer on the SG MUST maintain the state of the ASPs it is 512 supporting. The state of an ASP changes because of reception of 513 peer-to-peer messages (ASPM messages as described in Section 3.3.2) 514 or reception of indications from the local SCTP association. ASP 515 state transition procedures are described in Section 4.3.1. 517 At a SG, an Application Server list MAY contain active and inactive 518 ASPs to support ASP fail-over procedures. When, for example, both 519 a primary and a back-up ASP are available, M2UA peer protocol is 520 required to control which ASP is currently active. The ordered 521 list of ASPs within a logical Application Server is kept updated in 522 the SG to reflect the active Application Server Process. 524 Also the M2UA layer MAY need to inform the local management of the 525 change in status of an ASP or AS. This can be achieved using the M-ASP 526 STATUS or M-AS STATUS primitives. 528 1.5.3 SCTP Specifics 530 1.5.3.1 SCTP Stream Management 532 SCTP allows a user specified number of streams to be opened during 533 initialization of the association. It is the responsibility of the 534 M2UA layer to ensure proper management of these streams. Because of 535 the unidirectional nature of streams, a M2UA layer is not aware of the 536 stream information from its peer M2UA layer. Instead, the Interface 537 Identifier is in the M2UA message header. 539 The use of SCTP streams within M2UA is recommended in order to minimize 540 transmission and buffering delay, therefore improving the overall 541 performance and reliability of the signaling elements. A separate 542 SCTP stream can be used for each SS7 link. Or, an implementation may 543 choose to split the SS7 link across several streams based on SLS. 544 This method may be of particular interest for high speed links (MTP3b) 545 since high speed links have a 24-bit sequence number and the stream 546 sequence number is 16-bits. 548 SCTP Stream '0' SHOULD not be used for MTP2 User Adaptation (MAUP) 549 messages (see Section 3) since stream '0' SHOULD onlt be used for ASP 550 Management (ASPM) messages (see Section 4.3.3). 552 1.5.4 Seamless SS7 Network Management Interworking 554 The M2UA layer on the SG SHOULD pass an indication of unavailability of 555 the M2UA-User (MTP3) to the local Layer Management, if the currently 556 active ASP moves from the ACTIVE state. If the AS moves to the DOWN 557 state while SS7 links are in-service, the SG SHOULD follow the MTP 2 558 processor outage procedures [2]. 560 1.5.5 Flow Control / Congestion 562 It is possible for the M2UA layer to be informed of IP network 563 congestion onset and abatement by means of an implementation-dependent 564 function (i.e. an indication from the SCTP). The handling of 565 this congestion indication by M2UA is implementation dependent. 567 1.5.6 Audit of Link State 569 After a failover of one ASP to another ASP, it may be necessary for the 570 M2UA on the ASP to audit the current SS7 link state to ensure consistency. 571 The M2UA on the SG would respond to the audit request with information 572 regarding the current state of the link (i.e. in-service, out-of-service, 573 congestion state, LPO/RPO state). 575 1.6 Definition of the M2UA Boundaries 577 1.6.1 Definition of the M2UA / MTP Level 3 boundary 579 DATA 580 ESTABLISH 581 RELEASE 582 STATE 583 DATA RETRIEVAL 584 DATA RETRIEVAL COMPLETE 586 1.6.2 Definition of the M2UA / MTP Level 2 boundary 588 DATA 589 ESTABLISH 590 RELEASE 591 STATE 592 DATA RETRIEVAL 593 DATA RETRIEVAL COMPLETE 595 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 597 The upper layer and layer management primitives provided by SCTP are 598 provided in Reference [5] Section 9. 600 1.6.4 Definition of Layer Management / M2UA Boundary 602 M-SCTP ESTABLISH request 603 Direction: LM -> M2UA 604 Purpose: LM requests ASP to establish an SCTP association with an SG. 606 M-STCP ESTABLISH confirm 607 Direction: M2UA -> LM 608 Purpose: ASP confirms to LM that it has established an SCTP 609 association with an SG. 611 M-SCTP ESTABLISH indication 612 Direction: M2UA -> LM 613 Purpose: SG informs LM that an ASP has established an SCTP 614 association. 616 M-SCTP RELEASE request 617 Direction: LM -> M2UA 618 Purpose: LM requests ASP to release an SCTP association with SG. 620 M-SCTP RELEASE confirm 621 Direction: M2UA -> LM 622 Purpose: ASP confirms to LM that it has released SCTP association 623 with SG. 625 M-SCTP RELEASE indication 626 Direction: M2UA -> LM 627 Purpose: SG or IPSP informs LM that ASP has released an SCTP 628 association. 630 M-SCTP STATUS request 631 Direction: LM -> M2UA 632 Purpose: LM requests M2UA to report status of SCTP association. 634 M-SCTP STATUS indication 635 Direction: M2UA -> LM 636 Purpose: M2UA reports status of SCTP association. 638 M-ASP STATUS request 639 Direction: LM -> M2UA 640 Purpose: LM requests SG to report status of remote ASP. 642 M-ASP STATUS indication 643 Direction: M2UA -> LM 644 Purpose: SG reports status of remote ASP. 646 M-AS-STATUS request 647 Direction: LM -> M2UA 648 Purpose: LM requests SG to report status of AS. 650 M-AS-STATUS indication 651 Direction: M2UA -> LM 652 Purpose: SG reports status of AS. 654 M-NOTIFY indication 655 Direction: M2UA -> LM 656 Purpose: ASP reports that it has received a NOTIFY message 657 from its peer. 659 M-ERROR indication 660 Direction: M2UA -> LM 661 Purpose: ASP or SG reports that it has received an ERROR 662 message from its peer. 664 M-ASP-UP request 665 Direction: LM -> M2UA 666 Purpose: LM requests ASP to start its operation and send an ASP UP 667 message to the SG. 669 M-ASP-UP confirm 670 Direction: M2UA -> LM 671 Purpose: ASP reports that it has received an ASP UP Acknowledgement 672 message from the SG. 674 M-ASP-DOWN request 675 Direction: LM -> M2UA 676 Purpose: LM requests ASP to stop its operation and send an ASP DOWN 677 message to the SG. 679 M-ASP-DOWN confirm 680 Direction: M2UA -> LM 681 Purpose: ASP reports that is has received an ASP DOWN Acknowledgement 682 message from the SG. 684 M-ASP-ACTIVE request 685 Direction: LM -> M2UA 686 Purpose: LM requests ASP to send an ASP ACTIVE message to the SG. 688 M-ASP-ACTIVE confirm 689 Direction: M2UA -> LM 690 Purpose: ASP reports that is has received an ASP ACTIVE Acknowledgement 691 message from the SG. 693 M-ASP-INACTIVE request 694 Direction: LM -> M2UA 695 Purpose: LM requests ASP to send an ASP INACTIVE message to the SG. 697 M-ASP-INACTIVE confirm 698 Direction: M2UA -> LM 699 Purpose: ASP reports that is has received an ASP INACTIVE Acknowledgement 700 message from the SG. 702 2.0 Conventions 704 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 705 NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear 706 in this document, are to be interpreted as described in [RFC2119]. 708 3.0 Protocol Elements 710 This section describes the format of various messages used in this 711 protocol. 713 3.1 Common Message Header 715 The protocol messages for MTP2-User Adaptation require a message 716 structure which contains a version, message class, message type, message 717 length, and message contents. This message header is common among all 718 signaling protocol adaptation layers: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Version | Spare | Message Class | Message Type | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Message Length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Figure 3 Common Message Header 730 All fields in an M2UA message MUST be transmitted in the network byte 731 order, unless otherwise stated. 733 3.1.1 Version 735 The version field (vers) contains the version of the M2UA adapation 736 layer. The supported versions are: 738 Value Version 739 ----- ------- 740 1 Release 1.0 742 3.1.2 Message Type 744 The following List contains the valid Message Classes: 746 Message Class: 8 bits (unsigned integer) 748 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA] 749 1 Transfer Messages [M3UA] 750 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA] 751 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 752 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 753 5 Q.921/Q.931 Boundary Primitives Tranport (QPTM) 754 Messages [IUA] 755 6 MTP2 User Adaptatation (MAUP) Messages [M2UA] 756 7 Connectionless Messages [SUA] 757 8 Connection-Oriented Messages [SUA] 758 9 to 127 Reserved by the IETF 759 128 to 255 Reserved for IETF-Defined Message Class extensions 761 The following list contains the message types for the defined messages. 763 MTP2 User Adaptatation (MAUP) Messages 765 0 Reserved 766 1 Data 767 2 Establish Request 768 3 Establish Confirm 769 4 Release Request 770 5 Release Confirm 771 6 Release Indication 772 7 State Request 773 8 State Confirm 774 9 State Indication 775 10 Data Retrieval Request 776 11 Data Retrieval Confirm 777 12 Data Retrieval Indication 778 13 Data Retrieval Complete Indication 779 14 Congestion Indication 780 15 to 127 Reserved by the IETF 781 128 to 255 Reserved for IETF-Defined MAUP extensions 782 Application Server Process State Maintenance (ASPSM) messages 784 0 Reserved 785 1 ASP Up (UP) 786 2 ASP Down (DOWN) 787 3 Reserved 788 4 ASP Up Ack (UP ACK) 789 5 ASP Down Ack (DOWN ACK) 790 6 Reserved 791 7 to 127 Reserved by the IETF 792 128 to 255 Reserved for IETF-Defined ASPSM extensions 794 Application Server Process Traffic Maintenance (ASPTM) messages 796 0 Reserved 797 1 ASP Active (ACTIVE) 798 2 ASP Inactive (INACTIVE) 799 3 ASP Active Ack (ACTIVE ACK) 800 4 ASP Inactive Ack (INACTIVE ACK) 801 5 to 127 Reserved by the IETF 802 128 to 255 Reserved for IETF-Defined ASPTM extensions 804 Management (MGMT) Messages 806 0 Error (ERR) 807 1 Notify (NTFY) 808 2 to 127 Reserved by the IETF 809 128 to 255 Reserved for IETF-Defined MGMT extensions 811 3.1.3 Reserved 813 The Reserved field is 8-bits. It SHOULD be set to all '0's and 814 ignored by the receiver. 816 3.1.4 Message Length 818 The Message Length defines the length of the message in octets, 819 including the header. The Message Length includes parameter 820 padding bytes, if any. 822 3.1.5 Variable-Length Parameter Format 824 M2UA messages consist of a Common Header followed by zero or more 825 variable-length parameters, as defined by the message type. The 826 variable-length parameters contained in a message are defined in a 827 Tag-Length-Value format as shown below. 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Parameter Tag | Parameter Length | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 \ \ 835 / Parameter Value / 836 \ \ 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Mandatory paramters MUST be placed before optional parameters in a 840 message. 842 Parameter Tag: 16 bits (unsigned integer) 844 The Type field is a 16 bit identifier of the type of parameter. It 845 takes a value of 0 to 65534. The common parameter Tags (used by all 846 User Adaptation layers) defined are as follows: 848 Parameter Value Parameter Name 849 --------------- -------------- 850 0 (0x0) Reserved 851 1 (0x1) Interface Identifier (Integer) 852 2 (0x2) Interface Identifier (Integer Range) 853 3 (0x3) Interface Identifier (Text) 854 4 (0x4) Info String 855 5 (0x5) Unused 856 6 (0x6) Unused 857 7 (0x7) Diagnostic Information 858 8 (0x8) Heartbeat Data 859 9 (0x9) Unused 860 10 (0xa) Reason 861 11 (0xb) Traffic Mode Type 862 12 (0xc) Error Code 863 13 (0xd) Status Type/Information 864 14 (0xe) ASP Identifier 866 The M2UA specific parameter Tags defined are as follows: 868 Parameter Value Parameter Name 869 --------------- -------------- 870 768 (0x0300) Protocol Data 1 871 769 (0x0301) Protocol Data 2 (TTC) 872 770 (0x0302) State Request 873 771 (0x0303) State Result 874 772 (0x0304) State Event 875 773 (0x0305) Congestion Status 876 774 (0x0306) Discard Status 877 775 (0x0307) Action 878 776 (0x0308) Sequence Number 879 777 (0x0309) Retrieval Result 881 Parameter Length: 16 bits (unsigned integer) 883 The Parameter Length field contains the size of the parameter in bytes, 884 including the Parameter Tag, Parameter Length, and Parameter Value 885 fields. The Parameter Length does not include any padding bytes. 887 Parameter Value: variable-length. 889 The Parameter Value field contains the actual information to be 890 transferred in the parameter. 892 The total length of a parameter (including Tag, Parameter Length and Value 893 fields) MUST be a multiple of 4 bytes. If the length of the parameter is 894 not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., 895 after the Parameter Value field) with all zero bytes. The length of the 896 padding is NOT included in the parameter length field. A sender SHOULD 897 NOT pad with more than 3 bytes. The receiver MUST ignore the padding 898 bytes. 900 3.2 M2UA Message Header 902 In addition to the common message header, there will be a M2UA specific 903 message header. The M2UA specific message header will immediately 904 follow the common message header, but will only be used with MAUP 905 messages. 907 This message header will contain the Interface Identifier. The 908 Interface Identifier identifies the physical interface at the SG for 909 which the signaling messages are sent/received. The format of the 910 Interface Identifier parameter can be text or integer, the values of 911 which are assigned according to network operator policy. The values 912 used are of local significance only, coordinated between the SG and 913 ASP. 915 The integer formatted Interface Identifier MUST be supported. The 916 text formatted Interface Identifier MAY optionally be supported. 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Tag (0x1) | Length=8 | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Interface Identifier (integer) | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Figure 4 M2UA Message Header (Integer-based Interface Identifier) 928 The Tag value for Integer-based Interface Identifier is 0x1. The length 929 is always set to a value of 8. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Tag (0x3) | Length | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Interface Identifier (text) | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 5 M2UA Message Header (Text-based Interface Identifier) 943 The Tag value for the Text-based Interface Identifier is 0x3. The 944 length is variable. 946 3.3 M2UA Messages 948 The following section defines the messages and parameter contents. The 949 M2UA messages will use the common message header (Figure 3) and the 950 M2UA message header (Figure 4). 952 3.3.1 MTP2 User Adaptation Messages 954 3.3.1.1 Data 956 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 957 Data message contains the following parameter: 959 Protocol Data (mandatory) 961 The format for the Data Message parameters is as follows: 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Tag (0x300) | Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Protocol Data | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 The Protocol Data field contains the MTP2-User application message in 974 network byte order starting with the Signaling Information Octet (SIO). 976 The format for a Data Message with TTC PDU parameters is as follows: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Tag (0x301) | Length | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Protocol Data | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 The Protocol Data field contains the MTP2-User application message in 989 network byte order starting with the Length Indicator (LI) octet. 990 The Japanese TTC variant uses the spare bits of the LI octet for 991 priority. 993 3.3.1.2 Establish (Request, Confirmation) 995 The Establish Request message is used to establish the link or to 996 indicate that the channel has been established. The MGC controls the 997 state of the SS7 link. When the MGC desires the SS7 link to be 998 in-service, it will send the Establish Request message. Note that the 999 gateway MAY already have the SS7 link established at its layer. If so, 1000 upon receipt of an Establish Request, the gateway takes no action except 1001 to send an Establish Confirm. 1003 When the MGC sends an M2UA Establish Request message, the MGC MAY 1004 start a timer. This timer would be stopped upon receipt of an M2UA 1005 Establish Confirm. If the timer expires, the MGC would re-send the 1006 M2UA Establish Request message and restart the timer. In other words, 1007 the MGC MAY continue to request the establishment of the data link 1008 on periodic basis until the desired state is achieved or take some 1009 other action (notify the Management Layer). 1011 The mode (Normal or Emergency) for bringing the link in service is 1012 defaulted to Normal. The State Request (described in Section 3.3.1.4 1013 below) can be used to change the mode to Emergency. 1015 3.3.1.3 Release (Request, Indication, Confirmation) 1017 This Release Request message is used to release the channel. The 1018 Release Confirm and Indication messages are used to indicate that the 1019 channel has been released. 1021 3.3.1.4 State Request 1023 The State Request message can be sent from a MGC to cause an action 1024 on a particular SS7 link supported by the Signaling Gateway. The 1025 gateway sends a State Confirm to the MGC if the action has been success- 1026 fully completed. The State Confirm reflects that state value received 1027 in the State Request message. 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Tag (0x302) | Length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | State | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 The valid values for State are shown in the following table. 1039 Define Value Description 1040 STATUS_LPO_SET 0x0 Request local processor outage 1041 STATUS_LPO_CLEAR 0x1 Request local processor outage 1042 recovered 1043 STATUS_EMER_SET 0x2 Request emergency alignment 1044 procedure 1045 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1046 emergency) procedure 1047 STATUS_FLUSH_BUFFERS 0x4 Flush receive, transmit and retransmit 1048 queues 1049 STATUS_CONTINUE 0x5 Continue 1050 STATUS_AUDIT 0x6 Audit state of link 1051 STATUS_CONG_CLEAR 0x7 Congestion cleared 1052 STATUS_CONG_ACCEPT 0x8 Congestion accept 1053 STATUS_CONG_DISCARD 0x9 Congestion discard 1055 3.3.1.5 State Confirm 1057 The State Confirm message will be sent by the SG in response to a State 1058 Request from the MGC. The State Confirm reflects that state value 1059 received in the State Request message. There is also a field to indicate 1060 whether or not the the State Request was successfully completed. 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 | Tag (0x302) | Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | State | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Tag (0x303) | Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Result | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 The valid values for State are shown in the following table. The value 1075 of the State field should reflect the value received in the State Request 1076 message. 1078 Define Value Description 1079 STATUS_LPO_SET 0x0 Request local processor outage 1080 STATUS_LPO_CLEAR 0x1 Request local processor outage 1081 recovered 1082 STATUS_EMER_SET 0x2 Request emergency alignment 1083 procedure 1084 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 1085 emergency) procedure 1086 STATUS_FLUSH_BUFFERS 0x4 Flush receive, transmit and retransmit 1087 queues 1088 STATUS_CONTINUE 0x5 Continue 1089 STATUS_AUDIT 0x6 Audit state of link 1091 The valid values for the Result field are shown in the following table. 1093 Define Value Description 1094 STATUS_SUCCESS 0x0 Successfully completed Request 1095 STATUS_FAILURE 0x1 Failed to complete Request 1097 3.3.1.6 State Indication 1099 The MTP2 State Indication message can be sent from a gateway to an 1100 ASP to indicate a condition on a link. 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Tag (0x304) | Length | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Event | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 The valid values for Event are shown in the following table. 1112 Define Value Description 1113 EVENT_RPO_ENTER 0x1 Remote entered processor outage 1114 EVENT_RPO_EXIT 0x2 Remote exited processor outage 1116 3.3.1.7 Congestion Indication 1118 The Congestion Indication message can be sent from a Signaling Gateway 1119 to an ASP to indicate the congestion status and discard status of a link. 1120 When the MSU buffer fill increases above an Onset threshold or decreases 1121 below an Abatement threshold or crosses a Discard threshold in either 1122 direction, the SG SHALL send a congestion indication message. 1124 The SG shall send the message only when there is actually a change 1125 in either the discard level or the congestion level to report, 1126 meaning it is different from the previously sent message. In addition, 1127 the SG SHALL use an implementation dependent algorithm to limit the 1128 frequency of congestion indication messages. 1130 An implementation may optionally send Congestion Indication messages on 1131 a "high priority" stream in order to potentially reduce delay (Refer to 1132 [12] for more details). 1134 The Congestion Indication message contains the following parameters: 1136 Congestion Status (mandatory) 1137 Discard Status (optional) 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Tag (0x305) | Length | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Congestion Status | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Tag (0x306) | Length | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Discard Status | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 The valid values for Congestion Status and Discard Status are shown in 1152 the following table. 1154 Define Value Description 1155 LEVEL_NONE 0x0 No congestion. 1156 LEVEL_1 0x1 Congestion Level 1 1157 LEVEL_2 0x2 Congestion Level 2 1158 LEVEL_3 0x3 Congestion Level 3 1159 LEVEL_4 0x4 Discarding 1161 For networks that do not support multiple levels of congestion, only the 1162 LEVEL_NONE and LEVEL_3 values will be used. For networks that support 1163 multiple levels of congestion, it is possible for all values to be used. 1164 Refer to [2] and [9] for more details. 1166 When the SG runs out of buffer space for MSUs received from the MGC, the 1167 SG shall send a Congestion Indication message with Congestion Status and 1168 Discard Status set to LEVEL_DISCARDING and discard MSUs received from the 1169 MGC. 1171 3.3.1.8 Retrieval Request 1173 The MTP2 Retrieval Request message is used during the MTP Level 3 1174 changeover procedure to request the BSN, to retrieve PDUs from the 1175 transmit and retransmit queues or to flush PDUs from the retransmit 1176 queue. 1178 The Retrieval Request message contains the following parameters: 1180 Action (mandatory) 1181 Sequence Number (optional) 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Tag (0x307) | Length | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Action | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Tag (0x308) | Length | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Sequence Number | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 The valid values for Action are shown in the following table. 1196 Define Value Description 1197 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number 1198 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 1199 queue 1200 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue 1201 ACTION_RTRV_TRANS 0x4 Retrieve the PDUs from the transmit 1202 queue 1204 In the Retrieval Request message, the Sequence Number field SHOULD NOT 1205 be present if the Action field is ACTION_RTRV_BSN, ACTION_DROP_MSGS or 1206 ACTION_RTRV_TRANS. The Sequence Number field contains the Forward 1207 Sequnce Number (FSN) of the far end if the Action is ACTION_RTRV_MSGS. 1209 3.3.1.9 Retrieval Confirm 1211 The MTP2 Retrieval Confirm message is sent by the Signaling Gateway 1212 in response to a Retrieval Request message. 1214 The Retrieval Confirm message contains the following parameters: 1216 Action (mandatory) 1217 Result (mandatory) 1218 Sequence Number (optional) 1219 0 1 2 3 1220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Tag (0x307) | Length | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Action | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Tag (0x309) | Length | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Result | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Tag (0x308) | Length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Sequence Number | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 The valid values for Action are the same as in Retrieval Request. 1237 The values for Result are shown below: in the following table. 1239 Define Value Description 1240 RESULT_SUCCESS 0x0 Action successful 1241 RESULT_FAILURE 0x1 Action failed 1243 When the Signaling Gateway sends a Retrieval Confirm to a Retrieval 1244 Request, it echos the Action field. If the Action was ACTION_RTRV_BSN 1245 and the SG successfully retrieved the BSN, the SG will put the Backward 1246 Sequence Number (BSN) in the Sequence Number field and will indicate a 1247 success in the Result field. If the BSN could not be retrieved, the 1248 Sequence Number field will not be included and the Result field will 1249 indicate failure. 1251 For a Retrieval Confirm with Action of ACTION_RTRV_MSGS and 1252 ACTION_RTRV_TRANS, the value of of Result field will indicate success or 1253 failure. A failure means that the buffers could not be retrieved. The 1254 Sequence Number field is not used with ACTION_RTRV_MSGS. 1256 For a Retrieval Confirm with an Action of ACTION_DROP_MSGS, the Result 1257 value will indicate success or failure. The Sequence Number field is 1258 not used with ACTION_DROP_MSGS. 1260 3.3.1.10 Retrieval Indication 1262 The Retrieval Indication message is sent by the Signaling Gateway with a 1263 PDU from the transmit or retransmit queue. The Retrieval Indication 1264 message does not contain the Action or seq_num fields, just a MTP3 1265 Protocol Data Unit (PDU) from the transmit or retransmit queue. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Tag (0x300) | Length | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | PDU from transmit or retransmit queue | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 For TTC Data messages, the following parameter will be used to indicate 1278 a TTC PDU which starts at LI. 1280 0 1 2 3 1281 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 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Tag (0x301) | Length | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | TTC PDU from transmit or retransmit queue | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 The M2UA implementation MAY consider the use of the bundling feature 1291 of SCTP for Retrieval Indication messages. 1293 3.3.1.11 Retrieval Complete Indication 1295 The MTP2 Retrieval Complete Indication message is exactly the same as 1296 the MTP2 Retrieval Indication message except that it also indicates that 1297 it contains the last PDU from the transmit or retransmit queue. 1299 3.3.2 Application Server Process Maintenance (ASPM) Messages 1301 The ASPM messages will only use the common message header. 1303 3.3.2.1 ASP UP (ASPUP) 1305 The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer 1306 that the Adaptation layer is ready to receive traffic or maintenance 1307 messages. 1309 The ASPUP message contains the following parameters 1311 ASP Identifier (optional) 1312 Info String (optional) 1314 The format for ASPUP Message parameters is as follows: 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Tag (0xe) | Length | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | ASP Identifier* | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | Tag (0x4) | Length | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | INFO String* | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 The optional ASP Identifier parameter would contain a unique value 1331 that is locally significant to the ASPs that support an AS. The SG 1332 would save the ASP Identifier to be used, if necessary, with the 1333 Notify message (see Section 3.3.3.2). 1335 The optional INFO String parameter can carry any meaningful 8-bit ASCII 1336 character string along with the message. Length of the INFO String 1337 parameter is from 0 to 255 characters. No procedures are presently 1338 identified for its use but the INFO String MAY be used for debugging 1339 purposes. 1341 3.3.2.2 ASP Up Ack 1343 The ASP UP Ack message is used to acknowledge an ASP Up message received 1344 from a remote M2UA peer. 1346 The ASPUP Ack message contains the following parameters: 1348 INFO String (optional) 1350 The format for ASPUP Ack Message parameters is as follows: 1352 0 1 2 3 1353 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 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Tag (0x4) | Length | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | INFO String* | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 The format and description of the optional Info String parameter is the 1363 same as for the ASP UP message (See Section 3.3.2.1). 1365 3.3.2.3 ASP Down (ASPDN) 1367 The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer 1368 that the adaptation layer is not ready to receive traffic or 1369 maintenance messages. 1371 The ASPDN message contains the following parameters 1373 Reason 1374 INFO String (optional) 1376 The format for the ASPDN message parameters is as follows: 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Tag (0xa) | Length | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Reason | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Tag (0x4) | Length | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | INFO String* | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 The format and description of the optional Info String parameter is the 1393 same as for the ASP Up message (See Section 3.3.2.1). 1395 The Reason parameter indicates the reason that the remote M2UA 1396 adaptation layer is unavailable. The valid values for Reason are shown 1397 in the following table. 1399 Value Description 1400 0x1 Management 1402 3.3.2.4 ASP Down Ack 1404 The ASP Down Ack message is used to acknowledge an ASP Down message 1405 received from a remote M2UA peer. 1407 The ASP Down Ack message contains the following parameters: 1409 Reason 1410 INFO String (optional) 1412 The format for the ASPDN Ack message parameters is as follows: 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Tag (0xa) | Length | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Reason | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Tag (0x4) | Length | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | INFO String* | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 The format and description of the optional Info String parameter is the 1429 same as for the ASP UP message (See Section 3.3.2.1). 1431 The format of the Reason parameter is the same as for the ASP Down message 1432 (See Section 3.3.2.3). 1434 3.3.2.5 ASP Active (ASPAC) 1436 The ASPAC message is sent by an ASP to indicate to an SG that it is 1437 Active and ready to be used. 1439 The ASPAC message contains the following parameters 1441 Traffic Mode Type (mandatory) 1442 Interface Identifier (optional) 1443 - Combination of integer and integer ranges, OR 1444 - string (text formatted) 1445 INFO String (optional) 1447 The format for the ASPAC message using integer formatted Interface 1448 Identifiers is as follows: 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Tag (0xb) | Length | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Traffic Mode Type | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Tag (0x1=integer) | Length | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Interface Identifiers* | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Tag (0x8=integer range) | Length | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Interface Identifier Start1* | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Interface Identifier Stop1* | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Interface Identifier Start2* | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Interface Identifier Stop2* | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 . . 1474 . . 1475 . . 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Interface Identifier StartN* | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Interface Identifier StopN* | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Additional Interface Identifiers | 1483 | of Tag Type 0x1 or 0x8 | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Tag (0x4) | Length | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | INFO String* | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 The format for the ASPAC message using text formatted (string) 1494 Interface Identifiers is as follows: 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Tag (0xb) | Length | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Traffic Mode Type | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Tag (0x3=string) | Length | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Interface Identifier* | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Additional Interface Identifiers | 1511 | of Tag Type 0x3 | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Tag (0x4) | Length | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | INFO String* | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 The Traffic Mode Type parameter identifies the traffic mode of 1522 operation of the ASP within an AS. The valid values for Type are 1523 shown in the following table: 1525 Value Description 1526 0x1 Over-ride 1527 0x2 Load-share 1528 0x3 Broadcast 1530 Within a particular AS, only one Traffic Mode Type can be used. 1531 The Over-ride value indicates that the ASP is operating in Over-ride 1532 mode, where the ASP takes over all traffic in an Application Server 1533 (i.e., primary/back-up operation), over-riding any currently active 1534 ASPs in the AS. In Load-share mode, the ASP will share in the traffic 1535 distribution with any other currently active ASPs. In Broadcast mode, 1536 all of the Active ASPs receive all message traffic in the Application 1537 Server. 1539 The optional Interface Identifiers parameter contains a list of 1540 Interface Identifier integers (Type 0x1 or Type 0x8) or text strings 1541 (Type 0x3)indexing the Application Server traffic that the sending 1542 ASP is configured/registered to receive. If integer formatted 1543 Interface Identifiers are being used, the ASP can also send ranges of 1544 Interface Identifiers (Type 0x8). Interface Identifier types Integer 1545 (0x1) and Integer Range (0x8) are allowed in the same message. Text 1546 formatted Interface Identifiers (0x3) cannot be used with either 1547 Integer (0x1) or Integer Range (0x8) types. 1549 If no Interface Identifiers are included, the message is for all 1550 provisioned Interface Identifiers within the AS(s) in which the 1551 ASP is provisioned. If only a subset of Interface Identifiers are 1552 included, the ASP is noted as Active for all the Interface Identifiers 1553 provisioned for that AS. 1555 Note: If the optional Interface Identifier parameter is present, the 1556 integer formatted Interface Identifier MUST be supported, while the 1557 text formatted Interface Identifier MAY be supported. 1559 An SG that receives an ASPAC with an incorrect or unsupported Traffic 1560 Mode Type for a particular Interface Identifier will respond with an 1561 Error Message (Cause: Unsupported Traffic Handling Mode). 1563 The format and description of the optional Info String parameter is the 1564 same as for the ASP UP message (See Section 3.3.2.1). 1566 3.3.2.6 ASP Active Ack 1568 The ASPAC Ack message is used to acknowledge an ASP-Active message 1569 received from a remote M2UA peer. 1571 The ASPAC Ack message contains the following parameters: 1573 Traffic Mode Type (mandatory) 1574 Interface Identifier (optional) 1575 - Combination of integer and integer ranges, OR 1576 - string (text formatted) 1577 INFO String (optional) 1579 The format for the ASPAC Ack message with Integer-formatted Interface 1580 Identifiers is as follows: 1582 0 1 2 3 1583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Tag (0xb) | Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Traffic Mode Type | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Tag (0x1=integer) | Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Interface Identifiers* | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Tag (0x8=integer range) | Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Interface Identifier Start1* | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Interface Identifier Stop1* | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Interface Identifier Start2* | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Interface Identifier Stop2* | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 . . 1606 . . 1607 . . 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Interface Identifier StartN* | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Interface Identifier StopN* | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Additional Interface Identifiers | 1615 | of Tag Type 0x1 or 0x8 | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Tag (0x4) | Length | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | INFO String* | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 The format for the ASP Active Ack message using text formatted (string) 1626 Interface Identifiers is as follows: 1628 0 1 2 3 1629 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Tag (0xb) | Length | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Traffic Mode Type | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Tag (0x3=string) | Length | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Interface Identifier* | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Additional Interface Identifiers | 1643 | of Tag Type 0x3 | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Tag (0x4) | Length | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | INFO String* | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 The format and description of the optional Info String parameter is the 1654 same as for the ASP UP message (See Section 3.3.2.1.) 1656 The format of the Type and Interface Identifier parameters is the same 1657 as for the ASP Active message (See Section 3.3.2.5). 1659 3.3.2.7 ASP Inactive (ASPIA) 1661 The ASPIA message is sent by an ASP to indicate to an SG that it is no 1662 longer an active ASP to be used from within a list of ASPs. The SG will 1663 respond with an ASPIA Ack message and either discard incoming messages 1664 or buffer for a timed period and then discard. 1666 The ASPIA message contains the following parameters 1668 Traffic Mode Type (mandatory) 1669 Interface Identifiers (optional) 1670 - Combination of integer and integer ranges, OR 1671 - string (text formatted) 1672 INFO String (optional) 1674 The format for the ASP Inactive message parameters using Integer 1675 formatted Interface Identifiers is as follows: 1677 0 1 2 3 1678 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 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Tag (0xb) | Length | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | Traffic Mode Type | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | Tag (0x1=integer) | Length | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Interface Identifiers* | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Tag (0x8=integer range) | Length | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Interface Identifier Start1* | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Interface Identifier Stop1* | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Interface Identifier Start2* | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Interface Identifier Stop2* | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 . . 1701 . . 1702 . . 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Interface Identifier StartN* | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Interface Identifier StopN* | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Additional Interface Identifiers | 1710 | of Tag Type 0x1 or 0x8 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Tag (0x4) | Length | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | INFO String* | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 The format for the ASP Inactive message using text formatted (string) 1721 Interface Identifiers is as follows: 1723 0 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Tag (0xb) | Length | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Traffic Mode Type | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Tag (0x3=string) | Length | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Interface Identifier* | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | Additional Interface Identifiers | 1738 | of Tag Type 0x3 | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | Tag (0x4) | Length | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | INFO String* | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 The Traffic Mode Type parameter identifies the traffic mode of 1749 operation of the ASP within an AS. The valid values for Traffic Mode 1750 Type are shown in the following table: 1752 Value Description 1753 0x1 Over-ride 1755 The format and description of the optional Interface Identifiers and 1756 Info String parameters is the same as for the ASP Active message (See 1757 Section 3.3.2.3.) 1759 The optional Interface Identifiers parameter contains a list of 1760 Interface Identifier integers indexing the Application Server traffic 1761 that the sending ASP is configured/registered to receive, but does not 1762 want to receive at this time. 1764 3.3.2.8 ASP Inactive Ack 1766 The ASPIA Ack message is used to acknowledge an ASP-Inactive message 1767 received from a remote M2UA peer. 1769 The ASPIA Ack message contains the following parameters: 1771 Traffic Mode Type (mandatory) 1772 Interface Identifiers (optional) 1773 - Combination of integer and integer ranges, OR 1774 - string (text formatted) 1775 INFO String (optional) 1777 The format for the ASPIA Ack message is as follows: 1779 0 1 2 3 1780 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 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Tag (0xb) | Length | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Traffic Mode Type | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Tag (0x1=integer) | Length | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Interface Identifiers* | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Tag (0x8=integer range) | Length | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Interface Identifier Start1* | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Interface Identifier Stop1* | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Interface Identifier Start2* | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Interface Identifier Stop2* | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 . . 1803 . . 1804 . . 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Interface Identifier StartN* | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Interface Identifier StopN* | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Additional Interface Identifiers | 1812 | of Tag Type 0x1 or 0x8 | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Tag (0x4) | Length | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | INFO String* | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 The format for the ASP Inactive Ack message using text formatted 1823 (string) Interface Identifiers is as follows: 1825 0 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Tag (0xb) | Length | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Traffic Mode Type | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | Tag (0x3=string) | Length | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Interface Identifier* | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Additional Interface Identifiers | 1840 | of Tag Type 0x3 | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Tag (0x4) | Length | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | INFO String* | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 The format of the Traffic Mode Type and Interface Identifier 1851 parameters is the same as for the ASP Inactive message 1852 (See Section 3.3.2.7). 1854 The format and description of the optional Info String parameter is 1855 the same as for the ASP Up message (See Section 3.3.2.1). 1857 3.3.3 Layer Management (MGMT) Messages 1859 3.3.3.1 Error (ERR) 1861 The Error message is used to notify a peer of an error event 1862 associated with an incoming message. For example, the message type 1863 might be unexpected given the current state, or a parameter value might 1864 be invalid. 1866 The ERR message contains the following parameters: 1868 Error Code (mandatory) 1869 Diagnostic Information (optional) 1871 The format for the ERR message is as follows: 1873 0 1 2 3 1874 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 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | Tag (0xc) | Length | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Error Code | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Tag (0x7) | Length | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Diagnostic Information* | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 The Error Code parameter indicates the reason for the Error Message. 1888 The Error parameter value can be one of the following values: 1890 Invalid Version 0x1 1891 Invalid Interface Identifier 0x2 1892 Unsupported Message Class 0x3 1893 Unsupported Message Type 0x4 1894 Unsupported Traffic Handling Mode 0x5 1895 Unexpected Message 0x6 1896 Protocol Error 0x7 1897 Unsupported Interface Identifier Type 0x8 1898 Invalid Stream Identifier 0x9 1900 The "Invalid Version" error would be sent if a message was 1901 received with an invalid or unsupported version. The Error message 1902 would contain the supported version in the Common header. The 1903 Error message could optionally provide the supported version in 1904 the Diagnostic Information area. 1906 The "Invalid Interface Identifier" error would be sent by a SG if 1907 an ASP sends a message with an invalid (unconfigured) Interface 1908 Identifier value. 1910 The "Unsupported Traffic Handling Mode" error would be sent by a SG 1911 if an ASP sends an ASP Active with an unsupported Traffic Handling 1912 Mode. An example would be a case in which the SG did not support 1913 load-sharing. 1915 The "Unexpected Message" error would be sent by an ASP if it received 1916 a MAUP message from an SG while it was in the Inactive state. 1918 The "Protocol Error" error would be sent for any protocol anomaly 1919 (i.e. a bogus message). 1921 The "Invalid Stream Identifier" error would be sent if a message 1922 was received on an unexpected SCTP stream (i.e. a MGMT message 1923 was received on a stream other than "0"). 1925 The "Unsupported Interface Identifier Type" error would be sent by 1926 a SG if an ASP sends a Text formatted Interface Identifier and the 1927 SG only supports Integer formatted Interface Identifiers. When 1928 the ASP receives this error, it will need to resend its message with 1929 an Integer formatted Interface Identifier. 1931 The "Unsupported Message Class" error would be sent if a message with 1932 an unexpected or unsupported Message Class is received. 1934 The "Unsupported Interface Identifier Type" error would be sent by 1935 a SG if an ASP sends a Text formatted Interface Identifier and the 1936 SG only supports Integer formatted Interface Identifiers. When 1937 the ASP receives this error, it will need to resend its message with 1938 an Integer formatted Interface Identifier. 1940 The optional Diagnostic information can be any information germain to 1941 the error condition, to assist in identification of the error condition. 1942 In the case of an Invalid Version Error Code the Diagnostic information 1943 includes the supported Version parameter. In the other cases, the 1944 Diagnostic information MAY be the first 40 bytes of the offending message. 1946 3.3.3.2 Notify (NTFY) 1948 The Notify message is used to provide an autonomous indication of M2UA 1949 events to an M2UA peer. 1951 The NTFY message contains the following parameters: 1953 Status Type (mandatory) 1954 Status Information (mandatory) 1955 ASP Identifier (optional) 1956 Interface Identifiers (optional) 1957 INFO String (optional) 1959 The format for the Notify message with Integer-formatted Interface 1960 Identifiers is as follows: 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Tag (0xd) | Length | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Status Type | Status Information | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Tag (0xe) | Length | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | ASP Identifier* | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Tag (0x1=integer) | Length | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Interface Identifiers* | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Tag (0x8=integer range) | Length | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Interface Identifier Start1* | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Interface Identifier Stop1* | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Interface Identifier Start2* | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Interface Identifier Stop2* | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 . . 1990 . . 1991 . . 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Interface Identifier StartN* | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Interface Identifier StopN* | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Additional Interface Identifiers | 1999 | of Tag Type 0x1 or 0x8 | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Tag (0x4) | Length | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | INFO String* | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 The format for the Notify message with Text-formatted Interface 2010 Identifiers is as follows: 2012 0 1 2 3 2013 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 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | Tag (0xd) | Length | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Status Type | Status Information | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Tag (0xe) | Length | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | ASP Identifier* | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Tag (0x3=string) | Length | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | Interface Identifier* | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Additional Interface Identifiers | 2031 | of Tag Type 0x3 | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Tag (0x4) | Length | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | INFO String* | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 The Status Type parameter identifies the type of the Notify message. 2042 The following are the valid Status Type values: 2044 Value Description 2045 0x1 Application Server state change (AS_State_Change) 2046 0x2 Other 2048 The Status Information parameter contains more detailed information for 2049 the notification, based on the value of the Status Type. If the Status 2050 Type is AS_State_Change the following Status Information values are used: 2052 Value Description 2053 1 Application Server Down (AS_Down) 2054 2 Application Server Inactive (AS_Inactive) 2055 3 Application Server Active (AS_Active) 2056 4 Application Server Pending (AS_Pending) 2058 These notifications are sent from an SG to an ASP upon a change in status 2059 of a particular Application Server. The value reflects the new state of 2060 the Application Server. The Interface Identifiers of the AS MAY be 2061 placed in the message if desired. 2063 If the Status Type is Other, then the following Status Information values 2064 are defined: 2066 Value Description 2067 1 Insufficient ASP resources active in AS 2068 2 Alternate ASP Active 2069 3 ASP Failure 2071 In the Insufficent ASP Resources case, the SG is indicating to an 2072 "Inactive" ASP(s) in the AS that another ASP is required in order to 2073 handle the load of the AS (Load-sharing mode). For the Alternate ASP 2074 Active case, the formerly Active ASP is informed when an alternate 2075 ASP transitions to the ASP-Active state in Over-ride mode. The ASP 2076 ID (if available) of the Alternate ASP MUST be placed in the message. 2077 For the ASP Failure case, the SG is indicating to ASP(s) in the AS 2078 that one of the ASPs has failed (i.e. the ASP Transition to Down due 2079 to SCTP Communication Down Indication). The ASP ID (if available) of 2080 the failed ASP MUST be placed in the message. 2082 For each of the Status Information values in Status Type Other, the 2083 Interface Identifiers of the affected AS MAY be placed in the message 2084 if desired. 2086 The format and description of the optional Interface Identifiers and 2087 Info String parameters is the same as for the ASP Active message 2088 (See Section 3.3.2.3). 2090 4.0 Procedures 2092 The M2UA layer needs to respond to various primitives it receives from 2093 other layers as well as messages it receives from the peer-to-peer 2094 messages. This section describes various procedures involved in 2095 response to these events. 2097 4.1 Procedures to Support Service in Section 1.4.1 2099 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 2100 MTP Level 3 boundary" service. 2102 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 2104 On receiving a primitive from the local upper layer, the M2UA layer will 2105 send the corresponding MAUP message (see Section 3) to its peer. The 2106 M2UA layer MUST fill in various fields of the common and specific headers 2107 correctly. In addition the message SHOULD to be sent on the SCTP stream 2108 that corresponds to the SS7 link. 2110 4.1.2 MAUP Message Procedures 2112 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 2113 SG or MGC needs to invoke the corresponding layer primitives to the 2114 local MTP Level 2 or MTP Level 3 layer. 2116 4.2 Procedures to Support Service in Section 1.4.2 2118 These procedures achieve the M2UA layer's "Support for Communication 2119 between Layer Managements" service. 2121 4.2.1 Layer Management Primitives Procedure 2123 On receiving primitives from the local Layer Management, the M2UA layer 2124 will take the requested action and provide an appropriate response 2125 primitive to Layer Management. 2127 An M-SCTP ESTABLISH request from Layer Management will initiate the 2128 establishment of an SCTP association. An M-SCTP ESTABLISH confirm 2129 will be sent to Layer Management when the initiated association set-up 2130 is complete. An M-SCTP ESTABLISH indication is sent to Layer 2131 Management upon successful completion of an incoming SCTP association 2132 set-up from a peer M2UA node 2134 An M-SCTP RELEASE request from Layer Management will initiate the 2135 tear-down of an SCTP association. An M-SCTP RELEASE confirm will 2136 be sent by Layer Management when the association teardown is complete. 2137 An M-SCTP RELEASE indication is sent to Layer Management upon 2138 successful tear-down of an SCTP association initiated by a peer M2UA. 2140 M-SCTP STATUS request and indication support a Layer Management 2141 query of the local status of a particular SCTP association. 2143 M-NOTIFY indication and M-ERROR indication indicate to Layer 2144 Management the notification or error information contained in a 2145 received M2UA Notify or Error message respectively. These indications 2146 can also be generated based on local M2UA events. 2148 M-ASP STATUS request/indication and M-AS-STATUS request/indication 2149 support a Layer Management query of the local status of a particular 2150 ASP or AS. No M2UA peer protocol is invoked. 2152 M-ASP Up request, M-ASP Down request, M-ASP-INACTIVE request and 2153 M-ASP-ACTIVE request allow Layer Management at an ASP to initiate 2154 state changes. These requests result in outgoing M2UA ASP UP, 2155 ASP DOWN, ASP INACTIVE and ASP ACTIVE messages. 2157 M-ASP Up confirmation, M-ASP Down confirmation, M-ASP-INACTIVE 2158 confirmation and M-ASP-ACTIVE confirmation indicate to Layer 2159 Management that the previous request has been confirmed. 2161 All MGMT messages are sent on a sequenced stream to ensure ordering. 2162 SCTP stream '0' SHOULD be used. 2164 4.2.2 MGMT message procedures 2166 Upon receipt of MGMT messages the M2UA layer MUST invoke the corresponding 2167 Layer Management primitives indications (e.g., M-AS Status ind., M-ASP 2168 Status ind., M-ERROR ind...) to the local layer management. 2170 M-NOTIFY indication and M-ERROR indication indicate to Layer Management 2171 the notification or error information contained in a received M2UA 2172 Notify or Error message. These indications can also be generated 2173 based on local M2UA events. 2175 All MGMT messages are sent on a sequenced stream to ensure ordering. 2176 SCTP stream '0' SHOULD be used. 2178 4.3 Procedures to Support Service in Section 1.4.3 2180 These procedures achieve the M2UA layer's "Support for management of 2181 active associations between SG and MGC" service. 2183 4.3.1 AS and ASP State Maintenance 2185 The M2UA layer on the SG maintains the state of each ASP, in each 2186 Appliction Server that is configured to receive traffic. 2188 4.3.1.1 ASP States 2190 The state of the each ASP, in each AS that it is configured, is 2191 maintained in the M2UA layer on the SG. The state of an ASP changes 2192 due to events. The events include 2194 * Reception of messages from peer M2UA layer at that ASP 2195 * Reception of some messages from the peer M2UA layer at other 2196 ASPs in the AS 2197 * Reception of indications from SCTP layer 2199 The ASP state transition diagram is shown in Figure 6. The possible 2200 states of an ASP are the following: 2202 ASP Down: Application Server Process is unavailable and/or the related 2203 SCTP association is down. Initially all ASPs will be in this state. 2204 An ASP in this state SHOULD NOT not be sent any M2UA messages. 2206 ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the 2207 related SCTP association is up) but application traffic is stopped. 2208 In this state the ASP can be sent any non-MAUP M2UA messages. 2210 ASP-ACTIVE: The remote M2UA peer at the ASP is available and 2211 application traffic is active. 2213 Figure 6 ASP State Transition Diagram 2215 +-------------+ 2216 +----------------------| | 2217 | Alternate +-------| ASP-ACTIVE | 2218 | ASP | +-------------+ 2219 | Takeover | ^ | 2220 | | ASP | | ASP 2221 | | Active | | Inactive 2222 | | | v 2223 | | +-------------+ 2224 | | | | 2225 | +------>| ASP-INACT | 2226 | +-------------+ 2227 | ^ | 2228 ASP Down/ | ASP | | ASP Down / 2229 SCTP CDI | Up | | SCTP CDI 2230 | | v 2231 | +-------------+ 2232 +--------------------->| | 2233 | ASP Down | 2234 +-------------+ 2236 SCTP CDI: The local SCTP layer's Communication Down Indication to the 2237 Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this 2238 indication when it detects the loss of connectivity to the ASP's peer 2239 SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE 2240 notification and COMMUNICATION LOST notification from the SCTP. 2242 When an SCTP association fails at the SG, M2UA shall change the states 2243 of all ASPs reached through the aborted SCTP association to ASP-DOWN. 2245 4.3.1.2 AS States 2247 The state of the AS is maintained in the M2UA layer on the SG. 2249 The state of an AS changes due to events. These events include the 2250 following: 2252 * ASP state transitions 2253 * Recovery timer triggers 2255 The possible states of an AS are the following: 2257 AS-DOWN: The Application Server is unavailable. This state implies 2258 that all related ASPs are in the ASP Down state for this AS. When 2259 the AS transitions to the AS-DOWN state, all of the SS7 links (Interface 2260 Identifiers) for this AS should be taken out-of-service. Initially the 2261 AS will be in this state. 2263 AS-INACTIVE: The Application Server is available but no application 2264 traffic is active (i.e., one or more related ASPs are in the ASP-Inactive 2265 state, but none in the ASP-Active state). 2267 AS-ACTIVE: The Application Server is available and application traffic 2268 is active. This state implies that one ASP is in the ASP-ACTIVE state. 2270 AS-PENDING: An active ASP has transitioned from active to inactive or 2271 down and it was the last remaining active ASP in the AS. A recovery 2272 timer T(r) will be started and all incoming SCN messages will be 2273 queued by the SG. If an ASP becomes active before T(r) expires, the 2274 AS will move to AS-ACTIVE state and all the queued messages will be 2275 sent to the active ASP. 2277 If T(r) expires before an ASP becomes active, the SG stops queueing 2278 messages and discards all previously queued messages. In addition, 2279 the SG SHALL send the Stop primitive to MTP2 to take the link out of 2280 service. The AS will move to AS-Inactive if at least one ASP is in 2281 ASP-Inactive state, otherwise it will move to AS-DOWN state. 2283 If an ASP transitions to the ASP-DOWN state and all ASPs in the AS are 2284 in the ASP-DOWN state, then the SG SHALL send the Stop primitive to MTP2 2285 to take the link out of service and moves the AS to the AS-DOWN state. 2287 Figure 7 AS State Transition Diagram 2289 +----------+ one ASP trans ACTIVE +-------------+ 2290 | |------------------------>| | 2291 | AS-INACT | | AS-ACTIVE | 2292 | | | | 2293 | |< | | 2294 +----------+ \ +-------------+ 2295 ^ | \ Tr Expires ^ | 2296 | | \ at least one | | 2297 | | \ ASP in UP | | 2298 | | \ | | 2299 | | \ | | 2300 | | \ | | 2301 one ASP | | \ one ASP | | Last ACTIVE ASP 2302 trans | | all ASP \------\ trans to | | trans to INACT 2303 to | | trans to \ ACTIVE | | or DOWN 2304 INACT | | DOWN \ | | (start Tr timer) 2305 | | \ | | 2306 | | \ | | 2307 | | \ | | 2308 | v \ | v 2309 +----------+ \ +-------------+ 2310 | | -| | 2311 | AS-DOWN | | AS-PENDING | 2312 | | | (queueing) | 2313 | |<------------------------| | 2314 +----------+ Tr Expiry and no +-------------+ 2315 ASP in INACTIVE state 2317 Tr = Recovery Timer 2319 4.3.2 ASPM procedures for primitives 2321 Before the establishment of an SCTP association the ASP state at both 2322 the SG and ASP is assumed to be "Down". 2324 As the ASP is responsible for initiating the setup of an SCTP 2325 association to an SG, the M2UA layer at an ASP receives an M-SCTP 2326 ESTABLISH request primitive from the Layer Management, the M2UA layer 2327 will try to establish an SCTP association with the remote M2UA peer at 2328 an SG. Upon reception of an eventual SCTP-Communication Up confirm 2329 primitive from the SCTP, the M2UA layer will invoke the primitive 2330 M-SCTP ESTABLISH confirm to the Layer Management. 2332 At the SG, the M2UA layer will receive an SCTP Communication Up 2333 indication primitive from the SCTP. The M2UA layer will then invoke 2334 the primitive M-SCTP ESTABLISH indication to the Layer Management. 2336 Once the SCTP association is established and assuming that the local 2337 M2UA-User is ready, the local ASP M2UA Application Server Process 2338 Maintenance (ASPM) function will initiate the ASPM procedures, using 2339 the ASP Up/-Down/-Active/-Inactive messages to convey the ASP-state to 2340 the SG - see Section 4.3.3. 2342 The Layer Management and the M2UA layer on SG can communicate the 2343 status of the application server using the M-AS STATUS primitives. 2344 The Layer Managements and the M2UA layers on both the SG and ASP 2345 can communicate the status of an SCTP association using the 2346 M-SCTP STATUS primitives. 2348 If the Layer Management on SG or ASP wants to bring down an SCTP 2349 association for management reasons, they would send M-SCTP RELEASE 2350 request primitive to the local M2UA layer. The M2UA layer would release 2351 the SCTP association and upon receiving the SCTP Communication Down 2352 indication from the underlying SCTP layer, it would inform the local 2353 Layer Management using M-SCTP RELEASE confirm primitive. 2355 If the M2UA layer receives an SCTP-Communication Down or Restart 2356 indication from the underlying SCTP layer, it will inform the Layer 2357 Management by invoking the M-SCTP RELEASE indication primitive. At the 2358 SG, M2UA shall change the states of all ASPs reached through the aborted 2359 SCTP association to ASP-DOWN. Athe ASP, M2UA shall either cause other 2360 ASPs to become active or send link-out-of-service primitives to MTP3. 2362 At an ASP, the Layer Management MAY try to reestablish the SCTP 2363 association using M-SCTP ESTABLISH request primitive. 2365 4.3.3 ASPM procedures for peer-to-peer messages 2367 All ASPM messages are sent on a sequenced stream to ensure ordering. 2368 SCTP stream '0' SHOULD be used. 2370 4.3.3.1 ASP-Inactive 2372 After an ASP has successfully established an SCTP association to an SG, 2373 the SG waits for the ASP to send an ASP Up message, indicating that the 2374 ASP M2UA peer is available. The ASP is always the initiator of the 2375 ASP Up exchange. 2377 When an ASP Up message is received at an SG and internally the ASP is 2378 not considered locked-out for local management reasons, the SG marks 2379 the remote ASP as Inactive. If the ASP UP message contains an ASP 2380 Identifier, the SG saves the ASP Identifier for that ASP. The SG 2381 responds with an ASP Up Ack message in acknowledgement. The SG sends 2382 an ASP Up Ack message in response to a received ASP Up message even if 2383 the ASP is already marked as "Inactive" at the SG. 2385 If for any local reason the SG cannot respond with an ASP Up Ack, the 2386 SG responds to the ASP Up with a ASP Down Ack message. 2388 When the ASP sends an ASP Up it starts timer T(ack). If the ASP does 2389 not receive a response to an ASP Up within T(ack), the ASP MAY restart 2390 T(ack) and resend ASP Up messages until it receives an ASP Up Ack 2391 message. T(ack) SHOULD be provisionable, with a default of 2 seconds. 2392 Alternatively, retransmission of ASP Up messages MAY be put under 2393 control of Layer Management. In this method, expiry of T(ack) results 2394 in a M-ASP-Up confirmation carrying a negative indication. 2396 The ASP MUST wait for the ASP Up Ack message from the SG before 2397 sending any ASP traffic control messages (ASPAC or ASPIA) or MAUP 2398 messages or it will risk message loss. If the SG receives MAUP 2399 messages before an ASP Up is received, the SG SHOULD discard them. 2401 4.3.3.2 ASP Down 2403 The ASP will send an ASP Down to a SG when the ASP is to be removed 2404 from the list of ASPs in the Application Server that it is a member 2405 and no longer receive any M2UA traffic or management messages. 2407 Whether the ASP is permanently removed from an AS is a function of 2408 configuration management. 2410 The SG marks the ASP as "Down" and returns an ASP Down Ack message to 2411 the ASP if one of the following events occur: 2413 - to acknowledge an ASP Down message received from a remote M2UA 2414 peer 2415 - to reply to an ASPM message from an ASP which is locked out 2416 for management reasons. 2418 The SG sends an ASP Down Ack message in response to a received ASP Down 2419 message from the ASP even if the ASP is already marked as "Down" at 2420 the SG. 2422 At the ASP, the ASP Down Ack message received is not acknowledged. 2423 Layer Management is informed with an M-ASP Down confirm primitive. 2425 When the ASP sends an ASP Down it starts timer T(ack). If the ASP does 2426 not receive a response to an ASP Down within T(ack), the ASP MAY 2427 restart T(ack) and resend ASP Down messages until it receives an 2428 ASP Down Ack message. T(ack) SHOULD be provisionable, with a default 2429 of 2 seconds. Alternatively, retransmission of ASP Down messages MAY 2430 be put under control of Layer Management. In this method, expiry of 2431 T(ack) results in a M-ASP-Down confirmation carrying a negative 2432 indication. 2434 4.3.3.3 M2UA Version Control 2436 If a ASP Up message with an unsupported version is received, the 2437 receiving end responds with an Error message, indicating the version 2438 the receiving node supports. 2440 This is useful when protocol version upgrades are being performed in a 2441 network. A node upgraded to a newer version SHOULD support the older 2442 versions used on other nodes it is communicating with. Because ASPs 2443 initiate the ASP Up procedure it is assumed that the Error message 2444 would normally come from the SG. 2446 4.3.3.4 ASP Active 2448 Any time after the ASP has received a ASP Up Ack from the SG, the ASP 2449 can send an ASP Active (ASPAC) to the SG indicating that the ASP is 2450 ready to start processing traffic. 2452 When an ASP Active (ASPAC) message is received, the SG responds to the 2453 ASP with a ASPAC Ack message acknowledging that the ASPAC was received 2454 and starts sending traffic for the associated Application Server 2455 to that ASP. Note that the SG sends an ASP Active Ack message in 2456 response to a received ASP Active message even if the ASP is already 2457 marked as "Active" at the SG. 2459 The ASP MUST wait for the ASP Active Ack message from the SG before 2460 sending any Data messages or it will risk message loss. If the SG 2461 receives MAUP messages before an ASP Active is received, the SG SHOULD 2462 discard these messages. 2464 At the ASP, the ASP-Active Ack message received is not acknowledged. 2465 Layer Management is informed with an M-ASP Active confirm primitive. 2467 When the ASP sends an ASP Active it starts timer T(ack). If 2468 the ASP does not receive a response to an ASP Active within T(ack), the 2469 ASP MAY restart T(ack) and resend ASP Active messages until it 2470 receives an ASP Active Ack message. T(ack) SHOULD be provisionable, with 2471 a default of 2 seconds. Alternatively, retransmission of ASP Active 2472 messages may be put under control of Layer Management. In this method, 2473 expiry of T(ack) results in a M-ASP-Active confirmation carrying a 2474 negative indication. 2476 There are three modes of Application Server traffic handling in the SG 2477 M2UA - Over-ride, Load-share and Broadcast. The Traffic Mode Type 2478 parameter in the ASPAC messge indicates the mode used in a particular 2479 Application Server. If the SG determines that the mode indicates in 2480 an ASPAC is incompatible with the traffic handling mode currently used 2481 in the AS, the SG responds with an Error message indicating Unsupported 2482 Traffic Handling Mode. 2484 For Over-ride mode AS, the reception of an ASPAC message at an SG causes 2485 the redirection of all traffic for the AS to the ASP that sent the ASPAC. 2486 The SG responds to the ASPAC with an ASP Active Ack message to the ASP. 2487 Any previously active ASP in the AS is now considered Inactive and will 2488 no longer receive traffic from the SG within the AS. The SG sends a 2489 Notify (Alternate ASP-Active) to the previously active ASP in the AS, 2490 after stopping all traffic to that ASP. 2492 In the case of a Load-share mode AS, reception of an ASPAC message at 2493 an SG causes the redirection of some traffic to the ASP sending the 2494 ASPAC. The algorithm at the SG for load-sharing traffic within an AS 2495 to all the active ASPs is implementation dependent. The algorithm 2496 could, for example be round-robin or based on information in the Data 2497 message (e.g., such as the SLS in the Routing Label). 2499 In the case of a Broadcast mode AS, reception of an ASPAC message at 2500 an SG causes the traffic to be sent to the ASP sending the ASPAC and 2501 the same traffic continues to be sent to the other Active ASP(s). 2503 4.3.3.5 ASP Inactive 2505 When an ASP wishes to withdraw from receiving traffic within an AS, 2506 the ASP sends an ASP Inactive (ASPIA) to the SG. 2508 There are three modes of Application Server traffic handling in the SG 2509 M2UA when withdrawing an ASP from service - Over-ride, Load-share and 2510 Broadcast. The Traffic Mode Type parameter in the ASPIA messge indicates 2511 the mode used in a particular Application Server. If the SG determines 2512 that the mode indicates in an ASPAC is incompatible with the traffic 2513 handling mode currently used in the AS, the SG responds with an Error 2514 message indicating Unsupported Traffic Handling Mode. 2516 In the case of an Over-ride mode AS, where normally another ASP has 2517 already taken over the traffic within the AS with an Over-ride ASPAC, 2518 the ASP which sends the ASPIA is already considered by the SG to be 2519 "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is 2520 sent to the ASP, after ensuring that all traffic is stopped to the ASP. 2522 In the case of a Load-share mode AS, the SG moves the ASP to the 2523 "Inactive" state and the AS traffic is re-allocated across the 2524 remaining "active" ASPs per the load-sharing algorithm currently used 2525 within the AS. A NTFY(Insufficient ASP resources active in AS) may be 2526 sent to all inactive ASPs, if required. An ASPIA Ack message is sent 2527 to the ASP after all traffic is halted and Layer Management is informed 2528 with an ASP-INACTIVE indication primitive. 2530 In the case of a Broadcast mode AS, the SG moves the ASP to the 2531 "Inactive" state and stops sending the AS traffic to the ASP. The 2532 SG continues to send the AS traffic to the remaining "active" ASPs. 2533 A NTFY(Insufficient ASP resources active in AS) may be sent to all 2534 inactive ASPs, if required. An ASPIA Ack message is sent to the ASP 2535 after all traffic is halted and Layer Management is informed with an 2536 ASP-INACTIVE indication primitive. 2538 When the ASP sends an ASP Inactive it starts timer T(ack). If the ASP 2539 does not receive a response to an ASP Inactive within T(ack), the ASP 2540 MAY restart T(ack) and resend ASP Inactive messages until it receives 2541 an ASP Inactive Ack message. T(ack) SHOULD be provisionable, with a 2542 default of 2 seconds. Alternatively, retransmission of ASP Inactive 2543 messages may be put under control of Layer Management. In this method, 2544 expiry of T(ack) results in a M-ASP-Inactive confirmation carrying a 2545 negative indication. 2547 If no other ASPs are Active in the Application Server, the SG either 2548 discards all incoming messages for the AS or starts buffering the 2549 incoming messages for T(r) seconds, after which messages will be 2550 discarded. T(r) is configurable by the network operator. If the SG 2551 receives an ASPAC from an ASP in the AS before expiry of T(r), the 2552 buffered traffic is directed to the ASP and the timer is cancelled. 2554 4.3.3.6 Notify 2556 A Notify message reflecting a change in the AS state is sent to all 2557 ASP(s) in the AS, except those in the "Down" state, with appropriate 2558 Status Information. 2560 In the case where a Notify (AS-Pending) message is sent by an SG 2561 that now has no ASP(s) active to service the traffic, the Notify does 2562 not explicitly force the ASP(s) receiving the message to become 2563 active. The ASP remain in control of what (and when) action is 2564 taken. 2566 In addition, the Notify message will be sent to all ASP(s) in the 2567 AS, except those in the "Down" state, when an ASP fails with the 2568 ASP Identifier of the failed ASP. 2570 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 2572 5.1 Establishment of associations between SG and MGC examples 2574 5.1.1 Single ASP in an Application Server (1+0 sparing) 2576 This scenario shows the example M2UA message flows for the establishment 2577 of traffic between an SG and an ASP, where only one ASP is configured 2578 within an AS (no backup). It is assumed that the SCTP association is 2579 already set-up. 2581 SG ASP1 2582 | 2583 |<---------ASP Up----------| 2584 |--------ASP Up Ack------->| 2585 | | 2586 |<-------ASP Active--------| 2587 |------ASP_Active Ack----->| 2588 | | 2590 5.1.2 Two ASPs in Application Server (1+1 sparing) 2592 This scenario shows the example M2UA message flows for the establishment 2593 of traffic between an SG and two ASPs in the same Application Server, 2594 where ASP1 is configured to be active and ASP2 to be standby in the event 2595 of communication failure or the withdrawal from service of ASP1. ASP2 MAY 2596 act as a hot, warm, or cold standby depending on the extent to which ASP1 2597 and ASP2 share call/transaction state or can communicate call state under 2598 failure/withdrawal events. 2600 SG ASP1 ASP2 2601 | | | 2602 |<--------ASP Up----------| | 2603 |-------ASP Up Ack------->| | 2604 | | | 2605 |<-----------------------------ASP Up----------------| 2606 |----------------------------ASP Up Ack------------->| 2607 | | | 2608 | | | 2609 |<-------ASP Active-------| | 2610 |-----ASP-Active Ack----->| | 2611 | | | 2613 5.2 ASP Traffic Fail-over Examples 2615 5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) 2617 Following on from the example in Section 5.1.2, and ASP withdraws from 2618 service: 2620 SG ASP1 ASP2 2621 | | | 2622 |<-----ASP Inactive-------| | 2623 |----ASP Inactive Ack---->| | 2624 |--------------------NTFY(AS-Down) (Optional)------->| 2625 | | | 2626 |<------------------------------ ASP Active----------| 2627 |-----------------------------ASP-Active Ack)------->| 2628 | | 2630 In this case, the SG notifies ASP2 that the AS has moved to the 2631 Down state. The SG could have also (optionally) sent a Notify 2632 message when the AS moved to the Pending state. 2634 Note: If the SG detects loss of the M2UA peer (through a detection 2635 of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange 2636 would not occur. 2638 5.2.2 (1+1 Sparing, Back-up Over-ride) 2640 Following on from the example in Section 5.1.2, and ASP2 wishes to over- 2641 ride ASP1 and take over the traffic: 2643 SG ASP1 ASP2 2644 | | | 2645 |<------------------------------ ASP Active----------| 2646 |-----------------------------ASP-Active Ack-------->| 2647 |----NTFY( Alt ASP-Act)-->| 2648 | (optional) | | 2650 In this case, the SG notifies ASP1 that an alternative ASP has 2651 overridden it. 2653 5.3 SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 2655 When the M2UA layer on the ASP has a MAUP message to send to the SG, it 2656 will do the following: 2658 - Determine the correct SG 2660 - Find the SCTP association to the chosen SG 2662 - Determine the correct stream in the SCTP association based on 2663 the SS7 link 2665 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2666 Common Header 2668 - Send the MAUP message to the remote M2UA peer in the SG, over the 2669 SCTP association 2671 When the M2UA layer on the SG has a MAUP message to send to the ASP, it 2672 will do the following: 2674 - Determine the AS for the Interface Identifier 2676 - Determine the Active ASP (SCTP association) within the AS 2678 - Determine the correct stream in the SCTP association based on 2679 the SS7 link 2681 - Fill in the MAUP message, fill in M2UA Message Header, fill in 2682 Common Header 2684 - Send the MAUP message to the remote M2UA peer in the ASP, over the 2685 SCTP association 2687 5.3.1 SS7 Link Alignment 2689 The MGC can request that a SS7 link be brought into alignment using the 2690 normal or emergency procedure. An example of the message flow to bring 2691 a SS7 link in-service using the normal alignment procedure is shown 2692 below. 2694 MTP2 M2UA M2UA MTP3 2695 SG SG ASP ASP 2697 <----Start Req---|<---Establish Req----|<----Start Req------ 2699 ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind----> 2701 An example of the message flow to bring a SS7 link in-service using the 2702 emergency alignment procedure. 2704 MTP2 M2UA M2UA MTP3 2705 SG SG ASP ASP 2707 <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req--- 2709 -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm----> 2711 <---Start Req----|<-------Establish Req-------------|<---Start Req---- 2713 ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind--> 2715 5.3.2 SS7 Link Release 2717 The MGC can request that a SS7 link be taken out-of-service. It uses 2718 the Release Request message as shown below. 2720 MTP2 M2UA M2UA MTP3 2721 SG SG ASP ASP 2723 <-----Stop Req-----|<---Release Req------|<-----Stop Req------ 2725 --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind--> 2727 The SG can autonomously indicate that a SS7 link has gone out-of-service 2728 as shown below. 2730 MTP2 M2UA M2UA MTP3 2731 SG SG ASP ASP 2733 --Out of Serv->|----Release Ind----->|--Out of Serv--> 2735 5.3.3 Set and Clear Local Processor Outage 2737 The MGC can set a Local Processor Outage condition. It uses the 2738 State Request message as shown below. 2740 MTP2 M2UA M2UA MTP3 2741 SG SG ASP ASP 2743 <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req--- 2745 -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm----> 2747 The MGC can clear a Local Processor Outage condition. It uses the 2748 State Request message as shown below. 2750 MTP2 M2UA M2UA MTP3 2751 SG SG ASP ASP 2753 <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req--- 2755 ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm----> 2757 5.3.4 Notification of Remote Processor Outage 2759 The SG can indicate Remote has entered or exited the Processor Outage 2760 condition. It uses the State Indication message as shown below. 2762 MTP2 M2UA M2UA MTP3 2763 SG SG ASP ASP 2765 ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind----> 2767 -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind--> 2769 5.3.5 Notification of Link Congestion 2771 The SG can indicate that a link has become congested. It uses the 2772 Congestion Indication message as shown below. 2774 MTP2 M2UA M2UA MTP3 2775 SG SG ASP ASP 2777 ----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind----> 2779 -Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind-> 2781 5.3.6 SS7 Link Changeover 2783 An example of the message flow for an error free changeover is shown 2784 below. In this example, there were three messages in the retransmission 2785 queue that needed to be retrieved. 2787 MTP2 M2UA M2UA MTP3 2788 SG SG ASP ASP 2790 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2791 (seq_num = 0) 2793 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2794 (seq_num = BSN) 2796 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2797 (seq_num = FSN) 2799 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2800 (seq_num = 0) 2802 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2803 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2804 -Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind--> 2806 -Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind--> 2808 Note: The number of Retrieval Indication is dependent on the number of 2809 messages in the retransmit queue that have been requested. Only one 2810 Retrieval Complete Indication SHOULD be sent. 2812 An example of a message flow with an error retrieving the BSN is shown 2813 below. 2815 MTP2 M2UA M2UA MTP3 2816 SG SG ASP ASP 2818 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2820 -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> 2821 (seq_num = -1) 2823 An example of a message flow with an error retrieving the messages is 2824 shown below. 2826 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- 2828 -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> 2829 (seq_num = BSN) 2831 <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- 2832 (seq_num = FSN) 2834 -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> 2835 (seq_num = -1) 2837 An example of a message flow for a request to drop messages (clear 2838 retransmission buffers) is shown below. 2840 MTP2 M2UA M2UA MTP3 2841 SG SG ASP ASP 2843 <-Clr TB/RTB Req-|<-Rtrv Req (ACTION_DROP_MSGS)-|<--Clr TB/RTB Req--- 2845 -Clr TB/RTB Ind->|-Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr TB/RTB Ind--> 2847 5.3.7 Flush and Continue 2849 The following message flow shows a request to flush buffers. 2851 MTP2 M2UA M2UA MTP3 2852 SG SG ASP ASP 2854 <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- 2856 ---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm--> 2858 The following message flow shows a request to continue. 2860 MTP2 M2UA M2UA MTP3 2861 SG SG ASP ASP 2863 <---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req--- 2865 ----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm--> 2867 5.3.8 Auditing of SS7 link state 2869 It may be necessary for the ASP to audit the current state of a SS7 link. 2870 The flows below show an example of the request and all the potential 2871 responses. 2873 Below is an example in which the SS7 link is out-of-service. 2875 MTP2 M2UA M2UA MGMT 2876 SG SG ASP ASP 2878 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2880 |-----State Cfm (STATUS_AUDIT)--->| 2882 MTP3 2883 ASP 2885 |-----------Release Ind---------->|-Out of Serv Ind-> 2887 Below is an example in which the SS7 link is in-service. 2889 MTP2 M2UA M2UA MGMT 2890 SG SG ASP ASP 2892 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2894 |-----State Cfm (STATUS_AUDIT)--->| 2896 MTP3 2897 ASP 2899 |-----------Establish Cfm-------->|---In Serv Ind--> 2901 Below is an example in which the SS7 link is in-service, but congested. 2903 MTP2 M2UA M2UA MGMT 2904 SG SG ASP ASP 2906 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2908 |-----State Cfm (STATUS_AUDIT)--->| 2910 MTP3 2911 ASP 2913 |-----------Establish Cfm-------->|---In Serv Ind--> 2915 |----------Congestion Ind-------->|---Cong Ind-----> 2917 Below is an example in which the SS7 link is in-service, but in Remote 2918 Processor Outage. 2920 MTP2 M2UA M2UA MGMT 2921 SG SG ASP ASP 2923 |<----State Req (STATUS_AUDIT)----|<----Audit------- 2925 |-----State Cfm (STATUS_AUDIT)--->| 2927 MTP3 2928 ASP 2930 |-----------Establish Ind-------->|---In Serv Ind--> 2932 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter---> 2934 6.0 Timer Values 2936 The recommended default values for M2UA timers are: 2938 T(r) 2 seconds 2939 T(ack) 2 seconds 2941 7.0 Security 2943 M2UA is designed to carry signaling messages for telephony services. 2944 As such, M2UA MUST involve the security needs of several parties: the 2945 end users of the services; the network providers and the applications 2946 involved. Additional requirements MAY come from local regulation. 2947 While having some overlapping security needs, any security solution 2948 SHOULD fulfill all of the different parties' needs. 2950 7.1 Threats 2952 There is no quick fix, one-size-fits-all solution for security. As a 2953 transport protocol, M2UA has the following security objectives: 2955 * Availability of reliable and timely user data transport. 2956 * Integrity of user data transport. 2957 * Confidentiality of user data. 2959 M2UA runs on top of SCTP. SCTP [5] provides certain transport related 2960 security features, such as: 2962 * Blind Denial of Service Attacks 2963 * Flooding 2964 * Masquerade 2965 * Improper Monopolization of Services 2967 When M2UA is running in professionally managed corporate or service 2968 provider network, it is reasonable to expect that this network includes 2969 an appropriate security policy framework. The "Site Security Handbook" 2970 [10] SHOULD be consulted for guidance. 2972 When the network in which M2UA runs in involves more than one party, it 2973 MAY NOT be reasonable to expect that all parties have implemented 2974 security in a sufficient manner. In such a case, it is recommended that 2975 IPSEC is used to ensure confidentiality of user payload. Consult [11] 2976 for more information on configuring IPSEC services. 2978 7.2 Protecting Confidentiality 2980 Particularly for mobile users, the requirement for confidentiality MAY 2981 include the masking of IP addresses and ports. In this case application 2982 level encryption is not sufficient; IPSEC ESP SHOULD be used instead. 2983 Regardless of which level performs the encryption, the IPSEC ISAKMP 2984 service SHOULD be used for key management. 2986 8.0 IANA Considerations 2988 8.1 SCTP Payload Protocol Identifier 2990 A request will be made to IANA to assign an M2UA value for the Payload 2991 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 2992 Payload Protocol Identifier will be registered: 2994 M2UA 0x10 2996 The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, 2997 to indicate which protocol the SCTP is carrying. This Payload Protocol 2998 Identifier is not directly used by SCTP but MAY be used by certain 2999 network entities to identify the type of information being carried in a 3000 Data chunk. 3002 The User Adaptation peer MAY use the Payload Protocol Identifier as a 3003 way of determining additional information about the data being presented 3004 to it by SCTP. 3006 8.2 M2UA Protocol Extensions 3008 This protocol may also be extended through IANA in three ways: 3010 -- through definition of additional message classes, 3011 -- through definition of additional message types, and 3012 -- through definition of additional message parameters. 3014 The definition and use of new message classes, types and parameters is 3015 an integral part of SIGTRAN adaptation layers. Thus, these extensions 3016 are assigned by IANA through an IETF Consensus action as defined in 3017 [RFC2434]. 3019 The proposed extension must in no way adversely affect the general 3020 working of the protocol. 3022 8.2.1 IETF Defined Message Classes 3024 The documentation for a new message class MUST include the following 3025 information: 3027 (a) A long and short name for the message class. 3028 (b) A detailed description of the purpose of the message class. 3030 8.2.2 IETF Defined Message Types 3032 Documentation of the message type MUST contain the following information: 3034 (a) A long and short name for the new message type. 3035 (b) A detailed description of the structure of the message. 3036 (c) A detailed definition and description of intended use of each field 3037 within the message. 3038 (d) A detailed procedural description of the use of the new message type 3039 within the operation of the protocol. 3040 (e) A detailed description of error conditions when receiving this message 3041 type. 3043 When an implementation receives a message type which it does not support, 3044 it MUST respond with an Error (ERR) message with an Error Code of 3045 Unsupported Message Type. 3047 8.2.3 IETF-defined TLV Parameter Extension 3049 Documentation of the message parameter MUST contain the following 3050 information: 3052 (a) Name of the parameter type. 3053 (b) Detailed description of the structure of the parameter field. This 3054 structure MUST conform to the general type-length-value format 3055 described in Section 3.1.5. 3056 (c) Detailed definition of each component of the parameter value. 3057 (d) Detailed description of the intended use of this parameter type, 3058 and an indication of whether and under what circumstances 3059 multiple instances of this parameter type may be found within the 3060 same message type. 3062 9.0 Acknowledgements 3064 The authors would like to thank John Loughney, Neil Olson, Michael 3065 Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz 3066 Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald and Mark 3067 Kobine for their valuable comments and suggestions. 3069 10.0 References 3071 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 3072 System No. 7 (SS7)' 3074 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 3075 Message Transfer Part (MTP)' 3077 [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' 3079 [4] Bellcore GR-246-CORE 'Bell Communications Research Specification 3080 of Signaling System Number 7', Volume 1, December 1995 3082 [5] Stream Control Transmission Protocol, RFC 2960, October 2000 3084 [6] Architectural Framework for Signaling Transport, RFC 2719, 3085 October 1999 3087 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February 3088 1995 3090 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 3091 functions and messages using the services of ITU-T 3092 Recommendation Q.2140', August 1995 3094 [9] ITU-T Recommendation Q.751.1, 'Network Element Management Information 3095 Model for the Messsage Transfer Part', October 1995 3097 [10] Site Security Handbook, RFC 2196, September 1997 3099 [11] Security Architecture for the Internet Protocol, RFC 2401 3101 [12] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip- 3102 sctp-00.txt, May 7, 2001 3104 11.0 Author's Addresses 3106 Ken Morneault Tel: +1-703-484-3323 3107 Cisco Systems Inc. EMail: kmorneau@cisco.com 3108 13615 Dulles Technology Drive 3109 Herndon, VA. 20171 3110 USA 3112 Ram Dantu, Ph.D. Tel +1-469-255-0716 3113 Cisco Systems EMail rdantu@cisco.com 3114 17919 Waterview 3115 Dallas, TX 75252 3116 USA 3118 Greg Sidebottom Tel: +1-613-763-7305 3119 Nortel Networks EMail: gregside@nortelnetworks.com 3120 3685 Richmond Rd, 3121 Nepean, Ontario 3122 Canada K2H5B7 3124 Tom George Tel: +1-972-519-3168 3125 Alcatel USA EMail: tom.george@usa.alcatel.com 3126 1000 Coit Road 3127 Plano, TX 74075 3128 USA 3130 Brian Bidulock Tel +1-972-839-4489 3131 OpenSS7 Project EMail: bidulock@openss7.org 3132 c/o #424, 4701 Preston Park Blvd. 3133 Dallas, TX 75093 3134 USA 3136 Jacob Heitz Tek +1-510-747-2917 3137 Lucent Technologies Email: jheitz@lucent.com 3138 1701 Harbor Bay Parkway 3139 Alameda, CA, 94502 3140 USA 3142 This Internet Draft expires December 2001.