Overview of QoS policies on 7210 SAS-K 2F1C2T

On 7210 SAS-K 2F1C2T, QoS policies are applied on service ingress, service egress and access uplink ports (ingress and egress) and define the following:

There are the following types of QoS policies:

Service ingress QoS policies are applied to the customer-facing Service Access Points (SAPs) on access ports. Traffic that enters through the access SAP is classified to map it to a forwarding class (FC) and the user has an option to also assign a profile on SAP-ingress. An FC can be associated with either queues or policer/meter on service ingress. That is, service ingress FC can be configured to use queue or a meter allowing for some FCs to use queues and some others to use meters. When the FC is associated with a queue on access SAP-ingress (also known as service ingress), the profile determines the enqueing priority for the packet, with in-profile packets having a higher chance of getting a buffer, than out-of-profile packets. The mapping of traffic to FC/queues can be based on combinations of customer QoS marking in the packet header (for example, IEEE 802.1p bits, IP DSCP bits, MAC address, and so on). The characteristics of the FC queues are defined within the policy with regard to the number of FC queues to use for unicast traffic and BUM (Broadcast, Unknown-unicast, and Multicast) traffic along with the queue rate and buffer parameters (like CIR, PIR, CBS, MBS). Each of the FCs can be associated with different parameters for unicast traffic and different parameters for multipoint (that is, BUM) traffic.

A service ingress QoS policy defines up to eight queues per policy, with up to two queues (that is, Unicast Queue Mapping and Multicast Queue Mapping) per FC. Unicast and multipoint traffic can be mapped to use the same queue or mapped to use different queues per FC with a maximum of up to two queues per FC, one each for unicast and for multicast traffic.

For VPLS, the following types of forwarding are supported:

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 fashion within the service. Multicast, broadcast, and unknown traffic types use the same multicast-queue mapping defined for FC. That is, a separate queue for multicast, broadcast, and unknown unicast traffic types cannot be defined.

Service ingress policies provide an option to use a policer per FC, instead of a queue. It allows users to classify low-latency less bursty traffic on service ingress to an FC and use a policer to enforce rate. When an FC is associated with policer on access SAP-ingress, the profile determines the ingress color for the packet. It allows in-profile (green) packets to use the available tokens from the CIR rate first while out-of-profile packets use available tokens from the PIR rate first. This allows the user to prioritize in-profile packets over out-profile packets by ensuring that CIR rate is available for in-profile service ingress packets.

The mapping of traffic to FC meter can be based on combinations of customer QoS marking in the packet header (for example, IEEE 802.1p bits, IP DSCP bits, MAC address, and so on). The characteristics of the FC policer are defined within the policy with regard to the number of FC meters to use for unicast traffic and BUM traffic along with the policer rate (like CIR, PIR) and burst parameters (like CBS, MBS). Each FC can be associated with different parameters for unicast traffic and different parameters for multipoint (that is, BUM) traffic.

A service ingress QoS policy defines up to 16 meters per policy, with up to 2 meters per FC. Unicast and multipoint traffic can be mapped to use the same policer or mapped to use different policer per FC with a maximum of up to 2 policer per FC, one each for unicast and for multicast traffic. In the case of VPLS service, four 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 in a point-to-point fashion within the service. Multicast, broadcast, and unknown traffic types use the same multicast meter mapping defined for FC. That is, a separate meter for multicast, broadcast, and unknown unicast traffic types cannot be defined.

Service ingress QoS policy also provides an option to configure a mix of meters and queues per policy and per FC. That is, it is possible to use a queue for one of the FC used to forward bursty traffic while using a meter for another FC used to forward low-latency traffic. In addition, it is possible to configure a queue for unicast traffic type while using a meter for BUM traffic types or the other way around.

On service ingress when a combination of queues and meters are used, the option is available to configure the service ingress aggregate rate for queues and meters individually. That is, the service ingress aggregate policer rate enforces the rate across all the FC meters configured in the SAP while the service ingress aggregate shaper rate enforces the rate across all the FC queues configured in the SAP.

