QoS Protocols & Architectures

by
Harizakis Costas
Presentation Flow

 QoS defined
 QoS protocols :
– RSVP, DiffServ, MPLS, SBM
 QoS architectures
 QoS and multicast environments
 Protocol comparison …
 … conclusions !
IP-based Networks - Internet Today
 Internet today
– Provides “best effort” data delivery
– Complexity stays in the end-hosts
– Network core remains simple
– As demands exceeds capacity, service degrades
gracefully (increased jitter etc.)

Delivery delays cause problems to real-time

applications
QoS Defined

 The goal :
Provide some level of predictability and control
beyond the current IP “best-effort” service

 Fundamental principle
Leave complexity at the “edges” and keep network
“core” simple
QoS Metrics

 Performance attributes
– Service availability
– Delay
– Delay variation (jitter)
– Throughput
– Packet loss rate
Vary according to Service Level Agreement
(SLA)
Service Level Agreements (SLA)
QUALITY OF SERVICE PARAMETERS
Service Level Application Priority Mapping

1  Non-critical data  Best-effort delivery

 Similar to Internet today  Unmanaged performance
 No minimum information rate
guaranteed

2  Mission-critical data  Low loss rate

 VPN outsourcing, e-  Controlled delay and delay
commerce variation
 Similar to ATM VBR

3  Real time applications  Low loss rate

 Video streaming, voice,  Low delay and delay variation
videoconferencing
QoS Protocol Classification

 QoS can be achieved by :

– Resource reservation (integrated services)
– Prioritization (differentiated services)

 QoS can be applied :

– Per flow (individual, uni-directional streams)
– Per aggregate (two or more flows having something
in common)
QoS Protocols

 ReSerVation Protocol (RSVP)

 Differentiated Services (DiffServ)
 Multi Protocol Labeling Switching (MPLS)
 Subnet Bandwidth Management (SBM)
RSVP
- Resource Reservation

 Attributes
– The most complex of all QoS technologies
– Closest thing to circuit emulation on IP networks
– The biggest departure from “best-effort” IP service
 Provides the highest level of QoS in terms of :
– Service guarantees
– Granularity of resource allocation
– Detail of feedback to QoS-enabled applications
RSVP
- Integrated Services

 Enables integrated services (IntServ)

 IntServ types
– Guaranteed : as close as possible to a dedicated
virtual circuit
– Controlled Load : equivalent to best-effort service
under unloaded conditions
RSVP
- Implementation

Qo S L
e
a n d v el
Filt er
Traffic ion Spec if
ic at ion
at
Spec ific
RESV
PATH

Host A Host B
RSVP
- Implementation

 Sender
– PATH message containing
 traffic specification (bitrate, peak rate etc.)
 Receiver
– RECV message containing
 the reservation specification (guaranteed or controlled)
 the filter specification (type of packets that the reservation
is made for)
RSVP
- Queuing

 IntServ uses a token-bucket model to

characterize I/O queuing
 Token bucket attributes
– Token rate
– Token bucket depth
– Peak rate
– Minimum policed size
– Maximum packet size
RSVP
- Conclusions
 Reservations are “soft”
– Periodic refresh is necessary
 It is a network (control) protocol
– Works in parallel to TCP and UDP
 APIs are required to specify flow requirements
 Reservations are receiver-based
 Has to maintain a state for each flow
 Multicast reservations
– Merged at replication points, difficult to understood algorithms
have to be used though
DiffServ
- Prioritization

 Description
– Applied on flow aggregates
– Services requirements are classified
– Classification is performed at network ingress points
– A predefined per-hop behavior (PHB) is applied to
every service class
– Traffic is smoothed according to PHB applied
DiffServ
- Traffic Classes

Two traffic classes are available :

– Expeditied Forwarding (EF) - 1 codepoint
 Minimizes delay and jitter
 Provides the highest QoS
 Traffic that exceeds the traffic profile is discarded

– Assured Forwarding (AF) - 12 codepoints

 4 classes, 3 drop-precedences within each class
 Traffic that exceeds the traffic profile is not delivered with
such high probability
DiffServ
- Implementation

Classifier Conditioner

Maps DSCPs to Applies the

PHBs defined PHB
Marker Meter
(scheduling)

