UNIT - V

Protocols for QoS Support

INCREASED DEMANDS
Need

to incorporate bursty and stream traffic in TCP/IP architecture Increase capacity

Faster links, switches, routers Intelligent routing policies End-to-end flow control

Multicasting Quality

of Service (QoS) capability Transport protocol for streaming

RESOURCE RESERVATION - UNICAST

Prevention

as well as reaction to congestion

required Can do this by resource reservation Unicast

End users agree on QoS for task and request from network May reserve resources Routers pre-allocate resources If QoS not available, may wait or try at reduced QoS

RESOURCE RESERVATION MULTICAST

Generate

vast traffic

High volume application like video Lots of destinations

Can

reduce load

Some members of group may not want current transmission

Channels of video

Some members may only be able to handle part of transmission

Basic and enhanced video components of video stream

Routers

can decide if they can meet

demand

RESOURCE RESERVATION PROBLEMS ON AN INTERNET

Must interact with dynamic routing

Reservations must follow changes in route

Soft state a set of state information at a router that expires unless refreshed

End users periodically renew resource requests

RESOURCE RESERVATION PROTOCOL (RSVP) DESIGN GOALS

Enable receivers to make reservations

Different reservations among members of same multicast group allowed Dynamic reservations, separate for each member of group

Deal gracefully with changes in group membership

Aggregate for group should reflect resources needed

Take into account common path to different members of group

Receivers can select one of multiple sources (channel selection) Deal gracefully with changes in routes

Re-establish reservations

Control protocol overhead Independent of routing protocol

RSVP CHARACTERISTICS
Unicast and Multicast Simplex

Unidirectional data flow Separate reservations in two directions Receiver knows which subset of source transmissions it wants Responsibility of end users Users specify how reservations for groups are aggregated

Receiver initiated

Maintain soft state in internet

Providing different reservation styles

Transparent operation through non-RSVP routers Support IPv4 (ToS field) and IPv6 (Flow label field)

DATA FLOWS - SESSION

Data flow identified by destination Resources allocated by router for duration of session Defined by

Destination IP address

Unicast or multicast TCP, UDP etc. May not be used in multicast

IP protocol identifier

Destination port

FLOW DESCRIPTOR

Reservation Request

Flow spec
Desired QoS Used to set parameters in nodes packet scheduler Service class, Rspec (reserve), Tspec (traffic)

Filter spec
Set of packets for this reservation Source address, source prot

TREATMENT OF PACKETS OF ONE SESSION AT ONE ROUTER

RSVP OPERATION DIAGRAM

RSVP OPERATION
G1,

G2, G3 members of multicast group S1, S2 sources transmitting to that group Heavy black line is routing tree for S1, heavy grey line for S2 Arrowed lines are packet transmission from S1 (black) and S2 (grey) All four routers need to know reservation s for each multicast address

Resource requests must propagate back through routing tree

FILTERING

G3 has reservation filter spec including S1 and S2 G1, G2 from S1 only R3 delivers from S2 to G3 but does not forward to R4 G1, G2 send RSVP request with filter excluding S2 G1, G2 only members of group reached through R4
R4 doesnt need to forward packets from this session R4 merges filter spec requests and sends to R3

R3 no longer forwards this sessions packets to R4

Handling of filtered packets not specified Here they are dropped but could be best efforts delivery

R3 needs to forward to G3

Stores filter spec but doesnt propagate it

RESERVATION STYLES
Determines

manner in which resource requirements from members of group are aggregated Reservation attribute

Reservation shared among senders (shared)

Characterizing entire flow received on multicast address

Simultaneously capable of receiving data flow from each sender

Allocated to each sender (distinct)

Sender

selection

List of sources (explicit) All sources, no filter spec (wild card)

RESERVATION ATTRIBUTES AND STYLES

Reservation Attribute

Distinct
Sender selection explicit = Fixed filter (FF) Sender selection wild card = none

