QoS policies

When configured to operate in access-uplink mode, 7210 SAS-T QoS policies are applied on service ingress, access port egress, and access-uplink port ingress and egress. These policies allow users to configure the following:

• classification rules for how traffic is mapped to FCs

• FC association with meters and meter parameters used for policing (rate limiting)

• queuing parameters for shaping and buffer allocation

• QoS marking and interpretation

Several types of QoS policies exist:

• service ingress policies for access SAP ingress

  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. FCs are associated with a meter or policer 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 (such as CIR, PIR, and so on). Each of the FCs can be associated with different unicast parameters.

  A service ingress QoS policy also defines up to three (3) meters per FC to be used for multipoint traffic for multipoint services. There can be up to 32 meters in total per service ingress QoS policy. In the case of the VPLS, four forwarding types (which is not to be confused with forwarding classes) are supported: unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown 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.

• access egress policies for access port egress

  An access egress policy is analogous to a SAP-egress policy, as defined in the 7x50 SR series of products. The difference is the point of attachment. An access egress policy is applied on the physical port as opposed to the logical port (SAP) for SAP-egress policy. It applies to all the SAPs on the port. An access egress QoS policy maps the traffic egressing the customer facing ports into various queues and marks the traffic accordingly. The FCs are mapped to the queues. There are 8 (eight) queues at the port level. FC-to-queue mapping is not configurable. The number of queues is not user-configurable and software always allocates 8 (eight) queues at the port level. An access egress policy also defines how to remark the FC-to-packet header bits (for example, IEEE 802.1p bits in the Layer 2 VLAN header, and so on).

• network policies for access-uplink port, ingress and egress

  Network queue policies are applied on egress of access-uplink ports when operating in access-uplink mode. The policies define the FC queue characteristics for these entities. The FCs are mapped to the queues. There are 8 (eight) queues at the port level. FC-to-queue mapping is system-defined and not user-configurable. The number of queues is not user-configurable and software always allocates 8 (eight) queues at the port level.

  For devices configured to operate in access-uplink mode, network QoS policies apply to access-uplink ports. Access-uplink ports in access-uplink mode are analogous to network ports in network mode. On ingress, the policy applied to an access-uplink port maps incoming dot1p values to FC and profile state for the traffic received from the core network. On egress, the policy maps FC and profile state to packet header values (for example, IEEE 802.1p value in the Layer 2 header) for traffic to be transmitted into the core network.

• slope policies

  Slope policies are applied to the egress queues on the access, network, and hybrid ports. These policies define the WRED congestion management attributes, such as drop probability and thresholds for high-profile and low-profile traffic.

• network-queue policies for access-uplink port, egress

• port-scheduler policies for access port and access-uplink port egress

Service ingress, 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 QoS policy can be applied to a specific SAP. An access egress policy can be applied to an access port. One access egress QoS policy can be applied to the access port. One network QoS policy can be applied to an access-uplink port when operating in access-uplink mode. A network QoS policy defines both ingress and egress behavior. One network queue policy can be applied to an access-uplink port. If no QoS policy is explicitly applied to a SAP, port, or interface, a default QoS policy is applied.

The following table describes the major functions performed by the QoS policies.

QoS policies are applied on service ingress, access port egress, network port ingress and egress, and on network IP interface ingress when configured to operate in network mode.

These policies allow user to configure the following:

• classification rules to map traffic to FCs

• FC association with meters and meter parameters used for policing (rate-limiting)

• queuing parameters for shaping

• QoS marking and interpretation

Several types of QoS policies exist:

• service ingress policies for access SAP ingress

  Service ingress QoS policies are applied to customer-facing SAPs. Traffic that enters through the SAP is classified to map it to an FC. FCs are associated with meters or policers 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 in the policy as to the number of FC meters for unicast traffic and the meter characteristics (such as CIR, PIR, and so on). Each of the FCs can be associated with different unicast parameters. A service ingress QoS policy also defines up to three (3) meters per FC to be used for multipoint traffic for multipoint services. There can be up to 32 meters in total per service ingress QoS policy. In the case of VPLS, four forwarding types (which are not to be confused with FCs) are supported: unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown 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.

• access egress policies for access port egress

  An access egress policy is analogous to a SAP-egress policy, as defined in the 7x50 SR series of products. The difference is the point of attachment. An access egress policy is applied on the physical port as opposed to the logical port (SAP) for SAP egress policies. It applies to all the SAPs on the port. An access egress QoS policy maps the traffic egressing on the customer-facing ports into various queues and marks the traffic. The FCs are mapped to the queues. There are 8 (eight) queues at the port level. FC-to-queue mapping is static and not configurable. The number of queues is not user-configurable and the software allocates 8 (eight) queues at the port level. An access egress policy also defines how to remark the FC-to-packet header bits (for example, IEEE 802.1p bits in the Layer 2 VLAN header).

• network policies for network and hybrid port, ingress and egress

  For devices configured to operate in network mode, there are two types of network QoS policies, one applied to a network IP interface and the other is applied to a network port. Network QoS policies are applied to IP interfaces. On ingress, the policy applied to an IP interface maps incoming MPLS LSP EXP values to FC and profile state for the traffic received from the core network. On egress, the policy maps FC and profile state to MPLS LSP EXP values for traffic to be transmitted into the core network. The network policy applied to a network port maps incoming IP packets, DSCP or dot1p values, to the FC and the profile state for the traffic received from the core network. On egress, the policy maps FC and profile state to DSCP and/or dot1p values for IP traffic to be transmitted into the core network.

• network-queue policies for network and hybrid port egress

  Network queue policies are applied on egress to network ports when operating in network mode. The policies define the FC queue characteristics for these entities. The FCs are mapped to the queues. There are 8 (eight) queues at the port level. FC-to-queue mapping is static and not configurable. The number of queues is not user-configurable and the software allocates 8 (eight) queues at the port level.

• port-scheduler policies for access port, network port and hybrid port egress

  Port scheduler policies are applied on egress for access, network, and hybrid ports. These policies allow the user to define queue scheduling attributes, such as strict-priority queuing and weighted queuing.

• slope policies

  Slope policies are applied to the egress queues on the access, network, and hybrid ports. These policies define the WRED congestion management attributes, such as drop probability and thresholds for high-profile and low-profile traffic.

• remark policies for access port, network port, and hybrid port egress marking

  Remark policies are applied to access ports/SAPs, network ports/IP interfaces, and hybrid ports/SAPs/IP interfaces to configure the marking values for different forwarding classes and profiles.These policies enable marking of packet header QoS fields for packets that are forwarded out of the port, SAP, or IP interface. See Remark policies for more information.

