Configuring Circuits for QoS

Contents

1Overview
1.1Circuit Configuration with QoS Policies
1.2PD QoS Priority and Drop-precedence
1.3Circuit Groups
1.4Propagation of QoS Across Layer 3 and Layer 2 Networks

2

Configuration and Operations Tasks
2.1Configuration Guidelines
2.2Configure an ATM PVC for QoS
2.3Configure an Ethernet Circuit for QoS
2.4Configure a PDH Circuit for QoS
2.5Configure a POS Circuit for QoS
2.6Configure Cross-Connected Circuits for QoS
2.7Configure a Subscriber Circuit for QoS
2.8Configure QoS Propagation (Optional)
2.9Configure L2TP for QoS
2.10Configure MPLS for QoS
2.11Attach QoS Policies to a Circuit Group and Assign Members to the Group
2.12Configuring Virtual Port Circuit Groups
2.13Configure Nested Circuit Groups
2.14Configure Ingress Port Propagation
2.15Operations Tasks

3

Configuration Examples
3.1Attaching Rate- and Class-Limiting Policies
3.2Attaching Scheduling Policies
3.3Propagating QoS
3.4Attaching QoS Policies to Circuit Groups
Copyright

© Ericsson AB 2010-2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.

1   Overview

This document provides an overview of the quality of service (QoS) features supported on the SmartEdge® router for circuits and describes the tasks used to configure, monitor, and administer these features on circuits. This document also provides examples of QoS configurations for circuits.

Note:  
In this document, the term, circuit, refers to a port, channel, permanent virtual circuit (PVC), or link group.

For information about other QoS configuration tasks and commands, see the following documents:

This document distinguishes between first-generation and second-generation Asynchronous Transfer Mode (ATM) OC traffic cards.

The first-generation Asynchronous Transfer Mode (ATM) OC traffic cards follow:

The second-generation ATM OC traffic cards follow:

The terms traffic-managed circuit and traffic-managed port refer to a circuit and port on a card that supports Traffic Management (TM). The following cards support TM:

The Internet provides only best-effort service, offering no guarantees on when or whether a packet is delivered to the receiver. However, the SmartEdge router offers QoS differentiation based on traffic type and application. QoS policies create and enforce levels of service and bandwidth rates, and prioritize how packets are scheduled through egress queues.

1.1   Circuit Configuration with QoS Policies

You can attach both a metering and a policing policy to any port or channel to ATM and 802.1Q PVCs, to subscriber sessions, and to link groups. QoS metering and policing policies are described in Configuring Rate-Limiting and Class-Limiting.

Note:  
Metering, policing, and forwarding policies do not currently support policy ACLs for classification of IPv6 traffic. When IPv6 traffic is subject to a metering, policing, or forwarding policy that was configured using an IPv4 policy ACL, IPv6 packets do not match any of the classes, but are subject to the configured policy-level enforcement.

Child circuits can inherit the QoS metering and policing policies attached to a parent circuit below which the child circuits are configured. To enable a child circuit to inherit the metering or policing policy of its parent, configure the keyword inherit or hierarchical on the policy reference of the parent circuit. If you attach a different metering or policing policy to a child circuit, that policy overrides the metering or policing policy attached to the parent circuit unless the policy reference applied to the parent is configured with the hierarchical keyword. This keyword allows a child circuit that has its own metering or policing policy to inherit the policy of its parent and still be subject to its own policy. For more information about policy inheritance, see Policy Inheritance in Configuring Rate-Limiting and Class-Limiting.

The following types of inheritance are supported:

You can attach a scheduling policy to individual circuits (that are not cross-connected); however, the type of scheduling policy depends on the type of traffic card. QoS scheduling policies are described in Configuring Queuing and Scheduling. QoS queuing policies are automatically inherited by the children of the circuit to which the policy is applied unless the child circuit has its own queuing policy binding.

Note:  
Inheritance can span multiple levels. For example, a policy configured on a port inherited by a PVC in turn is inherited by PPPoX sessions configured under the PVC unless they have a specific policy applied.

You can also attach metering, policing, and scheduling policies to subscriber circuits; the type of scheduling policy depends on the type of traffic card on which the subscriber session is initiated. Layer 2 Tunneling Protocol (L2TP) network server (LNS) subscriber sessions are limited to priority weighted fair queuing (PWFQ) policies. To attach a QoS policy of any type to a subscriber circuit, you attach it to the subscriber record or profile. The system applies the policy to the subscriber circuit (port, channel, or PVC) on which the session is initiated.

Table 1 lists the traffic cards and their circuits to which QoS scheduling policies can be attached.

Note:  
Certain restrictions apply to the attachment of a QoS scheduling policy to a port, channel, or PVC; for detailed usage guidelines for each type of circuit and policy, see the description for the qos policy queuing command (in the appropriate circuit configuration mode).

Restrictions also apply to the configuration of the circuit; for information about configuring traffic card ports, channels, and circuits, see Configuring ATM, Ethernet, and POS Ports, Configuring Circuits, and Configuring Cross-Connections.


Table 1    QoS Scheduling Policy Support for SmartEdge Traffic Cards

Type

Traffic Card or MIC

Circuit

Policy

First-generation ATM OC

ATM OC-3c/STM-1c (2-port)

ATM PVC

EDRR or PQ

ATM OC-12c/STM-4c (1-port)

ATM PVC

EDRR or PQ

Second-generation ATM OC

ATM OC-3c/STM-1c IR (2-port) MIC, SmartEdge 100

ATM PVC

ATMWFQ

ATM OC-3c/STM-1c IR (4-port)

ATM PVC

ATMWFQ

ATM OC-3c/STM-1c (8-port)

ATM PVC

ATMWFQ

ATM OC-12c/STM-4c (1-port)

ATM PVC

ATMWFQ

Enhanced ATM OC-12c/STM-4c (1-port)

ATM PVC

ATMWFQ

ATM OC-12c/STM-4c (2-port)

ATM PVC

ATMWFQ

POS

POS OC-3c/STM-1c (8-port)

Port, Frame Relay PVC

PWFQ or MDRR

POS OC-12c/STM-4c (4-port)

Port, Frame Relay PVC

PWFQ or MDRR

POS OC-48c/STM-16c (4-port)

Port, Frame Relay PVC

PWFQ or MDRR

OC-192c/STM-64c (1-port)

Port, Frame Relay PVC

PWFQ or MDRR

OC-48c/STM-16c(1-port)

Port, Frame Relay PVC

EDRR or PQ

OC-12c/STM-4c IR (4-port)

Port, Frame Relay PVC

EDRR or PQ

OC-3c/STM-1c IR (8-port)

Port, Frame Relay PVC

EDRR or PQ

Ethernet

10/100 Ethernet (12-port)

Port, 802.1Q tunnel, 802.1Q PVC

EDRR or PQ

10/100 TX (12-port) MIC, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

10/100 FX SFP-based (12-port) MIC, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

Fast Ethernet-Gigabit Ethernet

Fast Ethernet–Gigabit Ethernet (60-port FE, 2-port GE)

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

Gigabit Ethernet

Gigabit Ethernet (4-port)

Port, 802.1Q tunnel, 802.1Q PVC

EDRR or PQ

Advanced Gigabit Ethernet (4-port)

Port, 802.1Q tunnel, 802.1Q PVC

EDRR or PQ

Gigabit Ethernet with traffic management

