Protocols for QoS Support

Lund University / Presentation 2012

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

Lund University / Presentation 2012

Review/Preview: IntServ

2 service classes, besides best-effort

guaranteed service:
for delay intolerant application, packets never arrive late maximum delay
guaranteed
controlled load service:
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!

Lund University / Presentation 2012

 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

Lund University / Presentation 2012

Resource ReSerVation Protocol (RSVP) Design Goals

Enable receivers to make reservations

Different reservations among members of same multicast
group allowed
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
Re-establish reservations
Need to control protocol overhead
Independent of routing protocol used
Specified in RFC2205

Lund University / Presentation 2012

RSVP Characteristics

Can be used for Unicast and Multicast

Simplex
I.e. unidirectional data flow
Separate reservations in two directions if two-way exchange
Receiver initiated
Receiver knows which subset of source transmissions it wants
Maintain soft state on internet
Its the responsibility of receivers!
Transparent operation through non-RSVP routers

Lund University / Presentation 2012

 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
Unicast or multicast
IP protocol field (rep. next higher level)
TCP, UDP etc.
Destination port
May not be used in multicast

Lund University / Presentation 2012

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

Lund University / Presentation 2012

Treatment of Packets of One Session at One Router

Lund University / Presentation 2012

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

Lund University / Presentation 2012

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

Lund University / Presentation 2012

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

Lund University / Presentation 2012

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

Lund University / Presentation 2012

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

Lund University / Presentation 2012

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

Lund University / Presentation 2012

Multiprotocol support (4)

Lund University / Presentation 2012

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 (forwarding equivalence class)
Each FEC declares QoS requirements
IP header not examined in LSRs
Forward only based on label value

Lund University / Presentation 2012

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

Lund University / Presentation 2012

 FECs, LSPs, and Labels
A FECs path is known as Labelled Switched Path (LSP)
Packets identified by locally significant label
At each LSR, labelled packets forwarded on basis of label
LSR replaces incoming label with outgoing label
Routing protocol ma determine topology and current conditions so LSP can be
assigned to FEC
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

Lund University / Presentation 2012

MPLS Operation Diagram

Lund University / Presentation 2012

 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

Lund University / Presentation 2012

Explanation Packet Handling

Packet enters domain through edge LSR

Processed to determine QoS (thru DS codepoint)
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
Remove incoming label, attach outgoing label and forward
Egress LSR strips label, reads IP header and forwards

Lund University / Presentation 2012

MPLS Packet Forwarding

Lund University / Presentation 2012

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

Lund University / Presentation 2012

Time to Live Processing

Needed to support TTL since IP header not read

Otherwise faulty LSR may result in endless looping
First label TTL set to IP header TTL on entry to MPLS domain
TTL decremented at internal LSR
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

Lund University / Presentation 2012

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!

Lund University / Presentation 2012