Packet Flow Description Management Procedure for Static and Predefined Rules
Feature Description
How It Works
- Moving Bulk Configurations from Control Plane to User Plane
  - Limitation
- Sx Association
  - Configuring Control Plane Group
  - Monitoring and Troubleshooting Sx Association
    - SNMP Trap
    - Show Commands and/or Outputs
Monitoring and Troubleshooting
- Show Command(s) and/or Outputs

Packet Flow Description Management Procedure for Static and Predefined Rules

Feature Description

The Packet Flow Description Management Procedure feature allows control plane to configure static and predefined rules and other charging information on the User Plane.

How It Works

Prior to CUPS, static and predefined rule processing was dependent on Rule-Def, Rule-Base, and Charging-Action. Rules-Base indicates the priority in which order static rules are needed to be matched and also provide associated charging action.

With the CUPS architecture, to process L3/L4 static and predefined rules, rule-def, rule-base, and charging-action need to be available at the User Plane. Using the PFD management message, control plane sends all this information to the associated User Plane.

To send this information from Control Plane to User Plane, CUPS architecture uses the following two modules:

Sx-U Demux: Handles all node level messages with different Control-Plane nodes.
Sx-C Demux: Handles node level message exchange with User-Plane service, that is, PFD management messages, Sx-association messages, Heartbeat related messages.

Once the Control-Plane is initialized with all the configuration and User-Plane is initialized with initial configuration, the PFD management request message is initiated using the debug mode CLI command. See to the Monitoring and Troubleshooting section for the debug command.
Once the debug CLI command is executed, the Sx-C demux pushes all the Rule-Def, Rule-Base, and Charging-Action configuration to the User-Plane using PFD management request or response message.
After the Sx-U demux on the User-Plane receives the PFD management request message, it decodes the configuration and sends it to each session manager instance at the User-Plane node and stores it in the SCT.

Moving Bulk Configurations from Control Plane to User Plane

A set of configurations can be pushed from the Control Plane (CP) to the User Plane (UP) using the push config-to-up all CLI command. A configuration timer constantly runs at the session controller. On expiration of this timer, various types of configurations in bulk are pushed to all designated session managers. The session controller maintains skip lists of various configuration types received from the CP. As and when the Sx Demux pushes the configuration, they are stored in skip lists based on the configuration type.

When the skip list reaches its maximum length, the entire list - for a particular configuration type, is pushed from the session controller to all session managers. This provision reduces the number of messenger events/messages between proclets as the configurations are sent in a single message rather than sending one message for each configuration.

The following configuration types supported for a bulk configuration push:

Ruledef
Charging Action
Action Priority Lines
Routing Rule configuration
Group of Ruledef configuration
Rule in Group of Ruledef configuration
Rulebase L3/L4/L7 Info configuration
APN configuration
ACS Service configuration
Service Chain configuration
NSH Format
NSH Field
Traffic Steering Group
Host pool configuration in ECS
Port Map configuration in ECS
Service scheme framework configuration in ECS
X-header format in ECS
Content filtering category Policy IDs in ECS

Currently, configuration propagation from CP to UP occurs only when Sx Association happens between CP and UP upon UP registration, or when push config-to-up all CLI is triggered. During configuration propagation, all the configurations are pushed from CP to UP. After UP registration occurs, when a new configuration is added or existing configuration is modified, the UP has to be rebooted for registration to receive the updated configuration from CP. This is because configuration updates are not propagated to UP for now.

When the push config-to-up all CLI is executed, the entire configuration is propagated to all the registered/associated UPs. The configuration can be propagated to a specific UP as well by giving the peer address as input. The configuration is pushed only to UPs that are associated with the CP.

The push config-to-up all CLI does not delete any existing configuration on the UP and also does not flush out any unwanted configuration in UP, which is not present in CP. The configuration from CP merges with what is currently present in UP. The existing configuration on UP is not flushed out. The configuration audit between CP and UP is not supported.

Rule, Rulebase action priority, Host pool, and Port Map removal through configuration on CP leads to automatic push from CP to UP. Rule addition or modification requires push through the CLI.

Support for rule-lines modifications (addition or deletion) are added in the ruledef. The changed rule-lines are the candidate for rule matching for the existing flows, the new flows, or the new calls.

