QoS and QoS Policies

In order to provide what network engineers call Quality of Service (QoS), the flow of data in the form of packets must be predetermined and resources must be somehow assured for that predetermined flow. Simple routing does not provide a predetermined path for the traffic, and priorities that are described by Class of Service (CoS) coding simply increase the odds of successful transit for one packet over another. There is still no guarantee of service quality. The guarantee of service quality is what distinguishes QoS from CoS. CoS is an element of overall QoS.

By using the traffic management features of the 7705 SAR, network engineers can achieve a QoS for their customers. Multiprotocol Label Switching (MPLS) provides a predetermined path, while policing, shaping, scheduling, and marking features ensure that traffic flows in a predetermined and predictable manner.

There is a need to distinguish between high-priority (that is, mission-critical traffic like signaling) and best-effort traffic priority levels when managing traffic flow. Within these priority levels, it is important to have a second level of prioritization, that is, between a certain volume of traffic that is contracted/needed to be transported, and the amount of traffic that is transported if the system resources allow. Throughout this guide, contracted traffic is referred to as in-profile traffic. Traffic that exceeds the user-configured traffic limits is either serviced using a lower priority or discarded in an appropriate manner to ensure that an overall quality of service is achieved.

The 7705 SAR must be properly configured to provide QoS. To ensure end-to-end QoS, each and every intermediate node together with the egress node must be coherently configured. Proper QoS configuration requires careful end-to-end planning, allocation of appropriate resources and coherent configuration among all the nodes along the path of a given service. Once properly configured, each service provided by the 7705 SAR will be contained within QoS boundaries associated with that service and the general QoS parameters assigned to network links.

The 7705 SAR is designed with QoS mechanisms at both egress and ingress to support different customers and different services per physical interface or card, concurrently and harmoniously (refer to Egress and Ingress Traffic Direction for a definition of egress and ingress traffic). The 7705 SAR has extensive and flexible capabilities to classify, police, shape and mark traffic to make this happen.

The 7705 SAR supports multiple forwarding classes (FCs) and associated class-based queuing. Ingress traffic can be classified to multiple FCs, and the FCs can be flexibly associated with queues. This provides the ability to control the priority and drop priority of a packet while allowing the fine-tuning of bandwidth allocation to individual flows.

Each forwarding class is important only in relation to the other forwarding classes. A forwarding class allows network elements to weigh the relative importance of one packet over another. With such flexible queuing, packets belonging to a specific flow within a service can be preferentially forwarded based on the CoS of a queue. The forwarding decision is based on the forwarding class of the packet, as assigned by the ingress QoS policy defined for the service access point (SAP).

7705 SAR routers use QoS policies to control how QoS is handled at distinct points in the service delivery model within the device. QoS policies act like a template. Once a policy is created, it can be applied to many other similar services and ports. As an example, if there is a group of Node Bs connected to a 7705 SAR node, one QoS policy can be applied to all services of the same type, such as High-Speed Downlink Packet Access (HSDPA) offload services.

There are different types of QoS policies that cater to the different QoS needs at each point in the service delivery model. QoS policies are defined in a global context in the 7705 SAR and only take effect when the policy is applied to a relevant entity.

QoS policies are uniquely identified with a policy ID number or a policy ID name. Policy ID 1 and policy ID ‟default” are reserved for the default policy, which is used if no policy is explicitly applied.

The different QoS policies within the 7705 SAR can be divided into two main types.

• QoS policies are used for classification, queue attributes, and marking.

• Slope policies define default buffer allocations and Random Early Discard (RED) and Weighted Random Early Discard (WRED) slope definitions.

The sections that follow provide an overview of the QoS traffic management performed on the 7705 SAR.

Throughout this document, the terms ingress and egress, when describing traffic direction, are always defined relative to the fabric. For example:

• ingress direction describes packets moving into the switch fabric away from a port (on an adapter card)

• egress direction describes packets moving from the switch fabric and into a port (on an adapter card)

When combined with the terms access and network, which are port and interface modes, the four traffic directions relative to the fabric are (see Egress and Ingress Traffic Direction):

• access ingress direction describes packets coming in from customer equipment and switched toward the switch fabric

• network egress direction describes packets switched from the switch fabric into the network

• network ingress direction describes packets switched in from the network and moving toward the switch fabric

• access egress direction describes packets switched from the switch fabric toward customer equipment

Queues can be created for each forwarding class to determine the manner in which the queue output is scheduled and the type of parameters the queue accepts. The 7705 SAR supports eight forwarding classes per SAP. Default Forwarding Classes shows the default mapping of these forwarding classes in order of priority, with Network Control having the highest priority.

The traffic flows of different forwarding classes are mapped to the queues. This mapping is user-configurable. Each queue has a unique priority. Packets from high-priority queues are scheduled separately, before packets from low-priority queues. More than one forwarding class can be mapped to a single queue. In such a case, the queue type defaults to the priority of the lowest forwarding class (see Queue Type for more information on queue type). By default, the following logical order is followed:

• FC-8 - NC

• FC-7 - H1

• FC-6 - EF

• FC-5 - H2

• FC-4 - L1

• FC-3 - AF

• FC-2 - L2

• FC-1 - BE

At access ingress, traffic can be classified as unicast traffic or one of the multipoint traffic types (broadcast, multicast, or unknown (BMU)). After classification, traffic can be assigned to a queue that is configured to support one of the four traffic types, namely:

• unicast (or implicit)

• broadcast

• multicast

• unknown

The scheduler modes available on adapter cards are 4-priority and 16-priority. Which modes are supported on a particular adapter card depends on whether the adapter card is a second-generation or third-generation card.

On Gen-3 hardware, 4-priority scheduling mode is the implicit, default scheduling mode and is not user-configurable. Gen-3 platforms with a TDM block support 4-priority scheduling mode. Gen-2 adapter cards support 16-priority and 4-priority scheduling modes.

For more information on differences between Gen-2 and Gen-3 hardware related to scheduling mode QoS behavior, see QoS for Gen-3 Adapter Cards and Platforms.

For information on scheduling modes as they apply to traffic direction, refer to the following sections:

• Access Ingress Queuing and Scheduling

• Network Egress Scheduling

• Network Ingress Scheduling

• Access Egress Queuing and Scheduling

Most 7705 SAR systems are susceptible to network processor congestion if the packet rate of small packets received on a node or card exceeds the processing capacity. If a node or card receives a high rate of small packet traffic, the node or card enters overload mode. Before the introduction of intelligent discards, when a node or card entered an overload state, the network processor would randomly drop packets.

The ‟intelligent discards during overload” feature allows the network processor to discard packets according to a preset priority order. In the egress direction, intelligent discards is applied to traffic entering the card from the fabric.

Traffic is discarded in the following order: low-priority out-of-profile user traffic is discarded first, followed by high-priority out-of-profile user traffic, then low-priority in-profile user traffic, high priority in-profile user traffic, and lastly control plane traffic. In the ingress direction, intelligent discards is applied to traffic entering the card from the physical ports. Traffic is discarded in the following order: low-priority user traffic is always discarded first, followed by high-priority user traffic. This order ensures that low-priority user traffic is always the most susceptible to discards.

In the egress direction, the system differentiates between high-priority and low-priority user traffic based on the internal forwarding class and queue-type fabric header markers. In the ingress direction, the system differentiates between high-priority and low-priority user traffic based on packet header bits. Ingress Packet Priority During Overload details the classification of user traffic in the ingress direction.

Intelligent discards during overload ensures priority-based handling of traffic and helps existing traffic management implementations. It does not change how QoS-based classification, buffer management, or scheduling operates on the 7705 SAR. If the node or card is not in overload operation mode, there is no change to the way packets are handled by the network processor.

There are no commands to configure intelligent discards during overload; the feature is automatically enabled on the following cards, modules, and ports:

• 10-port 1GigE/1-port 10GigE X-Adapter card

• 2-port 10GigE (Ethernet) Adapter card (only on the 2.5 Gb/s v-port)

• 2-port 10GigE (Ethernet) module (only on the v-port)

• 8-port Gigabit Ethernet Adapter card

