Cisco Cisco ASR 5000 Technical Manual
For Dynamic PCC rules installed by PCRF, per SDF level policing at the PGW is applied based on
the PCC rule level QOS data rates. Traffic hitting this Dynamic PCC rule would be policed with
respect to PCC-rules MBR data-rate. Any packet exceeding the configured MBR would be
discarded. Policing is achieved by maintaining token counts at flow level.
the PCC rule level QOS data rates. Traffic hitting this Dynamic PCC rule would be policed with
respect to PCC-rules MBR data-rate. Any packet exceeding the configured MBR would be
discarded. Policing is achieved by maintaining token counts at flow level.
For Static rules or PCRF activated Pre-Defined rules, PGW (PCEF) could have ITC (Intelligent
Traffic Control) policing applied at SDF level based on the flow limits configured in the charging
actions. Traffic hitting these rules with their charging actions having flow limits configured, would
be policed on these flow limit values .For Static and Predefined rules Policing will be done for both
MBR and GBR (if applicable) data-rate. Depending on the threshold exceed option configured in
the charging action (violate-action <value> OR exceed-action <value>), the packets would be
either discarded or TOS remarked to zero. Policing is achieved by maintaining token counts at
content-id level.
Traffic Control) policing applied at SDF level based on the flow limits configured in the charging
actions. Traffic hitting these rules with their charging actions having flow limits configured, would
be policed on these flow limit values .For Static and Predefined rules Policing will be done for both
MBR and GBR (if applicable) data-rate. Depending on the threshold exceed option configured in
the charging action (violate-action <value> OR exceed-action <value>), the packets would be
either discarded or TOS remarked to zero. Policing is achieved by maintaining token counts at
content-id level.
CLI for configuring the ITC policing functionality in charging action is as follows:
Note: For SDF level policing burst size can be only configured as a fixed size. No auto-readjust
option is provided.
option is provided.
DSCP marking support
PGW supports DSCP marking of the data packets that are transmitted over the EPS bearers.
DSCP levels can be assigned to specific traffic patterns in order to ensure that data packets are
delivered according to the precedence with which they’re tagged. The DifServ markings are
applied to the IP header of every subscriber data packet transmitted over the S5/S8/SGi
interface(s). PGW support DSCP marking for both IPv4 and IPv6 data packets. DSCP marking in
IP header is done as per IETF RFC 2474.
DSCP levels can be assigned to specific traffic patterns in order to ensure that data packets are
delivered according to the precedence with which they’re tagged. The DifServ markings are
applied to the IP header of every subscriber data packet transmitted over the S5/S8/SGi
interface(s). PGW support DSCP marking for both IPv4 and IPv6 data packets. DSCP marking in
IP header is done as per IETF RFC 2474.
In Cisco ASR5x00 Based PGW, DSCP marking is enabled in PGW by associating
A QCI-QOS table in a PGW service config or it can be configured on per-APN basis , QCI-table
associated in APN take precedence for a call. By default if there is no any QCI-QOS mapping
Table associated, so by default DSCP marking is disabled on PGW. QCI-QoS mapping tables are
used to map QCI values to appropriate QoS parameters.
associated in APN take precedence for a call. By default if there is no any QCI-QOS mapping
Table associated, so by default DSCP marking is disabled on PGW. QCI-QoS mapping tables are
used to map QCI values to appropriate QoS parameters.
QCI-QOS mapping table is used to configure DSCP marking config. Below is the CLI for DSCP
marking config for a QCI (num) in uplink/downlink direction:
marking config for a QCI (num) in uplink/downlink direction:
Syntax
For example:
Above CLI is configured for each QCI (standard range of 1-9) and for each direction (uplink or
downlink). By default no any config exists for a QCI for a direction then no any DSCP marking is
done, so explicit config is needed to enable DSCP marking. Using this CLI you can configure the
DSCP value to be marked for both outer (Tunnel IP header using “encaps-header” option) IP
header and/or even the DSCP value to be marked in the inner (Payloads IP header using
“userdatagram” option) IP header of the Tunnel packet. For outer header marking you can
configure to copy the inner (using “copy-inner” option) IP headers DSCP marking or a specific
value (using “dscp-marking” option). In the Uplink direction the Tunnel could be a SGi tunnel like
IP-in-IP, GRE or others. In the Downlink direction the Tunnel will be a GTPU tunnel on the
S5/S8/Gn interface.
downlink). By default no any config exists for a QCI for a direction then no any DSCP marking is
done, so explicit config is needed to enable DSCP marking. Using this CLI you can configure the
DSCP value to be marked for both outer (Tunnel IP header using “encaps-header” option) IP
header and/or even the DSCP value to be marked in the inner (Payloads IP header using
“userdatagram” option) IP header of the Tunnel packet. For outer header marking you can
configure to copy the inner (using “copy-inner” option) IP headers DSCP marking or a specific
value (using “dscp-marking” option). In the Uplink direction the Tunnel could be a SGi tunnel like
IP-in-IP, GRE or others. In the Downlink direction the Tunnel will be a GTPU tunnel on the
S5/S8/Gn interface.