QoS và MPLS

Tutor: Lưu Thanh Trà

Email: luu@hcmut.edu.vn

1
 QoS (Quality of Service)

 There is really a need for QoS (RFC1633)?

 NO
 Bandwidth is infinite thanks to the emergence of new
transmission technologies, the installation of new cables
 Difficult to implement a QoS approach
 Applications can adapt
 YES
 Bandwidth demand increases exponentially while supplied
bandwidth increases linearly
 Applications only adapt as the available bandwidth varies in
a limit range
 By supplying different QoS, ISPs can get more benefit

2
 Players in the QoS

 ISP, Internet Service  Subscribers

Providers  get as much bandwidth
 utilize their resources to as they can from ISP
the maximum  reliable connection
 get as many subscribers  zero down time if
as they can possible

3
 Service Level Agreement (SLA)
 Service Level Agreement.
 The SLA is a contract between the service provider and the
customer. The SLA can be applied to a customer, a group of
customer, to a group of business.
 SLA consist of:
 Availability

 Services offered
 Service Guarantees

 Responsibilities

 Auditing the service

 Pricing

4
 QoS Characteristics

 Service availability
 Delay

 Delayvariation
 Throughput

 Packet loos rate

5
 QoS Characteristics

 Latency
 Latency or a propagation time is referred to the time it takes to send a message
from the sender until to the time the receiver receives.

 Router Latency
 It’s the time it takes to the router to retransmit the packet that it had received
from the time it had arrived to the router.

 Jitter (Delay variation)

 Refers to the variation in time duration in all packets in stream taking the same
route. For instance, when sending a video or audio stream over the network
and the packets don’t arrive in the order that was sent on a timely basis. This
creates a distortion of the signal, which is very harmful to multimedia.

6
 QoS Characteristics
 Bandwidth
 Bandwidth is the ideal capacity that the network can operate. The networks
never work on ideal maximum capacity since there are negative factors that
cause deterioration of the quality of the network. Such as factors can be
transmission delay, noise and etc.

 Packet Loss
 Packet loss takes in place when we are experiencing congestion on our
network. In the event of the congestion the network can discard this packet,
which are defined by this parameter.

 Service Availability
 Availability is the reliability of the user’s connection to the Internet service.
To be able to do this we use Service Level Agreement (SLA).

7
Integrated Services - motivation

 Many applications are sensitive to the effects of delay, jitter and

packet loss

 The existing Internet architecture provides a best effort service

 All traffic is treated equally (FIFO queuing). Currently there is no

mechanism for distinguishing between delay sensitive and best effort
traffic.
 IPv4 TOS is not widely implemented.

 Aim of IntServ WG: to specify the enhanced services needed in the

Internet service model to support the integration of real-time and
“classical” data traffic.

8
Integrated Services Architecture

 Integrated Services (IntServ) expands congestion

control to include reservation of resources:

 Signalling through Resource Reservation Protocol (RSVP)

 Specification of traffic characteristics and QoS

 Admission control
 Policing and shaping of traffic
 Scheduling of flow packets

9
 Key Components
QoS routing agent Admission control

Reservation setup agent

Resource reservation table

Control plane

Flow identification Packet scheduler

Data plane

10
 Control Plane sets up resource reservation

 Data plane forwards data packets based on reservation

state.

 To setup reservation, app first characterizes its traffic flow

and specifies QoS requirements : referred to as flow
specification

 The reservation setup request is then sent to the network.

11
 Router upon getting the request, interacts with QoS
routing agent to find the next hop.

 It then coordinates with the admission control module

to determine if there are sufficient resources to meet
the requested resources.

 Once reservation set up is successful, the information

for the reserved flow is installed into the resource
reservation table.

 Information in the resource reservation table is used to

configure flow identification module and the packet
scheduling module in the data plane.
12
 Route Selection
 IntServ does not specify any route selection
of its own.
 It relies on existing routing protocols to
forward its control packets further.
 Obviously a more efficient routing protocol
which can find a path that is likely to have
sufficient resources is desired.

13
 Reservation Setup
 To setup reservation a reservation set up