Gigabit Ethernet 3 (4-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet 1020 (10-port) (ge-10-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet 1020 (20-port) (ge-20-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (5-port) (ge-5-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet 4 (20-port) (ge4-20-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet DDR (10-port) (ge2-10-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (2-port, copper) native port, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (2-port, optical) native port, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

10-Gigabit Ethernet

10 Gigabit Ethernet Gigabit Ethernet (10GE) (1-port)

Port, 802.1Q tunnel, 802.1Q PVC

MDRR

10 Gigabit Ethernet (10GE) (4-port)

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

10 Gigabit Ethernet / POS DDR

10 Gigabit Ethernet/OC-192c DDR (1-port)

Port, Frame Relay PVC, 802.1Q tunnel, 802.1Q PVC

MDRR

1.2   PD QoS Priority and Drop-precedence

The SmartEdge router associates a six-bit internal Packet Descriptor (PD) for the QoS value that is initialized when a packet is received on ingress. The PD remains associated with a packet as it transits the forwarding plane. This six-bit internal PD value is referred to as the PD QoS Codepoint. The upper three bits hold the PD QoS priority value (ppp), and the lower three bits the PD QoS drop-precedence value (ddd):

1.3   Circuit Groups

Circuit groups allow you to group arbitrary PVCs or other circuits, such as subscriber sessions, for collective metering, policing, and scheduling. You can group PVCs—for example, to represent a business entity—and apply class-aware or circuit-level rate limits to the group. In this case, the traffic on all of the member circuits is collectively limited to any metering, policing, and scheduling rates configured on the circuit group.

Circuit group membership is available for 802.1Q PVCs, 802.1Q PVCs within an 802.1Q tunnel, or a mix of these circuit types. Circuit group membership is also available for subscriber circuits. When hierarchical rate limiting is applied to a circuit group, traffic is first limited according to any metering or policing policy applied to the member circuit. Subsequently, traffic is limited again according to any metering or policing policy applied to the circuit group.

Circuit group members can have child circuits configured under them. The following apply to circuit group membership:

When a circuit with children is assigned circuit-group membership, those child circuits remain associated with their parent and are subject to QoS inheritance of any QoS policies applied to the circuit group or the member circuit itself. However, if the child circuit is itself assigned circuit-group membership, the QoS inheritance relationship with its parent circuit is broken and the child inherits from its own circuit group.

Counters values reported for the circuit group reflect the aggregate totals of all the members as well as their children.

Subscriber session circuits can be configured as direct members of a circuit group. You can configure the circuit-group-member command in the subscriber record, subscriber profile, or subscriber default configuration modes. In addition, a corresponding VSA (210, Circuit_Group_Member) is provided to allow configuration of circuit-group membership through RADIUS. The following apply to a subscriber session member of a circuit group:

For information about the circuit-group, circuit-group-member, and subscriber commands, see Command List. For information about VSA 210, see RADIUS Attributes.

1.3.1   Virtual Port Circuit Groups

The SmartEdge router supports virtual port circuit group (VPCGs, which allow you to partition circuits or link groups of ports that support PWFQ and have a line rate greater than 1 Gbps for collective scheduling. You can use a VPCG to divide a high-speed port's traffic into multiple, lower-bandwidth scheduling domains. You can assign a circuit to a virtual port by making the circuit a member of the VPCG.

The SmartEdge router supports the following methods of VPCG assignment for virtual ports:

Note:  
With explicit assignment of VPCG for a subscriber session, the subscriber session inherits the queuing policy and any metering and policing policies configured under the VPCG.

The following applies to auto-assignment of circuit group membership:

  • Static circuits—Statically configured circuits, such as 802.1q PVCs, have their auto-assigned virtual-port membership reflected by the automatic addition of the circuit-group-member command to the router configuration.

    Static circuit types:

    • Implicit ranges—Each PVC in implicit PVC ranges (for example, 802.1q PVC 1 to 10) may independently be auto-assigned to a different VPCG.
    • Explicit ranges—All PVCs in an explicit PVC range (for example, 802.1q PVC explicit 1 to 10) are collectively auto-assigned to a single VPCG.
    • Transport ranges—All VLAN IDs in a transport PVC range (for example, 802.1q PVC transport 1 to 10) are collectively auto-assigned to a single VPCG.
  • Dynamic circuits—Dynamically configured circuits, such as subscribers and on-demand PVCs, do not have their auto-assigned VPCG membership reflected in the router configuration.

    Dynamic circuit types:

    • On-demand ranges (also called circuit creation on demand (CCOD))—Each PVC in an on-demand PVC range (for example, 802.1q PVC on-demand 1 to 10) can be auto-assigned independently to a different VPCG when the PVC is activated.
    • Subscriber sessions—Each applicable subscriber session can be auto-assigned independently to a different VPCG when the subscriber session is established or when a PWFQ policy binding is added to the subscriber (for example, through reauthentication, change of authorization (CoA), or the use of the policy-refresh command).
    Note:  
    Implicit, explicit, and on-demand range circuits create multiple circuits; transport range circuits do not.

The following applies to VPCGs:

The following applies to a child of a VPCG:

On affected ports and link-groups, a circuit must be associated with a VPCG either directly or through inheritance before the circuit can accept any of the following PWFQ configuration commands:

A VPCG supports all of the functionality of a homed circuit group, including:

The following configuration restrictions apply to VPCGs:

  • The qos rate minimum and qos weight commands are not supported.
  • Node groups are not supported. Node groups have been replaced by circuit-group membership for subscribers.
  • Economical access link aggregation group (LAG) is not supported.
  • L2TP Network Server (LNS) and Multilink PPP (MP) subscribers support PWFQ on virtual-port cards. However, these subscribers do not support explicit or auto-assignment of VPCGs. Instead, the SmartEdge OS selects an appropriate VPCG based on the existing configuration.
  • On-demand 802.1q PVCs (for example, CCoD circuits) support PWFQ queuing, but rely on automatic VPCG assignment. Explicit VPCG assignment (for example, the circuit-group-member command) is currently not supported for CCoD circuits.

1.3.2   Nested Circuit Groups

A circuit group can belong to another circuit group. Use these nested circuit groups to configure hierarchical QoS. Members of child circuit groups are subject to QoS inheritance from both the child circuit group and its parent circuit group. If a parent circuit group is homed to a port or link group, its children circuit groups are implicitly homed to the same port or link group.

No limit is enforced on the number of nested levels. However, two to four is the practical range (including VPCGs).

To configure a nested circuit group, use the circuit-group command with the circuit-group-parent keyword. For information about the circuit-group and circuit-group-member commands, see Command List.

1.3.3   Inheritance for Circuit Group Members

Natural children and grandchildren of circuit-group members are subject to inheritance of inheritable QoS policy bindings or other attributes from their natural circuit parent in the SmartEdge OS hierarchy including the following:

Note:  
A circuit-group member that has no explicit queuing policy applied inherits the queues and scheduling policy of its parent port or link group.

The following QoS policy bindings are inheritable:

L3 hierarchical node bindings are implicitly inherited by any L2 nodes below them in the hierarchy. Inherited bindings are overridden by any binding of the same type configured on the circuit itself or on an intermediate ancestor.

1.4   Propagation of QoS Across Layer 3 and Layer 2 Networks

You can configure the SmartEdge router to propagate IP Differentiated Services Code Point (DSCP) settings in Layer 3 packets as they travel across Ethernet virtual LANs (VLANs), Layer 2 Tunneling Protocol (L2TP) networks, and Multiprotocol Label Switching (MPLS) networks. Conversely, Ethernet 802.1p priority bits, MPLS experimental (EXP) bits, and DSCP settings in Layer 3 packets encapsulated in L2TP packets can be propagated across IP networks. DSCP drop precedence settings can be propagated to the ATM cell loss priority (CLP) bit; however, the reverse is not true.

QoS propagation for a packet uses a packet descriptor (PD) in a SmartEdge router data structure that associates attributes with a forwarded packet that are not stored in the packet’s actual headers or payload. The PD includes a three-bit priority field and a three-bit drop-precedence field, as shown in Figure 1. The SmartEdge router uses these PD fields to perform the following functions for an incoming Layer 2 packet:

  1. Depending on configuration for the inbound circuit protocol, the SmartEdge router populates the PD for this packet, using one of the following functions:
    • If a QoS propagate from command is configured for the Layer 2 protocol, the SmartEdge router copies the priority bits from the Layer 2 header to the priority field in the PD. If no classification map is specified, depending on the Layer 2 protocol (MPLS, or 802.1Q, or L2TP), the SmartEdge router copies the priority field in the PD to the DSCP bits in the Layer 3 header.
    • If no QoS propagate from command is configured, the SmartEdge router copies the three most-significant DSCP bits from the Layer 3 header in the incoming packet to the priority field in the PD and the drop precedence settings in that header to the drop field in the PD.
  2. If a QoS policing policy, which can include a policy access control list (ACL), that includes a mark command (of any type) is attached to the inbound circuit, the SmartEdge router modifies the bits in the priority and drop fields in the PD based on the policy.

    A decision is made whether to forward the incoming Layer 3 packet to the outbound circuit for further QoS processing.

Figure 1   Propagation of QoS Across Layer 3 and Layer 2 Networks (791)

  1. If a QoS metering policy (which can include a policy ACL) that includes a mark command (of any type) is attached to the outbound circuit, the SmartEdge router modifies the bits in the qos and drop fields in the PD based on the policy.
  2. The SmartEdge router encapsulates the Layer 3 packet in a Layer 2 packet, using one of the following functions:
    • If a QoS propagate to command is configured for the Layer 2 protocol, the SmartEdge router copies the priority field in the PD to the priority bits in the Layer 2 header.
    • If no QoS propagate to command is configured, the SmartEdge router sets the priority bits in the Layer 2 header to the default (lowest) priority.
  3. The SmartEdge router uses the priority field in the PD to determine the egress queue for the outgoing packet, and the drop-precedence field to determine the relative priority within that queue.

The following sections further describe QoS propagation:

1.4.1   Propagation of QoS from IP to ATM

The CLP bit in the ATM header of a cell provides a method of controlling the discarding of cells in a congested ATM environment. A CLP bit can be set to either 0 (default) or 1, and ATM cells with setting of 1 are discarded before cells with a setting of 0. When you use the clpbit propagate qos to atm command to propagate the DSCP bits from IP packets to the CLP bit, the DSCP bits in the PD are used to determine if the CLP bit should be set and thus which ATM cells to discard in an ATM congested network. DSCP bits are mapped to the ATM CLP bit as described in Table 2.

Table 2    Mapping DSCP Bits to the ATM CLP Bit

DSCP

ATM CLP Bit

Network Control

0

Reserved

0

EF

0

AF11 AF21, AF31, AF41

0

AF12 AF22, AF32, AF42

1

AF13 AF23, AF33, AF43

1

DF

1


Note:  
This default mapping can be modified using the clbit propagate qos to atm command (in ATM profile configuration mode) in conjunction with an ATM egress class map.

Note:  
You can also use the mark dscp, mark priority, and mark precedence commands (in metering policy or policing policy configuration mode) to indirectly set the ATM CLP bit when using the clpbit propagate qos to atm command to propagate the DSCP bits from IP packets to the CLP bit.

1.4.2   Propagation of QoS Between IP and Ethernet

802.1p priority is carried in virtual LAN (VLAN) tags defined in IEEE 802.1p. The VLAN tag carries one of eight priority values recognizable by Layer 2 devices in a three-bit field. These three bits are called 802.1p prioritization bits, or "p bits". P-bit marking determines the service level the packet receives when crossing an 802.1p-enabled network segment. DSCP priority bits are mapped to p bits, in either or both directions, depending on whether you configure the qos propagate from ethernet and qos propagate to ethernet commands (in dot1q profile configuration mode). As shown in Figure 2, the following steps occur for an incoming 802.1Q packet:

  1. As a 802.1Q packet enters the SmartEdge router, its 802.1p bits are copied to the PD QoS priority field, if you use the propagate qos from ethernet command (in dot1q profile configuration mode) to propagate Ethernet 802.1p user priority bits and do not specify a classification map. If you do specify a classification map, the 802.1p bits are mapped to the PD QoS value.
  2. The PD is copied to the DSCP field in Layer 3, if you use the propagate qos from ethernet command (in dot1q profile configuration mode) to propagate Ethernet 802.1p user priority bits and do not specify a classification map.

Figure 2   Propagation of QoS Between IP and Ethernet (789)

When the SmartEdge router prepares to forward a packet on an 802.1Q virtual LAN (VLAN), the PD priority value is copied to the 802.1p field of the outgoing packet, if you use the propagate qos to ethernet command (in dot1q profile configuration mode) to propagate PD priority values.

If you create a classification map using the qos class-map command and reference it in propagate qos to ethernet syntax, the PD priority value is mapped to the 802.1p field, rather than copied.

For outgoing Virtual Router Redundancy Protocol (VRRP) control packets, the SmartEdge router automatically writes a value of 0 into the control packet. However, the SmartEdge router supports 802.1p marking for locally-generated VRRP advertisements, making VRRP packets subject to egress QoS maps. Any configured egress Ethernet class map can be used to map the internal priority of the packet to an 802.1p bit value.

1.4.3   Propagation of QoS Between IP and MPLS

MPLS EXP bits use one of eight priority values (3 bits in length), recognizable by Layer 2 devices. This marking determines the service level the packet receives when crossing an MPLS-enabled network segment. On ingress, MPLS EXP values are mapped to PD priority values, by default. You can modify the default mapping by doing one of the following:

On egress, if you use the propagate qos to mpls command (in MPLS router configuration mode), PD bits are mapped to MPLS EXP bits if you specify a classification map; see Figure 3.

In addition, the EXP value can be copied to the priority field of the packet’s IP header DSCP field by entering the propagate qos from mpls command without specifying a classification map.

Figure 3   Propagation of QoS Between IP and MPLS (790)

1.4.4   Propagation of QoS Between IP and L2TP

With L2TP packets, the DSCP and the precedence bits of the original IP packet are copied. The downstream process from the network to the SmartEdge router configured as an LNS to the SmartEdge router configured as an L2TP access concentrator (LAC) to the subscriber is illustrated in Figure 4

Figure 4   Propagation of QoS Downstream from the Network (792)

The downstream propagation process follows:

  1. At the LNS, the SmartEdge router copies the DSCP bits from the inner subscriber IP packet header in the incoming IP packet to the PD priority field.
  2. The SmartEdge router then copies the priority field to the DSCP bits in the outer L2TP IP packet header, using the propagate qos to l2tp command (in L2TP peer configuration mode), if configured. If the command is not configured, it sets the DSCP bits to the default (lowest) priority.
  3. The SmartEdge router selects an egress queue for the L2TP packet, based on the priority field.
  4. At the LAC, the SmartEdge router copies the DSCP bits in the outer L2TP IP packet header to the PD priority field.
  5. The SmartEdge router then copies the DSCP bits from the inner subscriber IP packet header to the PD priority field, using the propagate qos from subscriber command (in L2TP peer configuration mode) with the downstream keyword, if configured. This operation overwrites the priority field set by step 4.
  6. The SmartEdge router selects an egress queue, based on the priority field in the PD.

The upstream process from the subscriber to the SmartEdge router configured as an LAC to the SmartEdge router configured as an LNS to the network is illustrated in Figure 5.

Figure 5   Propagation of QoS Upstream from the Subscriber (793)

The upstream propagation process follows:

  1. At the LAC, if the propagate qos from subscriber command (in L2TP peer configuration mode) with the upstream keyword is configured, the SmartEdge router copies the DSCP bits from the inner subscriber IP packet header in the incoming IP packet to the priority field in the PD. If the propagate qos from subscriber command is not configured, it sets the priority field to the default (lowest) priority.
  2. The SmartEdge router then copies the priority field to the DSCP bits in the outer L2TP IP packet header, using the propagate qos to l2tp command (in L2TP peer configuration mode), if configured. If the command is not configured, it sets the DSCP bits to the default priority.
  3. The SmartEdge router selects an egress queue for the L2TP packet based on the priority field.
  4. At the LNS, the SmartEdge router copies the DSCP bits from the outer L2TP IP packet header in the incoming IP packet to the priority field in the PD.
  5. The SmartEdge router then copies the priority field to the DSCP bits in the inner subscriber IP packet header, using the propagate qos from l2tp command (in L2TP peer configuration mode), if configured with no classification map specified. If this command is not used, the inner subscriber IP packet header is not altered.
  6. The SmartEdge router selects an egress queue for the IP packet based on the priority field.

1.4.5   Priority Propagation for Oversubscribed Traffic Cards

Ingress propagation of QoS priority is available at the port level for certain oversubscribable traffic cards. Currently, only the 4-port 10 Gigabit Ethernet (10GE) card is supported. A traffic card is considered oversubscribable if it is designed such that the sum of the nominal rate of all its ports exceeds the actual packet-forwarding capacity of the card. The nominal packet-processing capacity of the 4-port 10GE traffic card is approximately 20 Gbps. When the total aggregate line bandwidth of in-service ports is greater than the nominal capacity of a traffic card, the card is oversubscribed. Any traffic received that exceeds the actual forwarding capacity of the card (which can vary based on factors such as average packet size and enabled ingress packet-processing features) is dropped.

The following port-level configuration commands are supported:

The port-propagate commands enable the mapping of external priority markings of MPLS EXP, Ethernet 802.1p, and IP TOS/DSCP to SmartEdge router internal QoS priority values stored in the Packet Descriptor (PD QoS). The PD QoS value so assigned in turn determines each packet's ingress oversubscription treatment.

Each port has four ingress queues (numbered 0 to 3) for the incoming traffic, and the PD QoS priority value that is assigned to a packet determines to which of the four queues the packet is admitted. Each queue has a fixed mapping to a priority number or numbers as shown in Table 3.

Table 3    Ingress Queue Assignment Based on PD Priority

Incoming Packets with PD QoS Priority Value of:

Are Placed in Ingress Queue:

0 or 1

0

2

1

3, 4, or 5

2

6 or 7

3


The PD QoS drop-precedence value that is assigned to a packet determines which of the four ingress queue admittance priorities (numbered 0 to 3) is assigned to it as shown in Table 4.

Table 4    Ingress Queue Admittance Priority Based on PD QoS Drop-precedence Values

Incoming Packets with PD QoS Drop-Precedence Value of:

Are Assigned an Ingress Queue Admittance Priority Value of:

0 or 1

0

2 or 3

1

4 or 5

2

6 or 7

3


Ingress queue admittance priority determines how much of the overall capacity of a queue that an incoming packet is allowed to take advantage of. Packets of ingress queue admittance priority 0 (zero) are admitted to the queue up to the point at which it is completely full, but packets of other priorities are discarded rather than queued at successively lower thresholds of the total occupancy capacity of the queue.

The 4-port 10 GE traffic card enables different queuing thresholds for each PD priority value. Each of the four packet priorities can take advantage of a different portion of the total queue depth according to the following ratios. The following values are percentages of the maximum queue occupancy level:

For example, if the target queue is 82% full, an incoming packet with a priority value of 2 or 3 is dropped, while a packet with a priority value of 0 or 1 is admitted to the queue.

The queues are serviced in strict priority order on a card-wide basis; that is, packets waiting in the highest-priority queues (queue 0) of any of the ports on the card are serviced until those queues are empty, then packets waiting in the second-highest priority queue are serviced (queue 1), and so on. Under congestion, the highest-priority are the most likely to be forwarded, and the lowest-priority packets are the most likely to be discarded due to queue overflow. If the port-propagate commands are not configured, then all packets received on the port are treated as the lowest-priority traffic for ingress oversubscription purposes (they are assigned to ingress queue 3 with queue admittance priority 3).

Packets discarded because of ingress queue overflow are reported by the show port counters detail command in the “Receive Counters" section as "overflows" (total number of packets discarded) and "overflow bytes" (total number of octets discarded).

The PD QoS value assigned during ingress oversubscription processing always determines its ingress oversubscription treatment, and it can remain associated with the packet for the subsequent SmartEdge forwarding processing stages that it will be subject to (for example, to determine which transmit queue the packet is assigned to on the egress port). However, this PD QoS value can be overridden subsequent to ingress admission by any applicable qos priority or propagate qos from command that also applies to the circuit and the default DSCP-to-PD mapping applied to all Layer 3 (bind interface, bind authentication, bind subscriber) IP circuits. When more than one port-propagate command is enabled for the same port, the outermost priority field present in a packet for which a corresponding port-propagate command has been configured on the port takes precedence. For example, if both the port-propagate from ip and port-propagate from ethernet commands are configured for the same port, the outer 802.1p value determines the ingress priority for all the 802.1q-encapsulated traffic received by the port, and the IP DSCP value determines the priority for non-802.1q-encapsulated IP over Ethernet traffic.

The port-propagation ingress classifier identifies and decodes frames of different types based on the following Ethertype field values.

Table 5    Supported Ethertype Field Values

Ethertype Field Value

Indicates Which Protocol Is Encapsulated in the Frame

0x0800

IPv4

0x8100(1)

802.1q

0x8847, 0x8848

MPLS


(1)  Plus the Ethertype value specified by the dot1q tunnel ethertype command under the port, if configured.


Note:  
Frames received with EtherType field values other than ones listed in Table 6 have their PD QoS priority and drop-precedence values set to 0 (zero) and receive the lowest-priority treatment for ingress oversubscription purposes (they are assigned to ingress queue 3 with queue admittance priority 3).

Table 6 lists the supported packets from which the supported PD priority values can be extracted.

Table 6    Supported Packet Types for Ingress Port QoS Priority Propagation

IPv4 Header TOS Field DSCP Values Can Be Examined for the Following Packets

Ethernet 802.1p Priority Values Can Be Examined for the Following Packets

MPLS EXP Priority Values Can Be Examined for the Following Packets

IPv4 over Ethernet

802.1q

MPLS over Ethernet

IPv4 over 802.1q

802.1q in 802.1q (1)

MPLS over 802.1q

IPv4 over 802.1q in 802.1q

MPLS over 802.1q in 802.1q


(1)  Only the outer 802.1p value is used in this case.


2   Configuration and Operations Tasks

Note:  
In this section, the command syntax in the task tables displays only the root command; for the complete command syntax, see Command List.

To configure circuits for QoS features, perform the tasks described in the following sections:

2.1   Configuration Guidelines

This section includes configuration guidelines that affect more than one command or a combination of commands:

2.2   Configure an ATM PVC for QoS

To configure an ATM PVC for QoS, perform the tasks described in the following sections:

2.2.1   Configure a PVC on a First-Generation ATM OC Traffic Card

To configure an ATM PVC on a first-generation ATM OC traffic card, perform the tasks described in Table 7; enter all commands in ATM PVC configuration mode, unless otherwise noted.

Table 7    Configure a PVC on a First Generation ATM OC Traffic Card

Task

Root Command

Notes

For packets coming into the SmartEdgerouter, propagate the CLP bit to PD values in ATM cells.

clpbit propagate qos from atm

Enter this command in ATM profile configuration mode.

For packets going out of the SmartEdge router, propagate IP DSCP bits to the CLP bit in ATM cells.

clpbit propagate qos to atm

Enter this command in ATM profile configuration mode.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

Possible policy types are EDRR and PQ. You must attach an EDRR policy to both the port and the PVC. To attach the EDRR policy to the port, enter this command in ATM OC configuration mode.

Optional. Modify the mode of an EDRR policy algorithm.

qos mode

Enter this command in ATM OC configuration mode.


By default, the mode is normal. Only one mode type is supported on a single port.


2.2.2   Configure a PVC on a Second-Generation ATM OC Traffic Card

To configure an ATM PVC on a second-generation ATM OC traffic card, perform the tasks described in Table 8; enter all commands in ATM PVC configuration mode, unless otherwise noted.

Table 8    Configure a PVC on a Second-Generation ATM OC Traffic Card

Task

Root Command

Notes

For packets coming into the SmartEdge router, propagate the CLP bit to PD values in ATM cells.

clpbit propagate qos from atm

Enter this command in ATM profile configuration mode.

For packets going out of the SmartEdge router, propagate IP DSCP bits to the CLP bit in ATM cells.

clpbit propagate qos to atm

Enter this command in ATM profile configuration mode.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy to a PVC.(1)

qos policy queuing

Only ATMWFQ policies are supported; you can attach them only to PVCs.


(1)  An ATMWFQ policy cannot be attached to a PVC that is shaped as UBRe.


2.3   Configure an Ethernet Circuit for QoS

To configure a circuit on any Ethernet traffic card for QoS, including any version of a Gigabit Ethernet traffic card, perform the tasks described in the following sections:

2.3.1   Configure Any Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet Circuit for QoS

To configure an Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet (any version) port, 802.1Q tunnel, or 802.1Q PVC, perform the tasks described in Table 9; enter all commands in port or dot1Q PVC configuration mode, unless otherwise noted.

Table 9    Configure Any Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet Circuit for QoS

Task

Root Command

Notes

For packets coming into the SmartEdge router , propagate Ethernet 802.1p user priority bits to IP DSCP bits.

propagate qos from ethernet

Enter this command in dot1q profile configuration mode.

For packets going out of the SmartEdge router, propagate IP DSCP bits to Ethernet 802.1p user priority bits.

propagate qos to ethernet

Enter this command in dot1q profile configuration mode.

Assign a priority group to the port, tunnel, or PVC.

qos priority

The QoS bit setting for packets traveling across the ingress circuit is not changed by the priority group assignment.


Not supported for CCOD ranges of 802.1q PVCs.

Attach an overhead profile to a port or an 802.1Q PVC.

qos profile overhead

 

Attach a policing policy to the port, tunnel, or PVC.

qos policy policing

 

Set the rate for outgoing traffic for a Gigabit Ethernet port.

qos rate

 

Attach a metering policy to a port, tunnel, or PVC.

qos policy metering

 

Attach a scheduling policy to a port, tunnel, or PVC.

qos policy queuing

Possible policy types are EDRR, MDRR, PQ, and PWFQ.(1)

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.


Not supported for CCOD ranges of 802.1q PVCs.

Optional. Modify the mode of an EDRR policy algorithm.

qos mode

By default, the mode is normal. Only one mode type is supported on a single port.


(1)  EDRR and PQ policies are not supported on traffic-managed circuits; these circuits support only PWFQ policies. MDRR policies are supported only on 10GE circuits.


2.3.2   Configure a Traffic-Managed Port for Hierarchical Scheduling

To configure a traffic-managed port and any 802.1Q tunnels and PVCs configured on it for hierarchical scheduling with a PWFQ policy, perform the tasks described in Table 10; enter all commands in port configuration mode, unless otherwise noted. For information about the dot1q pvc command (in port configuration mode), see Configuring Circuits.

Table 10    Configure a Traffic-Managed Port for Hierarchical Scheduling

Task

Root Command

Notes

Set the maximum and minimum rates for the port.

qos rate

You must specify the maximum rate; the minimum rate is optional.

Specify the scheduling algorithm for the port.

qos hierarchical mode strict

 

Attach a PWFQ policy to the port.

qos policy queuing

You can attach a policy to any or all 802.1Q tunnels and PVCs as well as the port.

Create one or more 802.1Q tunnels or PVCs and access dot1q PVC configuration mode.

dot1q pvc

 

Set the maximum and minimum rates for the tunnel or PVC.

qos rate

Enter this command in dot1q PVC configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this PVC.

Assign a relative weight to this PVC.

qos weight

Enter this command in dot1q PVC configuration mode. You cannot assign a relative weight if you also set a minimum rate for this PVC.

Specify the scheduling algorithm for the tunnel or PVC.

qos hierarchical mode strict

Enter this command in dot1q PVC configuration mode.

Attach a PWFQ policy to the tunnel or PVC.

qos policy queuing

Enter this command in dot1q PVC configuration mode. You can attach a policy to any or all tunnels and PVCs, as well as the port.


2.3.3   Configure a Traffic-Managed Port for Hierarchical Nodes

To configure a traffic-managed port for hierarchical nodes, node groups, and attach PWFQ policies to them, perform the tasks described in Table 11; enter all commands in port configuration mode, unless otherwise noted.

Table 11    Configure a Traffic-Managed Port for Hierarchical Nodes

Task

Root Command

Notes

Set the maximum and minimum rates for the port.

qos rate

You must specify the maximum rate; the minimum rate is optional.

Specify the scheduling algorithm for the port.

qos hierarchical mode strict

 

Create one or more hierarchical node groups and access hierarchical node group configuration mode.

qos node-group

 

Set the maximum and minimum rates for the node groups.

qos rate

Enter this command in hierarchical node group configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this node group.

Assign a relative weight to this node group.

qos weight

Enter this command in hierarchical node group configuration mode. You cannot assign a relative weight if you also set a minimum rate for this node group.

Specify the scheduling algorithm for the node groups.

qos hierarchical mode strict

Enter this command in hierarchical node group configuration mode. The mode need not be the same as the one you specify for the port.

Create one or more hierarchical nodes and access hierarchical node configuration mode.

qos node

Enter this command in hierarchical node group configuration mode.

Set the maximum and minimum rates for these nodes.

qos rate

Enter this command in hierarchical node configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this node.

Assign a relative weight for these nodes.

qos weight

Enter this command in hierarchical node configuration mode. You cannot assign a relative weight if you also set a minimum rate for this node.

Specify the scheduling algorithm for these nodes.

qos hierarchical mode strict

Enter this command in hierarchical node configuration mode. The mode need not be the same as the one you specify for the port or node group.

Attach a PWFQ policy to these nodes.

qos policy queuing

Enter this command in hierarchical node configuration mode. The policy need not be the same as the one you attach to the port, tunnel, or PVC.


2.4   Configure a PDH Circuit for QoS

To configure a PDH circuit (port, channel, PVC, or link group) for QoS, perform the tasks described in Table 12; enter all commands in DS-0 group, link group, or Frame Relay PVC configuration mode (depending on the type of PDH circuit), unless otherwise noted.

Table 12    Configure a PDH Circuit for QoS

Task

Root Command

Notes

Assign a priority group.

qos priority

The QoS bit setting for packets traveling across the ingress circuit is not changed by the priority group assignment.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

Policy types include EDRR and PQ.

Optional. Modify the mode of an EDRR policy algorithm.

qos mode

By default, the mode is normal. Only one mode type is supported on a single port.


2.5   Configure a POS Circuit for QoS

To configure a circuit on a Packet over SONET/SDH (POS) traffic card for QoS, perform the tasks described in Table 13; enter all commands in port configuration mode.

Table 13    Configure a POS Circuit for QoS

Task

Root Command

Notes

Assign a priority group.

qos priority

The QoS bit setting for packets traveling across the ingress circuit is not changed by the priority group assignment.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

Policy types include EDRR, PQ, and PWFQ.

Optional. Modify the mode of an EDRR policy algorithm.

qos mode

By default, the mode is normal. Only one mode type is supported on a single port.


2.6   Configure Cross-Connected Circuits for QoS

To configure a cross-connected circuit for QoS, perform the tasks described in Table 14 in. You cannot attach a scheduling policy to a cross-connected circuit; only metering and policing policies are supported on either or both circuits.

Note:  
You can perform the tasks in Table 14 in any order.

Table 14    Configure a Cross-Connected Circuit for QoS

Step

Task

Root Command

Notes

1.

Configure the inbound circuit for QoS with one of the following tasks:

   
 

An inbound ATM PVC.

 

Perform the tasks in Table 7 or Table 8, but do not attach a scheduling policy.

 

An inbound 802.1Q PVC.

 

Perform the tasks in Table 10, but do not attach a scheduling policy.

2.

Configure the outbound circuit for QoS with one of the following tasks:

   
 

An outbound ATM PVC.

 

Perform the tasks in Table 7 or Table 8, but do not attach a scheduling policy.

 

An outbound 802.1Q PVC.

qos priority

Perform the tasks in Table 10, but do not attach a scheduling policy.

3.

Create the cross-connection between the inbound and outbound circuits.

xc

Enter this command in global configuration mode. For information about this command, see the Configuring Cross-Connections.


2.7   Configure a Subscriber Circuit for QoS

You configure a subscriber circuit (or an LNS subscriber session) for QoS by configuring the subscriber record or profile; to configure a subscriber record or profile and thus any circuit on which the subscriber session is created, perform one or more of the tasks described in Table 15; enter all commands in subscriber configuration mode unless otherwise noted.

Table 15    Configure a Subscriber Circuit for QoS

Task

Root Command

Notes

Create a reference to a hierarchical node.

qos node-reference

 

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

Policy types include ATMWFQ, EDRR, MDRR, PQ, and PWFQ. Only PWFQ policies are supported for LNS subscriber sessions.

Attach an overhead profile to a subscriber record.

qos profile overhead

Enter this command in port configuration mode.

Optional. Modify the mode of an EDRR policy algorithm.

qos mode

By default, the mode is normal. Only one mode type is supported on a single port.


2.8   Configure QoS Propagation (Optional)

To create and apply customized classification mappings for QoS bits, perform the tasks described in Table 16; enter all commands in class map configuration mode, unless otherwise noted.

Table 16    Configure QoS Propagation

Task

Root Command

Notes

Create a classification map.

qos hierarchical mode strict

Enter this command in global configuration mode.

Specify a set of default values for a classification map.

mapping-schema

 

Specify an initial PD value to assign to ATM packets with the specified CLP value.

atm to qos

 

Translate outgoing PD QoS values to ATM CLP values.

qos to atm

 

For incoming packets with the specified CLP value, determine the initial PD QoS value from the user priority bits in the 802.1p VLAN TCI field of the packet header value.

atm use-ethernet

 

For incoming packets with the specified CLP value, determine the initial PD QoS value from the IP ToS field of the packet header.

atm use-ip

 

Translate incoming Ethernet 802.1p values to PD QoS values.

ethernet to qos

 

Translate outgoing PD QoS values to Ethernet 802.1p values.

qos to ethernet

 

For 802.1Q transport PVCs, use the 802.1p value from either the outer PVC header or the inner PVC header for propagation between internal PD classification values and Ethernet.

propagate qos transport use-vlan-header

Enter this command in dot1q profile configuration mode.

For incoming packets with the specified 802.1p value, determine the initial PD QoS value from the DSCP value in the IP header rather than the 802.1p value.

ethernet use-ip

 

Translate incoming IP header DSCP values to PD QoS values.

ip to qos

 

Translate outgoing PD QoS values to IP header DSCP values.

qos to ip

 

For outgoing packets with the specified PD QoS value, determine the final header EXP or 802.1p value based on the IP header DSCP value rather than the PD QoS value.

qos use-ip

 

Translate incoming MPLS EXP values to PD QoS values.

mpls to qos

 

Translate outgoing PD QoS values to MPLS header EXP values.

qos to mpls

 

For incoming packets with the specified MPLS EXP priority label, use the encapsulated Ethernet packet’s 802.1p priority label to determine the PD value for the packet.

mpls use-ethernet

 

For incoming packets with the specified EXP value, determine the initial PD QoS value from the IP header DSCP value rather than the EXP value.

mpls use-ip

 

For incoming MPLS EXP packets with an Ethernet VLAN header, specify the 802.1q-over-MPLS packets to examine for any header enclosed by the outer VLAN header.

propagate qos use-vlan-ethertype

Enter this command in MPLS router configuration mode.

For incoming MPLS packets, use the 802.1p value from the header of either the outer PVC header or the inner PVC for propagation from Ethernet to internal PD classification values.

propagate qos use-vlan-header

Enter this command in MPLS router configuration mode.

Reference the classification map when configuring propagation.

propagate qos from ethernet propagate qos from ip propagate qos from l2tp propagate qos from mpls propagate qos to ethernet propagate qos to ip propagate qos to l2tp propagate qos to mpls

Specify the class-map class-map construct for this function.

2.9   Configure L2TP for QoS

To configure L2TP for QoS to propagate subscriber DSCP bits in the downstream direction, perform the tasks described in Table 17; enter all commands in L2TP peer configuration mode for the default peer.

Table 17    Configure L2TP for QoS in the Downstream Direction

Task

Root Command

Notes

For network packets the SmartEdge router sends to the LAC when the router is configured as an LNS, propagate the PD priority bits to the outer DSCP value.

propagate qos to l2tp

 

For L2TP IP packets coming into the SmartEdge router when it is configured as a LAC, propagate the subscriber DSCP bits from the inner IP packet header to the PD priority bits from the LNS for the subscriber IP packet.

propagate qos from subscriber

Specify the downstream keyword for this function.


To configure L2TP for QoS to propagate DSCP bits in the upstream direction, perform the tasks described in Table 18; enter all commands in L2TP peer configuration mode for the default peer.

Table 18    Configure L2TP for QoS in the Upstream Direction

Task

Root Command

Notes

For subscriber IP packets coming into the SmartEdge router when it is configured as a LAC, propagate the subscriber DSCP bits in the IP packet header to the PD priority bits for the subscriber IP packet.

propagate qos from subscriber

Specify the upstream keyword for this function.

For network packets the SmartEdge router sends to the LNS when the router is configured as a LAC, propagate the PD priority bits to the outer DSCP value.

propagate qos to l2tp

 

For L2TP packets coming into the SmartEdge router when it is configured as an LNS, after the outer DSCP bits have been propagated to the PD priority bits, propagate the PD priority bits to the subscriber’s inner DSCP bits.

propagate qos from l2tp

 

2.10   Configure MPLS for QoS

To configure MPLS for QoS, perform the tasks described in one of the following sections:

2.10.1   Propagate QoS Using DSCP Bits and MPLS EXP Bits

To propagate QoS using DSCP bits to MPLS EXP bits (instead of DSCP bits) and vice versa, perform the tasks described in Table 19; enter either or both commands in MPLS router configuration mode.

Table 19    Propagate QoS Using DSCP Bits and MPLS EXP Bits

Task

Root Command

Notes

For packets coming into the SmartEdge router, propagate MPLS EXP bits to DSCP bits.

propagate qos from mpls

 

For packets going out of the SmartEdge router, propagate PD priority values to MPLS EXP bits.

propagate qos to mpls

 

2.10.2   Propagate QoS Using DSCP Bits Only

To propagate QoS by enabling the use of DSCP bits (instead of MPLS EXP bits) only, perform the task described in Table 20.

Table 20    Propagate QoS Using DSCP Bits Only

Task

Root Command

Notes

Enable the use of IP header DSCP bits (not MPLS EXP values) when determining the initial PD priority value of incoming MPLS packets.

egress prefer dscp-qos

Enter this command in MPLS router configuration mode.


2.11   Attach QoS Policies to a Circuit Group and Assign Members to the Group

To create a circuit group, attach a QoS metering, policing or scheduling policy to it, and then assign members to the group, perform the tasks described in Table 21.

Table 21    Attach QoS Policies to a Circuit Group and Assign Members to the Group

Step

Task

Root Command

Notes

1.

Create a circuit group and assign a specified name to it.

circuit group

Enter this command in global configuration mode. For information about this command, see Configuring Circuits.

2.

Attach a (QoS) metering, policing, or scheduling policy to the circuit group.

   
 

Attach a metering policy.

qos policy metering

Enter this command in dot1q PVC configuration mode.

 

Attach a policing policy.

qos policy policing

Enter this command in dot1q PVC configuration mode.

 

Attach a queuing policy.

qos policy queuing

Enter this command in dot1q PVC configuration mode.

3.

Select an Ethernet port in which the members of the circuit group are to reside and access port configuration mode.

port ethernet

Enter this command in global configuration mode.

4.

Specify the use of 802.1Q encapsulation for the Ethernet port.

encapsulation dot1q

Enter this command in port configuration mode.

5.

Specify the 802.1Q tunnel or one or more static 802.1Q PVCs to be assigned to the specified circuit group and access dot1q PVC configuration mode.

dot1q pvc

Enter this command in port configuration mode.

6.

Specify that the 802.1Q tunnel or PVCs being configured are members of the specified circuit group.

circuit-group-member

Enter this command in dot1q PVC configuration mode. For information about this command, see Configuring Circuits.


2.12   Configuring Virtual Port Circuit Groups

For information on how to configure VPCGs, see Configuring VPCGs.

2.13   Configure Nested Circuit Groups

To configure nested circuit groups, perform the tasks described in Table 22; enter the commands in the specified configuration modes. It is assumed you have configured the QoS policies before performing the tasks in Table 22.

Note:  
No limit on the number of nested levels is enforced. However, two to four is the practical range.

Table 22    Configure Nested Circuit Groups

Step

Task

Root Command

Notes

1.

Define a circuit group and specify a port on which all circuits in this circuit group reside. This is the parent circuit group.

circuit group

Enter this command in global configuration mode.

2.

Optional. Attach QoS policies, QoS overhead profiles, rate, or weight to the circuit group and its members.

Enter commands in circuit-group configuration mode.

3.

Define a circuit group, specify a parent circuit group, and specify a port on which all circuits in this circuit group reside.

circuit group

Enter this command in global configuration mode. Use the parent-circuit-group keyword to specify the parent circuit group from which all circuits in this group are subject to inheritance from.


2.14   Configure Ingress Port Propagation

To configure ingress port propagation for cards that support differentiated packet treatment for ingress oversubscription scenarios, perform the tasks described in Table 23.

Table 23    Configure Ingress Port Propagation

Step

Task

Root Command

Notes

1.

Configure a card and access card configuration mode.

card

Enter this command in global configuration mode.

2.

Select an Ethernet port to apply ingress port propagation and access port configuration mode.

port ethernet

Enter this command in global configuration mode.

3.

For incoming packets, configure ingress port propagation. Perform the following steps:

 

Enter the port-propagate commands in port configuration mode.

 

Propagate Ethernet 802.1p user priority bits to PD QoS bits and use the 802.1p bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from ethernet

 
 

Propagate IP DSCP bits to the PD QoS bits and use DSCP bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from ip

 
 

Propagate MPLS EXP bits to PD QoS bits and use EXP bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from mpls

 

2.15   Operations Tasks

To monitor and administer QoS features, perform the appropriate tasks described in Table 24. Enter the debug command in exec mode; enter the show commands in any mode.

Table 24    Monitor and Administer QoS Features

Task

Command

Enable the generation of QoS debug messages.

debug qos

Display information about ACLs attached to QoS policies.

show access-group

Display cell and SAR packet-level counters for configured ATM PVCs.

show atm counters

Display general counters and counters specific to the circuit type for one or more circuits in the system.

show circuit counters

Display the current QoS configuration.

show configuration qos

Display the information for a particular circuit that matches the specified circuit agent ID.

show qos agent-circuit-id

Display the information for all circuits or a particular circuit in the system.

show qos circuit

Display QoS PPA client information.

show qos client

Display QoS hierarchical node information.

show qos h-node

Display QoS daemon memory usage information.

show qos memory

Display information for all QoS policies.

show qos policy

Display the circuit information for a specific subscriber on the system.

show qos username

Display information about one or more QoS metering policies.

show qos policy metering

Display information about one or more QoS policing policies.

show qos policy policing

Display active QoS port bindings for ports on one or more traffic cards.

show qos port-map bind

3   Configuration Examples

This section provides examples of QoS configurations for attaching rate- and class-limiting policies, attaching scheduling policies, and propagating QoS.

3.1   Attaching Rate- and Class-Limiting Policies

Examples of configuring PVCs and subscriber records for QoS policies are provided in the following sections:

3.1.1   PVC Configuration

The following example attaches a metering policy, meter, to an 802.1Q PVC on an Ethernet port:

[local]Redback(config)#port ethernet 4/2

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 200

[local]Redback(config-dot1q-pvc)#bind interface if-200 local

[local]Redback(config-dot1q-pvc)#qos policy metering meter

The following example attaches an EDRR policy, example1, to an ATM PVC and its port on a first-generation ATM OC traffic card:

[local]Redback(config)#port atm 6/1

[local]Redback(config-port)#qos policy queuing example1

[local]Redback(config-atm)#atm pvc 200 300 profile prof1 encaps multi

[local]Redback(config-atmpvc)#qos policy queuing example1

3.1.2   Cross-Connected Circuit Configuration

The following example attaches a metering policy, output, to the inbound circuits of cross-connected 802.1Q PVCs on Ethernet ports:

[local]Redback(config)#port ethernet 4/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 2001

[local]Redback(config-dot1q-pvc)#qos policy metering output

[local]Redback(config-dot1q-pvc)#exit

[local]Redback(config-port)#dot1q pvc 2051

[local]Redback(config-dot1q-pvc)#qos policy metering output

[local]Redback(config-dot1q-pvc)#exit

[local]Redback(config-port)#dot1q pvc 2101

[local]Redback(config-dot1q-pvc)#qos policy metering output

[local]Redback(config-dot1q-pvc)#exit

!

[local]Redback(config)#port ethernet 4/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 2001

[local]Redback(config-dot1q-pvc)#exit

[local]Redback(config-port)#dot1q pvc 2051

[local]Redback(config-dot1q-pvc)#exit

[local]Redback(config-port)#dot1q pvc 2101

!

[local]Redback(config)#xc 4/1 vlan-id 2001 to 4/3 vlan-id 2001

[local]Redback(config)#xc 4/1 vlan-id 2051 to 4/3 vlan-id 2051

[local]Redback(config)#xc 4/1 vlan-id 2101 to 4/3 vlan-id 2101

3.1.3   Subscriber Configuration

The following example attaches a metering policy, meter, to a subscriber record:

[local]Redback(config)#subscriber name redback

[local]Redback(config-sub)#password redback

[local]Redback(config-sub)#qos policy metering meter

3.2   Attaching Scheduling Policies

Examples of configuring ports and PVCs for QoS features using scheduling policies are provided in the following sections:

3.2.1   Port Configuration

The following example attaches a PQ policy to a POS port:

[local]Redback(config)#port pos 2/1

[local]Redback(config-port)#qos policy queuing pos-qos

3.2.2   PVC Configuration

The following example attaches a PQ scheduling policy to each of three 802.1Q PVCs:

[local]Redback(config)#port ethernet 4/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 100

[local]Redback(config-dot1q-pvc)#bind interface if-100 local

[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing

[local]Redback(config-dot1q-pvc)#dot1q pvc 101

[local]Redback(config-dot1q-pvc)#bind interface if-101 local

[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing

[local]Redback(config-dot1q-pvc)#dot1q pvc 102

[local]Redback(config-dot1q-pvc)#bind interface if-102 local

[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing

The following example attaches an EDRR policy, example1, to an ATM PVC and its port on a first-generation ATM OC traffic card:

[local]Redback(config)#port atm 6/1

[local]Redback(config-port)#qos policy queuing example1

[local]Redback(config-atm)#atm pvc 200 300 profile prof1 encaps multi

[local]Redback(config-atmpvc)#qos policy queuing example1

3.2.3   Overhead Profile Configuration

The following example allows the child circuits of 802.1Q PVC 100 to inherit the example1 overhead profile:

[local]Redback(config)#port ethernet 2/1

[local]Redback(config-port)#dot1q pvc 100 encapsulation 1qtunnel

[local]Redback(config-port)#qos profile overhead example1 inherit

3.2.4   PWFQ Policy and Hierarchical Shaping

The following example configures a GE3 port with the home node group with 5 dslam nodes and attaches a PWFQ policy to each node:

[local]Redback(config)#port ethernet 5/2

[local]Redback(config-port)#qos rate maximum 100000000

[local]Redback(config-port)#qos rate minimum 100000

[local]Redback(config-port)#qos hierarchical mode strict

[local]Redback(config-port)#qos node-group home 1

[local]Redback(config-h-node)#qos node dslam 1 through 5

[local]Redback(config-h-node)#qos policy queuing pwfq4

3.2.5   PWFQ Policy and Hierarchical Scheduling

The following example configures a GE3 port and its 802.1Q PVC for hierarchical scheduling and attaches a PWFQ policy to both the port (pwfq-port) and its PVC (pwfq-pvc):

[local]Redback(config)#port ethernet 5/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#qos rate maximum 100000000

[local]Redback(config-port)#qos rate minimum 100000

[local]Redback(config-port)#qos hierarchical mode strict

[local]Redback(config-port)#qos policy queuing pwfq-port

[local]Redback(config-port)#dot1q pvc 200

[local]Redback(config-dot1q-pvc)#qos rate maximum 10000000

[local]Redback(config-dot1q-pvc)#qos rate minimum 10000

[local]Redback(config-dot1q-pvc)#qos policy queuing pwfq-pvc

3.3   Propagating QoS

The following example configures 802.1q profile, 8021q-on, to propagate QoS information between IP and any 802.1Q tunnel or PVC that has that profile assigned to it:

[local]Redback(config)#dot1q profile 8201p-on

[local]Redback(config-dot1q-profile)#propagate qos from ethernet

[local]Redback(config-dot1q-profile)#propagate qos to ethernet

[local]Redback(config-dot1q-profile)#exit

The following example propagates QoS on an 802.1Q PVC by configuring it with the 8021p-on profile:

[local]Redback(config)#port ethernet 3/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 20 profile 8021p-on

[local]Redback(config-dot1q-pvc)#exit

The following example maps control protocols, including VRRP advertisements, to an 802.1p priority value of 3. Control packets are always assigned an internal ToS priority of 6 (that is, CS6), so this example maps priority CS6 to a p bit of 3:

[local]Redback(config)#qos class-map pd-to-8021p ethernet out

[local]Redback(config-class-map)#qos cs6 to ethernet 3

[local]Redback(config-class-map)#exit

[local]Redback(config)#dot1q profile 8201p-on

[local]Redback(config-dot1q-profile)#propagate qos to 
ethernet class-map pd-to-8021p

[local]Redback(config-dot1q-profile)#exit

[local]Redback(config)#port ethernet 1/1

[local]Redback(config-port)#no shutdown

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 100 profile 8021p-on

[local]Redback(config-dot1q-pvc)#bind interface test local

[local]Redback(config-dot1q-pvc)#exit

The following example enables IP QoS information to be propagated to ATM on any ATM PVC or virtual path (VP) that has the profile, clp-on, assigned to it:

[local]Redback(config)#atm profile clp-on

[local]Redback(config-atm-profile)#clpbit propagate qos to atm

[local]Redback(config-atm-profile)#exit

The following example configures MPLS to propagate QoS in both directions:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router mpls

[local]Redback(config-mpls)#propagate qos from mpls

[local]Redback(config-mpls)#propagate qos to mpls

[local]Redback(config-mpls)#exit

The following example creates a classification map exp-to-pd that maps MPLS experimental EXP values to QoS PD values on ingress, then applies the classification map to the propagate qos from mpls command:

[local]Redback(config)#qos class-map exp-to-pd mpls in

[local]Redback(config-class-map)#mapping-schema 7P1D

[local]Redback(config-class-map)#mpls 1 to qos 0x24

[local]Redback(config-class-map)#exit

[local]Redback(config)#context mycontext

[local]Redback(config-ctx)#router mpls

[local]Redback(config-mpls)#propagate qos from mpls class-map exp-to-dscp

[local]Redback(config-mpls)#exit

The following example shows how to propagate Ethernet 802.1p user priority bits, IP DSCP bits, and MPLS EXP bits to PD QoS bits for incoming packets arriving in slot 10, port 1 of an Ethernet port and to use these bits to determine ingress oversubscription treatment. This configuration is applied to a 4-port 10GE card that is in slot 10 of the chassis:

[local]Redback(config)#card 10ge-4-port 10

[local]Redback(config)#port ethernet 10/1

[local]Redback(config-port)#port-propagate qos from ip

[local]Redback(config-port)#port-propagate qos from ethernet

[local]Redback(config-port)#port-propagate qos from mpls

3.4   Attaching QoS Policies to Circuit Groups

The following example shows how to create a circuit group salesgroup and attach previously configured policing and metering policies (group_policing_policy and group_metering_policy ) to this circuit group. This example also shows how to assign the 802.1Q PVC tunnels (50 through 60, 30, and 40) as members of the circuit group. The individual PVCs (or VLANs), 1 to 100, configured under the 802.1Q tunnel 30cvlan_individual_policy. With the hierarchical keyword configured for the policing policy ( each have their own individual policing policy specified as group_metering_policy ), the traffic on the individual PVCs are subject to both the child circuit policy (cvlan_individual_policy ) and the parent circuit policy (group_metering_policy ):

[local]Redback(config)#circuit-group salesgroup

[local]Redback(config-circuit-group)#qos policy policing group_policing_policy hierarchical

[local]Redback(config-circuit-group)#qos policy metering group_metering_policy inherit


[local]Redback(config)#port ethernet 12/1

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 50 through 60

[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup


[local]Redback(config)#port ethernet 12/2

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port)#dot1q pvc 30 encapsulation 1qtunnel

[local]Redback(config-dot1q-pvc)#dot1q pvc 30:1 through 100

[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup

! Specify that each 802.1Q PVC configured under the 802.1Q tunnel also

! has its own individual policing policy (specified as

! cvlan_individual_policy).

[local]Redback(config-dot1q-pvc)#qos policy policing cvlan_individual_policy

[local]Redback(config-dot1q-pvc)#dot1q pvc 40

[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup