2. QoS Policies

This chapter provides information about Quality of Service (QoS) policy management.

2.1. QoS Policies Overview

The 7210 SAS devices are designed with ingress and egress QoS mechanisms to support multiple services per physical port. The 7210 SAS devices have extensive and flexible capabilities to classify, police, queue, shape, and mark traffic.

In the Nokia service router service model, a service is provisioned on the provider-edge (PE) equipment. Service data is encapsulated and then sent in a service tunnel to the far-end Nokia service router where the service data is delivered.

The operational theory of a service tunnel is that the encapsulation of the data between the two Nokia service routers appears as a Layer 2 path to the service data; however, the data is really traversing an IP or IP/MPLS core. The tunnel from one edge device to the other edge device is provisioned with an encapsulation, and the services are mapped to the tunnel that most appropriately supports the service needs.

The 7210 SAS supports eight forwarding classes that are internally named: Network-Control, High-1, Expedited, High-2, Low-1, Assured, Low-2, and Best-Effort. See Forwarding Classes for more information.

The 7210 SAS supports the use of different types of QoS policies to handle the specific QoS needs at each point in the service delivery model within the device. QoS policies are defined in a global context on the 7210 SAS and only take effect when the policy is applied to an entity.

QoS policies are uniquely identified with a policy ID number or name. Typically, Policy ID 1 or Policy ID “default” is reserved for the default policy, however there are a few instances where the default QoS policy uses a different ID. The default QoS policy is used if no policy is explicitly applied.

The QoS policies supported on the 7210 SAS can be divided into the following main types.

  1. QoS policies that are used for classification, defining metering and queuing attributes, and defining marking behavior.
  2. Slope policies that define default buffer allocations and weighted random early detection (WRED) slope definitions.
  3. Port scheduler policies, SAP ingress and egress policies, or network and network-queue policies that determine how queues are scheduled.

2.2. Overview of QoS Policies on 7210 SAS-R6 and 7210 SAS-R12

7210 SAS-R6 and 7210 SAS-R12 QoS policies are applied on service ingress, service egress, access port egress, network port ingress and egress, and network IP interface ingress. These policies allow users to configure the following:

  1. classification rules to map traffic to FCs
  2. FC association with meters and meter parameters used for policing (rate-limiting)
  3. queuing parameters for shaping, scheduling, and buffer allocation
  4. QoS marking and interpretation

QoS policies are the following types:

  1. service ingress policies for access SAP ingress
  2. service egress policies for access SAP egress
  3. access port egress policies for access port egress
  4. access port ingress policies for access port ingress
  5. network policies for network port and hybrid port ingress and egress, and network IP interface ingress
  6. network queue policies for network port and hybrid port egress
  7. queue management policies for buffer allocation and slope configuration on service ingress, service egress, and network port egress
  8. remark policies for service egress, access port egress, network port and hybrid port egress, and network IP interface egress marking

Service ingress QoS policies are applied to the customer-facing SAPs. Traffic that enters through the SAP is classified to map it to an FC. FC is associated with meters on ingress. The mapping of traffic to meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP criteria, and MAC criteria.

The characteristics of the FC meters are defined within the policy with regard to the number of FC meters for unicast traffic and the meter characteristics (like CIR, PIR, and so on). Each FC can be associated with different unicast parameters. A service ingress QoS policy also defines up to three meters per FC, which are used for multipoint traffic for multipoint services. A maximum of 32 meters are supported per service ingress QoS policy.

For VPLS, the following forwarding types are supported:

  1. unicast
  2. multicast
  3. broadcast
  4. unknown

Multicast, broadcast, and unknown forwarding types are flooded to all destinations within the service, while the unicast forwarding type is handled in a point-to-point manner within the service.

On the 7210 SAS-R6 and 7210 SAS-R12, the user has a per-node or per-chassis option to use either a service egress QoS policy with the capability to use eight egress queues per SAP (port-scheduler-mode command disabled), or an access egress policy with the capability to use eight egress queues for all SAPs configured on the access port (port-scheduler-mode command enabled). The former is referred to as “SAP-based egress queuing mode,” and the latter is referred to as “access port-based egress queuing mode.” A service-egress QoS policy or access-egress policy also defines how to remark the FC-to-IEEE 802.1p bits in the customer traffic.

Service egress QoS policies are applied to SAPs and map FCs to service egress queues for a service. This option is available only when using SAP-based egress queuing mode. The system allocates eight queues per SAP for the eight FCs. All traffic types (that is, both unicast and BUM traffic types) classified to the same FC share the same queue on service egress.

A service egress QoS policy defines the FC queue characteristics, and also defines how to remark the FC-to-priority bits in the packet header (for example, IEEE 802.1p bits in the Ethernet VLAN tag) in the customer traffic. When SAP-based egress queuing mode is configured, the access egress policy configures marking values to use on egress. See Access Egress QoS Policies for more information.

An access ingress policy is applied to the physical port instead of the SAP; the policy applies to all SAPs configured on the specific access port. At ingress, the access ingress QoS policy uses dot1p, DEI with dot1p, or IP DSCP values to assign a forwarding class and profile to traffic, which facilitates the classification of traffic received on the access port. The FC is associated with meters at ingress. An access ingress QoS policy allows the user to define up to one meter per forwarding class for unicast traffic, and up to one meter per forwarding class for multipoint traffic (that is, broadcast, multicast, and unknown-unicast) for multipoint services. The system supports up to 16 meters per access ingress QoS policy.

For a SAP-egress policy, an access egress policy is applied on the physical port as opposed to the logical port (SAP). The policy applies to all the SAPs on the port. This option is available only when using SAP-based egress queuing mode. An access egress QoS policy maps the traffic egressing out the customer-facing ports into various queues and marks the traffic accordingly. The FCs are mapped onto the queues.

There are eight queues at the port level. FC-to-queue mapping is not configurable. The number of queues is not user-configurable, and the software allocates eight queues at the port level. All traffic types (that is, both unicast and BUM traffic types) classified to the same FC share the same queue on service egress. An access egress policy also defines how to remark the FC-to-packet header bits (for example, IEEE 802.1p bits in the L2 VLAN header).

Network QoS policies can be applied to the following:

  1. network IP interface
    On ingress, the policy maps incoming MPLS EXP values to the FC and profile state for the MPLS traffic received from the core network. On egress, the policy maps the FC and profile state MPLS EXP to values for MPLS traffic that is transmitted into the core network.
  2. network port
    On ingress, the network policy maps incoming IP packets, DSCP, or dot1p values to the FC and profile state for the IP traffic received from the core network. On egress, the policy maps the FC and profile state to DSCP or dot1p values for IP traffic that is transmitted into the core network.

On egress, network queue policies are applied to network and hybrid ports. The policies define the FC queue characteristics for these entities. The FCs are mapped onto the queues. There are eight queues at the port level. FC-to-queue mapping is not configurable. The number of queues are static and the service always had eight queues at the port level.

Service ingress, service egress, access egress, and network QoS policies are defined with a scope of either template or exclusive. Template policies can be applied to multiple entities (such as SAPs and ports); exclusive policies can only be applied to a single entity.

One service ingress and one service egress QoS policy can be applied to a specific SAP access egress policy, which can then be applied to an access port. One network QoS policy can be applied to a specific IP interface or network port based on the type of network QoS policy. A network QoS policy defines both ingress and egress behavior. One network queue policy can be applied to the network port.

If no QoS policy is explicitly applied to a SAP, port, or interface, a default QoS policy is applied.

The 7210 SAS-R6 and 7210 SAS-R12 can operate in either the low SAP scale mode or high SAP scale mode. In low SAP scale mode, SAP and service scaling is limited by the amount of CAM resources available for the SAP ingress policy (both classification and meters). In the high SAP scale mode, SAP and service scaling are significantly higher compared to the low SAP scale mode and use access port ingress policies. The use of network port policies remains unchanged when the system is operating in high SAP scale mode; however, the high SAP scale mode assumes that the user requires Layer 2 uplinks, and uses access port ingress and egress policies on those uplinks.

SAPs configured on ports operating in hybrid mode cannot be configured to use access ingress QoS policies. Therefore, the access-ingress-qos port-mode option is not supported for ports configured in hybrid mode.

The following QoS policies are supported on access ports and SAPs in the low SAP scale mode:

  1. service ingress policy for SAP ingress classification and metering using the following:
    1. CAM-based classification and metering
    2. table-based classification and CAM-based metering
  2. service egress policy for SAP egress queuing, shaping, and scheduling with an egress policy for marking only
  3. access egress policy for access port egress queuing, shaping, scheduling, and marking (this policy is mutually exclusive with the use of service egress policies)

The following QoS policies are supported on access ports and SAPs in the high SAP scale mode:

  1. the choice of an access port ingress policy on access service delivery ports or per-SAP ingress policies; Nokia recommends using an access port ingress policy for higher SAP scaling
  2. access egress policy for port egress queuing, shaping, scheduling, and marking (this policy is mutually exclusive with the use of service egress policies)

Table 5 describes the major functions performed by QoS policies for 7210 SAS-R6 and 7210 SAS-R12.

Table 5:  QoS Policy Types and Descriptions for 7210 SAS-R6 and 7210 SAS-R12 

Policy Type

Applied at

Description

Section

Service ingress

Access SAP ingress

  1. Defines up to 32 FC meters and meter parameters for traffic classification
  2. Defines match criteria to map flows to the meters based on any one of the criteria (IP or MAC, or both IP and MAC)
  3. Optionally, can map the priority bits (DSCP) to FC and profile using table-based classification

Service Ingress QoS Policies

Service egress

SAP egress

  1. Available only in SAP-based egress queuing mode
  2. Defines up to eight FC queues
  3. Maps FCs to queues
  4. Defines queue parameters for the queues
  5. Defines FC-to-remarking values
  6. Defines CIR levels and PIR weights that determine how the queue is prioritized by the scheduler

Service Egress QoS Policies

Access Ingress

Access Port

  1. Defines dot1p and IP DSCP classification criteria to use
  2. Defines up to 16 meters per access ingress QoS policy

Access Ingress QoS Policies

Access egress

Access port

The following is available only in access port-based egress queuing mode:

  1. Defines up to eight FC queues
  2. Maps FCs to queues
  3. Defines queue parameters for the queues
  4. Defines FC-to-remarking values
  5. Defines queue priorities that determine how the queue is prioritized by the scheduler
  6. In SAP-based egress queuing mode, access egress is used to configure the FC-to-remarking map values

Access Egress QoS Policies on 7210 SAS-R6 and 7210 SAS-R12

Network (type = ip-interface)

