Protocols for QoS Support

1
Chapter 18

• Protocols for QoS Support

2
Introduction

• Modern internet applications demand services not
  provided by a best-effort service model
• The TCP/IP infrastructure has been enhanced to
  address the need
• increased capacity and data rates
• efficient multicasting techniques (Chap. 15)
• QoS capabilities added (Chap. 17)
• Protocols are required to support the QoS
  enhancements to the infrastructure
• RSVP for reservation and admission control
• MPLS for traffic engineering
• RTP for real-time application support

3
Resource Reservation (RSVP)

• Internet resource reservation characteristics
  (RFC 2205)
• similar, but fundamentally different from that
  used in connection-oriented networks such as ATM,
  frame relay
• soft state at routers reserved resources expire
  unless refreshed
• there is no connection setup or teardown on
  which to base hard state maintenance
• end systems must periodically renew their
  requests (default every 30 sec.)

4
RSVP Design Characteristics

• Unicast and Multicast
• Simplex
• Receiver-initiated reservation
• Maintains soft state
• Different reservation styles
• Transparent operation through non-RSVP routers
• Support for IPv4 and IPv6

• Unicast and Multicast (design point)
• Simplex
• Receiver-initiated reservation
• Maintains soft state
• Different reservation styles
• Transparent operation through non-RSVP routers
• Support for IPv4 and IPv6

5
Receiver-Initiated Reservation

• Source-initiated reservations are inadequate for
  multicasting
• different members of same group may have
  different resource requirements
• if transmission flow is divided into sub-flows,
  not all members need all sub-flows
• if multiple sources are transmitting for same
  group, receiver may want to select source
• In general, QoS needs of different receivers may
  differ due to equipment, link speed, processing
  speed/power or other differences
• Sender provides traffic characteristics, but
  receiver requests desired QoS

6
Soft State

• Values associated with a given flow is
  temporarily cached at the router
• based on end-system reservation
• Routing for that flow is subject to change
• End systems must periodically refresh the state
  information
• Routers discard states not refreshed within
  specified time limit
• If a new route becomes the preferred route for
  the flow, end systems provide the reservation
  information to the new routers on the route

7
RSVP Data Flow Concepts

• How are flows of data identified?
• Session identifies a flow by its destination
  (unicast or multicast)
• Destination IP address
• IP protocol identifier (e.g., TCP or UDP)
• Destination port number
• Flowspec describes the QoS parameters
• Service class
• Tspec traffic characteristics of the flow
  (average rate, peak rate, maximum burst size)
• Rspec QoS reservations specification of the
  flow (for Guaranteed Service)
• Filter specification defines the packets in a
  flow
• Source IP address (minimal)
• UDP/TCP source port number (optional)
• other fields (based on application)

Flow Descriptor
8
Example Treatment of Packets at Router

1. Packet is checked to see if it is in a defined
   flow

3. Packets are handled (queued and serviced)
per QoS parameters
2. Packet in flow is granted the appropriate
QoS for that flow
9
RSVP Operation
R1, R2, R3, R4 forwarding routers G1, G2, G3
multicast receivers S1, S2 multicast senders
10
RSVP Reservation Operation
Destination(s)/ Receiver(s)
Source(s)/ Senders(s)
Router

• Reservation actions at router
• Admission control verify requested resources
  are available
• Policy control verify permissions
• Set up classifier and scheduler to provide
  requested Q0S
• Forward request upstream (aggregate as required)

11
Reservation Styles

• How resource reservations are aggregated/merged
  for multiple receivers in the same multicast
  group
• Two options, specified in the receivers
  reservation requests
• Reservation attribute reservation is shared over
  flows from multiple senders, or distinct for each
  sender
• Sender selection explicit list or wildcard
• Three reservation styles are defined

12
RSVP Styles - Reservation Attributes and Sender
Selection
per session
per sender

• Shared-Explicit
• Specifies that a single resource reservation is
  to be shared by an explicit list of senders
• Symbolic representation SE(S1, S2, Q)

• Wildcard-Filter
• Specifies that a single resource reservation is
  to be shared by all senders to this address
• Symbolic representation WF(Q)

• Fixed-Filter
• Specifies a distinct reservation for each sender
  and an explicit list of senders
• Symbolic representation FF(S1Q1, S2Q2, )

13
Reservation Styles Example
Router with RSVP capability
Multicast Group Receivers
Multicast Group Sources
14
RSVP Protocol Mechanisms

• Two basic message types
• Resv propagates upstream from receivers to
  establish router soft states (resource
  reservations) for a multicast group, merging as
  required. Message carries a merged flowspec.
• Path issued by senders to establish reverse-hop
  (upstream) path back to a source from group
  members

15
QoS Protocols (cont.)
16
Multiprotocol Label Switching
MPLS The intelligence of routing with the
performance of switching.
17
Multiprotocol Label Switching

• MPLS Goal provide ATM-like traffic management
  and QoS within IP-based networks
