Integrated Services

1
Integrated Services

• CS680
• Prof. A. Sahoo

2
Integrated Services

• Early 1990 IETF started Integrated Services
  working group to standardize a new resource
  allocation architecture.
• Based on a per flow resource reservation.
• Goal is to preserve the datagram model of
  IP-based networks and at the same time support
  resource reservation for real-time applications.

3
Basic Approach

• A set of mechanisms and protocols is used for
  making explicit resource reservation.
• To receive performance guarantee from the network
  resource reservation must be set up before the
  application can start transmitting packets.

4
Basic Approach (Contd)

• Sender starts the setup of a reservation by
  sending characteristics and resource requirement
  of the flow.
• The network can accept the new application flow
  only if sufficient resource is available.
• Once reservation is setup successfully,
  application can start sending data packets.

5
Key Components
QoS routing agent
Admission control
Reservation setup agent
Resource reservation table
Control plane
Flow identification
Packet scheduler
Data plane
6
Key Component (contd)

• 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.

7
Key Component (contd)

• 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 QoS.
• Once reservation set up is successful, the
  information for the reserved flow is installed
  into the resource reservation table.
• Info. in the resource reservation table is used
  to configure flow identification module and the
  packet scheduling module in the data plane.

8
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.

9
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.

10
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.

11
Admission Control (Contd)

• Two basic approaches
• Parameter based
• Measurement based

12
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.
• Simple sum of bandwidth is an example

13
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

14
Measurement Based (contd)

• 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

15
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.

16
Packet Scheduling

• Packet scheduler responsible for resource
  allocation
• Directly affects delay, jitter and packet loss
• Primary task is to select a packet to transmit
  when outgoing link is ready such that the QoS
  promised to flows is provided

17
Service Models

• Describe interface between the network and its
  users.
• IntServ has standardized two basic service
  models
• Guaranteed service
• Controlled load service

18
Flow Specification

• A service contract that specifies the traffic
  that the source will send
• If application violates the contract then it may
  not get the QoS expected.
• This is done by policing the traffic to ensure
  that it conforms to its traffic description.

19
Flow characterization

• Peak rate highest rate at which a source can
  generate traffic.
• Can be calculated from packet size and the
  spacing between two packets.
• Average rate The avg. transmission rate over a
  time interval.
• Typically calculated with a moving time window.
• Burst The max amount of data that can be
  injected at peak rate.

20
Flow specification (contd)

• In IntServ, traffic is described in terms of
  leaky bucket parameters.
• It has two parameters token arrival rate r and
  bucket depth b.
• Token gets into bucket at the rate r and packet
  is sent only if there are enough tokens.
• When a packet is sent, tokens equal to the packet
  size is removed from the bucket.

21
Flow specification (contd)

• If enough number of tokens are not available then
  packet waits until enough tokens are accumulated.
• Once token bucket reaches depth b no further
  tokens are accepted.
• The amount of bits transmitted during any
  interval t is then A(t) r t b.

22
Service Requirement

• Minimum bandwidth min bandwidth required by an
  app flow.
• Delay amount of time elapsed when packet leaves
  the source and arrives at the destination. Three
  components propagation, transmission, queuing.
• Delay Jitter difference between largest and
  smallest delay.
• Loss Rate ratio of lost packets to total
  packets transmitted

23
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.

24
Guaranteed Service (contd)

• 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 less
  than m will be counted as size m.
• Max packet size (M) Max packet size accepted.

25
Guaranteed Service (contd)

• 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.

26
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)
• As if service is provided by a dedicated wire of
  bandwidth R from src to dst
• If p is very large compared to R and r, then the
  worst case queuing delay AB b/R.

27
Delay Calculation(Contd)
r
A
B
R
b
O
28
Delay Calculation(Contd)

• If p is comparable to R and r, then the worst
  case queuing delay is AC
• b (p R) / R (p r) (p gt R r)

29
Delay Calculation(Contd)
r
A
C
F
E
R
b
p
O
D
B
30
Delay calculation (Contd)

• 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

31
Delay calculation (Contd)

• Incorporating the error terms and packet lengths,
  the worst-case queuing delay
• (b M) (pR) / R(p-r) (MCtot)/R Dtot
• (p gt R r)
• (M Ctot) / R Dtot (R p r)

32
Policing and Shaping

• Traffic flows 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, rTb-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.

33
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.

34
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.

35
RSVP

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

36
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.

37
Basic Features (Contd)

• 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.

38
Basic Features (Contd)

• 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.

39
Basic Features (Contd)

• 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.

40
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).
• destAddr can be unicast or multicast address

41
Reservation Model

• RSVP reservation request consists of a flowspec
  together with a filter spec.
• flowspec specifies a desired QoS and traffic
  (look at RFC 2210)
• Filterspec along with a session specifies a flow.
• filterSpec src address and src port
• Session dst address, dst port and proto id
• Flowspec used to set params in the nodes packet
  scheduler
• Filterspec used to set the params of the packet
  classifier.

42
Reservation Model (Contd)

• Flowspec include a service class (guaranteed or
  controlled load) and two sets of numeric params
  RSpec (desired QoS) and a TSpec (describes
  traffic).

43
Protocol Overview
44
Protocol Overview (contd)
45
Protocol Overview (Contd)

• 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.

46
Protocol Overview (Contd)

• 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.

47
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.

48
PATH Message (Contd)

• 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.

49
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.

50
RSVP Message Formats

• Each RSVP message begins with a common header
  followed by a series of variable-length RSVP
  objects.
• Common Header

3
0
1
2
0
vers
Msg type
flags
RSVP checksum
reserved
RSVP length
Send_TTL
51
RSVP Message Formats (Contd)

• 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

52
RSVP Message Formats (Contd)

• Send_TTL 8bits
• IP TTL value with which the message was sent
• Can be used to test whether there was any
  non-RSVP node
• RSVP length 16bits
• Total length of the RSVP message in bytes
  including the common header.

53
Object Formats

• Every RSVP object consists of one or more 32-bit
  words with a one-word header with the following
  format

1
2
3
0
Length (in bytes)
Class-Num
C-type
Object contents
54
Object Formats (contd)

• 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.

55
PATH message

• ltPath Messagegt ltCommon Headergt ltINTEGRITYgt
  ltSESSIONgt ltRSVP_HOPgt ltTIME_VALUESgt
  ltPOLICY_DATAgt ltsender descriptorgt
• ltSender descriptorgt ltSENDER_TEMPLATEgt
  ltSENDER_TSPECgt ltADSPECgt
• TIME_VALUES refresh period

56
RESV message

• ltResv Messagegt ltCommon Headergt ltINTEGRITYgt
  ltSESSIONgt ltRSVP_HOPgt ltTIME_VALUESgt
  ltRESV_CONFIRMgt ltSCOPEgt ltPOLICY_DATAgt
  ltSTYLEgt ltflow descriptor listgt
• ltflow descriptor listgt ltemptygt ltflow
  descriptor listgt ltflow descriptorgt
• SCOPE explicit list of sender hosts towards
  which the information in the message is to be
  forwarded
• Flow descriptor ltflowspecgt ltfilterspecgt
• ltflowspecgt gt b,r,p,m,M,R,slack
• ltfilterspecgt gt along with ltsessiongt uniquely
  defines the flow

57
PATH Tear message

• ltPATH Tear Messagegt ltCommon Headergt
  ltINTEGRITYgt ltSESSIONgt ltRSVP_HOPgt ltsender
  descriptorgt
• Path Tear is initiated by sender or by path state
  timeout.
• Deletes matching Path state.
• Travel downstream towards all receivers

58
RESV Tear message