Network IP interface

  1. Used for classification and marking of MPLS packets
  2. On ingress, defines MPLS LSP-EXP-to-FC mapping, and defines up to 16 FC meters
  3. On egress, defines FC-to-MPLS LSP-EXP marking

Network QoS Policies of the “ip-interface” Type

Egress rate

Access and network port

Configures the maximum bandwidth available for traffic sent out of a specified port

Egress Port Rate Limiting

Network (type = port)

Network and hybrid ports

  1. Used for classification and marking of IP packets
  2. On ingress, defines DSCP or dot1p-to-FC mapping, and up to 16 FC meters
  3. On egress, defines FC-to-DSCP or dot1p marking, or both

Network QoS Policies of the “port” Type

Network queue

Network and hybrid ports

  1. Defines FC mappings to network queues and queue characteristics for the queues

Network Queue Policies in Network Mode

Queue management policies

Queues at service ingress, service egress, and network egress

  1. Defines the CBS and MBS parameters for the queues
  2. Enables or disables the high-slope and low-slope parameters for the queues

Queue Management Policies

Remark

SAP egress,

network egress (port and IP interface)

  1. Defines the FC-to-remarking values

Remark Policies

2.3. Network and Service QoS Policies

Different QoS mechanisms are used with the 7210 SAS platforms based on the types of traffic on the interface. For customer interfaces, there are service ingress and service egress traffic types. For traffic received and sent to the network core over network ports and IP interfaces, there are network ingress and network egress traffic types, as shown in Figure 1.

Figure 1:  7210 SAS Traffic Types 

The 7210 SAS uses the following QoS policies applied to a SAP, network port, access port, or access-uplink port to define queuing, queue attributes, meter/policer attributes, and QoS marking interpretation.

The 7210 SAS supports the following types of service and network QoS policies:

  1. Network QoS Policies
  2. Network Queue Policies in Network Mode
  3. Service Ingress QoS Policies
  4. Service Egress QoS Policies

2.3.1. Network QoS Policies

The following apply to network QoS policies configured in network mode.

  1. Two types of network QoS policies can be defined: ip-interface and port. By default, a network QoS policy is created as the ip-interface type.
  2. Create a network QoS policy of the ip-interface type using the config qos network network-policy-id network-policy-type ip-interface create command.
  3. Create a network QoS policy of type the port type using the config qos network network-policy-id network-policy-type port create command.
  4. A network QoS policy of the ip-interface type, when it is applied to a network port or hybrid port IP interface, is used for classification of MPLS packets received based on LSP-EXP bits and marking of MPLS-EXP bits for MPLS traffic sent out of an IP interface.
  5. A network QoS policy of the port type, when it is applied to a network and hybrid port, is used for classification of IP packets based on the DSCP or dot1p bits.
  6. On 7210 SAS-R6 and 7210 SAS-R12, an option is available to reallocate resources needed by network QoS ingress to other features sharing the ingress-internal-tcam resource pool. Users must ensure that sufficient resources are available for network ingress QoS, if the user intends to use network ports and network IP interfaces.

2.3.1.1. Network QoS Policies of the “ip-interface” Type

Network QoS policies of the ip-interface type define ingress FC meters and map traffic to those meters for IP interfaces. When created, each network QoS policy has two meters defined within the policy that cannot be deleted; one meter handles the unicast traffic, and the other meter handles the multipoint traffic. These meters are used when the policy is applied to an IP interface. A remarking policy can be specified to define the FC-to-EXP bit marking, on egress.

The following apply to network QoS policies of the ip-interface type:

  1. ingress
    1. defines EXP value mapping to FCs and the ingress profile. Ingress profile assignment using MPLS EXP values is configured using the mpls-lsp-exp-profile-map policy.
    2. defines FC-to-meter mapping. By default, meters are color aware. The user cannot disable the meters or change the meter color mode (the meter color mode is always set to color-aware).
  2. egress
    1. specifies a remark policy that defines the FC-to-EXP value markings
    2. remarking of QoS bits can be enabled or disabled

The elements required by a network QoS policy are the following:

  1. a unique network QoS policy ID
  2. must specify a remark policy to define the FC-to-value mappings for each FC
  3. a default ingress FC and in-profile or out-of-profile state
  4. at least one default unicast FC meter. See Committed Information Rate (Meters) for information about meter configuration parameters.
  5. optional multipoint FC meter

Optional network QoS policy elements include:

  1. additional unicast meters, up to eight
  2. additional multipoint meters, up to eight
  3. EXP value to FC and profile state mappings for all EXP values received

Network policy ID 2 is reserved as the default network QoS policy of the ip-interface type. The default policy cannot be deleted or changed. Default network QoS policy 2 is applied to all IP interfaces that do not have another network QoS policy explicitly assigned.

The egress component of the network QoS policy applied to the network IP interface also determines how or whether the profile state is marked in packets transmitted into the service core network. If the profile state is marked in the service core packets, out-of-profile packets are preferentially dropped over in-profile packets at congestion points in the core network. For network egress, traffic remarking in the default network QoS policy is disabled. Table 6 lists the default mapping of FC-to EXP-values.

Table 6:  Default Network QoS Policy (ip-interface Type) Egress Marking 

FC-ID

FC Name

FC Label

Egress MPLS EXP Marking

In-Profile

Out-of-Profile

7

Network Control

nc

111 - 7

111 - 7

6

High-1

h1

110 - 6

110 - 6

5

Expedited

ef

101 - 5

101 - 5

4

High-2

h2

100 - 4

100 - 4

3

Low-1

l1

011 - 3

010-2

2

Assured

af

011-3

010 - 2

1

Low-2

l2

001 - 1

001 - 1

0

Best Effort

be

000 - 0

000 - 0

For network ingress, Table 7 lists the default mapping of EXP values to FC and profile state for the default network QoS policy.

Table 7:  Default Network QoS Policy (ip-interface Type) EXP-to-FC Mapping 

MPLS EXP Value

FC Ingress

Profile

0

be

Out

1

l2

In

2

af

Out

3

af

In

4

h2

In

5

ef

In

6

h1

In

7

nc

In

2.3.1.2. Network QoS Policies of the “port” Type

Network QoS policies of the port type define ingress FC meters, and map traffic to those meters for only IP traffic received on network and hybrid ports. When created, each network QoS policy of this type has a single meter defined within the policy that cannot be deleted. The meter is used when the policy is applied to a network port. It also defines the FC-to-DSCP or dot1p marking used for packets sent through that port.

A network QoS policy of the port type defines both the ingress and egress handling of QoS on the network port.

The following apply to network QoS policies of the port type:

  1. ingress
    1. defines DSCP or dot1p value mapping to FCs and the ingress profile. Only one type is supported (such as DSCP or dot1p) per policy. The option exists to use DEI bits along with dot1p classification for profile assignment. See DEI-Based Classification and Marking for more information about using DEI.
    2. defines FC-to-meter mapping. By default, meters are color aware. The user cannot disable meters or change the meter color mode (meter color mode is always set to color-aware).
  2. egress
    1. specifies a remark policy that defines FC-to-DSCP or dot1p value markings
    2. remarking of QoS bits can be enabled or disabled
    1. FC-to-DSCP marking used to mark only IP traffic sent out through that port, if marking is enabled
    2. FC-to-dot1p marking for MPLS packet is not supported; FC-to-dot1p marking is supported only for IP packets

The elements required in a network QoS policy of the port type are:

  1. a unique network QoS policy ID and network-policy-type set to port
  2. egress FC to DSCP or dot1p value mappings for each FC
  3. a default ingress FC and in-profile or out-of-profile state
  4. at least one default unicast FC meter. See Meter/Policer Parameters for information about the parameters that can be configured for a meter.

Optional network QoS policy elements include the following:

  1. additional unicast meters, up to eight
  2. additional multipoint meters, up to eight
  3. a DSCP or dot1p value to FC and profile state mappings for all DSCP or dot1p values received.
  4. option to use DEI bits along with dot1p classification for profile state mapping

Network policy ID 1 is reserved as the default network QoS policy of the port type. The default policy cannot be deleted or changed.

The default network QoS policy is applied to all network ports that do not have another network QoS policy explicitly assigned.

Table 8 lists the default mapping of FC-to-dot1p and DSCP values.

Table 8:  Default Network QoS Policy of “port” Type Egress Marking  

FC-ID

FC Name

FC Label

Egress DSCP Marking

Egress Dot1p Marking

In-Profile

Out-of-Profile

In-Profile

Out-of-profile

7

Network Control

nc

nc2

nc2

111 - 7

111 - 7

6

High-1

h1

nc1

nc1

110-6

110-6

5

Expedited

ef

ef

ef

101-5

101-5

4

High-2

h2

af41

af41

100-4

100-4

3

Low-1

l1

af21

af22

011-3

010-2

2

Assured

af

af11

af12

011-3

010-2

1

Low-2

l2

cs1

cs1

001-1

001-1

0

Best Effort

be

be

be

000-0

000-0

Table 9 lists the default mapping of dot1p and DSCP values to FC and profile state for the default network QoS policy of the port type for network ingress. Color-aware policing is supported on network ingress.

Table 9:  Default Network QoS Policy of the “port” Type — Dot1p/DSCP-to-FC Mapping 

DSCP Value

Dot1p Value

FC Ingress

Profile

be

0

be

Out

cs1

1

l2

In

af12

2

af

Out

af11

3

af

In

af41

4

h2

In

ef

5

ef

In

nc1

6

h1

In

nc2

7

nc

In

2.3.2. Network Queue Policies in Network Mode

In the network mode of operation, network queue policies define the network FC queue characteristics. Network queue policies are applied on egress on network and hybrid ports for 7210 SAS devices operating in network mode. The system allocates a fixed number of queues for the network port, and FCs are mapped to these queues. All policies use fixed number queues, like the default network queue policy.

Eight queues are allocated for a network queue policy and eight FCs are mapped to these eight queues. Table 20 lists the FC-to-queue mapping.

The network queues on hybrid ports are used for MPLS traffic, IP traffic, and SAP traffic sent out of IP interfaces, and SAPs configured on hybrid ports.

The queue characteristics that can be configured on a per-FC basis are the following:

  1. peak information rate (PIR) as a percentage of egress port bandwidth
  2. committed information rate (CIR) as a percentage of egress port bandwidth
  3. committed burst size (CBS) (using the queue-management policies)
  4. maximum burst size (MBS) (using the queue-management policies)
  5. queue-mode, strict or weighted
  6. adaptation rules for CIR and PIR
  7. WRED slope parameters (using the queue-management policy)

Network queue policies are identified with a unique policy name that conforms to the standard 7210 SAS alphanumeric naming conventions. The system default network queue policy is named “default” and cannot be edited or deleted. CBS values cannot be provisioned.

Table 10 list the default network queue policy definition.

