Protocols with QoS Support

1
Protocols with QoS Support
INF5070 Media Servers and Distribution Systems

• 27/9 - 2004

2
Overview

• Quality-of-Service
• Resource reservation
• Protocols
• IPv4
• IPv6
• Tenet
• ATM
• IntServ
• RSVP
• DiffServ
• MPLS

3
Quality-of-Service
4
QualityofService (QoS) I

• Many definitions, e.g.QoS represents the set
  of those quantitative and qualitative
  characteristics of a distributed multimedia
  system that are necessary to achieve the required
  functionality of an application Vogel et. al.
  Distributed Multimedia and QoS A Survey, IEEE
  Multimedia 1995

5
QualityofService (QoS) II

• Different semantics or classes of QoS
• determines reliability of offered service
• utilization of resources

max
reserved B
unused
available resources
reserved A
6
QualityofService (QoS) III

• Best effort QoS
• system tries its best to give a good performance
• no QoS calculation (could be called no effort
  QoS)
• simple do nothing
• QoS may be violated ? unreliable service
• Deterministic guaranteed QoS
• hard bounds
• QoS calculation based on upper bounds (worst
  case)
• premium better name!!??
• QoS is satisfied even in the worst case ? high
  reliability
• over-reservation of resources ? poor utilization
  and unnecessary service rejects
• QoS values may be less than calculated hard upper
  bound

7
QualityofService (QoS) IV

• Statistical guaranteed QoS
• QoS values are statistical expressions (served
  with some probability)
• QoS calculation based on average (or some other
  statistic or stochastic value)
• resource capabilities can be statistically
  multiplexed ? more granted requests
• QoS may be temporarily violated ? service not
  always 100 reliable
• Predictive QoS
• weak bounds
• QoS calculation based previous behavior of
  imposed workload
• resource capabilities can be statistically
  multiplexed ? more granted requests
• possibly more exact workload description (if past
  and actual behavior matches)
• QoS may be temporarily violated ? service not 100
  reliable
• QoS values may be less than calculated hard upper
  bound

8
Resource Reservation
9
Resource Reservation I

• Reservations is fundamental for reliable
  enforcement of QoS guarantees
• per-resource data structure (information about
  all usage)
• QoS calculations and resource scheduling may be
  done based on the resource usage pattern
• reservation protocols
• negotiate desired QoS by transferring information
  about resource requirements and resource usage
  between the end-systems and the intermediate
  systems participating in the data transfer
• reservation operation
• calculate necessary amount of resources based on
  the QoS specifications
• reserve resources according to the calculation
  (or reject request)
• resource scheduling
• enforce resource usage with respect to resource
  administration decisions

10
Resource Reservation

• QoS reservation
• specification (parameter set)
• how to describe QoS
• e.g., frames-per-second, color depth, ,
  bandwidth, delay, jitter, error rate,
• parameter mapping / translation
• negotiation procedure
• how to set up QoS
• peer-to-peer case all components or resources
  must agree
• different types
• triangular all components (server and network)
  allowed to change QoS
• bilateral only server allowed to change QoS
• unilateral take is or leave it from client
• enforcement (reflection) in access mechanisms
• how to ensure QoS
• e.g., scheduling

11
Resource Management Phases
Phase 1
users QoS requirements
specification
time
rejection or renegotiation
admission test and calculation of QoS guarantees
negotiation
resource reservation
QoS guarantees to user
confirmation
renegotiation
Phase 2
data transmission
QoS enforcement by proper scheduling
enforcement
not necessary an own phase, some protocols start
sending at once
monitoring and adaptation notification
renegotiation
Phase 3
stream termination
resource deallocation
termination
12
Reservation Directions
sender

• Sender oriented
• sender (initiates reservation)
• must know target addresses (participants)
• in-scalable
• good security

1. reserve
data flow
2. reserve
3. reserve
receiver
13
Reservation Directions
sender

• Receiver oriented
• receiver (initiates reservation)
• needs advertisement before reservation
• must know flow addresses
• sender
• need not to know receivers
• more scalable
• in-secure

3. reserve
data flow
2. reserve
1. reserve
receiver
14
Reservation Directions
sender

