|
Delivering Hard QoS in Carrier Ethernet Networks
Abstract This article discusses hard Quality of Service (QoS) as a major differentiator of carrier Ethernet compared with traditional relative QoS. It outlines the fundamentals of hard QoS which could be described as specific performance guarantees to the customer as long as the customer's traffic meets certain, pre-negotiated characteristics. It presents how MEF's CoS implementation agreement [1] can help standardize the offering of classes of service to end user and other service providers. The article presents how hard QoS could be delivered in the frequently used technologies for delivering carrier Ethernet and outlines the importance and innovation of connection-oriented Ethernet. Introduction Quality of Service (QoS) is the 4th Pillar of Carrier Ethernet according to MEF (as shown in figure 1).  This article discusses the importance of hard QoS in carrier Ethernet networks and demonstrates how hard QoS can be realized. Hard QoS provides the customer of the service with the performance guarantees that enable the quality of experience desired by mission critical applications. Most of the vendors who offer an end-to-end carrier Ethernet solutions have products that support hard QoS. This article presents common practice and does not try to describe any specific system or vendor's implementation. QoS is multi-faceted, with almost every Carrier and ISP providing "Quality of Service" and any device in a carrier network supporting some level of QoS. The basis for QoS can be attributed to IEEE 802.1Q [3] and IETF DiffServ ([4], [5] to name a few). However, these schemes did not guarantee specific performance guarantees parameters and were not easily testable by end users. MEF 10.1 [2] (Service Attributes) provides the mechanism with which to offer a Service Level Agreement (SLA) between a Service Provider and customers. The customer needs to specify traffic requirements measured in Committed Information Rate (CIR) and Excess Information Rate (EIR) accompanied by the contracted burst sizes, in addition the policing algorithm operates in two modes Color-aware and color-blind, refer to [2] for more details. In return, the service provider guarantees performance levels for the "in profile" traffic, which is the traffic admitted as conforming to the CIR and its burst (Committed Burst Size).
The performance
levels Delay, Delay Variation (sometimes known as Jitter), Frame loss ratio and
Availability. (Availability is not yet in common use and MEF has not specified yet
how one could measure availability in practice). Two years ago MEF
launched technical work on Carrier Ethernet Class of Service Implementation
Agreement [1] to standardize on offerings for several Classes of Service (CoS),
each with its own performance attributes. This would allow for inter-provider
services and would enable a customer purchasing service from a provider to verify
that the terms of the SLA are being met. This innovative QoS
methodology is commonly known as hard QoS. Meaning that service providers supply
hard numbers and are usually penalized if failing to meet the SLA terms.
Delivering Hard QoS Delivering hard QoS
usually requires a comprehensive solution deployed end-to-end.
UNI are illustrated
in the following figure, assuming that the network is implemented using PBB-TE
technology:
 A