Table 10:  Default Network Queue Policy Definition for 7210 SAS-R6 and 7210 SAS-R12 

FC

Queue

Definition

Network-Control (nc)

Queue 8

  1. PIR = 100%
  2. CIR = 5%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-1 (h1)

Queue 7

  1. PIR = 100%
  2. CIR = 5%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Expedited (ef)

Queue 6

  1. PIR = 100%
  2. CIR = 20%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-2 (h2)

Queue 5

  1. PIR = 100%
  2. CIR = 20%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-1 (l1)

Queue 4

  1. PIR = 100%
  2. CIR = 10%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Assured (af)

Queue 3

  1. PIR = 100%
  2. CIR = 10%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-2 (l2)

Queue 2

  1. PIR = 100%
  2. CIR = 10%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Best-Effort (be)

Queue 1

  1. PIR = 100%
  2. CIR = 0%
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

2.3.3. Service Ingress QoS Policies

Service ingress QoS policies define ingress service FCs and map flows to those FCs. The FC is configured with a meter/policer to limit the rate. When a service ingress QoS policy is created, it has a single meter defined that cannot be deleted and is used for all the traffic (both unicast and multicast traffic). These meters exist within the definition of the policy but only get instantiated in hardware when the policy is applied to a SAP. In the case where the service does not have multipoint traffic, the multipoint meters are not instantiated.

In the simplest service ingress QoS policy, all traffic is handled as a single flow and mapped to a single meter, including all flooded traffic. The required elements to define a service ingress QoS policy are the following:

  1. a unique service ingress QoS policy ID
  2. a QoS policy scope of template or exclusive
  3. the number of classification and meter resources to allocate for this policy
  4. the allocation of resources from the ingress internal CAM resource pool for use with service ingress QoS policies. Additionally, the allocation of resources to the appropriate classification match criteria.
  5. at least one default FC meter

Optional service ingress QoS policy elements include the following:

  1. additional unicast meters, up to eight
  2. additional multipoint meters, up to 24. QoS policy match criteria to map packets to an FC.
  3. QoS policy match criteria to map packets to an FC
  4. ability for users to select dot1p or DSCP for SAPs in Layer 2 services (Epipe and VPLS)
  5. FC can be configured to use a meter
  6. DSCP table-based classification

The the following options are available when using resources for classification and policing:

  1. CAM-based classification and policing
    Resources for both classification and policing are allocated from the CAM-based classification and meter resource pool. Resources from the CAM-based pool can be configured using the configure system resource-profile ingress-internal-tcam qos-sap-ingress-resource command. The user then has the flexibility to use IP criteria (both IPv4 and IPv6) and MAC criteria for classification of traffic flows to an FC. This option allows each SAP to define its own FC-to-meter map, which is the default option that is enabled when the system boots up with the default configuration.
  2. table-based classification and CAM-based policing
    Resources for classification are allocated from the table-based classification pool of resources, and policing resources are allocated from the CAM-based meter resource pool. Resources for the CAM-based pool can be configured using the configure system resource-profile ingress-internal-tcam qos-sap-ingress-resource command. See Service Ingress QoS Policies for examples showing how to configure this option. Using this option, the classification of traffic flows can be performed only using IP DSCP and or dot1p bits (see Service Ingress QoS Policies for classification support details). The use of IP and MAC criteria are mutually exclusive. Using this option allows each SAP to define its own FC-to-meter map.

Each meter or queue can have unique meter or queue parameters to allow individual policing or shaping of the flow mapped to the FC. Figure 2 shows service traffic being classified into three different FCs.

Figure 2:  Traffic Queuing Model for FCs 

Mapping flows to FCs is controlled by comparing each packet to the match criteria in the QoS policy. The ingress packet classification to FC requires a provisioned classification policy.

On SAP ingress, users have an option to use either MAC criteria or IP criteria, or both IPv4 and MAC criteria. To use the available classification resources effectively, the following options are available:

  1. supported MAC header fields using the mac-criteria any option
  2. only dot1p bits in the MAC header using the mac-criteria dot1p-only option
  3. supported IPv4 header fields using the ip-criteria any option
  4. only IPv4 DSCP in the IPv4 header using the ip-criteria dscp-only option
  5. supported IPv6 header fields using the ipv6-criteria any option
  6. only IPv6 DSCP bits in the IPv6 header using the ipv6-criteria dscp-only option
  7. both MAC and IPv4 header fields using the both the MAC and IPv4 criteria option together in a policy

Among the supported options, the following can be configured together in a single policy:

  1. mac-criteria any
  2. mac-criteria dot1p-only
  3. ip-criteria any and/or ipv6-criteria any, or ipv6-criteria dscp-only
  4. ip-criteria dscp-only and/or ipv6-criteria any or ipv6-criteria dscp-only
  5. mac-criteria any and ip-criteria any, or ip-criteria dscp-only and/or ipv6-criteria dscp-only
  6. mac-criteria dot1p-only and ip-criteria any, or ip-criteria dscp-only and/or ipv6-criteria dscp-only
Note:

When specifying both MAC and IPv4 criteria in a single SAP-ingress policy, only IPv6 DSCP match is allowed. Other IPv6 fields, such as src-address and dst-address, are not allowed.

In addition to the classification rules listed previously in this section, an optional DEI bit is available to identify the ingress profile and enable color-aware policing. See DEI-Based Classification and Marking for more information. The 7210 SAS-R6 and 7210 SAS-R12 also provide an option to use DSCP table-based classification to assign both FC and profile on SAP ingress for use with color-aware meters. See Service Ingress QoS Policies.

Note:

See Service Ingress QoS Policies for more information about the resource allocation required for each of these criteria.

The IP and MAC match criteria can be very basic or quite detailed. IP and MAC match criteria are assembled using policy entries. An entry is identified by a unique, numerical entry ID. A single entry cannot contain more than one match value for each match criteria. Each match entry has an action that specifies the FC of packets that match the entry.

The entries are evaluated in numerical order based on the entry ID from the lowest to highest ID value. The first entry that matches all match criteria has its action performed.

Table 11 lists the supported IPv4, MAC, and IPv6 header fields for SAP ingress classification.

Table 11:  Service Ingress QoS Policy Match Criteria for 7210 SAS-R6 and 7210 SAS-R12 

Match Criteria

Description

IP criteria

IP DSCP and IP precedence value (available for SAPs in VPLS, VLL, PBB Epipe I-SAP, PBB VPLS I-SAP, IES, VPRN, and R-VPLS services)

IP source and mask, IP destination and mask, IP protocol, TCP/UDP source port, TCP/UDP destination port (available only for SAPs in VPLS, VLL, PBB Epipe I-SAP, PBB VPLS I-SAP, IES, VPRN, and R-VPLS services)

IPv6 criteria

IP DSCP and IP precedence value (available for SAPs in VPLS, VLL, PBB services)

IPv6 128-bit source and mask, IPv6 128-bit destination and mask, IP protocol/next-header, TCP/UDP source port, TCP/UDP destination port (available only for SAPs in VPLS, VLL, PBB Epipe I-SAP, PBB VPLS I-SAP)

MAC criteria

IEEE 802.1p/dot1p value/mask, source MAC address/mask, destination MAC address/mask, EtherType Value/Mask (available for VLL, VPLS, PBB (Epipe I-SAP, VPLS I-SAP, B-SAP), IES, VPRN, and R-VPLS services)

The MAC match criteria that can be used for an Ethernet frame depends on the format of the frame. Table 12 and Table 13 describe MAC Ethernet frame types and list the MAC match criteria frame type dependencies.

Table 12:  MAC Match Ethernet Frame Types  

Frame Format

Description

802.3

IEEE 802.3 Ethernet frame. Only the source MAC, destination MAC, and IEEE 802.1p value are compared for match criteria.

Ethernet-II

Ethernet type II frame where the 802.3 length field is used as an Ethernet type (Etype) value. Etype values are two-byte values greater than 0x5FF (1535 decimal).

Table 13:  MAC Match Criteria Frame Type Dependencies  

Frame Format

Source MAC

Dest MAC

IEEE 802.1p Value

Etype Value

802.3

Yes

Yes

Yes

No

ethernet-II

Yes

Yes

Yes

Yes

Service ingress QoS policy ID 1 is reserved for the default service ingress policy. The default policy cannot be deleted or changed.

The default service ingress policy is implicitly applied to all SAPs that do not explicitly have another service ingress policy assigned. In the default policy, no queues are defined. All traffic is mapped to the default FC, which uses one meter by default. Table 14 lists the characteristics of the default policy.

Table 14:  Default Service Ingress Policy ID 1 Definition  

Characteristic

Item

Definition

Meter

Meter 1

1 (one) all unicast traffic:

  1. Default Forward Class (FC): best-effort (be)
  2. mode = trtcm1
  3. CIR, PIR = Closest (adaptation-rule)
  4. CIR = 0
  5. PIR = max
  6. MBS, CBS = default kilobits (values derived from applicable policy)
  7. color-mode = color-blind

Flows

Default FC

1 (one) flow defined for all traffic:

  1. All traffic mapped to best-effort (be)

The available ingress CAM hardware resources can be allocated according to user needs for use with different QoS classification match criteria. By default, the system allocates a single meter and two classification entries, so that all traffic is mapped to a single FC and the FC uses a single meter. Users can change the resource allocation based on the need to scale the number of entries or number of associations (that is, number of SAPs using a policy that uses a particular match criterion). If no resources are allocated to particular match criteria used in the policy, the association of that policy to a SAP fails. Allocation of classification entries also allocates meter resources, which are used to implement the per-FC per-traffic type policing function. See Resource Allocation for Service Ingress QoS Policies for information about resource use and allocation to SAP ingress policies.

2.3.3.1. Table-Based Classification

The 7210 SAS-R6 and 7210 SAS-R12 provide an option to use table-based classification using either IP DSCP or dot1p classification to assign both an FC and profile on SAP ingress for use with color-aware meters. See Service Ingress QoS Policies for more information.

2.3.3.2. Hierarchical Ingress Policing

Hierarchical ingress policing allows users to specify the amount of traffic admitted into the system per SAP. It also allows users to share the available bandwidth per SAP among the different FCs of the SAP. For example, users can allow the packets classified as Internet data to use the entire SAP bandwidth when other FCs do not have traffic.

Hierarchical ingress policing provides an option to configure a SAP-ingress aggregate policer per SAP on SAP ingress. The user should configure the PIR rate for the ingress aggregate policer and optionally configure the burst size.

The SAP-ingress aggregate policer monitors the traffic on different FCs and determines whether the packet is forwarded or dropped. The final behavior of the packet is based on the operating rate of the following:

  1. per-FC policer
  2. per-SAP aggregate policer

For more information about the final color/profile assigned to the packet, refer to the 7210 SAS-R6, R12 Services Guide, configure service sap ingress aggregate-meter-rate command description.

The trtcm2 (RFC 4115) meter mode is used only on SAP ingress. When the SAP-ingress aggregate policer is configured, the per-FC policer can be configured only in trtcm2 mode. The meter modes srtcm and trtcm1 can be used only if a SAP-ingress aggregate meter is not configured for use with the SAP.

Note:

Before using per-SAP ingress aggregate meters/policers, meter resources must be allocated using the config system resource-profile ingress-internal-tcam sap-aggregate-meter command. A change to the number of resources allocated for a SAP aggregate meter requires a reboot of the node to take effect. The amount of resources allocated for this feature determines the number of SAPs that can use the aggregate meter/policer. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information.

2.3.4. Service Egress QoS Policies

Service egress queues are implemented at the transition from the service core network to the service access network. The advantages of per-service queuing before transmission into the access network are the following:

  1. per-service egress sub-rate capabilities, especially for multipoint services
  2. more granular, fairer scheduling per-service into the access network
  3. per-service statistics for forwarded and discarded service packets
Note:

  1. On egress of access ports, use either port-based egress queuing and shaping, or SAP-based egress queuing and shaping for SAPs configured on the port. Use the config system global-resource-profile qos port-scheduler-mode command to select the mode for SAPs configured on either access ports or hybrid ports. This per-node setting affects all SAPs and access ports.
  2. When port-scheduler-mode is enabled, the software uses eight egress queues per port (access port or hybrid port). See Service Egress QoS Policies for more information. When port-scheduler-mode is disabled, the software allocates eight egress queues per SAP, which are configured using service egress policies.

The sub-rate capabilities and per-service scheduling control are required to make multiple services per physical port possible. Without egress shaping, it is impossible to support more than one service per port. There is no way to prevent service traffic from bursting to the available port bandwidth and starving other services.

For accounting purposes, per-service statistics can be logged. When statistics from service ingress queues are compared with service egress queues, the ability to conform to per-service QoS requirements within the service core can be measured. The service core statistics are a major asset to core provisioning tools.

Service egress QoS policies define egress queues and map FC flows to queues. The system allocates eight queues to service egress by default. To define a basic egress QoS policy, the following are required:

  1. a unique service egress QoS policy ID
  2. a QoS policy scope of template or exclusive

See Queue Parameters for information about parameters that can be configured for a queue.

Optional service egress QoS policy elements include specifying a remark policy that defines IEEE 802.1p priority value remarking, based on FC.

The user has an option to use SAP-based marking. With SAP-based marking, the remark policy defined in the SAP-egress policy associated with each SAP is used to mark the packets egressing out of the SAP, if marking is enabled. The user can also enable port-based marking, in which case the remark policy defined in the access-egress policy associated with the access port determines the marking values to use for all the SAPs defined on that port. See Access Egress QoS Policies for more information.

Each queue in a policy is associated with one of the FCs. Each queue can have individual queue parameters, which allow individual rate shaping of the FCs mapped to the queue.The FC per service egress packet is determined at ingress. If the packet ingresses the service on the same node, the service ingress classification rules determine the FC of the packet. If the packet is received on a network port over an MPLS tunnel, the FC is marked in the tunnel transport encapsulation (for example, MPLS EXP bits).

The FC-to-queue map is fixed and the queue priority is determined by the queue number, with a higher queue number having the higher priority. The user can configure a queue to be a strict queue to change the scheduling behavior for the queue. See Schedulers for more information.

Note:

When using SAP-based egress queues, only unicast traffic sent out of RVPLS SAPs uses per-SAP egress queues. BUM traffic sent out of RVPLS SAPs uses per-port egress queues.

Service egress QoS policy ID 1 is reserved as the default service, which does not have another service egress policy explicitly assigned. Table 15 lists the characteristics of the default policy for 7210 SAS-R6 and 7210 SAS-R12 platforms.

Table 15:  Default Service Egress Policy “default” Definition for 7210 SAS-R6 and 7210 SAS-R12 

Characteristic

Item

Definition

Queues

Queue 1-8

1 (one) queue defined for each traffic class

Network-Control (nc)

Queue 8

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-1 (h1)

Queue7

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Expedited (ef)

Queue 6

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-2 (h2)

Queue 5

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-1 (l1)

Queue 4

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Assured (af)

Queue 3

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-2 (l2)

Queue 2

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Best-Effort (be)

Queue 1

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

The marking values used to mark traffic from different FCs are defined by the remark policy in the access egress policy. Table 16 lists the remarking policy for type dot1p for 7210 SAS-R6 and 7210 SAS-R12.

Table 16:  Default Remarking Policy for dot1P on 7210 SAS-R6 and 7210 SAS-R12  

FC (FC)

In-profile

Out-Profile

Network-Control (nc)

7

7

High-1 (h1)

6

6

Expedited (ef)

5

5

High-2 (h2)

4

4

Low-1 (l1)

3

2

Assured (af)

3

2

Low-2 (l2)

1

1

Best-Effort (be)

0

0

Note:

  1. For L2 SAPs, if remarking is enabled for the SAP-egress policy and port-based marking is enabled, the values configured in the SAP-egress policy are used. For L3 SAPs, the values configured in the access-egress policy are used.
  2. If remarking is disabled for the SAP-egress policy and port-based marking is enabled, the IP DSCP values are marked, even for the traffic egressing out of the L2 SAPs configured on the port. To avoid this, Nokia recommends using only FC-to-dot1p values when both L2 and L3 SAPs are configured on the same access port.

2.4. Access Ingress QoS Policies

This section describes the access ingress QoS policies supported on the 7210 SAS-R6 and 7210 SAS-R12.

An access ingress QoS policy defines the ingress QoS processing for packets received on the access port when the configure port ethernet access-ingress-qos-mode command is set to port-mode.

When the access-ingress-qos-mode command is set to sap-mode, no access ingress QoS policy is attached to the port. When the access-ingress-qos-mode command is set to port-mode, access ingress policy 1 is attached by default, and this policy can be replaced with a user-defined access ingress QoS policy.

The access ingress QoS policy defines the ingress classification rule that uses dot1p and IP DSCP values from the packet header to map traffic flows to up to eight (8) FCs and assign a profile at ingress. In addition, the user also has an option to use DEI with dot1p classification for color assignment. Each FC can be associated with up to two (2) meters: one meter for unicast traffic and another for multipoint traffic (that is, broadcast, multicast and unknown-unicast traffic). The user can configure meter characteristics such as CIR and PIR rates, CBS and MBS, and so on.

Define the following to configure a basic access ingress QoS policy:

  1. a unique service access QoS policy ID
  2. parameters that can be configured for a meter, as described in Meter/Policer Parameters
  3. dot1p and DSCP classification policy to map dot1p and IP DSCP values to the FC
  4. an optional configuration to choose either IP DSCP or dot1p values, both, or the default FC values for classification
  5. an optional configuration to assign an access ingress profile for use with a color-aware meter using either a dot1p, DEI with dot1p, or IP DSCP

Access ingress QoS policy ID 1 is reserved as the default policy for access ports to which an access ingress policy is not explicitly assigned. Table 17 lists the characteristics of the default access ingress policy ID 1.

Table 17:  Default Access Ingress Policy ID 1 Definition 

Item

Definition

Meter 1

1 (one) meter all unicast traffic:

  1. Mode: trtcm1
  2. Adaptation rule: cir closest pir closest
  3. CIR = 0
  4. PIR = max
  5. Color mode: color-aware
  6. MBS, CBS = default kbits (values derived from applicable policy)

Meter 9

1 (one) meter all multicast traffic:

  1. Mode: trtcm1
  2. Adaptation rule: cir closest pir closest
  3. CIR = 0
  4. PIR = max
  5. Color mode: color-aware
  6. MBS, CBS = default kbits (values derived from applicable policy)

Default forwarding class (be)

1 (one) flow defined for all traffic:

  1. All traffic mapped to best-effort (be)
  2. Counter mode: in-out-profile-count
  3. dot1p-classification 1 (default dot1p classification policy)
  4. dscp-classification 1 (default IP DSCP classification policy)
  5. table-classification-criteria: both-dscp-dot1p
  6. num-qos-classifiers = 4

2.5. Access Egress QoS Policies on 7210 SAS-R6 and 7210 SAS-R12

On the 7210 SAS-R6 and 7210 SAS-R12, an access-egress policy allows users to define the marking values for the traffic sent out of the access ports towards the customer. Access-egress QoS policies map FC flows to marking values. In addition, based on the queuing mode used on access egress, it also defines the per-port queue parameters.

2.5.1. Access Egress QoS Policies for SAP-Based Queuing Mode

The 7210 SAS-R6 and 7210 SAS-R12 support SAP-based marking for access SAPs and port-based egress marking on access ports. SAP-based marking is only supported for L2 SAPs, which are SAPs configured in Epipe and VPLS services. If users enable remarking in the SAP-egress policy attached to the SAP, the configured remark policy is used to mark the packets sent out of the SAP. If remarking is disabled in the SAP-egress policy attached to the SAP, the remark policy configured under the access-egress policy associated with the egress-access port is used to mark all packets sent out of the L2 SAP configured on the access port. This is known as port-based marking.

Port-based marking is supported primarily for L3 SAPs (that is, SAPs configured in VPRN services and IES services). SAP-based marking is not supported for L3 SAPs.

No explicit CLI command is provided to choose between port-based marking and SAP-based marking for L2 SAPs. The user can choose SAP-based marking by enabling remarking in the SAP-egress policy attached to the L2 SAP, or port-based marking by disabling remarking in the SAP egress policy attached to the SAP and enabling remarking in the access-egress policy associated with the access port where the L2 SAP is configured.

A remarking policy can be defined for each access-egress policy and remarking is disabled by default. Only remarking policy of the type dot1p, dot1p-lsp-exp-shared, dscp, or dot1p-dscp can be used with access-egress policy. The following is the marking behavior with different remark policy types.

  1. If the remark policy type is dot1p or dot1p-lsp-exp-shared, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the dot1p bits marked.
  2. If the remark policy type is dscp, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the IP DSCP bits marked (assuming L2 SAPs are carrying IP traffic).
  3. If the remark policy type is dot1p-dscp, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the IP DSCP bits (assuming L2 SAPs are carrying IP traffic) and dot1p bits marked.