protocol is needed that goes hop by hop
along the path to install the reservation state
in the routers.
 The reservation protocol must also deal with
changes in the network topology.
 In IntServ, RSVP has been developed as the
resource reservation protocol.

14
 Admission Control
 In order to provide guaranteed resources for
reserved flows, a network must monitor its
resource usage and admit a new flow only if it
has sufficient resource.
 It has two functions : to determine if a new
flow reservation can be set up based on the
admission control policies and to monitor and
measure the available resources.

15
 Admission Control (Cont’d)
 Two basic approaches:
 Parameter
based
 Measurement based

16
 Measurement based
 Admission control module measures the
actual traffic load and uses that info while
admitting a new flow.
 Since traffic sources are not static, this
method is probabilistic in nature.
 So cannot be used to provide tight
guarantees.
 Measurements can be done in a number of
ways
17
 Measurement Based (cont’d)
 Exponential averaging :
 New estimate = (1-w) * old estimate +
w * new measurement
 Time window approach:
 Average arrival rate is measured over a sampling interval. At the
end of measuring period the highest average is used as the
estimated rate.
 If there are n sampling intervals in a measurement period T and
Ci is the average measured over sampling interval I, then
estimated rate = max [C1, C2, …., Cn]

18
 Parameter Based
A set of parameter used to precisely
characterize traffic flows
 Admission control agent then calculates the
required resources based on these
parameters
 Not easy to provide tight traffic models : may
lead to over or under utilization of resources.

19
 Flow Identification
 Router must examine every incoming packet
and decide whether the packet belongs to
one of the reserved flows.
 IP flow is identified by src addr, dest addr,
proto ID, src port, dst port : five-tuple.
 These five fields of the incoming packet is
compared against the five-tuple of all the
flows in the reservation table for flow
identification.
20
Integrated Services Architecture

1) Tspec (sender traffic spec)

Tx ADSpec (services, possibly modified by routers)

Rx
2) Tspec (reservation traffic spec)
RSpec (reservation service request)
Service class

21
 Fluid Model Scheduling
 If an element approximates the “fluid model” then the service
received will be the same as a wire with bandwidth equal to
the service rate.

Tx Rx
Fluid model scheduler with service
rate, R.
Tx Rx
wire with bandwidth R

 Aim is to isolate traffic flows from each other. D=b/R

22
Relationship between service, traffic,
loss and delay bounds

bits traffic arrival

traffic service

backlog

busy period time

23
 Traffic Specification

 To date, one general traffic specification parameter has been

defined (RFC 2215): TOKEN_BUCKET_TSPEC
 Consists of:
 float r token rate (bytes/sec)
 float b bucket depth (bytes)
 float p peak rate (bytes/sec)
 unsigned m minimum policed unit (bytes)
 unsigned M maximum packet size (bytes)
 RSPEC consists of:R requested rate (bytes/sec)
S delay slack
(microseconds)
24
 Service Categories

 Guaranteed Service
 Mathematically provable upper bound on queuing
delay, assured data rate, no loss
 Hard real-time applications
 Controlled Load
 Approximates best-effort service under unloaded
conditions
 Adaptive real-time applications
 Best effort

25
 FIFO
 First Arrival, First Transmission
 simple to implement!
 Completely dependent on arrival time
 No notion of priority or allocated buffers
 No space in queue, packet discarded
 Used in, e.g., IP Internet

Arrival N Departure
Full? Processor
Queue
Discard Y

26
 Weighted Robin Round
 if only one arrival queue -> it gets full bandwidth
 if n arrival queues -> each gets 1/n of bandwidth
 Each queue has a priority

Transmission queue
Arrival queues

Round robin

27
 Q1 Q3

Assign:
33%/66%
Q2

 example:
 A T3 trunk with 500 connections, each connection has mean packet
length 500 bytes: 250 with weight 1, 250 with weight 10

 Each packet takes 500 * 8/45 Mbps = 88.8 microseconds

 Round time =2750 * 88.8 = 244.2 ms

28
 Problems with Weighted Round Robin

 Unfair if packets are of different length or weights

are not equal
 With variable size packets and different weights,