• Combination
• start sender oriented reservation
• additional receivers join at routers(receiver
  based)

1. reserve
data flow
2. reserve
reserve from nearest router
3. reserve
receiver
15
Routing
16
Routing
application
transport
network
link
physical
17
Routing
209.73.164.90
216.239.51.101
192.67.198.54
80.91.34.111
129.42.16.99
129.240.148.31
81.93.162.20
209.189.226.17
193.99.144.71
66.77.74.20
129.240.148.31
18
Routing
216.239.51.101
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
19
Routing
216.239.51.101
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
20
Protocols
21
Internet Protocol version 4 (IPv4) I

• IP is THE network layer protocol within the
  Internet
• IPv4
• defined by RFC 791 (1981) STD 5
• unreliable datagram service (neither flow nor
  error control)
• no fixed routes
• flexibility for path selection
• reordering problems
• not suitable for time critical continuous media
  data
• but, source routing is optional
• loose specify some router IP addresses to be
  passed in order
• strict specify all routers to be passed in
  order
• maximum 64 KB datagrams including headers
• segmentation for smaller subnets (e.g., 1500 B
  for standard Ethernet)
• reassembly in end-systems IP-layer

22
Internet Protocol version 4 (IPv4) II
indication of the abstract parameters of
thequality of service desired somehow
treat high precedence traffic as more important
tradeoff between low-delay, high-reliability,
and high-throughput NOT used, bits now reused
indicates the format of the internet header,
i.e., version 4
length of the internet header in 32 bit words,
and thus points to the beginning of the data
(minimum value of 5)
datagram length (octets) includingheader and
data - allows the lengthof 65,535 octets
fragments allowed flag allowed and last fragment
flag
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Version IHL Type of
Service Total Length
-------------------------
------- Identification
Flags Fragment Offset
-------------------------
------- Time to Live Protocol
Header Checksum
-------------------------
------- Source
Address
-------------------------
-------
Destination Address
-------------------------
------- Options
Padding
-------------------------
-------
identifying value to aid assembly of fragments
indicate where this fragment belongs in datagram
disable a packet to circulate forever,decrease
value by at least 1 in each node discarded if 0
checksum on the header only TCP, UDP over
payload. Since some header fields change(TTL),
this is recomputed and verified at each point
indicates used transport layer protocol
32-bit address fields. May be configured
differently from small to large networks
options may extend the header. If the options do
not end on a 32-bit boundary, the remaining
fields are padded in the padding field (0s)
23
Internet Protocol version 6 (IPv6) I
disable a packet to circulate forever, decrease
value by at least 1 in each node discarded if 0
the 4-bit priority field has been replaced by an
8-bit traffic class field. To identify and
distinguish between different classes or
priorities

• IPv6
• defined by RFC 1883 (1995), but revised by RFC
  2460 (1998)
• simplified header

label packets which requests special handling by
the IPv6 routers, such as non-default quality of
service or real-time
-----------------------
--------- Version Prio.
Flow Label
-------------------------
------- Payload Length
Next Header Hop Limit
-------------------------
-------




Source Address




------------------------
--------




Destination Address




----------------------
----------
-----------------------
--------- Version Traffic Class
Flow Label
-------------------------
------- Payload Length
Next Header Hop Limit
-------------------------
-------




Source Address




------------------------
--------




Destination Address




----------------------
----------
version of protocol, i.e., version 6
length of payload in bytes. If zero, indicates
that the payload length is carried in a Jumbo
Payload option.
Identifies the type of headerimmediately
following the header e.g., TCP, UDP, but also
EXTENSION headers
128-bit address fields
24
Internet Protocol version 6 (IPv6) II

• IPv6
• enlarged address space (2128 3.4 x 1038
  addresses)
• simplified headers reduce packet processing time
• jumbograms allows packets larger than 64 KB
  (using a extension header)
• strict routing (source can fix route to
  destination using a routing extension header)
• inclusion of security concepts and mobile
  end-systems
• may specify only a geographical range for a
  multicast session
• some support for QoS concepts each packet
  header includes ...
• ... a 8-bit traffic class field defined by
  DiffServ
• ... a 20-bit flow label

25
Internet Protocol version 6 (IPv6) IV