Service ingress, 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) whereas exclusive policies can only be applied to a single entity.

One service ingress QoS policy can be applied to a specific SAP access egress policy. One access egress QoS policy can be applied to the 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, when operating in network mode. One network QoS policy can be applied to an access-uplink port when operating in access-uplink mode. A network QoS policy defines both ingress and egress behavior. One network queue policy can be applied to the network port or a access-uplink port.

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

The following table describes the major functions performed by QoS policies.

QoS policies are applied on service ingress, access port egress, network port ingress and egress, and network IP interfaces ingress when configured to operate in network mode.

These policies allow users to configure the following:

• classification rules for how traffic is mapped to FCs

• FC association with meters and meter parameters used for policing (rate-limiting)

• queuing parameters for shaping

• QoS marking/interpretation

Several types of QoS policies exist:

• service ingress policies for access SAP ingress

  Service ingress QoS policies are applied to customer-facing SAPs. Traffic that enters through the SAP is classified to map to an FC. FCs are associated with meters or policers on ingress. Mapping traffic meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP criteria, and MAC criteria. The policy defines the number of FC meters for unicast traffic and other meter characteristics (such as 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 for multipoint traffic for use with multipoint services. The system supports the configuration of up to 32 meters per service ingress QoS policy. In the case of VPLS, four forwarding types (not to be confused with forward classes) are supported: unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown types are flooded to all destinations within the service, while the unicast forwarding type is handled in a point-to-point fashion within the service.

• service egress policies for access SAP egress

  Service egress QoS policies are applied to SAPs and map FCs to service egress queues for a service. The system allocates a maximum of eight queues per SAP for the eight FCs; this is not user configurable. All traffic types (unicast and BUM) share the same service egress queue. A service egress QoS policy defines the FC queue characteristics and how the FC to priority bits in the packet header are remarked (for example, IEEE 802.1p bits in the Ethernet VLAN tag) in the customer traffic.

  On the 7210 SAS-Mxp, the user has a per-node or per-chassis option of configuring the SAP-based or access port-based egress queuing mode. The SAP-based egress queuing mode (port-scheduler-mode command disabled) uses a service egress QoS policy with the capability to use eight egress queues per SAP. The access port-based egress queuing mode (port-scheduler-mode command enabled) uses an access egress policy with the capability to use eight egress queues for all SAPs configured on the access port.

  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.

• access egress policies for access port egress

  An access egress policy is applied to all SAPs on the physical port (and not the logical port (SAP)) for SAP-egress policies. It applies to all the SAPs on the port. Access egress policies provide different capabilities based on the egress queuing mode applied to the node. In SAP-based egress queuing mode, an access egress policy defines the remarking of the FC-to-packet header bits. For example, IEEE 802.1p bits in the Layer 2 VLAN header.

  In port-based egress queuing mode, the access egress policy, in addition to remarking, is used to define the queuing and scheduling behavior for the port-based egress queues. Access egress QoS policies are applied to ports and map forwarding classes (FCs) to port egress queues. The system allocates a maximum of eight queues per port for the eight FCs. The allocation is not user-configurable. All traffic types, (unicast and BUM traffic types) share the same queue on port egress.

  An access egress QoS policy defines the FC queue characteristics and the remarking of the FC to priority bits in the packet header (for example, IEEE 802.1p bits in the Ethernet VLAN tag) in the customer traffic.

• access ingress policies for access port ingress

  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 an FC and profile to traffic, which facilitates the classification of traffic received on the access port.

  An option is provided to share an access ingress policy across multiple access ports so that the classification policy and the policer rate applies to all access SAPs configured across all access ports that share the policy. In shared mode, the access ingress policy provides an option to use dot1p, DEI, IP DSCP, and IP criteria (with or without a port range) classification entries to assign an FC and profile to traffic received on the access port.

  The FC assigned using the classification entry is associated with meters at ingress and allows the user to define up to one meter per FC for unicast traffic, and up to one meter per FC for multipoint traffic (broadcast, multicast, and unknown-unicast) for multipoint services. The system supports up to 16 meters per access ingress QoS policy.

  Note:

  This policy is available only when the node is operating in sap-scale mode high. See the 7210 SAS-Mxp, S, Sx, T Services Guide and 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about the sap-scale-mode command.

• network policies for network and hybrid port, ingress and egress

  For devices configured to operate in network mode, two types of network QoS policies are supported: one that is applied to a network IP interface and the other to a network port. Network QoS policies are applied to IP interfaces. On ingress, the policy applied to an IP interface maps incoming MPLS LSP EXP values to FC and profile state for traffic received from the core network. On egress, the network policy maps FC and profile state to MPLS LSP EXP values for traffic transmitted into the core network. The network policy applied to a network port maps incoming IP packets, DSCP, or dot1p values to the FC and the profile state for the traffic received from the core network. On egress, the network policy maps FC and profile state to DSCP or dot1p values for IP traffic transmitted into the core network.

• network queue policies for network and hybrid port, egress

  Network queue policies are applied on egress to network ports when operating in network mode. The policies define the FC queue characteristics for these entities. The FCs are mapped to the queues. The FC-to-queue mapping is static and not configurable. The number of queues is not user-configurable and the software allocates eight queues at the port level.

• port scheduler policies for access port, network port and hybrid port egress

  Port scheduler policies are applied on egress for access, network, and hybrid ports. These policies allow the user to define queue scheduling attributes, such as strict-priority queuing and weighted queuing.

• slope policies

  Slope policies are applied to the egress queues on the access, network, and hybrid ports. These policies define the WRED congestion management attributes, such as drop probability and thresholds for high-profile and low-profile traffic.

• remark policies for access port, network port and hybrid port egress marking

  Remark policies are applied to access ports/SAPs, network ports/IP interfaces, and hybrid ports/SAPs/IP interfaces to configure the marking values for different forwarding classes and profiles.These policies enable marking of packet header QoS fields for packets that are forwarded out of the port, SAP, or IP interface. See Remark policies for more information.

• queue management policies for buffer allocation and slope configuration on service egress and network port egress

  Queue management policies are applied to service egress, access port egress, network port egress, and hybrid port egress to configure CBS and MBS parameters for the egress queues and the WRED slope parameters for the queues.

The 7210 SAS-Mxp provides an option to use port-based queuing on access ports. This is a per-node configuration option and is mutually exclusive to the use of SAP-based egress queues (configured through service egress policies). When enabled, all SAPs on the access port share a set of 8 (eight) queues configured on the port and the access egress policy is used to define the queue parameters for port-based queues.

Service ingress, service egress, access ingress, 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.

The following policies are supported:

• one service ingress QoS policy and one service egress QoS policy applied to a specific SAP

• one access ingress and one access egress QoS policy applied to an access port

• one network QoS policy 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 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-Mxp 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 is significantly higher compared to the low SAP scale mode and use table-based classification with ingress service meters. The use of network port policies remains unchanged when the system is operating in the high SAP scale mode.

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:

• service ingress policy for SAP ingress classification and metering using the following:

  • CAM-based classification and metering/policing

  • table-based classification and CAM-based metering/policing

  • table-based classification and service-meter pool, also called table-based meter/policer pool, for metering/policing

• service egress policy for SAP egress queuing, shaping, and scheduling with an egress policy for marking only

• access egress policy for access port egress queuing, shaping, scheduling, and marking (this policy is mutually exclusive with the use of service egress policies)

A summary of the major functions performed by the QoS policies is listed in the following table.

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:

• classification rules to map traffic to FCs

• FC association with meters and meter parameters used for policing (rate-limiting)

• queuing parameters for shaping, scheduling, and buffer allocation

• QoS marking and interpretation

The 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c support the following types of QoS policies:

• service ingress policies for access SAP ingress

  Service ingress QoS policies are applied to customer-facing SAPs. Traffic that enters through the SAP is classified to map to an FC. FCs are associated with meters or policers on ingress. Mapping traffic meters can be based on combinations of customer QoS marking (IEEE 802.1p bits), IP criteria, and MAC criteria. The policy defines the number of FC meters for unicast traffic and other meter characteristics (such as 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 for multipoint traffic for use with multipoint services. The system supports the configuration of up to 32 meters per service ingress QoS policy. In the case of VPLS, four forwarding types (not to be confused with forward classes) are supported: unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown types are flooded to all destinations within the service, while the unicast forwarding type is handled in a point-to-point fashion within the service.

  Service ingress QoS policies are supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c.

• service egress policies for access SAP egress

  Service egress QoS policies are applied to SAPs and map FCs to service egress queues for a service. The system allocates a maximum of eight queues per SAP for the eight FCs; this is not user configurable. All traffic types (unicast and BUM) share the same service egress queue. A service egress QoS policy defines the FC queue characteristics and how the FC to priority bits in the packet header are remarked (for example, IEEE 802.1p bits in the Ethernet VLAN tag) in the customer traffic.

  On the 7210 SAS-R6 and 7210 SAS-R12, the user has a per-node or per-chassis option of configuring the SAP-based or access port-based egress queuing mode. The SAP-based egress queuing mode (port-scheduler-mode command disabled) uses a service egress QoS policy with the capability to use eight egress queues per SAP. The access port-based egress queuing mode (port-scheduler-mode command enabled) uses an access egress policy with the capability to use eight egress queues for all SAPs configured on the access port.

  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 policies are supported only on 7210 SAS-R6 IMM-b and 7210 SAS-R12 IMM-b. 7210 SAS-R6 IMM-c and 7210 SAS-R12 IMM-c support only the port-based egress queuing mode and use access egress policies to configure the access port egress queues.

• access egress policies for access port egress

  An access egress policy is applied to all SAPs on the physical port (and not the logical port (SAP)) for SAP-egress policies. It applies to all the SAPs on the port. Access egress policies provide different capabilities based on the egress queuing mode applied to the node. In SAP-based egress queuing mode, an access egress policy defines the remarking of the FC-to-packet header bits. For example, IEEE 802.1p bits in the Layer 2 VLAN header.

  In port-based egress queuing mode, the access egress policy, in addition to remarking, is used to define the queuing and scheduling behavior for the port-based egress queues. Access egress QoS policies are applied to ports and map forwarding classes (FCs) to port egress queues. The system allocates a maximum of eight queues per port for the eight FCs. The allocation is not user-configurable. All traffic types, (unicast and BUM traffic types) share the same queue on port egress.

  An access egress QoS policy defines the FC queue characteristics and the remarking of the FC to priority bits in the packet header (for example, IEEE 802.1p bits in the Ethernet VLAN tag) in the customer traffic.

  Access egress policies are supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c. On IMM-b cards, when SAP-based egress queuing is configured, an access egress policy is used to configure marking. When port-based egress queuing is configured, an access egress policy is used to define port egress queue shaping and scheduling parameters, and configure marking.

• access ingress policies for access port ingress

  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 an FC 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 FC for unicast traffic, and up to one meter per FC for multipoint traffic (broadcast, multicast, and unknown-unicast) for multipoint services. The system supports up to 16 meters per access ingress QoS policy.

  This policy is supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c.

  Note:

  Access ingress policies are available only when the node is operating in sap-scale mode high. See the 7210 SAS-Mxp, S, Sx, T Services Guide and 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about this command.

• network policies for network port and hybrid port ingress and egress, and network IP interface ingress

  For devices configured to operate in network mode, two types of network QoS policies are supported: one that is applied to a network IP interface and the other to a network port. On ingress, the policy applied to an IP interface maps incoming MPLS LSP EXP values to FC and profile state for traffic received from the core network. On egress, the network policy maps FC and profile state to MPLS LSP EXP values for traffic transmitted into the core network. The network policy applied to a network port maps incoming IP packets, DSCP, or dot1p values to the FC and the profile state for the traffic received from the core network. On egress, the network policy maps FC and profile state to DSCP or dot1p values for IP traffic transmitted into the core network.

  These network policies are supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c.

• network queue policies for network port and hybrid port, egress

  Network queue policies are applied on egress to network ports when operating in network mode. The policies define the FC queue characteristics for these entities. The FCs are mapped to the queues. The FC-to-queue mapping is static and not configurable. The number of queues is not user-configurable and the software allocates eight queues at the port level.

  These network queue policies are supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c.

• remark policies for service egress, access port egress, network port and hybrid port egress, and network IP interface egress marking

  Remark policies are applied to access ports/SAPs, network ports/IP interfaces, and hybrid ports/SAPs/IP interfaces to configure the marking values for different forwarding classes and profiles.These policies enable marking of packet header QoS fields for packets that are forwarded out of the port, SAP, or IP interface. See Remark policies for more information.

• queue management policies for buffer allocation and slope configuration on service egress and network port egress

  Queue management policies are applied to service egress, access port egress, network port egress, and hybrid port egress to configure CBS and MBS parameters for the egress queues and the WRED slope parameters for the queues.

  This policy is supported on the 7210 SAS-R6 IMM-b, 7210 SAS-R12 IMM-b, 7210 SAS-R6 IMM-c, and 7210 SAS-R12 IMM-c. On the 7210 SAS-R6 IMM-c and 7210 SAS-R12 IMM-c, the CBS and MBS parameters are system-defined and not user-configurable. The values configured in the queue management policy for CBS and MBS parameters are ignored and only the WRED slope parameters are used.

Service ingress, access 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:

• service ingress policy for SAP ingress classification and metering using the following:

  • CAM-based classification and metering

  • table-based classification and CAM-based metering

• service egress policy for SAP egress queuing, shaping, and scheduling with an egress policy for marking only

• 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:

• 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

• access egress policy for port egress queuing, shaping, scheduling, and marking (this policy is mutually exclusive with the use of service egress policies)

The following table describes the major functions performed by QoS policies for 7210 SAS-R6 and 7210 SAS-R12.

QoS policies are applied on service ingress, access port egress, network port ingress and egress, and network IP interfaces ingress when configured 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE operates with MPLS uplinks.

These policies allow users to configure the following:

• classification rules for how traffic is mapped to FCs

• FC association with meters and meter parameters used for policing (rate-limiting)

• queuing parameters for shaping

• QoS marking/interpretation

There are several types of QoS policies:

• service ingress policies for access SAP ingress

  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. FCs are associated with meters/policers 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.

• access egress policies for access port egress

  Access egress policies are analogous to SAP egress policies as defined in the 7750 SR series of products. The difference is the point of attachment. An access egress policy is applied on the physical port as opposed to the logical port (SAP) for SAP egress policy. It applies to all SAPs on a port. An access egress QoS policy maps the traffic egressing on customer facing ports into various queues and marks the traffic accordingly.

• access ingress policies for access port ingress

  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 an FC 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 FC for unicast traffic, and up to one meter per FC 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.

  Note:

  This policy is available only when the node is operating in sap-scale mode high. See the 7210 SAS-Mxp, S, Sx, T Services Guide and 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about the sap-scale-mode command.

• network policies for network and hybrid port, ingress and egress

  The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE support two types of network QoS policies, one applied to a network IP interface and the other to a network port or a hybrid port. Network QoS policies are applied to IP interfaces. On ingress, the policy applied to an IP interface maps incoming MPLS LSP EXP values to FC and profile state for the traffic received from the core network. On egress, the policy maps FC and profile state to MPLS LSP EXP values for traffic to be transmitted into the core network. The network policy applied to a network port maps incoming IP packets, DSCP, or dot1p values, to the FC and the profile state for the traffic received from the core network. On egress, the policy maps FC and profile state to DSCP or dot1p values for IP traffic to be transmitted into the core network.

• network queue policies for network and hybrid port, egress

  Network queue policies are applied on egress to network or hybrid ports when operating in network mode. The policies define the FC queue characteristics for these entities. The FCs are mapped to the queues. There are 16 queues at the port level. FC-to-queue mapping is static and not configurable. The number of queues is not user-configurable, and the software allocates 16 queues at the port level.

• port scheduler policies for access port, network port, and hybrid port egress

  Port scheduler policies are applied on egress for access, network, and hybrid ports. These policies allow the user to define queue scheduling attributes, such as strict-priority queuing and weighted queuing.

• slope policies

  Slope policies are applied to the egress queues on the access, network, and hybrid ports. These policies define the WRED congestion management attributes, such as drop probability and thresholds for high-profile and low-profile traffic.

• remark policies for access port, network port, and hybrid port egress marking

  Remark policies are applied to access ports/SAPs, network ports/IP interfaces, and hybrid ports/SAPs/IP interfaces to configure the marking values for different forwarding classes and profiles.These policies enable marking of packet header QoS fields for packets that are forwarded out of the port, SAP, or IP interface. See Remark policies for more information.

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

In the case of the VPLS, the following types of forwarding are supported (which is not to be confused with FCs): unicast, multicast, broadcast, and unknown. Multicast, broadcast, and unknown types are flooded to all destinations within the service, while the unicast forwarding type is handled point-to-point in the service.

The FCs are mapped to 16 queues at the port level (8 for unicast and 8 for multicast). FC-to-queue mapping is static and not configurable. The number of queues is not user configurable and the software allocates 16 queues at the port level. An access egress policy also defines the remarking of the FC-to-packet header bits (for example, IEEE 802.1p bits in the Layer 2 VLAN header, and others.).

The following applies to the use of QoS policies on hybrid ports:

• 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 ports.

• Network QoS policies of type ‟ip-interface” are supported for network IP interfaces on hybrid ports. The behavior is similar to the existing behavior for network IP interfaces on network ports. It supports per IP interface ingress classification and policing and egress marking (only EXP marking for MPLS traffic).

• Network QoS (type = port) policies are supported for hybrid ports. The behavior is similar to existing behavior for network ports. It supports per port ingress classification and policing and egress marking (dot1p and/or DSCP marking) for IP control packets.

• SAP ingress QoS policies are supported for SAPs configured on hybrid ports. The behavior is similar to existing behavior for access SAP ingress. It supports per SAP ingress classification and policing.

• For marking traffic sent out of SAPs and IP traffic sent out of IP interfaces configured on hybrid ports, users must use the network QoS policy of type ‟port”, with an option to mark dot1p, DSCP, or both.

  Note:

  If DSCP remarking or both is specified, the DSCP field is not marked for the traffic sent out of the Layer 2 SAPs.

Service ingress, 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 be applied to only a single entity. One service ingress QoS policy can be applied to a specific SAP.

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.

An access egress policy can be applied to an access port. One access egress QoS policy can be applied to the access port. One network QoS policy can be applied to a specific IP interface, network port, or hybrid 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 or hybrid port. If no QoS policy is applied to a SAP, port, or interface, a default QoS policy is applied.

The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE 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:

• service ingress policy for SAP ingress classification and metering using the following:

  • CAM-based classification and metering

  • table-based classification and CAM-based metering

• service egress policy for SAP egress queuing, shaping, and scheduling with an egress policy for marking only

• 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:

• 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

• access egress policy for port egress queuing, shaping, scheduling, and marking (this policy is mutually exclusive with the use of service egress policies)

The following table describes the major functions performed by QoS policies.

The following applies to QoS policies configured in network mode.

• The following types of network QoS policies can be defined: ip-interface and port. By default, when a network QoS policy is created, it is of the ip-interface type.

• Create a network QoS policy of the ip-interface type using the configure>qos>network context.

• Create a network QoS policy of the port type using the configure>qos>network context.

• When a network QoS policy of the ip-interface type is applied to an IP interface configured on network port and hybrid ports, the policy 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 the IP interface.

• When a network QoS policy of the port type is applied to a network and hybrid port, it is used for classification of IP packets, based on the DSCP or dot1p bits and marking of DSCP or dot1p bits for packets sent out of network or hybrid ports.

• 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.

Network QoS policies define ingress FC meters and map traffic to the meters for access-uplink ports. A network QoS policy always has two meters/policers defined that cannot be deleted, one for the unicast traffic and one for multipoint traffic. These meters exist within the definition of the policy. The meters are instantiated in hardware only when the policy is applied to an access-uplink port. The policy also defines the FC-to-priority bit marking, on egress.

A network QoS policy defines both the ingress and egress handling of QoS on the access-uplink ports. The following functions are defined:

• Ingress

  • defines dot1p value mapping to FCs and profiles with an option to use the DEI bit along with dot1p classification (DSCP is not available for use)

  • defines FC to meter mapping

• Egress

  • option to define the FC to dot1p value and IP DSCP value for marking

  • remarking of QoS bits can be enabled or disabled

The following are the required elements defined in a network QoS policy:

• unique network QoS policy ID

• egress FC to dot1p value mappings for each FC

• default ingress FC and in-profile/out-of-profile state

• at least one default unicast FC meter. See Meter/policer parameters for information about the parameters that can be configured for a meter.

• at least one multipoint FC meter

Optional network QoS policy elements include the following:

• additional unicast meters up to a total of 8

• additional multipoint meters up to 8

• dot1p value to FC and profile state mappings for all dot1p values received

• option to use the DEI bit along with dot1p classification for profile state mapping

Network policy ID 1 is reserved as the default network QoS policy which cannot be deleted or changed. The default network QoS policy is applied to all access-uplink ports that do not have another network QoS policy assigned. The network QoS policy applied at network egress (for example, on an access-uplink port) 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 network QoS policy is always enabled. The following table lists the default mapping of FC-to-dot1p values.

For network ingress, the following table lists the default mapping of dot1p values to FC and profile state for the default network QoS policy. Color-aware policing is supported on ingress for access-uplink ports.

This section provides information about network queue QoS policies.

Service ingress QoS policies define ingress service FC meters and map flows to the meters. 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 are instantiated in hardware only 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:

• unique service ingress QoS policy ID

• QoS policy scope of template or exclusive

• number of classification and meter resources to allocate for this policy

• 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.

• at least one default FC meter

  See Meter/policer parameters for information about the parameters that can be configured for a meter.

Optional service ingress QoS policy elements include the following:

• additional unicast meters up to a total of 8 (eight)

• additional multipoint meters up to 32

• QoS policy match criteria to map packets to an FC

• option to use dot1p or IP DSCP table-based classification in Layer 2 services (Epipe and VPLS) on 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

• option to use IP DSCP table-based classification in Layer 3 services on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

• option to use meters from either CAM-based meter resource pool or table-based service-meter resource pool on 7210 SAS-Mxp

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

• CAM-based classification and policing

  Resources for both classification and policing are allocated from the CAM-based classification and meter resource pool. Configure resources from the CAM-based pool using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource command. The user has the flexibility to use IP criteria (both IPv4 and IPv6) and MAC criteria for classification of traffic flows to an FC (FC). Using this option allows each SAP to define its FC-to-meter map, which is the default option that is enabled when the system boots up using the default configuration. This option is supported on the following platforms: 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T (in network and access-uplink mode). This is available with all services (Epipe SAPs, VPLS SAPs, VPRN SAPs, IES SAPs, and R-VPLS SAPs).

• 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. Configure resources for the CAM-based pool using the configure>system>resource-profile>ingress-internal-tcam>qos-sap-ingress-resource command. See Service ingress QoS policies for examples that show how to configure this option. Using this option, the classification of traffic flows can be done only using IP DSCP and or dot1p bits. (See Service ingress QoS policies for information about classification support details.) The use of IP and MAC criteria are mutually exclusive. Using this option allows each SAP to define its FC-to-meter map. This option is supported only on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12. This is available with all services (Epipe SAPs, VPLS SAPs, VPRN SAPs, IES SAPs, and R-VPLS SAPs).

• table-based classification and service-meter based policing

  Resources for classification are allocated from the table-based classification pool of resources, and policing resources are allocated from the table-based service-meter resource pool. See Service ingress QoS policies for examples that show how to configure this option. With this option, the classification of traffic flows can be done only using IP DSCP or dot1p bits (for classification support details, see Service ingress QoS policies). The use of IP and MAC criteria is not available. All SAPs in the node must use a single FC-to-meter map (other than the default). This option is only supported on the 7210 SAS-Mxp and is only available for Epipe SAPs, VPLS SAPs, VPRN SAPs, and IES SAPs. It is not available for R-VPLS SAPs.

Each meter can have unique meter parameters to allow individual policing of the flow mapped to the FC. The following figure shows service traffic being classified into three different FCs.

Mapping a flow to an FC 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.

Service egress queues are implemented at the transition from the service core network to the service access network and are available when SAP-based egress queues and shaping is enabled by using the configure system resource-profile qos no port-scheduler-mode command on the 7210 SAS-Mxp and the configure system global-resource-profile qos no port-scheduler-mode command on the 7210 SAS-R6 IMM-b and 7210 SAS-R12 IMM-b. The advantages of per-service queuing before transmission into the access network are:

• per-service egress subrate capabilities especially for multipoint services

• more granular, fairer scheduling per-service into the access network

• per-service statistics for forwarded and discarded service packets

The sub-rate capabilities and per-service scheduling control are required to make multiple services per physical port possible. Without egress shaping, it is not possible to support more than one service per port with QoS differentiation among services. 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.

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

• a unique service egress QoS policy ID

• a QoS policy scope of template or exclusive

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

The 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 SAP if marking is enabled. See the Service egress policies on 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 and the Remark policies for more information about marking behavior and the available options. 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 for all the SAPs defined on the port. See Access egress QoS policies on 7210 SAS-Mxp for more information.

Each queue in a policy is associated with one of the FCs. Each queue can have individual queue parameters allowing individual rate shaping of the FCs mapped to the queue. The FC per service egress packet is determined at ingress. If the packet ingressed the service on the same node, the service ingress classification rules determine the FC of the packet. If the packet is received, the FC is marked in the tunnel transport encapsulation.

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

Service egress QoS policy ID 1 is reserved as the default service for those that do not have another service egress policy explicitly assigned. The following table lists the characteristics of the default policy.

An access egress policy defines the access port queues, the FC- to-queue mapping, and the marking characteristics for the traffic egressing toward the customer on the access ports. By configuring queue shaping rates, the individual FC traffic can be managed so that each FC traffic is within SLA limits and does not impact the serviceability of other FCs.

The number of queues available per access port on different 7210 SAS platforms is the following:

• On the 7210 SAS-T, there are 8 (eight) queues always available per access port, and all FC traffic is mapped into these separate 8 (eight) queue as per the FC-to-queue-ID map. See Forwarding class to queue-ID map for more information.

• On the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, 16 queues are available per access port, with 8 (eight) queues allocated for unicast traffic and 8 (eight) allocated for multicast traffic. For each of the 8 (eight) FCs, unicast and multicast traffic are mapped to two different queues, for a total of 16 queues across 8 (eight) FCs. See Forwarding class-to-queue ID map for 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE for more information.

To define a basic access egress QoS policy, the following are required:

• unique service access QoS policy ID

• QoS policy scope of template or exclusive

• see Queue parameters for information about the parameters configured for a queue

• on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, access egress policy allows users to specify a single rate for both multicast and unicast queues, meaning that rates cannot be specified individually for the unicast and multicast queue of an FC. Instead, the rate specified for a queue (for example, queue 8) is distributed equally to the unicast queue and multicast queue associated with the FC. See Schedulers on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE for more information.

• remarking (for example, IEEE 802.1p value) based on FC

On the 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, remarking of dot1p or DSCP or both bits by default is disabled and can be enabled by the remarking command, with options to remark dot1p, dscp, or both present under access-egress context.

The following options are available on different platforms:

• In 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, network mode, the user is provided with an option to remark dot1p or DSCP or both.

• In 7210 SAS-T access-uplink mode, the user is provided with an option to remark both dot1p bits and IP DSCP bits.

The FC determination per service egress packet is determined at ingress. If the packet ingressed the service on the same router, the service ingress classification rules determine the FC of the packet.

The FC is determined as follows for network mode and access-uplink mode:

• In network mode, if the packet is received over a service transport tunnel on a network port, the FC is typically determined by the MPLS LSP EXP bits.

• For 7210 SAS-T in access-uplink mode, if the packet was received on a access-uplink port, the FC is determined by the dot1p bits in the outer tag of the QinQ encapsulation.

Access egress QoS policy ID 1 is reserved as the default for access ports that do not have another access egress policy explicitly assigned. The following table lists the characteristics of the default policy.

On 7210 SAS-Mxp, the 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. Use the configure system resource-profile qos port-scheduler-mode command to select the mode for SAPs configured on all the ports of the node.

On the 7210 SAS-Mxp platforms, an access egress policy provides different functionality based on the queuing mode in use, as described in the following sections.

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 toward 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.

The queue override feature for access egress QoS policies allows users to override the queue parameter settings of an access egress QoS policy 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 for use instead of per-SAP egress queues.

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.

The 7210 SAS supports port egress rate limiting, which 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.

There are 8 (eight) FCs supported on 7210 SAS devices. Each FC is mapped to a specific queue. By mapping FCs to different queues the differential treatment is imparted to various classes of traffic.

On the 7210 SAS devices, there are only 8 (eight) queues available at the port level for all ports. These 8 (eight) queues are created by default per port. Users cannot create or delete the queues nor the queue ID. Only the queue parameters can be changed. The queue ID is not configurable, and queue IDs 1 to 8 are, by default, used to identify the 8 (eight) queues available on the port. Queue parameters for the 8 (eight) queues can be configured using the different QoS policies based on the capabilities available on different 7210 SAS platforms. See QoS policies for more information.

The queue IDs 1 to 8 are assigned to each of the 8 (eight) queues. Queue-ID 8 is the highest priority and queue-id 1is the lowest priority. FCs are correspondingly mapped to these queue IDs according to their priority. The following table describes the system-defined map.

There are 8 FCs supported on the device. Each of these FC is mapped to two queues, one used for unicast traffic mapped to the FC and another used for multicast/BUM traffic mapped to the FC. By mapping an FC to different queues, the differential treatment is imparted to various classes of traffic.

In the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE devices, there are 16 queues available at the port level for all ports on the device. These 16 queues are created by default per port. Users cannot create or delete the queues or the queue ID. Only the queue parameters can be changed. On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, the queue ID represents one of the 8 scheduling nodes corresponding to 8 FCs. It is not a configurable entity and queue ID 1 to 8 are, by default, used to identify these 8 FC scheduling nodes available on the port. Parameters for these 8 FCs can be configured as part of the access egress QoS policy that is applied on the access ports, and network queue policy that is applied on the network ports and hybrid ports.

The queue IDs 1 to 8 are assigned to each of the 8 FCs. Queue ID 8 is the highest priority scheduling node and queue ID 1 is the lowest priority scheduling node. FCs are correspondingly mapped to these queue IDs according to their priority. The following table describes the system-defined map.

This section provides an overview of QoS policy support on hybrid ports:

• 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 ports.

• Network QoS (type = ip-interface) 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. It supports per IP interface ingress classification and policing, and egress marking (only EXP marking for MPLS traffic).

• Network QoS (type = port) policies are supported for hybrid ports. The behavior is similar to existing behavior for network ports. It supports per port ingress classification and policing, and egress marking (dot1p and/or DSCP marking) for IP control packets.

• SAP ingress QoS policies are supported for SAPs configured on hybrid ports. The behavior is similar to existing behavior for access SAP ingress. It supports per SAP ingress classification and policing.

• For marking traffic sent out of SAPs and IP traffic sent out of IP interfaces configured on hybrid ports, the user must use the network QoS policy of the port type, with an option to mark dot1p, DSCP, or both.

  Note:

  See Remark policies for more information about dot1p and IP DSCP marking.

This section provides an overview of QoS policy support on hybrid ports:

• Network queue policies are supported for queue configuration of egress queues on hybrid ports. The egress queues are shared by traffic sent out of SAPs and network IP interfaces configured on hybrid ports.

• Network QoS (type = ip-interface) 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. It supports per IP interface ingress classification and policing, and egress marking (only EXP marking for MPLS traffic).

• Network QoS (type = port) policies are supported for hybrid ports. The behavior is similar to existing behavior for network ports. It supports per port ingress classification and policing, and egress marking (dot1p and/or DSCP marking) for IP control packets.

• SAP ingress QoS policies are supported for SAPs configured on hybrid ports. The behavior is similar to existing behavior for access SAP ingress. It supports per SAP ingress classification and policing.

• For marking traffic sent out of SAPs and IP traffic sent out of IP interfaces configured on hybrid ports, users must use the network QoS policy of the port type, with an option to mark dot1p, DSCP, or both.

  Note:

  See Remark policies for more information about dot1p and IP DSCP marking.

This section provides an overview of QoS policy support on hybrid ports.

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

• 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 port.

• Network QoS (type = ip-interface) 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. It supports per IP interface ingress classification and policing, and egress marking (only EXP marking for MPLS traffic).

• Network QoS (type = port) policies are supported for hybrid ports. The behavior is similar to existing behavior for network ports. It supports per port ingress classification and policing, and egress marking (dot1p or DSCP marking). For marking IP control traffic sent out of network IP interfaces configured on hybrid port, user needs to use the network QoS policy of the port type, with an option to mark dot1p, DSCP, or both.

• SAP ingress QoS policies are supported for SAPs configured on hybrid ports. The behavior is similar to the behavior for access SAP ingress, which supports per SAP ingress classification and policing.

• 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 ports. For traffic sent out of SAPs configured in Layer 2 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 Layer 3 services. One of the options can be used per port by configuring the network QoS port type policy.

  Note:

  See Remark policies for more information about dot1p and IP DSCP marking.

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

• Network queue policies are supported for queue configuration of egress queues on hybrid ports. The egress queues are shared by traffic sent out of SAPs and network IP interfaces configured on hybrid ports, which means that per SAP service egress policies are not available for use.

• For traffic sent out of SAPs (both for SAPs configured in Layer 2 services and in Layer 3 services) configured on 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.

This section describes the meter parameters available. Meters are available for use in both network mode and access-uplink mode with the following policies.

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

• SAP ingress policies

• network QoS policies of the port type, associated with network port ingress or hybrid port ingress

• network QoS policy of the ip-interface type, associated with network IP interfaces configured on the network port of hybrid ports

In access-uplink mode of operation meter/policer is available with the following:

• SAP ingress policies

• network QoS policy associated with access-uplink port ingress

This section describes the queue parameters available for queues. Queues are available for use in both network mode and access-uplink mode with the following policies.

In network mode of operation, queue is configured with the following QoS policies on 7210 SAS platforms:

• On 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T network mode:

  • network queue policies associated with network port or hybrid port egress

  • access egress policies associated with access port egress

• On 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12:

  • network queue policies associated with network port or hybrid port egress

  • SAP egress policies associated with SAP egress (when SAP-based egress queuing and scheduling is enabled for use)

  • access egress policies associated with access port egress (when port-based egress queuing and scheduling is enabled for use)

In access-uplink mode of operation, a queue is available with the following platforms:

• On the 7210 SAS-T access-uplink mode:

  • network queue policies associated with access-uplink port egress

  • access egress policies associated with access port egress

The available buffer space is partitioned into buffer pools. The buffers for a queue are allocated from the available buffer pool.

This section provides information about buffer pools for 7210 SAS platforms.

Queue management policies allows the user to define the queue buffer and WRED slope parameters. The device supports a single buffer pool per node. All the queues created in the system are allocated buffers from this 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 allow the user to define the CBS, MBS and WRED parameters for use by the queue. The CBS and MBS parameters are used to allocate the appropriate amount of buffers from the system pool to the queues. The WRED parameters allow the user to define the WRED slope characteristics.

You can define a high-slope and a low-slope for each of the queues. High-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 buffers based on whether the queue is associated with a SAP or network port.

On 7210 SAS platforms RED slopes support is as follows:

• On 7210 SAS-T (both network mode and access-uplink mode), each queue, supports a high-priority RED slope and a low-priority RED slope.

• On 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12, each queue supports a high-priority RED slope and a low-priority RED slope, which are configurable using the queue-management policies.

• On 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, each queue supports a high-priority RED slope and a low-priority RED 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, all slopes are disabled.

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

For the queues within a buffer pool, packets are either queued using committed burst size (CBS) buffers or shared buffers. The CBS buffers are simply buffer memory that has been allocated to the queue while the queue depth is at or below its CBS threshold.

When a queue depth exceeds the queue’s CBS, packets received on that queue must contend with other queues exceeding their CBS for shared buffers. To resolve this contention, the buffer pool uses two RED 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 RED slope. This slope should be configured with RED parameters that prioritize buffer availability over packets associated with the low-priority RED slope. Packets that had been classified as low priority or out-of-profile are handled by this low-priority RED slope.

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

1. The RED function keeps track of shared buffer utilization and shared buffer average utilization.

2. At initialization, the utilization is 0 (zero) and the average utilization is 0 (zero).

3. When each packet is received, the current average utilization is plotted on the slope to determine the packet’s discard probability.

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 are 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 used 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’s probability is plotted on the RED 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 buffers 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.

    A RED slope itself is a graph with an X (horizontal) and Y (vertical) axis. The X-axis plots the percentage of shared buffer average utilization, going from 0 to 100 %. 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 (as shown in the following figure):

    

1. Section A is (0, 0) to (start-avg, 0). This is the part of the slope that 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 will result 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.

The packets that are destined for the CPU are prioritized based on the application. Some of the applications that are prioritized are Layer 2 data packets (a copy of which is sent to CPU for MAC learning), EFM, CFM, STP, LACP, ICMP, and so on The CPU provides 8 (eight) queues from BE (0) to NC (7). The packets destined for the CPU are classified internally and are put into the correct queue.

These packets are rate-limited to prevent DoS attacks. The software programs the classification entries to identify these packets and assigns appropriate bandwidth and priority to them. It is not configurable by the user.

The scheduling modes interact with the minimum and maximum bandwidth CoS queue and maximum bandwidth egress port shaping specifications. Each egress port may be configured to have a specific scheduling mode. The scheduler first services the queues to meet their CIR and then services the queues to meet the PIR. There are five possibilities as follows:

• Strict priority scheduling across CoS queues

  The strict priority scheduler provides strict priority access to the egress port across the CoS queue from highest CoS queue index (7) to the lowest (0). The purpose of the strict priority scheduler is to provide lower latency service to the higher CoS classes of traffic. In this mode, the scheduler services the queues in order of their prority in both the CIR and PIR loop.

  As described in the following table, CoS queues 7 and 6 each have a minimum bandwidth specification of 10 Mbps, whereas the remaining QoS queues have a minimum bandwidth specification of 50 Mbps. All CoS queues have a maximum bandwidth specification of 1 Gbps.

  The goal of these settings is to guarantee the minimum bandwidth settings for each of the queues while also allowing each CoS queue to fully use the egress port capability by having the maximum bandwidth setting at 1 Gbps. The strict priority scheduler mode provides low latency service for CoS queues 6 and 7 while their minimum bandwidth guarantees are being satisfied.

  Table 41. Minimum and maximum bandwidth meters example

  QoS queue name	Minimum bandwidth	Maximum bandwidth
  7	10 Mbps	1 Gbps
  6	10 Mbps	1 Gbps
  5	50 Mbps	1 Gbps
  4	50 Mbps	1 Gbps
  3	50 Mbps	1 Gbps
  2	50 Mbps	1 Gbps
  1	50 Mbps	1 Gbps
  0	50 Mbps	1 Gbps

• Round robin scheduling across CoS queues

  The round robin scheduler mode provides round robin arbitration across the CoS queues. The scheduler visits each backlogged CoS queue, servicing a single packet at each queue before moving on to the next one. The purpose of the round robin scheduler is to provide fair access to the egress port bandwidth (at a packet level). This works best when packet sizes are approximately comparable. In this mode, the scheduler services the queues in round-robin for both the CIR and the PIR loop.

• Weighted round robin (WRR)

  In WRR mode, the scheduler provides access to each CoS queue in round robin order.When the scheduler is providing access to a particular queue, it services a configurable number of back-to-back packets before moving on to the subsequent CoS queue. A value of strict is used to designate that a particular queue be considered to be a part of a hybrid Strict + WRR configuration.

  The values 1 to 15 are used to indicate the number of back-to-back packets to be serviced when the scheduler is servicing a particular CoS queue. If the weight specified is N, but if the number of packets in the queue is lesser than N, the scheduler continues working and moves on to the next backlogged queue. In this mode, with no strict queues configured, the scheduler services the queues in round robin in the CIR loop. The configured weights are not considered in the CIR loop. The weights are used only in the PIR loop.

• Weighted deficit round robin (WDRR) scheduling

  An inherent limitation of the WRR mode is that bandwidth is allocated in terms of packets. WRR works well if the average packet size for each CoS queue flow is known.WDRR aims at addressing this issue. WDRR provides a bandwidth allocation scheduler mode that takes into account the variably-sized packet issue by maintaining sufficient state information when arbitrating across the CoS queues. In this mode, with no strict queues configured, the scheduler services the queues in round-robin in the CIR loop.

  The configured weights are not considered in the CIR loop. The weights are used only in the PIR loop. A weight value of 1 to 15 can be configured for each queue. Based on the weights provided respective amount of bytes is de-queued from the queue. A value of 0 is used to designate that a particular queue be considered to be a part of a hybrid Strict + WDRR configuration. If a weight value of 1 is given for queue 1 and 5 is given for queue 2, we see traffic out of the port in the ratio of 1:5 between the queues (1 and 2), provided no traffic is flowing in the other queues. A weight value of 1 will actually pump out 2Kbytes from that queue, a value of 5 will pump out 10 Kbytes. Twice of the weight value given will be pumped out.

• Strict + WRR/WDRR

  If the WRR/WDRR weight associated with a particular CoS queue is set to strict, the queue is considered to be in a strict priority mode. This set of strict priority queues is serviced first in the order of their CoS numbering (higher numbered CoS queue receives service before smaller numbered queues). In this mode, the scheduler services the strict queues first and then the queues configured with weights in both the CIR and PIR loop. The scheduler ensures that it meets the CIR of all the queues (both strict queues and queues with weight), if bandwidth is available before scheduling the queues in the PIR loop. If multiple queues are configured as strict, the higher-priority strict queues are serviced first before the lower priority strict queues in both the CIR and the PIR loop. The weights configured for the queues are only considered during the PIR loop.

Port scheduler policies control the traffic behavior on a per-port basis. Associated with each egress port is a set of 8 (eight) class of service (CoS) queues and a default port-scheduler-policy named ‟default”. This default policy makes the port to behave in strict mode. The default policy cannot be modified. The user can attach another policy to the port to change its scheduling behavior.

The scheduler that provides the arbitration across the 8 (eight) CoS queues is a scheduler that is configured in a variety of modes. A major aspect of the arbitration mechanism is the ability to provide minimum and maximum bandwidth guarantees. This is accomplished by tightly integrating a network queue and access egress policies into the scheduler. After the packets are mapped into a COS queue, they are forwarded/conditioned using one of these schedulers (such as Strict Priority (SP), Round-Robin (RR), Weighted Round-Robin (WRR), Weighted Deficit Round-Robin (WDRR), (WRR+SP, WDRR+SP). The traffic shaping aspect is tightly integrated with the scheduler.

The 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE support port-based scheduling with the following:

• per-port egress scheduler for access port

• per-port egress scheduler for network and hybrid ports

See Schedulers on 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE for more information about scheduler behavior and to understand the queue parameters considered by the scheduler.

7210 SAS-Mxp supports scheduling as follows:

• When SAP-based scheduling mode is enabled, the following support is available:

  • per-SAP egress scheduler for access port and hybrid port.

  • per-port egress scheduler for network and hybrid port.

• When port-based scheduling mode is enabled, the following support is available:

  • per-port egress scheduler for access port.

  • per-port egress scheduler for network and hybrid port.

See the Schedulers on 7210 SAS-Mxp chapter for more information about scheduling behavior and to understand the queue parameters considered by the scheduler.

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

• When SAP-based scheduling mode is enabled, the following support is available:

  • per-SAP egress scheduler for access port and hybrid port

  • per-port egress scheduler for network and hybrid port

• When port-based scheduling mode is enabled, the following support is available:

  • per-port egress scheduler for access port

  • per-port egress scheduler for network and hybrid port

See Schedulers on 7210 SAS-R6 and 7210 SAS-R12 for more information about scheduling behavior and queue parameters considered by the scheduler.