• Reality provides an approach which reduces
  per-packet processing required at routers,
  thereby enhancing IP routing performance

• Significant new capabilities are introduced in
  MPLS
• support for connection-oriented QoS
• Traffic engineering
• VPN support
• multiprotocol support
• RFC 3031 issued in January 2001

18
MPLS in Practice

• High-speed IP backbones
• Legacy ATM networks
• MPLS-capable ATM networks
• Optical networks
• Frame relay networks
• Most prevalent usage is for transporting IP data
  over these networks with low overhead/latency,
  often to implement a VPN for IP traffic

19
MPLS in Practice

• improves packet-forwarding performance in the
  network
• MPLS enhances and simplifies packet forwarding
  through routers using Layer-2 switching
  paradigms.
• MPLS is simple, which allows for easy
  implementation.
• MPLS increases network performance because it
  enables routing by switching at wireline speeds.
• supports QoS and CoS for service differentiation
• MPLS uses traffic-engineered path setup and helps
  achieve service-level guarantees.
• MPLS incorporates provisions for constraint-based
  and explicit path setup.
• supports network scalability
• MPLS can be used to avoid the overlay performance
  problem associated with meshed IPATM networks.

20
MPLS in Practice

• integrates IP and ATM in the network
• MPLS provides a bridge between access IP and core
  ATM.
• MPLS can reuse existing router/ATM switch
  hardware, effectively joining the two disparate
  networks.
• builds interoperable networks
• MPLS is a standards-based solution that achieves
  synergy between IP and ATM networks.
• MPLS facilitates IPover-synchronous optical
  network (SONET) integration in optical switching.
  
• MPLS helps build scalable VPNs with
  traffic-engineering capability.

21
MPLS Terminology Summary
?
?
Per RFC 3031
22
MPLS Operation
? using an interior routing protocol (like OSPF),
establish a path (LSP) in advance for a given FEC
and establish the QoS parameters for the FEC.
Labels are assigned for each FEC.
? the egress LSR strips the label and forwards
the packet to its final destination
? packets entering at ingress LSR are assigned to
an appropriate FEC and a label is attached
? at each LSR along the LSP, the incoming label
is removed and an outgoing label is attached
23
MPLS Operation
24
MPLS Operation

• MPLS FEC can be determined by a number of
  parameters
• source/destination IP addresses
• port numbers
• IP protocol ID
• DS codepoint
• IPv6 flow label
• Forwarding between LSRs requires only simple
  mapping between label values and next hop
  addresses
• note labels have local significance only
• A particular PHB can be assigned for a given FEC
  at each LSR

25
MPLS Advantages over Network Layer Forwarding

• MPLS forwarding can be done by high-speed
  switches that may not be capable of IP packet
  analysis/handling
• Forwarding behavior (the LSP) can be based on
  information other than that in the IP header
• Forwarding behavior can be based on network
  ingress point
• FEC determination can be arbitrarily complex
  since it is done only once at ingress
• Paths for traffic can be engineered in advance
  to balance load traffic or provide different
  levels of serviced for different FECs

26
MPLS Packet Forwarding
Label stacking?
27
MPLS Label Format Placement
Data Link Frame
IEEE 802 MAC Frame
ATM Cell
Frame Relay Frame
28
MPLS Path Selection
Traffic Engineering
Class of Service
29
MPLS Path (Route) Selection

• Two options specified in RFC 3031
• hop-by-hop routing
• makes use of ordinary routing protocols, like
  OSPF
• does not readily support traffic engineering or
  routing based on policy/priority
• explicit routing
• single designated LSR, usually an ingress or
  egress LSR, specifies all LSRs in a route for a
  given FEC
• with loose explicit routing only some of the
  LSRs are specified

30
MPLS Label Distribution

• RFC 3031 does not define or depend on a specific
  label distribution protocol several are defined
• MPLS-LDP (RFC 3036)
• RSVP-TE (RFC 3209)
• MPLS-BGP
• MPLS-RSVP-TUNNELS
• Labels are distributed (bound) in a downstream
  path of LSRs in an LSP
• Labels must be unique on each hop between pairs
  of LSRs )local significance)

31
Real-Time Transport Protocol (RTP)
32
Real-Time Traffic Flow

• Real-Time
• Distributed
• Application
• Source generates data stream at a constant rate
• One or more destinations must deliver that data
  to an application at the same constant rate

33
Time relationship of real-time traffic
Real-time traffic requires preservation of the
time relationship between packets of a session.
From Data Communication and Networks, Forouzan,
4th Edition
34
Jitter (variation in delay)
Jitter is introduced due top the variable
component of delay in packet switched networks.
From Data Communication and Networks, Forouzan,
4th Edition
35
Timestamp
Timestamping packets can allow reconstruction of
original time relationship at the receiver.
From Data Communication and Networks, Forouzan,
4th Edition
36
Playback Buffer
threshold
threshold
A playback buffer at the receiver is used to
sequence/time the release of data to the
application.
From Data Communication and Networks, Forouzan,
4th Edition
37
TCP/UDP for Real-Time?