• Flow labels
• a flow is a sequence of packets sent from the
  source to the destination for which the source
  desires special handling by the routers
• each flow must have same flow label, priority and
  addresses
• flow pseudo-connection
• before start or during transmission
• set up flow between source and destination
• route is cached table entries in a router
  allows fast packet switching
• routers can reserve resources
• during data transmission
• routers can identify flows by a unique flow
  label/address combination
• routers can treat packets according to the flow
  type
• still experimental use
• BUT IPv6 itself does not define mechanisms for
  QoS treatment must use additional protocols

26
IP Multicast

• Limiting IP multicast geographically
• IPv4 interpretation of TTL header field is
  used(non-standardized MBONE use)
• IPv6 multicast address contains a 4-bit scope
  field
• possible geographical limits
• machine
• LAN
• organization
• country (v4 only)
• continent (v4 only)
• global no limit

27
Tenet I

• Late 80s/early 90s, Tenet group at Berkeley
• Aims for network support for real-time continuous
  media applications
• Real-time communication model
• Real-time channels end-to-end connection with
  performance guarantees and traffic restrictions
• associated with a set of nodes and links (a
  route) through which real-time packets pass
• resource reservation in route nodes
• admission control

28
Tenet II

• Traffic specification
• expressing peak and average load on the network
• indication of the burstiness of the load
• parameters
• minimum packet inter-arrival time
• average packet inter-arrival time
• averaging interval
• maximum packet size
• Supported QoS parameters (by which users describe
  their requirements)
• upper bound on end-to-end message delay
• delay violation probability bound
• buffer overflow probability bound
• delay jitter bound (optional)
• a throughput guarantee is obtained from the
  traffic specification

29
Tenet III
application
real-time messagetransport protocol
continuous media transport protocol
real-time channeladministration protocol

• Protocol suite
• Real-time Channel Administration Protocol (RCAP)
• performs channel setup
• uses the traffic description and performance
  requirementto find a route and maps the global
  requirement onto local resources
• performs admission control and reservations on
  the way
• Real-time Message Transport Protocol (RMTP)
• intended for message based real-time transport
• Continuous Media Transport Protocol (CMTP)
• offers a stream based interface and a time-driven
  mechanism for audio and video may demand data
  from application
• Real-time Internet Protocol (RTIP)
• replaces IP
• schedules packets according to resource
  reservations made by RCAP

real-timeinternet protocol
data link layer
physical layer
30
Asynchronous Transfer Mode (ATM) I

• Defined by ATM Forum and International
  Telecommunication Union (ITU)
• Targeted for all kinds of traffic within the same
  network (i.e., both continuous and discrete data
  types)
• A full suite of protocols
• physical layer deals with voltages, bit
  timingand framing on the physical medium
• ATM layer defines the ATM cell structure
• adaptation layer analogous to the Internet
  transport layer supporting different services
• Today IP-over-ATM
• IP rules TCP/IP is used in every end-system?
  ATM used as link-layer technology
• however, ATM may forward data quickly
• ATM may be used in the Internet backbone running
  under IP
• uses AAL5 to transport IP datagrams over the ATM
  network

ATM adaptation layer (AAL)
ATM layer
ATM physical layer
31
Asynchronous Transfer Mode (ATM) II

• Service classes
• constant bit rate (CBR)(real-time, guaranteed
  constant rate)
• variable bit rate (VBR) real-time and
  non-real-time
• available bit rate (ABR)(slightly better than
  best effort a minimum guarantee, only class
  with congestion control)
• unspecified bit rate (UBR)(best effort, no
  guarantees)
• Virtual channels (VC)
• the ATM network sets up a VC between sender and
  receiver
• a path consisting of a sequence of links
• each link has a virtual circuit identifier (VCI)
  used for routing(included in the cell header)
• ATM backbones usually use permanent VCs, i.e.,
  saving VC setup and teardown
• Virtual paths

32
Asynchronous Transfer Mode (ATM) III

• The ATM standard specifies a number of QoS
  parameters
• traffic generation by sender
• cell rate (sustainable (SCR) / peak (PCR) /
  minimum (MCR))
• maximum burst size (MBS)
• cell delay variation tolerance (CDVT)
• service provided by network
• cell transfer delay (CTD) cell transit time
  from source to destination