need to know mean packet size in advance
 Can be unfair for long periods of time

29
 Suggestion: Weighted Fair Queuing (WFQ)
 Deals better with variable size packets and weights:

 assign a relative weight to each queue ( higher priority queues get

a larger piece of the pipe).
 the weight is a relative value--not a guaranteed bandwidth rate!
 Actual bandwidth for each queue at any given moment depends
on # of queues using the pipe and on the relative weights of each
of those queues.

By default, WFQ favors lower-volume traffic flows over

higher-volume ones (for example, a routine e-mail
over a large FTP download).
30
31
 WFQ Algorithm

 Suppose, in each round, the server served one bit

from each active connection (GPS)
 Compute R=Round number = the number of
rounds already completed (can be fractional)
 for each packet, Compute f=finish number = round
number when a packet will complete its service
 Serve packets in order of finish numbers

32
 WFQ Computation
a packet of length p arriving to an empty queue when the round number is R,
Ideally, it will complete service when the round number is => f = R + p
(independent of the number of other connections!)

a packet arrives to a non-empty queue, and the previous packet has a finish
number of f, will have a finish number => f = (previous) f+p

Problem: we need to determine

• is the connection active?
• if not, what is the current round number?

Solution: Redefine round number as

a real-valued variable that increases at a rate inversely
proportional to the number of currently active connections 33
 Delay-Earliest Due Date (Delay-EDD)
 Delay-EDD prescribes how to assign deadlines to packets

° Earliest-due-date = packet with earliest deadline selected

° Deadline = expected arrival time + delay bound

Implementation:
 A source is required to send slower than its peak rate
 Bandwidth at scheduler reserved at peak rate
 Each packet gets a hard delay bound
 Delay bound is independent of bandwidth requirement
 but reservation is at a connection’s peak rate
 Implementation requires per-connection state and a priority queue

34
 Rate-controlled scheduling
 A class of disciplines
 two components: regulator and scheduler
 incoming packets are placed in regulator where they wait
to become eligible
 then they are put in the scheduler
 Regulator shapes the traffic, scheduler provides
performance guarantees

35
 Virtual Clock
(L. Zhang, 1991)

 Scheduling of packets based on when packets would have

been sent if TDM were used.
 Timers VC (flow monitoring) and auxVC (packet scheduling)
 On packet arrival both timers are advanced to next packet
eligibility time.
 After a set number of packets (AI*AR), VC is compared to a
real-time clock (RTC).
 If VC > RTC restrict flow
 If VC < RTC, VC=RTC (prevent higher rate in subsequent
interval)
 VC updates are packet based. AuxVC avoids saving “credits”

36
Guaranteed Service

37
 Guaranteed Service
 Provides guaranteed bandwidth and strict
bounds for delay.
 Intended for apps that require highest
assurance on bw and delay : mission critical
apps, intolerant playback apps.
 Can be viewed as a virtual circuit with
guaranteed bw.
 Provides bounds on maximal queuing delay.

38
Integrated Services Architecture

1) Tspec (sender traffic spec)

Tx ADSpec (services, possibly modified by routers)

Rx
2) Tspec (reservation traffic spec)
RSpec (reservation service request)
Service class

39
 Guaranteed Service (cont’d)
 Apps invoke guaranteed service by specifying a traffic
descriptor (TSpec) and a service spec (RSpec) to the
network.
 TSpec describes traffic sources with following
parameters:
 Bucket rate (r) : rate at which tokens arrive.
 Peak rate (p) : max rate for packet transmission
 Bucket depth (b) : size of token bucket
 Min policed unit (m) : any packet with size lass than m will be
counted as size m.
 Max packet size (M) : Max packet size accepted.
40
41
 Guaranteed Service (cont’d)
 RSpec is specific to guaranteed service
 Describes service requirements with two
params:
 Service rate (R) : bandwidth requirement
 Slack term (S) : the extra delay that a node may
add and still meet the end-to-end delay.

42
 Delay calculation
 Given the TSpec and RSpec the worst case
end-to-end queuing delay for a flow can be
calculated.
 Assume a fluid model and traffic source is
constrained by token bucket params (r, b, p)
 If p is very large compared to R and r, then