device implementing UNI-N functionality servicing multiple CoSs usually
features the capability to queue ingress traffic received from UNI-Cs. Traffic
belonging to different CoSs is likely to be assigned to separate queues. It
should be noted that multiple queues could serve a single CoS. However, in
doing so, it is recommended to design the system in such a way that
re-sequencing is avoided. Therefore, traffic belonging to a specific flow
should be put into a single queue. This should include both Color Yellow (i.e.,
Drop/Discard Eligible) and Color Green (non-Drop/discard Eligible) marked
frames of this specific flow.
This
implies that the policing and marking functions, which determine the extent of compliance
of the offered traffic to the SLS, are completed before enqueuing the packets.
When
multiple queues compete to be sent through an interface (towards the MEN
internal), a scheduling decision is needed. Scheduling can take many shapes and
forms and can combine different methods, such as, priority queuing (i.e.,
strict priority), WFQ, etc.
An
example of queuing and scheduling options for a port service of multiple CoSs
is provided below:
In
this example we see a single output port served by a SP (Strict Priority) scheduler. It provides absolute priority to a
single EF (Expedited Forwarding) queue. This queue usually serves voice and
video traffic.
When
the EF queue is empty, the rest of the bandwidth is shared according to weights
between 5 queues, 4 AF (Assured Forwarding) and a single BE (Best Effort).
Weights could be static or dynamically computed by the management plane.
A
useful capability is to ensure that traffic with the most stringent delay and
delay variation requirements (e.g. synchronization, mobile backhaul, control
traffic, etc) would be serviced immediately with virtually no delay.
Specific
queues might have rate guarantees (minimum rates) and a rate limit. This could
be useful to avoid starvation imposed by higher precedence queues. Note that
Mobile backhaul applications may require avoidance of multiple strict priority
mechanisms (strict priority queuing/servicing mechanisms) at least beyond the
Real Time classes to avoid starvation of lower classes.
In
conjunction with the queuing system, a certain level of active queue management,
such as WRED, should be used to allow congestion mitigation. However, dropping
green frames should be avoided in order to meet the frame loss targets.
In
some cases, lower priority CoSs might be oversubscribed by the service provider
and thus, in cases of congestion, some of this traffic would have to be dropped.
This means that the frame loss ratio for such CoS is usually lower or is
measured over longer time intervals (e.g. days), allowing the service provider
to actually drop most of these frames during congestion time.
The
delay and delay variation objectives should be considered when deciding how
much buffering a specific queue could consume. As buffering increases so does
the observed delay.
It
is likely that the queue serving VoIP would be quite short, however the queue serving
bulk data traffic, which may have no delay / delay variation objective, could
be deeper thus avoiding frame drop on account of additional delay in times of
congestion.
Connection Oriented Networks Recently there has been a proliferation of carrier Ethernet in connection oriented networks. The fundamental idea is that standard Ethernet and IP networks do not select the path from source to destination based on the resources available and the SLA. Furthermore, in the event of failure, these networks take a relatively long time (at least a few seconds) to converge.
In order to mimic
SONET/SDH predictability, several technologies have emerged, such as T-MPLS,
PBB-TE and recently, MPLS-TP. What they have in
common is a defined path from source to destination, established via a management
system or control plane (the latter is futuristic at the moment thus allowing
the service provider to control the path and ensure that it can meet the
traffic requirements). All these technologies have a restoration solution that
ensures minimal frame loss until traffic is restored with the appropriate QoS. These technologies,
however, do not, by themselves, offer additional QoS capabilities compared to
those of standard Ethernet or IP. The predictability
of this path is the main attribute that facilitates hard QoS.
Types of Services MEF has defined three categories for services:
It should be noted
that the industry has not yet specified a comprehensive QoS solution for E-LAN
and E-Tree. The challenges come from the fact that multiple unsynchronized
sources may send traffic towards the same destination through different network
paths. Dropping the excess traffic close to the destination is not practical
since it has already consumed network resources and may have adversely affected
other services. Today, multiple
proprietary heuristics are available to try and estimate and coordinate
resource allocation dynamically, nearer the sources.
OAM
We discussed the
mechanisms by which a service provider can offer SLA and hard QoS to its
customers. We then discussed how network elements can support these
requirements, but the missing element is the ability to accurately measure the
performance of each service. The requirements are two-fold:
MEF is working on a
service OAM (SOAM) implementation agreement that uses the standard mechanisms
of ITU-T Y.1731 and IEEE 802.1ag with adaptation to MEF terminology and SLA
needs. While the problem of
E-Line services is quite straightforward, the issue of verifying the SLA for
E-LAN (e.g. VPLS service) is certainly not trivial at all.
Conclusions The industry and the standards bodies have made considerable progress in enabling the delivery of hard QoS over carrier Ethernet networks. However, as illustrated in this article, there are many challenges still to be met for providing hard QoS and SLA monitoring for E-LAN services as well as for coordinating CoSs between service providers and for facilitating useful Service OAM. References [1] MEF CoS Implementation Agreement Phase 1 [2] MEF 10.1 – Service Attributes [3] IEEE 802.1Q-2006 [4] IETF RFC 2597 – Assured Forwarding PHB [5] IETF RFC 3246 – Expedited Forwarding About the Author Ayal Lior was active and well-known in the technical work of MEF between the years 2005 - 2008. Mr. Lior was twice commented for outstanding contribution to the MEF. With over 12 years of experience in networking and system architectures, system design, protocol design and intimate knowledge in Ethernet and TCP/IP. Mr. Lior is a Traffic Management expert (design, implementation, deployment) both S/W and H/W. He can be reached at This e-mail address is being protected from spambots. You need JavaScript enabled to view it His profile at linkedin is: http://www.linkedin.com/pub/0/837/209 Trackback(0)
Comments
(2)
Hi,
Votes: +0
I have question/clarification on the queuing and scheduling: The last queues is the BE (Best effort). This queue’s scheduling is WFQ, so he has some configured weight. This means that it will be served according to his weight and the others WFQ weights that configured on the higher queues. Is this best effort scheduling? As I understand it, is that the BE queue will be served only if there is no traffic on the others queues. Thanks, Doron. report abuse
vote down
vote up
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Monday, 15 June 2009 17:11 |
TrackBack URI for this entry
Subscribe to this comment's feed
The approach presented in this article complies with MEF's view.
Each CoS has CIR, EIR and therefore, starvation of one CoS is not applicable.
You can of course put the BE strictly below the WFQ scheduler. This has merits in some scenarios.
Note that tuning the weights could yield a very similar result at times of need.
Ayal