In CUPS (without RCM), modifications are done in Control Plane and pushed to User Plane via PFD mechanism. In CUPS (with RCM), changes are done in RCM and pushed to User Plane. Changes are done parallelly and separately in Control Plane.

The following table provides information about the impact of configuration change in new and existing calls.


Change in Configuration	Impact on existing calls (existing flows)	Impact on existing calls (new flows)	Impact on new calls
Existing Ruledef contents/New Rule addition	Rule match is enforced on existing flows after configuration change.	The configuration changes apply on new flows. For new flows, anyways fresh rule match would happen and the ruledef changes are applied on new flows for existing calls	The configuration changes apply on new calls. For new flows, anyways fresh rule match would happen and the ruledef changes are applied on flows for new calls.
No Ruledef	Rule in use cannot be deleted unless its action priority is deleted from the rulebase.	Rule match is enforced on existing flows after configuration change.	The configuration changes apply on new calls.
New Group of Ruledefs (GoR)/Changes to existing Group of Ruledefs contents (Add or Delete Rule in GoR)	Rule match is enforced on existing flows after configuration change.	The configuration changes apply on new flows. For new flows, anyways fresh rule match would happen and the GoR changes are applied on new flows for existing calls.	The configuration changes apply on new calls. For new flows, fresh rule match would happen, and the GoR changes are applied on flows for new calls.
No GoR	Rule in use cannot be deleted unless its action priority is deleted from the rulebase.	Rule match is enforced on existing flows after configuration change.	The configuration changes apply on new calls.
No Rule in GoR	Rule match is enforced on existing flows after configuration change.	New flows go through a fresh rule match and configuration change takes effect.	New flows go through a fresh rule match and configuration change takes effect.
Action Priority Changes/Action Priority addition	Configuration changes apply on existing flows.	Configuration changes apply on new flows.	Configuration changes apply on new calls.
No Action Priority	Configuration changes apply on existing flows.	Configuration changes apply on new flows.	Configuration changes apply on new calls.
No-Rulebase	No-Rulebase is not supported.	No-Rulebase is not supported	No-Rulebase is not supported
No-APN	No-APN is not supported	No-APN is not supported	No-APN is not supported
IP source violation	No impact on existing calls	No impact on existing calls	Configuration changes apply on new calls.

Limitation

When CP is on VPC-DI, delay in PFD configuration push from CP to UP may be observed on systems with bulk configurations in CP that is connected to large number of UPs.

The delay is caused as VPC-DI is a multi-card chassis, with an inter-card communication process, that takes some time to fetch configurations from Shared/System Configuration Task (SCT) for each peer UP.

When CP is on VPC-SI, the delay is not observed.

Sx Association

Important

This feature is not fully qualified in this release. It is available only for testing purposes. For more information, contact your Cisco Account representative.

In CUPS environment, the Control Plane and User Plane entity should perform association with each other before establishing communication.

The Sx Association procedure is defined in 3GPP TS 29.244. As these are node level messages, they are handled by Sx-C Demux on Control Plane and Sx-U Demux on User Plane.

Call Flow

Following is a brief overview of how Sx Association works:

Sx Association Setup Request is initiated by Control Plane or User Plane.

Important

In this release, only Sx Association Setup Request from User Plane is supported.

For User Plane to initiate Sx Association Setup Request, Operator should configure control-plane-group at Global Configuration mode and associate control-plane-group to User Plane Service. Refer Configuring Sx Association Setup Request section of this chapter.
Peer node ID (which is, currently, either IPv4 or IPv6 address) is configured in control-plane-group .
Currently, on User Plane, the Sx-U Demux uses Sx-Service Address (as it is on Node Id) which is sent into Sx Association Setup Request. Selection of IPv4 and IPv6 is depended on the configured peer-node-id .
After User Plane Service is up on User Plane, Sx-U Demux sends Sx Association Request toward Control Plane. Sx-C Demux validates and sends Sx Association Response toward User Plane.
After Control Plane processes Sx Association Request and sends response to User Plane, it starts Prime PFD message toward User Plane to send the configuration. Also, Control Plane starts Heartbeat procedure with the associated User Plane.
After receiving Sx Association Response, User Plane also starts Heartbeat procedure toward Control Plane.
If Control Plane is not ready (SAEGW Service is not up) when it receives Sx Association Setup Request, it rejects the Sx Association Setup Request. The User Plane reattempts Sx Association Set-up Request after association reattempt-timeout . Refer the Configuring Sx Association Reattempt Timeout section of this chapter.