Shared
Sender selection explicit= Shared-explicit (SE) Sender selection wild card = Wild card filter (WF)

WILD CARD FILTER STYLE

Single

resource reservation shared by all senders to this address If used by all receivers: shared pipe whose capacity is largest of resource requests from receivers downstream from any point on tree Independent of number of senders using it Propagated upstream to all senders WF(*{Q})

* = wild card sender Q = flowspec

Audio

teleconferencing with multiple sites

FIXED FILTER STYLE

Distinct reservation for each sender Explicit list of senders FF(S1{Q!}, S2{Q2},) Video distribution

SHARED EXPLICIT STYLE

Single reservation shared among specific list of senders SE(S1, S2, S3, {Q}) Multicast applications with multiple data sources but unlikely to transmit simultaneously

RESERVATION STYLE EXAMPLES

RSVP PROTOCOL MECHANISMS

Two

message types

Resv
Originate at multicast group receivers Propagate upstream Merged and packet when appropriate Create soft states Reach sender

Allow host to set up traffic control for first hop

Path
Provide upstream routing information Issued by sending hosts Transmitted through distribution tree to all destinations

Chapter 18 Protocols for QoS Support

RSVP HOST MODEL

MULTIPROTOCOL LABEL SWITCHING (MPLS)

Routing

algorithms provide support for performance goals

Distributed and dynamic
React to congestion Load balance across network

Based on metrics

Develop information that can be used in handling different service needs

Enhancements

provide direct support

IS, DS, RSVP

Nothing

directly improves throughput or

delay MPLS tries to match ATM QoS support

BACKGROUND
Efforts

to marry IP and ATM IP switching (Ipsilon) Tag switching (Cisco) Aggregate route based IP switching (IBM) Cascade (IP navigator) All use standard routing protocols to define paths between end points Assign packets to path as they enter network Use ATM switches to move packets along paths
ATM switching (was) much faster than IP routers Use faster technology

DEVELOPMENTS
IETF

working group in 1997, proposed standard 2001 Routers developed to be as fast as ATM switches

Remove the need to provide both technologies in same network

MPLS

does provide new capabilities

QoS support Traffic engineering Virtual private networks Multiprotocol support

CONNECTION ORIENTED QOS SUPPORT

Guarantee

fixed capacity for specific applications Control latency/jitter Ensure capacity for voice Provide specific, guaranteed quantifiable SLAs Configure varying degrees of QoS for multiple customers MPLS imposes connection oriented framework on IP based internets

TRAFFIC ENGINEERING
Ability to dynamically define routes, plan resource commitments based on known demands and optimize network utilization Basic IP allows primitive traffic engineering

E.g. dynamic routing Able to balance load in face of demand Able to commit to different levels of support to meet user traffic requirements Aware of traffic flows with QoS requirements and predicted demand Intelligent re-routing when congested

MPLS makes network resource commitment easy

VPN SUPPORT
Traffic from a given enterprise or group passes transparently through an internet Segregated from other traffic on internet Performance guarantees Security

MULTIPROTOCOL SUPPORT
MPLS

can be used on different network technologies IP

Requires router upgrades

Coexist with ordinary routers

ATM

Enables and ordinary switches co-exist

Frame Mixed

relay network

Enables and ordinary switches co-exist

MPLS TERMINOLOGY

MPLS OPERATION
Label

switched routers capable of switching and routing packets based on label appended to packet Labels define a flow of packets between end points or multicast destinations Each distinct flow (forward equivalence class FEC) has specific path through LSRs defined

Connection oriented

Each

FEC has QoS requirements IP header not examined

Forward based on label value

MPLS OPERATION DIAGRAM

EXPLANATION - SETUP
Labelled

switched path established prior to routing and delivery of packets QoS parameters established along path
Resource commitment Queuing and discard policy at LSR Interior routing protocol e.g. OSPF used Labels assigned