• ltResv Tear Messagegt ltCommon Headergt
  ltINTEGRITYgt ltSESSIONgt ltRSVP_HOPgt ltSCOPEgt
  ltSTYLEgt ltflow descriptor listgt
• Resv Tear is initiated by receiver or by resv
  state timeout.
• Deletes matching resv state.
• Travels upstream towards all matching senders.

59
PATH Error message

• ltPathErr Messagegt ltCommon Headergt
  ltINTEGRITYgt ltSESSIONgt ltERROR_SPECgt
  ltPOLICY_DATAgt ltsender descriptorgt
• Reports error in processing PATH msg
• Travel upstream towards sender

60
RESV Error message

• ltResvErr Messagegt ltCommon Headergt
  ltINTEGRITYgt ltSESSIONgt ltRSVP_HOPgt ltERROR_SPECgt
  ltSCOPEgt ltPOLICY_DATAgt ltSTYLEgt lterror flow
  descriptorgt
• Reports error in processing RESV msg.
• Or may report spontaneous disruption of a
  reservation
• Travel downstream towards appropriate receivers.

61
RESV Confirm message

• ltResvConf Messagegt ltCommon Headergt
  ltINTEGRITYgt ltSESSIONgt ltERROR_SPECgt
  ltRESV_CONFIRMgt ltSTYLEgt ltflow descriptor listgt
• Sent to acknowledge reservation request
• Sent when RESV_CONFIRM object is present in RESV
  message.
• Sent to receiver host from sender.

62
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.
• Useful when it is unlikely that all sources would
  transmit simultaneously
• Audio conferencing 1 or 2 people talk at the
  same time

63
Reservation Styles (Contd)
sender selection Reservation distinct shared
Explicit Fixed filter (FF) Shared explicit (SE)
wildcard Not defined Wildcard filter (WF)
64
Reservation Style (Contd)

• 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.

65
Reservation Style (Contd)

• Fixed-filter (FF) style
• Distinct reservation and explicit sender
  selection.
• Distinct reservation established for specific
  sender
• Can be represented as FF (S1(Q1), S2(Q2), ..)

66
Reservation Style (Contd)

• Shared explicit (SE) style
• Shared reservation but explicit sender selection
• Creates a single reservation shared by specific
  senders
• Represented as SE((S1, S2, ., Sn) Q).

67
Example
(c)
(a)
R1
S1
(d)
(b)
R2
S2, S3
R3
Multicast routes are such that traffic from any
source Si Goes to both the interfaces
68
Wildcard-Filter
Receives
Sends
Reserves
(c) 4B
WF(4B) ? (a)
(c) ? WF(4B)
(d) ? WF(3B) ? WF(2B)
WF(4B) ? (b)
(d) 3B
69
Fixed-Filter
Receives
Reserves
Sends
(c) ? FF(S14B, S25B)

• S14B
• S25B

FF(S14B) ? (a)
(d) ? FF(S13B, S3B) ? FF(S1B)

• S13B
• S3B

FF(S25B, S3B) ? (b)
70
SE-Filter
Receives
Reserves
Sends
(c) ? SE(S1,S2B)

• (S1,S2)B

SE(S13B) ? (a)
(d) ? SE(S1, S33B) ? SE(S22B)

• (S1,S2,S3)3B

SE(S2,S33B) ? (b)
71
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.

72
OPWA (Contd)

• 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.

73
OPWA (Contd)

• 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.

74
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).
• Flow Identification should happen at a high speed.

75
Design Choices

• Trade off between speed vs space
• One extreme is direct memory lookup
• Single memory access
• Requires high storage
• Five-tuple is 104 bits long
• Other extreme is binary search
• Efficient in terms of storage space
• But relatively slow
• Compromise is to use hashing based scheme

76
Hashing based scheme
0
0
Collision resolution table
M
Reservation table
N
Hash table
77
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 im 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

78
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

79
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.

80
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.