Release of Sessions for a Specific User Plane

To bring down a specific User Plane, it is recommended to first clear all subscribers that belong to that User Plane using the following CLI command:

clear subscribers saegw-only uplane-address user_plane_address no-select-up

Executing this CLI command releases all sessions that belong to the mentioned User Plane, gracefully, and marks that User Plane as "Not Available for Session Selection". This User Plane remains in Associated state but it will not be available for Session selection.

After clearing the session, execute either of the following CLI command on User Plane to remove its association from Control Plane.

no user-plane-service service_name

no peer-node-id { ipv4-address ipv4_address | ipv6-address ipv6_address }

For additional information about the above CLI commands, refer Configuring User Plane Service and Configuring Peer Node ID sections in this guide.

To release only the existing sessions from a User Plane, use the following CLI command:

clear subscribers saegw-only uplane-address user_plane_address

In this case, note that the User Plane remains in Associated state and available for Session selection.

Note

When the clear subscribers command is executed on UP, CP will not be informed and will consider the sessions as running.

ICSR Support

For Sx-Control Plane, Demux ICSR is supported. All associated Peer information is checkpointed to Standby Chassis Sx-Control Plane Demux through the Session manager.

Demux Recovery Support

Sx-Control Plane Demux recovery and unplanned Demux card migration is supported. During recovery, all associated Peer information is recovered from the Session manager to Sx-Control Plane Demux.

Currently, after Sx-Demux recovery, the Sx-Control Plane Demux does not perform audit with respective VPNmgr for peer entries and Peer ID. In case of any error, it can lead to call drop and out-of-sync situation between VPNMgr and SxMgr related to IP pool management and UP selection.

Configuring Control Plane Group

Use the following CLI commands to configure Control Plane Group under Global Configuration mode. The Control Plane Group lists the Control Plane endpoints to which the User Plane will be associated

configure 
   [ no ] control-plane-group control_plane_group_name 
   end

NOTES:

control-plane-group control_plane_group_name : Configures Control Plane Group on User Plane. The control_plane_group_name should be a string of size 1 to 63.
If previously configured, use the no control-plane-group control_plane_group_name CLI command to remove the Control Plane Group configuration

Configuring Sx Association

This sections describes the CLI commands available in support of this feature.

Configuring Sx Association Setup Request

Use the following CLI commands to enable the attributes related to Peer Node IDs and Sx Association under Control Plane Group Configuration mode.

configure 
   control-plane-group control_plane_group_name 
      sx-association { initiated-by-cp | initiated-by-up } 
      end

NOTES:

sx-association : Configures Sx Association Setup Request that is initiated by Control Plane or User Plane. The default value is initiated-by-up .

initiated-by-cp : Sx Association Setup Request will be initiated by Control Plane.

Important

This keyword is not supported in this release.

initiated-by-up : Sx Association Setup Request will be initiated by User Plane.

Associating Control Plane Group with User Plane Service

Important

Associating Control Plane Group with User Plane service is an optional parameter for User Plane service to come up. If there is Control Plane Group that is associated with User Plane, and as per its configuration it is supposed to start a Sx association, then the User Plane sends Sx Association Request to the defined Control Plane endpoint.

Use the following CLI commands to associate User Plane service with Control Plane Group.

configure 
   contextcontext_name 
      user-plane-service service_name 
         [ no ] associate control-plane-group control_plane_group_name 
         end

NOTES:

no : Removes Control Plane Group association from User Plane service.
control-plane-group control_plane_group_name : Associates Control Plane Group with which User Plane service performs Sx Association. The Control Plane Group name should be a string of size 1 to 63.

For more information about User Plane Service Configuration mode and it's relevant CLI commands, refer the Configuring User Plane in CUPS chapter.

Configuring Peer Node ID

Use the following CLI commands to configure Control Plane node IDs.

