Network Working Group D. Auerbach INTERNET-DRAFT D. Berg K. Morneault Cisco Systems Expires in six months 25 Feburary 1999 SESSION MANAGER Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft discusses a protocol layer, Session Manager, that provides network redundancy and redundant Media Gateway Controller configurations for signaling protocol applications. Session Manager provides this support transparently. Network and Media Gateway Controller redundancy are important for providing highly reliable commercial applications that provide transportation of signaling protocols over packet networks. Auerbach, Berg & Morneault [Page 1] Internet Draft Session Manager Protocol Feb 1999 TABLE OF CONTENTS 1. Introduction..............................................3 1.1 Background...........................................3 1.2 Terminology..........................................3 2. Problem Definition........................................4 3. Functionality.............................................4 3.1 Messages.............................................5 3.2 Message Header.......................................5 3.3 Session States.......................................5 3.4 Redundant Network....................................6 3.4.1 Server Side........................................6 3.4.2 Client Side........................................8 3.5 Redundant MGC Configuration.........................10 3.5.1 Server Side.......................................10 3.5.2 Client Side.......................................11 3.6 Session Manager Timers..............................13 3.7 Session Manager Counters............................13 3.8 Session Manager Statistics..........................14 4. Author's Addresses.......................................14 Auerbach, Berg & Morneault [Page 2] Internet Draft Session Manager Protocol Feb 1999 1. Introduction Session Manager provides support for network and Media Gateway Controller redundancy. Session Manager is intended to be used between a Media Gateway (MG) or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the packet world (IP/ATM), and a Media Gateway Controller (MGC), which provides call processing. For the rest of this document, Media Gateways and Signaling Gateways will be more generically refered to as gateways. 1.0 Background Before discussing the functions of Session Manager, it is important to define a session and the other terms associated with a session. 1.1 Terminology Session - A session is defined by a local IP address and port and a remote IP address and port. It is a “physical” connection between a MGC and a gateway. Session Group - One or more sessions make up a session group. A session group is used when network redundancy is required. Session Manager manages session group(s) for a signaling application. Session Set - A collection of session-group(s) each providing connectivity to a different MGC. A session set is used in a redundant MGC architecture. Channel - A channel is a physical termination of a signaling line (T1/E1 timeslot, V.35, etc.). It is defined by the protocol family, protocol variant and layer terminated (i.e. Q.921). Each channel is associated with a path. Path - A path consists of one or more channels. A path is defined by protocol family, variant and other relevant characteristics specific to the protocol supported by that path. A path will use a session, session group or a session set. Multiple paths between the same MGC and gateway can share the same sessions. For example, a SS7 path would be equivalent to a linkset and a SS7 channel would be equivalent to a link. An ISDN (FAS) path would be equivalent to a single ISDN D-channel. In the following diagram, there is an ISDN and DPNSS path. Both paths are associated with the same session group. The session group (SG1) consists of Session 1 and Session 2. For network redundancy, Session 1 would be on one IP network and Session 2 would be on a separate IP network. +----------+ +---------+ SG1/Session 1 | | -- DPNSS channel | | ------------------- | gateway | | MGC | SG1/Session 2 | | -- ISDN channel | | ------------------- | | +---------+ | | +----------+ Auerbach, Berg & Morneault [Page 3] Internet Draft Session Manager Protocol Feb 1999 The following diagram is the same except that the ISDN and DPNSS paths are carried over separate session group(s). Most likely, this configuration would be used when there was a desire to separate the DPNSS and ISDN signaling traffic. More sessions could be added to each session group for network redundancy. +----------+ +---------+ SG1/Session 1 | |--- DPNSS channel | |---------------------| gateway | | MGC | SG2/Session 1 | |--- ISDN channel | |---------------------| | +---------+ | | +----------+ The following diagram shows an example of the redundant MGC configuration. In this case, Session Manager provides the ability to manage ACTIVE/- STANDBY orientation on the client (gateway) side. In this configuration, Session Group 1 and Session Group 2 make up a Session Set. +----------+ +---------+ SG1/Session 1 | |--- DPNSS channel | ACTIVE |---------------------| gateway | | MGC | SG1/Session 2 | |--- ISDN channel | |---------------------| | +---------+ | | | | | | +---------+ SG2/Session 1 | | | STANDBY |---------------------| | | MGC | SG2/Session 2 | | | |---------------------| | +---------+ | | +----------+ 2.0 Problem Definition There is a need for a lightweight protocol layer below the signaling protocol application to manage sessions used by signaling paths and channels. The use of a session group or session set is desirable to maintain multiple connections between a given gateway (client) and MGC (server). This increases the availability of the gateway. In addition, there is a need for managing redundant MGC hardware configurations transparently to signaling protocol application(s). The intent is to have Session Manager provide these services to signaling application(s). As shown in the figure below, it sits below the application and above a reliable communication mechanism. Session Manager requires a reliable, connection-oriented transport mechanism Auerbach, Berg & Morneault [Page 3] Internet Draft Session Manager Protocol Feb 1999 as its lower layer. In the figure below, Session Manager sits on top of Reliable UDP. +------------------------------+ | Signaling Application | | (backhaul) | +------------------------------+ | Session Manager | +------------------------------+ | RUDP | +------------------------------+ The signaling session management layer provides the following functions: 1. Manage sessions in a session group based on priority and availability. Only the client side needs to know priority. 2. Provide a mechanism to support session failure / switchover scenario. 3. Provide a mechanism to support redundant MGC configurations. a. notification of ACTIVE / STANDBY state of server (MGC) to client (gateway). b. Manage ACTIVE / STANDBY orientation on the client side 4. Allow the application to control the state of the session group, session set or sessions. If multiple applications are using the same session group or session set, it is up to the applications to coordinate this type of management function. In effect, this could provide an operator the ability to adminstratively cause a session switchover. 5. Provide a mechanism for querying the state of the session set, session group or sessions. 6. Provide a mechanism for autonomous notification of session set, session group or session change of service state. 7. Provide a mechanism for querying statistics of session set, session group or sessions. 8. If available, work with reliable transport to circumvent the duplication of packets on switchovers. 9. Monitor the frequency of how often the session is switched and recovered. If the frequency is larger than the threshold trigger sm_unstable_session, an alarm and appropriate operation is taken to report this faulty situation. 10. Avoid the ping-pong effects of failing over sessions in a short period of time. 3.0 Functionality Session Manager provides two basic functions: the ability to manage sessions in a redundant network configuration and the ability to manage a session set in a redundant MGC configuration. Session Manager can provide this function for one or more applications. Auerbach, Berg & Morneault [Page 4] Internet Draft Session Manager Protocol Feb 1999 3.1 Messages In order to fulfill its functions, the client and server implementations of Session Manager need to pass messages. The four primary messages are the Start, Stop, Active, and Standby message. The Start message is sent by the client to activate a session to make it available for transmission and receiption of PDUs. The Stop message is sent by the client to deactivate a session for transmission and receiption of PDUs. The Active and Standby messages are used by the server to indicate ACTIVE/STANDBY state. 3.2 Message Header In order to support the above mentioned messages, a header is required. This header will contain a 16-bit message type, 8-bit version number and an 8-bit spare field. The valid messages types are: * Start Message (0x0) * Stop Message (0x1) * Active Message (0x2) - used with redundant MGC configuration * Standby Message (0x3) - used with redundant MGC configuration * Q_HOLD Invoke Message (0x4) - used with redundant MGC configuration * Q_HOLD Response Message (0x5) - used with redundant MGC configuration * Q_RESUME Invoke Message (0x6) - used with redundant MGC configuration * Q_RESUME Response Message (0x7) - used with redundant MGC configuration * Q_RESET Invoke Message (0x8) - used with redundant MGC configuration * Q_RESET Response Message (0x9) - used with redundant MGC configuration * PDU (0x8000) - Non Session Manager message from application Note that messages used by Session Manager (i.e. not passed to the application) are in the 0-0x7fff range. 0 7 8 15 16 31 +-------+---------+-----------------+ | Spare | Version | Msg Type | +-----------------+-----------------+ The initial version number is 1. 3.3 Session States A session can be in one of three states: 1. Out-of-Service: session has been created, but is not connected at transport layer. 2. In-Service: session has been created and is connected at network layer Auerbach, Berg & Morneault [Page 5] Internet Draft Session Manager Protocol Feb 1999 3. Primary In-Service: session is In-Service and START message has been transferred from client to server The figure below shows the state transitions. +---------+ | | | OOS | | | +---------+ | | (connection established) V +---------+ | | | IS | | | +---------+ | | (START message sent/received) V +---------+ | Primary | | IS | | | +---------+ 3.4 Redundant Network Session Manager should be used when redundant networks are required between a MGC (server) and a gateway (client). Each session is given a priority. The highest priority session will have a value of 1, lower priorities increase in value. Session Manager will keep all sessions In-Service. If an In-Service session fails (goes Out-of-Service), Session Manager should periodically retry to bring that session back In-Serivce. Session Manager only transmits and receives PDUs over the Primary In-Service session in order to avoid sequencing problems. Thus, only one session can be Primary In-Service at a given time. The client side implementation of Session Manager coordinates which In-Service session is primary. The algorithm the client uses to handle session failovers is described in Section 3.4.2. 3.4.1 Server Side The server side implementation of Session Manager in a redundant network configuration is fairly straightforward. A server can be in one of four states: 1. Idle: a session group has been created Auerbach, Berg & Morneault [Page 6] Internet Draft Session Manager Protocol Feb 1999 2. Out-of-Service: a session or sessions have been added to the session group, no Primary In-Service session (there may be one or more In-Service sessions though). 3. In-Service: one of the sessions is in the Primary In-Service state Note: The server side must have received the START message from the client before it will transition to In-Service. 4. Switchover: the Primary In-Service session has failed, sm_switchover_timer set Initially, the server side is in the Idle state after the session group has been created. It transitions to the Out-of-Service state when a session(s) is added. As sessions come In-Service, the server remains Out-of-Service until a session is selected to be primary. This occurs when the client side sends a START message over an In-Service session. At this point, the server side transitions to the In-Service state. It will remain In- Service unless the Primary In-Service session fails. In this case, it transitions to the Switchover state. In the Switchover state, the server side sets the sm_switchover_timer and waits for the client to make another session primary. If the timer expires, the server side transitions to Out-of-Service. Note that if the currently active session is a secondary session, the server may want to indicate a degradation in service (i.e. In-Service- Degraded). The figure below shows an example of the state diagram for a server side implementation. +---------+ | | | Idle | | | +---------+ | | V +---------+ | | ----| OOS |<--- / | | \ / +---------+ \ session / \ Switchover Timer Primary IS / \ Triggered / \ / \ V | +---------+ Primary IS -> OOS +---------+ | |-------------------->| | | IS | | Recover | | |<--------------------| | +---------+ Session Primary IS +---------+ Auerbach, Berg & Morneault [Page 7] Internet Draft Session Manager Protocol Feb 1999 3.4.2 Client Side The client side supports five states: 1. Idle: a session group has been created 2. Out-of-Service: a session or sessions have been added to the session group, no active session (meaning session is connected but Start message has not been sent). 3. In-Service: one of the highest priority sessions is Primary In-Service 4. Switchover: the active session has failed, try to bring next highest priority session In-Service. 5. IS-Degraded: one of the lower priority sessions is Primary In- Service The client side begins in the Idle state when the session group has been created. It transitions to the Out-of-Service state as soon as a session is added. The client side periodically (sm_retry_timer) tries to bring all the sessions to the In-Service state. Once a session is In- Service, the client determines if it should be transitioned to Primary-In-Service based on priority. The session is made Primary- In-Service by passing a START message to the server side on that session. The client can remove the primary designation of a session by passing a STOP message to the server side on that session. If one of the highest priority sessions is designated as primary, the client transitions to the In-Service. If a lower priority session is designated as primary, the client transitions to the In-Service- Degraded state. If the primary session fails while In-Service, the client side transitions to the Switchover state. In this switchover state, the client does the following: a. Find the highest priority session that is In-Service. If there are multiple high priority sessions, it picks the first. b. If there are no sessions In-Service, it sets the sm_switchover_timer and it tries to bring all sessions In-Service in order of priority. If the switchover timer (sm_switchover_timer) expires, the client transitions to Out-of-Service. c. Once the client has picked the session, it sends a START on that session to transition it to the Primary-In-Service state. The client then transitions its own state to In-Service or In-Service-Degraded based on whether the session is of the highest priority. The figure below shows an example of the state diagram for a client side implementation. Auerbach, Berg & Morneault [Page 8] Internet Draft Session Manager Protocol Feb 1999 +---------+ | | | Idle | | | +---------+ | | V +---------+ | | -------------| OOS |------------- / | | \ / +---------+ \ HPS / ^ \ LPS Primary IS / | \ Primary IS / | Switchover \ / | Timer \ / | Triggered \ V | V +---------+ HPS -> OOS +---------+ LPS -> IS +----------+ | |--------------->| |-------------->| | | IS | | Switch | | IS | | |<---------------| Over |<--------------| Degraded | +---------+ HPS -> IS +---------+ LPS -> OOS +----------+ * HPS = Highest Priority Session LPS = Lower Priority Session 3.4.2.1 Client Side with RUDP When the client side Session Manager is using RUDP as its transport mechanism, it has the opportunity to initiate a session switchover to another session in a session group. In this configuration, the client does the following: a. Receive the CONN_FAIL signal from RUDP which indicates the session has failed (disconnected) b. Find the highest priority session that is In-Service. If there are multiple high priority sessions, it picks the first. c. If there are no sessions In-Service, it sets the sm_switchover_timer and it tries to bring all sessions In-Service in order of priority. If the switchover timer (sm_switchover_timer) expires, the client transitions to Out-of-Service. d. Once the client has picked the session, it sends a START on that session to transition it to the Primary-In-Service state. The client then transitions its own state to In-Service or In-Service-Degraded based on whether the session is of the highest priority. e. If the AUTO_RESET signal has not yet been received from RUDP, Session Manager initiates a state transfer from the failed session to the Primary-In-Service session. RUDP is responsible Auerbach, Berg & Morneault [Page 9] Internet Draft Session Manager Protocol Feb 1999 for ensuring the messages are retransmitted and avoiding the transmission/reception of duplicate messages. 3.5 Redundant MGC Configuration In a redundant MGC configuration, a gateway is connected to an ACTIVE MGC and one or more STANDBY MGC(s). On the gateway side (client side), Session Manager is used to manage ACTIVE/STANDBY state for the signaling application. On the MGC side (server side), the signaling application informs Session Manager of its ACTIVE/STANDBY state. The Primary In-Service state is separated into two states for this mode of operation: 1. Primary In-Service-ACTIVE: session is In-Service and START message has been transferred from client to server, server has transferred ACTIVE notification to client 2. Primary In-Service-STANDBY: session is In-Service and START message has been transferred from client to server, server has transferred STANDBY notification to client 3.5.1 Server Side The server side implementation of this functionality is very straight- forward. The figure below shows the state diagram. The server side supports three states: 1. Idle: a session set has been created 2. Out-of-Service: session group(s) have been added to the session set, a session In-Service. 3. In-Service: a session is Primary In-Service and ACTIVE/STANDBY state has been sent The server initializes to the Idle state when the session set is created. When the session set is created, the initial ACTIVE/STANDBY state is passed as an argument. After the session set has been created, the signaling application can change the ACTIVE/STANDBY state at any time. The server transitions to the Out-of-Service state when a session is created. When a session transitions to the Primary In-Service state, it passes an ACTIVE or STANDBY message to the client. The server then transitions to the In-Service state. Note: The server periodically sends its state (ACTIVE/STANDBY) based on sm_state_timer. The figure below shows an example of the state diagram for a server side implementation. Auerbach, Berg & Morneault [Page 10] Internet Draft Session Manager Protocol Feb 1999 +---------+ | | | Idle | | | +---------+ | | V +---------+ | | | OOS | | | +---------+ | | Session transitions to Primary IS | ACTIVE/STANDBY notification sent V +---------+ | | | IS | | | +---------+ 3.5.2 Client Side The client side implementation is a bit more complex since it needs to act on ACTIVE/STANDBY indications from each server. The figure below shows the state diagram. The client side supports five states: 1. SESS_IDLE State: a Session has been created. 2. SESS_OOS State: a session or sessions have been added to session group, no ACTIVE notification has been received from MGC. 3. SESS_ACTIVE_IS State: a ACTIVE notification has been received over one In-Service session, STANDBY notification has not been received on any available In-Service session(s). 4. SESS_STANDBY_IS State: a STANDBY notification is received, but there is no In-Service Active session available. 5. SESS_FULL_IS State: a session In-Service that has ACTIVE notification and at least one session In-Service that has STANDBY notification. The client side only accepts PDU messages received from the ACTIVE MGC. The client can be configured to send to just the ACTIVE MGC or both the ACTIVE and STANDBY MGCs. The client side session initializes to SESS_IDLE state when the session is created. It transitions to the SESS_OOS state when a session is added, and then waits for an ACTIVE or STANDBY notification. If the notification is ACTIVE, it transitions to SESS_ACTIVE_IS state and informs all the applications using this Session Set that the Session Set is operational. If the notification is STANDBY, it transitions to SESS_STANDBY_IS state. The session that the ACTIVE Auerbach, Berg & Morneault [Page 11] Internet Draft Session Manager Protocol Feb 1999 notification is received on will be called the Active session. The session that the STANDBY notifcation is received on will be called the Standby session. If in the SESS_ACTIVE_IS state, it transitions to the SESS_FULL_IS state if the STANDBY notification is received on any session other than the Active session. If on the other hand, it receives a STANDBY notification on the Active session, it transitions to the SESS_STANDBY_IS state. If in the SESS_STANDBY_IS state, the client transitions to the SESS_FULL_IS state if the ACTIVE notification is received on a session other than the Standby session. If on the other hand, the client receives an ACTIVE notification on the Standby session, it transitions to the SESS_ACTIVE_IS state. If in the SESS_FULL_IS state, the client transitions to the SESS_ACTIVE_IS state if an ACTIVE notification is received on the Standby session and no other Standby session(s) is/are available. Likewise, if in the SESS_FULL_IS state, the client transitions to the SESS_STANDBY_IS state if a STANDBY notification is received on the Active session. The figure below shows an example of the state diagram for a client side implementation. +---------+ | | | Idle | | | +---------+ | | V +---------+ | | -------------| OOS |----------------- / --------->| |<---------- \ / / +---------+ \ \ / / \ \ Active / / Active Standby \ \ Standby IS / / OOS OOS \ \ IS / / \ \ / / \ \ V / \ V +---------+ Standby IS +---------+ Standby IS +----------+ | ACTIVE |--------------->| FULL |-------------->| STANDBY | | IS | | IS | | IS | | |<---------------| |<--------------| | +---------+ Active IS +---------+ Standby OOS +----------+ Auerbach, Berg & Morneault [Page 12] Internet Draft Session Manager Protocol Feb 1999 3.5.2.1 Session Queueing In the redundant MGC configuration, there is a requirement to be able to queue messages on the client side while the MGC is in the process of failover/switchover. The ACTIVE MGC requests that messages be queued using the Q_HOLD Invoke message. The Q_HOLD Response message indicates to the ACTIVE MGC that messages are being queued. At this point, the MGC can freeze its state, transfer that state to the STANDBY MGC, then the MGCs will transition states with the STANDBY MGC becoming ACTIVE. The Q_RESUME Invoke message is used to request that the client begin sending the queued messages to the ACTIVE MGC. The Q_RESET Invoke message is used to request that the client clear (delete) all queued messages. In this SESS_ACTIVE_IS state, if Q_RESET Invoke notification is received the Q_HOLD condition of all the queues associated with the session are cleared and any queued messages are deleted. On the other hand, if Q_RESUME Invoke notification is received, the Q_HOLD condition of all the queues associated with the session are cleared and any queued messages are transferred. If Q_HOLD condition is not set, a Q_RESET Invoke or Q_RESUME Invoke notification are ignored. The same action is taken when Q_RESET Invoke or Q_RESUME Invoke notifications are received in any other state except SESS_IDLE and SESS_OOS states. In this SESS_FULL_IS state, if the client receives a Q_HOLD Invoke notification it will not change state, but the status of all the queues associated with the session is set to Q_HOLD. The Q_HOLD Invoke notification is only acted on in the SESS_FULL_IS state. Once Q_HOLD condition is set for queues, it remains until cleared by Q_RESUME Invoke or Q_RESET Invoke messages. No state transition clears the Q_HOLD condition. 3.6 Session Manager Timers Session Manager uses the following timers: * sm_retry_timer - used to retry connection of Out-of-Service sessions (default is 5 seconds) * sm_switchover_timer - amount of time allowed for a switchover to another session before transitioning to Out-of-Service state (default is 3 seconds) * sm_state_timer (redundant MGC configuration) - the server will send state (ACTIVE/STANDBY) periodically based on this timer (default is 60 seconds) 3.7 Session Manager Counters * sm_unstable_session - alarm trigger - if 20 session recoveries in 60 minutes or less Auerbach, Berg & Morneault [Page 13] Internet Draft Session Manager Protocol Feb 1999 3.8 Session Manager Statistics Statistics should be maintained on a session, session group and session set basis. The application should be able to query and clear the statistics. * number of bytes transmitted * number of PDUs transmitted * number of bytes received * number of PDUs received * number of session switchovers (kept at a session group level) * number of MGC switchovers/failovers - redundant MGC configuration (kept at a session set level) 4.0 Author's Addresses David Auerbach Tel: +1-703-484-3464 Cisco Systems Email: dea@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA Diane Berg Tel: +1-703-484-3461 Cisco Systems Email: dberg@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA Ken Morneault Tel: +1-703-484-3323 Cisco Systems Email: kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA