World Wide Packets 

Service Assurance Hard QoS

LightningEdge® QoS Capabilities

The LightningEdge solution supports a very flexible QoS implementation that permits a wide range of traffic types and rates to be delivered over a single access infrastructure without interference or degradation.

LightningEdge QoS Architecture

Flexible QoS Service Mapping with parameters identifying a traffic flow, a service or a subscriber
Service Level that links traffic parameters with subscriber SLA
Congestion Handling Multi-level schedulers that provide strict CIR and weighted EIR and reduce latency and jitter
Layer 2 and 3 traffic profiling and remarking
Automated Service Provisioning LE-NS Service Provisioning provides complete automation of provisioning of services, including QoS policies

LightningEdge QoS is implemented by a robust multi-level architecture that addresses the creation, implementation, enforcement, and monitoring of all QoS parameters through the entire access network. The main parts of the LightningEdge QoS architecture include:

  • Flexible QoS implementation
  • Sophisticated congestion handling
  • Automated service provisioning

The following sections examine and explain all the components of the LightningEdge QoS architecture in more detail.

Flexible QoS Implementation

The LightningEdge Quality of Service solution relies on two key components:

  • Service Mapping – defines the traffic flow, and associates it to a service-level.
  • Service Level – represents one or more hardware queues that provide dedicated resources to the traffic.

Service Mapping

Traffic ingressing and egressing a LightningEdge device can contain one or many traffic flows. Service Mapping enables the network operator to define parameters that permit the identification of specific traffic flows. LightningEdge platforms support 512 Service Mapping definitions that can use any of the following parameters:

  • VLAN
  • Source port or source link aggregation group
  • Destination port or destination link aggregation group
  • IEEE 802.1D priority
  • MPLS Virtual Circuit (VC) Label
  • TCP or UDP port
  • Differentiated Services Code Point (DSCP)

Service Level

A Service Level defines a specific set of QoS parameters and the necessary LightningEdge device resources that will be required to support the Service Level. A LightningEdge device supports 128 Service Levels. Some of the 128 Service Levels are pre-defined to implement basic IEEE 802.1D priority handling. One or several Service Mappings can be associated with each of the 128 Service Levels. Service Level definitions are unidirectional, enabling implementation of both symmetrical and asymmetrical Service Mapping.

Figure 3. CIR and EIR Definition

The following parameters are used to define a Service Level:

  • Egress Port – Not specifying an egress port enables QoS for multicast traffic. This is particularly useful to protect Video over IP.
  • Service Level Name
  • Committed Information Rate (CIR) – When configured, this rate will be serviced by the LightningEdge devices in a rigorous and strict fashion, enabling the device to absolutely guarantee the availability of the bandwidth at any time and in any state of network congestion. CIR is defined in 64 kb/s increments. (See diagram on previous page.)
  • Excess Information Rate (EIR) – This rate is both a maximum rate limit above which no traffic will be forwarded and a configured amount of burst bandwidth that the traffic flow can use if sufficient resources are available. EIR is also defined in 64 kb/s increments.
  • Burst Priority – This priority applies to EIR and enables servicing of the burst bandwidth in a configured fashion. The burst bandwidth represents the difference between the EIR and the CIR. If the EIR and the CIR are configured to the same value, there will be no burst bandwidth. This configuration is typically applied to constant rate services. The Burst Priority ranges from 0 to 7.
  • Queue Size – This defines the size of the queue (minimum, medium, large or maximum), which corresponds to different levels of latency and jitter tolerance.

The example below shows how the LightningEdge solution can be used to support multiple services, each with their own QoS requirements. FTP traffic from a data center, video from a server, and voice traffic can be provisioned with their own CIR, EIR, and with a high burst priority using VLAN and/or TCP and UDP port numbers. Non-critical traffic, such as HTTP, can be restricted to low priority configurable bursting.

Figure 4. Example of Flexible QoS

Sophisticated Congestion Handling

Although World Wide Packets’ solution supports Rate Limits and Class of Service QoS methods for interoperability reasons, the LightningEdge devices have been designed to support delivery of multiple services, each with their own QoS. Instead of offering only a way to rate limit subscriber traffic, the LightningEdge solution protects critical traffic while allowing bursting, through the following main traffic parameters:

  • CIR
  • EIR
  • Burst Priority