Note:

  1. For L2 SAPs, if remarking is enabled for the SAP-egress policy and port-based marking is enabled, the values configured in the SAP-egress policy are used. For L3 SAPs, the values configured in the access-egress policy are used.
  2. If remarking is disabled for the SAP-egress policy and port-based marking is enabled, IP DSCP values get marked even for the traffic egressing out of the L2 SAPs configured on the port. To avoid this, Nokia recommends using only FC-to-dot1p values when both L2 and L3 SAPs are configured on the same access port.
  3. When using SAP-based egress queues and scheduling (that is, no port-scheduler-mode), only the configured remarking value and remark policy are used from the default access-egress policy. The queue configuration from the default access-egress policy is not used. For more information, see Table 15 and Table 19.

2.5.2. Access Egress QoS Policy for Port-Based Queuing Mode

When port-based queues are enabled in addition to marking values, the access-egress QoS policy provides an option to define port-based queues and scheduling.

Users have an option to use either port-based egress queuing and shaping or SAP-based egress queuing and shaping for SAPs configured on access ports or hybrid ports. The config system global-resource-profile qos port-scheduler-mode command allows users to select the mode used for SAPs configured on all the ports of the node (this is a per-node setting). When port-scheduler-mode is enabled, the software uses eight egress queues per access port, and all the SAPs configured on the port share the eight egress queues for traffic sent out of that port.

When port-scheduler-mode is enabled, the queue parameters for the access port egress queues are defined using the access-egress policies.

Modify queue parameters for a specific queue using the queue override feature. See QoS Overrides for Meters/Policers for more information.

Additionally, the marking values used to mark traffic from different FCs are defined by the remark policy in the access-egress policy. Per-SAP marking cannot be used when port-based queuing mode is used. A remarking policy can be defined for each access-egress policy and remarking is disabled by default. Only a remarking policy of the type dot1p, dot1p-lsp-exp-shared, dscp, or dot1p-dscp can be used with an access-egress policy. The following is the marking behavior for different remark policy types.

  1. If the remark policy type is dot1p or dot1p-lsp-exp-shared, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the dot1p bits marked.
  2. If the remark policy type is dscp, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the IP DSCP bits marked (assuming L2 SAPs are carrying IP traffic).
  3. If the remark policy type is dot1p-dscp, all traffic sent out of L2 SAPs and L3 SAPs configured on that port has the IP DSCP bits (assuming L2 SAPs are carrying IP traffic) and dot1p bits marked.
Note:

  1. When port-scheduler-mode is disabled, per-SAP egress queues are available. The per-SAP egress queues are configured in the service egress policies.
  2. When port-based queues are enabled, SAPs configured on hybrid ports share the egress queues with network port traffic. Packets sent out a SAP on a hybrid port use the marking values (if remarking is enabled) defined in the network QoS policy associated with the hybrid port.
  3. When port-based queuing mode is enabled, RVPLS SAPs use the port-based egress queues for both unicast and BUM traffic; as a result, all SAPs, including RVPLS SAPs, share the eight egress queues created per port.

Access-egress QoS policies define egress queues and map FC flows to queues, if port-scheduler-mode is enabled. Using port-scheduler-mode, the system allocates eight queues to access port egress by default. To define a basic access-egress QoS policy, the following are required:

  1. unique access-egress QoS policy ID
  2. QoS policy scope of template or exclusive

See Queue Parameters for information about the parameters that can be configured for a queue.

Optional service-egress QoS policy elements include the following:

  1. specifying a remark policy that defines IEEE 802.1p priority value remarking based on FC

When port-based queuing is used, the FC-to-queue map is fixed and the queue priority is determined by the queue number, with higher queue numbers having the higher priority. The user can configure a queue to be a strict queue to change the scheduling behavior for the queue.

Access-egress QoS policy ID 1 is reserved as the default access-egress policy. The default policy cannot be deleted or changed. The default access-egress policy is applied to all access ports that do not have another access-egress policy explicitly assigned. By default, sap-qos-marking is enabled. Table 18 and Table 19 list the characteristics of the default policy.

Table 18:  Default Access-Egress QoS Policy “default” Definition for 7210 SAS-R6 and 7210 SAS-R12 

Characteristic

Item

Definition

Network-Control (nc)

Queue 8

  1. CIR = 0
  2. PIR = max
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-1 (h1)

Queue7

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Expedited (ef)

Queue 6

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

High-2 (h2)

Queue 5

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-1 (l1)

Queue 4

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Assured (af)

Queue 3

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Low-2 (l2)

Queue 2

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1

Best-Effort (be)

Queue 1

  1. CIR = 0
  2. PIR = max (line rate)
  3. queue-mgmt = default
  4. queue-mode = weighted
  5. weight = 1
Table 19:  Default Remarking Policy for dot1P on 7210 SAS-R6 and 7210 SAS-R12  

FC (FC)

In-profile

Out-Profile

Network-Control (nc)

7

7

High-1 (h1)

6

6

Expedited (ef)

5

5

High-2 (h2)

4

4

Low-1 (l1)

3

2

Assured (af)

3

2

Low-2 (l2)

1

1

Best-Effort (be)

0

0

2.6. Remark Policies

This policy defines the FC-to-egress marking values. Based on the packet encapsulation used to send out the service packets, the remark policy allows the user to define and associate appropriate policies to service egress and network egress QoS policies. 7210 SAS supports the following types of remark policies:

  1. dot1p
    This policy is used for service egress, access port egress, and network QoS (port type) policies.
  2. dscp
    This policy is used for access port egress marking and network QoS (port type) policies.
  3. lsp-exp
    The policy is used for network QoS (ip-interface type) policies.
  4. dot1p-dscp
    This policy is used for access port egress marking and network QoS (port type) policies.
  5. dot1p-lsp-exp-shared
    This policy is used for access port egress, access port egress marking, and network QoS (ip-interface type) policies.

Each of these remark policy types can be associated with only appropriate QoS policies, as describes in the previous list. Refer to the section about marking support on network egress, SAP egress and access port egress in the 7210 SAS-R6, R12 Quality of Service Guide.

Note:

On the 7210 SAS-R6 and 7210 SAS-R12, when the port-based scheduling mode is enabled per-node for SAPs, only per-port egress marking policies are supported; per-SAP egress marking is not supported for L2 and L3 SAPs.

The required elements to define a remark QoS policy are the following:

  1. unique remark QoS policy ID
  2. FC to appropriate marking values

2.6.1. Egress Port Rate Limiting

The 7210 SAS supports port egress rate limiting. This feature allows the user to limit the bandwidth available on the egress of the port to a value less than the maximum possible link bandwidth. It also allows the user to control the amount of burst sent out.

2.6.2. Forwarding Classes

The 7210 SAS supports multiple FCs and class-based queuing, which means that the concept of FCs is common to all the QoS policies.

Each FC (also called Class of Service (CoS)) is important only in relation to the other FCs. An FC provides network elements a method to weigh the relative importance of one packet over another in a different FC.

Queues are created for a specific FC to determine the manner in which the queue output is scheduled. The FC of the packet, along with the in-profile or out-of-profile state, determines how the packet is queued and handled (the per-hop behavior (PHB)) at each hop along its path to a destination egress point. Table 20 describes the FCs supported by the 7210 SAS.

Table 20:  Forwarding Classes 

FC ID

FC Name

FC Designation

DiffServ Name

Notes

7

Network Control

NC

NC2

Intended for network control traffic

6

High-1

H1

NC1

Intended for a second network control class or delay/jitter sensitive traffic

5

Expedited

EF

EF

Intended for delay/jitter sensitive traffic

4

High-2

H2

AF4

Intended for delay/jitter sensitive traffic

3

Low-1

L1

AF2

Intended for assured traffic. Also is the default priority for network management traffic.

2

Assured

AF

AF1

Intended for assured traffic

1

Low-2

L2

CS1

Intended for BE traffic

0

Best Effort

BE

BE

Table 20 lists the default definitions for the FCs. The FC behavior, in terms of ingress marking interpretation and egress marking, can be changed; see Network QoS Policies for more information. All FC queues support the concept of in-profile and out-of-profile.

2.6.2.1. FC-to-Queue ID Map

Eight FCs are supported on the 7210 SAS devices. Each of these FCs is mapped to a specific queue. By mapping FCs to different queues, the differential treatment is imparted to various classes of traffic.

By default, the 7210 SAS allocates eight queues to SAP egress (or optionally access port egress) and network. The queues cannot be created or deleted by the user. CLI commands allow the user to configure the queue parameters.

The queue IDs 1 to 8 are assigned to each of the eight queues. Queue ID 8 is the highest priority and queue ID 1 is the lowest priority. FCs are correspondingly mapped to these queue IDs according to their priority. Table 21 describes the system-defined map is described. This mapping is not user configurable.

Note:

On the 7210 SAS-R6 and 7210 SAS-R12, users can configure the queue to be strict mode or weighted mode. Strict priority queues are serviced before weighted queues. See Schedulers for more information about scheduling behavior and queue parameters.

Table 21:  FC-to-Queue ID Map  

FC-ID

FC Name

FC Designation

Queue-ID

7

Network control

NC

8

6

High-1

H1

7

5

Expedited

EF

6

4

High-2

H2

5

3

Low-1

L1

4

2

Assured

AF

3

1

Low-2

L2

2

0

Best-Effort

BE

1

2.6.3. QoS Policy Entities

Services are configured with default QoS policies. Additional policies must be explicitly created and associated. The following policies are configured by default:

  1. one default service ingress QoS policy
  2. one default service egress QoS policy
  3. one default network QoS policy
  4. one default network queue policy

Only one ingress QoS policy and one egress QoS policy can be applied to a SAP or IP interface, or network port.

When you create a new QoS policy, default values are provided for most parameters, with the exception of the policy ID and descriptions. Each policy has a scope, default action, a description, and meters for ingress policies and queues for egress policies. The queue is associated with an FC.

QoS policies can be applied to the following service types:

  1. Epipe
    SAP-ingress and SAP-egress policies are supported on an Epipe SAP.
  2. VPLS
    SAP-ingress and SAP-egress policies are supported on a VPLS SAP.
  3. VPRN
    SAP-ingress and SAP-egress policies are supported on a VPRN SAP.
  4. IES
    SAP-ingress and SAP-egress policies are supported on a IES service.
  5. R-VPLS
    R-VPLS-ingress and SAP-egress policies are supported on a R-VPLS service.

QoS policies can be applied to the following entities:

  1. SAP-ingress and SAP-egress policies on access SAPs; optionally, access-egress policies on access ports
  2. network QoS policies (ingress) on network ports or network IP interfaces
  3. network queue policies on network ports

Default access QoS policies map all traffic with equal priority and allow an equal chance of transmission (best effort (be) FC) and an equal chance of being dropped during periods of congestion. QoS prioritizes traffic according to the FC and uses congestion management to control access ingress, access egress, and network traffic, with queuing according to priority.