Service egress QoS policies are applied to SAPs and map FCs to service egress queues for a service. The system can allocate a maximum of eight queues per SAP for the eight FCs. All traffic types (that is, both unicast and BUM traffic types) 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.

Network QoS policies are applied to access-uplink ports. Access-uplink ports are typically used to connect to the core network and forward customer traffic toward the core network. A network QoS policy defines both ingress and egress behavior. On access-uplink port ingress, traffic that enters through the access-uplink port is classified to map it to an FC and the user has an option to assign a profile. FC is associated with ingress queues on access uplink port ingress and the profile determines the enqueing priority for the packet, with in-profile packets have a higher chance of getting the buffer, than out-of-profile packets. The mapping of traffic to FC queues is based on QoS marking (for example, IEEE 802.1p bits, IP DSCP bits).

The characteristics of the FC ingress queues are defined within the policy as to the number of FC queues for the unicast traffic type and BUM traffic types, along with the queue rate and buffer parameters (like CIR, PIR, CBS, MBS, and so on). Each of the FCs can be associated with different ingress and ingress queue parameters for unicast traffic type and for multipoint (that is, BUM) traffic type.

A network QoS policy defines up to eight ingress queues per policy, with up to two ingress queues per FC. Unicast and multipoint traffic can be defined to use the same queue or different ingress queues per FC.

For VPLS, the following types of forwarding are supported:

Multicast, broadcast, and unknown types are sent to multiple destinations within the service while the unicast forwarding type is handled in a point-to-point fashion within the service. All these traffic types use the same queue (a separate queue for multicast, broadcast, and unknown unicast traffic types cannot be defined).

On access-uplink port egress, the policy maps FC and profile state to dot1p or IP DSCP values for traffic to be transmitted out of the access-uplink port. All the access-uplink SAPs configured on the same access-uplink port use the same policy and the same set of FC queues. Traffic received and transmitted through all the access-uplink SAPs configured on a particular access-uplink port receive similar QoS treatment.

On egress, network queue policies are applied to access-uplink ports and map FCs to network-egress queues on access-uplink ports. The system allocates eight egress queues per access-uplink port for the eight FCs. The policy defines the FC queue characteristics (that is, CIR, PIR, CBS, MBS, and so on). All traffic types (that is, both unicast and BUM traffic types) share the same queue on access-uplink port egress. All the access-uplink SAPs configured on the same access-uplink port use the same policy and the same set of FC queues. Traffic transmitted through all the access-uplink SAPs configured on a specific access-uplink port receive similar QoS treatment.

Slope policies are applied to service ingress queues, service egress queues, access uplink port ingress queues, and access uplink port egress queues. Each of these queuing points allocates buffers from the buffer pool and implements WRED for congestion management. During congestion WRED is used to evaluate how buffers from the pool are allocated to different FCs and to in-profile and out-of-profile traffic within a specific FC. The slope policies define the WRED parameters to use for in-profile/high-priority packets and for out-of-profile/low-priority packets. The high-slope and low-slope define the parameters for in-profile/high-priority packets and for out-of-profile/low-priority packets respectively. In addition, the 7210 SAS-K 2F1C2T introduces the concept of ring and non-ring ports with an option for preferential allocation of traffic for ring ports. The system by default treats access-uplink ports as ring ports.

Remark policies are applied to access SAP-egress and access-uplink port egress. They are not directly associated with the SAP and access-uplink port egress. Instead they are associated with service egress policy and network QoS policy. They define the FC and profile to egress marking values (for example, IEEE 802.1p bits in the Ethernet VLAN tag) to use.

Dot1p classification and DSCP classification allows the user to define the map of dot1p bits and IP DSCP values to FC and assign the profile for the packet on access SAP-ingress and access-uplink port ingress.

One service ingress QoS policy and one service egress QoS policy can be applied to a SAP access. One network QoS can be applied to a specific access-uplink port. One network queue policy can be applied to the access uplink port. If no QoS policy is explicitly applied to a SAP or port, a default QoS policy is applied.

Parent topic: QoS policies overview