Protocols for QoS Support

COMP5416
Chapter 18

Chapter 18 Protocols for QoS

Support

Review/Preview
Approaches to QoS support:
Fine-grained approach

provide QoS to individual applications or

flows
IntServ, RSVP (ATM too)

Coarse-grained approach

provide QoS to large classes of data or

aggregated traffic
DiffServ
Chapter 18 Protocols

Review/Preview: IntServ

2 service classes, besides best-effort

guaranteed service:

controlled load service:

for delay intolerant application, packets never arrive late maximum

delay guaranteed
for adaptive applications that run well if network is not heavily loaded

Mechanisms

Declaring service requirements and characterising the data

(flowspec)
admission control (can we provide requested service to given data)
resource reservation (networks exchange of information)
packet scheduling (actions of routers to meet the requirements)
i.e. queuing discipline!

Chapter 18 Protocols

Resource Reservation Problems

on an Internet

Must interact with dynamic routing

Reservations must follow changes in

route

Thus, keep soft state a set of

state information at a router that
expires unless refreshed

End users periodically renew resource

requests

Chapter 18 Protocols

Resource ReSerVation Protocol

(RSVP) Design Goals

Enable receivers to make reservations

Deal gracefully with changes in group

membership

Dynamic reservations, separate for each member of

group

Receivers can select one of multiple sources (like

channel selection)
Deal gracefully with changes in routes

Different reservations among members of same

multicast group allowed

Re-establish reservations

Need to control protocol overhead

Specified in RFC2205

Chapter 18 Protocols

RSVP Characteristics

Can be used for Unicast and Multicast

Simplex

Receiver initiated

Receiver knows which subset of source

transmissions it wants

Maintain soft state on internet

I.e. unidirectional data flow

Separate reservations in two directions if twoway exchange

Its the responsibility of receivers!

Transparent operation through non-RSVP

routers
Chapter 18 Protocols

Data Flows - Session

Data flow identified by destination

Resources allocated by router for
duration of session
Defined by (used for packet filtering)

Destination IP address

IP protocol field (rep. next higher level)

Unicast or multicast
TCP, UDP etc.

Destination port

May not be used in multicast

Chapter 18 Protocols

Flow Descriptor

Reservation Request includes a flow

descriptor containing a flowspec and a
filter spec
Flowspec:

Specifies the service class

TSpec: a flows traffic characteristics, such as
data rate
RSpec: service requested from network (its
desired QoS)

Filter spec

Set of packets for this reservation

Uses source address & source port

Chapter 18 Protocols

Treatment of Packets of One Session

at One Router

Chapter 18 Protocols

RSVP Protocol Mechanisms

Two message types:
Path

Provide upstream routing information

Used by receivers to make reservation
Issued by sending hosts
Transmitted through distribution tree to
all destinations

Resv (i.e. reserve)

Originate at multicast group receivers

Propagate upstream
Merged and packed as appropriate
Create & store soft states

Chapter 18 Protocols

10

Path reservation

Receiver-oriented approach - receiver needs

to know senders TSpec and the path
sender sends a message with TSpec to
receiver, get reverse path as a bonus

source transmits PATH, receiver responds with RESV

Chapter 18 Protocols

11

MPLS: Background

Efforts to marry IP and ATM as ATM

switching (was) much faster than IP routers
IETF working group formed in 1997,
proposed standard 2001
However, routers developed to be as fast
as ATM switches now!

Remove the need to provide both technologies

in same network

MPLS does provide new capabilities:

QoS support
Traffic engineering
Virtual private networks (VPNs)
Multiprotocol support

Chapter 18 Protocols

12

Connection Oriented QoS

Support (1)

Guarantee fixed capacity for

specific applications
Control latency/jitter

E.g., ensures capacity for voice

MPLS imposes connection oriented

framework on IP based internets

Contrary to RSVPs approach

Chapter 18 Protocols

13

Traffic Engineering (2)

Ability to dynamically define routes, plan

resource commitments based on known
demands and optimise network utilisation
Basic IP allows primitive traffic engineering

E.g. dynamic routing

MPLS makes network resource commitment