the worst case queuing delay = AB = b/R.

43
Delay Calculation(Cont’d)
bits

A B
R

time
O

44
 Delay Calculation(Cont’d)
 Ifp is comparable to R and r, then the worst
case delay is AC =
b (p – R) / R (p – r) (p > R ≥ r)

45
Delay Calculation(Cont’d)

A
C

F E
R

b
p

O D
B

46
 Delay calculation (Cont’d)
 In real network fluid model does not apply.
 So two error terms are introduced: Error term C is rate
dependent and represents the delay that a packet
experiences due to rate parameter and packet length
(store and forward model).
 Error term D is rate independent : delay due to route
lookup, flow identification.
 End-to-end sums of C and D over a path are Ctot and
Dtot

47
 Delay calculation (Cont’d)
 Incorporating the error terms and packet
lengths, the worst-case queuing delay :
[(b –M) (p–R) / R(p-r)] + [(M+Ctot)/R] + Dtot
(p > R ≥ r)
[(M + Ctot) / R] + Dtot (R ≥ p ≥ r)

48
 Policing and Shaping
 Trafficflows that receive guaranteed service
must conform to the token bucket and peak
rate params over all periods.
 For any period T, the amount of data sent
cannot exceed M + Min (pT, rT+b-M).
Packets smaller than min policing unit m are
counted as m.
 Policing is done at the edge of the network by
comparing the traffic to the agreed TSpec
params.
49
 Policing and Shaping
 Shaping is done at all heterogeneous branch
points and all merging points.
 Heterogeneous branch point is a spot where
a multicast distribution tree has multiple
outgoing branch that have different TSpecs.

50
Controlled load service

51
 Controlled load service
 Strict bw assurance and delay bound comes at a price
: resources have to be reserved for the worst case.
 For some apps a service model with less strict
guarantees and lower cost would better serve their
needs.
 End-to-end behavior somewhat vague.
 A very high percentage of packets will be successfully
delivered by the network to the receivers.
 The transit delay experienced by a very high
percentage of packets will not greatly exceed min
delay.

52
Resource Reservation
Protocol (RSVP)

53
 RSVP
A resource reservation protocol defined for
IntServ.
 Used by hosts to communicate service
requirements to the network and by routers in
the network to establish reservation state
along a path

54
 Basic Features
 Simplex Reservation :
 Makes reservation only in one direction.
 Treats sender as logically distinct from a receiver

 For two way communication, the two ends must

establish reservation for both directions.
 Receiver Oriented
 Receivers of a flow initiates and maintains the
resource reservation.

55
 Basic Features (Cont’d)
 Routing Independent
 Designed to operate with current and future unicast
and multicast routing protocols
 The path for a flow is done separately by routing
protocols
 Policy Independent
 RSVP transports and maintains traffic control and
policy control parameters that are opaque to RSVP
 Control params are passed to relevant control
modules for processing.

56
 Basic Features (Cont’d)
 Soft State
 RSVP maintains soft states providing graceful
support for dynamic membership changes and
automatic adaptation to routing changes.
 Reservation state has a timer associated with the
state. When timer expires, the state is
automatically deleted.
 RSVP periodically refreshes the reservation state
to maintain the state along the paths.

57
 Basic Features (Cont’d)
 Reservation Style
 RSVP provides several reservation models or
styles to fit a variety of applications
 Can be used to share a reservation among traffic
streams from multiple senders or to select a
particular sender.

58
 Data Flows
 RSVP defines a session to be a data flow
with a particular destination and transport
layer protocol.
 RSVP session defined by the triple
(destAddr, ProtoId, [dstPort]).

59
 Reservation Model
 RSVP reservation request consists of a flowspec
together with a filter spec.
 flowspec specifies a desired QoS
 Filterspec along with a session specifies a flow.
 Flowspec used to set params in the node’s packet
scheduler
 Filterspec used to set the params of the packet
classifier.

60
 Reservation Model (Cont’d)
 Flowspec include a service class (guaranteed
or controlled load) and two sets of numeric
params RSpec (desired QoS) and a TSpec
(describes traffic).

