QoS Protocols & Architectures

1
QoS Protocols Architectures

• by
• Harizakis Costas

2
Presentation Flow

• QoS defined
• QoS protocols
• RSVP, DiffServ, MPLS, SBM
• QoS architectures
• QoS and multicast environments
• Protocol comparison
• conclusions !

3
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

4
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

5
QoS Metrics

• Performance attributes
• Service availability
• Delay
• Delay variation (jitter)
• Throughput
• Packet loss rate
• Vary according to Service Level Agreement (SLA)

6
Service Level Agreements (SLA)
7
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)

8
QoS Protocols

• ReSerVation Protocol (RSVP)
• Differentiated Services (DiffServ)
• Multi Protocol Labeling Switching (MPLS)
• Subnet Bandwidth Management (SBM)

9
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

10
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

11
RSVP - Implementation
12
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)

13
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

14
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

15
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

16
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

17
DiffServ- Implementation
18
DiffServ- Implementation

• DiffServ codepoints (DSCPs) redefine the
  Type-of-Service (ToS) IPv4 field
• Precedence bits are preserved
• Type-of-Service bits are NOT

19
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

20
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

21
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

22
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

23
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

24
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

25
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

26
QoS Architectures
27
Protocol Comparison
28
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

29
Conclusions

• Complexity at the edges simple network core
• Limit RSVPs 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

30
References

• http//www.nortelnetworks.com/solutions/collateral
  /qos_wp.pdf
• http//www.qosforum.com/white-papers/qosprot_v3.pd
  f
• http//www.qosforum.com/white-papers/Need_for_QoS-
  v4.pdf