Flow Checkpoint Support for ADC Rules

This feature adds Flow Checkpoint support for ADC rules after ICSR/SR switchover.

Feature Information

Summary Data

Status

Modified Functionality

Introduced-In Release

21.1

Modified-In Release(s)

21.2

Applicable Product(s)

GGSN, P-GW, SAEGW

Applicable Platform(s)

ASR 5500

Default Setting

Enabled. This is CLI controlled feature and the same CLI which was used in "Flow Recovery Support for ECS Rules" feature to configure flow-recovery will enable this as well.

Related CDETS ID(s)

CSCvc48853

Related Changes in This Release

Not Applicable

Related Documentation

ECS Administration Guide

Revision History


Important

Revision history details are not provided for features introduced before release 21.2.

Revision Details

Release

Release Date

Modified in this release.

21.2

April 27, 2017

Feature Changes

Cisco P-GW supports ICSR/SR check pointing at session level. The Flow Recovery feature was introduced to support flow checkpoint for ECS rules.

This feature adds Flow Checkpoint support for ADC rules after ICSR/SR switchover. Flows of a rule can be recovered if the rule is made eligible. To make any rule eligible for checkpointing or recovery, the rule must be configured in the service scheme framework and identified based on rulename. Any type of rule can be eligible for checkpointing irrespective of the rule definition or protocol type. The rule type can be static/predefined, group-of-ruledef, dynamic, or ADC rule.

When this feature is implemented, the following things are avoided:

  • Default rule being matched post recovery or ICSR switchover.

  • Flow charging when they are zero rated or not charged.

  • Different or incorrect policy being applied to the data.

Behavior Changes

Previous Behavior 1: For configuring multiple rules for flow recovery, a single trigger condition was sufficient as it was possible to add all eligible rules under it along with the delay. If a flow matches any of the configured eligible rules, P-GW started checkpointing the flow after the configured period of delay.

Example: Rule rule01, rule02, and rule03 are eligible for flow recovery. Flow should be checkpointed after 60 sec of flow creation. 

trigger-condition tc1
rule-name = rule01
rule-name = rule02
rule-name = rule03
delay = 60
#exit

The above configuration enabled P-GW to checkpoint flows matching either rule01, rule02, or rule03 after a delay of 60 seconds.

New Behavior 1: With this feature, there is a change in the way flow recovery is configured on the chassis. A new CLI command multi-line-or all-lines under trigger condition. Because of this delay cannot be configured along with multiple rules in same trigger condition. If there is a need to configure delay, then you must create multiple trigger condition (one for each rule).

Example with new configuration: 

trigger-condition tc1
rule-name = rule01
delay = 60
#exit
trigger-condition tc2
rule-name = rule02
delay = 60
#exit
trigger-condition tc3
rule-name = rule03
delay = 60
#exit

The above configuration enables P-GW to checkpoint flows matching either rule01, rule02, or rule03 after a delay of 60 seconds.

Configuration for multiple rules without delay: 

trigger-condition tc1
rule-name = rule01
rule-name = rule02
rule-name = rule03
multi-line-or all-lines
#exit

Previous Behavior 2: ULI was not sent with "successful_resource" allocation CCR-U, if there is no change in the ULI.

New Behavior 2: ULI is sent with "successful_resource" allocation CCR-U, even if there no change in the ULI. Old value of ULI is encoded and sent.

Relationships to Other Features

This sections describes the relationship of the Flow Checkpoint Support for ADC Rules feature with other supported features.

Feature Interaction

The following table describes the impact to inline services with the Flow Checkpoint Support for ADC Rules implementation.

The behavior applies to recovered flows unless explicitly mentioned.

Inline Services

Flow Recovery Impact

Description

CF Static and Dynamic

No

Post recovery, CF redirect and CF blacklist will not work and packets will be allowed.

ICAP

No

Post recovery GET messages for the recovered flow will not be forwarded to ICAP server.

Tethering Detection

No

For IP-TTL based tethering detection, the post recovery flow will be considered as tethered if the first packet post recovery is uplink packet and will be considered as non-tethered..

For OS-DB signature based tethering detection, the post recovery flow will be considered as tethered if the SYN packet received post recovery has matching signature in the database.

Post processing rules

No

URL Redirect for recovered flows will not be supported based on post processing rules. The default action "Discard" will be applied.

X-Header insertion

No

X-header insertion will not work for recovered rules.

DSCP/IP-TOS Marking

Yes

Packets will be marked post recovery with correct DSCP/IP-TOS values.

Idle-timeout handling

Yes

The flow is terminated after idle timeout and checkpoint limits are decremented.

TCP based application Protocol

No

Analyzer will not be engaged for recovered flows.

UDP Based application Protocol

Yes

Analyzer will be engaged for recovered flows if configured in rulebase.

ICSR

Yes

Flows will be recovered to match the last match rule pre ICSR and for which checkpoint was successful.

Session Recovery

Yes

Flows will be recovered to match the last match rule pre SR and for which checkpoint was successful.

IPv6

Yes

IPv6 flows will be recovered.

Charging Methods

The following table describes the impact to ECS charging methods with the flow checkpoint support for the ADC Rules feature implementation.

The behavior applies to recovered flows unless explicitly mentioned.

Charging Method

Flow Recovery Impact

eGCDR

No

PGW-CDR

No

VoGx

No

Gy

No

RF

No

EDR

For P2P we will not recover field P2P app-identifier(SNI) and P2P duration

FDR

No

UDR

No

How It Works

This section describes the working of this feature.

  • Flows of a rule is eligible for recovery if the rule is made eligible for flow recovery under policy framework service scheme.

  • The number of flows checkpointed/recovered is limited at per subscriber call level as per the configuration at active-charging service level.

  • The number of flows checkpointed/recovered is limited at per sessmgr instance level which will not be a configurable value.

  • The eligible flow(s) is/are checkpointed in the following cases:

    • Post flow establishment, the delay timer configured in the policy framework service scheme for matching rule expires.

    • Limit for number of recovered flows is not reached

  • Any flow which has been recovered will continue matching the last matched checkpointed rule irrespective of a higher precedence rule available later. If the last matched checkpointed rule for a flow is removed, will match to rules based on L3/L4 definition.

  • Any flow for which delay timer has not expired and which was not checkpointed, will match the rules based on L3/L4 definition after recovery.

Sample Configuration

This section lists sample configuration for configuring P2P rules.

In order to make a P2P rule eligible for checkpoint, the rule needs to be configured in the policy framework service scheme under trigger-condition and then associated with the flow-recovery trigger-action.

Configuring P2P Rule for the Youtube 


configure 
  active-charging service service_1 
    ruledef rule_youtube 
       p2p protocol = youtube 
       p2p traffic-type = file-transfer 
    #exit 
    rulebase base_1 
       action priority 1 ruledef rule_youtube charging-action ca_edr 
end

Configuring P2P Rule Youtube for Flow Recovery 


active-charging service ACS 
    trigger-action action1 
      flow-recovery 
    #exit 
    trigger-condition tc1 
      rule-name = rule_youtube 
      delay = 600 
    #exit 
    service-scheme scheme1 
      trigger flow-create  
      priority 1 trigger-condition tc1 trigger-action action1  
    #exit 
  #exit 
end

Limitations

Due to memory and performance impact only selected P2P field will be recovered for EDR, that is, P2P Protocol, P2P Protocol Group, and P2P Traffic Type.

Important

All the limitations mentioned in the "Flow Recovery" feature are applicable for this feature as well.