GO-ITS 571TES Network Quality of Service Standard
This document defines the requirements for service classes and design criteria when deploying QoS.
1. Introduction
Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and IT Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.
These publications support the responsibilities of the Treasury Board Secretariat for coordinating the standardization of I&IT in the Government of Ontario. In particular, GO-IT Standards describe where the application of an IT standard is mandatory and specify any qualifications governing the implementation of the IT standards.
2. Summary
2.1 Standard Name and Description
This document, GO-ITS 571TES Network Quality of Service Standard, defines the requirements for service classes and design criteria when deploying Network Quality of Service.
2.2 Background and Rationale
Quality of Service (QoS) is the process of marking flows of packets or traffic, classifying them for a class (level) of service, and then processing them based on those markings. The ultimate goal is to guarantee a certain level of performance for a data flow during times of network congestion. The level of services is based on a priority hierarchy, from high to low priority and data flows are classified based on which are most susceptible to jitter, delay, and packet loss while the network is congested.
Packets marked as in a high-priority service category will get “preferential” treatment while travelling across the network while lower priority marked packets get less preference through the network. When a mixture of high and low-priority marked packets encounter congestion on the network, QoS helps to manage the congestion by employing different queuing and scheduling features across network components.
As an example, packets not highly impacted by jitter, latency, and packet loss such as general web browsing would be placed in a lower priority queue while the network is congested. While a data flow that is highly impacted like voice or video calls would be prioritized to guarantee performance.
In recent years, networks and network-based applications have evolved and a significant amount of emphasis is being placed on performance management through the implementation of QoS. At the present time, the Ontario Government’s network adequately supports hundreds of network applications without such services enabled. The key business driver for the need to standardize QoS within the Ontario Government is related to the development and deployment of future enterprise video, voice, and Unified Communications (UC) services which are accompanied by strict network performance requirements.
With the implementation of new network-intensive services on the horizon, this standard shall define a set of guidelines, roles and responsibilities and a traffic prioritization scheme to guarantee performance during times of congestion.
2.3 Target audience
The target audience for this document includes, but is not limited to:
• Developers
• Technical implementers
• Procurement
• Program managers
2.4 Scope
2.4.1 In scope
- All internal data communications networks including Data Centre Infrastructure, Local Area Networks (LAN), and Wide Area Networks (WAN)
- All data, voice, and video networks used within the OPS
- Unified Communications services including, call control, telephony, instant messaging, presence, speech recognition, unified messaging and video conferencing
- Network infrastructure devices including, routers, switches, and firewalls
2.4.2 Out of scope
- Broader Public Sector (BPS) and other arms-length organizations including, academic institutions, health care providers, major transfer payment recipients, municipalities, and school boards
- Infrastructure devices including, servers, storage, backup devices, and load balancers.
- Implementation of QoS
2.4.3 Objectives of GO-ITS 571TES
This standard outlines:
- Mandatory requirements and design criteria for deploying Quality of Service on the Government of Ontario Network.
- A defined, structured set of Network Traffic Queues
2.4.4 Network Objectives
The Ontario Government Network Traffic Queues (Appendix D) defines a framework for how current and future network traffic must be classified. The main focus of any QoS deployment should be to:
- Define a set of traffic prioritization rules for times of network congestion
- Ensure that time-sensitive and mission-critical applications have the network resources required while allowing other applications to coexist and access the network.
- Increase application, network, and infrastructure efficiency, resiliency, and performance of network-intensive services.
- Govern control over network resources and allows for effective management of the network from a business, rather than a technical perspective.
- Accommodate new applications and technologies (Unified Communications, VoIP, Video Conferencing)
- Support continued infrastructure growth
2.5 Applicability statements
2.5.1 Organization
All Ministries and I&IT Clusters are subject to the Government of Ontario IT Standards.
All adjudicative and advisory agencies are subject to the Government of Ontario IT Standards.
All other agencies that are using OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to either the Governance and Management of Information Technology Directive or Government of Ontario IT Standards by a memorandum of understanding.
As new GO-IT Standards are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).
When implementing or adopting any Government of Ontario IT standards or IT standards updates, Ministries, I&IT Clusters and applicable agencies must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.
2.5.2 Requirement levels
Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:
Must - This word, or the terms "required" or "shall", means that the statement is an absolute requirement.
Should - This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (for example, business functionality, security, cost) must be understood and carefully weighed before choosing a different course.
3. Technical specification
The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.
3.1 QoS-Based Architectures
This QoS standard covers the definitions of QoS, traffic and service specifications, IntServ and DiffServ frameworks.
3.1.1 Definition of QoS
QoS is defined as service differentiation and performance assurance for data flows running over the
LAN or WAN. Service differentiation provides different services to different applications according to
their requirements. Performance assurance addresses bandwidth, loss, delay and delay variation. The
specifications of traffic and its desired service can be given on a per-flow basis or in service level
agreement (SLA) from the perspective of packet forwarding treatment an application receives.
There are two major frameworks, Integrated Services (IntServ) and Differentiated services (DiffServ)
recognized as the principal architecture for providing QoS.
3.1.2 Integrated Services (IntServ)
An Integrated Services (IntServ) approach utilizes Resource Reservation Protocol (RSVP) to reserve
capacity and capability across a network; this makes it ideal for end-to-end delay and jitter-sensitive
applications, such as Voice and Video. With RSVP capacity is reserved and prioritized across the
network on a per-flow basis.
This type of prioritization, because of the reservation of resources, does not scale well in a large network
environment with a multitude of applications contending for a finite amount of resources. Although
RSVP may be ideal in small well-behaved networks, but in most large networks today, it is impractical to
implement RSVP as a QoS mechanism due to the number of flows and reservations that would have to
be managed and the amount of bandwidth and CPU cycles that would be required to maintain the
environment.
3.1.3 Differentiated Services (DiffServ)
Differentiated Services (Diffserv) utilizes a different approach to prioritize traffic. Instead of looking at
individual flows, Diffserv marks each packet. By marking groups of packets from applications
with similar requirements with the same identifiers, the network elements can recognize the service
levels required by each packet and ensure the proper treatment across the network. Network
prioritization is assessed on a hop-by-hop (Per Hop Behaviour) basis, and each node is responsible to
manage congestion based on the Diffserv priorities.
In general, Diffserv implementation follows the following steps.
- Each Packet is categorized, and a series of bits are set in a field in the IP header upon network entry or at a network boundary using legacy IP precedence or the more scalable Differentiated Services Code Points (DSCP).
- Using this field’s bit marking the nodes inside the network queues and forwards the packets based on the markings.
- In the event of congestion, these bit markings are used to decide what traffic will be prioritized and what traffic will be dropped.
- Individual packets are marked for a certain class of service and are handled consistently at any point in the network to ensure a consistent level of service. As an example, HTTP packets will be marked for a certain Per Hop Behaviour (PHB) versus a voice packet which will have a “higher” marking PHB and will be handled at a higher level of service. As opposed to IntServ Flows, DiffServ is granular at the packet level and classifications can be coarse to fine as
needed. With DiffServ, the bits called Differentiated Services Code Points or DSCP can be scaled to 64 different markings. This means a packet may be marked in 64 different ways, although the vast majority of networks only implement 3-8 different priorities.
- The major advantage of this approach is scalability and performance since the packets are only examined for classification and marking at the edge of the network and then the traffic is prioritized based on the DSCP markings.
3.2 DiffServ Key Service Concepts (Reference RFC 4594)
Differentiated Services is a general architecture that may be used to implement a variety of network-intensive services (e.g., voice and video). Three fundamental forwarding behaviours have been defined and characterized for general use. These are basic Default Forwarding (DF) behaviour for elastic traffic, the Assured Forwarding (AF) behaviour, and the Expedited Forwarding (EF) behaviour for real-time (inelastic) traffic. The fact that four code points are recommended for AF and that one code point is recommended for EF are arbitrary choices, and the architecture allows any reasonable number of AF and EF classes simultaneously. The choice of four AF classes and one EF class in the current document is also arbitrary, and network operators may choose to operate more or fewer of either.
3.2.1 Assured Forwarding (AF)
Assured Forwarding behaviour is explicitly modelled on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss Priority (CLP) capability. It is intended for networks that offer average-rate Service Level Agreements (SLAs) (as FR and ATM networks do). This is an enhanced best-effort service; traffic is expected to be "elastic" in nature. The receiver will detect loss or variation in delay in the network and provide feedback such that the sender adjusts its transmission rate to approximate available capacity as with most TCP-based data applications.
For such behaviours, multiple DSCP values are provided to identify the traffic; a common queue is used to store the aggregate and active queue management is used to protect the network and limit delays. Traffic is metered and marked as it enters the network depending on the arrival rate of the aggregate. The premise is that it is normal for users occasionally to use more capacity than their contract stipulates (burst), perhaps up to some bound. However, if traffic should be marked or lost to manage the queue, this excess traffic will be marked or lost first.
3.2.2 Expedited Forwarding (EF)
The intent of Expedited Forwarding Per-hop Behaviour (PHB)
To protect the network from abuse, at minimum traffic should be policed at various points to ensure that the design of a queue is not overrun, and then the traffic should be given a low-delay queue (often using priority, although it is asserted that a rate-based queue can do this) to ensure that variation in delay is not an issue, to meet application needs.
3.2.3 Class Selector (CS)
The Class Selector provides support for historical code point definitions and PHB requirements. The Class Selector DiffServ field provides a limited backward compatibility with legacy (pre DiffServ) practice, as described in RFC2474, Section 4. Backward compatibility is addressed in two ways. First, there are per-hop behaviours that are already in widespread use (e.g., those satisfying the IPv4 precedence queuing requirements specified in RFC1812, and we wish to permit their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to the historical use of the IP Precedence field, and we reserve these codepoints to map to PHBs that meet the general requirements specified in RFC2474.
A DiffServ-compliant network can be deployed with a set of one or more Class Selector-compliant PHB groups. Also, a network administrator may configure the network nodes to map codepoints to PHBs, irrespective of bits 3-5 of the DSCP field, to yield a network that is compatible with historical IP Precedence use. Thus, for example, codepoint '011000' would map to the same PHB as codepoint '011010'.
In the majority of implementations, CS and AF are used simply as identifiers with each implementation applying its own data priority and queuing mechanism to control data prioritization and queuing behaviour.
3.3 Mandatory
3.3.1 Differentiated Services QoS Implementation
Due to the scalability and the adoption rate of Diffserv by Canadian Carriers for MPLS WAN implementations, a Diffserv approach will be followed for QoS implementations. The current guidelines for Diffserv implementation are detailed in RFC 4594.
3.3.1.1 Service Classes
Traffic flowing through a network may be classified in many different ways. For the purposes of this standard, service classes will be divided into the following two groupings:
3.3.1.1.1 Network Control Group
The network control traffic group is further divided into two service classes:
- Network Control Service Class (EF) - for routing and network control functions.
- Operations, Administration, and Management (OAM) Service Class (AF31) - for configuration and management functions.
3.3.1.1.2 User/Subscriber Traffic Group
The user/subscriber traffic group is broken down into ten service classes to provide service differentiation for all the different types of applications/services:
- Telephony Service Class (EF) - is best suited for applications that require very low delay variation and are of constant rate, such as IP telephony (VoIP) and circuit emulation over IP applications.
- Signalling Service Class (CS4/AF42) - is best suited for peer-to-peer and client-server signalling and control functions using protocols such as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol (MGCP).
- Multimedia Conferencing Service Class (AF41) - is best suited for applications that require a very low delay and have the ability to change encoding rate (rate adaptive), such as H.323/V2 and later video conferencing service.
- Real-Time Interactive Service Class (AF41) - is intended for interactive variable rate inelastic applications that require low jitter and loss and very low delay, such as video conferencing applications that do not have the ability to change encoding rates or to mark packets with different importance indications.
- Multimedia Streaming Service Class (CS4/AF42) - is best suited for variable rate elastic streaming media applications where a human is waiting for output and where the application has the capability to react to packet loss by reducing its transmission rate, such as streaming video and audio and webcast.
- Broadcast Video Service Class (CS3) - is best suited for inelastic streaming media applications that may be of a constant or variable rate, requiring low jitters and very low packet loss, such as broadcast TV and live events, video surveillance, and security.
- Low-Latency Data Service Class (AF31) - is best suited for data processing applications where a human is waiting for output, such as web-based ordering or an Enterprise Resource Planning (ERP) application.
- High-Throughput Data Service Class (AF21) - is best suited for store and forward applications such as file transfer protocol (FTP) and billing record transfer.
- Standard Service Class (CS0) - is for traffic that has not been identified as requiring differentiated treatment and is normally referred to as best effort.
- Low-Priority Data Service Class (CS1) - is intended for packet flows where bandwidth assurance is not required.
Note: It is understood that due to equipment limitations and the design requirements of specific QoS implementations, the service classes above may not be applicable and may be combined with other classes by the OPS or the network vendor(s).
See Appendix B, for a comparison table of each Service Class’ tolerance to delay, jitter, and loss.
See Appendix C, for Differentiated Service Code Point (DSCP) Markings and Service Classes
3.4 QoS Design Criteria
As defined earlier there are a significant number of service classes and differentiators related to implementing QoS and network-intensive services. At the present time, within the industry, the majority of organizations have yet to differentiate application traffic to this level of granularity. This is typically due to the fact that organizations have not yet deployed or do not yet have a clear business requirement for implementing all service classes and differentiators.
For example, if an organization is not deploying Voice over IP (VoIP) or video conferencing there may not be a requirement to deploy or allocate these service classes. However, if there are plans to use that technology in the future, it would be wise to reserve these service classes for future implementation and not allocate them to applications unnecessarily.
As the Ontario Government network evolves, this standard may be revised from time to time as business requirements dictate changes to the defined service classes.
See Appendix D for the Ontario Government Network Traffic Queues
3.4.1 QoS Principles
The following principles have been developed and are mandatory for the design and administration of data communication services which may require QoS.
Principle #1: General QoS Design
Do not enable QoS features simply because they exist. Instead, start to design from a high level and clearly define the organization’s objectives.
Rationale
- Efficiency in controlling network characteristics and assessing traffic data
- Accuracy of use of classes of service
- Ability to measure and justify application requirements to services enabled
Implications
- The OPS Network (subsequently referred to as « GONET ») should be run as a centralized service to ensure the QoS-enabled service is one centralized service
Principle #2: Classification and Marking
Classify and mark applications as close to their sources as technically and administratively feasible and use DSCP markings whenever possible
Rationale
- Promote end-to-end Differentiated Services and per-hop behaviours (PHBs)
- Avoid allowing users to mark their own traffic.
- Promote DSCP markings whenever possible to ensure interoperability and future expansion.
Implications
- Proper analysis and design are needed to ensure accurate markings
Principle #3: Policing and Markdown
Police traffic flows as close to their sources as possible.
Rationale
- This principle applies to legitimate flows also because denial-of-service (DoS) attacks and worm-generated traffic might be masquerading under legitimate, well-known TCP and UDP ports, causing extreme amounts of traffic to be poured onto the network infrastructure.
- Whenever supported, markdown should be done according to open standards-based rules, such as RFC 2597 ("Assured Forwarding PHB Group").
Implications
- Congestion-management policies, such as DSCP-based WRED, should be configured
3.5 Traffic Marking Rules
The following must be used to correctly correlate traffic to the appropriate classes.
3.5.1 LAN EF
- All traffic in the IP range that matches the Ports for Voice bearer traffic.
- Any routing protocol traffic (OSPF, BGP or RIP)
3.5.2 LAN AF41
- All traffic in the IP range, should be considered urgent service and used for the new Video Conferencing Service
- Any Internal Government address space that matches the Ports used for Video in the current implementation
- Any special application that would require time-sensitive treatment.
3.5.3 LAN CS4 or AF42
- System Network Architecture (SNA) Data-link switching (DLSw) or Telnet3270 Traffic
- All other IP ranges for Call Setup
- Any internal traffic with ports matching WEBCast type traffic.
3.5.4 LAN AF21
- Any traffic to and from Exchange servers.
- Any Priority Bulk Transfers (Specifically identified)
3.5.5 LAN CS0
- Any HP Client Configuration Management (Radia) traffic
- Any HP Software Server Automation traffic
- Any SMS traffic
3.5.6 LAN CS1
- Any Traffic to or from a non-Internal IP Address (Web or other protocols)
3.5.7 LAN AF31 (default)
- All other Data (Default Class)
- Data Base
- Office applications
- OPS Intranets
- OAM
- Desktop Video Conferencing
- Unclassified Data
For sites subscribing to a WAN service, but without a LAN, classification and marking will be dealt with on a case-by-case basis by the Network Architecture and Security Committee. In order to mitigate potential risks, applications that would normally fall into a particular category but are found to behave poorly and have an adverse effect on the overall network may be re-prioritized into a lower service class to protect the general performance of the network. Before being introduced into the network, new applications should be assessed for QoS requirements as part of the Architecture Review or by consultation with the ITS Telecommunications Services Network Team.
4. Related standards and impacted infrastructure
4.1 Impacts to existing standards
Standards that reference or are referenced by this standard and description of impact.
GO-ITS standard | Impact | Recommended action |
---|---|---|
None | None | None |
4.2 Impacts to existing infrastructure
Applications, systems, solutions and technology platforms that could be affected by this standard and description of impact.
Impacted infrastructure | Impact | Recommended action |
---|---|---|
None | None | None |
5. Compliance requirements
In order to manage the effectiveness and implementation of this standard, Ministries, I&IT Clusters and applicable agencies are expected to adopt and monitor compliance.
6. Roles and responsibilities
Accountable Role (Standard Owner) Definition
The individual or committee is ultimately accountable for the effectiveness of a standard and for its full life cycle, including development, reviews, revisions, updates, evaluations, and rescindment. Where a committee owns the standard, the committee Chair is accountable for the standard. There must be exactly one accountable role identified.
Accountable Role:
Title: Director, Telecommunications Services Branch
Ministry/I&IT Cluster: Ministry of Public and Business Service Delivery
Division: Infrastructure Technology Services
Responsible Role Definition
The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard).
Responsible Organization(s):
Ministry/I&IT Cluster: Ministry of Public and Business Service Delivery
Division: Infrastructure Technology Services
Branch: Telecommunications Services Branch
Support Role Definition
The support role is the resource(s) to whom the responsibility for maintaining this standard has been assigned. Inquiries, feedback, and suggestions should be sent to this resource.
Support Role (Editor):
Ministry/I&IT Cluster: Ministry of Public and Business Service Delivery
Division: Infrastructure Technology Services
Branch: Telecommunications Services Branch
Section: Modernization
Job Title: Senior Manager, Modernization
Name: Charles Wang
Phone:
Email: Charles.Wang2@ontario.ca
2nd Support Role
Section: Enterprise Strategic Planning, Services & Architecture Section
Job Title: Manager, Enterprise Architecture Office
Name: Alan Matsumoto
Phone:
Email: Alan.Matsumoto@ontario.ca
3rd Support Role (if applicable):
Section: Enterprise Strategic Planning, Service & Architecture Section
Job Title: Technical Architect
Name: David Lin
Phone:
Email: david.lin@ontario.ca
7. Consultations
Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:
Organization Consulted (Ministry/I&IT Cluster) | Division | Branch | Date |
---|---|---|---|
Ministry of Government Services | Infrastructure Technology Services | Data Centre Operations | March/May 2009/2010 |
Ministry of Government Services | Infrastructure Technology Services | ESPDS Branch | March/May 2009/2010 |
Ministry of Government Services | Infrastructure Technology Services | Guelph Data Centre Project Team | May 2010 |
Ministry of Government Services | OCCIO | Corporate Security Branch | March/May 2009 |
Ministry of Government Services | OCCTO | Corporate Architecture Branch | March/May 2009 |
Ministry of Government Services | OCCIO | Corporate Architecture and Standards Branch | March/May 2009 |
.
Committee/Working Group Consulted | Date |
---|---|
Technology Architecture Domain Working Group | May 25, 2010 |
Security Architecture Domain Working Group | June 9, 2010 |
ITS Architecture Core Team | June 11, 2010 |
Solutions Delivery Leadership Committee (SDLC) | July 8, 2010 |
Information Technology Standards Council | July 21, 2010 |
IT Service Management Leads Forum | July 22, 2010 |
8. Document history
Date | Summary |
---|---|
2009-08-24 | Created: Network Quality of Service Standard, initial draft version 0.1 |
2010-08-18 | Endorsed: IT Standards Council endorsement |
2010-09-16 | Approved: Architecture Review Board approval • Approved version number set to 1.0 |
2023-04 | Reaffirmed by standard owner (Infrastructure Technology Services) |
2023-10-18 | Architecture Review Board (ARB) endorsement of minor administrative updates |
2023-11-14 | GO-ITS 57.1 renumbered to GO-ITS 571TES |
2024-01-18 | Information Technology Executive Leadership Council (ITELC) approval — Version number set to 1.1 (i.e., GO-ITS 571TES v1.1) |
9. Glossary
Specialized terms and acronyms used throughout this document are generally accepted within the IT field and, therefore, not defined here. Alternatively, readers may choose to contact the editor listed in section 6.
Appendix A: Normative references
- Governance and Management of Information Technology Directive (for OPS employees/internal users)
- GO-IT Standards
Note: a normative reference specifies a supporting document or GO-IT Standard (in the case of the Government of Ontario's I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO-IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO-IT Standard owner.
Informative references
RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
K. Nichols, S. Blake, F. Baker, D. Black. Definition of the Differentiated Services Field (
DS
Field) in the
IPv4
and
IPv6
Headers
. Dec. 1998
Description: This document defines the IP header field, called the DS (for differentiated services) field. In Ipv4, it defines the layout of the TOS octet; in Ipv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviours, is defined.
RFC 1812: Requirements for IP Version 4 Routers
F. Baker, Requirements for
IP
Version 4 Routers
. June 1995
Description: This document defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as IP routers or simply routers; The OSI community refers to such devices as intermediate systems. Many older Internet documents refer to these devices as gateways, a name which more recently has largely passed out of favor to avoid confusion with application gateways.
RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior)
B. Davie, A. Charny, J.C.R. Bennett, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. An Expedited Forwarding
PHB
(Per-Hop Behavior)
. March 2002
Description: This document defines a PHB (per-hop behaviour) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598.
RFC 4594 - Configuration Guidelines for DiffServ Service Classes
J. Babiarz, F. Baker, K. Chan. Configuration Guidelines for DiffServ Service Classes
August 2006
Description: This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
Cisco Enterprise QoS Solution Reference Network Design Guide, Nov 2005
Description: This document provides design considerations and guidelines for implementing Cisco Quality of Service within an enterprise environment.
Appendix B: Network Service Class Comparison Table
Service Class Name | Traffic Characteristics | Tolerance to Loss | Tolerance to Delay | Tolerance to Jitter | |||
Network Control Group | Network Control | Variable Size packets, Mostly Inelastic short messages, some bursting (Routing Protocols) | Low | Low | High | ||
OAM | Variable Size Packets, Elastic and Inelastic Flows | Low | Med – High | High | |||
User/Subscriber Traffic Group | Telephony | Fixed-size small packets, constant rate, inelastic | Very Low | Very Low | Very Low | ||
Signalling | Variable Size packets, bursty short-lived flow | Low | Low | High | |||
Multimedia / Video Conferencing | Variable size packers, constant transmit rate, adaptive, can adapt to loss | Low – med | Very Low | Low | |||
Real-Time Interactive | RTP/UDP streams, inelastic, variable rate | Low | Very Low | Low | |||
Multimedia Streaming | Variable size packets, Elastic with variable rate | Low – med | Med | High | |||
Broadcast Video | Constant and variable rate, inelastic, non-bursty | Very Low | Med | Low | |||
Low Latency Data | Variable rate, bursty short-lived elastic flows | Low | Low – med | High | |||
High-Throughput Data | Variable rate, bursty Long-lived elastic flows | Low | Med – High | High | |||
Standard | A bit of everything | Unspecified | |||||
Low Priority Data | Non-Real Time and elastic | High | High | High |
Appendix C: Differentiated Services Code Point Markings & Service Classes
Service Class Name | DSCP Name | DSCP Value | Application Examples |
---|---|---|---|
Network Control | CS6 | 110000 | Network Routing Protocols |
Telephony | EF | 101110 | IP Telephony Bearer |
Signalling | CS5 | 101110 | IP Telephony Signalling |
Multimedia / Video Conferencing | AF41 AF42 AF43 | 100010 100100 100110 | H.323 video Conferencing (Adaptive) |
Real-Time Interactive | CS4 | 100000 | Video Conferencing and Interactive applications (Gaming, SNA etc) |
Multimedia Streaming | AF31 AF32 AF33 | 011010 011100 011110 | Streaming Video and Audio on Demand |
Broadcast Video | CS3 | 011000 | Broadcast TV & live events |
Low Latency Data | AF21 AF22 AF23 | 010010 010100 010110 | Client Server transactions, WEB-based Applications |
OAM | CS2 | 010000 | OAM&P |
High Throughput Data | AF11 AF12 AF13 | 001010 001100 001110 | Store and Forward Type applications |
Standard | DF (CS0) | 000000 | Undifferentiated Applications |
Low-Priority Data | CS1 | 001000 | Any Flow that has no BW assurance (Scavenger) |
Appendix D: Ontario Government network traffic queues
Data Type | LAN Queue | WAN QOS | Bandwidth |
---|---|---|---|
Priority Data (EF)
| Strict Priority Queue (EF) | Strict Priority (EF) | As Required for Number of VoIP calls (No more than 33% of total Bandwidth) |
Interactive Video (AF41)
| Priority Data (Threshold 1) 80% of Queue | Priority Data (AF 3) | As Required for types and number of Video + 10 - 0% of Non EF Bandwidth |
Streaming Video (CS4, AF42)
| Priority Data (Threshold 2) 20% of Queue | Priority Data (AF 3) | As Required for types and number of Video + 10 - 0% of Non EF Bandwidth |
Normal Data (Default) (AF31)
| Normal Data (Threshold 1) 80% of Queue | Normal Data (AF2) | 55-80% of Non EF Bandwidth Depending on amount of AF3 |
Priority transfer (AF21)
| Normal Data (Threshold 2) 20% of Queue | Normal Data (AF2) | 55-80% of Non EF Bandwidth Depending on amount of AF3 |
File Transfer (DF or CS0)
| Low Priority Data (Threshold 1) 80% of Queue | Low Priority Data (AF1) | 5% of Non EF Bandwidth |
Low priority Data (CS1)
| Low Priority Data (Threshold 2) 20% of Queue | Low Priority Data (AF1) | 5% of Non EF Bandwidth |
Note: The Managed Network Service Providers must provide mechanisms for ensuring agreed upon bandwidth limits are not exceeded during normal operations.
Footnotes
- footnote[1] Back to paragraph RFC3426
- footnote[2] Back to paragraph Applications that would normally fall into this category but are found to be poorly behaved and have an adverse effect on overall network performance may get re-prioritized into a lower service class to protect the overall performance of the network.