configure 
   control-plane-group control_plane_group_name 
      [ no ] peer-node-id { ipv4-address ipv4_address | ipv6-address ipv6_address } 
      end

NOTES:

no : Removes the followed option.
ipv4-address : Configures IPv4 address.
ipv6-address : Configures IPv6 address (supports colon-separated hexadecimal notation).
The peer-node-id is the Control Plane sx-service address which should be started, and should receive and answer Setup requests.
Currently, five node IDs can be added to the Control Plane group.

Configuring Sx Association Reattempt Timeout

Use the following configurations for Association Reattempt Timeout for Sx service.

configure 
   context context_name 
      sx-service service_name 
         sx-protocol association reattempt-timeout timeout_seconds 
         end

NOTES:

association : Configures Sx Association parameters.
reattempt-timeout timeout_seconds : Configures the Association Reattempt timeout for Sx Service, in seconds, ranging from 30 to 300. Default is 60.
After User Plane starts, it waits for 2 minutes on SSI and 10 minutes on ASR 5500 to start Association Setup with Control Plane. This is done to make sure that the User Plane system is fully ready to handle configuration messages that are sent from the Control Plane after Association Setup. These values can be changed using reattempt-timeout.

Configuring Sx Association SNMP Traps

When an Sx association is detected, an SNMP trap (notification) is automatically generated by the system.

Use the following configuration to enable an SNMP trap when an Sx association is detected:

configure 
   snmp trap enable SxPeerAssociated 
   end

Use the following configuration to enable an SNMP trap when there is a Sx association release::

configure 
   snmp trap enable SxPeerAssociationRelease 
   end

Moving Bulk Configurations from Control Plane to User Plane

Use the following configuration to move bulk configurations from Control Plane to User Plane:

push config-to-up all peer-ip-addrIP_Address

NOTES:

all : Pushes the configurations to all associated User Planes.
peer-ip-addr : Pushes the configurations to a specified User Plane. The User Plane should be associated to receive the configuration.IP_Address (IPv4 or IPv6) specifies the IP address of the User Plane node.
IP Pool related configurations are not pushed using the above configuration.

Monitoring and Troubleshooting Sx Association

This section provides information about CLI commands available for monitoring and troubleshooting the Sx Association procedure.

SNMP Trap

The following traps are available to track the status of an Sx Association:

sn_trap_sx_peer_node_associated: An information trap which is triggered when an Sx association is detected. The following information is shared with both Control Plane and User Plane:
- Context Name
- Service Name
- Node Type
- Node ID
- Peer Node Type
- Peer Node ID
- Group-Name
sn_trap_sx_peer_node_association_release: An information trap which is triggered when an Sx association release is detected. The following information is shared with both Control Plane and User Plane:
- Context Name
- Service Name
- Node Type
- Node ID
- Peer Node Type
- Peer Node ID
- Group-Name

Show Commands and/or Outputs

This section provides information regarding show commands and/or their outputs in support of Sx Association.

show control-plane-group all

The ouput of this show command displays fields in support of Sx Association.

Control Plane Group
- Name:
- Sx-Association:
- Node-Id:
- Node-Id:

show user-plane-service name <name>

The output of this show command displays the following fields in support of Sx Association.

Service name
- Service-Id
- Context
- Status
- PGW Ingress GTPU Service
- SGW Ingress GTPU Service
- SGW Egress GTPU Service
- Control Plane Tunnel GTPU Service
- Sx Service
- Control Plane Group

show sx peers

The output of this show command displays the fields in support of Sx Association.

Node Type:
- (C) - CPLANE
- (U) - UPLANE
Peer Mode:
- (A) - Active
- (S) - Standby
Association State:
- (i) - Idle
- (I) - Initiated
- (A) - Associated
- (R) - Releasing
Configuration State:
- (C) - Configured
- (N) - Not Configured
IP Pool:
- (E) - Enable
- (D) - Disable
Sx Service ID
Group Name
Node ID
Peer ID
Recovery Timestamp
No of Restart
Current Sessions
Max Sessions

show snmp trap history

The output of this command includes the following fields:

Timestamp
Trap Information

Monitoring and Troubleshooting

This section provides information regarding the debug command and show commands and/or their outputs in support of this feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.