The following restrictions apply to the Cisco 7600 series router only.

• Queueing features are not supported in the ingress (incoming) direction of a router in an IP session. This means that traffic shaping, priority queueing such as low latency queueing (LLQ), class-based weighted fair queueing (CBWFQ), and weighted random early detection (WRED) are not supported. Features that can be configured are traffic policing and traffic marking in either the class-default class or any of the user-defined classes, as shown in the following example:

 policy-map sess_ingress
  class c1
   police 2000000
   set ip precedence 4
  class class-default
   police 5000000
   set ip precedence 1 

Note	This restriction does not apply at the subinterface level in the ingress direction. That is, LLQ and traffic shaping are supported in the ingress direction. CBWFQ and WRED are not supported. For more information, see the "IP Subscriber Awareness over Ethernet module.

• A policy map (in the egress direction) used in an IP session can have only packet marking enabled in the user-defined class. No other QoS features (for instance, traffic policing, LLQ, WRED, or traffic shaping) can be enabled. This means that the simplified configuration shown below would not be supported.

policy-map sess_egress
 class c1
  police/priority/bandwidth/wred/shape

The simplified configuration shown below would be supported.

policy-map sess_egress
 class c1
  set <name> <value>

However, all QoS features can be configured in the class-default class, as illustrated below.

policy-map sess_egress
 class class-default
  police/priority/bandwidth/wred/shape/set

• A hierarchical policy map (in the egress direction) on a IP session is supported, but the child policy map must be attached to the class class-default of the parent policy map as illustrated in the simplified configuration below.

policy-map sess_egress
 class class-default
  <Queueing feature like traffic shaping or bandwidth remaining ratio>
  service-policy child

Note	None of the restrictions that apply to a "flat" policy map (that is, a policy map not in a hierarchical policy map structure) in the egress or outgoing direction on a session apply to the child policy map. A simplified configuration illustrating this point is shown below.

 policy-map child
  class voip
   police 9000
   priority level 1
  class iptv
   police 4193000
   priority level 2
   set cos 4
  class gaming
   bandwidth 1000 (kbps)
  class class-default
   set cos 1

Traffic in both the ingress and egress direction can be classified (matched) on the basis of characteristics or attributes such as the following:

• Ip precedence value
• Differentiated services code point (DSCP) value
• Class of service (CoS) value and CoS-inner value (of a Layer 2 QinQ packet)
• Access control list (ACL) number
• VLAN and inner-VLAN numbers

Combinations of these characteristics or attributes are allowed with the following restrictions:

• A combination of the CoS-inner setting and ACL number is not supported.
• While the command-line interface (CLI) does allow a configuration that contains two match coscommands, the match-any keyword must be used with the class-map command to make such a configuration meaningful.
• The match vlan and match vlan-inner commands are supported at the main interface level only.

Traffic in both the ingress and egress direction can be marked on the basis of characteristics or attributes such as the following:

• Ip precedence value
• DSCP value
• CoS value
• CoS-inner value (in the egress direction only )

If a set command is specified, note the following points:

• Specifying both set cos 4 and set cos 5 in the same traffic class causes the show policy-mapcommand to display only set cos 5 in the show command output.
• Specifying both the set ip prec 5 command and the set dscp cs6command in the same class causes the show policy-map command to display only set dscp cs6 in the show command output.

The ability to apply QoS features on a per-session basis helps the Internet service provider (ISP) to adhere to the Service Level Agreement (SLA) established for handling traffic. Applying QoS on a per-session basis provides a higher degree of granularity for managing traffic on the network.

A policy map specifies the QoS feature to be applied to network traffic. Examples of QoS features that can be specified in a policy map include traffic classification, shaping, queueing, and policing, among others. Each QoS feature is configured using the appropriate QoS commands.

• Hierarchical Policy Maps
  

As mentioned earlier, you can configure the Per-Session QoS feature using a virtual template.

Note	Using virtual templates to configure the Per-Session QoS feature applies to PPP sessions only.

A virtual template is a logical interface that is configured with generic configuration information for a specific purpose or with configuration information common to specific users, plus router-dependent information. The template takes the form of a list of Cisco IOS interface commands that are applied to virtual access interfaces, as needed.

A virtual template is configured (defined) on an interface. When a session is enabled (that is, when a packet arrives at the interface), the virtual template inherits the QoS features specified in the policy map for use during the session.

After configuring the policy maps (as many as needed) and associating the policy maps with the virtual template on the interface, you may want to verify the configuration. To verify the per-session QoS configuration, use the show policy-map session [uid uid-number] command. This command allows you to see whether the policy maps are configured the way that you intended.

QoS features can be applied on a per-session basis using the ISG framework in a number of ways, including the following:

• Enabling the QoS feature when it is triggered by specific events configured in the ISG policy map (for instance, at the start of a session or at a predetermined expiration interval).
• Using the Change of Authorization (CoA).
• Using the Transparent Auto Logon (TAL).
• Downloading the service profile at the time of authentication.

Cisco AV pairs are part of vendor-specific attributes (VSAs) that allow a policy map to be applied to the router. Cisco AV pairs are a combination of an attribute and a value. The purpose of the Cisco VSA (attribute 26) is to communicate vendor-specific information between the router and the RADIUS server. The Cisco VSA encapsulates vendor-specific attributes that allow vendors such as Cisco to support their own extended attributes.

For this configuration, one of two Cisco AV pairs can be used (formatted as shown below):

• lcp:interface-config=service-policy output/input <policy name>

This Cisco AV pair is considered a "legacy" AV pair. It is of earlier origin but is still an available choice.

• ip:sub-qos-policy-in/out=<policy name>

This Cisco AV pair takes advantage of more recent technology and is the recommended choice. This Cisco AV pair is the one shown in the configuration task and example.

The Cisco AV pair is added to the service profile on the RADIUS server. Each entry establishes an attribute that the user can access.

In a user file, the data to the left of the equal sign (=) is an attribute defined in the dictionary file, and the data to the right of the equal sign is the configuration data.

The Cisco AV pair identifies the policy map that was used to configure the specific QoS features. When the router requests the policy map name (specified in the Cisco AV pair), the policy map is pulled to the router from the RADIUS server when the session is established. The Cisco AV pair applies the appropriate policy map (and, therefore, the QoS feature) directly to the router from the RADIUS server.

• Adding the Cisco QoS AV Pairs to the Service Profile on the RADIUS Server
  
• Defining an ISG Policy Map to Start the QoS Service on the RADIUS Server
  
• Reviewing Session Statistics and Verifying the Policy Map Configuration
  

• Configuring a Local Service Profile
  
• Defining an ISG Policy Map to Start the QoS Service
  
• Starting the Session and Verifying the Policy Map Configuration