• cell delay variation (CDV) variance in
  transfer delays
• cell loss ratio (CLR) fraction of cells lost
  or delivered too late
• cell error rate (CER) fraction of cells with
  bit errors
• severly-errored cell block ratio (SECBR)
  fraction of an N-cell block with M or more cells
  damaged
• cell misinsertion rate (CMR) number of cells
  delivered to wrong destination

33
Asynchronous Transfer Mode (ATM) VI

• Traffic contracts
• the VC acts like a contract between customer and
  network for a service
• consist of a connection traffic descriptor and a
  set of QoS parameters
• which traffic to be offered
• which service class
• compliance requirements
• the QoS parameters are negotiated during the VC
  setup (can be specified either explicitly or
  implicitly)

34
Asynchronous Transfer Mode (ATM) V

• Different service categories require different
  parameters

35
Asynchronous Transfer Mode (ATM) VI

• Application areas for ATM service categories (by
  ATM Forum)

3 good 2 fair 1 not good, not applicable
with advantage n/s not suitable
may be more useful now!!??
36
Integrated Services (IntServ) I

• Framework by IETF to provide individualized QoS
  guarantees to individual application sessions
• Goals
• efficient Internet support for applications which
  require service guarantees
• fulfill demands of multipoint, real-time
  applications (like video conferences)
• do not introduce new data transfer protocols
• In the Internet, it is based on IP (v4 or v6) and
  RSVP (described later)
• Two key features
• reserved resources the routers need to know
  what resources are available (both free and
  reserved)
• call setup (admission call) reserve resources
  on the whole path from source to destination

37
Integrated Services (IntServ) II
receiver

• Admission call
• traffic characterization and specification
• one must specify the traffic one willtransmit on
  the network (Tspec)
• one must specify the requested QoS(Rspec
  reservation specification)
• signaling for setup
• send the Tspec and Rspec to all routers
• per-element admission test
• each router checks whether the requestsspecified
  in the R/Tspecs can be fulfilled
• if YES, accept reject otherwise

sender
1. request specify traffic (Tspec), guarantee
(Rspec)
1
3
2. consider request against available resources
3. accept or reject
2
38
Integrated Services (IntServ) III

• IntServ introduce two new services enhancing the
  Internets traditional best effort
• guaranteed service
• guaranteed bounds on delay and bandwidth
• for applications with real-time requirements
• controlled-load service
• a QoS closely to the QoS the same flow would
  receive from an unloaded network element RFC
  2212, i.e., similar to best-effort in networks
  with limited load
• no quantified guarantees, but packets should
  arrive with a very high percentage
• for applications that can adapt to moderate
  losses, e.g., real-time multimedia applications

39
Integrated Services (IntServ) IV

• Both service classes uses token bucket to police
  a packet flow
• packets need a token to be forwarded
• each router has a b-sized bucket with tokensif
  bucket is empty, one must wait
• new tokens are generated at a rate r and
  addedif bucket is full (little traffic), the
  token is deleted
• the token generation rate r serves to limit the
  long term average rate
• the bucket size b serves to limit themaximum
  burst size

token generation
bucket
token wait queue
40
Integrated Services (IntServ) V

• Usual protocol structure

application
RTP
UDP
RSVP
IP
data link
41
Resource Reservation Protocol (RSVP) - I

• Defined by RFC 2205 (1997)
• A protocol to signal reservations of resources in
  the Internet
• contains protocol elements for control
• no support for data transfers (reservation
  signals only)
• simplex protocol, i.e., makes reservations for
  unidirectional flows
• receiver-oriented, i.e., the receiver initiates
  and maintains resource reservations
• maintains a soft state graceful changes to
  dynamic memberships and automatic adaptation to
  route changes (timeouts)
• companion protocol to IP supports both IPv4 and
  IPv6
• transported as raw IP datagram with protocol
  number 46
• filtering provides support for heterogeneous
  receivers and different reservation styles

42
Resource Reservation Protocol (RSVP) - II

• RSVP will generally require raw network I/O
• sends raw IP datagrams using protocol 46
• operates on top of IP, i.e., takes the place of
  the transport protocol