Maintains Accumulates
DSCP statistics
mappings and
associations
with local
policies
DiffServ
- Implementation
 DiffServ codepoints (DSCPs) redefine the Type-of-Service
(ToS) IPv4 field
 Precedence bits are preserved
 Type-of-Service bits are NOT

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

DSCP CU Precedence Type of Service MBZ

Class Selector Unused RFC 1122 RFC 1349

Must
Be
Zero
Differenciated Services
Codepoint (DSCP) IP Type of Service (TOS)
DiffServ
- Conclusions
 Traffic classes are equivalent to IP precedence service
descriptors
– DiffServ unaware routers pass-through DiffServ traffic
 Easy to be implemented / integrated even into the
network core.
 Proper classification can lead to efficient resource
allocation and though improved QoS
MPLS
- Label Switching
 Used to establish fixed bandwidth routes (similar to
ATM virtual circuits)
 Resides only on routers and is protocol independent
 Traffic is marked at ingress and unmarked at egress
boundaries
 Markings are used to determine next router hop (not
priority)

The aim is to simplify the routing process …

MPLS
- Implementation
 The 1st hop router, using the header information (destination
address etc.) attaches a label and forwards the packet
 Every MPLS-enabled router uses the label as an index to a table
defining the next hop and label

20 3 1 8

Label Value Exp . S TTL

20-bits : Label value used for lo okup 3-bits : Reserved 8-bits : Time-To-Live
1-bit : Bottom of Label Stack
MPLS
- Conclusions
 Labels can be “stacked”
– This allows MPLS “routes within routes”
 Label Distribution Protocol (LDP)
– Distributes labels across MPLS-enabled routers
– Ensures they agree on the meaning of labels
– Usually transparent to network managers
 Implication :
– Define a policy management that distributes labels
SBM
- Subnet Bandwidth Management

 A top-to-bottom QoS approach

 Applies to the Data Link Layer (OSI layer 2)
 Makes LAN topologies (e.g. Ethernet) QoS-
enabled
 Fundamental requirement
– All traffic must pass through at least one SBM-
enabled switch
SBM
- Implementation

 SBM Modules
– Bandwidth Allocator (BA)
 Hosted on switches
 Performs admission control
– Requestor Module (RM)
 Resides in every end-station
 Maps Layer 2 priority levels and the higher-layer QoS
protocol parameters
SBM
- Conclusions

 Much like the RSVP protocol

 Makes the traditional Ethernet, QoS aware
 Introduces an additional indirection in the
routing mechanism
 8-level priority value
QoS Architectures

Host A Host B

Application Application
QoS-enabled
Presentation Presentation
Application
Session Session QoS API

Transport Transport RSVP

Top-to-Bottom QoS

Network Network DiffServ

Data Link Data Link SBM

Physical Physical

SBM

RSVP DiffServ and MPLS RSVP

End-to-End QoS
Protocol Comparison

QoS Net App Description

most x Provisioned resources end-to-end (leased lines)
x x RSVP Guaranteed (provides feedback to application)
x x RSVP Controlled Load (provides feedback to application)
x MPLS (Multi-Protocol Label Switching)
DiffServ applied at network ingress appropriate to RSVP service
x x
level for that flow
x x DiffServ or SBM applied on per-flow basis by source application
x DiffServ applied at network core ingress
x Fair queuing applied by network elements (e.g. WFQ, RED)
least Best effort service
Multicast Environments
 RSVP
– Heterogeneous receivership makes reservation merging a
difficult task
 DiffServ
– Its relative simplicity makes it a better fit for multicast support
 MPLS
– Work is underway, no standards have emerged yet
 SBM
– Explicit support for multicast
Conclusions
 Complexity at the edges – simple network core
– Limit RSVP’s use on the backbone
– Instead use the DiffServ
 DiffServ is a perfect complement for RSVP

 ToDo :
– Performance attributes for each class still missing
– Interworking solution for mapping IP CoS to ATM QoS
References

 http://www.nortelnetworks.com/solutions/collateral/qos_wp.pdf

 http://www.qosforum.com/white-papers/qosprot_v3.pdf

 http://www.qosforum.com/white-papers/Need_for_QoS-v4.pdf