CIR can be fulfilled under any state of network congestion, provided the sum of the CIRs does not exceed the network capacity. The EIR can be fulfilled when there is still available bandwidth after servicing all the CIRs. If a subscriber does not use its configured CIR at a given time, that bandwidth can be applied to servicing other subscribers’ EIRs.

In the example below, five subscribers are configured with a CIR of 200 Mb/s and a EIR of 1,000 Mb/s. If all of them ingress traffic 200 Mb/s or more at the same time, they will each be able to egress 200 Mb/s.

Figure 5. CIR and EIR Servicing

If subscribers 1, 2, 3 and 4 ingress 100 Mb/s, and if subscriber 5 ingresses 1,000 Mb/s, subscribers 1, 2, 3 and 4 will have their CIR serviced up to the bandwidth they are ingressing, i.e., 100 Mb/s each. Subscriber 5 will have its CIR serviced, 200 Mb/s, and then will have its EIR serviced up to the maximum available bandwidth left, i.e., 600 Mb/s (200 Mb/s of CIR and 400 Mb/s of burst bandwidth).

If subscribers 1, 2, and 3 ingress 100 Mb/s, and if subscribers 4 and 5 ingress 1,000 Mb/s, subscribers 1, 2 and 3 will again have their CIR serviced, i.e., 100 Mb/s. Subscriber 4 and 5 will also have their CIR serviced and then will compete

for the remaining bandwidth. Since subscriber 4 is configured with a higher burst priority, it will get most of the remaining bandwidth.

Under all circumstances, the CIRs will be serviced. Once the CIRs are serviced, the EIR will be also serviced up to the maximum available bandwidth. This enables an optimum utilization of the provider’s network at any time. In the previous example, the link utilization is always 100%. This maximizes the revenue a provider can generate out of its network infrastructure.

Figure 6. Revenue Potential

In typical networks, Rate Limiting can be viewed as a network where CIR = EIR. This limitation does not exist in the LightningEdge solution. EIR can be configured to exceed CIR. This EIR can be included in the Service Level Agreement (SLA) that the service provider will offer, as a differentiator from other providers as well as a new source of revenue.

Scheduling Services

The key to a powerful QoS is how a network device services the available bandwidth. The LightningEdge solution offers a very simple, but yet very powerful, two-level servicing method.

Figure 7. Complete Servicing Method

Before entering the two-level method the Classifier sorts ingress traffic according to the classification defined by the network operator. Once classified, the traffic is directed to one of the available 128 hardware queues.

Then the LightningEdge QoS implementation relies on two schedulers:

  • The Main Scheduler – this scheduler has a global view of all the traffic ingressing the device, as well as the configuration of each hardware queue.
  • The Egress Schedulers – each port has a dedicated egress scheduler that ensures that higher priority traffic has the lowest latency through the device.

Every minimum frame size time, the Main Scheduler goes through two servicing algorithms:

  • First, obeying a strict servicing of the CIRs versus the EIRs, the Main Scheduler services all the CIRs in a round-robin fashion for all the configured queues
  • Then, following the configured burst priorities, the Main Scheduler applies a Weighted Fair servicing of the EIRs.

Once serviced, the traffic is forwarded to the egress port, where the Egress Scheduler applies a Weighted Fair servicing of the output queues. Only the Main Scheduler can drop traffic based on the configured QoS. Because traffic forwarded to the egress port will never exceed the egress port capacity, traffic will never get dropped there. The Egress Scheduler’s main function is to reduce latency and jitter on high priority traffic by transmitting it first.

In comparison, less sophisticated QoS implementations only offer:

  • A limited Classifier
  • No Main Scheduler
  • One Egress Scheduler shared amongst all ports

Figure 8. Typical CoS Limited Scheduling

Very often, these less sophisticated QoS platforms implement rate limiting on the egress. This means that traffic must traverse the device switch fabric before either being forwarded or dropped. Waiting until the very last moment before dropping excess traffic leads to a waste of finite resources that could be applied to traffic actually forwarded by the device.

Latency and Jitter

Latency is the delay introduced by the network on the traffic that it forwards. Latency can impact time sensitive application such as voice and interactive video. If the latency exceeds 300 milliseconds for a round trip, the quality of the conversation carried by a phone call will be impacted. If it exceeds 500 milliseconds, a conversation becomes impractical. Latency can be introduced by the following factors:

  • Queuing delay – this is the time the frame spends in the queuing structure of the device. This delay is highly dependent on the level of congestion.
  • Forwarding delay – this is the time it takes the device to make a forwarding decision on the frame. Since the LightningEdge devices are fully line rate, this delay is null.
  • Transmission delay – this is the time it takes to transmit the frame on the transport media. It takes 12 µs to serialize a 1,500-byte frame onto a 1000 Mb/s media.
  • Propagation delay – this is the time it takes the traffic to travel through the transport media. It takes 5 µs for a bit to travel one kilometer over fiber.