61
 Protocol Overview

PATH
(1) (2) (3)

(6) (5) (4)

RESV

62
 Protocol Overview (cont’d)
Sender 1
RESV
PATH RESV

Sender 2 PATH
R R

PATH RESV

R RESV
R
PATH

Receiver A
R

Receivier B

63
 Protocol Overview (Cont’d)
 Two primary RSVP msgs : PATH and RESV
 PATH msgs are sent from source towards the receivers.
 Used to pass characteristics of the path.
 Installs path state in each node along the way
 Includes IP address of previous hop (needed to send RESV msg)

 Sender template : sender IP address and port

 Sender Tspec : traffic spec of sender

 After receiving PATH msg receiver can request a reservation

by sending RESV msg.

64
 Protocol Overview (Cont’d)
 RESV must follow the exact same reverse
path upstream.
 They create reservation state in each node
along the paths
 After receiving RESV msg sender can start
sending data packets.

65
 PATH Message
 Contains previous hop, sender template,
sender TSpec and the AdSpec.
 Sender template contains info that along with
Session uniquely identifies the flow.
 It has same format as filterspec.
 Sender TSpec characterizes the traffic that
sender will generate.

66
 PATH Message (Cont’d)
 AdSpec is an optional element in PATH msg :
used to carry OPWA (One Pass with
Advertising)
 Passed to local traffic control at each node, which
returns an updated AdSpec, the updated version
is then forwarded in PATH msg downstream.

67
 RESV Message
 Sent by receivers towards sender along
reverse direction of PATH msg to request
reservation.
 Contains info about reservation style,
flowspec object and filterspec object.
 Flowspec includes a service class,
reservation spec (RSpec) that defines the
desired QoS and a traffic spec (TSpec) that
describes the traffic flow.
68
 RSVP Message Formats
 Each RSVP message begins with a common
header followed by a series of variable-length
RSVP objects.
 Common Header
00 1 2 3

vers flags Msg type RSVP checksum

Send_TTL reserved RSVP length

69
 RSVP Message Formats
(Cont’d)
 Version : 4 bits
 Protocol version number : Current version is 1
 Flags : 4 bits
 Reserved

 Msg Type: 8 bits

1 = Path
 2 = Resv

 RSVP checksum: 16bits

70
 RSVP Message Formats
(Cont’d)
 Send_TTL: 8bits
 IP TTL value with which the message was sent
 RSVP length : 16bits
 Totallength of the RSVP message in bytes
including the common header.

71
 Object Formats
 Every RSVP object consists of one or more
32-bit words with a one-word header with the
following format:
0 1 2 3

Length (in bytes) Class-Num C-type

Object contents

72
 Object Formats (cont’d)
 Length : length of the object in bytes
 Class-Num : Identifies the object class.
 SESSION

 FLOWSPEC

 SENDER_TSPEC

 C-type : Object type unique within Class-Num.

73
 PATH message

<Path Message> ::= <Common Header>

[<INTEGRITY>] <SESSION> <RSVP_HOP>
<TIME_VALUES> [<POLICY_DATA>]
[<sender descriptor>]
<Sender descriptor> ::=
<SENDER_TEMPLATE>
<SENDER_TSPEC> [<ADSPEC>]

74
 RESV message

<Resv Message> ::= <Common Header>

[<INTEGRITY>] <SESSION> <RSVP_HOP>
<TIME_VALUES> [<RESV_CONFIRM>]
[<SCOPE>] [<POLICY_DATA>] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= <empty> | <flow
descriptor list> <flow descriptor>

75
 PATH Tear message

<PATH Tear Message> ::= <Common Header>

[<INTEGRITY>] <SESSION> <RSVP_HOP>
[<sender descriptor>]

 Path Tear is initiated by sender or by path

state timeout.
 Deletes matching Path state.

 Travel downstream towards all receivers

76
 RESV Tear message
<Resv Tear Message> ::= <Common Header>
[<INTEGRITY>] <SESSION> <RSVP_HOP>
[<SCOPE>] <STYLE> <flow descriptor list>

 Resv Tear is initiated by receiver or by resv