• does not perform traditional transport layer
  services must add a transport protocol (UDP)

application
UDP
RSVP
IP
data link
43
Resource Reservation Protocol (RSVP) - III

• Sessions
• a data flow with particular destination and
  transport protocol
• defined by (destination address, protocol ID)
• IP address
• IP protocol ID
• may carry multiple data flows
• Data flows are distinguished by
• source IP address and source port (IPv4)
• source IP address and flow label (IPv6)
• Transmission model

44
Resource Reservation Protocol (RSVP) - IV

• Two fundamental messages
• PATH
• sender sends a PATH message downstream following
  the data path
• sent using same source and destination addresses
• includes
• hop-addresses
• sender template (describes data packet format)
• sender Tspec (traffic characteristics generated
  by sender)
• sender Adspec (advertisement information)
• ...
• RESV
• receiver sends a RESV message upstream using the
  path described in the PATH message
• sent to previous hop only
• includes
• flowspec reservation requests, desired QoS
  (e.g., RFC 1363)
• filterspec reservation style
• reverse data paths for the flow
• ...

45
Resource Reservation Protocol (RSVP) - V

• Creating and maintaining a reservation state
• the SOURCE
• multicasts data flows
• sends PATH messages with traffic characteristics
  (Tspec) describing flows
• the RECEIVER
• joins multicast group
• receives the PATH message
• determines own QoS requirements based the PATH
  Tspec
• sends a RESV message with request and filters
• the ROUTERS
• reserve according to incoming flowspecs
  downstream
• merge and forward the RESV messages to next node
  using largest flowspec
• the reservations are maintained using soft
  states
• the reservation has an associated timer a
  timeout removes the reservation
• periodically refreshed by PATH and RESV messages

46
Resource Reservation Protocol (RSVP) - VI
10 Mbps
1 Mbps
RESV10 Mbps
RESV1 Mbps
reserved 10 Mbps
merging
merging
merging
reserved 1 Mbps
PATH
PATH
PATH
PATH
PATH
reserved 10 Mbps
reserved 10 Mbps
reserved 1 Mbps
PATH
RESV10 Mbps
RESV10 Mbps
RESV1 Mbps
5 Kbps
PATH
reserved 5 Kbps
reserved 3 Mbps
RESV5 Kbps
RESV3 Mbps
merging
PATH
PATH
PATH
reserved 3 Mbps
reserved 3 Mbps
RESV3 Mbps
RESV3 Mbps
reserved 1 Mbps
3 Mbps
RESV1 Mbps
1 Mbps
47
Resource Reservation Protocol (RSVP) - VII

• RSVP in hosts and routers
• RESV with flowspec and filterspec to RSVP daemon
• policy control to check privileges etc.
• admission control using flowspec
• forward RESV message
• control of local modules classifier and
  scheduler

application process
RSVPdaemon
policy control
routing process
RSVPdaemon
policy control
admission control
admission control
packet classifier
packet scheduler
packet classifier
packet scheduler
data
48
Resource Reservation Protocol (RSVP) - VIII

• Reservation styles
• a reservation request includes a set of options
  called the reservation style
• shared vs. distinct reservations
• concerns treatment of reservations of different
  senders
• shared single reservation for all senders
  (e.g., video conference audio)
• distinct one reservation per sender (e.g.,
  video conference video)
• explicit vs. wildcard
• concerns selection of senders
• explicit specify senders (e.g., teleteaching)
• wildcard automatically select all senders
  (e.g., video conference)

49
Resource Reservation Protocol (RSVP) - IX
50
Resource Reservation Protocol (RSVP) - X

• The RSVP standard RFC 2205 allows to reserve
  link bandwidth it does NOT...
• ...define how the network should provide the
  reserved bandwidth to the data flows the
  routers must implement these mechanisms
  themselves
• ...specify how to do resource provisioning
  which must likely be done using a proper
  scheduling mechanism
• ...determine the route it is not a routing
  protocol, but relies on others
• ...determine which data to drop in case of
  overflow, i.e., the most important data may be
  lost
• ...perform an admission test, but it assumes that
  the routers perform admission control
