SGSN Support for Peer-Server Blocking

This chapter describes SGSN support for Peer-Server Blocking.

Feature Description

The validity of SCTP redundancy has to be tested by simulating fail overs when new RNCs/STPs have to be commissioned. Peer-Server Blocking support has been added to prevent any issues during commissioning of new RNCs/STPs.

The Peer Server Blocking feature provides the following functionalities:

  1. The SCTP association can be either brought up or down in order to test the redundancy of the same.

  2. The PSPs can be brought down without removing the configuration.

  3. The SGSN supports a new configuration command under the psp-instance to block/unblock peer endpoint and this configuration is pushed to the Link Manager to achieve peer-server blocking.

  4. The SGSN sends a SCTP Shutdown to the remote endpoint and marks the endpoint as LOCKED when the PSP is configured as blocked and if the PSP is in ESTABLISHED state.

  5. The SGSN initiates a SCTP INIT when a blocked PSP is un-blocked and if the SGSN is a client and is asp-associated.

  6. The SGSN replies with an ABORT when the peer sends INIT in LOCKED state.

  7. The SGSN marks the remote endpoint as LOCKED when the PSP is configured as blocked and if the PSP is in a CLOSED state.

  8. The PSP state is recovered if the Link Manager expires and no messages are initiated after recovery if the PSP is in locked state.

Supported Number of SCTP Links

The SCTP links are configured as PSP instances per peer server.

In releases prior to 21.5, SGSN supports 12 SCTP links per peer server and 12 Link Manager instances. For a fully loaded chassis with 12 Link Manager Instances, 12 Application Server Processes (ASPs) could be configured with each PSP instance mapped directly to one ASP such that loads get equally distributed and also supports redundancy.

In release 21.5, the number of SCTP links that SGSN supports has been increased from 12 links to 32 links. For configuring more than 12 PSPs, the PSP instances must be mapped in a round-robin technique to the ASPs in order to achieve load distribution.

How it Works

The SCTP associations are between PSPs and ASPs. The control to bring down a SCTP association is added at the PSP level. The option for shutdown/no shutdown is added under each PSP configuration. This information is stored in SCT and is forwarded to the Session Controller. The Session Controller sends this configuration request to the Master Link Manager via a messenger call. The Link Manager receives the configuration from the Master Manager. Based on the current association state and the CLI (shutdown/no shutdown ) issued the following actions are taken:

  1. If the CLI shutdown is issued, the shutdown flag is set. When the association is in an ESTABLISHED state, the Link Manager initiates a SCTP SHUTDOWN towards the peer and moves to the LOCKED state after shutdown procedure is completed.

  2. If the CLI no shutdown is issued, the shutdown flag is not set and this serves as a trigger to INIT towards the peer, provided the PSP is already in LOCKED state and SGSN is configured as client. A SCTP INIT is triggered towards the peer. If the association is in any state other than LOCKED state, the configuration is ignored.

The following table provides information on various Peer Server blocking scenarios based on the CLI configuration:

CLI configuration

Current Association State

SGSN Action

Result Association State

shutdown

LOCKED

  1. No action taken.
  2. Association remains in LOCKED state.

shutdown

CLOSED

  1. Association is marked as LOCKED.
  2. SCTP Abort is sent on receiving Init from peer, and the Init is dropped.

LOCKED

shutdown

COOKIE-WAIT

  1. Association is marked as LOCKED.
  2. SCTP Abort is sent for every subsequent Init from peer.

LOCKED

shutdown

COOKIE-ECHOED

  1. Association is marked as LOCKED.
  2. SCTP Abort is sent on receiving Init from peer and the Init is dropped.

LOCKED

shutdown

ESTABLISHED

  1. SCTP SHUTDOWN is initiated
  2. The association is moved to the LOCKED state after SCTP shutdown procedure is complete

LOCKED

shutdown

SHUTDOWN-PENDING

SHUTDOWN-SENT

SHUTDOWN-RECEIVED

SHUTDOWN-ACK SENT

Once the SCTP shutdown procedure is completed the association is moved to the LOCKED state.

LOCKED

no shutdown

LOCKED

If SGSN is the client, an INIT is initiated and the association is moved to COOKIE-WAIT state. If SGSN is the server the association is moved to CLOSED state

COOKIE-WAIT (on triggering INIT)/CLOSED

no shutdown

CLOSED

COOKIE-WAIT

COOKIE-ECHOED

ESTABLISHED

No action required.

No change in state

no shutdown

SHUTDOWN-PENDING

SHUTDOWN-SENT

SHUTDOWN-RECEIVED

SHUTDOWN-ACK SENT

No action required, an Error is displayed until the shutdown procedure completed and PSP is moved to either LOCKED state (if the shutdown procedure is due to a previous "shutdown" on PSP) or CLOSED state (if the shutdown is due to some other reason).

No change in state

Configuring Peer-Server Blocking

The following command is used to configure the Peer-Server Blocking feature:

config 
   ss7-routing-domain routing_domain_id variant variant_type  
      peer-server id server_id 
         psp instance id 
            [ no ] shutdown  
            end 

Notes:

  • In release 21.5, the number of SCTP links that SGSN supports has been increased from 12 links to 32 links.

    psp instance id : In release 21.5, id must be an integer from 1 to 32. In releases prior to 21.5, id is an integer from 1 to 12.

  • On configuring shutdown , the PSP is brought down via a SCTP Shutdown procedure (if association is already ESTABLISHED) or Abort (any other association state) and it is marked LOCKED. The SGSN does not initiate any messages towards the peer and any message from the peer will be responded with a SCTP Abort, when the PSP is in a LOCKED state.

  • On configuring no shutdown , the PSP is marked unlocked and the SGSN initiates an association establishment towards the peer. This is the default configuration for a PSP. The default is no shutdown .

Listed below are the error codes added to support the Peer-Server blocking feature:

  • Once the CLI is configured if the operator tries to re-configure the same CLI again, a CLI failure is displayed. This suppresses the Link Manager error logs while trying to push same configuration twice.

    The error code displayed is:

    Failure: PSP: Re-configuring same value

  • During an ongoing shutdown procedure if the command no shutdown is executed, the execution of the command will be unsuccessful and a CLI failure error message is displayed.

    The error code displayed is:

    Cannot unlock PSP during ongoing shutdown procedure

    This ensures that the shutdown procedure is graceful. The command no shutdown can be configured only when there is no ongoing shutdown procedure.

Verifying the Peer-Server Blocking Configuration

Use the following show command to verify the Peer-Server Blocking configuration:

show ss7-routing-domain num sctp asp instance num status peer-server id  num peer-server-process instance num 

The field Association State is displayed as LOCKED when the PSP is locked via the shutdown CLI.

Monitoring and Troubleshooting the Peer-Server Blocking

The following traps are generated on locking a PSP via shutdown CLI:

  • SCTPAssociationFail

  • M3UAPSPDown

  • SS7PCUnavailable

  • M3UAPSDown

The trap M3UAPSPDown additionally indicates the cause, the cause value indicated is Administrative-Shutdown.