Download QoS Protocols & Architectures

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

AppleTalk wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Peering wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Distributed firewall wikipedia , lookup

Computer network wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Network tap wikipedia , lookup

IEEE 1355 wikipedia , lookup

Airborne Networking wikipedia , lookup

Internet protocol suite wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Deep packet inspection wikipedia , lookup

Net bias wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Quality of service wikipedia , lookup

Transcript
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
 Similar to Internet today
 No minimum information rate
guaranteed
 Best-effort delivery
 Unmanaged performance
2
 Mission-critical data
 VPN outsourcing, ecommerce
 Similar to ATM VBR
 Low loss rate
 Controlled delay and delay
variation
3
 Real time applications
 Video streaming, voice,
videoconferencing
 Low loss rate
 Low delay and delay variation
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
f ic
n
Traf ificatio
c
Sp e
H
PAT
Host A
Qo
S
and Lev
el
F ilt
er
Sp
eci
f i ca
tion
RE
SV
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”
–

It is a network (control) protocol
–




Periodic refresh is necessary
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
Maps DSCPs to
PHBs
Conditioner
Marker
Maintains
DSCP
mappings and
associations
with local
policies
Meter
Accumulates
statistics
Applies the
defined PHB
(scheduling)
DiffServ
- Implementation



0
DiffServ codepoints (DSCPs) redefine the Type-of-Service
(ToS) IPv4 field
Precedence bits are preserved
Type-of-Service bits are NOT
1
2
3
4
5
DSCP
Class Selector
Differenciated Services
Codepoint (DSCP)
6
7
0
1
2
CU
Precedence
Unused
RFC 1122
3
4
5
6
Type of Service
RFC 1349
IP Type of Service (TOS)
7
MBZ
Must
Be
Zero
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 lookup
3-bits : Reserved
8-bits : Time-To-Live
1-bit : Bottom of Label Stack
MPLS
- Conclusions

Labels can be “stacked”
–

Label Distribution Protocol (LDP)
–
–
–

This allows MPLS “routes within routes”
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) QoSenabled
Fundamental requirement
–
All traffic must pass through at least one SBMenabled 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
Top-to-Bottom QoS
QoS Architectures
Host A
Host B
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
RSVP
Netw ork
Netw ork
DiffServ
Data Link
Data Link
SBM
Physical
Physical
SBM
RSVP
DiffServ and MPLS
End-to-End QoS
RSVP
QoS-enabled
Application
QoS API
Protocol Comparison
QoS
most
Net App Description
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
least
MPLS (Multi-Protocol Label Switching)
x
x
DiffServ applied at network ingress appropriate to RSVP service
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)
Best effort service
Multicast Environments

RSVP
–

DiffServ
–

Its relative simplicity makes it a better fit for multicast support
MPLS
–

Heterogeneous receivership makes reservation merging a
difficult task
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