Behavior of IDFT Feature in StarOS

Introduction 

This document describes the behavior of the Indirect Forwarding Tunnel (IDFT) Feature in Control and User Plan Separation (CUPS) and legacy/baremetal setup.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• StarOS
• Serving Gateway(SGW) function related to IDFT

Components Used

The information in this document is based on the SGW - 21.25.9 (in legacy and CUPS) software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

SGW supports IDFT procedures for creation and deletion, which are applicable for Pure-S and Collapsed calls with multi-Packet Data Network (PDN) and multi-bearers. This feature is applicable for IDFT support with or without SGW relocation and collision scenarios.

The IDFT feature supports these functionalities:

• Create IDFT request for Collapsed, Pure-S, a combination of Collapsed and Pure-S multi-PDN calls with multiple bearers.

• Data transfer on downlink and uplink IDFT bearers.
• Deletion of IDFT request from Mobility Management Engine (MME). Also, timer-based deletion of IDFT bearer after expiration of a default value of 100 seconds, if the MME does not send an IDFT request for deletion.

• Deletion of IDFT PDN, which includes Clear/Delete subscribers from MME/P-GW, when normal PDN goes down.

• Sx-Path Failure Handling in case of Pure-S and collapsed calls at the time of IDFT Active/IDFT Create Sx-Pending state.

• Message interaction and collision at the time of IDFT PDN establishment or deletion with any other procedure.
• S11/S5 and Sx-Path Failure Handling on non-IDFT PDN is now supported when IDFT PDN is Active.

Configure IDFT

This section describes the CLI commands available in support of the IDFT feature.

On Control Plane, use these CLI commands to enable or disable the IDFT feature.

configure

   context context_name

      sgw-service service_name

          [ default | no ] egtp idft-support

       end

Problem 

SGW Processes the Create IDFT Request even when the feature is off. This behavior is seen in legacy/baremetal nodes.

Here is the IDFT configuration present in the node:

sgw-service SGW-SVC

      accounting context EPC gtpp group default

      accounting mode gtpp

      associate ingress egtp-service S11-SGW

      associate egress-proto gtp egress-context EPC egtp-service S5-S8-SGW

      no egtp idft-support                                                                                           ---> IDFT feature is off in the node.

Analysis

The traces and debug logs are taken through simulation of this scenario in the lab and the behavior of Create IDFT Request and Create IDFT Response is seen.

1) MME sends the Create IDFT Request to SGW.

2) SGW processes the request and sends the response Create IDFT Response back to MME with the cause 'Request accepted'.

In this Create IDFT Response it is expected that SGW must send Create IDFT Response with the cause 'Data Forwarding not supported' as this feature is disabled in the configuration.

The same configuration is used in the CUPS setup:

1) MME sends the Create IDFT Request to SGW.

2) SGW processes the request and sends the response Create IDFT Response back to MME with the cause 'Data Forwarding not supported'.

From the admin guide, to enable this feature you need to perform these steps:
On Control Plane, use these CLI commands to enable or disable the IDFT feature.

configure

   context context_name

      sgw-service service_name

         [ default | no ] egtp idft-support

         end

If you follow these steps in legacy to enable/disable the service, you cannot see any options to toggle it.

[sgw]TITAN-ULTRA-001(config-sgw-service)# egtp

  cause-code           - Configuration to related to handling failure response from peer

  change-notification-req - Configuration related to handling change notification request

  modify-bearer-req    - Configuration related to handling Modify Bearer Request

[sgw]TITAN-ULTRA-001(config-sgw-service)# no egtp

  cause-code           - Configuration to related to handling failure response from peer

  change-notification-req - Configuration related to handling change notification request

  modify-bearer-req    - Configuration related to handling Modify Bearer Request

When you try to enable/disable it in the CUPS setup, it shows the option to toggle it.

[SAEGW]saegw-cp1(config-sgw-service)# egtp

  cause-code           - Configuration to related to handling failure response from peer

  change-notification-req - Configuration related to handling change notification request

  idft-support         - Enable/Disable the IDFT Feature for CUPS. By default, it is disabled

  modify-bearer-req    - Configuration related to handling Modify Bearer Request

[SAEGW]saegw-cp1(config-sgw-service)# egtp

  cause-code           - Configuration to related to handling failure response from peer

  change-notification-req - Configuration related to handling change notification request

  idft-support         - Enable/Disable the IDFT Feature for CUPS. By default, it is disabled

  modify-bearer-req    - Configuration related to handling Modify Bearer Request

Solution

The reason for this behavior is described here:

Legacy behavior:

- There was no CLI in legacy to control IDFT behavior.

- IDFT is always supported in legacy code.

CUPS behavior:

- The CLI is license controlled, that is, it is available only with a CUPS license.

- It can be enabled/disabled in CUPS.