• TCP
• point-to-point, connection-oriented, so not
  suitable for multicast
• includes retransmission mechanisms for lost
  segments, which often conflicts with real-time
  application requirement
• no segment timing information available
• UDP
• no segment timing information available or other
  general purpose real time tools

38
Real-Time Transport Protocol (RTP)

• Defined in RFC 3550 to provide mechanisms needed
  to support real-time traffic in IP-based
  networks,
• primarily to satisfy the needs of multi-
  participant multimedia conferences
• Best suited for soft real-time communication
• Lacks mechanisms to support hard real-time
  traffic (i.e., traffic with no loss tolerance,
  minimal jitter)
• Closely coupled with the application layer in the
  Internet protocol stack (typically, above UDP)
• Two protocols make up RTP
• RTP, a data transfer protocol (carries the data)
• RTCP, a control protocol (carries session/QoS
  info)

39
RTP Architecture Concepts
From Data Communication and Networks, Forouzan,
4th Edition
40
RTP Architecture Concepts

• Application-Level Framing
• recovery from lost data and framing can be
  handled at the application layer
• retransmission may not be appropriate
• may be more useful for destination(s) to inform
  source about the quality of transmission
• application often provides data for
  retransmission
• may need to re-compute lost data before sending
• may be able to send new data that fixes the
  consequences of any lost data
• flow is broken into ADUs (application data
  units), e.g. audio samples, video frames
• lower layers must preserve ADU boundaries
• payload format is specific to the application

41
RTP Architecture Concepts

• Integrated Layer Processing
• typical layered protocols call for data units to
  be sequentially processed by each layer
• integrated layer processing allows adjacent
  layers (application, RTP, transport) of the
  protocol stack to be tightly coupled
• therefore, RTP is not complete by itself
  requires application-layer and transport layer
  capabilities (and appropriate information in its
  header)

42
RTP Architecture Concepts

• Profile Specification Document
• defines a set of payload type codes and their
  mapping to payload formats (e.g., media
  encodings). May also define extensions or
  modifications to RTP that are specific to a
  particular class of applications. Typically, an
  application will operate under only one profile.
  E.g. profile for AV application data may be found
  in RFC 3551.
• Payload Format Specification Documents
• define how a particular payload, such as an
  audio or video encoding, is to be carried in RTP.

43
RTP Data Transfer Protocol

• Supports transfer of real-time data among
  participants in a RTP session
• session is defined by RTP port, RTCP port,
  participant IP address
• Four primary functions are
• payload type identification
• timestamping data
• sequencing/synchronizing data
• mixing/translating data

44
RTP Data Transfer Protocol

• Each RTP data unit must include
• source identifiers (who generated data)
• timestamp (when data was generated)
• sequence number (order of data in a flow)
• payload format (type of data)
• RTP relays
• mixer combines data from multiple sources and
  creates new single data signal
• translator converts input and resends in new
  format, or replicates for unicast destinations

45
RTP Mixers Translators
Mixer
Translator
46
RTP Fixed Header
Supplied by a mixer
47
Some Standard Payload Types
(see RFC 3551)
48
RTP Control Protocol (RTCP)

• Provides control information and feedback between
  session participants
• Each participant in an RTP session periodically
  issues an RTCP packet
• Uses same underlying transport as RTP (usually
  UDP)
• RTCP port RTP session port 1
• Provides four key functions for real-time traffic
  management (per RFC 1889)
• QoS and congestion control
• Source identification
• Session size estimation and scaling
• Session control

49
RTCP Operation

• Protocol specifies report packets exchanged
  between sources and destinations in real-time
  flows (max. one every 5 secs, limit to 5 session
  traffic)
• Five report types are defined Sender (SR),
  Receiver(RR), Goodbye (BYE), Source Description
  (SDES) and Application specific
• SR and RR reports contain statistics such as the
  number of packets sent,
  number of packets lost,
  inter-arrival jitter,
  etc.
• Used to modify sender(s) transmissions and for
  diagnostics
  purposes

50
RTCP Bandwidth Scaling

• RTCP attempts to limit its traffic to 5 of the
  session bandwidth.
• Example
• Suppose one sender, sending video at a rate of 2
  Mbps. Then RTCP attempts to limit its traffic to
  100 Kbps (5 of 2 Mbps)
• RTCP gives 75 of this rate to the receivers
  remaining 25 to the sender

• The 75 kbps is equally shared among receivers
• With R receivers, each receiver gets to send
  RTCP traffic at 75/R kbps.
• Sender gets to send RTCP traffic at 25 kbps.
• Participant determines RTCP packet transmission
  period by calculating avg RTCP packet size
  (across the entire session) and dividing by
  allocated rate.

51
RTCP Formats
52
SDES Types