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 attribute-value (AV) pairs are 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 device and the RADIUS server. The Cisco VSA encapsulates vendor-specific attributes that allow vendors such as Cisco to support their own extended attributes.

The RADIUS user profile contains an entry for each user that the RADIUS server authenticates. Each entry establishes an attribute the user can access. When configuring PPPoEoA session queueing using RADIUS, enter the following Cisco AV-pair in the appropriate user profile:

cisco-avpair=ip:sub-qos-policy-in/out=<policyname>

The Cisco AV-pair identifies the policy map the device is to use when applying QoS features to a PPPoEoA session. After receiving a service-logon request from the policy server, RADIUS sends a change of authorization (CoA) request to the device to activate the service for the user, who is already logged in. If the authorization succeeds, the device downloads the name of the policy map from RADIUS using the Cisco AV-pair and applies the QoS policy to the session.

Note	Although the router also supports the RADIUS vendor specific attribute (VSA) 38, Cisco-Policy-Down and Cisco-Policy-Up, we recommend that you use the above attribute for QoS policy definitions.

• 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