idnits 2.17.1 draft-ietf-sigtran-m2ua-02.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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 31) being 379 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages 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 47 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 983 has weird spacing: '...and discards ...' -- 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 (December 1999) is 8898 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1635, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1641, 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' ** Downref: Normative reference to an Informational draft: draft-ietf-sigtran-framework-arch (ref. '4') == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-00 ** Downref: Normative reference to an Informational draft: draft-huitema-megaco-mgcp-v1 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Cisco Systems 3 Mallesh Kalla 4 Telcordia 5 Greg Sidebottom 6 Nortel Networks 7 Ram Dantu 8 Tom George 9 Alcatel 11 Expires in six months December 1999 13 SS7 MTP2-User Adaptation Layer 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC 2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as 'work in progress.' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To learn the current status of any Internet-Draft, please check the 36 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 37 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 38 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 Abstract 43 This Internet Draft defines a protocol for backhauling of SS7 MTP2 44 User signaling messages over IP using the Simple Control Transmission 45 Protocol (SCTP). One application of this protocol would be to use it 46 between a Signaling Gateway (SG) and Media Gateway Controller (MGC). 47 In this case, the Signaling Gateway would be acting as a Signaling 48 Link Terminal. Another application of this protocol would be to use 49 it between a SG and a SCP. In either application, it is assumed that 50 the SG receives SS7 signaling over a standard SS7 interface using the 51 SS7 Message Transfer Part (MTP) to provide transport. 53 TABLE OF CONTENTS 55 1. Introduction..............................................2 56 1.1 Scope..................................................2 57 1.2 Terminology............................................3 58 1.3 Signaling Transport Architecture.......................3 59 1.4 Services Provide by the M2UA Adaptation Layer..........4 60 1.5 Function Provided by the M2UA Layer....................6 61 1.6 Definition of the M2UA Boundaries......................7 62 2. Protocol Elements.........................................8 63 2.1 Common Message Header..................................8 64 2.2 M2UA Message Header....................................9 65 2.3 M2UA Messages.........................................10 66 3. Procedures...............................................17 67 3.1 Procedures to Support Service in Section 1.4.1........17 68 3.2 Procedures to Support Service in Section 1.4.2........17 69 3.3 Procedures to Support Service in Section 1.4.3........17 70 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......22 71 4.1 Establishment of associations between SG and MGC......22 72 examples 73 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........23 74 4.3 Layer Management Communication Examples................25 75 5. Security.................................................31 76 6. Acknowledgements.........................................31 77 7. References...............................................31 78 8. Author's Addresses.......................................32 80 1. Introduction 82 1.1 Scope 84 There is a need for SCN signaling protocol delivery from an Signaling 85 Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point 86 (IPSP). The delivery mechanism should meet the following criteria: 88 * Support for MTP Level 2 / MTP Level 3 interface boundary 89 * Support for communication between Layer Management modules on SG and 90 MGC 91 * Support for management of active associations between the SG and MGC 93 In other words, the Signaling Gateway will transport MTP Level 3 messages 94 to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). In the 95 case of delivery from an SG to an IPSP, the SG and IPSP function as 96 traditional SS7 nodes using the IP network as a new type of SS7 link. 97 This allows for full MTP Level 3 message handling and network management 98 capabilities. 100 1.2 Terminology 102 MTP2-User - A protocol that normally uses the services of MTP Level 2 103 (i.e. MTP3). 105 Interface - For the purposes of this document, an interface is a SS7 106 signaling link. 108 Association - An association refers to a SCTP association. The 109 association will provide the transport for the delivery of protocol 110 data units for one or more interfaces. 112 Stream - A stream refers to a SCTP stream. 114 Backhaul - Refers to the transport of signaling from the point of 115 interface for the associated data stream (i.e., SG function in the MGU) 116 back to the point of call processing (i.e., the MGCU), if this is not 117 local [4]. 119 Application Server (AS) - A logical entity serving a specific application 120 instance. An example of an Application Server is a MGC handling the 121 MTP Level 3 and call processing for SS7 links terminated by the Signaling 122 Gateways. Practically speaking, an AS is modeled at the SG as an ordered 123 list of one or more related Application Server Processes (e.g., primary, 124 secondary, tertiary, �). 126 Application Server Process (ASP) - A process instance of an Application 127 Server. Examples of Application Server Processes are primary or backup 128 MGC instances. 130 Application Server Process Path (ASP Path or just Path) - A Path to a 131 remote Application Server Process instance. A Path maps 1:1 to an SCTP 132 association. 134 Fail-over - The capability to re-route signaling traffic as required 135 to a next-preferred Application Server Process within an Application 136 Server in the event of failure or unavailability of the currently used 137 Application Server Process (e.g., from primary MGC to back-up MGC). 138 Fail-over may also apply upon the return to service of a previously 139 unavailable Application Server Process. 141 Signaling Link Terminal (SLT) - Refers to the means of performing all 142 of the functions defined at MTP level 2 regardless of their 143 implementation [2]. 145 1.3 Signaling Transport Architecture 147 The architecture that has been defined [4] for SCN signaling transport 148 over IP uses multiple components, including an IP transport 149 protocol, a signaling common transport protocol (SCTP) and an adaptation 150 module to support the functions expected by a particular SCN signaling 151 protocol from its underlying protocol layer. 153 In reference to the SIGTRAN framework architecture [4], this document 154 defines a SCN adaptation module that is suitable for the transport of 155 SS7 MTP2 User. The only SS7 MTP2 User is MTP3. 157 1.3.1 Case 1: SG to MGC 159 In a Signaling Gateway, it is expected that the SS7 signaling is 160 received over a standard SS7 network termination, using the SS7 Message 161 Transfer Part (MTP) to provide transport of SS7 signaling messages to 162 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 163 Point (STP). In other words, the SG acts as a Signaling Link Terminal 164 (SLT) [2]. The SG then provides interworking of transport functions 165 with IP Signaling Transport, in order to transport the MTP3 signaling 166 messages to the MGC where the peer MTP3 protocol layer exists, as shown 167 below: 169 ****** SS7 ****** IP ******* 170 *SEP *-----------* SG *-------------* MGC * 171 ****** ****** ******* 173 +----+ 174 |S7UP| 175 +----+ 176 +----+ |MTP | 177 |S7UP| |L3 | 178 +----+ +----+----+ +----+ 179 |MTP | |MTP |M2UA| |M2UA| 180 |L3 | | +----+ +----+ 181 |L2 | |L2 |SCTP| |SCTP| 182 |L1 | |L1 +----+ +----+ 183 | | | |UDP | |UDP | 184 +----+ +---------+ +----+ 186 SEP - SS7 Signaling Endpoint 187 UDP - User Datagram Protocol 188 SCTP - Simple Control Transmission Protocol 189 (Refer to Reference [5]) 191 Figure 1: M2UA in the SG to MGC Application 193 Note: STPs may be present in the SS7 path between the SEP and the SG. 195 1.3.2 Case 2: SG to IPSP 197 The following figure shows the seamless interworking at the MTP3 198 layer. MTP3 is adapted to the SCTP layer using MTP2 User Adaptation 199 Layer (M2UA). In this example, the Signaling Gateway could be an STP. 200 All the primitives between MTP3 and MTP2 are supported by M2UA. Any 201 of the nodes in the diagram could have SCCP or other SS7 user parts. 203 ****** SS7 ****** IP ************ 204 *SEP *-------* SG *-------------* IPSP * 205 ****** ****** ************ 207 +----+ +---------+ 208 |TCAP| | TCAP | 209 +----+ +---------+ 210 |SCCP| | SCCP | 211 +----+ +---------+ +---------+ 212 |MTP | | MTP | | MTP | 213 |L3 | | L3 | | L3 | 214 |L2 | +----+----+ +----+----+ 215 |L1 | |MTP |M2UA| |M2UA|MTP | 216 | | |L2 +----+ +----+L2 | 217 | | |L1 |SCTP| |SCTP|L1 | 218 | | | |----| |----| | 219 | | | |UDP | |UDP | | 220 +----+ +----+----+ +----+----+ 222 SEP - SS7 Signaling Endpoint 223 IPSP - IP Signaling Point 224 UDP - User Datagram Protocol 225 SCTP - Simple Control Transmission Protocol 226 (Refer to Reference [5]) 228 Figure 2: M2UA in the SG to IPSP Application 230 In this case, the SCTP association acts as an SS7 link between the SG 231 and the IPSP. The association contains two streams, one in each 232 direction. The IPSP may or may not have a termination to the SS7 233 network. 235 1.3.3 UDP port 237 A request will be made to IANA to assign a UDP port for M2UA. 239 1.4 Services Provided by the M2UA Adaptation Layer 241 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 242 point in the IP network, so that the M2UA protocol layer is required to 243 provide the equivalent set of services to its users as provided by the 244 MTP Level 2 to MTP Level 3. 246 This includes the following services: 248 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 250 Also provision is made for protocol elements that enable a seamless, or 251 as seamless as possible, operation of the MTP2-User peers in the SS7 and 252 IP domains. This includes 254 Data 256 Provides the ability to transport MTP2 User information (in this case, 257 MTP Level 3 PDUs). 259 Link Establish 261 Provides the ability to request MTP Level 2 to bring SS7 links 262 in-service. 264 Link Release 266 Provides the ability to request MTP Level 2 to take SS7 links out-of- 267 service. Also, provides mechanism for MTP2 to autonomously indicate 268 that SS7 link(s) have gone out-of-service. 270 Link State 272 Provides the ability to request state change or information on a 273 per link basis. Some examples would be the forcing of Local Processor 274 Outage or flushing buffers. 276 Link Status 278 Provides a means for asychronous notification of link state changes to 279 be reported to the upper layer (MTP Level 3). An examples would be the 280 reporting of remote processor 281 outage event. 283 Data Retrieval 285 Provides a mechanism to perform SS7 link changeover procedure in 286 the case of a SS7 link failure. 288 1.4.2 Support for communication between Layer Management modules 289 on SG and MGC 291 It is envisioned that the M2UA layer needs to provide some messages that 292 will facilitate communication between Layer Management modules on the SG 293 and MGC. 295 To facilitate reporting of errors that arise because of backhauling MTP 296 Level 3 scenario, the following primitive is defined: 298 M-ERROR 300 The M-ERROR message is used to indicate an error with a received 301 M2UA message (e.g., interface identifier value is not known to the SG). 303 1.4.3 Support for management of active associations between SG and MGC 305 The M2UA layer on the SG keeps the state of various ASPs it is associated 306 with. A set of primitives between M2UA layer and the Layer Management 307 are defined below to help the Layer Management manage the association(s) 308 between the SG and the MGC. 310 M-SCTP ESTABLISH 312 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 313 the establishment of SCTP association to a peer M2UA node. 315 The M2UA layer may also need to inform the status of the SCTP 316 association(s) to the Layer Management. This can be achieved using 317 the following primitive. 319 M-SCTP STATUS 321 The M-SCTP STATUS primitive is used to request and indicate the status 322 of underlying SCTP association(s). 324 The Layer Management may need to inform the M2UA layer of a user status 325 (i.e., failure, active, etc.), so that messages can be exchanged between 326 M2UA layer peers to stop traffic to the local M2UA user. This can be 327 achieved using the following primitive. 329 M-ASP STATUS 331 The M-ASP STATUS primitive is used by the Layer Management to indicate 332 the status of the local M2UA user to the M2UA layer. 334 1.5 Functions Provided by the M2UA Layer 336 1.5.1 Mapping 338 The M2UA layer must maintain a map of a Interface ID to a physical 339 interface on the Signaling Gateway. A physical interface would be a 340 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 341 must also maintain a map of Interface ID to SCTP association and to a 342 stream within the association. 344 1.5.2 Status of ASPs 346 The M2UA layer on the Signaling Gateway must maintain the state of one or 347 more Application Server Process(es) it is associated with. The state of 348 an ASP changes because of reception of peer-to-peer messages or reception 349 of indications from the local SCTP association. ASP state transition 350 procedures are described in Section Section 3.3. 352 1.5.3 Flow Control / Congestion 354 It is possible for the M2UA layer to be informed of IP network congestion 355 by means of an implementation-dependent function (i.e. an indication 356 from the SCTP). If the M2UA layer receives this indication, the action(s) 357 taken are implementation dependent. 359 1.5.4 SCTP Stream Management 361 SCTP allows user specified number of streams to be opened during the 362 initialization. It is the responsibility of the M2UA layer to ensure 363 proper management of these streams. SCTP streams provide a means for 364 avoiding head of line blocking. For that reason, a stream will be used 365 per SS7 signaling link terminated by the Signaling Gateway. The SS7 366 signaling link can be identified by the optional Interface Identifier 367 in the M2UA specific message header (refer to Section 2.2). 369 1.5.5 Seamless SS7 Network Management Interworking 371 If the SG loses the SCTP association to the MGC, it should follow 372 MTP 2 processor outage procedures [2]. 374 1.5.6 Management Inhibit/Uninhibit 376 Local Management may wish to stop traffic across an SCTP association in 377 order to temporarily remove the association from service or to perform 378 testing and maintenance activity. The function could optionally be used 379 to manage the start of traffic on to a newly-available SCTP association. 381 1.6 Definition of the M2UA Boundaries 383 1.6.1 Definition of the M2UA / MTP Level 3 boundary 385 DATA 386 ESTABLISH 387 RELEASE 388 STATE 389 STATUS 390 RETRIEVAL 391 DATA RETRIEVAL 392 DATA RETRIEVAL COMPLETE 393 1.6.2 Definition of the M2UA / MTP Level 2 boundary 395 DATA 396 ESTABLISH 397 RELEASE 398 STATE 399 STATUS 400 RETRIEVAL 401 DATA RETRIEVAL 402 DATA RETRIEVAL COMPLETE 404 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 406 The upper layer and layer management primitives provided by SCTP are 407 provided in Reference [6] Section 9. 409 1.6.4 Definition of Layer Management / M2UA Boundary 411 M-ERROR 412 M-SCTP ESTABLISH 413 M-SCTP STATUS 414 M-ASP STATUS 416 2.0 Protocol Elements 418 This section describes the format of various messages used in this 419 protocol. 421 2.1 Common Message Header 423 The protocol messages for MTP2 User Adaptation require a message header 424 structure which contains a version, message type and message length. This 425 message header is common among all SCN adaptation layers. 427 0 7 8 15 16 31 428 +---------------+---------------+ 429 | Vers | Spare | Msg Type | 430 +---------------+---------------+ 431 | Message Length | 432 +-------------------------------+ 434 Figure 2 Common Message Header 436 2.1.1 Version 438 The version field (vers) contains the version of the M2UA adapation 439 layer. The supported versions are: 441 01 Release 1.0 of M2UA adaptation protocol 443 2.1.2 Message Type 445 The valid message types are defined in Section 2.2.2 and the message 446 contents are described in Section 2.3. Each message can contain 447 parameters. 449 The following list contains the message types for the defined messages. 451 MTP2 User Adaptatation (MAUP) Messages 453 Data Request 0601 454 Data Indication 0602 455 Establish Request 0603 456 Establish Confirm 0604 457 Release Request 0605 458 Release Confirm 0606 459 Release Indication 0607 460 State Request 0608 461 State Confirm 0609 462 State Indication 060a 463 Data Retrieval Request 060b 464 Data Retrieval Confirm 060c 465 Data Retrieval Indication 060d 466 Data Retrieval Complete Indication 060e 468 Application Server Process Maintenance (ASPM) Messages 470 ASP Up (ASPUP) 0301 471 ASP Down (ASPDN) 0302 472 ASP Active (ASPAC) 0401 473 ASP Inactive (ASPIA) 0402 475 Management (MGMT) Messages 477 Error 0001 479 2.1.3 Message Length 481 The Message length defines the length of the message in octets, not 482 including the header. 484 2.2 M2UA Message Header 486 In addition to the common message header, there will be a M2UA specific 487 message header. The M2UA specific message header will immediately 488 follow the common message header, but will only be used with MAUP and 489 MGMT messages. 491 This message header will contain the Interface Identifier. The Interface 492 Identifier identifies the physical interface at the SG for which the 493 signaling messages are sent/received. Or, the Interface Identifier 494 can be left empty (a null string of length zero). The Interface Identifier 495 follows the same endpoint naming scheme provided in MGCP [7]. For example, 496 if a Signaling Gateway terminates a E1 and the SS7 signaling link is one 497 timeslot 16, the interface identifier could be the following: 499 e1/16@sgw1.example.net 501 The use of wildcards is not acceptable. 503 Ed's Note: The Interface Identifier string should be padded to 32-bit 504 boundaries. The length field indicates the end of the string. 506 0 15 16 31 507 +---------------+---------------+ 508 | Tag (0x1) | Length | 509 +-------------------------------+ 511 | Interface Identifier | 513 +-------------------------------+ 515 Figure 3 M2UA Message Header 517 The Tag value for Interface Identifier is 0x1. The length provides the 518 length of the Interface Identifier string in bytes. 520 2.3 M2UA Messages 522 The following section defines the messages and parameter contents. The 523 M2UA messages will use the command header and the M2UA specific header. 525 2.3.1 MTP2 User Adaptation Messages 527 2.3.1.1 Data (Request, Indication) 529 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 530 Data message contains the protocol data. 532 The format for the Data Message parameters is as follows: 534 0 15 16 31 535 +-------------------------------+ 536 ... 537 | Protocol Data | 538 ... 539 +---------------+---------------+ 541 The Protocol Data field contains the MTP2-User application message. 543 2.3.1.2 Establish (Request, Confirmation) 545 The Establish Request message is used to establish the channel or to 546 indicate that the channel has been established. Note that the gateway 547 may already have the channel established at its layer. If so, upon 548 receipt of an Establish Request, the gateway takes no action except to 549 send an Establish Confirm. 551 0 15 16 31 552 +---------------+---------------+ 553 | State | 554 +---------------+---------------+ 556 The valid values for State are shown in the following table. 558 Define Value Description 559 ESTABLISH_NORMAL 0x0 Follow normal procedure for 560 establishing a SS7 link 561 ESTABLISH_EMERGENCY 0x1 Follow emergency procedure for 562 establishing a SS7 link 564 2.3.1.3 Release (Request, Indication, Confirmation) 566 This Release Request message is used to release the channel. The Release 567 Confirm and Indication messages are used to indicate that the channel has 568 been released. 570 0 15 16 31 571 +---------------+---------------+ 572 | Reason | 573 +---------------+---------------+ 575 The valid values for Reason are shown in the following table. 577 Define Value Description 578 RELEASE_MGMT 0x0 Management layer generated release. 579 RELEASE_PHYS 0x1 Physical layer alarm generated release. 580 RELEASE_SIOS 0x2 Receipt of SIOS 581 RELEASE_OTHER 0x3 Other reason SS7 link out-of-service 583 (should we keep it simple, or provide list of reasons that would 584 enable debugging) 586 2.3.1.4 State (Request, Confirm) 588 The State Request message can be sent from a MGC to cause an action 589 on a particular SS7 link supported by the Signaling Gateway. The 590 gateway sends a State Confirm to the MGC if the action has been success- 591 fully completed. The State Confirm reflects that state value received 592 in the State Request message. 594 0 15 16 31 595 +---------------+---------------+ 596 | State | 597 +---------------+---------------+ 599 The valid values for State are shown in the following table. 601 Define Value Description 602 STATUS_LOC_PROC_SET 0x0 Request local processor outage. 603 STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage 604 recovered. 605 STATUS_EMER_SET 0x2 Request emergency alignment 606 procedure. 607 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 608 emergency) procedure. 609 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. 610 STATUS_CONTINUE 0x5 Continue. 612 2.3.1.5 State Indication 614 The MTP2 State Indication message can be sent from a gateway to a call 615 agent to indicate a condition on a channel. 617 0 15 16 31 618 +---------------+---------------+ 619 | State | 620 +---------------+---------------+ 622 The valid values for State are shown in the following table. 624 Define Value Description 625 EVENT_ENTER_LPO 0x0 Entered local processor outage. 626 EVENT_EXIT_LPO 0x1 Exited local processor outage. 627 EVENT_ENTER_CONG 0x2 Entered a congested state. 628 EVENT_EXIT_CONG 0x3 Exited a congested state. 629 EVENT_PHYS_UP 0x4 Physical interface up. 630 EVENT_PHYS_DOWN 0x5 Physical interface down. 631 EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. 632 EVENT_REM_ENTER_CONG 0xc Remote entered congestion. 633 EVENT_REM_EXIT_CONG 0xd Remote exited congestion. 634 EVENT_REM_ENTER_PO 0xe Remote entered processor outage. 635 EVENT_REM_EXIT_PO 0xf Remote exited processor outage. 637 2.3.1.6 Retrieval (Request, Confirm) 639 The MTP2 Retrieval Request message is used during the MTP Level 3 640 changeover procedure to request the BSN, to retrieve PDUs from the 641 retransmit queue or to flush PDUs from the retransmit queue. 643 0 15 16 31 644 +---------------+---------------+ 645 | Action | 646 +---------------+---------------+ 647 | fsn_bsn | 648 +---------------+---------------+ 650 The valid values for Action are shown in the following table. 652 Define Value Description 653 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. 654 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 655 queue. 656 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. 658 In the Retrieval Request message, the fsn_bsn field contains the FSN of 659 the far end if the action is ACTION_RTRV_MSGS. 661 When the Signaling Gateway sends a Retrieval Confirm to this request, 662 it echos the action and puts the BSN in the fsn_bsn field if the action 663 was ACTION_RTRV_BSN. 665 2.3.1.7 Retrieval Indication 667 The Retrieval Indication message is sent by the Signaling Gateway 668 with a PDU from the retransmit queue. The Retrieval Indication 669 message does not contain the Action or fsn_bsn fields, just a PDU from 670 the retransmit queue. 672 0 15 16 31 673 +---------------+---------------+ 674 | | 676 . PDU from retransmit . 677 . queue . 679 | | 680 +---------------+---------------+ 682 2.3.1.8 Retrieval Complete Indication 684 The MTP2 Retrieval Complete Indication message is exactly the same as 685 the MTP2 Retrieval Indication message except that it also indicates that 686 it contains the last PDU from the retransmit queue. 688 2.3.2 Application Server Process Maintenance (ASPM) Messages 690 The ASPM messages will only use the common header. 692 2.3.2.1 ASP UP (ASPUP) 694 The ASPUP message is used to indicate to a remote M2UA peer that the 695 layer is ready to receive traffic or maintenance messages. 697 The ASPUP message contains the following parameters: 699 Adaptation Layer Identifer (optional) 700 SCN Protocol Identifier (optional) 702 The Adaptation Layer Identifier is a string that identifies the 703 adaptation layer. This string must be set to "M2UA" which means 704 the length will be 4. 706 The Protocol Identifier field contains the identity of the specific SCN 707 signaling protocol being transported. The Protocol ID defines the 708 protocol type, variant, and version, and thereby specifies the components 709 and encoding of the PROTOCOL DATA field. The Protocol Identifier also 710 defines what SCN protocol message components are included in the PROTOCOL 711 DATA. 713 (Ed. Note: Need encoding of mime-type value or OID or fixed 714 string/integer that will be administered outside of this document 715 (IANA). Also, perhaps bring in text from Christian's mime document - See 716 "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP 717 media type defined according to the rules defined in RFC 2048.?) 719 The format for the ASPUP message is as follows: 721 0 15 16 31 722 +---------------+---------------+ 723 | Tag (0x2) | Length | 724 +---------------+---------------+ 726 | Adaptation Layer Identifier | 728 +---------------+---------------+ 729 | Tag (0x3) | Length | 730 +---------------+---------------+ 732 | Protocol Identifier | 734 +---------------+---------------+ 735 | Tag (0x4) | Length | 736 +---------------+---------------+ 738 | INFO String | 740 +---------------+---------------+ 742 Note: Strings are padded to 32-bit boundaries. The length field 743 indicates the end of the string. 745 2.3.2.2 ASP Down (ASPDN) 747 The ASPDN message is used to indicate to a remote M2UA peer that the 748 layer is not ready to receive traffic or maintenance messages. 750 The ASPDN message contains the following parameters: 752 INFO String 754 The format for the ASPDN message is as follows: 756 0 15 16 31 757 +---------------+---------------+ 758 | Tag (0x4) | Length | 759 +---------------+---------------+ 761 | INFO String | 763 +---------------+---------------+ 765 ##### 766 We discussed adding a reason code. Reason could be failure or 767 management inhibit. 768 ##### 770 2.3.2.3 ASP Active (ASPAC) 772 The ASPAC message is sent by an ASP to indicate to an SG that it is 773 the active ASP to be used from within a list of primary and back-up ASPs 774 for a particular signaling mapping relationship. 776 The ASPAC message contains the following parameters: 778 Controlled/Forced flag (C/F flag) 779 INFO String 781 The format for the ASPAC message is as follows: 783 0 15 16 31 784 +---------------+---------------+ 785 | C/F flag | 786 +---------------+---------------+ 787 | Tag (0x4) | Length | 788 +---------------+---------------+ 790 | INFO String | 792 +---------------+---------------+ 794 The valid values for C/F flag are shown in the following table. 796 Define Value Description 797 FORCED 0x0 Force sending of all messages to ASP 798 CONTROLLED 0x1 Only send "new work" to ASP 800 2.3.2.4 ASP Inactive (ASPIA) 802 The ASPIA message is sent by an ASP to indicate to an SG that it is 803 no longer the the active ASP to be used from within a list of primary 804 and back-up ASP for a particular signaling mapping relationship. The 805 SG will respond with an ASPIA message and either buffer or discard 806 incoming messages for a timed period and then discard. 808 The ASPIA message contains the following parameters: 810 INFO String 812 The format for the ASPIA message is as follows: 814 0 15 16 31 815 +---------------+---------------+ 816 | Tag (0x4) | Length | 817 +---------------+---------------+ 819 | INFO String | 821 +---------------+---------------+ 823 2.3.3 Layer Management (MGMT) Messages 825 2.3.3.1 Error (ERR) 827 The ERR message is sent when an invalid value is found in an incoming 828 messages. 830 The ERR message contains the following parameters: 832 Error Code 834 The format for the ERR message is as follows: 836 0 7 8 15 16 31 837 +---------------+---------------+ 838 | Error Code | 839 +---------------+---------------+ 841 The Error Code can be one of the following values: 843 Invalid Version 0x1 844 Invalid Interface Identifier 0x2 845 Invalid SCN Version 0x3 846 Invalid Adaptation Layer Identifier 0x4 847 Invalid Stream Identifier 0x5 848 Invalid Message Type 0x6 850 3.0 Procedures 852 The M2UA layers needs to respond to various primitives it receives from 853 other layers as well as messages it receives from the peer-to-peer 854 messages. This section describes various procedures involved in 855 response to these events. 857 3.1 Procedures to Support Service in Section 1.4.1 859 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 860 MTP Level 3 boundary" service. 862 3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 864 On receiving a primitives from the local layer, the M2UA layer will 865 send the corresponding MAUP message (see Section 2) to its peer. The 866 M2UA layer must fill in various fields of the common and specific headers 867 correctly. In addition the message needs to be sent on the SCTP stream 868 that corresponds to the SS7 link. 870 3.1.2 MAUP Message Procedures 872 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 873 SG or MGC needs to invoke the corresponding layer primitives to the 874 local MTP Level 2 or MTP Level 3 layer. 876 3.2 Procedures to Support Service in Section 1.4.2 878 These procedures achieve the IUA layer's "Support for Communication 879 between Layer Managements" service. 881 3.2.1 Layer Management Primitives Procedure 883 On receiving these primitives from the local layer, the M2UA layer will 884 send the corresponding MGMT message (Error) to its peer. The M2UA layer 885 must fill in the various fields of the common and specific headers 886 correctly. 888 3.2.2 MGMT message procedures 890 Upon receipt of MGMT messages the M2UA layer must invoke the corresponding 891 Layer Management primitives (M-ERROR) to the local layer management. 893 3.3 Procedures to Support Service in Section 1.4.3 895 These procedures achieve the M2UA layer's "Support for management of 896 active associations between SG and MGC" service. 898 3.3.1 State Maintenance 900 3.3.1.1 ASP States 902 The state of the each ASP is maintained in the M2UA layer on the SG. The 903 state of an ASP changes due to events. The events include: 905 * Reception messages from peer M2UA layer 906 * Reception of indications from layers below 908 The ASP state transition diagram is shown in Figure 4. The possible states 909 of an ASP are: 911 ASP-DOWN: Application Server Process is unavailable. Initially all ASPs 912 are in this state. 914 ASP-UP: Application Server Process is available but application traffic is 915 stopped. 917 ASP-ACTIVE: Application Server Process is available and application traffic 918 is active. At most one ASP per AS can be in the active state. 920 Figure 4: ASP State Transition Diagram 922 +-------------+ 923 |-------->| | 924 | | ASP-ACTIVE | 925 | | | 926 | | | 927 | +-------------+ 928 | ^ | 929 | ASP | | ASP 930 | Active | | Inactive 931 | | v 932 | +-------------+ 933 | | | 934 ASP Down / | | | 935 SCTP CDI | | ASP-UP | 936 | | | 937 | | | 938 | +-------------+ 939 | ^ | 940 | ASP | | ASP Down / 941 | Up | | SCTP CDI 942 | | v 943 | +-------------+ 944 | | | 945 |-------->| | 946 | ASP-DOWN | 947 | | 948 | | 949 +-------------+ 951 SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer 952 Protocol (M2UA) on an SG. SCTP will send this indication when it 953 detects the loss of connectivity to ASP's SCTP layer. 955 3.3.1.2 AS States 957 The state of the AS is maintained in the ITUN layer on the SG. The 958 state of an AS changes due to events. These events include: 960 * ASP state transitions 961 * Recovery timer triggers 963 The possible states of an AS are: 965 AS-DOWN: Application Server is unavailable. This state implies that all 966 ASPs are in the ASP-DOWN state for this AS. 968 AS-UP: One or more ASPs are in the ASP-UP state. 970 AS-ACTIVE: Application Server is available and application traffic is 971 active. This state implies that one ASP is in the ASP-ACTIVE state. 973 AS-PENDING: Currently Active ASP became inactive or SCTP association with 974 it is lost. A Recovery timer will be started and in coming SCN messages 975 will be queuedby the SG. If an ASP becomes Active before the recovery 976 timer (Tr) expires, the AS will move to AS-ACTIVE state and all the 977 queued messages will be sent to the active ASP. If the recovery timer 978 expires before an ASP becomes active, SG stops queuing messages and 979 discards all queued messages. AS will move to AS-UP if at least one 980 ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. 982 If Tr expires before an ASP becomes active, the SG stops queuing messages 983 and discards all previously queued messages. The AS will move to AS-UP if 984 at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. 986 Ed's Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN 987 states, the Layer Management on MG may take appropriate SCN 988 notification actions. 990 +----------+ one ASP trans ACTIVE +-------------+ 991 | |------------------------>| | 992 | AS-UP | | AS-ACTIVE | 993 | | | | 994 | |< -| | 995 +----------+ \ / +-------------+ 996 ^ | \ Tr Trigger / ^ | 997 | | \ at least one / | | 998 | | \ ASP in UP / | | 999 | | \ / | | 1000 | | \ / | | 1001 | | \ /---/ | | 1002 one ASP | | \ / one ASP | | ACTIVE ASP 1003 trans | | all ASP \-/----\ trans | | trans to UP or 1004 to UP | | trans to / \ ACTIVE | | ACTIVE ASP 1005 | | DOWN / \ | | SCTP CDI 1006 | | / \ | | 1007 | | / \ | | 1008 | | /all ASP \ | | 1009 | v / trans to \ | v 1010 +----------+ / DOWN \ +-------------+ 1011 | |<--/ -| | 1012 | AS-DOWN | | AS-PENDING | 1013 | | | (queueing) | 1014 | |<------------------------| | 1015 +----------+ Tr Trigger no ASP +-------------+ 1016 in UP state or 1017 prev ACTIVE ASP trans 1018 to DOWN state 1020 Tr = Recovery Timer 1022 Figure 5: AS State Transition Diagram 1024 3.3.2 ASPM procedures for primitives 1026 Before the establishment of an SCTP association the ASP state at both the 1027 SG and ASP is assumed to be "Down". 1029 When the M2UA layer receives an M-SCTP ESTABLISH request primitive from 1030 the Layer Management, the M2UA layer will try to establish an SCTP 1031 association with the remote M2UA peer. Upon reception of an eventual 1032 SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer 1033 will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. 1035 Alternatively, if the remote M2UA-peer establishes the SCTP association 1036 first, the M2UA layer will receive an SCTP Communication Up indication 1037 primitive from the SCTP. The M2UA layer will then invoke the primitive 1038 M-SCTP ESTABLISH indication to the Layer Management. 1040 Once the SCTP association is established, The M2UA layer at an ASP will 1041 then find out the state of its local M2UA-user from the Layer Management 1042 using the primitive M-ASP STATUS. Based on the status of the local 1043 M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM) 1044 function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/ 1045 -Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. 1047 If the M2UA layer subsequently receives an SCTP-Communication Down 1048 indication from the underlying SCTP layer, it will inform the Layer 1049 Management by invoking the M-SCTP STATUS indication primitive. The state 1050 of the ASP will be moved to "Down" at both the SG and ASP. 1052 At an ASP, the Layer Management may try to reestablish the SCTP association 1053 using M-SCTP ESTABLISH request primitive. 1055 3.3.3 ASPM procedures for peer-to-peer messages 1057 3.3.3.1 ASP UP 1059 The SG will mark the path as up if an explicit ASP UP (ASPUP) message is 1060 received and internally the path is allowed to come up (i.e., not in a 1061 locked local maintenance state). An ASP UP (ASPUP) message will be sent 1062 to acknowledge the received ASPUP. The SG will respond to a ASPUP with a 1063 ASPDN message if the path is in a locked maintenance state. 1065 The SG will send a ASPUP message in response to a received ASPUP message 1066 from the MGC even if that path was already marked as UP at the SG. 1068 The paths are controlled by the MGC. The SG will only send ASPUP in 1069 response to the reception of a ASPUP message. 1071 The MGC will send ASPUP messages every 2 (add text regarding this being 1072 a configurable timer) seconds until the path comes up (i.e. until it 1073 receives a ASPUP message from the SG for that path). The MGC may decide 1074 to reduce the frequency (say to every 5 seconds) if the an acknowledge- 1075 ment is not received after a few tries. 1077 The MGC should wait for the ASPUP message from the SG before transmitting 1078 ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will 1079 risk message loss. The ASPUP message received from the SG is not 1080 acknowledged by the MGC. 1082 3.3.3.2 ASP Down 1084 The SG will mark the ASP as down and send a ASPDN message to the MGC if 1085 one of the following events occur: 1087 - a ASP Down(ASPDN) message is received from the MGC, 1088 - the ASP is locked by local maintenance. 1090 The SG will also send a ASPDN message when the ASP is already down and 1091 a ASPDN) message is received from the MGC. 1093 The MGC will send ASPDN whenever it wants to take down a ASP. Since the 1094 ASPDN messages to the SG or the ASPDN responses from the SG can be lost 1095 (for example, during a MGC node failover), the MGC can send ASPDN messages 1096 every 2 seconds until the path comes down (i.e. until it receives a ASPDN 1097 message from the SG for that path). 1099 3.3.4 ASP Version Control 1101 If a ASP Up message with an unknown version is received, the receiving 1102 end will respond with an Error message. This will indicate to the 1103 sender which version the receiving node supports. 1105 This is useful when protocol version upgrades are being performed. A 1106 node with the newer version should support the older versions used on 1107 other nodes it is communicating with. 1109 The version field in the Error message header associated with the will 1110 indicate the version supported by the node. 1112 3.3.5 ASP Inactive 1114 When a ASPIA message is received, message transmission to that ASP ceases. 1115 The SG will either discard all incoming messages or start buffering the 1116 incoming messages for N seconds after which messages will be discarded. 1118 If the ASP is down, all of the Paths that were supported by that ASP 1119 are, by default, down. 1121 3.3.6 ASP Active 1123 When a ASP Active (ASPAC) message is received, the SG will start routing 1124 to that ASP. Reception of a ASPAC message overrides any previous ASPAC 1125 messages and results in the ASP associated with the ASPAC message to 1126 become the newly active ASP. 1128 4.0 Examples of MTP2 User Adaptation (M2UA) Procedures 1130 4.1 Establishment of associations between SG and MGC examples 1132 An example of the message flows for establishing active associations between 1133 SG and MGC is shown below. 1135 SG ASP1 1137 <----------- ASP Up 1138 ASP Up ----------> 1139 (ACK) 1140 <----------- ASP Active 1141 ASP Active ----------> 1142 (ACK) 1144 An example of message flows for establishment of associations with two 1145 ASPs and the message flows for take-over of the primary (ASP1) by the 1146 secondary (ASP2). 1148 SG ASP1 ASP2 1150 <----------- ASP Up 1151 ASP Up ----------> 1152 (ACK) 1153 <------------------------------ ASP Up 1154 ASP Up ------------------------------> 1155 (ACK) 1156 <----------- ASP Active 1157 ASP Active ----------> 1158 (ACK) 1159 ... 1161 <----------- ASP Inactive 1162 ASP Inactive ----------> 1163 (ACK) 1165 (this message is optional) 1166 ASP Inactive ------------------------------> 1167 <------------------------------ ASP Active 1168 ASP Active ------------------------------> 1169 (ACK) 1171 An example of message flows for establishment of associations with two 1172 ASPs and the message flows for controlled take-over of the primary (ASP1) 1173 by the secondary (ASP2). In this case, the SG sends new work to ASP2. 1175 SG ASP1 ASP2 1177 <----------- ASP Up 1178 ASP Up ----------> 1179 (ACK) 1180 <------------------------------ ASP Up 1181 ASP Up ------------------------------> 1182 (ACK) 1183 <----------- ASP Active 1184 ASP Active ----------> 1185 (ACK) 1186 ... 1188 <------------------------------ ASP Active 1189 (New Work) 1190 ASP Active ------------------------------> 1191 (ACK) 1193 <----------- ASP Inactive 1194 ASP Inactive ----------> 1195 (ACK) 1197 4.2 Case 1: SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 1199 4.2.1 SS7 Link Alignment 1201 The MGC can request that a SS7 link be brought into alignment using the 1202 normal or emergency procedure. An example of the message flow to bring 1203 a SS7 link in-service using the normal alignment procedure is shown 1204 below. 1206 SG MGC 1208 <----------- Establish Request (ESTABLISH_NORMAL) 1209 Establish Response ----------> 1211 An example of the message flow to bring a SS7 link in-service using the 1212 emergency alignment procedure. 1214 SG MGC 1216 <----------- Establish Request (ESTABLISH_EMER) 1217 Establish Response ----------> 1218 4.2.2 SS7 Link Release 1220 The MGC can request that a SS7 link be taken out-of-service. It uses 1221 the Release Request message as shown below. 1223 SG MGC 1225 <------------ Release Request (RELEASE_MGMT) 1226 Release Response ------------> 1228 The SG can autonomously indicate that a SS7 link has gone out-of-service 1229 as shown below. 1231 SG MGC 1233 Release Indication ------------> 1234 (RELEASE_PHYS) 1236 4.2.3 Set and Clear Local Processor Outage 1238 to be added 1240 4.2.4 Notification of Processor Outage (local or remote) 1242 to be added 1244 4.2.5 Flush Buffers or Continue 1246 to be added 1248 4.2.6 SS7 Link Changeover 1250 An example of the message flow for a changeover is shown below. 1252 SG MGC 1254 <---------- Retrieval Request (MTP2_RTRV_BSN) 1255 Retrieval Confirm ----------> 1256 (with BSN) 1257 <---------- Retrieval Request (MTP2_RTRV_MSGS 1258 with FSN) 1259 Retrieval Confirm ----------> 1261 Retrieval Ind -----------> 1262 Retrieval Ind -----------> 1263 Rtrvl Complete Ind ----------> 1265 Note: The number of Retrieval Indication is dependent on the number of 1266 messages in the retransmit queue that have been requested. Only one 1267 Retrieval Complete Indication should be sent. 1269 4.3 Case 2: SG to IPSP, MTP Level 2 to MTP Level 3 Boundary Procedures 1271 In general, messages passed between MTP3 and M2UA are the same as 1272 those passed between MTP3 and MTP2. M2UA interprets messages from MTP3 1273 and sends the appropriate message to SCTP. Likewise, messages from 1274 SCTP are used to generate a meaningful message to MTP3. 1276 4.3.1 Link Initialization (Alignment) 1278 The MTP3 layer can request that an SS7 link be brought into alignment 1279 using the normal or emergency procedure. An example of the message 1280 flow to bring an SS7 link in-service is shown below. 1282 There are two alignment procedures normal alignment and emergency 1283 alignment. During normal alignment, communication to the other end is 1284 tested for a period of time to make sure that the communication link 1285 satisfies the performance requirements of the application. The 1286 examples are RTT and packet loss. Normal alignment is used when there 1287 are other links available to the same destination. Emergency alignment 1288 is used when there are no other links to the same destination. During 1289 emergency, the link is not tested for a long period of time. Instead, 1290 an indication from the SCTP layer is used to bring the link in 1291 service. 1293 The procedure for beginning an Association is described in the SCTP 1294 standard [5]. 1296 MTP3 M2UA SCTP SCTP M2UA MTP3 1297 ---- ---- ---- ---- ---- ---- 1299 Power On 1300 ------------> 1302 Out of Service 1303 <------------ 1305 Emergency OR 1306 Emergency Ceases 1307 ------------> 1309 Start 1310 ------------> 1312 Associate 1313 ------------> 1315 (SCTP Association 1316 procedure) 1318 Communication Up Communication Up 1319 <------------ ------------> 1321 Indication Indication 1322 (Link In Service) (Link In Service) 1323 <------------ ------------> 1325 For the Emergency Ceases case, proving begins at this time. See the 1326 section on Link Proving below. 1328 4.3.2 Link Proving 1330 One function of the adaptation layer is to make sure that the link 1331 meets the performance requirements of the application. This is 1332 usually done by proving the link. For example, for proving the link, 1333 we need the adaptation layer to issue an heartbeat/RTT to its peer. 1334 This is done before declaring link is in service to its application. 1335 For this purpose, the existing "status" command is used. Note how the 1336 link meets performance requirements is implementation dependent. 1337 Also, the proving period can be configurable. 1339 Proving is done by both ends of the link. To simplify the diagram, 1340 proving is shown on one end only. 1342 In the following diagram the Link has just completed the alignment 1343 procedure. 1345 The Status primitive is sent to determine if the Heartbeats were 1346 delivered successfully within the desired time period. 1348 MTP3 M2UA SCTP SCTP M2UA MTP3 1349 ---- ---- ---- ---- ---- ---- 1351 Request Heartbeat 1352 ------------> 1353 (Heartbeat sent 1354 and acknowledged) 1355 Request Heartbeat 1356 ------------> 1357 (Heartbeat sent 1358 and acknowledged) 1360 Request Heartbeat 1361 ------------> 1362 (Heartbeat sent 1363 and acknowledged) 1365 Heartbeats are sent for M seconds (Note A). 1367 Status 1368 ------------> 1370 Indication 1371 (Link In Service) (After checking that link is sane) 1372 <------------ 1374 Note A M is implementation-dependent. 1376 4.3.3 Message Transmission and Reception 1378 Messages are transmitted using the Data Request primitive from MTP3 to 1379 M2UA. The diagram shows the case where the Link is In Service. The 1380 message is passed from MTP3 of the source to MTP3 of the destination. 1382 MTP3 M2UA SCTP SCTP M2UA MTP3 1383 ---- ---- ---- ---- ---- ---- 1385 Request 1386 (Message for 1387 transmission) 1388 ------------> 1390 Send 1391 ------------> 1393 (SCTP sends message) 1395 Receive 1396 ------------> 1398 Indication 1399 (Received message) 1400 ------------> 1402 4.3.4 Link Status Indication 1404 The M2UA layer sends an indication that the Link is In Service or Out 1405 of Service after receiving a Communication indication from the SCTP 1406 layer. In either case, MTP3 responds in its usual way. 1408 MTP3 M2UA SCTP SCTP M2UA MTP3 1409 ---- ---- ---- ---- ---- ---- 1411 Communication Up 1412 <------------ 1414 (If Emergency Ceases, 1415 Link proving is done 1416 by M2UA now.) 1418 Indication 1419 (Link In Service) 1420 <------------ 1422 MTP3 M2UA SCTP SCTP M2UA MTP3 1423 ---- ---- ---- ---- ---- ---- 1425 Communication Lost 1426 <------------ 1428 Indication 1429 (Link Out of Service) 1430 <------------ 1432 4.3.5 Congestion Notification to Upper layer 1434 MTP3 layer expects notification of the link congestion. For example, 1435 this is accomplished by two messages 1) Link Congestion Onset 2) Link 1436 Congestion Abated. Congestion is assumed if M2UA layer notices 1437 repeated failures to send requests to SCTP (this is implementation 1438 dependent and it is assumed that the SEND Failure has an error code 1439 "life time expired"). Subsequently M2UA can start polling status of 1440 SCTP. If all the messages are successfully transmitted over a period 1441 of time (implementation dependent) then it is assumed that the 1442 congestion is abated. If the congestion condition should continue, 1443 the link will be taken out of service. In this case, it is possible 1444 to start the link changeover procedure. 1446 The US National version of SS7 has congestion levels. For US National 1447 SS7, the Indication primitive for Congestion Onset should report the 1448 congestion level. 1450 In the example below, M2UA has sent a message to SCTP. 1452 MTP3 M2UA SCTP SCTP M2UA MTP3 1453 ---- ---- ---- ---- ---- ---- 1455 Send Failure 1456 <------------ 1457 Send Failure 1458 <------------ 1460 Send Failure 1461 <------------ 1462 "N" consecutive fails - 1463 implementation specific 1465 Indication 1466 (Congestion Onset) 1467 <------------ 1469 Status 1470 ------------> 1471 Status 1472 ------------> 1474 Status 1475 ------------> 1476 polled for certain time until 1477 congestion ceases - 1478 implementation specific 1480 Indication 1481 (Congestion Abatement) 1482 <------------ 1484 4.3.6 Link Deactivation 1486 The MTP3 can request that a SS7-IP link be taken out-of-service. It 1487 uses the Release Request message as shown below. 1489 MTP3 M2UA SCTP SCTP M2UA MTP3 1490 ---- ---- ---- ---- ---- ---- 1492 Request 1493 (Deactivate Link) 1494 ------------> 1496 Terminate 1497 ------------> 1499 Terminate Successful 1500 <------------ 1502 Communication Lost 1503 <------------ 1505 Indication 1506 (Link Out of Service) 1507 <------------ 1509 4.3.7 Link Changeover 1511 The objective of the changeover is to ensure that signaling traffic 1512 carried by the unavailable signaling link is diverted to the 1513 alternative signaling link as quickly as possible while avoiding 1514 message loss, duplication, or mis-sequencing. For this purpose, the 1515 changeover procedure includes data retrieval, which is performed 1516 before reopening the alternative signaling links to the diverted 1517 traffic. Data retrieval consists of identifying all those messages in 1518 the retransmission buffer of the unavailable signaling link which have 1519 not been received by the far end. Retrieval includes transferring the 1520 concerned messages to the transmission buffers of the alternative 1521 links. In order to support changeover, the SCTP SSN must be used in 1522 place of the FSN/BSN of SS7. 1524 Stream Sequence Numbers used by SCTP (Signaling Control Transport 1525 Protocol) are sixteen bits long. MTP2's forward and backward sequence 1526 numbers are only seven bits long. Hence it is necessary to modify 1527 MTP3 to accomodate the larger SSNs. Reference [7] can be used as a guide 1528 for the MTP3 changes. 1530 For data retrieval, MTP3 requests Backward Sequence Number (BSN) from 1531 M2UA. This is the sequence number of the last message received by the 1532 local end. During normal period, SCTP delivers ordered messages to 1533 the application. However, during congestion or failure condition, the 1534 sequence numbers of the acknowledged messages can have gaps. In 1535 particular, the SACK (selective acknowledgement message) message can 1536 have several of these gaps. Hence, it is important to scan through 1537 these gaps and find the sequence number before first gap. This is the 1538 number from which the remote end has to transmit the messages. So, 1539 this is the number considered as the Backward Sequence Number and 1540 communicated to the remote end. In a similar way, the remote end also 1541 detects the BSN and indicates to local end. As soon as the MTP3 of the 1542 local end receives this BSN, MTP3 retrieves all the unacknowledged 1543 messages starting from BSN. This is accomplished through "Retrieve 1544 FSN" message. After all the messages are sent from M2UA to MTP3, a 1545 retrieval complete message is sent. 1547 Note that the sequence numbers and messages requested by MTP3 are sent 1548 from SCTP to M2UA in the Communication Lost primitive. 1550 MTP3 M2UA SCTP SCTP M2UA MTP3 1551 ---- ---- ---- ---- ---- ---- 1553 Communication Lost 1554 <------------ 1556 Indication 1557 (Link Out of Service) 1558 <------------ 1560 Request 1561 (Retrieve BSN) 1562 ------------> 1564 (M2UA locates 1565 first gap in 1566 received messages) 1568 Indication 1569 (Indicate BSN) 1570 <------------ 1572 Request - COO (BSN) on another link 1573 ------------------------------------------------------------> 1575 Request 1576 (Retrieve BSN) 1577 <------------ 1579 Indication 1580 (Indicate BSN) 1581 ------------> 1583 Request - COA (BSN) 1584 <------------------------------------------------------------ 1586 Request 1587 (Retrieve FSN) 1588 ------------> 1590 (M2UA locates 1591 first gap in 1592 acknowledgements) 1594 Indication 1595 (FSB Not retrievable) (in case) 1596 <------------ 1598 Indication 1599 (Retrieved Message) 1600 <------------ 1602 Indication 1603 (Retrieved Message) 1604 <------------ 1606 Indication 1607 (Retrieval Complete) 1608 <------------ 1610 Send messages on another link. 1612 4.4 Layer Management Communication Examples 1614 An example of the message flows for communication between Layer Manage- 1615 ment modules between SG and MGC is shown below. An active association 1616 between MGC and SG is established (section 4.1) prior to the following 1617 message flows. 1619 SG MGC 1621 <----------- Establish Request 1622 Error ----------> 1623 (Invalid Interface Id) 1624 5.0 Security 1626 SCN adaptation layers rely on SCTP to provide security. 1628 6.0 Acknowledgements 1630 The authors would like to thank Ian Rytina for his valuable comments and 1631 suggestions. 1633 7.0 References 1635 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 1636 System No. 7 (SS7)' 1638 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 1639 Message Transfer Part (MTP)' 1641 [3] Bellcore GR-246-CORE 'Bell Communications Research Specification 1642 of Signaling System Number 7', Volume 1, December 1995 1644 [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- 1645 framework-arch-03.txt, June 1999 1647 [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, 1648 August 1999 1650 [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- 1651 v1-03.txt, August 1999 1653 [7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 1654 functions and messages using the services of ITU-T 1655 Recommendation Q.2140' 1657 8.0 Author's Addresses 1659 Ken Morneault Tel: +1-703-484-3323 1660 Cisco Systems Inc. EMail: kmorneau@cisco.com 1661 13615 Dulles Technology Drive 1662 Herndon, VA. 20171 1663 USA 1665 Malleswar Kalla Tel: +1-973-829-5212 1666 Telcordia Technologies EMail: kalla@research.telcordia.com 1667 MCC 1J211R 1668 445 South Street 1669 Morristown, NJ 07960 1670 USA 1672 Greg Sidebottom Tel: +1-613-763-7305 1673 Nortel Networks EMail: gregside@nortelnetworks.com 1674 3685 Richmond Rd, 1675 Nepean, Ontario 1676 Canada K2H5B7 1678 Ram Dantu, Ph.D. Tel: +1-972-477-8446 1679 Alcatel USA EMail: ram.dantu@usa.alcatel.com 1680 1000 Coit Road 1681 Plano, TX 74075 1683 Tom George Tel: +1-972-519-3168 1684 Alcatel USA EMail: tom.george@usa.alcatel.com 1685 1000 Coit Road 1686 Plano, TX 74075 1688 This Internet Draft expires June 2000.