2.6.3.1. QoS Policy Entities for Hybrid Ports on 7210 SAS-R6 and 7210 SAS-R12

An overview of QoS policy support on hybrid ports is described in this section.

The following policies are available when SAP-based queues are enabled.

  1. Network queue policies are supported for queue configuration of egress queues on hybrid ports. These egress queues are used by traffic sent out of network IP interfaces configured on hybrid ports.
  2. Network QoS (ip-interface type) policies are supported for network IP interfaces on hybrid ports. The behavior is similar to the existing behavior for network IP interfaces on network ports. The policies support per IP interface ingress classification and policing, and egress marking (only EXP marking for MPLS traffic).
  3. Network QoS (port type) policies are supported for hybrid ports. The behavior is similar to existing behavior for network ports. The policies support per-port ingress classification and policing, and egress marking (dot1p and DSCP marking). For marking IP control traffic sent out of network IP interfaces configured on hybrid port, users must use the network QoS policy of the port type, with an option to mark dot1p, DSCP, or both.
  4. SAP-ingress QoS policies are supported for SAPs configured on hybrid ports. The behavior is similar to existing behavior for access SAP ingress, which supports per-SAP ingress classification and policing.
  5. Service-egress policies are supported for queue configuration of per SAP egress queues for SAPs configured on hybrid ports. These egress queues are used by traffic sent out of SAPs configured on hybrid port. For traffic sent out of SAPs configured in L2 services, dot1p can be marked per-SAP using the service egress policy. An option is provided to mark only dot1p, only IP DSCP, or both dot1p and IP DSCP, for traffic sent out of SAPs configured in L3 services. One of the options can be used per-port by configuring the network QoS port type policy. If DSCP marking or both is specified, all traffic, including traffic sent out of SAPs configured in a L2 services, is marked with IP DSCP.

When port-based queues are enabled for SAPs, the QoS policies available for use with hybrid port are the same as in the previous list, with the following exceptions:

  1. Network queue policies are supported for queue configuration of egress queues on hybrid ports. These egress queues are shared by traffic sent out of SAPs and network IP interfaces configured on hybrid port, which means that per-SAP service egress policies are not available for use.
  2. For traffic sent out of SAPs (both for SAPs configured in L2 services and SAPs configured in L3 services) configured with hybrid ports, an option is provided to mark only dot1p, only IP DSCP, or both dot1p and IP DSCP. One of the options can be used per-port, by configuring the network QoS port type policy.
    If DSCP marking or both is specified, traffic sent out of SAPs configured in an L2 service are not marked with IP DSCP.

2.7. Meters/Policers

This section provides information about meters/policers.

2.7.1. Meter/Policer Parameters

This section describes the supported meter parameters.

In network mode of operation, meter/policer is available with the following:

  1. SAP ingress policies
  2. network QoS policies of the port type, associated with network port ingress or hybrid port ingress
  3. network QoS policy of the ip-interface type, associated with network IP interfaces configured on a network port or hybrid port

2.7.1.1. Meter ID

The meter ID uniquely identifies the meter. The meter ID is only unique within the context of the QoS policy within which the meter is defined.

2.7.1.2. Committed Information Rate (Meters)

The committed information rate (CIR) for a meter is the long-term average rate at which traffic is considered conforming traffic or in-profile traffic. The higher the rate, the greater the expected throughput. The user can burst above the CIR and up to the PIR for brief periods of time. The time and profile of the packet is determined based on the burst sizes. See Committed Burst Size and Maximum Burst Size.

When defining the CIR for a meter, the value specified is the administrative CIR for the meter. The 7210 SAS devices have a number of native rates in the hardware that determine the operational CIR for the meter. The user has some control over how the administrative CIR is converted to an operational CIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation Rule for Meters for information about the interpretation of the administrative CIR.

The CIR for meters is provisioned on service ingress and network ingress within service ingress QoS policies and network QoS policies, respectively.

2.7.1.3. Peak Information Rate (Meters)

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the meter. The PIR does not specify the maximum rate at which packets can enter the meter; this is controlled by the ability of the meter to absorb bursts and is defined by its maximum burst size (MBS).

When defining the PIR for a meter, the value specified is the administrative PIR for the meter. The 7210 SAS devices have a number of rates in hardware that determine the operational PIR for the meter. The user has some control over how the administrative PIR is converted to an operational PIR, if the hardware does not support the exact CIR and PIR combination specified. See Adaptation Rule for Meters for information about the interpretation of the administrative PIR.

The PIR for meters is provisioned on service ingress and network ingress within service ingress QoS policies and network QoS policies, respectively.

2.7.1.4. Adaptation Rule for Meters

The adaptation rule provides the QoS provisioning system with the ability to adapt the administrative rates provisioned for CIR and PIR, to derive the operational rates based on the underlying capabilities of the hardware. The administrative CIR and PIR rates are translated to actual operational rates, which are enforced by the hardware meter. The rule provides a constraint for when the exact rate is not available as a result of hardware capabilities. Table 22 list supported rates and burst step sizes.

Table 22:  Supported Hardware Rates for CIR and PIR Values for 7210 SAS-R6 and 7210 SAS-R12 

Rate (kb/s)

Rate Step Size (bits)

2048 to 4095

2

4096 to 8191

4

8192 to 16383

8

16384 to 32767

16

32768 to 65535

32

65536 to 131071

64

131072 to 262143

128

262144 to 524287

256

524288 to 1048575

512

1048576 to 2097151

1024

2097152 to 4194303

2048

4194304 to 8388607

4096

8388608 to max

8192

The system attempts to find the best operational rate, depending on the defined constraint. The following constraints are supported:

  1. minimum
    The system finds the next multiple of the hardware step size that is equal to or greater than the specified rate.
  2. maximum
    The system finds the next multiple of the hardware step size that is less than or equal to the specified rate.
  3. closest
    The system finds the next multiple of the hardware step size that is closest to the specified rate.

Table 23 lists the rate values configured in the hardware when different PIR or CIR rates are specified in the CLI.

Table 23:  Administrative Rate Example  

Administrative Rate

Operation Rate (Min)

Operation Rate (Max)

Operation Rate (Closest)

8

8

8

8

10

16

8

8

118085

11808

11800

11808

46375

46376

46368

46376

If the configured value is greater than 0 and less than 8, the operation rate configured in the hardware is 8 kb/s, irrespective of the constraint.

Note:

The configured burst size affects the rate step size used by the system. The system uses the step size to ensure that both the burst size and rate parameter constraints are met. For example, if the rate specified is less than 4 Gb/s but the burst size is 17 Mb, the system uses rate step size of 16 kb and burst step size of 8192 bits.

2.7.1.5. Committed Burst Size (Meters/Policers)

The CBS command specifies the committed burst size that can be transmitted by the source at the CIR while complying with the CIR. If the transmitted burst is lower than the CBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter-configured parameters.

The operational CBS set by the system is adapted from the user-configured value by using the minimum constraint.

2.7.1.6. Maximum Burst Size (Meters/Policers)

For Two Rate Three Color Marking (trTCM), the MBS command specifies the maximum burst size that can be transmitted by the source at the PIR while complying with the PIR. If the transmitted burst is lower than the MBS value, the packets are marked as out-of-profile by the meter to indicate that the traffic is not complying with CIR, but complying with PIR.

For Single Rate Three Color Marking (srTCM), the MBS command specifies the maximum burst size that can be transmitted by the source while not complying with the CIR. If the transmitted burst is lower than the MBS value, the packets are marked as out-of-profile by the meter to indicate that the traffic is not complying with CIR.

If the packet burst is higher than MBS, packets marked as red are dropped.

The operational MBS set by the system is adapted from the user-configured value by using the minimum constraint.

2.7.1.7. Meter Counters

The 7210 SAS devices maintain counters for meters within the system for granular billing and accounting. Each meter maintains the following counters:

  1. counters for packets and octets marked as in-profile by the meter
  2. counters for packets and octets marked as out-of-profile by the meter
  3. optional counter for dropped and forwarded packets and octets is supported

2.7.1.8. Meter Modes

The 7210 SAS devices support the following meter modes:

  1. srTCM: Single Rate Three Color Marking
  2. trTCM: Two Rate Three Color Marking (applicable only for network QoS policies)
  1. trTCM1: Two Rate Three Color Marking (applicable only for service ingress QoS policies)
  2. trTCM2: Two Rate Three Color Marking (applicable only for service ingress QoS policies)

In srTCM, the CBS and MBS token buckets are replenished at single rate, that is, CIR; in trTCM, CBS and MBS buckets are individually replenished at CIR and PIR rates, respectively. In trTCM1, the policing algorithm is implemented as defined in RFC 2698; in trTCM2 the policing algorithm is implemented as defined in RFC 4115.

2.7.2. Color-Aware Policing

In color-aware policing, the user can define the color of the packet using the classification and feed the colored packets to the meter. A color-aware meter handles packets according to the color defined on ingress. The following applies to color-aware policing.

  1. If the packet is pre-colored as in-profile (also called green packets), depending on the burst size of the packet, the meter can either mark it in-profile or out-profile.
  2. If the packet is pre-colored as out-of-profile (also called yellow packets), even if the packet burst is less than the current available CBS, the packet is marked as in-profile and continues as out-profile.
  3. If the packet burst is higher than the MBS, it is marked red and dropped by the meter at ingress.

The profile marked by the meter determines the eligibility of the packet to be enqueued into a buffer on egress (when a slope policy is configured on egress).

In color-blind mode, the profile and color assigned to the packet on ingress is ignored. The CIR and PIR rate configured for the meter determines the final profile for the packet. If the packet is within the CIR, the final profile assigned to the packet is in-profile/green, and if the packets exceeds the CIR and is within the PIR, the final profile assigned to the packet is out-of-profile/yellow. Packets that exceed the PIR rate are dropped.

In color-aware mode, the meter uses the profile assigned to the packet on ingress. The profile can be assigned on ingress either by enabling DEI classification, as done on access ports, or by assigning the profile based on either dot1p or DEI, as done on network ports and access-uplink ports. On the 7210 SAS-R6 and 7210 SAS-R12, the profile can also be assigned on service (or SAP) ingress by using a DSCP classification policy while using table-based classification.

The 7210 SAS devices support color-aware policing on network ingress; however, on service ingress, a policing option is provided to use either color-aware policing or color-blind policing.

2.7.3. QoS Overrides for Meters/Policers

The QoS override feature on access SAPs allows the user to override the meter/policer parameters, such as CBS, MBS, rate (CIR and PIR), mode, and adaptation rule (CIR and PIR), in the SAP context.

When the meter or queue parameter values are not overridden, the values are taken from the SAP-ingress policy. See Configuration Guidelines for QoS Overrides for information about configuring overrides for meters/policers.