• THUS RSVP can only be used as a small piece in
  the QoS guarantee puzzle Kurose, J. F., Ross,
  K. W. Computer Networking A Top-Down Approach
  Featuring the Internet, 2nd edition, Addison
  Wesley, 2002

51
Differentiated Services (DiffServ) I

• IntServ and RSVP provide a framework for per-flow
  QoS, but they
• give complex routers
• much information to handle
• have scalability problems
• set up and maintain per-flow state information
• periodically PATH and RESV messages overhead
• specify only a predefined set of services
• new applications may require other flexible
  services
• DiffServ RFC 2475 tries to be both scalable and
  flexible

52
Differentiated Services (DiffServ) II

• ISP favor DiffServ
• Basic idea
• multicast is not necessary
• make the core network simple due to many users
• implement more complex control operations at the
  edge
• aggregation of flows reservations for a group
  of flows, not per flow
• thus, avoid scalability problems on routers with
  many flows
• do not specify services or service classes
• instead, provide the functional components on
  which services can be built
• thus, support flexible services

53
Differentiated Services (DiffServ) III

• Two set of functional elements
• edge functions packet classification and traffic
  conditioning
• core function packet forwarding
• At the edge routers, the packets are tagged with
  a DS-mark (differentiated service mark)
• uses the type of service field (IPv4) or the
  traffic class field (IPv6)
• different service classes (DS-marks) receive
  different service
• subsequent routers treat the packet according to
  the DS-mark
• classification
• incoming packet is classified (and steered to
  the appropriate marker function) using the header
  fields
• the DS-mark is set by marker
• once marked, forward

classifier
marker
forward
54
Differentiated Services (DiffServ) IV

• Note, however, that there is no rules for
  classification it is up to the network
  provider
• A metric function may be used to limit the packet
  rate
• the traffic profile may define rate and maximum
  bursts
• if packets arrive too fast, the metric function
  assigns another marker function telling the
  router to delay or drop the packet

shaper / dropper
classifier
marker
forward
55
Differentiated Services (DiffServ) V

• In the core routers, a DS-marked packet is
  forwarded according to a per-hop behavior (PHB)
  associated with the DS-tag
• the PHB determines how the router resources are
  used and shared among the competing service
  classes
• the PHB should be based on the DS-tag only
  simple forwarding decisions, no need for
  QoS-states for each source-destination pair
• packets with same DS-tag are treated equally
  regardless of source or destination (traffic
  aggregating)
• a PHB can result in different service classes
  receiving different performance
• performance differences must be observable and
  measurable to be able to monitor the system
  performance
• no specific mechanism for achieving these
  behaviors are specified- any mechanism can by
  used as long as the performance specification is
  met

56
Differentiated Services (DiffServ) VI

• Currently, two PHBs are under active discussion
• expedited forwarding RFC 3246
• specifies a minimum departure rate of a class,
  i.e., a guaranteed bandwidth
• the guarantee is independent of other classes,
  i.e., enough resources must be available
  regardless of competing traffic
• assured forwarding RFC 2597
• divide traffic into four classes
• each class is guaranteed a minimum amount of
  resources
• each class are further partitioned into one of
  three drop categories(if congestion occur, the
  router drops packets based on drop value)

57
Differentiated Services (DiffServ) VII
Edge routeruse header fields to lookup right
DS-tag and mark packet
fast and scalable due to simple core routers
Core routeruse PHB according to DS-tag to
forward packet
58
Internet Streaming Protocol, Version 2 (ST-II)
I
application

• ST-II is defined by RFC 1190/1819
• It is a connection-oriented supplement to IP
  with two components
• ST reservations and data management
• SCMP (ST control message protocol) reliable
  control messages
• Main concepts
• unreliable data transfers, reliable control
• a negotiated packet size (no fragmentation and
  reassembly)
• routing tree from sender to multiple receivers
• flow specification describing QoS parameters
  during connection setup

transport
link
59
Internet Streaming Protocol, Version 2 (ST-II)
II

• The resource reservation is sender-oriented
• SCMP sends a message with a flow specification
• if the routers and the destination accepts the
  call, the call is returned (possibly modified) to
  the source
• typical parameters include
• bandwidth
• delay
• delay variance
• size

accept/reject
connect
connect
60
Fast Routing
61
Routing Speed-up

