Transcript Chapter 18

Protocols for QoS Support
COMP5416
Chapter 18
Chapter 18 Protocols for QoS
Support
1
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 for QoS
Support
2
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 for QoS
Support
3
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 for QoS
Support
4
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 for QoS
Support
5
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 two-way
exchange
It’s the responsibility of receivers!
Transparent operation through non-RSVP
routers
Chapter 18 Protocols for QoS
Support
6
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 for QoS
Support
7
Flow Descriptor

Reservation Request includes a flow
descriptor containing a flowspec and a filter
spec

Flowspec:




Specifies the service class
TSpec: a flow’s 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 for QoS
Support
8
Treatment of Packets of One Session at
One Router
Chapter 18 Protocols for QoS
Support
9
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 for QoS
Support
10
Path reservation


Receiver-oriented approach - receiver needs to
know sender’s 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 for QoS
Support
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)
18 Protocols for QoS
MultiprotocolChapter
support
Support
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 RSVP’s approach
Chapter 18 Protocols for QoS
Support
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 for QoS
Support
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 for QoS
Support
15
Multiprotocol support (4)
Chapter 18 Protocols for QoS
Support
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 for QoS
Support
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 for QoS
Support
18
FECs, LSPs, and Labels


A FEC’s 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 for QoS
Support
19
MPLS Operation Diagram
Chapter 18 Protocols for QoS
Support
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 for QoS
Support
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 for QoS
Support
22
MPLS Packet Forwarding
Chapter 18 Protocols for QoS
Support
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 for QoS
Support
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 for QoS
Support
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 for QoS
Support
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 for QoS
Support
27