idnits 2.17.1 draft-ietf-sigtran-m3ua-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 1 longer page, the longest (page 1) being 1660 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 240 has weird spacing: '...then determin...' == Line 1152 has weird spacing: '...ges and disca...' -- 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 (8 October 1999) is 8967 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) == Unused Reference: '1' is defined on line 1363, 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' == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-00 -- Possible downref: Non-RFC (?) normative reference: 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' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Sidebottom, L. Ong, Guy Mousseau 2 INTERNET-DRAFT Nortel Networks 3 Ian Rytina 4 Ericsson 5 Hanns-Juergen Schwarzbauer 6 Siemens 7 Ken Morneault 8 Cisco 9 Mallesh Kalla 10 Telcordia 12 Expires in six months 8 October 1999 14 SS7 MTP3-User Adaptation Layer (M3UA) 15 17 Status of This Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC 2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as 'work in progress.' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check the 37 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 38 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 40 ftp.isi.edu (US West Coast). 42 Abstract 44 This Internet Draft defines a protocol for transport of SS7 MTP3-User 45 signaling (e.g., ISUP and SCCP messages) over IP using the Simple 46 Control Transport Protocol. Also, provision is made for protocol 47 elements that enable a seamless, or as seamless as possible, operation 48 of the MTP3-User peers in the SS7 and IP domains. This protocol would 49 be used between a Signaling Gateway (SG) and a Media Gateway Controller 50 (MGC) or IP-resident database but could also be used between two SGs 51 if desired. It is assumed that the SG receives SS7 signaling 52 over a standard SS7 interface using the SS7 Message Transfer Part 53 (MTP) to provide transport. 55 NOTE: THIS DRAFT REPLACES 57 1 58 TABLE OF CONTENTS 60 1. Introduction..............................................3 61 2. Protocol Elements........................................11 62 3. Procedures...............................................21 63 4. Examples.................................................26 64 5. Security.................................................27 65 6. Acknowledgements.........................................27 66 7. References...............................................27 67 8. Author's Addresses.......................................28 69 2 70 1. Introduction 72 1.1 Scope 74 There is a need for SCN signaling protocol delivery from an SS7 75 Signaling Gateway (SG) to a Media Gateway Controller (MGC). The 76 delivery mechanism should meet the following criteria: 78 * Support for transfer of SS7 MTP3-User Part messages (e.g., ISUP, 79 SCCP, TUP, etc.) 80 * Support for the seamless operation of MTP3-User peers 81 * Support for the management of SCTP 82 transport associations between an SG and an MGC or IP Database) 83 * Support for the asynchronous reporting of status changes to 84 management 86 In other words, the SG will terminate SS7 MTP2 and MTP3 protocols and 87 deliver ISUP, SCCP and/or any other MTP3-User protocols to IP-resident 88 Application Server Processes over an SCTP transport association 90 1.2 Terminology 92 Application Server (AS) - A logical entity serving a specific 93 application instance. An example of an Application Server is a virtual 94 switch handling all call processing for a particular SS7 95 OPC/DPC/CIC_range. Practically speaking, an AS is modeled at the SG as 96 an ordered list of one or more related Application Server Processes 97 (e.g., primary, secondary, tertiary, ...). 99 Application Server Process (ASP) - A process instance of an Application 100 Server. Examples of Application Server Processes are primary or backup 101 MGC instances. 103 Application Server Process Path (ASP Path or just Path) - A Path to a 104 remote Application Server Process instance. A Path maps 1:1 to an SCTP 105 association 107 Application Server Cluster (ASC) - A group of one or more Application 108 Servers represented to the SS7 network by the same SS7 Point Code. An 109 SG cannot send MTP Level 3 management messages relating to the 110 availability/congestion status of an SS7 destination in the IP domain 111 unless the status is true across all members of the Application Server 112 Cluster. 114 Association - An association refers to an SCTP association. The 115 association will provide the transport for the delivery of MTP3-User 116 protocol data units and M3UA adaptation layer peer messages. 118 Fail-over - The capability to re-route signaling traffic as required to 119 a next-preferred Application Server Process within an Application 120 Server in the event of failure or unavailability of the currently used 122 3 123 Application Server Process (e.g., from primary MGC to back-up MGC). 124 Fail-over may also apply upon the return to service of a previously 125 unavailable Application Server Process. 127 MTP3-User - Any protocol normally using the services of the SS7 MTP3 128 (e.g., ISUP, SCCP, TUP, etc.). 130 Stream - A stream refers to an SCTP stream. 132 1.3 Signaling Transport Architecture 134 The architecture that has been defined for SCN signaling transport 135 over IP uses multiple components, including an IP transport 136 protocol, a signaling common transport protocol and an adaptation 137 module to support the services expected by a particular SCN signaling 138 protocol from its underlying protocol layer. 140 In reference to the SIGTRAN framework architecture [xx], This document 141 defines an MTP3-User adaptation module that is suitable for the 142 transport of SS7 ISDN User Part (ISUP) and Signalling Connection 143 Control Part (SCCP) messages but could be used equally to transport 144 other SS7 MTP3-User Part messages such as, for example, TUP. Note: 145 SCCP-Users (e.g., INAP/TC or ISUP) are supported implicitly as SCCP 146 payload. 148 In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling 149 is transmitted and received over a standard SS7 network interface, 150 using the SS7 Message Transfer Part (MTP) to provide transport of 151 ISUP/SCCP signaling messages to and from an SS7 Signaling End Point 152 (SEP) or Signaling Transfer Point (STP). The SG then provides 153 interworking of transport functions with IP Signaling Transport, in 154 order to transfer the ISUP/SCCP signaling messages to and from the ASP 155 where the peer ISUP/SCCP protocol layer exists. Three general cases 156 are shown below to cover the routing options in the event of ISUP or 157 SCCP transport across the SG as shown below: 159 1.3.1 Case 1: ISUP transport 161 ****** SS7 ****** IP ****** 162 *SEP *-----------* SG *-----------*ASP * 163 ****** ****** ****** 165 +----+ +----+ 166 |ISUP| |ISUP| 167 +----+ +---------+ +----+ 168 |MTP | |MTP |M3UA| |M3UA| 169 |L3 | |L3 +----+ +----+ 170 |L2 | |L2 |SCTP| |SCTP| 171 |L1 | |L1 +----+ +----+ 172 | | | |UDP | |UDP | 173 +----+ +---------+ +----+ 175 SEP - SS7 Signaling End Point 176 SCTP - Simple Control Transport Protocol [5] 178 4 179 Note: The use of MTP Level 2 signaling links in the SS7 network is 180 shown as an example. ATM-based High Speed Links could also be used, 181 using MTP3/SSCF/SSCOP [3,4]. For that matter, it is possible that IP- 182 based links could present, using MTP3/M2UA/SCTP. Also, STPs may be 183 present in the SS7 path between the SEP and the SG. 185 To enable a seamless, or as seamless as possible, operation of the 186 MTP3-User peers in the SS7 and IP domains, the SG implements for 187 modeling purposes a nodal interworking function. The interworking 188 function purpose is to deliver MTP-TRANSFER indication primitives 189 received from the MTP Level 3 upper layer interface to an M3UA-resident 190 network address translation and mapping function for ongoing routing to 191 the final IP destination. This internal SG function also delivers MTP- 192 TRANSFER request primitives to the MTP Level 3 upper layer interface 193 from the M3UA network address translation and mapping function for 194 ongoing MTP Level 3 routing to the SS7 node. This nodal interworking 195 function is described for modeling purposes only - it is a nodal 196 implementation-dependent function that does not affect the peer 197 protocol exchanges. 199 1.3.2 Case 2: SCCP transport where an SCCP function at the SG is 200 invoked: 202 ****** SS7 ****** IP ******* 203 *SEP *-----------* SG *------------* ASP * 204 * or * * * * * 205 *STP * * * * * 206 ****** ****** ******* 208 +----+ +---------+ +-----+ 209 |SCCP| | SCCP | |SCCP | 210 +----+ +---------+ +-----+ 211 |MTP | |MTP |M3UA| |M3UA | 212 |L3 | |L3 +----+ +-----+ 213 |L2 | |L2 |SCTP| |SCTP | 214 |L1 | |L1 +----+ +-----+ 215 | | | |UDP | | UDP | 216 +----+ +---------+ +-----+ 218 Note: An SEP can be an SCP or SSP 220 In this case, the SCCP at the SG performs Global Title Translation 221 (GTT) for messages in either direction that do not yet have a final SS7 222 MTP Destination Point Code address (and possibly SCCP Subsystem). Use 223 of the SCCP at the SG will avoid a requirement for a GTT function 224 within the M3UA protocol. The SG nodal interworking function delivers 225 an MTP-TRANSFER indication primitive incoming from the SS7 network to 227 5 228 an M3UA-resident network address translation and mapping function for 229 ongoing routing to the final IP destination, but only after the SCCP 230 GTT has been performed and a new Destination Point Code (and possibly 231 Subsystem) have been determined. The M3UA network address translation 232 and mapping function then determines the final IP destination. It is 233 possible that the SCCP GTT result could be a non-final GTT result and 234 M3UA would then actually be determining an IP destination that will 235 perform the next GTT. 237 Similarly messages from the IP network can be addressed to the SG for 238 SCCP GTT. The SG nodal interworking function would deliver these MTP- 239 TRANSFER request primitives to the SCCP from M3UA. The SCCP GTT will 240 then determine an SS7 Destination Point Code (and possibly Subsystem) 241 before delivery into the SS7 network. It is possible that after SCCP 242 GTT the DPC (and possibly Subsystem) result could represent an IP-based 243 ASP and be sent by the nodal interworking function back to the M3UA- 244 resident network address translation and mapping function for ongoing 245 routing to an IP destination. 247 1.3.3 Case 3: SCCP transport where an SCCP function at the SG is not 248 invoked: 250 ****** SS7 ****** IP ******* 251 *SEP *-----------* SG *------------* ASP * 252 * or * * * * * 253 *STP * * * * * 254 ****** ****** ******* 256 +----+ +-----+ 257 |SCCP| |SCCP | 258 +----+ +---------+ +-----+ 259 |MTP | |MTP |M3UA| |M3UA | 260 |L3 | |L3 +----+ +-----+ 261 |L2 | |L2 |SCTP| |SCTP | 262 |L1 | |L1 +----+ +-----+ 263 | | | |UDP | | UDP | 264 +----+ +---------+ +-----+ 266 For this case, the SG nodal interworking function operates as in Case 267 1. 269 1.3.4 UDP Port 271 A request will be made to IANA to assign a UDP port for M3UA. 273 1.4 Services Provided by the M3UA Layer 275 1.4.1 Support for the transport of MTP3-User/MTP boundary primitives 277 6 278 The SS7 MTP Level 3 upper layer interface is retained at the ASP, so 279 the M3UA protocol layer is required to provide the equivalent set of 280 services to its users as provided by the MTP Level 3. 282 This includes the following services: 284 M3UA provides the ability to transfer MTP3-User messages (in this 285 Case, ISUP/SCCP PDUs) across SCTP associations. Note that M3UA does 286 not itself impose a 256 octet user information block limit as specified 287 by the MTP Level 3. Larger blocks can be accommodated directly by 288 M3UA/SCTP without the need for an upper layer segmentation/re-assembly 289 procedure such as in the ITU White Book SCCP [6] or ISUP segmentation 290 procedures. However, in the context of an SG the maximum 256 octet 291 block size must be followed when interworking to an SS7 network that 292 does not support the transfer of larger blocks to the final 293 destination. This will avoid ISUP or SCCP fragmentation at the SG. 294 However,if the SS7 network supports the Broadband MTP [7] the 295 block size limit can be increased past 256 octets. In the future, 296 M3UA/SCTP could be specified for use between two IP Nodes directly to 297 carry larger ISUP+ (BICC) [8] or MAP/TCAP [9] messages. 299 Provision is made for a seamless, or as seamless as possible, operation 300 of the MTP3-User peers in the SS7 and IP domains. This includes: 302 - Providing an indication to MTP3-Users at an ASP that a remote 303 MTP3-User peer in the SS7 network is not 304 reachable, as expected by all MTP3-User protocols. 306 - Providing an indication to MTP-Users at an ASP that a remote MTP3- 307 User peer in the SS7 network is now reachable, as expected by all MTP3- 308 User protocols. 310 - Providing an indication to MTP3-Users at an ASP that messages to a 311 remote MTP3- 312 User peer in the SS7 network are experiencing SS7 congestion or the 313 remote MTP3-User peer is unavailable, as expected by all MTP3-User 314 protocols. 316 1.4.2 Support for communication between Layer Management Modules on the 317 SG and ASP 319 An M-ERROR primitive is used to indicate an error with a received M3UA 320 message (e.g., unknown parameter value). 322 ********* 323 Ed Note: This section is ffs 324 ********* 326 1.4.3 Support for management of SCTP associations and ASP Paths between 327 the SG and ASP 329 The M3UA layer at the SG keeps the state of all configured ASPs. A set 331 7 332 of primitives between the Layer Management and the M3UA layer are 333 defined below for the layer Management to manage the ASP Paths and the 334 traffic between the SG and the ASPs. 336 The M3UA layer can be instructed by the Layer Management to establish 337 an SCTP association to a peer M3UA node. This can be achieved using 338 the M-SCTP ESTABLISH primitive to request, indicate and confirm the 339 establishment of an SCTP association to a peer M3UA node. 341 The M3UA layer may also need to inform Layer Management of the status 342 of the underlying SCTP associations using the M-SCTP STATUS request and 343 indication primitive. For example, the M3UA may inform Layer Management 344 of the reason for the release of an SCTP association, determined either 345 locally within the M3UA layer or by a primitive from the SCTP. 347 Layer Management may inform the M3UA layer of a change in the local 348 M3UA User status (e.g., failure, available). Also the M3UA layer may 349 need to inform the Layer Management of the change in status of an ASP 350 or ASP Path. This can be achieved using the M-ASP STATUS primitive to 351 change and indicate the status of an ASP. 353 *** Ed Note: This will be moved to a procedures section***** 354 The M3UA layer may be informed of a local M3UA-User failure by means of 355 an indication from local Layer Management. In response, a peer 356 protocol is invoked with the remote M3UA layer to stop traffic over the 357 SCTP association until recovery of the local M3UA-Users. When the 358 M3UA-User layer recovers, local Layer Management informs the M3UA layer 359 and a message is sent to the remote M3UA layer indicating traffic can 360 be restarted over the SCTP association. The M3UA layer maintains 361 status of the local M3UA-User availability. 362 *********************************************** 364 1.5 Internal Functions Provided in the M3UA Layer 366 1.5.1 Address Translation and Mapping 368 The M3UA layer maps primitives received from the ASP-User lower layer 369 boundary, or SG nodal interworking function, to the SCTP reliable 370 transport upper layer boundary and maps signals received from the SCTP 371 to the ASP MTP3-User lower layer boundary, or SG nodal interworking 372 function. For example, the MTP-TRANSFER request primitive received 373 from an MTP3-User is mapped to an SCTP Send primitive and the SCTP 374 Receive primitive is mapped to an MTP-TRANSFER indication primitive 375 to the MTP3-User. 377 To support this mapping, the M3UA layer at the SG must additionally 378 maintain a network address translation table of incoming SS7 379 address/routing information keys to Application Servers. The 380 Application Server represents an ordered list of one or more possible 381 Application Server Processes. Normally, one of the ASPs in the ordered 382 list will be the active ASP for a particular routing key entry. Note 383 that in certain failure and transition cases it is possible that there 384 may not be an active ASP. 386 8 387 This table is required in order to route the SS7 ISUP/SCCP messages 388 incoming from the SS7 network domain to the appropriate ASP in the IP 389 network domain. This mapping is dynamic, taking into account the 390 availability status of the individual ASP Paths in the list, 391 configuration changes, and possible fail-over mechanisms. 393 Possible SS7 address/routing information to be considered as a routing 394 key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or 395 SCCP Called Party Address. The network address translation function in 396 effect defines the SS7 address representation of the Application 397 Servers within the IP domain. As such, the implementation of this 398 function must be flexible enough to handle the SS7 address vision of 399 network operator(s). For example, some network operators may choose to 400 represent the SG and Application Servers with a single SS7 point code. 401 Other operators may choose to represent each SG and Application Server 402 with individual SS7 point codes, or may group logical groups of 403 Application Servers under point codes. 405 From the perspective of the M3UA instance at an Application Server 406 Process, it is possible that the ASP could route signaling messages 407 destined to the SS7 network through more than one SG. A primary/back- 408 up case is possible where the unavailability of a the ASP Path to a 409 primary SG,or the unavailability of the SS7 destination node from the 410 primary SG, could be used to reroute to a next-preferred SG. Also, a 411 loadsharing case is possible where the signaling messages are load- 412 shared across two (or more) SGs. 414 1.5.2 SCTP Stream Mapping. M3UA also supports the assignment of 415 traffic into streams within an SCTP association. Traffic that requires 416 sequencing should be assigned to the same stream. For example, SS7 417 traffic may be assigned to individual streams based on the SLS value in 418 the MTP3 Routing Label or the ISUP CIC assignment, subject of course to 419 the maximum number of streams supported by the underlying SCTP 420 association. Traffic that does not require sequencing can be assigned 421 to an unsequenced stream. 423 1.5.3 Congestion Control. 425 The M3UA Layer is informed of local and IP network congestion by means 426 of an implementation-dependent function (e.g., an implementation- 427 dependent indication from the SCTP of IP network congestion). When an 428 SG determines that the transport of SS7 messages to an Application 429 Server Cluster is encountering congestion, the SG may optionally 430 trigger SS7 MTP3 Transfer Controlled management messages to originating 431 SS7 nodes. The triggering of SS7 MTP3 Management messages from an SG is 432 an implementation-dependent function. At an ASP, congestion is 433 indicated to local MTP3-Users by means of an MTP-Status primitive 434 indicating congestion, to invoke appropriate upper layer responses, as 435 per current MTP3 procedures. Congestion Control mechanisms are for 436 further study. 438 9 439 1.5.4 Seamless Network Management Interworking. 441 (Ed. Note: It is ffs if this function is modeled in the M3UA layer at 442 an SG or is part of an independent relay function at the SG that is a 443 user of the M3UA layer and MTP-3 layer.) 445 The SG must maintain knowledge of SS7 node and Application Server 446 Cluster status in their respective domains in order to perform as 447 seamless as possible interworking of the two domains. For example, SG 448 knowledge of the availability and/or congestion status of Application 449 Server Clusters and SS7 nodes must be maintained and disseminated in 450 the respective networks so that end-to-end operation is transparent to 451 the communicating SCN protocol peers at the SS7 node and ASP. 453 When an SG determines that the transport of SS7 messages to an 454 Application Server Cluster is encountering congestion, the SG may 455 optionally issue MTP Transfer Controlled (TFC) messages to the SS7 SEPs 456 which are generating signalling traffic to the affected Application 457 Server Cluster, as per current MTP procedures [2]. 459 When an SG determines that the transport of SS7 messages to an 460 Application Server Cluster is interrupted, the SG may optionally issue 461 MTP Transfer Prohibited (TFP) messages to the adjacent SS7 nodes which 462 are generating signalling traffic to the affected Application Server 463 Clusters per current MTP procedures [2]. 465 When an SG determines that the transport of SS7 messages to an 466 Application Server Cluster can now be resumed, the SG may optionally 467 issue MTP Transfer Allowed (TFA) messages to the adjacent SS7 nodes to 468 resume signalling traffic to the affected Application Server Clusters 469 per current MTP procedures [2]. 471 Triggering of the MTP-3 management messages is an implementation 472 dependent function. 474 1.5.5 Management Inhibit/Uninhibit 476 Local Management may wish to stop traffic across an SCTP association in 477 order to temporarily remove the association from service or to perform 478 testing and maintenance activity. The function could optionally be 479 used to manage the start of traffic on to a newly-available SCTP 480 association. 482 1.5.6 Active Association Control 484 An Application Server Process can have associated back-up process. 485 When, for example, both a primary and a back-up ASP are available, then 486 peer protocol is required to control which ASP, 487 and hence ASP Path, is currently active. The ordered list of ASPs 488 related to an Application Server is kept updated to reflect the active 489 Application Server Process instance. 491 10 492 1.6 Definition of M3UA Boundaries 494 1.6.1 Definition of the boundary between M3UA and an MTP3-User. 496 From ITU Q.701 [2]: 498 MTP-TRANSFER request 499 MTP-TRANSFER indication 500 MTP-PAUSE indication 501 MTP-RESUME indication 502 MTP-STATUS indication 504 1.6.2 Definition of the boundary between M3UA and SCTP 506 The upper layer primitives provided by the SCTP are provided in [5] 508 1.6.3 Definition of the Boundary between M3UA and the Layer Management 510 M-SCTP ESTABLISH 511 M-SCTP RELEASE 512 M-SCTP STATUS 513 M-ASP STATUS 514 M-ERROR 516 (Ed Note: more text to be added) 518 2.0 Protocol Elements 520 The general message format includes a Common Message Header together 521 with a list of zero or more parameters as defined by the Message Type. 522 For forward compatability, all Message Types may have attached 523 parameters even if none are specified in this version. 525 2.1 Common Message Header 527 The protocol messages for MTP3-User Adaptation require a message 528 structure which contains a version, message type, message length, and 529 message contents. This message header is common among all signaling 530 protocol adaptation layers: 532 0 7 8 15 16 31 533 +-------+-------+---------------+ 534 | Vers | Spare | Msg Type | 535 +-------+-------+---------------+ 536 | Message Length | 537 +---------------+---------------+ 539 2.1.1 M3UA Protocol Version 541 The version field (vers) contains the version of the M3UA adaptation 543 11 544 layer. The supported versions are: 546 01 Release 1.0 protocol 548 2.1.2 Message Types 550 The following list contains the message types for the defined messages. 552 ISUP/SCCP Tunneling (ITUN) Messages 554 Data Message 0101 556 SS7 Signalling Network Management (SSNM) Messages 558 Destination Unavailable (DUNA) 0201 559 Destination Available (DAVA) 0202 560 Destination State Audit (DAUD) 0203 561 SS7 Network Congestion State (SCON) 0204 562 Destination User Part Unavailable (DUPU) 0205 564 Application Server Process Maintenance (ASPM) messages 566 ASP Up 0301 567 ASP Down 0302 568 ASP Active 0401 569 ASP Inactive 0402 571 Management (MGMT) Messages 573 Error 0000 575 2.1.3 Message Length 577 The Message Length defines the length of the message in octets, not 578 including the header. 580 2.2 ITUN Messages 582 The following section describes the ITUN messages and parameter 583 contents. The general ITUN message format includes a Common Message 584 Header together with a list of zero or more parameters as defined by 585 the Message Type. All Message Types can have attached parameters. 587 2.2.1 Data Message 589 The Data message contains SS7 MTP3-User protocol data, which is an MTP- 590 TRANSFER primitive, normally including the complete MTP3 Routing Label. 591 The Data message contains the following parameters: 593 SCN PROTOCOL IDENTIFIER (Optional) 594 INTERFACE IDENTIFIER (Optional) 595 PROTOCOL DATA 597 12 598 The format for the Data Message parameters is as follows: 599 0 15 16 31 600 +---------------+---------------+ 601 | Tag (0xx) | Length | 602 +---------------+---------------+ 604 | SCN Protocol Identifier* | 606 +---------------+---------------+ 607 | Tag (0xx) | Length | 608 +---------------+---------------+ 610 | Interface Identifier* | 612 +-------------------------------+ 613 | Tag (0xx) | Length | 614 +---------------+---------------+ 615 ... 616 | Protocol Data | 617 ... 618 +---------------+---------------+ 620 The SCN Protocol Identifier parameter identifies explicitly the SCN 621 signaling protocol being transported, where the SCN protocol carried is 622 not known implicitly in the context of a particular association or 623 stream. The SCN Protocol Id defines the protocol type, variant, and 624 version, and thereby specifies the components and encoding of the 625 Protocol Data parameter. The SCN Protocol Id may also define what SCN 626 Protocol Data components are omitted in the Protocol Data (e.g., 627 whether or not the Protocol Data contains an MTP routing label). SCN 628 Protocol Ids will be maintained by IANA outside of this document and 629 may be registered on an "as needed" basis. The SCN Protocol ID is not 630 required in Data messages if the Protocol Id information is pre- 631 configured or identified at Association or Path establishment. 633 *********** 634 ED Note: The SCN Protocol Identifier parameter format is for further 635 study. The protocol identifier values should be maintained outside of 636 this document by IANA to allow registration of values without re- 637 issuing the adaptation layer protocol document. We need decision on 638 encoding of mime-type value or fixed string/integer. If mime-type need 639 to refer to "draft-ietf-sigtran-mime-isup.txt" for an example of an 640 application/ISUP media type defined according to the rules defined in 641 RFC 2048. 642 ************ 644 The Interface Identifier optionally identifies the physical interface, 645 or network, at the SG for which the signaling messages are 646 sent/received. The format is an ASCII string, the values of which are 647 assigned according to network operator policy. The interface Identifier 648 string should be padded to 32-bit boundaries. 650 13 651 ************** 652 Ed Note: The identification of the interface can be very useful at MGCs 653 that are receiving signaling from multiple national networks and cannot 654 rely on the SS7 NI value to tell their signalling traffic apart. 655 However, no procedures are specified. 656 ************** 658 The Protocol Data field contains the MTP3-User application message, 659 which is an MTP-TRANSFER primitive. As defined for a specific value of 660 the Protocol Identifier, this will include the MTP-User Data and 661 normally includes the MTP Routing Label (SS7 OPC, DPC, SLS), and the 662 SIO (Network Indicator & optional Message Priority codes). 664 2.3.2 SS7 Signaling Network Management (SSNM) Messages 666 2.3.2.1 Destination Unavailable (DUNA) 668 The DUNA message is sent from the SG to the ASP to indicate that 669 the SG has determined that an SS7 destination is unreachable. The MTP- 670 User at the ASP is expected to stop traffic to the affected destination 671 through the SG initiating the DUNA. 673 The DUNA message contains the following parameters: 675 Protocol Identifier (Optional) 676 Affected Destination Point Code 677 Info String (Optional) 679 The format for DUNA parameter is as follows: 681 0 7 8 15 16 31 682 +---------------+---------------+ 683 | Tag (0xx) | Length | 684 +---------------+---------------+ 686 | Protocol Identifier* | 688 +---------------+---------------+ 689 | Tag (0xx) | Length | 690 +---------------+---------------+ 691 | Affected DPC | 692 +---------------+---------------+ 693 | Tag (0xx) | Length | 694 +---------------+---------------+ 696 | INFO String* | 698 +-------------------------------+ 700 The Protocol Identifier parameter is defined similarly to the SCN 702 14 703 Protocol Id but in this case defines the MTP3 version/variant. In this 704 context it defines the format of the Affected DPC parameter. By 705 identifying the MTP variant and version, the point code size (e.g., 14- 706 , 16-, or 24-bit) and sub-field definitions (e.g., ANSI 707 network/cluster/member, ITU-international zone/region/signal_point, 708 many national field variants, ...) can be determined. 710 The INFO String parameter can carry any meaningful 8-BIT ASCII 711 character string along with the message. Length of the INFO String 712 parameter is from 0 to 255 characters. No procedures are presently 713 identified for its use but the INFO String can be used by Operators to 714 identify in text form the location reflected by the Affected DPC for 715 debugging purposes. 717 The Affected DPC is provisionally a three-octet parameter to allow 14-, 718 16- and 24-bit binary formatted SS7 Point Codes. 720 2.3.2.2 Destination Available (DAVA) 722 The DAVA message is sent from the SG to the ASP to indicate that the SG 723 has determined that an SS7 destination is now reachable. The ASP MTP3- 724 User protocol is expected to resume traffic to the affected destination 725 through the SG initiating the DUNA. 727 The DAVA message contains the following parameters: 729 Protocol Identifier (Optional) 730 Affected Destination Point Code 731 Info String (Optional) 733 The parameter format and definitions for the DAVA message is the same 734 as for the DUNA message (See Section 2.3.2.2). 736 2.3.2.3 Destination State Audit (DAUD) 738 The DAUD message can be sent from the ASP to the SG to query the 739 availability state of the SS7 routes to an affected destination. A 740 DAUD is sent periodically after the ASP has received a DUNA, until a 741 DAVA is received. The DAUD can also be sent when an ASP recovers from 742 interruption of the transport path to the SG. 744 Protocol Identifier (Optional) 745 Affected Destination Point Code 746 Info String (Optional) 748 The format and description of DAUD parameters is the same as for the 749 DUVA message (See Section 2.3.2.1.) 751 *********** 752 Ed Note: It is for further study whether multiple Affected 753 Destination Point Codes can be included as a list in one DAUD message 754 and in responding DUVA messages. 755 *********** 757 15 758 The SG receiving the DAUD should reply with the availability state of 759 the queried destination in a DUNA or DAVA message. 761 2.3.2.4 SS7 Network Congestion (SCON) 763 The SCON message can be sent from the SG to the ASP to indicate that 764 the congestion level in the SS7 network to a specified destination has 765 changed. 767 The SCON message contains the following parameters: 769 Protocol Identifier (Optional) 770 Affected Destination Point Code 771 Info String (Optional) 772 Congestion Level (Optional) 774 0 7 8 15 16 31 775 +---------------+---------------+ 776 | Tag (0xx) | Length | 777 +---------------+---------------+ 779 | Protocol Identifier* | 781 +---------------+---------------+ 782 | Tag (0xx) | Length | 783 +---------------+---------------+ 784 | Affected DPC | 785 +---------------+---------------+ 786 | Tag (0xx) | Length | 787 +---------------+---------------+ 789 | INFO String* | 791 +-------------------------------+ 792 | Tag (0xx) | Length | 793 +---------------+---------------+ 794 | Congestion Level* | 795 +-------------------------------+ 797 The format and description of the Protocol Identifier, Affected DPC and 798 Info String parameters is the same as for the DUVA message (See Section 799 2.3.2.1.) 801 The valid values for the optional Congestion Level are shown in the 802 following table. 804 16 805 Define Value Description 806 Level 0 0000 No Congestion or Undefined 807 Level 1 0001 Congestion Level 1 808 Level 2 0002 Congestion Level 2 809 Level 3 0003 Congestion Level 3 811 The congestion levels are as defined in the national congestion method 812 in the ITU MTP recommendation [2] or in the ANSI MTP standard [10]. 813 For MTPs without congestion levels, for example the ITU international 814 method, the parameter is omitted. 816 The ASP receiving the SCON message is expected to follow the currently 817 defined MTP3-User protocol reaction to an indication of SS7 network 818 congestion. 820 2.3.2.5 Destination User Part Unavailable (DUPU) 822 The DUPU message is used by a SG to inform an ASP that a remote peer 823 MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. 825 The DUPU message contains the following parameters: 827 Protocol Identifier (Optional) 828 Affected Destination Point Code 829 Info String (Optional) 830 Reason 832 The format for optional DUPU message is as follows: 834 0 7 8 15 16 31 835 +---------------+---------------+ 836 | Tag (0xx) | Length | 837 +---------------+---------------+ 839 | Protocol Identifier* | 841 +---------------+---------------+ 842 | Tag (0xx) | Length | 843 +---------------+---------------+ 844 | Affected DPC | 845 +---------------+---------------+ 846 | Tag (0xx) | Length | 847 +---------------+---------------+ 849 | INFO String* | 851 +-------------------------------+ 852 | Tag (0xx) | Length | 853 +---------------+---------------+ 854 | Reason | 855 +-------------------------------+ 857 17 858 The format and description of the Protocol Identifier, Affected DPC and 859 Info String parameters is the same as for the DUVA message (See Section 860 2.3.2.1.) 862 The valid values for Reason are shown in the following table. 864 Define Value Description 865 UPU-Unknown 0x4 MTP User Part Unavailable, No Reason Given 866 UPU-Unequipped 0x5 MTP User Part Unavailable, Unequipped 867 UPU-Inaccessible 0x6 MTP User Part Unavailable, Inaccessible 869 The ASP receiving the DUPU message is expected to follow the currently 870 defined MTP3-User protocol reaction to an indication of remote user 871 part unavailabilty. 873 2.3.3 Application Server Process Maintenance (ASPM) Messages 875 2.3.3.1 ASP Up (ASPUP) 877 The ASP-UP message is used to indicate to a remote M3UA peer that the 878 Adaptation layer is ready to receive traffic or maintenance messages. 880 The ASPUP message contains the following parameters: 882 Adaptation Layer Identifer (optional) 883 SCN Protocol Identifier (optional) 884 INFO String (optional) 886 The format for the ASPUP message is as follows: 888 0 15 16 31 889 +---------------+---------------+ 890 | Tag (0x2) | Length | 891 +---------------+---------------+ 893 | Adaptation Layer Identifier* | 895 +---------------+---------------+ 896 | Tag (0x3) | Length | 897 +---------------+---------------+ 899 | Protocol Identifier* | 901 +---------------+---------------+ 902 | Tag (0x4) | Length | 903 +---------------+---------------+ 905 | INFO String* | 907 +---------------+---------------+ 909 18 910 The format and description of the optional Protocol Identifier and Info 911 String parameters is the same as for the DUVA message (See Section 912 2.3.2.1.) 914 The optional Adaptation Layer Identifier is a string that identifies 915 the adaptation layer. This string must be set to "M3UA" which results 916 in a length of 4. The ALI would normally only be used in the initial 917 ASP Up message across a new SCTP association to ensure both peers are 918 assuming the same adaptation layer protocol. 920 Note: Strings are padded to 32-bit boundaries. The length field 921 indicates the end of the string. 923 2.3.3.2 ASP Down (ASPDN) 925 The ASP-DN message is used to indicate to a remote M3UA peer that the 926 adaptation layer is not ready to receive traffic or maintenance 927 messages. 929 The ASPDN message contains the following parameters: 931 INFO String (Optional) 933 The format for the ASPDN message is as follows: 935 0 15 16 31 936 +---------------+---------------+ 937 | Tag (0x4) | Length | 938 +---------------+---------------+ 940 | INFO String* | 942 +---------------+---------------+ 944 **************** 945 Ed Note: Need to add a reason code parameter. Reasons could be failure 946 or management inhibit. 947 **************** 949 2.3.3.3 ASP Active (ASPAC) 951 The ASPAC message is sent by an ASP to indicate to an SG that it is 952 the active ASP to be used from within a list of primary and back-up 953 ASPs for a particular AS. 955 The ASPAC message contains the following parameters: 957 INFO String (Optional) 959 The format for the ASPAC message is as follows: 961 19 962 0 15 16 31 963 +---------------+---------------+ 964 | Tag (0x4) | Length | 965 +---------------+---------------+ 967 | INFO String* | 969 +---------------+---------------+ 971 2.3.3.4 ASP Inactive (ASPIA) 973 The ASPIA message is sent by an ASP to indicate to an SG that it is 974 no longer the the active ASP to be used from within a list of primary 975 and back-up ASP for a particular AS. The SG will respond with an ASPIA 976 message and either discard incoming messages or buffer for a timed 977 period and then discard. 979 The ASPIA message contains the following parameters: 981 INFO String (Optional) 983 The format for the ASPIA message is as follows: 985 0 15 16 31 986 +---------------+---------------+ 987 | Tag (0x4) | Length | 988 +---------------+---------------+ 990 | INFO String* | 992 +---------------+---------------+ 994 2.3.4 Management Messages 996 2.3.4.1 Error (ERR) 998 The ERR message is sent when an invalid value is found in an incoming 999 message. 1001 The ERR message contains the following parameters: 1003 Error Code 1005 The format for the ERR message is as follows: 1007 0 7 8 15 16 31 1008 +---------------+---------------+ 1009 | Error Code | 1010 +---------------+---------------+ 1012 20 1013 The Error Code can be one of the following values: 1015 Invalid Version 0x1 1016 Invalid Interface Identifier 0x2 1017 Invalid SCN Version 0x3 1018 Invalid Adaptation Layer Identifier 0x4 1019 Invalid Stream Identifier 0x5 1020 Invalid Message Type 0x6 1022 3.0 Procedures 1024 The M3UA layer needs to respond to various local primitives it receives 1025 from other layers as well as the messages that it receives from the 1026 peer M3UA layers. This section describes the M3UA procedures in 1027 response to these events. 1029 3.1 Procedures to support the M3UA services in Section 1.4.1 1031 These procedures support the M3UA transport of MTP3-User/MTP3 boundary 1032 primitives. 1034 3.1.1 Receipt of Local primitives 1036 On receiving a primitive from the upper layer, the M3UA layer will 1037 send the corresponding ITUN or SSNM message (see Section 2) to its 1038 peer. The M3UA layer must fill in various fields of the common and 1039 specific headers correctly. In addition the message needs to be sent 1040 on the appropriate SCTP stream. 1042 3.1.2 Receipt of ITUN or SSNM Messages from the Peer M3UA 1044 On receiving ITUN or SSNM messages from the remote M3UA Peer, the M3UA 1045 layer invokes the appropriate primitive indications to the M3UA-User 1047 3.2 Procedures to support the M3UA services in Section 1.4.2 1049 3.2.1 Layer Management primitives procedures 1051 On receiving these primitives from the local layer management, the M3UA 1052 layer will send the corresponding management message (Error) to its 1053 peer. The M3UA layer must fill in the various fields of the common and 1054 specific headers correctly. 1056 3.2.2 Receipt of Peer Management messages 1058 Upon receipt of Management messages, the M3UA layer must invoke the 1059 corresponding Layer Management primitive indications (M-ERROR ind.) to 1060 the local layer management. 1062 3.3 Procedures to support the M3UA services in Section 1.4.3 1064 21 1065 These procedures support the M3UA management of SCTP Associations and 1066 ASP Paths between SGs and ASPs 1068 3.3.1 State Maintenance 1070 The M3UA layer on the SG needs to maintain the state of each ASP as 1071 well as the state of the related ASs. 1073 3.3.1.1 ASP States 1075 The state of each ASP is maintained in the M3UA layer in the SG. The 1076 state of an ASP changes due to events. The events include: 1078 * Reception of messages from peer M3UA layer 1079 * Reception of indications from the SCTP layer 1081 The ASP state transition diagram is shown in Figure 4. The possible 1082 states of an ASP are: 1084 ASP-DOWN: The Application Server Process is unavailable. Initially all 1085 ASPs will be in this state. 1087 ASP-UP: The Application Server Process is available but application 1088 traffic is stopped. 1090 ASP-ACTIVE: The Application Server Process is available and application 1091 traffic is active. At most one ASP per AS can be in the active state. 1093 Figure 4: ASP State Transition Diagram 1095 +-------------+ 1096 |-------->| | 1097 | | ASP-ACTIVE | 1098 | +-------------+ 1099 | ^ | 1100 | ASP | | ASP 1101 | Active | | Inactive 1102 | | v 1103 | +-------------+ 1104 ASP Down / | | | 1105 SCTP CDI | | ASP-UP | 1106 | +-------------+ 1107 | ^ | 1108 | ASP | | ASP Down / 1109 | Up | | SCTP CDI 1110 | | v 1111 | +-------------+ 1112 | | | 1113 |-------->| | 1114 | ASP-DOWN | 1115 +-------------+ 1117 22 1118 SCTP CDI: The local SCTP layer's Communication Down Indication to the 1119 Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this 1120 indication when it detects the loss of connectivity to the ASP's SCTP 1121 layer. 1123 3.3.1.2 AS States 1125 The state of the AS is maintained in the M3UA layer on the SG. 1127 The state of an AS changes due to events. These events include: 1129 * ASP state transitions 1130 * Recovery timer triggers 1132 The possible states of an AS are: 1134 AS-DOWN: The Application Server is unavailable. This state implies 1135 that all related ASPs are in the ASP-DOWN state for this AS. Initially 1136 the AS will be in this state. 1138 AS-UP: The Application Server is available but no application traffic 1139 is active (i.e., one or more related ASPs are in the ASP-UP state, but 1140 none in the ASP-Active state). 1142 AS-ACTIVE: The Application Server is available and application traffic 1143 is active. This state implies that one ASP is in the ASP-ACTIVE state. 1145 AS-PENDING: The Active ASP has transitioned from active to inactive or 1146 down. A recovery timer T(r) will be started and all incoming SCN 1147 messages will be queued by the SG. If an ASP becomes active before T(r) 1148 expires, the AS will move to AS-ACTIVE state and all the queued 1149 messages will be sent to the active ASP. 1151 If T(r) expires before an ASP becomes active, the SG stops queuing 1152 messages and discards all previously queued messages. The AS will move 1153 to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move 1154 to AS-DOWN state. 1156 23 1157 Figure 5: AS State Transition Diagram 1159 +----------+ one ASP trans ACTIVE +-------------+ 1160 | |------------------------>| | 1161 | AS-UP | | AS-ACTIVE | 1162 | | | | 1163 | |< -| | 1164 +----------+ \ / +-------------+ 1165 ^ | \ Tr Trigger / ^ | 1166 | | \ at least one / | | 1167 | | \ ASP in UP / | | 1168 | | \ / | | 1169 | | \ / | | 1170 | | \ /---/ | | 1171 one ASP | | \ / one ASP | | ACTIVE ASP 1172 trans | | all ASP \-/----\ trans to | | trans to UP or 1173 to UP | | trans to / \ ACTIVE | | DOWN 1174 | | DOWN / \ | | 1175 | | / \ | | 1176 | | / \ | | 1177 | | /all ASP \ | | 1178 | v / trans to \ | v 1179 +----------+ / DOWN \ +-------------+ 1180 | |<--/ -| | 1181 | AS-DOWN | | AS-PENDING | 1182 | | | (queueing) | 1183 | |<------------------------| | 1184 +----------+ Tr Trigger no ASP +-------------+ 1185 in UP state or 1187 Tr = Recovery Timer 1189 3.3.2 ASPM procedures for primitives 1191 Before the establishment of an SCTP association the ASP state at both 1192 the SG and ASP is assumed to be "Down". 1194 When the M3UA layer receives an M-SCTP ESTABLISH request primitive from 1195 the Layer Management, the M3UA layer will try to establish an SCTP 1196 association with the remote M3UA peer. Upon reception of an eventual 1197 SCTP-Communication Up confirm primitive from the SCTP, the M3UA layer 1198 will invoke the primitive M-SCTP ESTABLISH confirm to the Layer 1199 Management. 1201 Alternatively, if the remote M3UA-peer establishes the SCTP association 1202 first, the M3UA layer will receive an SCTP Communication Up indication 1203 primitive from the SCTP. The M3UA layer will then invoke the primitive 1204 M-SCTP ESTABLISH indication to the Layer Management. 1206 Once the SCTP association is established, The M3UA layer at an ASP will 1207 then find out the state of its local M3UA-user from the Layer 1208 Management using the primitive M-ASP STATUS. Based on the status of 1209 the local M3UA-User, the local ASP M3UA Application Server Process 1211 24 1212 Maintenance (ASPM) function will initiate the ASPM procedures, using 1213 the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to 1214 the SG - see Section 3.3.3. 1216 If the M3UA layer subsequently receives an SCTP-Communication Down 1217 indication from the underlying SCTP layer, it will inform the Layer 1218 Management by invoking the M-SCTP STATUS indication primitive. The 1219 state of the ASP will be moved to "Down" at both the SG and ASP. 1221 At an ASP, the Layer Management may try to reestablish the SCTP 1222 association using M-SCTP ESTABLISH request primitive. 1224 3.3.3 ASPM procedures for peer-to-peer messages 1226 3.3.3.1 ASP-Up 1228 The SG will mark the path as up if an explicit ASP UP (ASPUP) message is 1229 received and internally the path is allowed to come up (i.e., not in a 1230 locked local maintenance state). An ASP UP (ASPUP) message will be sent 1231 to acknowledge the received ASPUP. The SG will respond to a ASPUP with a 1232 ASPDN message if the path is in a locked maintenance state. 1234 The SG will send a ASPUP message in response to a received ASPUP message 1235 from the MGC even if that path was already marked as UP at the SG. 1237 The paths are controlled by the MGC. The SG will only send ASPUP in 1238 response to the reception of a ASPUP message. 1240 The MGC will send ASPUP messages every 2 (add text regarding this being 1241 a configurable timer) seconds until the path comes up (i.e. until it 1242 receives a ASPUP message from the SG for that path). The MGC may decide 1243 to reduce the frequency (say to every 5 seconds) if the an acknowledge- 1244 ment is not received after a few tries. 1246 The MGC should wait for the ASPUP message from the SG before transmitting 1247 ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will 1248 risk message loss. The ASPUP message received from the SG is not 1249 acknowledged by the MGC. 1251 3.3.3.2 ASP Down 1253 The SG will mark the ASP as down and send a ASPDN message to the MGC if 1254 one of the following events occur: 1256 - a ASP Down(ASPDN) message is received from the MGC, 1257 - the ASP is locked by local maintenance. 1259 The SG will also send a ASPDN message when the ASP is already down and 1260 a ASPDN) message is received from the MGC. 1262 The MGC will send ASPDN whenever it wants to take down a ASP. Since the 1263 ASPDN messages to the SG or the ASPDN responses from the SG can be lost 1265 25 1266 (for example, during a MGC node failover), the MGC can send ASPDN messages 1267 every 2 seconds until the path comes down (i.e. until it receives a ASPDN 1268 message from the SG for that path). 1270 3.3.3.3 ASP Version Control 1272 If a ASP Up message with an unknown version is received, the receiving 1273 end will respond with an Error message. This will indicate to the 1274 sender which version the receiving node supports. 1276 This is useful when protocol version upgrades are being performed. A 1277 node with the newer version should support the older versions used on 1278 other nodes it is communicating with. 1280 The version field in the Error message header associated will indicate the 1281 version supported by the node. 1283 3.3.3.4 ASP Active 1285 When a ASP Active (ASPAC) message is received, the SG will start routing 1286 to that ASP. Reception of a ASPAC message overrides any previous ASPAC 1287 messages and results in the ASP associated with the ASPAC message to 1288 become the newly active ASP. 1290 3.3.3.5 ASP Inactive 1292 When a ASPIA message is received, message transmission to that ASP ceases. 1293 The SG will either discard all incoming messages or start buffering the 1294 incoming messages for T(r)seconds after which messages will be discarded. 1296 If the ASP is down, all of the Paths that were supported by that ASP 1297 are, by default, down. 1299 4.0 Examples of M3UA Procedures 1301 4.1 Establishment of associations between an SG and an ASP 1303 An example of the message flows for establishing an active association 1304 between an SG and ASP is shown below. 1306 SG ASP1 1308 <----------- ASP Up 1309 ASP Up ----------> 1310 (ACK) 1311 <----------- ASP Active 1312 ASP Active ----------> 1313 (ACK) 1315 An example of message flows for establishment of associations with two 1316 ASPs and the message flows for take-over of the primary (ASP1) by the 1317 secondary (ASP2). 1319 26 1320 SG ASP1 ASP2 1322 <----------- ASP Up 1323 ASP Up ----------> 1324 (ACK) 1325 <------------------------------ ASP Up 1326 ASP Up ------------------------------> 1327 (ACK) 1328 <----------- ASP Active 1329 ASP Active ----------> 1330 (ACK) 1331 ... 1333 <----------- ASP Inactive 1334 ASP Inactive ----------> 1335 (ACK) 1337 (this message is optional) 1338 ASP Inactive ------------------------------> 1339 <------------------------------ ASP Active 1340 ASP Active ------------------------------> 1341 (ACK) 1343 4.2 M3UA/MTP3-User Boundary Examples 1345 ***************** 1346 Ed Note: Text to be added 1347 ***************** 1349 5.0 Security 1351 M3UA relies upon IPSEC to ensure confidentiality of user payload. Consult 1352 [RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. 1353 Atkinson, November 1998] for more information on configuring IPSEC 1354 services. 1356 6.0 Acknowledgements 1358 The authors would like to thank John Loughney for his valuable comments 1359 and suggestions. 1361 7.0 References 1363 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 1364 System No. 7 (SS7)' 1366 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 1367 (SS7) - Message Transfer Part (MTP)' 1369 [3] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - 1371 27 1372 Service Specific Coordination Function for signaling at the Network 1373 Node Interface (SSCF at NNI) 1375 [4] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - 1376 Service Specific Connection Oriented Protocol (SSCOP) 1378 [5] Simple Control Transport Protocol 1379 draft-ietf-sigtran-sctp-00.txt, Sept. 1999, Work in Progress 1381 [6] ITU-T Recommendation Q.711-714 'Signalling System No. 7 1382 (SS7) - Signaling Connection Control Part (SCCP)' 1384 [7] ITU-T Recommendation Q.2210 'B-ISDN MTP' 1386 [8] ITU-T Recommendation Q.xxxx 'ISUP BICC' 1388 [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 1389 (SS7) - Transaction Capabilities (TCAP) 1391 [10] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' 1393 5.0 Author's Addresses 1395 Lyndon Ong 1396 Nortel Networks 1397 4401 Great America Pkwy 1398 Santa Clara, CA, USA 95054 1399 long@nortelnetworks.com 1401 Greg Sidebottom 1402 Nortel Networks 1403 3685 Richmond Rd, 1404 Nepean, Ontario, Canada K2H 5B7 1405 gregside@nortelnetworks.com 1407 Guy Mousseau 1408 Nortel Networks 1409 3685 Richmond Rd 1410 Nepean, Ontario, Canada K2H 5B7 1412 Ian Rytina 1413 Ericsson Australia 1414 37/360 Elizabeth Street 1415 Melbourne, Victoria 3000, Australia 1416 ian.rytina@ericsson.com 1418 Hanns Juergen Schwarzbauer 1419 SIEMENS AG 1420 Hofmannstr. 5181359 1421 Munich, Germany 1422 HannsJuergen.Schwarzbauer@icn.siemens.de 1424 28 1425 Ken Morneault 1426 Cisco Systems Inc. 1427 13615 Dulles Technology Drive 1428 Herndon, VA, USA 20171 1429 EMail: kmorneau@cisco.com 1431 Malleswar Kalla 1432 Telcordia Technologies 1433 MCC 1J211R 1434 445 South Street 1435 Morristown, NJ, USA 07960 1436 EMail: kalla@research.telcordia.com 1438 This draft expires April 2000. 1440 29