state timeout.
 Deletes matching resv state.
 Travels upstream towards all matching
senders.
77
 PATH Error message

<PathErr Message> ::= <Common Header>

[<INTEGRITY>] <SESSION>
<ERROR_SPEC> [<POLICY_DATA>]
[<sender descriptor>]
 Reports error in processing PATH msg

 Travel upstream towards sender

78
 RESV Error message
<ResvErr Message> ::= <Common Header>
[<INTEGRITY>] <SESSION> <RSVP_HOP>
<ERROR_SPEC> [<SCOPE>]
[<POLICY_DATA>] <STYLE> <error flow
descriptor>
 Reports error in processing RESV msg.
 Or may report spontaneous disruption of a
reservation
 Travel downstream towards appropriate
receivers.
79
 RESV Confirm message

<ResvConf Message> ::= <Common Header>

[<INTEGRITY>] <SESSION>
<ERROR_SPEC> <RESV_CONFIRM>
<STYLE> <flow descriptor list>
 Sent to acknowledge reservation request

 Sent when RESV_CONFIRM object is

present in RESV message.
 Sent to receiver host from sender.

80
 Reservation Styles
 Reservation request includes a set of options
that are collectively called reservation style.
 Decides whether distinct reservation for each
upstream sender or else make a single
reservation that is shared among selected
senders.

81
 Reservation Styles (Cont’d)
sender selection Reservation:
distinct shared

Explicit Fixed filter (FF) Shared explicit

(SE)

wildcard Not defined Wildcard filter

(WF)

82
 Reservation Style (Cont’d)
 Wildcard-filter (WF) style
 Implies shared reservation and wild card sender
selection
 All receivers share a single reservation whose
size is the largest of the resource requests from
the receivers; all upstream senders can use the
reservation.
 Can be represented as WF (*, {Q}), where * is the
wildcard sender and Q is the flowspec.

83
 Reservation Style (Cont’d)
 Fixed-filter (FF) style
 Distinct reservation and explicit sender selection.
 Distinct reservation established for specific
sender
 Can be represented as FF (S (Q ), S (Q ), ..)
1 1 2 2

84
 Reservation Style (Cont’d)
 Shared explicit (SE) style
 Shared reservation but explicit sender selection
 Creates a single reservation shared by specific
senders
 Represented as SE((S , S , …., S ) {Q}).
1 2 n

85
 Example

(a) (c)
S1 R1

(b) (d)
R2
S2, S3
R3

86
 Wildcard-Filter

Sends Reserves Receives

WF(*{4B})  (a) (c) *{4B} (c)  WF(*{4B})

(d)  WF(*{3B})
WF(*{4B})  (b) (d) *{3B}  WF(*{2B})

87
 Fixed-Filter

Sends Reserves Receives

FF(S1{4B})  (a) (c)S1{4B} (c)  FF(S1{4B}, S2{5B})

S2{5B}

(d)  FF(S1{3B}, S3{B})

FF(S2{5B}, S3{B})  (b) (d)S1{3B}
 FF(S1{B})
S3{B}

88
 SE-Filter

Sends Reserves Receives

SE(S1{3B})  (a) (c)(S1,S2){B} (c)  SE(S1,S2{B})

(d)  SE(S1, S3{3B})

SE(S2,S3{3B})  (b) (d)(S1,S2,S3){3B}
 SE(S2{2B})

89
 OPWA
 Basic reservation model in RSVP is one pass.
 It is not possible to determine characteristics
of the path or whether the path is able to
support the desired QoS.
 Other model, OPWA (One Pass with
Advertising) is more sophisticated which uses
AdSpec.
 Sender includes an AdSpec in its PATH msg
to collect info about the path.

90
 OPWA (Cont’d)
 Receiver can use information in the AdSpec to determine
end-to-end characteristics of the path and calculate end-to-
end delay.
 Has three components :
 Default general parameters
 Guaranteed service fragment
 Controlled load service fragment
 Default general parameters
 Min path latency : sum of fixed delay along the path in addition to
queuing delay.
 Path bandwidth : min bandwidth of the path
 Integrated services hop count : total number of hops that are capable