Local significance only Manually or using Label distribution protocol (LDP) or enhanced version of RSVP

EXPLANATION PACKET HANDLING

Packet enters domain through edge LSR

Processed to determine QoS

LSR

assigns packet to FEC and hence LSP

May need co-operation to set up new LSP

Append

label Forward packet Within domain LSR receives packet Remove incoming label, attach outgoing label and forward Egress edge strips label, reads IP header and forwards

NOTES

MPLS domain is contiguous set of MPLS enabled routers Traffic may enter or exit via direct connection to MPLS router or from non-MPLS router FEC determined by parameters, e.g. Source/destination IP address or network IP address Port numbers IP protocol id Differentiated services codepoint IPv6 flow label Forwarding is simple lookup in predefined table Map label to next hop Can define PHB at an LSR for given FEC Packets between same end points may belong to different FEC

MPLS PACKET FORWARDING

LABEL STACKING
Packet

may carry number of labels LIFO (stack)

Processing based on top label Any LSR may push or pop label

Unlimited levels

Allows aggregation of LSPs into single LSP for part of route C.f. ATM virtual channels inside virtual paths E.g. aggregate all enterprise traffic into one LSP for access provider to handle Reduces size of tables

LABEL FORMAT DIAGRAM

Label

value: Locally significant 20 bit Exp: 3 bit reserved for experimental use

E.g. DS information or PHB guidance

S:

1 for oldest entry in stack, zero otherwise Time to live (TTL): hop count or TTL value

TIME TO LIVE PROCESSING

Needed to support TTL since IP header not read First label TTL set to IP header TTL on entry to MPLS domain TTL of top entry on stack decremented at internal LSR

If zero, packet dropped or passed to ordinary error processing (e.g. ICMP) If positive, value placed in TTL of top label on stack and packet forwarded

At exit from domain, (single stack entry) TTL decremented

If zero, as above If positive, placed in TTL field of Ip header and forwarded

LABEL STACK
Appear after data link layer header, before network layer header Top of stack is earliest (closest to network layer header) Network layer packet follows label stack entry with S=1 Over connection oriented services

Topmost label value in ATM header VPI/VCI field Facilitates ATM switching Top label inserted between cell header and IP header In DLCI field of Frame Relay Note: TTL problem

POSITION OF MPLS LABEL STACK

FECS, LSPS, AND LABELS

Traffic grouped into FECs Traffic in a FEC transits an MLPS domain along an LSP Packets identified by locally significant label At each LSR, labelled packets forwarded on basis of label.

LSR replaces incoming label with outgoing label

Each flow must be assigned to a FEC Routing protocol must determine topology and current conditions so LSP can be assigned to FEC

Must be able to gather and use information to support QoS

LSRs must be aware of LSP for given FEC, assign incoming label to LSP, communicate label to other LSRs

TOPOLOGY OF LSPS

Unique ingress and egress LSR

Single path through domain

Multiple paths, possibly sharing final few hops

Unique egress, multiple ingress LSRs

Multiple egress LSRs for unicast traffic Multicast

ROUTE SELECTION
Selection

of LSP for particular FEC Hop-by-hop

LSR independently chooses next hop Ordinary routing protocols e.g. OSPF Doesnt support traffic engineering or policy routing

Explicit

LSR (usually ingress or egress) specifies some or all LSRs in LSP for given FEC Selected by configuration,or dynamically

CONSTRAINT BASED ROUTING ALGORITHM

Take

in to account traffic requirements of flows and resources available along hops

Current utilization, existing capacity, committed services Additional metrics over and above traditional routing protocols (OSPF)
Max link data rate Current capacity reservation Packet loss ratio Link propagation delay

LABEL DISTRIBUTION
Setting up LSP Assign label to LSP Inform all potential upstream nodes of label assigned by LSR to FEC

Allows proper packet labelling Learn next hop for LSP and label that downstream node has assigned to FEC

Allow LSR to map incoming to outgoing label

