2.1.2.1. Overview of network QoS policy applied to access-uplink ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Access-uplink ports are typically used to connect to the core network using QinQ or dot1q links and forward customer traffic towards 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:

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 given access-uplink port receive similar QoS treatment.

2.1.2.2. Overview of network QoS policy applied to network and hybrid ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Network ports are typically used to connect to the core network using IP/MPLS tunnels and forward customer traffic towards 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:

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 given network port or hybrid port receive similar QoS treatment.

2.2.1.1. Ingress classification support for network ports and hybrid ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

2.2.1.2. Egress marking support for network ports and hybrid ports on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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.

2.2.2.1. Ingress classification support for access-uplink ports

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.

2.2.4.1. Default service ingress 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.

2.2.5.1. Service ingress classification

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.

2.2.5.2. Service ingress classification — IP and MAC packet fields

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.

Note: The default frame type configured is Ethernet-II.

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

2.2.6.1. Default service egress policy

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.

2.3.1.1. Meter ID

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.

2.3.1.2. Committed information rate

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.

Note: The in-profile and out-profile values assigned determine the meter behavior for the packet. See Ingress profile assignment for information.

2.3.1.3. Peak information rate

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.

Note: The in-profile and out-profile values assigned determine the meter behavior for the packet. See Ingress profile assignment for information.

2.3.1.4. Adaptation rule for meters

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:

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.

Note: The 7210 SAS software considers the adaptation rules and the hardware values available to determine the admin PIR/CIR rates.

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.

2.3.1.5. Committed burst size

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.

2.3.1.6. Maximum burst size

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.

2.3.1.7. Meter counters

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

Each meter maintains the following counters:

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.

2.3.1.8. Meter modes

The 7210 SAS supports the following meter modes:

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.

2.3.1.9. Meter platform support

The following support is available on different platforms:

2.3.3.1. Configuring meter override parameters

The following is a sample meter override parameter configuration output.

2.8.1.1. Queue ID

The queue ID is used to uniquely identify the queue. The queue ID is only unique within the context of the QoS policy 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.

2.8.1.2. Committed information rate

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

Note: The in-profile and out-profile state of the ingress queue determines the packet’s final profile state based on the queue CIR, PIR values. The in-profile and out-profile state of the ingress queue also interacts with the scheduler mechanism and provides the minimum and maximum bandwidth guarantees. This is true only for ingress queues and not for egress queues. That is, the in-profile and out-profile state of the egress queue does not change the packets final profile state based on the queue CIR, PIR values. The in-profile and out-profile state of the egress queue only interacts with the scheduler mechanism and provides the minimum and maximum bandwidth guarantees. See Ingress profile assignment for more information.

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.

2.8.1.3. Peak information rate

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

2.8.1.4. Adaptation rule for queues

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 will attempt to find the best operational rate depending on the defined constraint.

The supported constraints are:

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.

Note: The 7210 SAS software considers the adaptation rules and the hardware values available to determine the admin PIR/CIR rates.

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.

2.8.1.5. Committed burst size

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. Once the reserved buffers for a given queue have been 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.

2.8.1.6. Maximum burst size

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

2.8.1.7. Ingress profile assignment

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 hence 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. Once 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 the user so desires.

2.8.1.8. Weight and priority

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.

2.8.1.9. Queue counters

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

Each queue maintains the following counters:

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.

2.8.1.10. Queue platform support

The following support is available.

2.8.2.1. Ring and non-ring buffer pool

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 towards 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 towards 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 vice versa, 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 vice versa, 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 given below.

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

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:

2.8.2.2. Configuration guidelines for CBS and MBS

2.8.4.1. Operation and configuration of RED slopes

Each queue provides the following options:

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.

2.8.4.2. Simplified overview of RED

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

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 percent. The Y-axis plots the probability of packet discard marked as 0 to 1. The actual slope can be defined as four sections in (X, Y) points.

Figure 3:  RED slope characteristics 

The following describes the sections shown in the preceding figure:

Plotting any value of shared buffer average utilization will 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.

2.8.4.3. Slope policy parameters

The elements required to define a slope policy are:

The following table lists the default slope policy definitions.