QoS policies

Access-uplink ports are typically used to connect to the core network using QinQ or dot1q links and forward customer traffic toward the core network. A network QoS policy defines both ingress and egress behavior on a access-uplink port. On access-uplink port ingress, traffic that enters through the 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 ingress 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 with regard to the number of FC queues for unicast traffic type and BUM traffic type, 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 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 2 ingress queues per FC. Unicast and multipoint traffic can be defined to use the same ingress queue or different ingress queues per FC.

For VPLS, the following types of forwarding are supported:

• unicast

• multicast

• broadcast

• unknown.

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 manner 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 any combination of dot1p and 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. That is, traffic received and transmitted through all the access-uplink SAPs configured on a specific access-uplink port receive similar QoS treatment.

Network ports are typically used to connect to the core network using IP/MPLS tunnels and forward customer traffic toward the core network. A network QoS policy defines both ingress and egress behavior on a network port. On network port ingress, traffic that enters through the 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 network port ingress and the profile determines the en-queuing 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 ingress queues is based on QoS marking (for example, MPLS EXP bits, 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 unicast traffic type and BUM traffic type, 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 ingress queue or different ingress queues per FC.

For VPLS, the following types of forwarding are supported:

• unicast

• multicast

• broadcast

• unknown

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 manner 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 network port egress or hybrid port egress, the policy maps FC and profile state to any combination of MPLS EXP, dot1p, and IP DSCP values for traffic to be transmitted out of the network IP interface that is configured on the network port or hybrid port. All network IP interfaces configured on the same network port or hybrid port use the same policy and the same set of FC queues; traffic received and transmitted through all network IP interfaces configured on a specified network port or hybrid port receive similar QoS treatment.

On ingress of network and hybrid ports, the user has an option to use both MPLS EXP and dot1p bits to map received MPLS packets to an FC. If both MPLS EXP and dot1p bits are configured, then the match order for MPLS packets is to match with MPLS EXP entries first and assign an FC if there is match. If no match exists, MPLS packets are matched with configured dot1p entries and assigned an FC if there is a match. If there is no match with both MPLS EXP and dot1p entries, the default configured FC is assigned. The DEI bit can be used to assign profile state to the MPLS packets on network ingress.

On ingress of network and hybrid ports, the user has an option to use both IP DSCP and dot1p bits to map received IP packets (plain routed packets in the context of network IP interfaces configured on the network port or hybrid port) to FC. If both IP DSCP and dot1p bits are configured, then the match order for IP packets is to match with IP DSCP entries first and dot1p entries next. The FC and profile value configured in the entry that matches first is assigned to the packet. If there is no match with either IP DSCP or dot1p values, the default FC is assigned to the packet. The DEI bit can be used to assign a profile state to the IP packets on network ingress.

MPLS EXP classification entries that map MPLS EXP values to FC, dot1p classification entries that map dot1p bits to FC, and IP DSCP classification entries that map IP DSCP values to FC are defined using MPLS EXP classification policies, dot1p classification policies, and DSCP classification policies, respectively.

On network port and hybrid port egress, the option to mark MPLS EXP and dot1p values for MPLS packets is provided. For IP packets sent out of network IP interfaces configured on a network port or hybrid port, the option to mark IP DSCP and dot1p values for IP packets is provided. Along with dot1p, the user has an option to mark the DEI bit for both MPLS and IP DSCP packets.

Network policy ID 2 is reserved for the default network QoS policy applied to network and hybrid ports. The default policy cannot be deleted or changed. The default network QoS policy is applied to all network and hybrid ports that do not have another network QoS policy explicitly assigned.

The network QoS policy applied at the network egress (that is, on a network port or hybrid 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 packets, out-of-profile packets are preferentially dropped over in-profile packets at congestion points in the network.

For network egress, traffic remarking in the network QoS policy can be enabled or disabled.

The following table lists the default mapping of FC to dot1p values for egress marking.

For network ingress, the following figure lists the default mapping of dot1p values to FC and profile state for the default network QoS policy.

For network ingress, the following table lists the default mapping of mpls-lsp-exp-classification values to FC and profile state for the default network QoS policy.

For network ingress, the following table lists the default mapping of dscp-classification values to FC and profile state for the default network QoS policy.

On ingress of access-uplink ports, users have the option to use both IP DSCP and dot1p bits to map received IP packets to FC. If both IP DSCP and dot1p bits are configured, then the match order for IP packets is to match with IP DSCP entries first and dot1p entries next. The FC and profile value configured in the entry which matches first is assigned to the packet. If there is no match with either IP DSCP and dot1p values, then the default FC is assigned to the packet. DEI bit can be used to assign profile state to the packets of network ingress.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, dot1p classification entries that map dot1p bits to FC and IP DSCP classification entries that map IP DSCP values to FC are defined by using dot1p-classification policies and DSCP classification policies respectively.

Network policy ID 1 is reserved for the default network QoS policy applied to access-uplink ports. The default policy cannot be deleted or changed. The default network QoS policy is applied to all access-uplink ports which do not have another network QoS policy explicitly assigned.

The network QoS policy applied at network egress (that is, 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 packets, out-of-profile packets are preferentially dropped over in-profile packets at congestion points in the network.

For network egress, traffic remarking in the network QoS policy can be enabled or disabled.

For network egress, the following table lists the default mapping of dot1p values to FC and profile state for the default network QoS policy.

For network ingress, the following table lists the default mapping of dot1p values to FC and profile state for the default network QoS policy.

Service ingress QoS policy ID 1 is reserved for the default service ingress policy. The default policy cannot be deleted or changed. The default service ingress policy is implicitly applied to all SAPs that do not explicitly have another service ingress policy assigned. In the default policy, all traffic is mapped to the default FC which uses a queue by default. The following table lists the characteristics of the default policy.

On access SAP-ingress, the user has an option to use either dot1p classification, IPv4 DSCP classification, IPv4 packet header fields, IPv6 packet header fields, or MAC packet header fields. The dot1p or DSCP classification rules to be used are defined in the dot1p and DSCP classification policy and associated with the SAP-ingress policy. The DSCP and dot1p classification policies can be configured in the same QoS policy. The IPv4 or IPv6 or MAC criteria can be configured in the SAP-ingress policy.

When packets are received on an access SAP, the following steps are used to determine the FC to assign to the packet.

1. Match IP criteria entries with the IP packet header fields in the packet. Assign the FC corresponding to the first entry which matches with IP packet header field values in the packet. If it is not an IP packet or if there is no match, go to next step.

2. Match MAC criteria entries with the MAC packet header fields in the packet. Assign the FC corresponding to the first entry which matches with MAC packet header field values in the packet. If there is no match, go to next step.

3. Match the IP DSCP value in the packet with the value configured in each of the IP DSCP entry defined in the DSCP classification policy. Assign the FC corresponding to the first entry which matches with IP DSCP value in the packet. If it is not an IP packet or if there is no match, go to next step.

4. Match the dot1p value in the packet (if available) with the value configured in each of the dot1p entry defined in the dot1p classification policy. Assign the FC corresponding to the first entry which matches with dot1p value in the packet. If there is no match, go to next step.

5. Assign the default FC.

The IP and MAC match criteria can be very basic or quite detailed. IP and MAC match criteria are assembled from policy entries. An entry is identified by a unique, numerical entry ID. A single entry cannot contain more than one match value for each match criteria. Each match entry has an action which specifies the FC of packets that match the entry. The entries are evaluated in numerical order based on the entry ID from the lowest to highest ID value. The first entry that matches all match criteria has its action performed.

The following tables list the packets fields used for match-criteria used for access SAP-ingress classification.

The following table lists the Packet Fields available for match in QoS classification policy and ACL policy for different SAPs.

The 7210 SAS does not support configuring of the frame-type match criteria and the default frame type configured is Ethernet - II; see the following table.

The following table lists the criteria that can be matched for the various MAC frame types.

Service egress QoS policy ID 1 is reserved as the default service egress policy. The default policy cannot be deleted or changed. The default access egress policy is applied to all SAPs service egress policy explicitly assigned. The following table lists the characteristics of the default policy.

The meter ID is used to uniquely identify the meter/policer. The meter ID is only unique within the context of the QoS policy in which the meter is defined. It allows user to define multiple Meters with different characteristics and identify them while associating it with different FCs.

The user has the option to allocate up to eight meters and assign them a meter ID along with the option to configure the meter parameters that determine the meter characteristics.

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

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

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the meter. The PIR does not specify the maximum rate at which packets can enter the meter; this is controlled by the ability of the meter to absorb bursts and is defined by its maximum burst size (MBS).When defining the PIR for a meter, the value specified is the administrative PIR for the meter. The 7210 SAS devices have a number of rates in the hardware that determine the operational PIR for the meter. The user has limited control over how the administrative PIR is converted to an operational PIR if the hardware does not support the exact CIR and PIR combination specified. See Adaptation rule for meters for more information about the interpretation of the administrative PIR.

The adaptation rule provides the QoS provisioning system with the ability to adapt specific CIR and PIR defined administrative rates to the underlying capabilities of the hardware the queue will be created on to derive the operational rates. The administrative CIR and PIR rates are translated to actual operational rates, which are enforced by the hardware meter/policer. The rule provides a constraint when the exact rate is not available.

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

• minimum

  The system finds the hardware supported rate that is equal to or higher than the specified rate.

• maximum

  The system finds the hardware supported rate that is equal to or lesser than the specified rate.

• closest

  The system finds the hardware supported rate that is closest to the specified rate.

Depending on the platform on which the queue is provisioned, the actual operational CIR and PIR settings used by the queue will be dependent on the method the hardware uses to implement and represent the mechanisms that enforce the CIR and PIR rates. The adaptation rule controls the method the system uses to choose the rate step based on the administrative rates defined by the rate command.

To illustrate (the example that follows is only for illustration of the use of adaptation rule and the values provided below does not list the actual values supported in hardware), how the adaptation rule constraints minimum, maximum and closest are evaluated in determining the operational CIR or PIR for the 7210 SAS, assume there is a queue where the administrative CIR and PIR values are 90 Kb/s and 150 Kb/s, respectively. If the adaptation rule is minimum, the operational CIR and PIR values will be 128 Kb/s and 192 Kb/s respectively, as it is the native hardware rate greater than or equal to the administrative CIR and PIR values.

If the adaptation rule is maximum, the operational CIR and PIR values are 64 kb/s and 128 kb/s. If the adaptation rule is closest, the operational CIR and PIR values are 64 kb/s and 128 kb/s, respectively, as those are the closest matches for the administrative values that are even multiples of the 64 kb/s rate step.

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

The operational CBS set by the system is adapted from the user-configured value by using the minimum constraint. The burst size configured by the user affects the rate step-size used by the system. The system uses the step size in a manner that both the burst-size and rate parameter constraints are met.

For Two Rate Three Color Marking (trTCM) policer using two-rate three-color marker) The maximum burst size parameter specifies the maximum burst size that can be transmitted by the source at the PIR while complying with the PIR. If the transmitted burst is lower than the MBS value, the packets are marked as out-profile by the meter to indicate that the traffic is not complying with CIR, but is complying with PIR.For Single Rate Three Color Marking (srTCM) (policer using single rate three color marker), the maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while not complying with the CIR. If the transmitted burst is lower than the MBS value, the packets are marked as out-profile by the meter to indicate that the traffic is not complying with CIR. If the packet burst is higher than MBS, packets marked as red are dropped.

The operational MBS set by the system is adapted from the user-configured value by using the minimum constraint. The burst size configured by the user affects the rate step-size used by the system. The system uses the step size in a manner that both the burst-size and rate parameter constraints are met.

The router maintains counters for meters within the system for the purpose of granular billing and accounting.

Each meter maintains the following counters:

• counter to count packets and octets forwarded in-profile

• counter to count packets and octets forwarded out-of-profile

• counter to count packets and octets dropped

Accounting record support available on each of the platforms is listed in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide under the ‟Accounting Records/Logs” section.

The 7210 SAS supports the following meter modes:

• srTCM - Single Rate Three Color Marking

• trTCM - Two Rate Three Color Marking

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

For all platforms, a service meter can be provisioned on access SAP-ingress within service ingress QoS policies.

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy within which the queue is defined. It allows user to define multiple queues with different characteristics and identify them while associating it with different FCs.

The user has an option to allocate up to 8 queues and assign them a queue ID along with the option to configure some of the queue parameters that determine the queue characteristics.

The committed information rate (CIR) for a queue performs two distinct functions:

• Minimum bandwidth guarantees

  Queue’s CIR setting provides the bandwidth that is provided to this queue as compared to other queues on the port competing for a share of the available link bandwidth. The queue CIR does not necessarily guarantee bandwidth in all scenarios and also depends on factors such as CIR over subscription and link port bandwidth capacity. For each packet in a queue, the CIR is checked with the current transmission rate of the queue. If the current rate is at or below the CIR threshold, the queue is considered in-profile. If the current rate is above the threshold, the queue is considered out-of-profile. The in-profile and out-profile state of queue is linked to scheduler prioritizing behavior as discussed below.

• Scheduler queue priority metric

  The scheduler serving a group of queues prioritizes individual queues based on their current CIR and PIR states. Queues operating below their CIR are always served before those queues operating at or above their CIR. Also see information about schedulers to know the scheduler behavior on different 7210 SAS platforms.

When defining the CIR for a queue, the value specified is the administrative CIR for the queue. User has some control over how the administrative CIR is converted to an operational CIR should the hardware not support the exact CIR and PIR combination specified. The interpretation of the administrative CIR is discussed below in Adaptation rule for queues.

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

The CIR of the queue is configurable under the different QoS policies that provide the option to configure the queue parameters; for example, under service ingress and service egress queue policies, access port policies, and network queue policies.

The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit the queue. It does not specify the maximum rate at which packets may enter the queue; this is governed by the queue's ability to absorb bursts. The actual transmission rate of an egress queue depends on more than just its PIR. Each queue is competing for transmission bandwidth with other queues. Each queue's PIR, CIR and the relative priority and/or weight of the scheduler serving the queue, all combine to affect a queue's ability to transmit packets.

When defining the PIR for a queue, the value specified is the administrative PIR for the queue. The user has some control over how the administrative PIR is converted to an operational PIR should the hardware not support the exact CIR and PIR values specified. The interpretation of the administrative PIR is discussed in Adaptation rule for queues

The PIR of the queue is configurable under the different qos policies that provide the option to configure the queue parameters – example under service ingress and service egress queue policies, access port policies, network queue policies, and so on

The adaptation rule provides the QoS provisioning system with the ability to adapt specific CIR and PIR defined administrative rates to the underlying capabilities of the hardware the queue will be created on to derive the operational rates. The administrative CIR and PIR rates are translated to actual operational rates enforced by the hardware queue. The rule provides a constraint used when the exact rate is not available.

For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

The supported constraints are:

• minimum

  Find the hardware supported rate that is equal to or higher than the specified rate.

• maximum

  Find the hardware supported rate that is equal to or lesser than the specified rate.

• closest

  Find the hardware supported rate that is closest to the specified rate.

Depending on the platform on which the queue is provisioned, the actual operational CIR and PIR settings used by the queue are dependent on the method the hardware uses to implement and represent the mechanisms that enforce the CIR and PIR rates. The adaptation rule controls the method the system uses to choose the rate step based on the administrative rates defined by the rate command.

To illustrate (the example that follows is only for illustration of the use of adaptation rule and the values provided below does not list the actual values supported in hardware), how the adaptation rule constraints minimum, maximum and closest are evaluated in determining the operational CIR or PIR for the 7210 SAS, assume there is a queue where the administrative CIR and PIR values are 90 kb/s and 150 kb/s, respectively. If the adaptation rule is minimum, the operational CIR and PIR values will be 128 kb/s and 192 kb/s respectively, as it is the native hardware rate greater than or equal to the administrative CIR and PIR values. If the adaptation rule is maximum, the operational CIR and PIR values will be 64 kb/s and 128 kb/s. If the adaptation rule is closest, the operational CIR and PIR values will be 64 kb/s and 128 kb/s, respectively, as those are the closest matches for the administrative values that are even multiples of the 64 kb/s rate step.

The committed burst size (CBS) parameters specify the amount of buffers that can be drawn from the reserved buffer portion of the queue’s buffer pool. After the reserved buffers for a specific queue are used, the queue contends with other queues for additional buffer resources up to the maximum burst size.

The CBS of the queue is configurable under the different QoS policies, if supported by the platform, that provide the option to configure the queue parameters – example under service ingress and service egress queue policies, network queue policies, and so on The CBS for a queue is specified in kbytes.

The CBS for the queues is user-configurable. By default, software assigns a default value. It can be modified by the user as per their needs. The default value are specified in the command description.

The maximum burst size (MBS) parameter specifies the maximum queue depth to which a queue can grow. This parameter ensures that a customer that is massively or continuously oversubscribing the PIR of a queue does not consume all the available buffer resources. For high-priority FC service queues, the MBS can be relatively smaller than the other FC queues because the high-priority service packets are scheduled with priority over other service FCs.

The MBS of the queue is configurable under the different QoS policies, if supported by the platform, that provide the option to configure the queue parameters – example under service ingress and service egress queue policies, network queue policies, and so on The MBS for a queue is specified in kbytes.

The MBS for the queues is user-configurable. By default, software assigns a default value. It can be modified by the user as per their needs. The default values are specified in the command description.

Queues can operate in two modes – profile mode and non-profile mode.

On the 7210 SAS-K 2F1C2T, SAP-ingress queues and access uplink port ingress queues operate in either profile mode or non-profile mode.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, SAP-ingress queues, network port and hybrid port ingress queues, and access uplink port ingress queues operate in either profile mode or non-profile mode.

In profile mode, the profile defined in the policy is used to determine the WRED slope to use for ingress queuing, with ‟profile in” packets using high-slope and ‟profile out” packets using low-slope. The ingress queue shaper does not change the profile value assigned to a packet that has a user assigned profile value. That is, if a user assigns a profile value of green and the packet exceeds the CIR rate of the shaper, it is not changed to yellow. Similarly, packets assigned yellow are not changed by the shaper. The color assigned by the user is also subsequently used at the egress queuing point to determine the slope to use.

In non-profile mode, the profile is not specified by the user (and the node maps it to a value of ‟undefined”. The low WRED slope is used at the ingress queuing point, as all packets received are considered to be the same as ‟profile out”. The packet is then assigned the profile by the ingress queue shaper. It is assigned ‟in” profile value if it is within the CIR and assigned ‟out” profile value if it exceeds the CIR. It is dropped if it exceeds the PIR rate of ingress queue shaper (except for packets which are assigned a profile value of ‟undefined” on ingress and where the shaper assigns the profile based on CIR/PIR rate). The profile assigned by the ingress queue shaper is also subsequently used at the egress queuing point to determine the slope to use.

The user is provided with different options to assign the profile to the packet (for example, DEI based). It is always assigned on ingress of the packet into the node. When the profile is assigned at the ingress, it is used at subsequent queuing points in the system. That is, subsequent modules and queuing points in the system do not change the profile assigned to the packet on ingress. The profile assigned at ingress is also used to subsequently assign different marking/remarking values to in-profile and out-of-profile packets, if this meets user needs.

A priority and weight can be assigned to the queue. The priority determines the service order of the queue when the scheduler schedules multiple queues configured on the same port. The queue weight determines the proportion of the available bandwidth that the scheduler allocates to a queue.

The router maintains counters for queues within the system for granular billing and accounting.

Each queue maintains the following counters:

• counters for packets and octets accepted into the queue

• counters for packets and octets rejected at the queue

• counters for packets and octets transmitted in-profile

• counters for packets and octets transmitted out-of-profile

The counters available vary among the 7210 SAS platform. Not all the counters are supported on all the platforms. Additionally there are restrictions on the number of counters that can be used simultaneously with a single queue. Some platforms can only count octets or packets and other can count both packets and octets. Counter (and corresponding accounting record) support available on each of the platform is listed in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C System Management Guide in the Accounting Records/Logs section.

The following support is available.

• For all platforms

  Service queue is provisioned on access SAP-ingress and access SAP-egress service queues within service ingress QoS policies and service egress QoS policies, respectively.

• For all platforms

  Access-uplink port ingress queues are defined within network QoS policies.

• For all platforms

  Access-uplink port egress queues are defined within network queue policies.

• On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

  Network port and hybrid port ingress queues are defined within network QoS policies.

• On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

  Network port and hybrid port egress queues are defined within network queue policies.

When the 7210 SAS-K 2F1C2T is deployed in a ring environment, the access-uplink ports are typically used to connect the node to ring. Similarly, on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, users will typically use the network ports to join the node into a ring. Therefore, these ports are designated as the ring ports. These ring ports carry traffic from the head-end toward the node (that is, the 7210 SAS), dropping traffic off to user/customer locations. Simultaneously, these ring ports carry traffic from the user/customer to the head-end. That is, traffic received from the user/customer is added to the ring and sent out toward the service edge, where services are terminated. The traffic in both these directions is typically admitted into the ring after being shaped and groomed. In the upstream direction (that is, in the direction of customer to service edge) the SLA is enforced at service ingress points (that is, typically access SAPs) and the traffic is shaped and groomed, similarly in the downstream direction (that is, in the direction of service edge to customer) it is done by the service edge device or the access aggregation device. That is, the downstream traffic should typically be allowed to pass through the intermediate nodes of the ring, without contention with and prioritized over the traffic that is received from the customer and being added into the ring by the nodes on the ring.

On the 7210 SAS-K 2F1C2T, the access-uplink ports are designated as ring ports and access ports are designated as non-ring ports. Traffic going from any access-uplink to another access-uplink port is identified as ring traffic. Traffic going from an access port to any access-uplink port, or traffic going from any access-uplink port to an access port (in egress), or traffic going from an access port to another access port is identified as non-ring traffic.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the network ports and access-uplink ports are designated as ring ports and access ports are designated as non-ring ports. Traffic going from any network port or access-uplink to another network port or access-uplink port is identified as ring traffic. Traffic going from an access port to any network port or access-uplink port, or traffic going from any network port or access-uplink port to an access port (in egress), or traffic going from an access port to another access port is identified as non-ring traffic.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the SAPs configured on hybrid ports are designated as non-ring service objects, and network port IP interfaces are designated as ring service objects. Traffic going from any network port IP interface on a hybrid port to another network port IP interface on a network port or a hybrid port, or the other way around, is identified as ring traffic. Traffic going from a SAP configured on a hybrid port to any network port, access-uplink port, or access port, or to another SAP on the hybrid port, or the other way around, is designated as non-ring traffic.

To ensure that the traffic received on ring ports is prioritized over traffic received on non-ring access ports, a separate ring MBS buffer pool (one each for ingress and egress) is provided for traffic received and sent out of ring ports. In addition, for ring ports and service objects, such as network port egress, hybrid port egress, and access-uplink egress (where shaped customer (access) traffic and ring traffic share the ring pool), two additional ring slopes (for a total of four configurable WRED slopes) are provided to prioritize the ring traffic. Each egress queue on the network port, hybrid port, or access-uplink port supports four slopes per queue — ring high-slope, ring low-slope, non-ring high-slope, and non-ring low-slope (in the CLI command, the ring slopes are configured using the high-slope-ring and low-slope-ring, and the non-ring slopes are configured using the high-slope and low-slope). Ring high-slope and ring low-slope are used for in-profile and out-of-profile QoS profile ring traffic. Non-ring high-slope and low-slope are used for in-profile and out-of-profile non-ring traffic. Slope parameters (start-avg, max-avg, max-prob) of four slopes can be configured such that the ring traffic is prioritized over the non-ring traffic (that is, traffic being added onto the ring) in congestion scenarios.

A separate non-ring MBS buffer pool for traffic received and sent out of access ports along with two configurable WRED slopes is supported. Each queue on the access ports supports two slopes per queue –non-ring high-slope and non-ring low-slope. Non-ring high-slope and low-slope is used for in-profile and out-of-profile non-ring traffic. The non-ring buffer pool (one each for ingress and egress) is used to allocate buffers for non-ring traffic.

The usage of buffer pools for different traffic flows is as follows.

On the 7210 SAS-K 2F1C2T, the ring and non-ring buffer pools are used by the following traffic flows:

• Traffic received on access-uplink SAP and sent out of access-uplink SAP, uses the ring MBS buffer pool for MBS buffers on access-uplink port ingress and access-uplink port egress. In this case, ring high-slope is used for in-profile traffic and ring low-slope is used for out-of-profile traffic for both access-uplink ingress and access-uplink egress.

• Traffic received on access SAP and sent out of access-uplink SAP, uses the non-ring MBS buffer pool for MBS buffers on access SAP-ingress and uses the ring MBS buffer pool for MBS buffers on access-uplink SAP-egress. In this case, non-ring high slope and non-ring low slope is used on both access SAP-ingress and access-uplink egress.

• Traffic received on access-uplink SAP and sent out of another access SAP uses ring MBS buffer pool for MBS buffers on access-uplink SAP-ingress and the non-ring MBS buffer pool for MBS buffers on access SAP-egress. In this case, ring high-slope and ring low-slope is used on access-uplink ingress and non-ring high-slope and non-ring low-slope is used on access egress.

• Traffic received on access SAP and sent out of another access SAP uses the non-ring MBS pool for MBS buffers for both access SAP-ingress and access SAP-egress. In this case, non-ring high-slope and non-ring low-slope is used on both access ingress and access egress.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the ring and non-ring buffer pools are used by the following traffic flows:

• Traffic received on network port and sent out of network port, uses the ring MBS buffer pool for MBS buffers on network port ingress and network port egress. In this case, ring high-slope is used for in-profile traffic and ring low-slope is used for out-of-profile traffic for both network port ingress and port egress.

• Traffic received on access SAP and sent out of port, uses the non-ring MBS buffer pool for MBS buffers on access SAP-ingress and uses the ring MBS buffer pool for MBS buffers on network port egress. In this case, non-ring high slope and non-ring low slope is used on both access SAP-ingress and network port egress.

• Traffic received on network port and sent out of another access SAP uses ring MBS buffer pool for MBS buffers on network port ingress and the non-ring MBS buffer pool for MBS buffers on access SAP-egress. In this case, ring high-slope and ring low-slope is used on network port ingress and non-ring high-slope and non-ring low-slope is used on access egress.

• Traffic received on access-uplink SAP and sent out of access-uplink SAP, uses the ring MBS buffer pool for MBS buffers on access-uplink port ingress and access-uplink port egress. In this case, ring high-slope is used for in-profile traffic and ring low-slope is used for out-of-profile traffic for both access-uplink ingress and access-uplink egress.

• Traffic received on access SAP and sent out of access-uplink SAP, uses the non-ring MBS buffer pool for MBS buffers on access SAP-ingress and uses the ring MBS buffer pool for MBS buffers on access-uplink SAP-egress. In this case, non-ring high slope and non-ring low slope is used on both access ingress and access-uplink egress.

• Traffic received on access-uplink SAP and sent out of another access SAP uses ring MBS buffer pool for MBS buffers on access-uplink SAP-ingress and the non-ring MBS buffer pool for MBS buffers on access SAP-egress. In this case, ring high-slope and ring low-slope is used on access-uplink ingress and non-ring high-slope and non-ring low-slope is used on access egress.

• Traffic received on access SAP and sent out of another access SAP uses the non-ring MBS pool for MBS buffers for both access SAP-ingress and access SAP-egress. In this case, non-ring high-slope and non-ring low-slope is used on both access ingress and access egress.

• Traffic received on a network IP interface on a hybrid port and sent out of a network port or another IP interface on a hybrid port uses the ring MBS buffer pool for MBS buffers on network or hybrid port ingress and network or hybrid port egress. In this case, ring high-slope is used for in-profile traffic, and ring low-slope is used for out-of-profile traffic for both network and hybrid port ingress and egress.

• Traffic received on a SAP on a hybrid port and sent out of a network port or network IP interface on a hybrid port uses the non-ring MBS buffer pool for MBS buffers on SAP-ingress and the ring MBS buffer pool for MBS buffers on network port egress. In this case, non-ring high-slope and non-ring low-slope are used on both access SAP-ingress and network port egress.

• Traffic received on a network IP interface on a hybrid port and sent out of a SAP configured on a hybrid port uses the ring MBS buffer pool for MBS buffers on network port ingress and the non-ring MBS buffer pool for MBS buffers on SAP-egress. In this case, ring high-slope and ring low-slope are used on network port ingress and non-ring high-slope and non-ring low-slope are used on SAP-egress.

• Traffic received on a SAP on a hybrid port and sent out of an access-uplink SAP uses the non-ring MBS buffer pool for MBS buffers on SAP-ingress and uses the ring MBS buffer pool for MBS buffers on access-uplink SAP-egress. In this case, non-ring high-slope and non-ring low-slope are used on both SAP-ingress and access-uplink egress.

• Traffic received on an access-uplink SAP and sent out of a SAP on a hybrid port uses the ring MBS buffer pool for MBS buffers on access-uplink SAP-ingress and the non-ring MBS buffer pool for MBS buffers on SAP-egress. In this case, ring high-slope and ring low-slope are used on access-uplink ingress and non-ring high-slope and non-ring low-slope are used on SAP-egress.

• Traffic received on a SAP on a hybrid port and sent out of another SAP on the hybrid port uses the non-ring MBS pool for MBS buffers for both SAP-ingress and access SAP-egress. In this case, non-ring high-slope and non-ring low-slope are used on both SAP-ingress and SAP-egress.

• For configuring the CBS value, the following must be considered:

  • If Jumbo frames need to be accommodated, then CBS must be set to at least a minimum of 10 kbytes. The default value set for the queue allows for jumbo frames. It is recommended to set the CBS to twice the amount of maximum frame size the queues is expected to carry.

  • CBS pool cannot be oversubscribed.

• For configuring the MBS value, the following must be considered:

  • MBS value determines the maximum delay a packet can experience when using that queue. It should be set to a value such that the delay is acceptable.

  • It is recommended to set the minimum value for MBS to be about four to five times the maximum size of the frame the queue is expected to carry to ensure better scheduling performance.

Each queue provides the following options:

• an option to use two slopes per queue on non-ring ports - a high-priority RED slope and a low-priority RED slope

• an option to use four slopes per queue on ring ports – a non-ring high-priority RED slope, a non-ring low-priority RED slope, a ring high-priority RED slope, and a ring 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. See Buffer pools for more information.

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

When a queue depth exceeds the queue CBS, packets received on that queue must contend with other queues exceeding their CBS for shared buffers. To resolve this contention, RED slopes are used to determine buffer availability on a packet-by- packet basis. A packet that is 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 are 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:

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

• At initialization, the utilization is zero and the average utilization is zero.

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

• A random number is generated associated with the packet and is compared to the discard probability.

• The lower the discard probability, the lower the chances that the random number is within the discard range.

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

• A packet is discarded if the utilization variable is equal to the shared buffer size, or if the utilized CBS (actually in use by queues, not just defined by the CBS) is oversubscribed and has stolen buffers from the shared size, lowering the effective shared buffer size equal to the shared buffer utilization size.

• The new shared buffer average utilization is used as the shared buffer average utilization next time a packet probability is plotted on the RED slope.

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

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

The following describes the sections shown in the preceding figure:

• Section A is (0, 0) to (start-avg, 0). This is the part of the slope where the packet discard value is always zero, preventing the RED function from discarding packets when the shared buffer average utilization falls between 0 and start-avg.

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

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

• Section D is (max-avg, 1) to (100%, 1). On this part of the slope, the shared buffer average utilization value of max-avg to 100% results in a packet discard probability of 1.

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

The elements required to define a slope policy are:

• a unique policy ID

• the high-slope (for in-profile packets) and low-slope (for out-of-profile packets) per queue; configurable parameters on each slope are start-avg, max-avg, and max-prob

• the ring and non-ring high and low slopes for access-uplink port egress

• on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the ring and non-ring high and low slopes for network port and hybrid port egress

The following table lists the default slope policy definitions.