idnits 2.17.1 draft-ietf-sigtran-m2ua-01.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 24) being 84 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 59 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 977 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 (October 1999) is 8959 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) == Missing Reference: '7' is mentioned on line 491, but not defined == Unused Reference: '1' is defined on line 1563, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1569, 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') Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 6 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 Alcatel 10 Expires in six months October 1999 12 SS7 MTP2-User Adaptation Layer 13 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC 2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as 'work in progress.' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 To learn the current status of any Internet-Draft, please check the 35 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 36 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 37 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 38 ftp.isi.edu (US West Coast). 40 Abstract 42 This Internet Draft defines a protocol for backhauling of SS7 MTP2 43 User signaling messages over IP using the Simple Control Transmission 44 Protocol (SCTP). One application of this protocol would be to use it 45 between a Signaling Gateway (SG) and Media Gateway Controller (MGC). 46 In this case, the Signaling Gateway would be acting as a Signaling 47 Link Terminal. Another application of this protocol would be to use 48 it between a SG and a SCP. In either application, it is assumed that 49 the SG receives SS7 signaling over a standard SS7 interface using the 50 SS7 Message Transfer Part (MTP) to provide transport. 52 TABLE OF CONTENTS 54 1. Introduction..............................................2 55 1.1 Scope..................................................2 56 1.2 Terminology............................................3 57 1.3 Signaling Transport Architecture.......................3 58 1.4 Services Provide by the M2UA Adaptation Layer..........4 59 1.5 Function Provided by the M2UA Layer....................6 60 1.6 Definition of the M2UA Boundaries......................7 61 2. Protocol Elements.........................................8 62 2.1 Common Message Header..................................8 63 2.2 M2UA Message Header....................................9 64 2.3 M2UA Messages.........................................10 65 3. Procedures...............................................17 66 3.1 Procedures to Support Service in Section 1.4.1........17 67 3.2 Procedures to Support Service in Section 1.4.2........17 68 3.3 Procedures to Support Service in Section 1.4.3........17 69 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......22 70 4.1 Establishment of associations between SG and MGC......22 71 examples 72 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........23 73 4.3 Layer Management Communication Examples................25 74 5. Security.................................................31 75 6. Acknowledgements.........................................31 76 7. References...............................................31 77 8. Author's Addresses.......................................32 79 1. Introduction 81 1.1 Scope 83 There is a need for SCN signaling protocol delivery from an Signaling 84 Gateway (SG) to a Media Gateway Controller (MGC) or Signaling Control 85 Point (SCP). The delivery mechanism should meet the following criteria: 87 * Support for MTP Level 2 / MTP Level 3 interface boundary 88 * Support for communication between Layer Management modules on SG and 89 MGC 90 * Support for management of active associations between the SG and MGC 92 In other words, the Signaling Gateway will transport MTP Level 3 messages 93 to a Media Gateway Controller (MGC) or Signaling Control Point (SCP). 95 1.2 Terminology 97 MTP2-User - A protocol that normally uses the services of MTP Level 2 98 (i.e. MTP3). 100 Interface - For the purposes of this document, an interface is a SS7 101 signaling link. 103 Association - An association refers to a SCTP association. The 104 association will provide the transport for the delivery of protocol 105 data units for one or more interfaces. 107 Stream - A stream refers to a SCTP stream. For the purposes of this 108 document, a stream will be mapped to a SS7 signaling link, or interface. 110 Backhaul - Refers to the transport of signaling from the point of 111 interface for the associated data stream (i.e., SG function in the MGU) 112 back to the point of call processing (i.e., the MGCU), if this is not 113 local [4]. 115 Application Server (AS) - A logical entity serving a specific application 116 instance. An example of an Application Server is a MGC handling the 117 MTP Level 3 and call processing for SS7 links terminated by the Signaling 118 Gateways. Practically speaking, an AS is modeled at the SG as an ordered 119 list of one or more related Application Server Processes (e.g., primary, 120 secondary, tertiary, �). 122 Application Server Process (ASP) - A process instance of an Application 123 Server. Examples of Application Server Processes are primary or backup 124 MGC instances. 126 Application Server Process Path (ASP Path or just Path) - A Path to a 127 remote Application Server Process instance. A Path maps 1:1 to an SCTP 128 association. 130 Fail-over - The capability to re-route signaling traffic as required 131 to a next-preferred Application Server Process within an Application 132 Server in the event of failure or unavailability of the currently used 133 Application Server Process (e.g., from primary MGC to back-up MGC). 134 Fail-over may also apply upon the return to service of a previously 135 unavailable Application Server Process. 137 Signaling Link Terminal (SLT) - Refers to the means of performing all 138 of the functions defined at MTP level 2 regardless of their 139 implementation [2]. 141 1.3 Signaling Transport Architecture 143 The architecture that has been defined for SCN signaling transport 144 over IP uses multiple components, including an IP transport 145 protocol, a signaling common transport protocol (SCTP) and an adaptation 146 module to support the functions expected by a particular SCN signaling 147 protocol from its underlying protocol layer. 149 In reference to the SIGTRAN framework architecture [4], this document 150 defines a SCN adaptation module that is suitable for the transport of 151 SS7 MTP2 User. The only SS7 MTP2 User is MTP3. 153 1.3.1 Case 1: SG to MGC 155 In a Signaling Gateway, it is expected that the SS7 signaling is 156 received over a standard SS7 network termination, using the SS7 Message 157 Transfer Part (MTP) to provide transport of SS7 signaling messages to 158 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 159 Point (STP). In other words, the SG acts as a Signaling Link Terminal 160 (SLT) [2]. The SG then provides interworking of transport functions 161 with IP Signaling Transport, in order to transport the MTP3 signaling 162 messages to the MGC where the peer MTP3 protocol layer exists, as shown 163 below: 165 ****** SS7 ****** IP ******* 166 *SEP *-----------* SG *-------------* MGC * 167 ****** ****** ******* 169 +----+ 170 |S7UP| 171 +----+ 172 +----+ |MTP | 173 |S7UP| |L3 | 174 +----+ +----+----+ +----+ 175 |MTP | |MTP |M2UA| |M2UA| 176 |L3 | | +----+ +----+ 177 |L2 | |L2 |SCTP| |SCTP| 178 |L1 | |L1 +----+ +----+ 179 | | | |UDP | |UDP | 180 +----+ +---------+ +----+ 182 SEP - SS7 Signaling Endpoint 183 UDP - User Datagram Protocol 184 SCTP - Simple Control Transmission Protocol 185 (Refer to Reference [5]) 187 Figure 1: M2UA in the SG to MGC Application 189 Note: STPs may be present in the SS7 path between the SEP and the SG. 191 1.3.2 Case 2: SG to IPSCP 193 The following figure shows the seamless interworking at MTP3 layer. 194 MTP3 is adapted to SCTP layer using MTP2 User Adaptation Layer. In this 195 example, the Signaling Gateway can be a STP. All the primitives between 196 MTP3 and MTP2 are supported using MTP2 User Adaptation Layer (MTP2UA). 197 In the following example, the Signaling Gateway could also have SCCP 198 layer for providing Gateway Screening functionality for the IPSCP. 200 ****** SS7 ****** IP ************ 201 *SEP *-------* SG *-------------* IPSCP * 202 ****** ****** ************ 204 +----+ +---------+ 205 |TCAP| | TCAP | 206 +----+ +---------+ 207 |SCCP| | SCCP | 208 +----+ +---------+ +---------+ 209 |MTP | | MTP | | MTP | 210 |L3 | | L3 | | L3 | 211 |L2 | +----+----+ +----+----+ 212 |L1 | |MTP |M2UA| |M2UA|MTP | 213 | | |L2 +----+ +----+L2 | 214 | | |L1 |SCTP| |SCTP|L1 | 215 | | | |----| |----| | 216 | | | |UDP | |UDP | | 217 +----+ +----+----+ +----+----+ 219 SEP - SS7 Signaling Endpoint 220 IPSCP - IP Signaling Control Point 221 UDP - User Datagram Protocol 222 SCTP - Simple Control Transmission Protocol 223 (Refer to Reference [5]) 225 Figure 2: M2UA in the SG to IPSCP Application 227 Note that in this case, the SCTP association acts as a SS7 link between 228 the SG and IPSCP. The IPSCP may or may not have a termination to the 229 SS7 network. 231 1.3.3 UDP port 233 A request will be made to IANA to assign a UDP port for M2UA. 235 1.4 Services Provided by the M2UA Adaptation Layer 237 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 238 point in the IP network, so that the M2UA protocol layer is required to 239 provide the equivalent set of services to its users as provided by the 240 MTP Level 2 to MTP Level 3. 242 This includes the following services: 244 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 246 Also provision is made for protocol elements that enable a seamless, or 247 as seamless as possible, operation of the MTP2-User peers in the SS7 and 248 IP domains. This includes 250 Data 252 Provides the ability to transport MTP2 User information (in this case, 253 MTP Level 3 PDUs). 255 Link Establish 257 Provides the ability to request MTP Level 2 to bring SS7 links 258 in-service. 260 Link Release 262 Provides the ability to request MTP Level 2 to take SS7 links out-of- 263 service. Also, provides mechanism for MTP2 to autonomously indicate 264 that SS7 link(s) have gone out-of-service. 266 Link State 268 Provides the ability to request state change or information on a 269 per link basis. Some examples would be the forcing of Local Processor 270 Outage or flushing buffers. 272 Link Status 274 Provides a means for asychronous notification of link state changes to 275 be reported to the upper layer (MTP Level 3). An examples would be the 276 reporting of remote processor 277 outage event. 279 Data Retrieval 281 Provides a mechanism to perform SS7 link changeover procedure in 282 the case of a SS7 link failure. 284 1.4.2 Support for communication between Layer Management modules 285 on SG and MGC 287 It is envisioned that the M2UA layer needs to provide some messages that 288 will facilitate communication between Layer Management modules on the SG 289 and MGC. 291 To facilitate reporting of errors that arise because of backhauling MTP 292 Level 3 scenario, the following primitive is defined: 294 M-ERROR 296 The M-ERROR message is used to indicate an error with a received 297 M2UA message (e.g., interface identifier value is not known to the SG). 299 1.4.3 Support for management of active associations between SG and MGC 301 The M2UA layer on the SG keeps the state of various ASPs it is associated 302 with. A set of primitives between M2UA layer and the Layer Management 303 are defined below to help the Layer Management manage the association(s) 304 between the SG and the MGC. 306 M-SCTP ESTABLISH 308 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 309 the establishment of SCTP association to a peer M2UA node. 311 The M2UA layer may also need to inform the status of the SCTP 312 association(s) to the Layer Management. This can be achieved using 313 the following primitive. 315 M-SCTP STATUS 317 The M-SCTP STATUS primitive is used to request and indicate the status 318 of underlying SCTP association(s). 320 The Layer Management may need to inform the M2UA layer of a user status 321 (i.e., failure, active, etc.), so that messages can be exchanged between 322 M2UA layer peers to stop traffic to the local M2UA user. This can be 323 achieved using the following primitive. 325 M-ASP STATUS 327 The M-ASP STATUS primitive is used by the Layer Management to indicate 328 the status of the local M2UA user to the M2UA layer. 330 1.5 Functions Provided by the M2UA Layer 332 1.5.1 Mapping 334 The M2UA layer must maintain a map of a Interface ID to a physical 335 interface on the Signaling Gateway. A physical interface would be a 336 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 337 must also maintain a map of Interface ID to SCTP association and to a 338 stream within the association. 340 1.5.2 Status of ASPs 342 The M2UA layer on the Signaling Gateway must maintain the state of one or 343 more Application Server Process(es) it is associated with. The state of 344 an ASP changes because of reception of peer-to-peer messages or reception 345 of indications from the local SCTP association. ASP state transition 346 procedures are described in Section Section 3.3. 348 1.5.3 Flow Control / Congestion 350 It is possible for the M2UA layer to be informed of IP network congestion 351 by means of an implementation-dependent function (i.e. an indication 352 from the SCTP). If the M2UA layer receives this indication, the action(s) 353 taken are implementation dependent. 355 1.5.4 SCTP Stream Management 357 SCTP allows user specified number of streams to be opened during the 358 initialization. It is the responsibility of the M2UA layer to ensure 359 proper management of these streams. SCTP streams provide a means for 360 avoiding head of line blocking. For that reason, a stream will be used 361 per SS7 signaling link terminated by the Signaling Gateway. The SS7 362 signaling link can be identified by the optional Interface Identifier 363 in the M2UA specific message header (refer to Section 2.2). 365 1.5.5 Seamless SS7 Network Management Interworking 367 If the SG loses the SCTP association to the MGC, it should follow 368 MTP 2 processor outage procedures [2]. 370 1.5.6 Management Inhibit/Uninhibit 372 Local Management may wish to stop traffic across an SCTP association in 373 order to temporarily remove the association from service or to perform 374 testing and maintenance activity. The function could optionally be used 375 to manage the start of traffic on to a newly-available SCTP association. 377 1.6 Definition of the M2UA Boundaries 379 1.6.1 Definition of the M2UA / MTP Level 3 boundary 381 DATA 382 ESTABLISH 383 RELEASE 384 STATE 385 STATUS 386 RETRIEVAL 387 DATA RETRIEVAL 388 DATA RETRIEVAL COMPLETE 389 1.6.2 Definition of the M2UA / MTP Level 2 boundary 391 DATA 392 ESTABLISH 393 RELEASE 394 STATE 395 STATUS 396 RETRIEVAL 397 DATA RETRIEVAL 398 DATA RETRIEVAL COMPLETE 400 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 402 The upper layer and layer management primitives provided by SCTP are 403 provided in Reference [6] Section 9. 405 1.6.4 Definition of Layer Management / M2UA Boundary 407 M-ERROR 408 M-SCTP ESTABLISH 409 M-SCTP STATUS 410 M-ASP STATUS 412 2.0 Protocol Elements 414 This section describes the format of various messages used in this 415 protocol. 417 2.1 Common Message Header 419 The protocol messages for MTP2 User Adaptation require a message header 420 structure which contains a version, message type and message length. 421 This message header is common among all SCN adaptation layers. 423 0 7 8 15 16 31 424 +---------------+---------------+ 425 | Vers | Spare | Msg Type | 426 +---------------+---------------+ 427 | Message Length | 428 +-------------------------------+ 430 Figure 2 Common Message Header 432 2.1.1 Version 434 The version field (vers) contains the version of the M2UA adapation 435 layer. The supported versions are: 437 01 Release 1.0 of M2UA adaptation protocol 439 2.1.2 Message Type 441 The valid message types are defined in Section 2.2.2 and the message 442 contents are described in Section 2.3. Each message can contain 443 parameters. 445 The following list contains the message types for the defined messages. 447 MTP2 User Adaptatation (MAUP) Messages 449 Data Request 0601 450 Data Indication 0602 451 Establish Request 0603 452 Establish Confirm 0604 453 Release Request 0605 454 Release Confirm 0606 455 Release Indication 0607 456 State Request 0608 457 State Confirm 0609 458 State Indication 060a 459 Data Retrieval Request 060b 460 Data Retrieval Confirm 060c 461 Data Retrieval Indication 060d 462 Data Retrieval Complete Indication 060e 464 Application Server Process Maintenance (ASPM) Messages 466 ASP Up (ASPUP) 0301 467 ASP Down (ASPDN) 0302 468 ASP Active (ASPAC) 0401 469 ASP Inactive (ASPIA) 0402 471 Management (MGMT) Messages 473 Error 0001 475 2.1.3 Message Length 477 The Message length defines the length of the message in octets, not 478 including the header. 480 2.2 M2UA Message Header 482 In addition to the common message header, there will be a M2UA specific 483 message header. The M2UA specific message header will immediately 484 follow the common message header, but will only be used with MAUP and 485 MGMT messages. 487 This message header will contain the Interface Identifier. The Interface 488 Identifier identifies the physical interface at the SG for which the 489 signaling messages are sent/received. Or, the Interface Identifier 490 can be left empty (a null string of length zero). The Interface Identifier 491 follows the same endpoint naming scheme provided in MGCP [7]. For example, 492 if a Signaling Gateway terminates a E1 and the SS7 signaling link is one 493 timeslot 16, the interface identifier could be the following: 495 e1/16@sgw1.example.net 497 The use of wildcards is not acceptable. 499 Note: The Interface Identifier string should be padded to 32-bit 500 boundaries. The length field indicates the end of the string. 502 0 15 16 31 503 +---------------+---------------+ 504 | Tag (0x1) | Length | 505 +-------------------------------+ 507 | Interface Identifier | 509 +-------------------------------+ 511 Figure 3 M2UA Message Header 513 The Tag value for Interface Identifier is 0x1. The length provides the 514 length of the Interface Identifier string in bytes. 516 2.3 M2UA Messages 518 The following section defines the messages and parameter contents. The 519 M2UA messages will use the command header and the M2UA specific header. 521 2.3.1 MTP2 User Adaptation Messages 523 2.3.1.1 Data (Request, Indication) 525 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 526 Data message contains the protocol data. 528 The format for the Data Message parameters is as follows: 530 0 15 16 31 531 +-------------------------------+ 532 ... 533 | Protocol Data | 534 ... 535 +---------------+---------------+ 537 The Protocol Data field contains the MTP2-User application message. 539 2.3.1.2 Establish (Request, Confirmation) 541 The Establish Request message is used to establish the channel or to 542 indicate that the channel has been established. Note that the gateway 543 may already have the channel established at its layer. If so, upon 544 receipt of an Establish Request, the gateway takes no action except to 545 send an Establish Confirm. 547 0 15 16 31 548 +---------------+---------------+ 549 | State | 550 +---------------+---------------+ 552 The valid values for State are shown in the following table. 554 Define Value Description 555 ESTABLISH_NORMAL 0x0 Follow normal procedure for 556 establishing a SS7 link 557 ESTABLISH_EMERGENCY 0x1 Follow emergency procedure for 558 establishing a SS7 link 560 2.3.1.3 Release (Request, Indication, Confirmation) 562 This Release Request message is used to release the channel. The Release 563 Confirm and Indication messages are used to indicate that the channel has 564 been released. 566 0 15 16 31 567 +---------------+---------------+ 568 | Reason | 569 +---------------+---------------+ 571 The valid values for Reason are shown in the following table. 573 Define Value Description 574 RELEASE_MGMT 0x0 Management layer generated release. 575 RELEASE_PHYS 0x1 Physical layer alarm generated release. 576 RELEASE_SIOS 0x2 Receipt of SIOS 577 RELEASE_OTHER 0x3 Other reason SS7 link out-of-service 579 (should we keep it simple, or provide list of reasons that would 580 enable debugging) 582 2.3.1.4 State (Request, Confirm) 584 The State Request message can be sent from a MGC to cause an action 585 on a particular SS7 link supported by the Signaling Gateway. The 586 gateway sends a State Confirm to the MGC if the action has been success- 587 fully completed. The State Confirm reflects that state value received 588 in the State Request message. 590 0 15 16 31 591 +---------------+---------------+ 592 | State | 593 +---------------+---------------+ 595 The valid values for State are shown in the following table. 597 Define Value Description 598 STATUS_LOC_PROC_SET 0x0 Request local processor outage. 599 STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage 600 recovered. 601 STATUS_EMER_SET 0x2 Request emergency alignment 602 procedure. 603 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 604 emergency) procedure. 605 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. 606 STATUS_CONTINUE 0x5 Continue. 608 2.3.1.5 State Indication 610 The MTP2 State Indication message can be sent from a gateway to a call 611 agent to indicate a condition on a channel. 613 0 15 16 31 614 +---------------+---------------+ 615 | State | 616 +---------------+---------------+ 618 The valid values for State are shown in the following table. 620 Define Value Description 621 EVENT_ENTER_LPO 0x0 Entered local processor outage. 622 EVENT_EXIT_LPO 0x1 Exited local processor outage. 623 EVENT_ENTER_CONG 0x2 Entered a congested state. 624 EVENT_EXIT_CONG 0x3 Exited a congested state. 625 EVENT_PHYS_UP 0x4 Physical interface up. 626 EVENT_PHYS_DOWN 0x5 Physical interface down. 627 EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. 628 EVENT_REM_ENTER_CONG 0xc Remote entered congestion. 629 EVENT_REM_EXIT_CONG 0xd Remote exited congestion. 630 EVENT_REM_ENTER_PO 0xe Remote entered processor outage. 631 EVENT_REM_EXIT_PO 0xf Remote exited processor outage. 633 2.3.1.6 Retrieval (Request, Confirm) 635 The MTP2 Retrieval Request message is used during the MTP Level 3 636 changeover procedure to request the BSN, to retrieve PDUs from the 637 retransmit queue or to flush PDUs from the retransmit queue. 639 0 15 16 31 640 +---------------+---------------+ 641 | Action | 642 +---------------+---------------+ 643 | fsn_bsn | 644 +---------------+---------------+ 646 The valid values for Action are shown in the following table. 648 Define Value Description 649 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. 650 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 651 queue. 652 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. 654 In the Retrieval Request message, the fsn_bsn field contains the FSN of 655 the far end if the action is ACTION_RTRV_MSGS. 657 When the Signaling Gateway sends a Retrieval Confirm to this request, 658 it echos the action and puts the BSN in the fsn_bsn field if the action 659 was ACTION_RTRV_BSN. 661 2.3.1.7 Retrieval Indication 663 The Retrieval Indication message is sent by the Signaling Gateway 664 with a PDU from the retransmit queue. The Retrieval Indication 665 message does not contain the Action or fsn_bsn fields, just a PDU from 666 the retransmit queue. 668 0 15 16 31 669 +---------------+---------------+ 670 | | 672 . PDU from retransmit . 673 . queue . 675 | | 676 +---------------+---------------+ 678 2.3.1.8 Retrieval Complete Indication 680 The MTP2 Retrieval Complete Indication message is exactly the same as 681 the MTP2 Retrieval Indication message except that it also indicates that 682 it contains the last PDU from the retransmit queue. 684 2.3.2 Application Server Process Maintenance (ASPM) Messages 686 The ASPM messages will only use the common header. 688 2.3.2.1 ASP UP (ASPUP) 690 The ASPUP message is used to indicate to a remote M2UA peer that the 691 layer is ready to receive traffic or maintenance messages. 693 The ASPUP message contains the following parameters: 695 Adaptation Layer Identifer (optional) 696 SCN Protocol Identifier (optional) 698 The Adaptation Layer Identifier is a string that identifies the 699 adaptation layer. This string must be set to "M2UA" which means 700 the length will be 4. 702 The Protocol Identifier field contains the identity of the specific SCN 703 signaling protocol being transported. The Protocol ID defines the 704 protocol type, variant, and version, and thereby specifies the components 705 and encoding of the PROTOCOL DATA field. The Protocol Identifier also 706 defines what SCN protocol message components are included in the PROTOCOL 707 DATA. 709 (Ed. Note: Need encoding of mime-type value or OID or fixed 710 string/integer that will be administered outside of this document 711 (IANA). Also, perhaps bring in text from Christian's mime document - See 712 "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP 713 media type defined according to the rules defined in RFC 2048.?) 715 The format for the ASPUP message is as follows: 717 0 15 16 31 718 +---------------+---------------+ 719 | Tag (0x2) | Length | 720 +---------------+---------------+ 722 | Adaptation Layer Identifier | 724 +---------------+---------------+ 725 | Tag (0x3) | Length | 726 +---------------+---------------+ 728 | Protocol Identifier | 730 +---------------+---------------+ 731 | Tag (0x4) | Length | 732 +---------------+---------------+ 734 | INFO String | 736 +---------------+---------------+ 738 Note: Strings are padded to 32-bit boundaries. The length field 739 indicates the end of the string. 741 2.3.2.2 ASP Down (ASPDN) 743 The ASPDN message is used to indicate to a remote M2UA peer that the 744 layer is not ready to receive traffic or maintenance messages. 746 The ASPDN message contains the following parameters: 748 INFO String 750 The format for the ASPDN message is as follows: 752 0 15 16 31 753 +---------------+---------------+ 754 | Tag (0x4) | Length | 755 +---------------+---------------+ 757 | INFO String | 759 +---------------+---------------+ 761 ##### 762 We discussed adding a reason code. Reason could be failure or 763 management inhibit. 764 ##### 766 2.3.2.3 ASP Active (ASPAC) 768 The ASPAC message is sent by an ASP to indicate to an SG that it is 769 the active ASP to be used from within a list of primary and back-up ASPs 770 for a particular signaling mapping relationship. 772 The ASPAC message contains the following parameters: 774 Controlled/Forced flag (C/F flag) 775 INFO String 777 The format for the ASPAC message is as follows: 779 0 15 16 31 780 +---------------+---------------+ 781 | C/F flag | 782 +---------------+---------------+ 783 | Tag (0x4) | Length | 784 +---------------+---------------+ 786 | INFO String | 788 +---------------+---------------+ 790 The valid values for C/F flag are shown in the following table. 792 Define Value Description 793 FORCED 0x0 Force sending of all messages to ASP 794 CONTROLLED 0x1 Only send "new work" to ASP 796 2.3.2.4 ASP Inactive (ASPIA) 798 The ASPIA message is sent by an ASP to indicate to an SG that it is 799 no longer the the active ASP to be used from within a list of primary 800 and back-up ASP for a particular signaling mapping relationship. The 801 SG will respond with an ASPIA message and either buffer or discard 802 incoming messages for a timed period and then discard. 804 The ASPIA message contains the following parameters: 806 INFO String 808 The format for the ASPIA message is as follows: 810 0 15 16 31 811 +---------------+---------------+ 812 | Tag (0x4) | Length | 813 +---------------+---------------+ 815 | INFO String | 817 +---------------+---------------+ 819 2.3.3 Layer Management (MGMT) Messages 821 2.3.3.1 Error (ERR) 823 The ERR message is sent when an invalid value is found in an incoming 824 messages. 826 The ERR message contains the following parameters: 828 Error Code 830 The format for the ERR message is as follows: 832 0 7 8 15 16 31 833 +---------------+---------------+ 834 | Error Code | 835 +---------------+---------------+ 837 The Error Code can be one of the following values: 839 Invalid Version 0x1 840 Invalid Interface Identifier 0x2 841 Invalid SCN Version 0x3 842 Invalid Adaptation Layer Identifier 0x4 843 Invalid Stream Identifier 0x5 844 Invalid Message Type 0x6 846 3.0 Procedures 848 The M2UA layers needs to respond to various primitives it receives from 849 other layers as well as messages it receives from the peer-to-peer 850 messages. This section describes various procedures involved in 851 response to these events. 853 3.1 Procedures to Support Service in Section 1.4.1 855 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 856 MTP Level 3 boundary" service. 858 3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 860 On receiving a primitives from the local layer, the M2UA layer will 861 send the corresponding MAUP message (see Section 2) to its peer. The 862 M2UA layer must fill in various fields of the common and specific headers 863 correctly. In addition the message needs to be sent on the SCTP stream 864 that corresponds to the SS7 link. 866 3.1.2 MAUP Message Procedures 868 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 869 SG or MGC needs to invoke the corresponding layer primitives to the 870 local MTP Level 2 or MTP Level 3 layer. 872 3.2 Procedures to Support Service in Section 1.4.2 874 3.2.1 LM primitives procedures 876 On receiving these primitives from the local layer, the M2UA layer will 877 send the corresponding LM message (Error) to its peer. The M2UA layer 878 must fill in the various fields of the common and specific headers 879 correctly. 881 3.2.2 LM message procedures 883 Upon receipt of LM messages the M2UA layer must invoke the corresponding 884 Layer Management primitives (M-ERROR) to the local layer management. 886 3.3 Procedures to Support Service in Section 1.4.3 888 These procedures achieve the M2UA layer's "Support for management of 889 active associations between SG and MGC" service. 891 3.3.1 State Maintenance 893 3.3.1.1 ASP States 895 The state of the each ASP is maintained in the M2UA layer on the SG. The 896 state of an ASP changes due to events. The events include: 898 * Reception messages from peer M2UA layer 899 * Reception of indications from layers below 901 The ASP state transition diagram is shown in Figure 4. The possible 902 states of an ASP are: 904 ASP-DOWN: Application Server Process is unavailable. Initially all ASPs 905 are in this state. 907 ASP-UP: Application Server Process is available but application traffic is 908 stopped. 910 ASP-ACTIVE: Application Server Process is available and application 911 traffic is active. At most one ASP per AS can be in the active state. 913 Figure 4: ASP State Transition Diagram 915 +-------------+ 916 |-------->| | 917 | | ASP-ACTIVE | 918 | | | 919 | | | 920 | +-------------+ 921 | ^ | 922 | ASP | | ASP 923 | Active | | Inactive 924 | | v 925 | +-------------+ 926 | | | 927 ASP Down / | | | 928 SCTP CDI | | ASP-UP | 929 | | | 930 | | | 931 | +-------------+ 932 | ^ | 933 | ASP | | ASP Down / 934 | Up | | SCTP CDI 935 | | v 936 | +-------------+ 937 | | | 938 |-------->| | 939 | ASP-DOWN | 940 | | 941 | | 942 +-------------+ 944 SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper 945 Layer Protocol (M2UA) on an SG. SCTP will send this indication when 946 it detects the loss of connectivity to ASP's SCTP layer. 948 3.3.1.2 AS States 950 The state of the AS is maintained in the ITUN layer on the SG. 952 The state of an AS changes due to events. These events include: 954 * ASP state transitions 955 * Recovery timer triggers 957 The possible states of an AS are: 959 AS-DOWN: Application Server is unavailable. This state implies that all 960 ASPs are in the ASP-DOWN state for this AS. 962 AS-UP: One or more ASPs are in the ASP-UP state. 964 AS-ACTIVE: Application Server is available and application traffic is 965 active. This state implies that one ASP is in the ASP-ACTIVE state. 967 AS-PENDING: Currently Active ASP became inactive or SCTP association with it 968 is lost. A Recovery timer will be started and in coming SCN messages will 969 be queuedby the SG. If an ASP becomes Active before the recovery timer 970 expires, AS will move to AS-ACTIVE state and all the queued messages will 971 be sent to the active ASP. If the recovery timer expires before an ASP 972 becomes active, SG stops queuing messages and discards all queued messages. 973 AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it 974 will move to AS-DOWN state. 976 If T(r) expires before an ASP becomes active, the SG stops queuing messages 977 and discards all previously queued messages. The AS will move to AS-UP if 978 at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. 980 +----------+ one ASP trans ACTIVE +-------------+ 981 | |------------------------>| | 982 | AS-UP | | AS-ACTIVE | 983 | | | | 984 | |< -| | 985 +----------+ \ / +-------------+ 986 ^ | \ Tr Trigger / ^ | 987 | | \ at least one / | | 988 | | \ ASP in UP / | | 989 | | \ / | | 990 | | \ / | | 991 | | \ /---/ | | 992 one ASP | | \ / one ASP | | ACTIVE ASP 993 trans | | all ASP \-/----\ trans | | trans to UP or 994 to UP | | trans to / \ ACTIVE | | ACTIVE ASP 995 | | DOWN / \ | | SCTP CDI 996 | | / \ | | 997 | | / \ | | 998 | | /all ASP \ | | 999 | v / trans to \ | v 1000 +----------+ / DOWN \ +-------------+ 1001 | |<--/ -| | 1002 | AS-DOWN | | AS-PENDING | 1003 | | | (queueing) | 1004 | |<------------------------| | 1005 +----------+ Tr Trigger no ASP +-------------+ 1006 in UP state or 1007 prev ACTIVE ASP trans 1008 to DOWN state 1010 Tr = Recovery Timer 1012 Figure 5: AS State Transition Diagram 1014 Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the 1015 Layer Management on MG may take appropriate SCN notification actions. 1017 3.3.2 ASPM procedures for primitives 1019 Before the establishment of an SCTP association the ASP state at both the 1020 SG and ASP is assumed to be "Down". 1022 When the M2UA layer receives an M-SCTP ESTABLISH request primitive from 1023 the Layer Management, the M2UA layer will try to establish an SCTP 1024 association with the remote M2UA peer. Upon reception of an eventual 1025 SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer 1026 will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. 1028 Alternatively, if the remote M2UA-peer establishes the SCTP association 1029 first, the M2UA layer will receive an SCTP Communication Up indication 1030 primitive from the SCTP. The M2UA layer will then invoke the primitive 1031 M-SCTP ESTABLISH indication to the Layer Management. 1033 Once the SCTP association is established, The M2UA layer at an ASP will 1034 then find out the state of its local M2UA-user from the Layer Management 1035 using the primitive M-ASP STATUS. Based on the status of the local 1036 M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM) 1037 function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/ 1038 -Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. 1040 If the M2UA layer subsequently receives an SCTP-Communication Down 1041 indication from the underlying SCTP layer, it will inform the Layer 1042 Management by invoking the M-SCTP STATUS indication primitive. The state 1043 of the ASP will be moved to "Down" at both the SG and ASP. 1045 At an ASP, the Layer Management may try to reestablish the SCTP association 1046 using M-SCTP ESTABLISH request primitive. 1048 3.3.3 ASPM procedures for peer-to-peer messages 1050 3.3.3.1 ASP UP 1052 The SG will mark the path as up if an explicit ASP UP (ASPUP) message is 1053 received and internally the path is allowed to come up (i.e., not in a 1054 locked local maintenance state). An ASP UP (ASPUP) message will be sent 1055 to acknowledge the received ASPUP. The SG will respond to a ASPUP with a 1056 ASPDN message if the path is in a locked maintenance state. 1058 The SG will send a ASPUP message in response to a received ASPUP message 1059 from the MGC even if that path was already marked as UP at the SG. 1061 The paths are controlled by the MGC. The SG will only send ASPUP in 1062 response to the reception of a ASPUP message. 1064 The MGC will send ASPUP messages every 2 (add text regarding this being 1065 a configurable timer) seconds until the path comes up (i.e. until it 1066 receives a ASPUP message from the SG for that path). The MGC may decide 1067 to reduce the frequency (say to every 5 seconds) if the an acknowledge- 1068 ment is not received after a few tries. 1070 The MGC should wait for the ASPUP message from the SG before transmitting 1071 ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will 1072 risk message loss. The ASPUP message received from the SG is not 1073 acknowledged by the MGC. 1075 3.3.3.2 ASP Down 1077 The SG will mark the ASP as down and send a ASPDN message to the MGC if 1078 one of the following events occur: 1080 - a ASP Down(ASPDN) message is received from the MGC, 1081 - the ASP is locked by local maintenance. 1083 The SG will also send a ASPDN message when the ASP is already down and 1084 a ASPDN) message is received from the MGC. 1086 The MGC will send ASPDN whenever it wants to take down a ASP. Since the 1087 ASPDN messages to the SG or the ASPDN responses from the SG can be lost 1088 (for example, during a MGC node failover), the MGC can send ASPDN messages 1089 every 2 seconds until the path comes down (i.e. until it receives a ASPDN 1090 message from the SG for that path). 1092 3.3.4 ASP Version Control 1094 If a ASP Up message with an unknown version is received, the receiving 1095 end will respond with an Error message. This will indicate to the 1096 sender which version the receiving node supports. 1098 This is useful when protocol version upgrades are being performed. A 1099 node with the newer version should support the older versions used on 1100 other nodes it is communicating with. 1102 The version field in the Error message header associated with the will 1103 indicate the version supported by the node. 1105 3.3.5 ASP Inactive 1107 When a ASPIA message is received, message transmission to that ASP ceases. 1108 The SG will either discard all incoming messages or start buffering the 1109 incoming messages for N seconds after which messages will be discarded. 1111 If the ASP is down, all of the Paths that were supported by that ASP 1112 are, by default, down. 1114 3.3.6 ASP Active 1116 When a ASP Active (ASPAC) message is received, the SG will start routing 1117 to that ASP. Reception of a ASPAC message overrides any previous ASPAC 1118 messages and results in the ASP associated with the ASPAC message to 1119 become the newly active ASP. 1121 4.0 Examples of MTP2 User Adaptation (M2UA) Procedures 1123 4.1 Establishment of associations between SG and MGC examples 1125 An example of the message flows for establishing active associations between 1126 SG and MGC is shown below. 1128 SG ASP1 1130 <----------- ASP Up 1131 ASP Up ----------> 1132 (ACK) 1133 <----------- ASP Active 1134 ASP Active ----------> 1135 (ACK) 1137 An example of message flows for establishment of associations with two 1138 ASPs and the message flows for take-over of the primary (ASP1) by the 1139 secondary (ASP2). 1141 SG ASP1 ASP2 1143 <----------- ASP Up 1144 ASP Up ----------> 1145 (ACK) 1146 <------------------------------ ASP Up 1147 ASP Up ------------------------------> 1148 (ACK) 1149 <----------- ASP Active 1150 ASP Active ----------> 1151 (ACK) 1152 ... 1154 <----------- ASP Inactive 1155 ASP Inactive ----------> 1156 (ACK) 1158 (this message is optional) 1159 ASP Inactive ------------------------------> 1160 <------------------------------ ASP Active 1161 ASP Active ------------------------------> 1162 (ACK) 1164 An example of message flows for establishment of associations with two 1165 ASPs and the message flows for controlled take-over of the primary (ASP1) 1166 by the secondary (ASP2). In this case, the SG sends new work to ASP2. 1168 SG ASP1 ASP2 1170 <----------- ASP Up 1171 ASP Up ----------> 1172 (ACK) 1173 <------------------------------ ASP Up 1174 ASP Up ------------------------------> 1175 (ACK) 1176 <----------- ASP Active 1177 ASP Active ----------> 1178 (ACK) 1179 ... 1181 <------------------------------ ASP Active 1182 (New Work) 1183 ASP Active ------------------------------> 1184 (ACK) 1186 <----------- ASP Inactive 1187 ASP Inactive ----------> 1188 (ACK) 1190 4.2 Case 1: SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 1192 4.2.1 SS7 Link Alignment 1194 The MGC can request that a SS7 link be brought into alignment using the 1195 normal or emergency procedure. An example of the message flow to bring 1196 a SS7 link in-service using the normal alignment procedure is shown 1197 below. 1199 SG MGC 1201 <----------- Establish Request (ESTABLISH_NORMAL) 1202 Establish Response ----------> 1204 An example of the message flow to bring a SS7 link in-service using the 1205 emergency alignment procedure. 1207 SG MGC 1209 <----------- Establish Request (ESTABLISH_EMER) 1210 Establish Response ----------> 1211 4.2.2 SS7 Link Release 1213 The MGC can request that a SS7 link be taken out-of-service. It uses 1214 the Release Request message as shown below. 1216 SG MGC 1218 <------------ Release Request (RELEASE_MGMT) 1219 Release Response ------------> 1221 The SG can autonomously indicate that a SS7 link has gone out-of-service 1222 as shown below. 1224 SG MGC 1226 Release Indication ------------> 1227 (RELEASE_PHYS) 1229 4.2.3 Set and Clear Local Processor Outage 1231 to be added 1233 4.2.4 Notification of Processor Outage (local or remote) 1235 to be added 1237 4.2.5 Flush Buffers or Continue 1239 to be added 1241 4.2.6 SS7 Link Changeover 1243 An example of the message flow for a changeover is shown below. 1245 SG MGC 1247 <---------- Retrieval Request (MTP2_RTRV_BSN) 1248 Retrieval Confirm ----------> 1249 (with BSN) 1250 <---------- Retrieval Request (MTP2_RTRV_MSGS 1251 with FSN) 1252 Retrieval Confirm ----------> 1254 Retrieval Ind -----------> 1255 Retrieval Ind -----------> 1256 Rtrvl Complete Ind ----------> 1258 Note: The number of Retrieval Indication is dependent on the number of 1259 messages in the retransmit queue that have been requested. Only one 1260 Retrieval Complete Indication should be sent. 1262 4.3 Case 2: SG to IPSCP, MTP Level 2 to MTP Level 3 Boundary Procedures 1264 4.3.1 Message Transmission 1266 Messages are transmitted using the Data Request primitive from MTP3 to 1267 MTP2UA. 1269 MTP2UA MTP3 1271 <------------- Message For Transmission (Data Request) 1273 4.3.2 Message Reception 1275 Messages are received using the Data Indication primitive from MTP2UA to 1276 MTP3. 1278 MTP2UA MTP3 1280 ------------> Received Message (Data Indication) 1282 4.3.3 Link Status Indication 1284 The MTP2UA layer sends Link_In_Service and Link_out_Of_Service after 1285 receiving indication from SCTP layer. 1287 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1289 <-------------- 1290 Communication Up 1291 Link proving is done 1292 By MTP2UA at this moment. 1293 <--------------- 1294 Link_In_Service 1296 <-------------- 1297 Communication Lost 1298 <--------------- 1299 Link Out of Service 1301 4.3.4 Link Alignment 1303 The MTP3 layer in the IPSCP can request that a SS7 link be brought into 1304 alignment using the normal or emergency procedure. An example of the 1305 message flow to bring a SS7 link in-service using the normal alignment 1306 procedure is shown below. 1308 MTP2UA MTP3 1310 <----------- Establish Request (ESTABLISH_NORMAL) 1311 Establish Response ----------> 1313 An example of the message flow to bring a SS7 link in-service using the 1314 emergency alignment procedure. 1316 MTP2UA MTP3 1318 <----------- Establish Request (ESTABLISH_EMER) 1319 Establish Response ----------> 1321 4.3.5 Link Proving (During Emergency) 1323 There are two alignment procedures used: normal alignment and emergency 1324 alignment. During normal alignment, communication to other end is tested 1325 for a period of time for making sure that the communication link does 1326 satisfy the performance requirements of the application. The examples 1327 are RTT and packet loss. Normal alignment is used when there are other 1328 links associated with the affected link. The other links should be to 1329 the same destination. Emergency alignment is used when there are no other 1330 links to the same destination. During emergency, link is not tested for 1331 long period of time but instead, an indication from SCTP layer is used to 1332 bring the link in service. 1334 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1336 -------------> 1337 Emergency Disable Proving 1339 <------------- 1340 Communication UP 1341 --------------> 1342 Status (validate the SCTP association meets 1343 application requirement) 1345 <------------- 1346 Link_In_Service 1348 4.3.6 Link Proving (Emergency Ceased) 1350 One function of the adaptation layer is to make sure that the link meets 1351 the performance requirements of the application. This is usually done 1352 by proving the link. For example, for proving the link, we need the 1353 adaptation layer to issue an heartbeat/RTT to its peer. This is done 1354 before declaring link is in service to its application. For this purpose, 1355 the existing "status" command is used. Note that how to the link meets 1356 performance requirements is implementation dependent. Also, the proving 1357 period can be configurable. 1359 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1361 -------------> 1362 Emergency Enable Proving 1363 ceased 1365 <--------------- 1366 Communication UP 1367 ---------------> RTT 1368 Status --------> 1369 RTTs are --------> 1370 Sent for a --------> 1371 Period of ......... 1372 3 seconds --------> 1373 RTT 1374 <-------------- 1375 Link_In_Service (After checking that link is sane) 1377 4.3.7 Congestion Notification to Upper layer 1379 MTP3 layer expects notification of the link congestion. For example, this 1380 is accomplished by two messages: I) Link Congested ii) Link Congestion 1381 Ceased. Congestion is assumed if MTP2UA layer notices repeated failures 1382 to send requests to SCTP (this is implementation dependent and it is 1383 assumed that the SEND Failure has an error code "life time expired"). 1384 Subsequently MTP2UA can start polling status of SCTP. If all the messages 1385 are successfully transmitted over a period of time (implementation dependent) 1386 then it is assumed that the congestion is abated. If the congestion 1387 condition should continue, the link will be taken out of service. In 1388 this case, it is possible to start link change over procedure. 1390 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1392 <-------------- 1393 Send Failure 1394 <-------------- 1395 Send Failure 1396 <-------------- 1397 Send Failure 1398 ("N" consecutive fails) 1399 (implementation specific) 1400 <------------- 1401 Congestion Detected 1402 -------------> 1403 Status 1404 ------------> 1405 Status 1406 -------------> 1407 polled for certain time 1408 till the congestion ceased 1409 (implementation specific) 1410 <-------------- 1411 Congestion ceased 1413 4.3.8 Link Change Over due to Congestion 1415 Due to sustained congestion, MTP2UA can take the link out of service. 1416 Next, MTP2UA sends an indication to MTP3 regarding link is out service 1417 due to congestion. In this context, MTP3 can initiate a link change 1418 over to its peer. 1420 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1422 <-------------- 1423 Send Failure 1424 <-------------- 1425 Send Failure 1426 <-------------- 1427 Send Failure 1428 ("N" consecutive fails) 1429 (implementation specific) 1430 <-------------- 1431 Congestion Detected 1432 ------------> 1433 Terminate 1434 <------------ 1435 Terminate Successful 1436 <------------ 1437 Communication Lost 1438 <--------------- 1439 Link Out of Service 1441 4.3.9 Link Release 1443 The MTP3 can request that a SS7-IP link be taken out-of-service. It uses 1444 the Release Request message as shown below. 1446 MTP2UA MTP3 1448 <------------ Release Request 1449 Release Response ------------> 1451 The SG can autonomously indicate that a SS7 link has gone out-of-service 1452 as shown below. 1454 MTP2UA MTP3 1456 Release Indication ------------> 1457 (Link_Out_Of_Service) 1459 NOTE: We may be able to effective use of "State" primitives here. 1460 For further investigation 1462 4.3.10 Link Change Over 1464 The objective of the change over is to ensure that signaling traffic 1465 carried by the unavailable signaling link is diverted to the alternative 1466 signaling link as quickly as possible while avoiding message loss, 1467 duplication or mis-sequencing. For this purpose, the changeover 1468 procedure includes data retrieval, which is performed before reopening 1469 the alternative signaling links to the diverted traffic. Data retrieval 1470 consists of identifying all those messages in the retransmission buffer 1471 of the unavailable signaling link which have not been received by the far 1472 end. Retrieval includes transferring the concerned messages to the 1473 transmission buffers of the alternative links. In order to support 1474 changeover, the SCTP TSN must be mapped to FSN/BSN of SS7. 1476 Transmit Sequence Numbers used by SCTP (Signaling Control Transport 1477 Protocol) are of sixteen bits. MTP2's forward and backward sequence 1478 numbers of only seven bits. Hence it is required to map the sixteen bit 1479 TSN to seven bit FSN/BSN. For simplicity, it is assumed that only least 1480 seven significant seven bits of TSN are used. There can be a 1481 configuration, where the links in the link set are of not equal bandwidth. 1482 Further investigation is required for this scenario. 1484 15 8 0 1485 ---------------------------------------------- 1486 0 0 0 0 0 0 0 0 0 X X X X X X X 1487 ----------------------------------------------- 1489 <------FSN/BSN-----> 1491 In order to convert TSN to FSN and BSN, the following formula is used: 1493 FSN, BSN = (Transmit Sequence Number - 1) MODULO 255 1495 For data retrieval, MTP3 requests Backward Sequence Number (BSN) from 1496 MTP2UA. This the sequence number of the last message received by the 1497 local end. During normal period, SCTP delivers ordered messages to the 1498 application. However, during congestion or failure condition, the sequence 1499 numbers of the acknowledged messages can have gaps. In particular, the 1500 SACK (selective acknowledgement message) message can have several of these 1501 gaps. Hence, it is important to scan through these gaps and find the 1502 sequence number before first gap. This is the number from which the remote 1503 end has to transmit the messages. So, this is the number considered as 1504 the Backward Sequence Number and communicated to the remote end. In a 1505 similar way, the remote end also, detects the BSN and indicates to local 1506 end. As soon, the MTP3 of local end receives this BSN, MTP3 retrieves all 1507 the unacknowledged messages starting from BSN. This is accomplished 1508 through "Retrieve FSN" message. After all the messages are sent from 1509 MTP2UA to MTP3, a retrieval complete message is sent. 1511 MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 1513 <------------- 1514 Communication Lost 1515 <-------------- 1516 Link Out of Service 1518 --------------> Find the gaps 1519 Retrieve BSN in the rcvd. Msgs 1520 And locate the first gap 1521 <--------------- 1522 Indicate BSN 1523 ----------------------------------------------------------------> 1524 COO (BSN) 1525 <----------- 1526 Retrieve BSN 1527 -----------> 1528 Indicate BSN 1529 <----------------------------------------------------------------- 1530 COA (BSN) 1532 --------------------->Go through the transmit 1533 Retrieve FSN queue and find unack. Msgs. 1534 <--------------------- FSB Not retrievable (in case) 1535 <--------------------- Retrieved Message 1536 <----------------------Retrieved Message 1537 ... 1538 <----------------------Retrieval Complete 1540 4.4 Layer Management Communication Examples 1542 An example of the message flows for communication between Layer Manage- 1543 ment modules between SG and MGC is shown below. An active association 1544 between MGC and SG is established (section 4.1) prior to the following 1545 message flows. 1547 SG MGC 1549 <----------- Establish Request 1550 Error ----------> 1551 (Invalid Interface Id) 1552 5.0 Security 1554 SCN adaptation layers rely on SCTP to provide security. 1556 6.0 Acknowledgements 1558 The authors would like to thank Ian Rytina for his valuable comments and 1559 suggestions. 1561 7.0 References 1563 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 1564 System No. 7 (SS7)' 1566 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 1567 Message Transfer Part (MTP)' 1569 [3] Bellcore GR-246-CORE 'Bell Communications Research Specification 1570 of Signaling System Number 7', Volume 1, December 1995 1572 [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- 1573 framework-arch-03.txt, June 1999 1575 [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, 1576 August 1999 1578 [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- 1579 v1-03.txt, August 1999 1581 8.0 Author's Addresses 1583 Ken Morneault Tel: +1-703-484-3323 1584 Cisco Systems Inc. EMail: kmorneau@cisco.com 1585 13615 Dulles Technology Drive 1586 Herndon, VA. 20171 1587 USA 1589 Malleswar Kalla Tel: +1-973-829-5212 1590 Telcordia Technologies EMail: kalla@research.telcordia.com 1591 MCC 1J211R 1592 445 South Street 1593 Morristown, NJ 07960 1594 USA 1596 Greg Sidebottom Tel: +1-613-763-7305 1597 Nortel Networks EMail: gregside@nortelnetworks.com 1598 3685 Richmond Rd, 1599 Nepean, Ontario 1600 Canada K2H5B7 1602 Ram Dantu, Ph.D. Tel: +1-972-477-8446 1603 Alcatel USA EMail: ram.dantu@usa.alcatel.com 1604 1000 Coit Road 1605 Plano, Tx. 74075 1607 This Internet Draft expires April 2000.