REAL TIME TRANSPORT PROTOCOL

TCP not suited to real time distributed application

Point to point so not suitable for multicast Retransmitted segments arrive out of order No way to associate timing with segments

UDP does not include timing information nor any support for real time applications Solution is real-time transport protocol RTP

RTP ARCHITECTURE

Close coupling between protocol and application layer functionality

Framework for application to implement single protocol

Application level framing Integrated layer processing

APPLICATION LEVEL FRAMING

Recovery of lost data done by application rather than transport layer

Application may accept less than perfect delivery

Real time audio and video Inform source about quality of delivery rather than retransmit Source can switch to lower quality

Application may provide data for retransmission

Sending application may recompute lost values rather than storing them Sending application can provide revised values Can send new data to fix consequences of loss

Lower layers deal with data in units provided by application

Application data units (ADU)

INTEGRATED LAYER PROCESSING

Adjacent layers in protocol stack tightly coupled Allows out of order or parallel functions from different layers

RTP ARCHITECTURE DIAGRAM

RTP DATA TRANSFER PROTOCOL

Transport of real time data among number of participants in a session, defined by:

RTP Port number

UDP destination port number if using UDP Destination port address used by all participants for RTCP transfer Multicast or set of unicast

RTP Control Protocol (RTCP) port number

IP addresses

MULTICAST SUPPORT
Each RTP data unit includes: Source identifier Timestamp Payload format

RELAYS
Intermediate

system acting as receiver and transmitter for given protocol layer Mixers
Receives streams of RTP packets from one or more sources Combines streams Forwards new stream

Translators

Produce one or more outgoing RTP packets for each incoming packet E.g. convert video to lower quality

RTP HEADER

RTP CONTROL PROTOCOL (RTCP)

RTP is for user data RTCP is multicast provision of feedback to sources and session participants Uses same underlying transport protocol (usually UDP) and different port number RTCP packet issued periodically by each participant to other session members

RTCP FUNCTIONS
QoS and congestion control Identification Session size estimation and scaling Session control

RTCP TRANSMISSION

Number of separate RTCP packets bundled in single UDP datagram

Sender report Receiver report Source description Goodbye Application specific

RTCP PACKET FORMATS

PACKET FIELDS (ALL PACKETS)

Version

(2 bit) currently version 2 Padding (1 bit) indicates padding bits at end of control information, with number of octets as last octet of padding Count (5 bit) of reception report blocks in SR or RR, or source items in SDES or BYE Packet type (8 bit) Length (16 bit) in 32 bit words minus 1 In addition Sender and receiver reports have:

Synchronization Source Identifier

PACKET FIELDS (SENDER REPORT) SENDER INFORMATION BLOCK

NTP timestamp: absolute wall clock time when report sent RTP Timestamp: Relative time used to create timestamps in RTP packets Senders packet count (for this session) Senders octet count (for this session)

PACKET FIELDS (SENDER REPORT) RECEPTION REPORT BLOCK

SSRC_n (32 bit) identifies source refered to by this report block Fraction lost (8 bits) since previous SR or RR Cumulative number of packets lost (24 bit) during this session Extended highest sequence number received (32 bit)

Least significant 16 bits is highest RTP data sequence number received from SSRC_n Most significant 16 bits is number of times sequence number has wrapped to zero

Interarrival jitter (32 bit) Last SR timestamp (32 bit) Delay since last SR (32 bit)

RECEIVER REPORT

Same as sender report except:

Packet type field has different value No sender information block

SOURCE DESCRIPTION PACKET

Used by source to give more information 32 bit header followed by zero or more additional information chunks E.g.: 0 END End of SDES list 1 CNAME Canonical name 2 NAME Real user name of source 3 EMAIL Email address

GOODBYE (BYE)

Indicates one or more sources no linger active

Confirms departure rather than failure of network

APPLICATION DEFINED PACKET

Experimental use For functions & features that are application specific