easy

Able to balance load in face of demand

Able to commit to different levels of support to meet
user traffic requirements
Aware of traffic flows with QoS requirements and
predicted demand
Intelligent re-routing when congested

Chapter 18 Protocols

14

Virtual Private Network (VPN)

Support (3)
Traffic from a given enterprise or
group passes transparently
through an internet
Dedicated resources for VPNs
Segregated from other traffic on
internet
VPN feature allows:

Performance guarantees
Security
Chapter 18 Protocols

15

Multiprotocol support (4)

Chapter 18 Protocols

16

MPLS Operation

Label switched routers (LSRs) capable of

switching and routing packets based on
label appended to a packet
Labels define a flow of packets between
end points or multicast destinations
Each flow has specific path through LSRs

Connection oriented
Assigned to a FEC (forward equivalence class)

Each FEC declares QoS requirements

IP header not examined in LSRs

Forward only based on label value

Chapter 18 Protocols

17

MPLS Operation II

MPLS domain is contiguous set of MPLS

enabled routers (i.e LSRs)
A FEC (i.e. a flow) determined by:
Source/destination IP address or network IP
address
Port numbers
IP protocol value
DiffServ codepoint or IPv6 flow label
Forwarding is simple lookup in predefined table
Map label to next hop
Packets between same end points may belong
to different FECs
Chapter 18 Protocols

18

FECs, LSPs, and

Labels
A FECs path is known as Labelled Switched Path

(LSP)
Packets identified by locally significant label

Routing protocol must determine topology and

current conditions so LSP can be assigned to FEC

At each LSR, labelled packets forwarded on basis of

label
LSR replaces incoming label with outgoing label

Must be able to gather and use information to support

QoS

LSRs must be aware of LSP for given FEC, assign

label to FEC and communicate label to other
LSRs

Chapter 18 Protocols

19

MPLS Operation Diagram

Chapter 18 Protocols

20

Explanation Connection
Setup
LSP established prior to routing and

delivery of packets
QoS parameters established along
LSP

Resource commitment
Queuing and AQM policies at LSR

Labels assigned

Has local significance only

Manually or using a distribution
protocol
Chapter 18 Protocols

21

Explanation Packet
Handling
Packet enters domain through edge LSR

Ingress LSR assigns packet to FEC and

hence LSP

May need co-operation to set up new LSP

LSR appends label and forwards packet

Other LSR in LSP receives packet

Processed to determine QoS (thru DS codepoint)

Remove incoming label, attach outgoing

label and forward

Egress LSR strips label, reads IP header

and forwards
Chapter 18 Protocols

22

MPLS Packet Forwarding

Chapter 18 Protocols

23

Label Format Diagram

Label value: Locally significant 20 bit

Exp: 3 bit reserved for experimental use
S: 1 for oldest entry in stack, zero
otherwise
Time to live (TTL): hop count or TTL value
Chapter 18 Protocols

24

Time to Live Processing

Needed to support TTL since IP header not read

First label TTL set to IP header TTL on entry to

MPLS domain
TTL decremented at internal LSR

Otherwise faulty LSR may result in endless looping

If zero, packet dropped or passed to ordinary error

processing (e.g. ICMP)
If positive, value placed in TTL of label and packet
forwarded

At exit from domain, TTL decremented

If zero, as above
If positive, placed in TTL field of IP header and
forwarded

Chapter 18 Protocols

25

Summary

RSVP and MPLS protocols used to

provide QoS support
There are other protocols used for
specific type of applications

RTP and SCTP for streaming applications

requiring soft real-time communication

Choice of a suitable protocol and

architecture depends upon user
requirements
To substantiate a choice, performance
studies are required through tools like
queuing theory and simulators!
Chapter 18 Protocols

26

Final Exam Tips

2 questions from Performance part

4 questions from Traffic Control part

Simulation (no coding!)

Queuing analysis
TCP traffic control
ATM traffic control
IntServ framework
RSVP

Main focus on above, but understanding of all

required
You are allowed to bring in one A4 annotated
(double-sided) page
Bring along a calculator (non-programmable)
Chapter 18 Protocols

27