2.8. Queue Management

This section provides information about QoS queue management.

2.8.1. Queue Parameters

This section describes the parameters available for queues.

On the 7210 SAS-R6 and 7210 SAS-R12, queues are available for use with the following:

  1. network queue policies associated with network port or hybrid port egress
  2. SAP-egress policies associated with access SAP egress

2.8.1.1. Queue ID

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy where the queue is defined.

2.8.1.2. Committed Information Rate

The CIR for a queue performs the following functions:

  1. minimum bandwidth guarantees
    The egress queue CIR setting provides the bandwidth for the queue, as compared to other queues on the port that are competing for the available link bandwidth. The queue CIR guarantees bandwidth in all scenarios, assuming sufficient link port bandwidth capacity is available.
    On the 7210 SAS platforms, the CIR rate cannot be oversubscribed. For each packet in an egress queue, the CIR is checked with the current transmission rate of the queue. If the current rate is at or below the CIR threshold, the queue is considered in-profile. If the current rate is above the threshold, the queue is considered out-of-profile. The profile state of the queue is linked to scheduler prioritizing behavior, as described in the following bullet point.
  2. scheduler queue priority metric
    The scheduler for a group of egress queues prioritizes individual queues based on their current CIR and PIR states. Queues operating below their CIR are always served before those queues operating at or above their CIR. See Schedulers for more information.

On egress, queues never mark the packets as in-profile or out-profile based on the queue CIR and PIR values. The in-profile and out-profile state of the queue interacts with the scheduler mechanism and provides the minimum and maximum bandwidth guarantees.

When defining the CIR for a queue, the value specified is the administrative CIR for the queue. The user has some control over how the administrative CIR is converted to an operational CIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation Rule for Meters for information about the interpretation of the administrative CIR.

Although the 7210 SAS is flexible in how the CIR can be configured, there are conventional ranges for the CIR based on the FC of a queue. A queue associated with the high-priority class normally has the CIR threshold equal to the PIR rate, although the 7210 SAS allows the CIR to be provisioned to any rate below the PIR, if required.

The CIR for a queue is provisionedf on egress using the service egress QoS policy.

The CIR for the network queues are defined within network queue policies based on the FC. The CIR for network queues is specified as a percentage of the network interface bandwidth.

2.8.1.3. Peak Information Rate

The PIR defines the maximum rate at which packets are allowed to exit the queue. The PIR does not specify the maximum rate at which packets can enter the queue; this is determined by the ability of the queue to absorb bursts. The actual transmission rate of a egress queue depends on more than just its PIR. Each queue is competing with other queues for transmission bandwidth. The PIR, CIR, and relative priority and weight of the scheduler serving each queue combine to affect the ability of the queue to transmit packets.

The PIR is provisioned on egress queues using service egress QoS policies.

The PIR for network queues are defined using network queue policies based on the FC. The PIR for the queues is specified as a percentage of the network interface bandwidth.

When defining the PIR for a queue, the value specified is the administrative PIR for the queue.The user has some control over how the administrative PIR is converted to an operational PIR, if the hardware does not support the exact CIR and PIR values specified. See Adaptation Rule for Queues for information about the interpretation of the administrative PIR.

2.8.1.4. Adaptation Rule for Queues

The adaptation rule provides the QoS provisioning system with the ability to adapt defined CIR and PIR administrative rates to the underlying capabilities of the hardware where the queue will be created, which derives the operational rates. The administrative CIR and PIR rates are translated to actual operational rates enforced by the hardware queue. The rule provides a constraint used when the exact rate is not available as a result of hardware implementation trade-offs.

For the CIR and PIR parameters individually, the system attempts to find the best operational rate, depending on the defined constraint. The following constraints are supported:

  1. minimum
    The system finds the hardware supported rate that is equal to or greater than the specified rate.
  2. maximum
    The system finds the hardware supported rate that is less than or equal to the specified rate.
  3. closest
    The system finds the hardware supported rate that is closest to the specified rate.

Depending on the hardware where the queue is provisioned, the actual operational CIR and PIR settings used by the queue depend on the method the hardware uses to implement and represent the mechanisms that enforce the CIR and PIR rates.

The 7210 SAS-R6 and 7210 SAS-R12 use a rate step value based on the configured rate to define the granularity for both the CIR and PIR rates. See Table 24 for 7210 SAS-R6 and 7210 SAS-R12 values. The adaptation rule controls the method the system uses to choose the rate step based on the administrative rates defined by the rate command.

Table 24:  Supported Hardware Rates for CIR and PIR Values for 7210 SAS-R6 and 7210 SAS-R12 

Rate (kbps)

Rate Step Size (bits)

0 to 2047

8

2048 to 4095

8

4096 to 8191

8

8192 to 16383

8

16384 to 32767

16

32768 to 65535

32

65536 to 131071

64

131072 to 262143

128

262144 to 524287

256

524288 to 1048575

512

1048576 to 2097151

1024

2097152 to 4194303

2048

4194304 to 8388607

4096

8388608 to max

8192

If the adaptation rule is minimum, the operational CIR and PIR values are 99 kbps and 161 kbps. The hardware step rate is 12.359619, because the native hardware rate is equal to or greater than the administrative CIR and PIR values.

If the adaptation rule is maximum, the operational CIR and PIR values are 87 kbps and 149 kbps.

If the adaptation rule is closest, the operational CIR and PIR values are 87 kbps and 149 kbps, respectively, because those are the closest matches for the administrative values that are even multiples of the 12.359619 kbps rate step.

2.8.1.5. Queue Priority and Weight

The user has an option to specify whether the SAP egress queue is a strict or weighted queue. The priority of the queue is determined by the FC of the queue, with the higher priority FC being assigned a queue at a higher priority. The user can specify the weight of the queue for weighted queues. The pir-weight command determines the proportion of the available bandwidth that is allocated to the queues that are vying for bandwidth at the same priority.

2.8.1.6. Committed Burst Size and Maximum Burst Size

The CBS and MBS parameters specify the amount of buffer reserved for a queue, and up to how much buffer a queue can compete for in the shared buffer space, respectively. After the reserved buffers for a queue are used, the queue competes with other queues for shared buffer resources up to the MBS.

The CBS and MBS for the queues are configurable for access and network ports and access uplink ports. The CBS and MBS values for the queues are set to default values that handle specific FC needs in maintaining differential treatment.

The default CBS and MBS values are as follows:

  1. CBS (network queue) — 128 kbytes
  2. CBS (access queue) — 10 kbytes
  3. MBS (network queue) — 256 kbytes
  4. MBS (access queue) — 64 kbytes

2.8.2. Buffer Pools

The 7210 SAS-R6 and 7210 SAS-R12 have a single buffer pool per node, the system pool. All the queues created by the system are allocated buffers from this system pool. Queues come up with default buffers, and the buffers change accordingly when they are associated with a network port or SAP. Queue management policies allow the user to specify the parameters that determine buffer allocation to the queues. Buffer pools cannot be created or deleted in the 7210 SAS.

2.8.3. Queue Management Policies

Queue management policies define the queue buffer and WRED slope parameters.

The 7210 SAS supports a single buffer pool per node. All the queues created in the system are allocated buffers from the system pool. The default buffers are allocated to the queues accordingly when they are associated with a SAP or a network port.

Queue management policies define the CBS, MBS, and WRED parameters for use by the queue. The CBS and MBS parameters allocate the appropriate amount of buffer from the system pool to the queues. The WRED parameters define the WRED slope characteristics. Users can define a high-slope and a low-slope for each of the queues. High-priority slope is used for in-profile packets being enqueued into the queues, and low-priority slope is used for out-of-profile packets being enqueued into the queues.

By default, each queue is associated with a default queue-management policy. The default policy allocates the appropriate amount of CBS and MBS buffer based on whether the queue is associated with a SAP or network port.

Note:

If WRED is not configured, tail drop is used.

2.8.3.1. Operation and Configuration of WRED Slopes

This section describes the operation and configuration of weighted random early detection (WRED) slopes.

The 7210 SAS provides a single buffer pool for use by all the queues created in the system. Each queue provides users with an option to configure a high-priority WRED slope and a low-priority WRED slope.

The high-priority RED slope manages access to the shared portion of the buffer pool for high-priority or in-profile packets. The low-priority RED slope manages access to the shared portion of the buffer pool for low-priority or out-of-profile packets.

By default, the high-priority and low-priority slopes are disabled.

The WRED uses average queue lengths, queue thresholds provisioned, and drop probability to calculate the eligibility of a packet to be enqueued. The committed portion of the buffer pool is exclusively used by a queue to enqueue traffic within a committed rate.

For the queues within a buffer pool, packets are either queued using CBS buffers or shared buffers. The CBS buffers are buffer memory that is allocated to the queue while the queue depth is at or below its CBS threshold. The amount of CBS assigned to all queues depends on the number of queues created, the setting of the default CBS defined in the policy, and any CBS values set per queue within a QoS policy. However, from a functional perspective, the buffer pool does not keep track of the total of the CBS assigned to queues serviced by the pool. CBS subscription on the pool is an administrative function that must be monitored by the queue provisioner.

For each queue, the amount of access and network buffer pools and the percentage of the buffers that are reserved for CBS buffers are configured by the software (cannot be changed by users). This setting indirectly assigns the amount of shared buffer on the pool. This is an important function that controls the ultimate average and total shared buffer utilization value calculation for WRED slope operation. The CBS setting can dynamically maintain the buffer space on which the WRED slopes operate.

When queue depth exceeds the CBS of the queue, packets received on the queue must contend with other queues exceeding their CBS for shared buffers. To resolve this contention, the buffer pool uses two WRED slopes to determine buffer availability on a packet-by-packet basis. A packet that was either classified as high priority or considered in-profile is handled by the high-priority WRED slope. This slope should be configured with WRED parameters that prioritize buffer availability over packets associated with the low-priority WRED slope. Packets classified as low priority or out-of-profile are handled by this low-priority WRED slope.