Figure 9. Non-congested Device Latency (Latency - uSec)

The propagation and the serialization delays obey the laws of physics and there is very little that can be done to reduce these intrinsic delays.

The forwarding delay has already been reduced to almost nothing. The queuing delay, however, can have a very significant impact on the overall latency, especially on a congested network as shown in the following chart.

Jitter is the variation of the latency for a given traffic flow over time. The network introduces jitter when the level of congestion varies, varying the queuing delay.

Once again the time-critical traffic such as voice will be most impacted by jitter. Excessive jitter through the network can result in sound artifacts such as cracking noise during a phone call.

A simple way to reduce jitter is to buffer the traffic at its termination point. However, this buffering will again add latency to the network.

The LightningEdge solution reduces latency through the network by offering the following:

  • The optimum compromise between being able to queue ingress traffic and keeping the queuing delay to the minimum by not increasing the buffer memory beyond what is absolutely required.
  • A configurable queue size for each hardware queue that permits queues bearing time-critical traffic to be kept to the minimum size.
  • A configurable queue priority that enables the egress scheduler on each port to prioritize the serialization of time-critical traffic first.

Traffic Profiling

In addition to these congestion-handling techniques, the LightningEdge solution offers traffic profiling similar to the Differentiated Services (DiffServ) model. This enables a service provider to configure the network such that traffic out of profile can be dropped before traffic in profile. In case of congestion, ingress traffic, if out of profile, can be remarked to a lower profiling value. The traffic will carry that profiling value through the network. If congestion happens later on in the network, and if the traffic is still out of profile, the traffic can be discarded.

A traffic profile is associated to a port and contains:

  • A Low Information Rate – Traffic above this threshold will be remarked.
  • A High Information Rate – Traffic above this threshold will be discarded.

In addition to supporting the traditional DiffServ model by remarking standard Per-Hop Behavior Group (RFC 3836) traffic, the LightningEdge solution also enables Traffic Profiling and Remarking for DiffServ Code Point (DSCP), IP Type of Service (TOS), and IEEE 802.1D priority traffic.

Figure 10. Traffic Profiling Example

Traffic between the Low Information Rate and High Information Rate thresholds can be remarked following the example below.

Traffic Remarking Example

Traffic Profiling Type Ingress Traffic Egress Remarking
Standard DiffServ AF11 AF12
Custom DiffServ 23 27
IP ToS 5 3
IEEE 802.1D priority 5 3

Automated Service Provisioning

World Wide Packets LightningEdge Network Supervisor (LE-NS) Service Provisioning module enables fully automated provisioning of QoS within a LightningEdge Access Network, resulting in significantly lower Operating Expense (OPEX) versus the effort required to provision services manually.

Using LE-NS, a network operator configures the SLA and defines the service offering which customers can then subscribe to. When the service is provisioned, LE-NS programs all the required QoS entries on all the required devices within the LightningEdge Access Network. The algorithm used to apply the QoS entries to the devices optimizes the use of the QoS resources on the device.

LE-NS fully supports automated configuration of VLAN connectivity, Service Mappings, and Service Levels of LightningEdge network elements in any topology, including rings, stars and mixed deployments.

Figure 11. Service Provisioning Example

Provisioning Rules

Regardless of whether services are provisioned manually or automatically using the LE-NS Service Provisioning module, a few basic provisioning rules should be observed.

The CIR can be provisioned to equal the bandwidth available through the network at any time. Provisioning the CIR to exceed the available bandwidth will prevent the network from fulfilling the CIR when all the CIRs are reached at the same time.

∑CIRDOWNLINK ≤ ∑ CIRUPLINK

EIRs, however, can be over-provisioned.

∑EIRDOWNLINK ≤ or ≥ ∑ EIRUPLINK

The only guarantee offered on the EIR is that if the network is not congested, the EIR can be serviced. Therefore, the EIR sold to a subscriber should not exceed the uplink capacity.

EIRSUBSCRIBER ≤ CAPACITYUPLINK

Figure 12. Provisioned Service Example

Continue