• ATM
• Virtual Channels and Virtual Path
• RSVP
• IP and Port Mapping
• ST-II
• Hop ID
• MPLS
• Label

62
Multiprotocol Label Switching (MPLS)

• Multiprotocol Label Switching
• Separate path determination from hop-by-hop
  forwarding
• Forwarding is based on labels
• Path is determined by choosing labels
• Distribution of labels
• On application-demand
• LDP label distribution protocol
• By traffic engineering decision
• RSVP-TE traffic engineering extensions to RSVP

63
Multiprotocol Label Switching (MPLS)

• MPLS works above multiple link layer protocols
• Carrying the label
• Over ATM
• Virtual path identifier or Virtual channel
  identifier
• Maybe shim
• Frame Relay
• data link connection identifier (DLCI)
• Maybe shim
• Ethernet, TokenRing,
• Shim
• Shim?

64
Multiprotocol Label Switching (MPLS)

• Shim the label itself

Link Layer Header
Shim
Shim
65
Routing using MPLS
216.239.51.101
Reserved path for this label
192.67.198.54
209.73.164.90
80.91.34.111
129.42.16.99
Remove label
Added label
209.189.226.17
129.240.148.31
81.93.162.20
66.77.74.20
129.240.148.31
193.99.144.71
66
MPLS Label Stack

• The ISP 1
• Classifies the packet
• Assigns it to a reservation
• Performs traffic shaping
• Adds a label to the packet for routers in his net

ISP 3
ISP 2
ISP 2
ISP 1
ISP 1

• The ISP 1
• Buys resources from ISP 2
• The ISP 2
• Repeats classifying, assignment, shaping
• Adds a label for the routers in his net
• He pushes a label on the label stack

67
MPLS Label Stack
ISP 3
ISP 2
ISP 2
ISP 1
ISP 1
68
The EndSummary
69
Summary

• Timely access to resources is important for
  multimedia application to guarantee QoS
  reservation might be necessary
• Many protocols have tried to introduce QoS into
  the Internet, but no protocol has yet won the
  battle...
• often NOT only technological problems, e.g.,
• scalability
• flexibility
• ...
• but also economical and legacy reasons, e.g.,
• IP rules everything must use IP to be useful
• several administrative domains (how to make ISPs
  agree)
• router manufacturers will not take the high costs
  (in amount of resources) for per-flow
  reservations
• pricing
• ...

70
Some References

• ATM Forum, http//www.atmforum.com
• ATM Forum ATM Service Categories,
  http//www.atmforum.com/aboutatm/6.html
• Danthine, A., Bonaventure, O. From Best Effort
  to Enhanced QoS, in Spaniol, O., Danthine, A.,
  Effelsberg, W. (Eds.) Architecture and
  Protocols for High-Speed Networks, Kluwer
  Achademic Publishers, 1994, pp. 179-201
• Kurose, J. F., Ross, K. W. Computer Networking
  A Top-Down Approach Featuring the Internet, 2nd
  edition, Addison Wesley, 2002
• Steinmetz, R., Nahrstedt, C. Multimedia
  Computing, Communications Applications,
  Prentice Hall, 1995
• Tenet group http//tenet.berkeley.edu/tenet.html
  
• The RFC repository maintained by the IETF
  Secretariat can be found at http//www.ietf.org/rf
  c.htmlThe following RFCs might be interesting
  with respect to this lecture
• RFC 791 Internet Protocol
• RFC 1883 Internet Protocol, Version 6 (IPv6)
• RFC 2460 Internet Protocol, Version 6 (IPv6),
  Obsoletes 1883
• RFC 2212 Specification of Guaranteed Quality of
  Service
• RFC 2205 Resource ReSerVation Protocol (RSVP)
• RFC 1363 A Proposed Flow Specification
• RFC 2475 An Architecture for Differentiated
  Services
• RFC 3246 An Expedited Forwarding PHB (Per-Hop
  Behavior)
• RFC 2597 Assured Forwarding PHB Group
• RFC 1190 Experimental Internet Stream Protocol,
  Version 2 (ST-II)
• RFC 1819 Internet Stream Protocol Version 2
  (ST2) Protocol Specification - Version ST2