The following is a simplified overview of how a WRED slope determines shared buffer availability on a packet basis.

  1. The WRED function keeps track of shared buffer utilization and shared buffer average utilization.
  2. At initialization, the utilization is zero and the average utilization is zero.
  3. When each packet is received, the current average utilization is plotted on the slope to determine the discard probability for the packet.
  4. A random number is generated, associated with the packet, and is compared to the discard probability.
  5. The lower the discard probability, the lower the chances that the random number is within the discard range.
  6. If the random number is within the range, the packet is discarded, which results in no change to the utilization or average utilization of the shared buffers.
  7. A packet is discarded if the utilization variable is equal to the shared buffer size, or if the utilized CBS (actually in use by queues, not just defined by the CBS) is oversubscribed and has stolen buffers from the shared size, lowering the effective shared buffer size equal to the shared buffer utilization size.
  8. If the packet is queued, a new shared buffer average utilization is calculated using the time-average-factor (TAF) for the buffer pool. The TAF describes the weighting between the previous shared buffer average utilization result and the new shared buffer utilization in determining the new shared buffer average utilization. See Tuning the Shared Buffer Utilization Calculation.
  9. The new shared buffer average utilization is used as the shared buffer average utilization next time a packet probability is plotted on the WRED slope.
  10. When a packet is removed from a queue (if the buffers returned to the buffer pool are from the shared buffers), the shared buffer utilization is reduced by the amount of buffer returned. If the buffers are from the CBS portion of the queue, the returned buffers do not result in a change in the shared buffer utilization.

Figure 3 shows how a RED slope is a graph with an X (horizontal) and Y (vertical) axis. The X-axis plots the percentage of shared buffer average utilization, ranging from 0 to 100 percent. The Y-axis plots the probability of packet discard marked as 0 to 1. The actual slope can be defined as four sections in (X, Y) points.

Figure 3:  RED Slope Characteristics 

The following describe the sections shown in Figure 3.

  1. Section A is (0, 0) to (start-avg, 0). This is the part of the slope where the packet discard value is always zero, preventing the RED function from discarding packets when the shared buffer average utilization falls between 0 and start-avg.
  2. Section B is (start-avg, 0) to (max-avg, max-prob). This part of the slope describes a linear slope where packet discard probability increases from zero to max-prob.
  3. Section C is (max-avg, max-prob) to (max-avg, 1). This part of the slope describes the instantaneous increase of packet discard probability from max-prob to one. A packet discard probability of 1 results in an automatic discard of the packet.
  4. Section D is (max-avg, 1) to (100%, 1). On this part of the slope, the shared buffer average utilization value of max-avg to 100% results in a packet discard probability of 1.

Plotting any value of shared buffer average utilization results in a value for packet discard probability from 0 to 1. Changing the values for start-avg, max-avg, and max-prob allows the adaptation of the RED slope to the needs of the access or network queues using the shared portion of the buffer pool, including disabling the RED slope.

2.8.3.1.1. Tuning the Shared Buffer Utilization Calculation

The 7210 SAS allows tuning the calculation of the Shared Buffer Average Utilization (SBAU) after assigning buffers for a packet entering a queue as used by the RED slopes to calculate a packet’s drop probability. It implements a time average factor (TAF) parameter in the buffer policy which determines the contribution of the historical shared buffer utilization and the instantaneous Shared Buffer Utilization (SBU) in calculating the SBAU. The TAF defines a weighting exponent used to determine the portion of the shared buffer instantaneous utilization and the previous shared buffer average utilization used to calculate the new shared buffer average utilization. To derive the new shared buffer average utilization, the buffer pool takes a portion of the previous shared buffer average and adds it to the inverse portion of the instantaneous shared buffer utilization (SBU). The formula used to calculated the average shared buffer utilization is shown in Figure 4.

Figure 4:  Calculation for Average Shared Buffer Utilization 

where:

SBAUn = Shared buffer average utilization for event n

SBAUn-1 = Shared buffer average utilization for event (n-1)

SBU = The instantaneous shared buffer utilization

TAF = The time average factor

Table 25 describes the effect the allowed values of TAF have on the relative weighting of the instantaneous SBU and the previous SBAU (SBAUn-1) on calculating the current SBAU (SBAUn).

Table 25:  TAF Impact on Shared Buffer Average Utilization Calculation  

TAF

2TAF

Equates To

Shared Buffer Instantaneous Utilization Portion

Shared Buffer Average Utilization Portion

0

20

1

1/1 (1)

0 (0)

1

21

2

1/2 (0.5)

1/2 (0.5)

2

22

4

1/4 (0.25)

3/4 (0.75)

3

23

8

1/8 (0.125)

7/8 (0.875)

4

24

16

1/16 (0.0625)

15/16 (0.9375)

5

25

32

1/32 (0.03125)

31/32 (0.96875)

6

26

64

1/64 (0.015625)

63/64 (0.984375)

7

27

128

1/128 (0.0078125)

127/128 (0.9921875)

8

28

256

1/256 (0.00390625)

255/256 (0.99609375)

9

29

512

1/512 (0.001953125)

511/512 (0.998046875)

10

210

1024

1/1024 (0.0009765625)

1023/2024 (0.9990234375)

11

211

2048

1/2048 (0.00048828125)

2047/2048 (0.99951171875)

12

212

4096

1/4096 (0.000244140625)

4095/4096 (0.999755859375)

13

213

8192

1/8192 (0.0001220703125)

8191/8192 (0.9998779296875)

14

214

16384

1/16384 (0.00006103515625)

16383/16384 (0.99993896484375)

15

215

32768

1/32768 (0.000030517578125)

32767/32768 (0.999969482421875)

The value specified for the TAF affects the speed at which the shared buffer average utilization tracks the instantaneous shared buffer utilization. A low value weights the new shared buffer average utilization calculation more to the shared buffer instantaneous utilization. When TAF is zero, the shared buffer average utilization is equal to the instantaneous shared buffer utilization. A high value weights the new shared buffer average utilization calculation more to the previous shared buffer average utilization value. The TAF value applies to all high and low priority RED slopes for ingress and egress buffer pools controlled by the buffer policy.

2.8.3.2. Queue Management Policy Parameters

The elements required to define a queue management policy are the following:

  1. unique policy ID
  2. RED slope shapes for the buffer-pool: start-average, max-average, max-drop-probability settings for the high-priority and low priority RED slope
  3. TAF factor for the queue

The queue management policy ID default is reserved for the default queue management policy. The default policy cannot be deleted or changed. The default policy is implicitly applied to all queues that do not have another queue management policy explicitly assigned.

Table 26, Table 27, and Table 28 list the default values for the default slope policy.

Table 26:  Default Slope Policy Definition 

Parameter

Description

Setting

Policy ID

Queue management policy ID

Default (for default queue management policy)

CBS

Committed burst size

Default (in kilobytes)

MBS

Maximum burst size

Default (in kilobytes)

High (RED) slope

Administrative state

Shutdown

start-avg

70% utilization

max-avg

90% utilization

max-prob

75%

Low (RED) slope

Administrative state

Shutdown

start-avg

50% utilization

max-avg

75% utilization

max-prob

75%

TAF

time-average-factor

7

Table 27:  Default CBS Queues for 7210 SAS Platforms 

Platforms

CBS (in KB) Network Queue

CBS (in KB) Access Queue

7210 SAS-R6 and 7210 SAS-R12

128

10

Table 28:  Default MBS Queues for 7210 SAS Platforms in Network Mode 

Platforms

MBS (in KB) Network Queue

MBS (in KB) Access Queue

7210 SAS-R6 and 7210 SAS-R12

256

64

2.9. Configuration Guidelines for QoS Overrides

The configuration guidelines for the QoS override feature are the following.

  1. QoS override commands can be used only for the meters or policers.
  2. SAP-ingress queues are not supported on the 7210 SAS-R6 and 7210 SAS-R12.
  3. QoS override commands are not allowed when the attached policy is of the exclusive type.
  4. QoS override commands are not allowed on mirror destination SAPs.
  5. QoS override commands are not supported for network QoS and network queue QoS policies used with network IP interfaces and network ports.
  6. QoS override commands are not supported for SAP-egress queues configured in the SAP-egress QoS policies.

2.9.1. Configuring Meter Override Parameters

The following is a sample meter override parameter configuration output.

*7210SAS>config>service>epipe>sap>ingress# info 
----------------------------------------------
                    qos 13 
                    meter-override
                        meter 1 create
                            mode trtcm2 
                            adaptation-rule pir max cir max
                            cbs 300
                            mbs 200 
                            rate cir 300 pir 400
                        exit
                    exit
----------------------------------------------
*A:7210SAS>config>service>epipe>sap>ingress#

2.9.2. Configuring Queue Override Parameters

The following is a sample queue override parameter configuration output.

A:7210SAS>config>service>vpls>sap>ingress# info 
----------------------------------------------
                    qos 10 
                    queue-override
                        queue 1 create
                            adaptation-rule pir min cir max
                            port-parent pir-weight 3 cir-level 5
                            rate pir 1000 cir 100
                            queue-mgmt "10"
                        exit
                    exit
----------------------------------------------
*A:7210SAS>config>service>vpls>sap>ingress#

2.9.3. Configuring Access Egress QoS Policy Queue Overrides on the 7210 SAS-R6 and 7210 SAS-R12

The queue override feature for access egress QoS policies allows users to override the queue parameter settings of an access egress QoS policy that is applied to a port. An access egress QoS policy defines the QoS behavior on access port egress. Queue override is used when port-based queues with shaping and scheduling are configured instead of per-SAP egress queues. Queue override is supported on the 7210 SAS-R6 and 7210 SAS-R12.

Queue override support on access egress ports allows the user to override queue parameters, such as adaptation rule, percent CIR and PIR rates, queue-management policy, queue mode, CIR and PIR rates, and queue weight. See Queue Parameters for parameter descriptions.

When the queue override feature is not used, queue parameters for the port are taken from the access egress QoS policy assigned to the port.

Queue override commands are supported on all Ethernet access ports.

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for CLI command descriptions of the queue override parameters.

The following is a sample queue override parameter configuration output.

*7210SAS>config>port>ethernet>access>egress# info 
----------------------------------------------
               qos 13 
               queue-override 
                   queue 4
                       adaptation-rule cir closest pir closest
                       queue-mgmt default 
                       queue-mode weighted
                       rate cir 300 pir 400
                       weight 5
                   exit
               exit
----------------------------------------------
*A:7210SAS>config>service>epipe>sap>ingress#

2.10. Schedulers on 7210 SAS-R6 and 7210 SAS-R12

The 7210 SAS-R6 and 7210 SAS-R12 support scheduling as follows.

  1. When SAP-based scheduling mode is enabled, the following support is available:
    1. per-SAP egress scheduler for access port and hybrid port
    2. per-port egress scheduler for network and hybrid port
  2. When port-based scheduling mode is enabled, the following support is available:
    1. per-port egress scheduler for access port
    2. per-port egress scheduler for network and hybrid port

See Schedulers for more information about scheduling behavior and queue parameters considered by the scheduler.

2.11. Configuration Notes

The following information describes QoS implementation guidelines and restrictions.

  1. Creating additional QoS policies is optional.
  2. Default policies are created for service ingress, service egress, network-ingress, network-egress, queue-management, and multipoint bandwidth management.
  3. Associating a service or ports with a QoS policy other than the default policy is optional.