idnits 2.17.1 draft-ietf-sigtran-session-mgr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 1 longer page, the longest (page 1) being 881 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 13 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (25 Feburary 1999) is 9254 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Auerbach 2 INTERNET-DRAFT D. Berg 3 K. Morneault 4 Cisco Systems 6 Expires in six months 25 Feburary 1999 8 SESSION MANAGER 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This Internet Draft discusses a protocol layer, Session Manager, 33 that provides network redundancy and redundant Media Gateway 34 Controller configurations for signaling protocol applications. 35 Session Manager provides this support transparently. Network 36 and Media Gateway Controller redundancy are important for providing 37 highly reliable commercial applications that provide transportation of 38 signaling protocols over packet networks. 40 Auerbach, Berg & Morneault [Page 1] 41 TABLE OF CONTENTS 43 1. Introduction..............................................3 44 1.1 Background...........................................3 45 1.2 Terminology..........................................3 46 2. Problem Definition........................................4 47 3. Functionality.............................................4 48 3.1 Messages.............................................5 49 3.2 Message Header.......................................5 50 3.3 Session States.......................................5 51 3.4 Redundant Network....................................6 52 3.4.1 Server Side........................................6 53 3.4.2 Client Side........................................8 54 3.5 Redundant MGC Configuration.........................10 55 3.5.1 Server Side.......................................10 56 3.5.2 Client Side.......................................11 57 3.6 Session Manager Timers..............................13 58 3.7 Session Manager Counters............................13 59 3.8 Session Manager Statistics..........................14 60 4. Author's Addresses.......................................14 62 Auerbach, Berg & Morneault [Page 2] 63 1. Introduction 65 Session Manager provides support for network and Media Gateway 66 Controller redundancy. Session Manager is intended to be used between 67 a Media Gateway (MG) or Signaling Gateway (SG), which interfaces 68 between the circuit world (PSTN) and the packet world (IP/ATM), and a 69 Media Gateway Controller (MGC), which provides call processing. For the 70 rest of this document, Media Gateways and Signaling Gateways will be 71 more generically refered to as gateways. 73 1.0 Background 75 Before discussing the functions of Session Manager, it is important to 76 define a session and the other terms associated with a session. 78 1.1 Terminology 80 Session - A session is defined by a local IP address and port and a 81 remote IP address and port. It is a �physical� connection between a 82 MGC and a gateway. 84 Session Group - One or more sessions make up a session group. A session 85 group is used when network redundancy is required. Session Manager 86 manages session group(s) for a signaling application. 88 Session Set - A collection of session-group(s) each providing connectivity 89 to a different MGC. A session set is used in a redundant MGC architecture. 91 Channel - A channel is a physical termination of a signaling line (T1/E1 92 timeslot, V.35, etc.). It is defined by the protocol family, protocol 93 variant and layer terminated (i.e. Q.921). Each channel is associated 94 with a path. 96 Path - A path consists of one or more channels. A path is defined by 97 protocol family, variant and other relevant characteristics specific to 98 the protocol supported by that path. A path will use a session, session 99 group or a session set. Multiple paths between the same MGC and gateway 100 can share the same sessions. For example, a SS7 path would be equivalent 101 to a linkset and a SS7 channel would be equivalent to a link. An ISDN 102 (FAS) path would be equivalent to a single ISDN D-channel. 104 In the following diagram, there is an ISDN and DPNSS path. Both paths 105 are associated with the same session group. The session group (SG1) 106 consists of Session 1 and Session 2. For network redundancy, Session 1 107 would be on one IP network and Session 2 would be on a separate IP 108 network. 110 +----------+ 111 +---------+ SG1/Session 1 | | -- DPNSS channel 112 | | ------------------- | gateway | 113 | MGC | SG1/Session 2 | | -- ISDN channel 114 | | ------------------- | | 115 +---------+ | | 116 +----------+ 118 Auerbach, Berg & Morneault [Page 3] 119 The following diagram is the same except that the ISDN and DPNSS 120 paths are carried over separate session group(s). Most likely, this 121 configuration would be used when there was a desire to separate the 122 DPNSS and ISDN signaling traffic. More sessions could be added 123 to each session group for network redundancy. 125 +----------+ 126 +---------+ SG1/Session 1 | |--- DPNSS channel 127 | |---------------------| gateway | 128 | MGC | SG2/Session 1 | |--- ISDN channel 129 | |---------------------| | 130 +---------+ | | 131 +----------+ 133 The following diagram shows an example of the redundant MGC configuration. 134 In this case, Session Manager provides the ability to manage ACTIVE/- 135 STANDBY orientation on the client (gateway) side. In this configuration, 136 Session Group 1 and Session Group 2 make up a Session Set. 138 +----------+ 139 +---------+ SG1/Session 1 | |--- DPNSS channel 140 | ACTIVE |---------------------| gateway | 141 | MGC | SG1/Session 2 | |--- ISDN channel 142 | |---------------------| | 143 +---------+ | | 144 | | 145 | | 146 +---------+ SG2/Session 1 | | 147 | STANDBY |---------------------| | 148 | MGC | SG2/Session 2 | | 149 | |---------------------| | 150 +---------+ | | 151 +----------+ 153 2.0 Problem Definition 155 There is a need for a lightweight protocol layer below the signaling 156 protocol application to manage sessions used by signaling paths and 157 channels. The use of a session group or session set is desirable to 158 maintain multiple connections between a given gateway (client) and MGC 159 (server). This increases the availability of the gateway. In addition, 160 there is a need for managing redundant MGC hardware configurations 161 transparently to signaling protocol application(s). 163 The intent is to have Session Manager provide these services to signaling 164 application(s). As shown in the figure below, it sits below the 165 application and above a reliable communication mechanism. Session 166 Manager requires a reliable, connection-oriented transport mechanism 168 Auerbach, Berg & Morneault [Page 3] 169 as its lower layer. In the figure below, Session Manager sits on top 170 of Reliable UDP. 172 +------------------------------+ 173 | Signaling Application | 174 | (backhaul) | 175 +------------------------------+ 176 | Session Manager | 177 +------------------------------+ 178 | RUDP | 179 +------------------------------+ 181 The signaling session management layer provides the following functions: 183 1. Manage sessions in a session group based on priority and 184 availability. Only the client side needs to know priority. 185 2. Provide a mechanism to support session failure / switchover 186 scenario. 187 3. Provide a mechanism to support redundant MGC configurations. 188 a. notification of ACTIVE / STANDBY state of server (MGC) 189 to client (gateway). 190 b. Manage ACTIVE / STANDBY orientation on the client side 191 4. Allow the application to control the state of the session group, 192 session set or sessions. If multiple applications are using the 193 same session group or session set, it is up to the applications 194 to coordinate this type of management function. In effect, this 195 could provide an operator the ability to adminstratively cause a 196 session switchover. 197 5. Provide a mechanism for querying the state of the session set, 198 session group or sessions. 199 6. Provide a mechanism for autonomous notification of session set, 200 session group or session change of service state. 201 7. Provide a mechanism for querying statistics of session set, 202 session group or sessions. 203 8. If available, work with reliable transport to circumvent the 204 duplication of packets on switchovers. 205 9. Monitor the frequency of how often the session is switched and 206 recovered. If the frequency is larger than the threshold trigger 207 sm_unstable_session, an alarm and appropriate operation is taken 208 to report this faulty situation. 209 10. Avoid the ping-pong effects of failing over sessions in a short 210 period of time. 212 3.0 Functionality 214 Session Manager provides two basic functions: the ability to manage 215 sessions in a redundant network configuration and the ability to manage 216 a session set in a redundant MGC configuration. Session Manager can 217 provide this function for one or more applications. 219 Auerbach, Berg & Morneault [Page 4] 220 3.1 Messages 222 In order to fulfill its functions, the client and server implementations 223 of Session Manager need to pass messages. The four primary messages 224 are the Start, Stop, Active, and Standby message. The Start message 225 is sent by the client to activate a session to make it available 226 for transmission and receiption of PDUs. The Stop message is sent 227 by the client to deactivate a session for transmission and receiption 228 of PDUs. The Active and Standby messages are used by the server to 229 indicate ACTIVE/STANDBY state. 231 3.2 Message Header 233 In order to support the above mentioned messages, a header is required. 234 This header will contain a 16-bit message type, 8-bit version number 235 and an 8-bit spare field. The valid messages types are: 237 * Start Message (0x0) 238 * Stop Message (0x1) 239 * Active Message (0x2) - used with redundant MGC configuration 240 * Standby Message (0x3) - used with redundant MGC configuration 241 * Q_HOLD Invoke Message (0x4) - used with redundant MGC 242 configuration 243 * Q_HOLD Response Message (0x5) - used with redundant MGC 244 configuration 245 * Q_RESUME Invoke Message (0x6) - used with redundant MGC 246 configuration 247 * Q_RESUME Response Message (0x7) - used with redundant MGC 248 configuration 249 * Q_RESET Invoke Message (0x8) - used with redundant MGC 250 configuration 251 * Q_RESET Response Message (0x9) - used with redundant MGC 252 configuration 253 * PDU (0x8000) - Non Session Manager message from application 255 Note that messages used by Session Manager (i.e. not passed to the 256 application) are in the 0-0x7fff range. 258 0 7 8 15 16 31 259 +-------+---------+-----------------+ 260 | Spare | Version | Msg Type | 261 +-----------------+-----------------+ 263 The initial version number is 1. 265 3.3 Session States 267 A session can be in one of three states: 269 1. Out-of-Service: session has been created, but is not connected at 270 transport layer. 271 2. In-Service: session has been created and is connected at network 272 layer 274 Auerbach, Berg & Morneault [Page 5] 275 3. Primary In-Service: session is In-Service and START message has 276 been transferred from client to server 278 The figure below shows the state transitions. 280 +---------+ 281 | | 282 | OOS | 283 | | 284 +---------+ 285 | 286 | (connection established) 287 V 288 +---------+ 289 | | 290 | IS | 291 | | 292 +---------+ 293 | 294 | (START message sent/received) 295 V 296 +---------+ 297 | Primary | 298 | IS | 299 | | 300 +---------+ 302 3.4 Redundant Network 304 Session Manager should be used when redundant networks are required 305 between a MGC (server) and a gateway (client). Each session is given a 306 priority. The highest priority session will have a value of 1, lower 307 priorities increase in value. 309 Session Manager will keep all sessions In-Service. If an In-Service 310 session fails (goes Out-of-Service), Session Manager should periodically 311 retry to bring that session back In-Serivce. 313 Session Manager only transmits and receives PDUs over the Primary 314 In-Service session in order to avoid sequencing problems. Thus, only 315 one session can be Primary In-Service at a given time. The client side 316 implementation of Session Manager coordinates which In-Service 317 session is primary. The algorithm the client uses to handle session 318 failovers is described in Section 3.4.2. 320 3.4.1 Server Side 322 The server side implementation of Session Manager in a redundant network 323 configuration is fairly straightforward. A server can be in one of 324 four states: 326 1. Idle: a session group has been created 328 Auerbach, Berg & Morneault [Page 6] 329 2. Out-of-Service: a session or sessions have been added to the 330 session group, no Primary In-Service session (there may be one or 331 more In-Service sessions though). 332 3. In-Service: one of the sessions is in the Primary In-Service state 333 Note: The server side must have received the START message from 334 the client before it will transition to In-Service. 335 4. Switchover: the Primary In-Service session has failed, 336 sm_switchover_timer set 338 Initially, the server side is in the Idle state after the session group 339 has been created. It transitions to the Out-of-Service state when a 340 session(s) is added. 342 As sessions come In-Service, the server remains Out-of-Service until 343 a session is selected to be primary. This occurs when the client side 344 sends a START message over an In-Service session. At this point, the 345 server side transitions to the In-Service state. It will remain In- 346 Service unless the Primary In-Service session fails. In this case, it 347 transitions to the Switchover state. 349 In the Switchover state, the server side sets the sm_switchover_timer 350 and waits for the client to make another session primary. If the 351 timer expires, the server side transitions to Out-of-Service. 353 Note that if the currently active session is a secondary session, the 354 server may want to indicate a degradation in service (i.e. In-Service- 355 Degraded). 357 The figure below shows an example of the state diagram for a server side 358 implementation. 360 +---------+ 361 | | 362 | Idle | 363 | | 364 +---------+ 365 | 366 | 367 V 368 +---------+ 369 | | 370 ----| OOS |<--- 371 / | | \ 372 / +---------+ \ 373 session / \ Switchover Timer 374 Primary IS / \ Triggered 375 / \ 376 / \ 377 V | 378 +---------+ Primary IS -> OOS +---------+ 379 | |-------------------->| | 380 | IS | | Recover | 381 | |<--------------------| | 382 +---------+ Session Primary IS +---------+ 384 Auerbach, Berg & Morneault [Page 7] 385 3.4.2 Client Side 387 The client side supports five states: 389 1. Idle: a session group has been created 390 2. Out-of-Service: a session or sessions have been added to the 391 session group, no active session (meaning session is connected but 392 Start message has not been sent). 393 3. In-Service: one of the highest priority sessions is Primary 394 In-Service 395 4. Switchover: the active session has failed, try to bring next 396 highest priority session In-Service. 397 5. IS-Degraded: one of the lower priority sessions is Primary In- 398 Service 400 The client side begins in the Idle state when the session group has been 401 created. It transitions to the Out-of-Service state as soon as a 402 session is added. The client side periodically (sm_retry_timer) tries 403 to bring all the sessions to the In-Service state. Once a session is In- 404 Service, the client determines if it should be transitioned to 405 Primary-In-Service based on priority. The session is made Primary- 406 In-Service by passing a START message to the server side on that session. 407 The client can remove the primary designation of a session by passing a 408 STOP message to the server side on that session. 410 If one of the highest priority sessions is designated as primary, 411 the client transitions to the In-Service. If a lower priority session 412 is designated as primary, the client transitions to the In-Service- 413 Degraded state. 415 If the primary session fails while In-Service, the client side 416 transitions to the Switchover state. In this switchover state, the 417 client does the following: 419 a. Find the highest priority session that is In-Service. If there 420 are multiple high priority sessions, it picks the first. 421 b. If there are no sessions In-Service, it sets the 422 sm_switchover_timer and it tries to bring all sessions 423 In-Service in order of priority. If the switchover timer 424 (sm_switchover_timer) expires, the client transitions to 425 Out-of-Service. 426 c. Once the client has picked the session, it sends a START on 427 that session to transition it to the Primary-In-Service state. 428 The client then transitions its own state to In-Service or 429 In-Service-Degraded based on whether the session is of the 430 highest priority. 432 The figure below shows an example of the state diagram for a client side 433 implementation. 435 Auerbach, Berg & Morneault [Page 8] 436 +---------+ 437 | | 438 | Idle | 439 | | 440 +---------+ 441 | 442 | 443 V 444 +---------+ 445 | | 446 -------------| OOS |------------- 447 / | | \ 448 / +---------+ \ 449 HPS / ^ \ LPS 450 Primary IS / | \ Primary IS 451 / | Switchover \ 452 / | Timer \ 453 / | Triggered \ 454 V | V 455 +---------+ HPS -> OOS +---------+ LPS -> IS +----------+ 456 | |--------------->| |-------------->| | 457 | IS | | Switch | | IS | 458 | |<---------------| Over |<--------------| Degraded | 459 +---------+ HPS -> IS +---------+ LPS -> OOS +----------+ 461 * HPS = Highest Priority Session 462 LPS = Lower Priority Session 464 3.4.2.1 Client Side with RUDP 466 When the client side Session Manager is using RUDP as its transport 467 mechanism, it has the opportunity to initiate a session switchover 468 to another session in a session group. In this configuration, the 469 client does the following: 471 a. Receive the CONN_FAIL signal from RUDP which indicates the session 472 has failed (disconnected) 473 b. Find the highest priority session that is In-Service. If there 474 are multiple high priority sessions, it picks the first. 475 c. If there are no sessions In-Service, it sets the 476 sm_switchover_timer and it tries to bring all sessions In-Service 477 in order of priority. If the switchover timer (sm_switchover_timer) 478 expires, the client transitions to Out-of-Service. 479 d. Once the client has picked the session, it sends a START on 480 that session to transition it to the Primary-In-Service state. 481 The client then transitions its own state to In-Service or 482 In-Service-Degraded based on whether the session is of the highest 483 priority. 484 e. If the AUTO_RESET signal has not yet been received from RUDP, 485 Session Manager initiates a state transfer from the failed 486 session to the Primary-In-Service session. RUDP is responsible 488 Auerbach, Berg & Morneault [Page 9] 489 for ensuring the messages are retransmitted and avoiding the 490 transmission/reception of duplicate messages. 492 3.5 Redundant MGC Configuration 494 In a redundant MGC configuration, a gateway is connected to an 495 ACTIVE MGC and one or more STANDBY MGC(s). On the gateway side (client 496 side), Session Manager is used to manage ACTIVE/STANDBY state for the 497 signaling application. On the MGC side (server side), the signaling 498 application informs Session Manager of its ACTIVE/STANDBY state. 500 The Primary In-Service state is separated into two states for this mode 501 of operation: 503 1. Primary In-Service-ACTIVE: session is In-Service and START 504 message has been transferred from client to server, server has 505 transferred ACTIVE notification to client 506 2. Primary In-Service-STANDBY: session is In-Service and START 507 message has been transferred from client to server, server has 508 transferred STANDBY notification to client 510 3.5.1 Server Side 512 The server side implementation of this functionality is very straight- 513 forward. The figure below shows the state diagram. The server side 514 supports three states: 516 1. Idle: a session set has been created 517 2. Out-of-Service: session group(s) have been added to the session 518 set, a session In-Service. 519 3. In-Service: a session is Primary In-Service and ACTIVE/STANDBY 520 state has been sent 522 The server initializes to the Idle state when the session set is 523 created. When the session set is created, the initial ACTIVE/STANDBY 524 state is passed as an argument. After the session set has been created, 525 the signaling application can change the ACTIVE/STANDBY state at any 526 time. 528 The server transitions to the Out-of-Service state when a session is 529 created. When a session transitions to the Primary In-Service state, 530 it passes an ACTIVE or STANDBY message to the client. The server then 531 transitions to the In-Service state. 533 Note: The server periodically sends its state (ACTIVE/STANDBY) based 534 on sm_state_timer. 536 The figure below shows an example of the state diagram for a server side 537 implementation. 539 Auerbach, Berg & Morneault [Page 10] 540 +---------+ 541 | | 542 | Idle | 543 | | 544 +---------+ 545 | 546 | 547 V 548 +---------+ 549 | | 550 | OOS | 551 | | 552 +---------+ 553 | 554 | Session transitions to Primary IS 555 | ACTIVE/STANDBY notification sent 556 V 557 +---------+ 558 | | 559 | IS | 560 | | 561 +---------+ 563 3.5.2 Client Side 565 The client side implementation is a bit more complex since it needs to 566 act on ACTIVE/STANDBY indications from each server. The figure below 567 shows the state diagram. The client side supports five states: 569 1. SESS_IDLE State: a Session has been created. 570 2. SESS_OOS State: a session or sessions have been added to session 571 group, no ACTIVE notification has been received from MGC. 572 3. SESS_ACTIVE_IS State: a ACTIVE notification has been received 573 over one In-Service session, STANDBY notification has not been 574 received on any available In-Service session(s). 575 4. SESS_STANDBY_IS State: a STANDBY notification is received, but 576 there is no In-Service Active session available. 577 5. SESS_FULL_IS State: a session In-Service that has ACTIVE 578 notification and at least one session In-Service that has STANDBY 579 notification. 581 The client side only accepts PDU messages received from the ACTIVE 582 MGC. The client can be configured to send to just the ACTIVE MGC or 583 both the ACTIVE and STANDBY MGCs. 585 The client side session initializes to SESS_IDLE state when the 586 session is created. It transitions to the SESS_OOS state when a 587 session is added, and then waits for an ACTIVE or STANDBY notification. 588 If the notification is ACTIVE, it transitions to SESS_ACTIVE_IS state 589 and informs all the applications using this Session Set that the 590 Session Set is operational. If the notification is STANDBY, it 591 transitions to SESS_STANDBY_IS state. The session that the ACTIVE 593 Auerbach, Berg & Morneault [Page 11] 594 notification is received on will be called the Active session. The 595 session that the STANDBY notifcation is received on will be called the 596 Standby session. 598 If in the SESS_ACTIVE_IS state, it transitions to the SESS_FULL_IS state 599 if the STANDBY notification is received on any session other than the 600 Active session. If on the other hand, it receives a STANDBY 601 notification on the Active session, it transitions to the SESS_STANDBY_IS 602 state. 604 If in the SESS_STANDBY_IS state, the client transitions to the 605 SESS_FULL_IS state if the ACTIVE notification is received on a session 606 other than the Standby session. If on the other hand, the client 607 receives an ACTIVE notification on the Standby session, it transitions 608 to the SESS_ACTIVE_IS state. 610 If in the SESS_FULL_IS state, the client transitions to the 611 SESS_ACTIVE_IS state if an ACTIVE notification is received on the 612 Standby session and no other Standby session(s) is/are available. 613 Likewise, if in the SESS_FULL_IS state, the client transitions to 614 the SESS_STANDBY_IS state if a STANDBY notification is received on 615 the Active session. 617 The figure below shows an example of the state diagram for a client side 618 implementation. 620 +---------+ 621 | | 622 | Idle | 623 | | 624 +---------+ 625 | 626 | 627 V 628 +---------+ 629 | | 630 -------------| OOS |----------------- 631 / --------->| |<---------- \ 632 / / +---------+ \ \ 633 / / \ \ 634 Active / / Active Standby \ \ Standby 635 IS / / OOS OOS \ \ IS 636 / / \ \ 637 / / \ \ 638 V / \ V 639 +---------+ Standby IS +---------+ Standby IS +----------+ 640 | ACTIVE |--------------->| FULL |-------------->| STANDBY | 641 | IS | | IS | | IS | 642 | |<---------------| |<--------------| | 643 +---------+ Active IS +---------+ Standby OOS +----------+ 645 Auerbach, Berg & Morneault [Page 12] 646 3.5.2.1 Session Queueing 648 In the redundant MGC configuration, there is a requirement to be able 649 to queue messages on the client side while the MGC is in the process of 650 failover/switchover. The ACTIVE MGC requests that messages be queued 651 using the Q_HOLD Invoke message. The Q_HOLD Response message 652 indicates to the ACTIVE MGC that messages are being queued. At this point, 653 the MGC can freeze its state, transfer that state to the STANDBY MGC, then 654 the MGCs will transition states with the STANDBY MGC becoming ACTIVE. 656 The Q_RESUME Invoke message is used to request that the client begin 657 sending the queued messages to the ACTIVE MGC. The Q_RESET Invoke 658 message is used to request that the client clear (delete) all queued 659 messages. 661 In this SESS_ACTIVE_IS state, if Q_RESET Invoke notification is received 662 the Q_HOLD condition of all the queues associated with the session are 663 cleared and any queued messages are deleted. On the other hand, if 664 Q_RESUME Invoke notification is received, the Q_HOLD condition of all the 665 queues associated with the session are cleared and any queued messages 666 are transferred. If Q_HOLD condition is not set, a Q_RESET Invoke or 667 Q_RESUME Invoke notification are ignored. The same action is taken 668 when Q_RESET Invoke or Q_RESUME Invoke notifications are received in any 669 other state except SESS_IDLE and SESS_OOS states. 671 In this SESS_FULL_IS state, if the client receives a Q_HOLD Invoke 672 notification it will not change state, but the status of all the queues 673 associated with the session is set to Q_HOLD. The Q_HOLD Invoke 674 notification is only acted on in the SESS_FULL_IS state. Once Q_HOLD 675 condition is set for queues, it remains until cleared by Q_RESUME Invoke 676 or Q_RESET Invoke messages. No state transition clears the Q_HOLD 677 condition. 679 3.6 Session Manager Timers 681 Session Manager uses the following timers: 683 * sm_retry_timer - used to retry connection of Out-of-Service 684 sessions (default is 5 seconds) 685 * sm_switchover_timer - amount of time allowed for a switchover to 686 another session before transitioning to Out-of-Service state 687 (default is 3 seconds) 688 * sm_state_timer (redundant MGC configuration) - the server will send 689 state (ACTIVE/STANDBY) periodically based on this timer (default is 690 60 seconds) 692 3.7 Session Manager Counters 694 * sm_unstable_session - alarm trigger - if 20 session recoveries in 695 60 minutes or less 697 Auerbach, Berg & Morneault [Page 13] 698 3.8 Session Manager Statistics 700 Statistics should be maintained on a session, session group and session 701 set basis. The application should be able to query and clear the 702 statistics. 704 * number of bytes transmitted 705 * number of PDUs transmitted 706 * number of bytes received 707 * number of PDUs received 708 * number of session switchovers (kept at a session group level) 709 * number of MGC switchovers/failovers - redundant MGC configuration 710 (kept at a session set level) 712 4.0 Author's Addresses 714 David Auerbach Tel: +1-703-484-3464 715 Cisco Systems Email: dea@cisco.com 716 13615 Dulles Technology Drive 717 Herndon, VA 20171 718 USA 720 Diane Berg Tel: +1-703-484-3461 721 Cisco Systems Email: dberg@cisco.com 722 13615 Dulles Technology Drive 723 Herndon, VA 20171 724 USA 726 Ken Morneault Tel: +1-703-484-3323 727 Cisco Systems Email: kmorneau@cisco.com 728 13615 Dulles Technology Drive 729 Herndon, VA 20171 730 USA