of supporting IntServ.
 Global break bit : set to 0 by sender. Set to 1 if any node along the
path does not support RSVP
 Path MTU : MTU of the path.

91
 OPWA (Cont’d)
 Guaranteed service fragment includes Ctot,
Dtot, Csum, Dsum and optional values that
override default general params
 Controlled load service fragment does not
require any extra data, but may contain
optional values that override default general
params.

92
 Flow Identification
 An important module in the data plane.
 In an integrated services network, a router
has to extract the five tuple from an incoming
packet and compare it against the reservation
table to see if it belongs to a reserved flow
 Packet processing has to happen very fast
(on OC12 link (622 Mbps), it is of the order of
micro seconds).
 FlowIdentification should happen at a high
speed.
93
 Design Choices
 Tradeoff between speed vs space
 One extreme is direct memory lookup
 Singlememory access
 Requires high storage
 Five-tuple is 104 bits long
 Other extreme is binary search
 Efficientin terms of storage space
 But relatively slow

 Compromise is to use hashing based scheme

94
 Hashing based scheme
0

Collision resolution table

M

N Reservation table
Hash table
95
 Hashing based scheme
 XOR folding of source and destination IP address
 H(.) = A1 xor A2 xor …. An
 Ai is the substring with i bit to i+m bit of the 64-bit string
 No need to get fourth layer info (port)
 XOR folding of destination IP address and
Destination port
 Suitable for web-based application where the source addr
and source port may be the same for flows, but destination
addr and destination port may be different

96
 Hashing based scheme
 XOR folding of the five tuple
 Likely to perform better for scheme that uses the
full five tuple.
 Similar to other schemes except that 104 bits are
used in hash calculation

97
 Hashing based scheme
 32-bit CRC has been widely used for error detection
in communication systems
 Known for exploiting the randomness in traffic well
 CRC32 of five tuples as hash function
 Double hashing
 Used to significantly reduce collision rate
 If there is a collision with first hashing function, a second
hashing function is used
 Probability of collision with two hashing function is low
 More complex because of two level of hashing.

98
 RSVP summary

 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

99
 IntServ References
 R. Braden, D. Clark, S. Shenker, “Integrated Services in
the Internet Architecture: an Overview”, RFC1633
 J. Wroclawski, “The Use of RSVP with IETF Integrated
Services”, RFC2210.
 J. Wroclawski , “Specification of the Controlled-Load
Network Element Service”, RFC2211
 S. Shenker, C. Patridge, R. Guerin, “Specification of
Guaranteed Quality of Service, RFC2212
 R. Braden, L.Zhang et. al., “Resource Reservation
Protocol (RSVP)”, RFC2205.

100
 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

101
 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

102
 DiffServ - Implementation

C la s s if ie r C o n d it io n e r

M a p s D S C P s to A p p lie s th e
PH Bs d e fin e d P H B
M a rk e r M e te r
( s c h e d u lin g )

M a in ta in s A c c u m u la t e s
D SC P s t a t is tic s
m a p p in g s a n d
a s s o c ia tio n s
w ith lo c a l
p o lic ie s

103
 DiffServ - Implementation
 DiffServ codepoints (DSCPs) redefine the Type-of-
Service (ToS) IPv4 field
 Precedence bits are preserved
 Type-of-Service bits are NOT
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

DSCP CU P re c e d e n c e T y p e o f S e r v ic e M BZ

C la s s S e le c t o r U nused R FC 1122 RFC 1349

M ust
B e
Z e ro
D if f e r e n c ia t e d S e r v ic e s
C o d e p o in t (D S C P ) IP T y p e o f S e r v ic e ( T O S )

104
 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

105
 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 …

106
 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

L a b e l V a lu e Exp. S TTL

2 0 - b it s : L a b e l v a lu e u s e d f o r lo o k u p 3 - b its : R e s e r v e d 8 - b it s : T im e - T o - L iv e
1 - b it : B o t to m o f L a b e l S t a c k

107
 MPLS - Conclusions

 Labels can be “stacked”

 This allows MPLS “routes within routes”
 Label Distribution Protocol (LDP)
 Distributeslabels 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

108
109