• 6-port Ethernet 10Gbps Adapter card

• Packet Microwave Adapter card

• 4-port SAR-H Fast Ethernet module

• 6-port SAR-M Ethernet module

• 7705 SAR-A Ethernet ports

• 7705 SAR-Ax Ethernet ports

• 7705 SAR-Wx Ethernet ports

• 7705 SAR-M Ethernet ports

• 7705 SAR-H Ethernet ports

• 7705 SAR-Hc Ethernet ports

• 7705 SAR-X Ethernet ports

Buffer space is allocated to queues based on the committed buffer space (CBS), the maximum buffer space (MBS) and availability of the resources, and the total amount of buffer space. The CBS and the MBS define the queue depth for a particular queue. The MBS represents the maximum buffer space that is allocated to a particular queue. Whether that much space can actually be allocated depends on buffer usage (that is, the number of other queues and their sizes).

Memory allocation is optimized to guarantee the CBS for each queue. The allocated queue space beyond the CBS is limited by the MBS and depends on the use of buffer space and the guarantees accorded to queues as configured in the CBS.

This section contains information on the following topics:

• Buffer Pools

• CBS and MBS Configuration

• Buffer Unit Allocation and Buffer Chaining

This section contains overview information as well as information on the following topics:

• Shaped and Unshaped SAPs

• H-QoS Example

This section provides information on per-SAP aggregate shapers for Gen-2 adapter cards and platforms. For information on Gen-3 adapter cards and platforms, see QoS for Gen-3 Adapter Cards and Platforms.

Hierarchical QoS (H-QoS) provides the 7705 SAR with the ability to shape traffic on a per-SAP basis for traffic from up to eight CoS queues associated with that SAP.

On Gen-2 hardware, the per-SAP aggregate shapers apply to access ingress and access egress traffic and operate in addition to the 16-priority scheduler, which must be used for per-SAP aggregate shaping.

The 16-priority scheduler acts as a soft policer, servicing the SAP queues in strict priority order, with conforming traffic (less than CIR) serviced prior to non-conforming traffic (between CIR and PIR). The 16-priority scheduler on its own cannot enforce a traffic limit on a per-SAP basis; to do this, per-SAP aggregate shapers are required (see H-QoS Example).

The per-SAP shapers are considered aggregate shapers because they shape traffic from the aggregate of one or more CoS queues assigned to the SAP.

Access Ingress Scheduling for 4-Priority and 16-Priority SAPs (with Per-SAP Aggregate Shapers) and Access Egress Scheduling for 4-Priority and 16-Priority SAPs (with Per-SAP Aggregate Shapers) (per Port) illustrate per-SAP aggregate shapers for access ingress and access egress, respectively. They indicate how shaped and unshaped SAPs are treated.

H-QoS is not supported on the 4-port SAR-H Fast Ethernet module.

This section provides information on per-VLAN network egress shapers for Gen-2 adapter cards and platforms. For information on Gen-3 adapter cards and platforms, see QoS for Gen-3 Adapter Cards and Platforms.

The 7705 SAR supports a set of eight network egress queues on a per-port or on a per-VLAN basis for network Ethernet ports. Eight unique per-VLAN CoS queues are created for each VLAN when a per-VLAN shaper is enabled. When using per-VLAN shaper mode, in addition to the per-VLAN eight CoS queues, there is a single set of eight queues for hosting traffic from all unshaped VLANs, if any. VLAN shapers are enabled on a per-interface basis (that is, per VLAN) when a network queue policy is assigned to the interface. See Per-VLAN Shaper Support for a list of cards and nodes that support per-VLAN shapers.

On a network port with dot1q encapsulation, shaped and unshaped VLANs can coexist. In such a scenario, each shaped VLAN has its own set of eight CoS queues and is shaped with its own configured dual-rate shaper. The remaining VLANs (that is, the unshaped VLANs) are serviced using the unshaped-if-cir rate, which is configured using the config>port>ethernet>network>egress>unshaped-if-cir command. Assigning a rate to the unshaped VLANs is required for arbitration between the shaped VLANs and the bulk (aggregate) of unshaped VLANs, where each shaped VLAN has its own shaping rate while the aggregate of the unshaped VLANs has a single rate assigned to it.

Per-VLAN shapers are supported on dot1q-encapsulated ports. They are not supported on null- or qinq-encapsulated ports.

Network Egress Shaped and Unshaped VLAN Queuing and Scheduling illustrates the queuing and scheduling blocks for network egress VLAN traffic.

This section provides information on per-customer aggregate shapers for Gen-2 adapter cards and platforms. For information on Gen-3 adapter cards and platforms, see QoS for Gen-3 Adapter Cards and Platforms.

A per-customer aggregate shaper is an aggregate shaper into which multiple SAP aggregate shapers can feed. The SAPs can be shaped at a desired rate called the Multiservice Site (MSS) aggregate rate. At ingress, SAPs that are bound to a per-customer aggregate shaper can span a whole Ethernet MDA meaning that SAPs mapped to the same MSS can reside on any port on a given Ethernet MDA.

At egress, SAPs that are bound to a per-customer aggregate shaper can only span a port. Towards the fabric at ingress and towards the port at egress, multiple per-customer aggregate shapers are shaped at their respective configured rates to ensure fair sharing of available bandwidth among different per-customer aggregate shapers. Deep ingress queuing capability ensures that traffic bursts are absorbed rather than dropped. Multi-tier shapers are based on an end-to-end backpressure mechanism that uses the following order (egress is given as an example):

• per-port egress rate (if configured), backpressures to

• per-customer aggregate shapers, backpressures to

• per-SAP aggregate shapers, backpressures to

• per-CoS queues (in the scheduling priority order)

To configure per-customer aggregate shaping, a shaper policy must be created and shaper groups must be created within that shaper policy. For access ingress per-customer aggregate shaping, a shaper policy must be assigned to an Ethernet MDA and SAPs on that Ethernet MDA must be bound to a shaper group within the shaper policy bound to that Ethernet MDA. For access egress per-customer aggregate shaping, a shaper policy must be assigned to a port and SAPs on that port must be bound to a shaper group within the shaper policy bound to that port. The unshaped SAP shaper group within the policy provides the shaper rate for all the unshaped SAPs (4-priority scheduled SAPs). For each shaped SAP, however, an ingress or egress shaper group can be specified. For more information on shaper policies, see Applying a Shaper QoS Policy and Shaper Groups.

The access ingress shaper policy is configured at the MDA level for fixed platforms. The default value for an access ingress shaper policy for each MDA and module is blank, as configured using the no shaper-policy command. On all 7705 SAR fixed platforms (with the exception of the 7705 SAR-X), when no MSS is configured, the existing access ingress aggregate rate is used as the shaper rate for the bulk of access ingress traffic. In order to use MSS, a shaper policy must be assigned to the access ingress interface of one MDA, and the shaper policy change is cascaded to all MDAs and modules in the chassis.

Before the access ingress shaper policy is assigned, the config system qos access-ingress-aggregate-rate 10000000 unshaped-sap-cir max command must be configured. Once a shaper policy is assigned to an access ingress MDA, the values configured using the access-ingress-aggregate-rate command cannot be changed.

On all 7705 SAR fixed platforms (with the exception of the 7705 SAR-X), when a shaper policy is assigned to an Ethernet MDA for access ingress aggregate shaping, it is automatically assigned to all the Ethernet MDAs in that chassis. The shaper group members contained in the shaper policy span all the Ethernet MDAs. SAPs on different Ethernet MDAs configured with the same ingress shaper group will share the shaper group rate.

Once the first MSS is configured, traffic from the designated SAPs is mapped to the MSS and shaped at the configured rate. The remainder of the traffic is then shaped according to the configured unshaped SAP rate. When a second MSS is added, SAPs that are mapped to the second MSS are shaped at the configured rate and traffic is arbitrated between the first MSS, the second MSS and unshaped SAP traffic.

In the access egress direction, the default shaper policy is assigned to each MSS-capable port. Ports that cannot support MSS are assigned a blank value, as configured using the no shaper-policy command. The default egress shaper group is assigned to each egress SAP that supports MSS. If the SAP does not support MSS, the egress SAP is assigned a blank value, as configured using the no shaper-group command.

This section provides information on QoS for hybrid ports on Gen-2 adapter cards and platforms. For information on Gen-3 adapter cards and platforms, see QoS for Gen-3 Adapter Cards and Platforms.

In the ingress direction of a hybrid port, traffic management behavior is the same as it is for access and network ports. See Access Ingress and Network Ingress.

In the egress direction of a hybrid port, access and network aggregate shapers are used to arbitrate between the bulk (aggregate) of access and network traffic flows. As shown in Hybrid Port Egress Shapers and Schedulers on Gen-2 Hardware, on the access side (above the solid line), both the access egress SAP aggregates (#1) and the unshaped SAP shaper (#2) feed into the access egress aggregate shaper (#3). On the network side (below the solid line), both the per-VLAN shapers (#4) and the unshaped interface shaper (#5) feed into the network egress aggregate shaper (#6). Then, the access and the network aggregate shapers are arbitrated in a dual-rate manner, in accordance with their respective configured committed and peak rates (#7). As a last step, the egress-rate for the port (when configured) applies backpressure to both the access and the network aggregate shapers, which apply backpressure all the way to the FC queues belonging to both access and network traffic.

As part of the hybrid port traffic management solution, access and network second-tier shapers are bound to access and network aggregate shapers, respectively. The hybrid port egress datapath can be visualized as access and network datapaths that coexist separately up until the access and network aggregate shapers at Tier 3 (#3 and #6).

In Hybrid Port Egress Shapers and Schedulers on Gen-2 Hardware, the top half is identical to access egress traffic management, where CoS queues (Tier 1) feed into either per-SAP shapers for shaped SAPs (#1) or a single second-tier shaper for all unshaped SAPs (#2). Up to the end of the second-tier, per-SAP aggregate shapers, the access egress datapath is maintained in the same manner as an Ethernet port in access mode. The same logic applies for network egress. The bottom half of the figure shows the datapath from the CoS queues to the per-VLAN shapers, which is identical to the datapath for any other Ethernet port in network mode.

The main difference between hybrid mode and access and network modes is shown when the access and the network traffic is arbitrated towards the port (Tier 3). At this point, a new set of dual-rate shapers (called shaper groups) are introduced: one shaper for the aggregate (bulk) of the access traffic (#3) and another shaper for the aggregate of the network traffic (#6) —to ensure rate-based arbitration among access and network traffic.

Depending on the use and the application, the committed rate for any one mode of flow might need to be fine-tuned to minimize delay, jitter and loss. In addition, through the use of egress-rate limiting, a fourth level of shaping can be achieved.

When egress-rate is configured (under config>port>ethernet), the following events occur:

• egress-rate applies backpressure to the access and network aggregate shapers

• as a result, the aggregate shapers apply backpressure to the per-SAP and per-VLAN aggregate shapers

  • access aggregate shapers apply backpressure to the per-SAP aggregate shapers and the unshaped SAP aggregate shaper

  • network aggregate shapers apply backpressure to the per-VLAN aggregate shapers and the unshaped VLAN aggregate shaper

• as a result, the per-SAP and per-VLAN aggregate shapers apply backpressure to their respective CoS queues

Third-generation (Gen-3) Ethernet adapter cards and Ethernet ports on Gen-3 platforms support 4-priority scheduling.

The main differences between Gen-3 hardware and Gen-2 hardware are that on Gen-3 hardware:

• SAPs are shaped (that is, no unshaped SAPs)

• SAPs and VLANs are shaped by 4-priority schedulers, not 16-priority schedulers

• 4-priority scheduling is done on a per-SAP basis

• backpressure is applied according to relative priority across VLANs and interfaces. That is, scheduling is carried out in priority order, ignoring per-VLAN and per-interface boundaries. Conforming, expedited traffic across all queues is scheduled regardless of the VLAN boundaries. After all the conforming, expedited traffic across all queues has been serviced, the servicing of conforming, best effort traffic begins.

See Scheduling Modes for a summary of scheduler mode support. For information on adapter card generations, refer to the ‟Evolution of Ethernet Adapter Cards, Modules, and Platforms” section in the 7705 SAR Interface Configuration Guide.

The following figure describes the access, network, and hybrid port scheduling behavior for Gen-3 hardware and compares it with the scheduling behavior of Gen-2 hardware.

In summary, the following updates to Gen-3 scheduling are implemented:

• enabled CIR-based shaping for:

  • per-SAP aggregate ingress and egress shapers

  • per-customer aggregate ingress and egress shapers

  • per-VLAN shaper at network egress when port is in hybrid mode

  • access and network aggregate shapers for hybrid ports

• disabled backpressure to the FC queues dependent on the relative priority among all VLAN-bound IP Interfaces at:

  • access ingress and access egress when port is in access mode

  • access ingress and access egress when port is in hybrid mode

  • network ingress

  • network egress when port is in hybrid mode

This section contains overview information as well as information on the following topics:

• Network and Network Queue QoS Policy Types

• Network QoS and Network Queue Policies on a Ring Adapter Card or Module

• Considerations for Using Ring Adapter Card or Module QoS Policies

Ports on a 2-port 10GigE (Ethernet) Adapter Card shows a simplified diagram of the ports on a 2-port 10GigE (Ethernet) Adapter card (also known as a ring adapter card). The ports can also be conceptualized the same way for a 2-port 10GigE (Ethernet) module. A ring adapter card or module has physical Ethernet ports used for Ethernet bridging in a ring network (labeled Port 1 and Port 2 in the figure). These ports are referred to as the ring ports because they connect to the Ethernet ring. The ring ports operate on the Layer 2 bridging domain side of the ring adapter card or module, as does the add/drop port, which is an internal port on the card or module.

On the Layer 3 IP domain side of a ring adapter card or module, there is a virtual port (v-port) and a fabric port. The v-port is also an internal port. Its function is to help control traffic on the IP domain side of a ring adapter card or module.

To manage ring and add/drop traffic mapping to queues in the L2 bridging domain, a ring type network QoS policy can be configured for the ring at the adapter card level (under the config>card>mda context). To manage ring and add/drop traffic queuing and scheduling in the L2 bridging domain, network queue QoS policies can be configured for the ring ports and the add-drop port.

To manage add/drop traffic classification and remarking in the L3 IP domain, ip-interface type network QoS policies can be configured for router interfaces on the v-port. To manage add/drop traffic queuing and scheduling in the L3 IP domain, network queue QoS policies can be configured for the v-port and at network ingress at the adapter card level (under the config>card>mda context).

For specific information about QoS for IPSec traffic, refer to the ‟QoS” section in the ‟IPSec” chapter in the 7705 SAR Services Guide.

The 7705 SAR provides priority and scheduling for traffic into the encryption and decryption engines on nodes that support network group encryption (NGE). This applies to traffic at network ingress or network egress.

For specific information, refer to the ‟QoS for NGE Traffic” section in the ‟Network Group Encryption” chapter in the 7705 SAR Services Guide.

Traffic classification identifies a traffic flow and maps the packets belonging to that flow to a preset forwarding class, so that the flow can receive the required special treatment. Up to eight forwarding classes are supported for traffic classification. Refer to Default Forwarding Classes for a list of these forwarding classes.

For TDM channel groups, all of the traffic is mapped to a single forwarding class. Similarly, for ATM VCs, each VC is linked to one forwarding class. On Ethernet ports and VLANs, up to eight forwarding classes can be configured based on 802.1p (dot1p) bits or DSCP bits classification. On PPP/MLPPP, FR (for Ipipes), or cHDLC SAPs, up to eight forwarding classes can be configured based on DSCP bits classification. FR (for Fpipes) and HDLC SAPs are mapped to one forwarding class.

Once the classification takes place, forwarding classes are mapped to queues as described in the sections that follow.

Once the traffic is classified to different forwarding classes, the next step is to create the ingress queues and bind forwarding classes to these queues.

There is no restriction of a one-to-one association between a forwarding class and a queue. That is, more than one forwarding class can be mapped to the same queue. This capability is beneficial in that it allows a bulk-sum amount of resources to be allocated to traffic flows of a similar nature. For example, in the case of 3G UMTS services, HSDPA and OAM traffic are both considered BE in nature. However, HSDPA traffic can be mapped to a better forwarding class (such as L2) while OAM traffic can remain mapped to a BE forwarding class. But they both can be mapped to a single queue to control the total amount of resources for the aggregate of the two flows.

A large but finite amount of memory is available for the queues. Within this memory space, many queues can be created. The queues are defined by user-configurable parameters. This flexibility and complexity is necessary in order to create services that offer optimal quality of service and is much better than a restrictive and fixed buffer implementation alternative.

Memory allocation is optimized to guarantee the CBS for each queue. The allocated queue space beyond the CBS that is bounded by the MBS depends on the usage of buffer space and existing guarantees to queues (that is, the CBS). The CBS is defaulted to 8 kilobytes (for 512 byte buffer size) or 18 kilobytes (for 2304 byte buffer size) for all access ingress queues on the 7705 SAR. With a small default queue depth (CBS) allocated for each queue, all services at full scale are guaranteed to have buffers for queuing. The default value would need to be altered to meet the requirements of a specific traffic flow or flows.

Traffic management on the 7705 SAR uses a packet-based implementation of the dual leaky bucket model. Each queue has a guaranteed space limited with CBS and a maximum depth limited with MBS. New packets are queued as they arrive. Any packet that causes the MBS to be exceeded is discarded.

The packets in the queue are serviced by two different profiled (rate-based) schedulers, the In-Profile and Out-of-Profile schedulers, where CIR traffic is scheduled before PIR traffic. These two schedulers empty the queue continuously.

For 4-priority scheduling, rate-based schedulers (CIR and PIR) are combined with queue-type schedulers (EXP or BE). For 16-priority scheduling, the rate-based schedulers are combined with the strict priority schedulers (CoS-8 queue first to CoS-1 queue last).

Access ingress scheduling is supported on the adapter cards and ports listed in Scheduling Modes Supported by Adapter Cards and Ports at Access Ingress. The supported scheduling modes are 4-priority scheduling and 16-priority scheduling. Scheduling Modes Supported by Adapter Cards and Ports at Access Ingress shows which scheduling mode each card and port supports at access ingress.

This section also contains information on the following topics:

• Profiled (Rate-based) Scheduling

• Queue-Type Scheduling

• 4-Priority Scheduling

• 4-Priority (Gen-3) Scheduling

• 16-Priority Scheduling

• Ingress Queuing and Scheduling for BMU Traffic

On the 7705 SAR, H-QoS adds second-tier (or second-level), per-SAP aggregate shapers. As shown in Access Ingress Scheduling for 4-Priority and 16-Priority SAPs (with Per-SAP Aggregate Shapers), traffic ingresses at an Ethernet SAP and is classified and mapped to up to eight different CoS queues on a per-ingress SAP basis. The aggregate rate CIR and PIR values are then used to shape the traffic. The conforming loop (aggregate CIR loop) schedules the packets out of the eight CoS queues in strict priority manner (queue priority CIRs followed by queue priority PIRs). If the aggregate CIR is crossed at any time during the scheduling operation, regardless of the per-queue CIR/PIR configuration, then the aggregate conforming loop for the SAP ends and the aggregate non-conforming loop begins.

The aggregate non-conforming loop schedules the packets out of the eight CoS queues in strict priority manner. SAPs sending traffic to the 4-priority scheduler do not have a second-tier per-SAP aggregate shaper unless traffic arbitration is desired, in which case an aggregate CIR for all the 4-priority SAPs can be configured (see Access Ingress Per-SAP Shapers Arbitration). See Per-SAP Aggregate Shapers (H-QoS) On Gen-2 Hardware for general information.

The aggregate rate limit for the per-SAP aggregate shaper is configured in the service context, using the sap>ingress>agg-rate-limit or sap>egress>agg-rate- limit command.

For per-SAP aggregate shaping on Gen-2 adapter cards, the SAP must be scheduled using a 16-priority scheduler.

The 16-priority scheduler can be used without setting an aggregate rate limit for the SAP, in which case traffic out of the SAP queues are serviced in strict priority order, the conforming traffic prior to the non-conforming traffic. Using 16-priority schedulers without a configured per-SAP aggregate shaper (PIR = maximum and CIR = 0 kb/s) might be preferred over 4-priority mode for the following reasons:

• coherent scheduler behavior across SAPs (one scheduler model)

• ease of configuration

As indicated in Access Ingress Scheduling for 4-Priority and 16-Priority SAPs (with Per-SAP Aggregate Shapers), all the traffic leaving from the shaped SAPs must be serviced using 16-priority scheduling mode.

The SAPs without an aggregate rate limit, which are called unshaped SAPs, can be scheduled using either 4-priority or 16-priority mode as one of the following:

• unshaped SAPs bound to a 4-priority scheduler

• unshaped SAPs bound to a 16-priority scheduler

The arbitration of access ingress traffic leaving the 4-priority and 16-priority schedulers and continuing towards the fabric is described in the following section.

After the traffic is scheduled, it must be sent to the fabric interface. In order to avoid congestion in the fabric and ease the effects of possible bursts, a shaper is implemented on each adapter card.

The shapers smooth out any packet bursts and ease the flow of traffic onto the fabric. The shapers use buffer space on the adapter cards and eliminate the need for large ingress buffers in the fabric.

The ingress to-fabric shapers are user-configurable. For the 7705 SAR-8 Shelf V2 and the 7705 SAR-18, the maximum rate depends on a number of factors, including platform, chassis variant, and slot type. See Configurable Ingress Shaping to Fabric (Access and Network) for details. For the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, the shapers can operate at a maximum rate of 5 Gb/s. For the 7705 SAR-X, the shapers are not user-configurable. See Fabric Shaping on the Fixed Platforms (Access and Network) for details.

After the shaping function, all of the traffic is forwarded to the fabric interface in round-robin fashion, one packet at a time, from every access ingress adapter card.

The use of fabric profiles allows the ingress (to the fabric) shapers to be user-configurable for access ingress and network ingress traffic.

For the 7705 SAR-8 Shelf V2 and 7705 SAR-18, the maximum rates are:

• 2.5 Gb/s for the 7705 SAR-8 Shelf V2 (all 6 MDA slots)

• 10 Gb/s for the 7705 SAR-8 Shelf V2 (MDA slots 1 and 2)

• 1 Gb/s or 2.5 Gb/s for the 7705 SAR-18 (12 MDA slots)

• 10 Gb/s for the 7705 SAR-18 (4 XMDA slots)

For information about fabric shapers on the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-X, see Fabric Shaping on the Fixed Platforms (Access and Network).

By allowing a rate of 1 Gb/s or higher to be configured from any adapter card to the fabric, the fabric may become congested. Therefore, the collection and display of fabric statistics are provided. These statistics report about the fabric traffic flow and potential discards. See the 7705 SAR Interface Configuration Guide, ‟Configuring Adapter Card Fabric Statistics”, ‟Configuration Command Reference”, and ‟Show, Monitor, Clear, and Debug Command Reference” for information about how to configure, show, and monitor fabric statistics on an adapter card.

The ingress buffers for a card are much larger than the ingress buffers for the fabric; therefore, it is advantageous to use the larger card buffers for ingress shaping. In order to use the ingress card buffers and have much more granular control over traffic, two fabric profile modes are supported, per-destination mode and aggregate mode. Both modes offer shaping towards the fabric from an adapter card, but per-destination shapers offer the maximum flexibility by precisely controlling the amount of traffic to each destination card at a user-defined rate. Aggregate mode is used for simpler deployments, where the amount of traffic flowing to a destination adapter card is not controlled.

The default mode of operation for the 7705 SAR is set to aggregate, and the fixed aggregate rate of 200 Mb/s is set for both access ingress and network ingress traffic. Therefore, in a default configuration, each adapter card can switch up to 200 Mb/s of access ingress and network ingress traffic towards the fabric.

All the switched traffic can be destined for a single adapter card or it can be spread among multiple adapter cards. For higher-bandwidth applications, a network traffic analysis is recommended to determine which shaper rates would best suit the application and traffic patterns of a particular environment.

The to-fabric shapers are provided on the 7705 SAR to ensure adequate use of ingress buffers in case of congestion. With the ingress shapers, the large ingress card buffers can be configured to absorb bursty traffic and pace the traffic for better use of resources.

For example, if the average access ingress traffic bandwidth for an adapter card is 400 Mb/s and the peak bandwidth is 800 Mb/s, the rate of the to-fabric shapers can be configured to be 400 Mb/s. This allows the bursty ingress traffic to be paced by absorbing the bursty traffic after being shaped at 400 Mb/s. The initial burst is absorbed at the adapter card where the bursty traffic ingresses the 7705 SAR. The ingress buffers are used to absorb the burst and the fabric buffers are not exhausted by any single adapter card. The same example applies to network ingress traffic.

Fabric Profile Modes Options and Capabilities summarizes the different capabilities offered by the two modes.

Fabric Shapers in Per Destination Mode and Fabric Shapers in Aggregate Mode illustrate the functionality of fabric shapers in per-destination mode and aggregate mode, respectively.

Referring to Fabric Shapers in Per Destination Mode, once the per-destination prioritization and scheduling takes place, as described in previous sections in this chapter, the per-destination adapter card shapers take effect. With per destination shapers, the maximum amount of bandwidth that each destination adapter card can receive from the fabric can be controlled. For example, the maximum amount of bandwidth that adapter card 1 can switch to the remaining adapter cards, as well as the amount of bandwidth switched back to adapter card 1, can be configured at a set rate.

Fabric Shapers in Aggregate Mode illustrates the functionality of fabric shapers in aggregate mode. Once the policing, classification, queuing and per-destination based priority queuing takes place, as described in previous sections in this chapter, the aggregate mode adapter card shapers take effect. In aggregate mode, the aggregate of all the access ingress and network ingress traffic is shaped at a user-configured rate regardless of the destination adapter card.

Mixing different fabric shaper modes within the same chassis and on the same adapter card is not recommended; however, it is supported. As an example, an 8-port Gigabit Ethernet Adapter card in a 7705 SAR-18 can be configured for aggregate mode for access ingress and for per-destination mode for network ingress. The same chassis can also contain an adapter card (for example, the 32-port T1/E1 ASAP Adapter card) that is configured for per-destination mode for all traffic. This setup is shown in the following example.

The 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, and 7705 SAR-Wx support user-configurable fabric shapers at rates of up to 5 Gb/s for access ingress and network ingress traffic. The fabric interface on these nodes is a shared resource between both traffic types, and one buffer pool serves all MDAs (ports).

These nodes do not support fabric profiles; instead, they have a single aggregate rate limit for restricting access traffic into the fabric and a single aggregate rate limit for restricting network traffic into the fabric. These limits apply to all MDAs. Both access ingress and network ingress traffic can be configured to shaping rates of between 1 kb/s and 5 Gb/s. The default rate for access ingress traffic is 500 Mb/s. The default rate for network ingress traffic is 2 Gb/s. Statistics can be viewed for aggregate access and network traffic flow through the fabric and possible discards.

The 7705 SAR-X fabric shaper rate is not configurable for access ingress or network ingress traffic, and is set to the maximum rate for the platform. There are three buffer pools on the 7705 SAR-X, one for each MDA (block of ports).

The 7705 SAR uses an Ethernet-based fabric. Each packet that is sent to the fabric is equipped with a fabric header that contains its specific CoS requirement. Since all of the packets switched across the fabric are already classified, queued, scheduled and marked according to the desired QoS parameters, each of these packets has been passed through the Traffic Management (TM) block on an adapter card, or the Control and Switching Module (CSM) in the case of control packets. Therefore, each packet arrives at the fabric having been already scheduled for optimal flow. The function of the fabric is to switch each packet through to the appropriate destination adapter card, or CSM in the case of control packets, in an efficient manner.

Since the traffic is shaped at a certain rate by the ingress adapter card (that is, bursts are smoothed by the traffic management function), minimal buffering should be needed on the switch fabric. However, the buffer space allocation and usage is in accordance with the priorities at the ingress adapter card. As is the case with schedulers at the adapter cards, there are two priorities supported on the switch fabric. The switch fabric serves the traffic in the following priority order:

1. Expedited

2. Best Effort

BMU traffic at network egress is handled in the same way as unicast traffic in terms of scheduling, queuing, or port-level shaping. Both unicast and BMU traffic are mapped to queues as per the FC markings. Traffic from these queues, whether unicast or BMU, is scheduled according to user-configured rates. Port-level shapers treat all the queues identically, regardless of traffic type.

After traffic is switched through the fabric from one or several access ingress adapter cards to a network egress adapter card, queuing-level aggregation on a per-forwarding-class basis is performed on all of the received packets.

An adapter card that is used for network egress can receive—and will likely receive—packets from multiple adapter cards that are configured for access ingress operations, and from the CSM. Adapter cards that are configured for network access permit user configuration of queues and the association of forwarding classes to the queues. These are the same configuration principles that are used for adapter cards that are configured for access ingress connectivity. Like access ingress, more than one forwarding class can share the same queue.

Aggregation of different forwarding classes under queues takes place for each bundle or port. If a port is a member of a bundle, such as a Multilink Point-to-Point Protocol (MLPPP) bundle, then the aggregation and queuing is implemented for the entire bundle. If a port is a standalone port, that is, not a member of bundle, then the queuing takes place for the port.

Network egress scheduling is supported on the adapter cards and ports listed in the following table. The supported scheduling modes are 4-priority and 16-priority. The table shows which scheduling mode each card and port supports at network egress.

This section also contains information about the following topics:

• Network Egress 4-Priority Scheduling

• Network Egress 4-Priority (Gen-3) Scheduling

• Network Egress 16-Priority Scheduling

All the network egress traffic is shaped at the bundle or interface rate. An interface may not necessarily correspond directly to a port, and an interface could be a sub-channel of a port. As an example, Fast Ethernet could be the choice of network egress, but the leased bandwidth could still be a fraction of the port speed. In this case, it is possible to shape at the interface rate of 15 Mb/s, for example.

The same also applies to MLPPP bundles. The shaping takes place per MLPPP bundle, and the traffic is shaped at the aggregate rate of the MLPPP bundle.

Hybrid ports use a third-tier, dual-rate aggregate shaper to provide arbitration between the bulk of access and network egress traffic flows. For details, see QoS for Hybrid Ports on Gen-2 Hardware.

Network egress VLAN traffic uses second-tier (or second-level), per-VLAN shapers to prepare network egress traffic for arbitration with the aggregate of the unshaped VLAN shaper. All the shaped VLAN shapers are arbitrated with one unshaped VLAN shaper.

As shown in Network Egress Shaped and Unshaped VLAN Queuing and Scheduling, traffic from the fabric flows to one or more VLANs, where it is classified and mapped to up to eight different CoS queues on a per-VLAN basis. The VLANs can be shaped or unshaped. Each shaped VLAN has its own set of CoS queues. The aggregate of unshaped VLANs uses the same set of CoS queues (that is, one set of queues for all unshaped VLANs).

For more information, see Per-VLAN Network Egress Shapers and Shaped and Unshaped VLANs.

Because the per-VLAN shapers are dual-rate shapers, their aggregate rate CIR and PIR values shape the traffic, as follows.

• The conforming, in-profile loop (aggregate CIR loop) schedules the packets out of the eight CoS queues in strict priority manner (queue priority CIRs followed by queue priority PIRs).

• If the aggregate CIR is crossed at any time during the scheduling operation, regardless of the per-queue CIR/PIR configuration, then the aggregate conforming loop for the VLAN ends and the aggregate non-conforming loop (out-of-profile) begins.

• The aggregate non-conforming loop schedules the packets out of the eight CoS queues in strict priority manner.

A shaped VLAN configured with default aggregate rate limits (PIR = maximum and CIR = 0 kb/s) is equivalent to an unshaped VLAN except that its traffic flows through a per-VLAN shaper rather than getting combined with the bulk (aggregate) of the unshaped VLANs. Using a shaped VLAN in this way (default rate limits) might be preferred over using an unshaped VLAN for the following reasons:

• coherent scheduler behavior across VLANs (that is, the use of only one scheduler model)

• ease of configuration

• higher throughput, as each shaped VLAN gets to transmit one packet at each pass of the out-of-profile scheduler as opposed to one packet from the aggregate of unshaped VLAN queues

The arbitration of shaped and unshaped VLAN traffic at the third-tier shaper is described in the following section.

The EXP bit settings can be marked at network egress. The EXP bit markings of the forwarding class are used for this purpose. The tunnel and pseudowire EXP bits are marked to the forwarding class value.

The default network egress QoS marking settings are given in Default Network QoS Policy Egress Marking .

Network ingress traffic originates from a network egress port located on another interworking device, such as a 7710 or 7750 Service Router or another 7705 SAR, and flows from the network toward the fabric in the 7705 SAR.

The ingress MPLS packets can be mapped to forwarding classes based on EXP bits that are part of the headers in the MPLS packets. These EXP bits are used across the network to ensure an end-to-end network-wide QoS offering. With pseudowire services, there are two labels, one for the MPLS tunnel and one for the pseudowire. Mapping is performed using the EXP values from the outer tunnel MPLS label. This ensures that the EXP bit settings, which may have been altered along the path by the tandem label switch routers (LSRs), are used to identify the forwarding class of the encapsulated traffic.

Ingress GRE and IP packets are mapped to forwarding classes based on DSCP bit settings of the IP header. GRE tunnels are not supported for IPv6; therefore, DSCP bit classification of GRE packets is only supported for IPv4. DSCP bit classification of IP packets is supported for both IPv4 and IPv6.

Untrusted traffic uses multi-field classification (MFC), where the traffic is classified based on any IP criteria currently supported by the 7705 SAR filter policies; for example, source and destination IP address, source and destination port, whether or not the packet is fragmented, ICMP code, and TCP state. For information on MFC, refer to the 7705 SAR Router Configuration Guide, ‟Multi-field Classification (MFC)” and ‟IP, MAC, and VLAN Filter Entry Commands”.

Network ingress traffic can be classified in up to eight different forwarding classes, which are served by 16 queues (eight queues for unicast traffic and eight queues for multicast (BMU) traffic). Each queue serves at least one of the eight forwarding classes that are identified by the incoming EXP bits. These queues are automatically created by the 7705 SAR. Default Network Ingress QoS Policy shows the default network QoS policy for the 16 CoS queues.

The value for CBS and MBS is a percentage of the size of the buffer pool for the adapter card. MBS can be shared across queues, which allows overbooking to occur.

Network ingress scheduling is supported on the adapter cards and ports listed in Scheduling Modes Supported by Adapter Cards and Ports at Network Ingress. The supported scheduling modes are 4-priority and 16-priority. Scheduling Modes Supported by Adapter Cards and Ports at Network Ingress shows which scheduling mode each card and port supports at network ingress.

This section also contains information on the following topics:

• Network Ingress 4-Priority Scheduling

• Network Ingress 4-Priority (Gen-3) Scheduling

• Network Ingress 16-Priority Scheduling

After the traffic is scheduled, it must be sent to the fabric interface. In order to avoid congestion in the fabric and ease the effects of possible bursts, a shaper is implemented on each adapter card.

Network ingress shaping to the fabric operates in a similar fashion to access ingress shaping to the fabric. See Ingress Shaping to Fabric (Access and Network) for details.

Configuring network ingress shapers to the fabric is similar to configuring access ingress shapers to the fabric.

The ingress to-fabric shapers are user-configurable. For the 7705 SAR-8 Shelf V2 and the 7705 SAR-18, the maximum rate depends on a number of factors, including platform, chassis variant, and slot type. See Configurable Ingress Shaping to Fabric (Access and Network) for details.

For information about fabric shapers on the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, see Fabric Shaping on the Fixed Platforms (Access and Network). The 7705 SAR-X does not support configurable network ingress shapers.

The 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, and 7705 SAR-Wx support user-configurable fabric shapers at rates of up to 5 Gb/s for access ingress traffic and network ingress traffic.

On the 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, and 7705 SAR-Wx, network ingress shapers to the fabric operate similarly to access ingress shapers to the fabric. The 7705 SAR-X does not support configurable network ingress shapers. See Fabric Shaping on the Fixed Platforms (Access and Network) for more information.

The following sections discuss the queuing and scheduling of access egress traffic, which is traffic that egresses the fabric on the access side:

• BMU Traffic Access Egress Queuing and Scheduling

• ATM Access Egress Queuing and Scheduling

• Ethernet Access Egress Queuing and Scheduling

Access egress scheduling takes place at the native traffic layer. As an example, once the ATM pseudowire payload is delivered from the network ingress to the access egress, the playback of the ATM cells to the appropriate ATM SAP is done according to ATM traffic management specifications.

Access egress scheduling is supported on the adapter cards and ports listed in the following table. The supported scheduling modes are 4-priority and 16-priority. The table shows which scheduling mode each card and port supports at access egress.

Per-SAP aggregate shapers in the access egress direction operate in a similar fashion to aggregate shapers for access ingress, except that egress traffic goes through the schedulers to the egress port shaper instead of through the schedulers to the fabric port as in the access ingress case. For information on how access egress and access ingress per-SAP shaping is similar, see Access Ingress Per-SAP Aggregate Shapers (Access Ingress H-QoS). For general information on per-SAP shapers, see Per-SAP Aggregate Shapers (H-QoS) On Gen-2 Hardware.

The arbitration of access egress traffic from the per-SAP aggregate shapers to the schedulers is described in the following section.

Hybrid ports use a third-tier, dual-rate aggregate shaper to provide arbitration between the bulk of access and network egress traffic flows. For details, see QoS for Hybrid Ports on Gen-2 Hardware.

The adapter cards and ports that support 4-priority (Gen-3) scheduling for access egress traffic are listed in Scheduling Modes Supported by Adapter Cards and Ports at Access Egress. See QoS for Gen-3 Adapter Cards and Platforms for details.

At access egress, where the network-wide QoS boundary is reached, there may be a requirement to mark or re-mark the CoS indicators to match customer requirements. Dot1p and DSCP marking and re-marking is supported at Ethernet access egress.

Similar to access ingress for Ethernet, DSCP marking or re-marking is supported for untagged, single-tagged, or double-tagged Ethernet frames.

On Ipipe SAPs over an Ethernet VLAN, both dot1p and DSCP marking and re-marking is supported at access egress. On Ipipe SAPs over PPP/MLPPP, DSCP marking and re-marking is supported at access egress. DSCP re-marking is supported for Ipipes using FR or cHDLC SAPS at the access egress.

Packet byte offset (PBO), or internal headerless rate, allows 7705 SAR schedulers to operate on a modified packet size by adding or subtracting a certain number of bytes. The actual packet size remains the same but schedulers take into account the modified size as opposed to the actual size of the packet. One of the main uses of the packet byte offset feature is to allow scheduling, at access ingress, to be carried out on the received packet size without taking into account service (for example, PW, MPLS) or internal overhead. Transport providers who sell bandwidth to customers typically need the 7705 SAR shapers/schedulers to only take into account the received packet size without the added overhead in order to accurately calculate the bandwidth they need to provide to their customers. Packet byte offset addresses this requirement. Another common use is at egress where port shapers can take into account four additional bytes, associated with Ethernet FCS.

Packet byte offset is configured under QoS profiles. Packet size modification might be desired to accommodate inclusion or exclusion of certain headers or even fields of headers during the scheduling operation. The packet size that the schedulers take into account is altered to accommodate or omit the desired number of bytes. Both addition and subtraction options are supported by the packet-byte-offset command. The actual packet size is not modified by the command; only the size used by ingress or egress schedulers is changed. The scheduling rates are affected by the offset, as well as the statistics (accounting) associated with the queue. Packet byte offset does not affect port-level and service-level statistics. It only affects the queue statistics.

When a QoS policy configured with packet byte offset is applied to a SAP or network interface, all the octet counters and statistics operate and report based on the new adjusted value. If configured, per-SAP aggregate shapers and per-customer aggregate shapers also operate on the adjusted packet sizes. The only exceptions to this rule are port shapers. The egress port shapers do not take the adjusted packet size into account but operate only on the final packet size.

The following table shows PBO support on the 7705 SAR.

7705 SAR QoS policies are applied on service ingress, service egress, and network interfaces. The service ingress and service egress points may be considered as the network QoS boundaries for the service being provided.

The QoS policies define:

• classification rules for how traffic is mapped to forwarding classes

• how forwarding classes are aggregated under queues

• the queue parameters used for policing, shaping, and buffer allocation

• QoS marking/interpretation

There are several types of QoS policies (see QoS Policy Types and Descriptions for summaries and references to details):

• service ingress (also known as access ingress)

• service egress (also known as access egress)

• MC-MLPPP SAP egress

• network (for ingress and egress and ring)

  • IP interface type policy for network ingress and egress

  • ring type policy for Ethernet bridging domain on a ring adapter card

• network queue (for ingress and egress)

• slope

• ATM traffic descriptor profile

• fabric profile

• shaper

  Note: The terms access ingress/egress and service ingress/egress are interchangeable. The previous sections used the term access, and the sections that follow use the term service.

Service ingress QoS policies are applied to the customer-facing Service Access Points (SAPs) and map traffic to forwarding class queues on ingress. The mapping of traffic to queues can be based on combinations of customer QoS marking (dot1p bits and DSCP values). The number of forwarding class queues for ingress traffic and the queue characteristics are defined within the policy. There can be up to eight ingress forwarding class queues in the policy, one for each forwarding class.

Within a service ingress QoS policy, up to three queues per forwarding class can be used for multipoint traffic for multipoint services. Multipoint traffic consists of broadcast, multicast, and unknown (BMU) traffic types. For VPLS, four types of forwarding are supported (which are not to be confused with forwarding classes): unicast, broadcast, multicast, and unknown. The BMU types are flooded to all destinations within the service, while the unicast forwarding type is handled in a point-to-point fashion within the service.

Service ingress QoS policies on the 7705 SAR permits flexible arrangement of these queues. For example, more than one FC can be mapped to a single queue, both unicast and multipoint (BMU) traffic can be mapped to a single queue, or unicast and BMU traffic can be mapped to separate queues. Therefore, customers are not limited to the default configurations that are described in this guide.

Service egress QoS policies are applied to egress SAPs and provide the configurations needed to map forwarding classes to service egress queues. Each service can have up to eight queues configured, since a service may require multiple forwarding classes. A service egress QoS policy also defines how to re-mark dot1p bits and DSCP values of the customer traffic in native format based on the forwarding class of the customer traffic.

Network ingress and egress QoS policies are applied to network interfaces. On ingress for traffic received from the network, the policy maps incoming EXP values to forwarding classes and profile states. On egress, the policy maps forwarding classes and profile states to EXP values for traffic to be transmitted into the network.

On the network side, there are two types of QoS policies: network and network queue (see QoS Policy Types and Descriptions ). The network type of QoS policy is applied to the network interface under the config>router>interface command and contains the EXP marking rules for both ingress and egress. The network queue type of QoS policy defines all of the internal settings; that is, how the queues, or sets of queues (for ingress), are set up and used per physical port on egress and per adapter card for ingress.

A ring type network policy can be applied to the ring ports and the add/drop port on a ring adapter card. The policy is created under the config>qos>network command, and applied at the adapter card level under the config>card>mda command. The policy maps each dot1p value to a queue and a profile state.

If GRE or IP tunneling is enabled, policy mapping can be set up to use DSCP bits.

Network queue policies are applied on egress to network ports and channels and on ingress to adapter cards. The policies define the forwarding class queue characteristics for these entities.

Service ingress, service egress, and network QoS policies are defined with a scope of either template or exclusive. Template policies can be applied to multiple SAPs or interfaces, whereas exclusive policies can only be applied to a single entity.

One service ingress QoS policy and one service egress QoS policy can be applied to a specific SAP. One network QoS policy can be applied to a specific interface. A network QoS policy defines both ingress and egress behavior. If no QoS policy is explicitly applied to a SAP or network interface, a default QoS policy is applied.

QoS Policy Types and Descriptions provides a summary of the major functions performed by the QoS policies.

Service ingress QoS policies define ingress service forwarding class queues and map flows to those queues. When a service ingress QoS policy is created, it always has a default ingress traffic queue defined that cannot be deleted. These queues exist within the definition of the policy. The queues only get created when the policy is applied to a SAP.

In the simplest service ingress QoS policy, all traffic is treated as a single flow and mapped to a single queue. The required elements to define a service ingress QoS policy are:

• a unique service ingress QoS policy ID

• a QoS policy scope of template or exclusive

• at least one default ingress forwarding class queue. The parameters that can be configured for a queue are discussed in Network and Service QoS Queue Parameters.

Optional service ingress QoS policy elements include:

• additional ingress queues up to a total of eight

• QoS policy match criteria to map packets to a forwarding class

Each queue can have unique queue parameters to allow individual policing and rate shaping of the flow mapped to the forwarding class. Traffic Queuing Model for Three Queues and Three Classes depicts service traffic being classified into three different forwarding class queues.

Mapping flows to forwarding classes is controlled by comparing each packet to the match criteria in the QoS policy. The ingress packet classification to forwarding class and enqueuing priority is subject to a classification hierarchy. Each type of classification rule is interpreted with a specific priority in the hierarchy.

Forwarding Class and Enqueuing Priority Classification Hierarchy Based on Rule Type is given as an example for an Ethernet SAP (that is, a SAP defined over a whole Ethernet port, over a single VLAN, or over QinQ VLANs). It lists the classification rules in the order in which they are evaluated.

The enqueuing priority is specified as part of the classification rule and is set to high or low. The enqueuing priority relates to the forwarding class queue’s high-priority-only allocation, where only packets with a high enqueuing priority are accepted into the queue once the queue’s depth reaches the defined threshold. See High-Priority-Only Buffers.

The mapping of ingress traffic to a forwarding class based on dot1p or DSCP bits is optional. The default service ingress policy is implicitly applied to all SAPs that do not explicitly have another service ingress policy assigned. The characteristics of the default policy are listed in Default Service Ingress Policy ID 1 Definition .

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

• per-service egress shaping, soft-policing capabilities

• more granular, more fair scheduling per service into the access network

• per-service statistics for forwarded and discarded service packets

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

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

Service egress QoS policies define egress service queues and map forwarding class flows to queues. In the simplest service egress QoS policy, all forwarding classes are treated as a single flow and mapped to a single queue.

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

• a unique service egress QoS policy ID

• a QoS policy scope of template or exclusive

• at least one defined default queue. The parameters that can be configured for a queue are discussed in Network and Service QoS Queue Parameters.

Optional service egress QoS policy elements include:

• additional queues, up to a total of eight separate queues

• dot1p priority and DSCP value re-marking based on forwarding class

Each queue in a policy is associated with one or more of the supported forwarding classes. Each queue can have its individual queue parameters, allowing individual rate shaping of the forwarding classes mapped to the queue. More complex service queuing models are supported in the 7705 SAR where each forwarding class is associated with a dedicated queue.

The forwarding class determination per service egress packet is determined at ingress. If the packet ingressed the service on the same 7705 SAR router, the service ingress classification rules determine the forwarding class of the packet. If the packet was received over a service transport tunnel, the forwarding class is marked in the tunnel transport encapsulation.

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

The default service egress policy is applied to all SAPs that do not have another service egress policy explicitly assigned. The characteristics of the default policy are listed in Default Service Egress Policy ID 1 Definition .

SAPs running MC-MLPPP have their own SAP egress QoS policies that differ from standard policies. Unlike standard SAP policies, MC-MLPPP SAP egress policies do not contain queue types, CIR, CIR adaptation rules, or dot1p re-marking.

Standard and MC-MLPPP SAP egress policies can never have the same policy ID except when the policy ID is 1 (default). Standard SAP egress QoS policies cannot be applied to SAPs running MC-MLPPP. Similarly, MC-MLPPP SAP egress QoS policies cannot be applied to standard SAPs. The default policy can be applied to both MC-MLPPP and other SAPs. It will remain the default policy regardless of SAP type.

MC-MLPPP on the 7705 SAR supports scheduling based on multi-class implementation. Instead of the standard profiled queue-type scheduling, an MC-MLPPP encapsulated access port performs class-based traffic servicing.

The four MC-MLPPP classes are scheduled in a strict priority fashion, as shown in MC-MLPPP Class Priorities.

For example, if a packet is sent to an MC-MLPPP class 3 queue and all other queues are empty, the 7705 SAR fragments the packet according to the configured fragment size and begins sending the fragments. If a new packet is sent to an MC-MLPPP class 2 queue, the 7705 SAR finishes sending any fragments of the class 3 packet that are on the wire, then holds back the remaining fragments in order to service the higher-priority packet. The fragments of the first packet remain at the top of the class 3 queue. For packets of the same class, MC-MLPPP class queues operate on a first-in, first-out basis.

The user configures the required number of MLPPP classes to use on a bundle. The forwarding class of the packet, as determined by the ingress QoS classification, is used to determine the MLPPP class for the packet. The mapping of forwarding class to MLPPP class is a function of the user-configurable number of MLPPP classes. The default mapping for a 4-class, 3-class, and 2-class MLPPP bundle is shown in Packet Forwarding Class to MLPPP Class Mapping .

If one or more forwarding classes are mapped to a queue, the scheduling priority of the queue is based on the lowest forwarding class mapped to it. For example, if forwarding classes 0 and 7 are mapped to a queue, the queue is serviced by MC-MLPPP class 3 in a 4-class bundle model.

The QoS mechanisms within the 7705 SAR are specialized for the type of traffic on the interface. For customer interfaces, there is service ingress and service egress traffic, and for network interfaces, there is network ingress and network egress traffic.

The 7705 SAR uses QoS policies applied to a SAP for a service or to a network port to define the queuing, queue attributes, and QoS marking/interpretation.

The 7705 SAR supports the following types of network and service QoS policies:

• Network QoS Policies

• Network Queue QoS Policies

• Service Ingress QoS Policies (described previously)

• Service Egress QoS Policies (described previously)

  Note: Queuing parameters are the same for both network and service QoS policies. See Network and Service QoS Queue Parameters.

As part of 7705 SAR queue management, policies for WRED and/or RED queue management (also known as congestion management or buffer management) to manage the queue depths can be enabled at both access and network ports and associated with both ingress and egress queues. WRED policies can also be enabled on bridged domain (ring) ports.

Without WRED and RED, once a queue reaches its maximum fill size, the queue discards any new packets arriving at the queue (tail drop).

WRED and RED policies prevent a queue from reaching its maximum size by starting random discards once the queue reaches a user-configured threshold value. This avoids the impact of discarding all the new incoming packets. By starting random discards at this threshold, customer devices at an end-system may be adjusted to the available bandwidth.

As an example, TCP has built-in mechanisms to adjust for packet drops. TCP-based flows lower the transmission rate when some of the packets fail to reach the far end. This mode of operation provides a much better way of dealing with congestion than dropping all the packets after the whole queue space is depleted.

The WRED and RED curve algorithms are based on two user-configurable thresholds (minThreshold and maxThreshold) and a discard probability factor (maxDProbability) (see WRED for High-Priority and Low-Priority Traffic on the Same Queue). The minThreshold (minT) indicates the level when where discards start and the discard probability is zero. The maxThreshold (maxT) is indicates the level where the discard probability reaches its maximum value. Beyond this the maxT level, all newly arriving packets are discarded. The steepness of the slope between minT and maxT is derived from the maxDProbability (maxDP). Thus, the maxDP indicates the random discard probability at the maxT level.

The main difference between WRED and RED is that with WRED, there can be more than one curve managing the fill rate of the same queue.

WRED slope curves can run against high-priority and low-priority traffic separately for ingress and egress queues. This allows the flexibility to treat low-priority and high-priority traffic differently. WRED slope policies are used to configure the minT, maxT and maxDP values, instead of configuring these thresholds against every queue. It is the slope policies that are then applied to individual queues. Thus, WRED slope policies affect how and when the high-priority and low-priority traffic is discarded within the same queue.

Referring to WRED for High-Priority and Low-Priority Traffic on the Same Queue, one WRED slope curve can manage discards on high-priority traffic and another WRED slope curve can manage discards on low-priority traffic. The minT, maxT and maxDP values configured for high-priority and low-priority traffic can be different and can start discarding traffic at different thresholds. Use the start-avr, max-avr, and max-prob commands to set the minThreshold, maxThreshold, and maxDProbabilty values, respectively.

The formula to calculate the average queue size is:

average queue size = (previous average ✕ (1 – 1/2^TAF)) + (current queue size ✕ 1/2^TAF)

The Time Average Factor (TAF) is the exponential weight factor used in calculating the average queue size. The time_average_factor parameter is not user-configurable and is set to a system-wide default value of 3. By locking TAF to a static value of 3, the average queue size closely tracks the current queue size so that WRED can respond quickly to long queues.

Traffic descriptor profiles capture the cell arrival pattern for resource allocation. Source traffic descriptors for an ATM connection include at least one of the following:

• Sustained Information Rate (SIR)

• Peak Information Rate (PIR)

• Minimum Information Rate (MIR)

• Maximum Burst Size (MBS)

QoS traffic descriptor profiles are applied on ATM VLL (Apipe) SAPs.

Fabric profiles allow access and network ingress to-fabric shapers to have user-configurable rates of switching throughput from an adapter card towards the fabric.

Two fabric profile modes are supported: per-destination mode and aggregate mode. Both modes offer shaping towards the fabric from an adapter card, but per-destination shapers offer the maximum flexibility by precisely controlling the amount of traffic to each destination card at a user-defined rate.

For the 7705 SAR-8 Shelf V2 and the 7705 SAR-18, the maximum rate depends on a number of factors, including platform, chassis variant, and slot type. See Configurable Ingress Shaping to Fabric (Access and Network) for details. For information about fabric shaping on the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, see Fabric Shaping on the Fixed Platforms (Access and Network).

Shaper policies define dual-rate shaper parameters that control access or network traffic by providing tier-3 aggregate shaping to:

• shaped and unshaped SAP traffic for access ingress flows

• shaped and unshaped SAP traffic for access egress flows

• shaped and unshaped VLAN traffic for network egress flows

See Per-SAP Aggregate Shapers (H-QoS) On Gen-2 Hardware and Per-VLAN Network Egress Shapers for details on per-SAP and per-VLAN shapers.

Services are configured with default QoS policies. Additional policies must be explicitly created and associated. There is one default service ingress QoS policy, one default service egress QoS policy, and one default network QoS policy. Only one ingress QoS policy and one egress QoS policy can be applied to a SAP or network port.

When you create a new QoS policy, default values are provided for most parameters with the exception of the policy ID and queue ID values, descriptions, and the default action queue assignment. Each policy has a scope, default action, a description, and at least one queue. The queue is associated with a forwarding class.

All QoS policy parameters can be configured in the CLI. QoS policies can be applied to the following service types:

• Epipe — both ingress and egress policies are supported on an Epipe SAP

• Apipe — both ingress and egress policies are supported on an Apipe SAP

• Cpipe — only ingress policies are supported on a Cpipe SAP

• Fpipe — both ingress and egress policies are supported on an Fpipe SAP

• Hpipe — both ingress and egress policies are supported on an Hpipe SAP

• Ipipe — both ingress and egress policies are supported on an Ipipe SAP

QoS policies can be applied to the following network entities:

• network ingress interface

• network egress interface

Default QoS policies treat all traffic with equal priority and allow an equal chance of transmission (Best Effort forwarding class) and an equal chance of being dropped during periods of congestion. QoS prioritizes traffic according to the forwarding class and uses congestion management to control access ingress, access egress, and network traffic with queuing according to priority.