T-110.5116 Computer Networks II Quality of Service

18.10.2010 Matti Siekkinen

(Some material from: J. Kurose, K. Ross: “Computer Networking: A Top Down Approach”, J. Manner: IP Quality of Service) October 18, 10

Outline

! What is QoS? ! Overview of QoS mechanisms ! Application level techniques

"  Media streaming example case o  Client or server based techniques

"  Overlays "  CDN

! Network-layer techniques "  Queuing, policing, resource reservation, … "  DiffServ, IntServ, RSVP "  Multiprotocol Label Switching (MPLS)

October 18, 10

What is Quality of Service?

! Many applications are sensitive to delay, jitter, and packet loss "  Too high values makes utility drop to zero

! Some mission-critical applications cannot tolerate disruption "  VoIP "  high-availability computing

! Charge more for business applications vs. consumer applications

! Related concept is service availability "  How likely is it that I can place a call and not get interrupted? "  requires meeting the QoS requirements for the given

application

October 18, 10

Example QoS Requirements

Personal voice over IP Network

monitoring

CEO Video conference with analysis

Financial Transactions

Interactive whiteboard

Unicast radio

Network management traffic Extranet

web traffic Public web traffic

Push news

Personal e-mail

Business e-mail

Server backups

Sensitive

Insensitive

Casual Critical

Delay

Mission Criticality

October 18, 10

QoS in Today’s Internet TCP/UDP/IP: “best-effort service” ! no guarantees on delay, loss

Today’s Internet applications use application-level techniques to mitigate

(as best possible) effects of delay, loss

But some apps (multimedia) require QoS and level of performance to be

effective!

• ? • ? • ? • ? • ?

• ?

• ? • ? • ?

• ?

• ?

October 18, 10

How should the Internet evolve to better support QoS?

Integrated services philosophy: !  fundamental changes in

Internet so that apps can reserve end-to-end bandwidth

!  requires new, complex software in hosts & routers

Laissez-faire !  no major changes !  more bandwidth when

needed !  content distribution,

application-layer multicast "  application layer

Differentiated services philosophy:

!  fewer changes to Internet infrastructure, yet provide 1st and 2nd class service

What’s your opinion?

October 18, 10

Outline

! What is QoS? ! Overview of QoS mechanisms ! Application level techniques

"  Media streaming example case o  Client or server based techniques

"  Overlays "  CDN

! Network-layer techniques "  Queuing, policing, resource reservation, … "  DiffServ, IntServ, RSVP "  Multiprotocol Label Switching (MPLS)

October 18, 10

QoS Mechanisms: classification

! Provisioning "  Admission control

o  Prohibit or allow new flows to enter the nw "  Resource reservation

! Control "  Operate on short time scales "  Real-time traffic or flow control

o  E.g. scheduling, shaping, policing... ! Management

"  Monitor the QoS "  Longer time scales than control

October 18, 10

QoS Mechanisms

Packet Scheduling

Admission Control

Traffic Shaping

(Users get their share of bandwidth) (Amount of traffic

users can inject into the network)

(To accept or reject a flow based on flow specifications)

Core

Adapt application behavior

October 18, 10

QoS Control Mechanisms

! Application-level techniques "  Application adapts to network conditions "  Use overlays

! Transport-layer techniques "  Adapt transport protocols to application requirements

and network conditions "  TCP, DCCP

! Network-layer techniques "  Scheduling (FIFO, WFQ) "  Queue mgmt (drop-tail, RED) "  Policing (leaky/token bucket)

Make the best out of best effort

October 18, 10

Outline

! What is QoS? ! Overview of QoS mechanisms ! Application level techniques

"  Media streaming example case o  Client or server based techniques

"  Overlays "  CDN

! Network-layer techniques "  Queuing, policing, resource reservation, … "  DiffServ, IntServ, RSVP "  Multiprotocol Label Switching (MPLS)

October 18, 10

Example case: Multimedia networking

! Streaming stored multimedia ! Interactive real time media

October 18, 10

Streaming stored media application-level streaming

techniques for making the best out of best effort service: "  client-side buffering "  use of UDP versus TCP "  multiple encodings of

multimedia

!  jitter removal !  decompression !  error concealment !  graphical user interface

w/ controls for interactivity

Media Player

October 18, 10

constant bit rate video transmission

Cum

ulat

ive

data

time

variable network

delay (jitter)

client video reception

constant bit rate video playout at client

client playout delay

buff

ered

vi

deo

Client buffering and jitter

! client-side buffering, playout delay compensate for network-added jitter

October 18, 10

Client Buffering

! client-side buffering, playout delay compensate for network-added jitter

buffered video

variable fill rate, x(t)

constant drain rate, d

October 18, 10

Streaming: UDP or TCP?

UDP ! server sends at rate appropriate for client (oblivious to

network congestion !) "  often send rate = encoding rate = constant rate "  then, fill rate = constant rate - packet loss

! short playout delay (2-5 seconds) to remove network jitter

! error recover: time permitting TCP ! send at maximum possible rate under TCP ! fill rate fluctuates due to TCP congestion control !  larger playout delay: smooth TCP delivery rate ! HTTP/TCP passes more easily through firewalls

October 18, 10

Streaming Multimedia: client rate(s)

Q: how to handle different client receive rate capabilities? ! 28.8 Kbps dialup !  100 Mbps Ethernet

A: server stores, transmits multiple copies of video, encoded at different rates

1.5 Mbps encoding

28.8 Kbps encoding

October 18, 10

Real-time interactive applications ! PC-2-PC phone

"  Skype ! PC-2-phone

"  Dialpad "  Net2phone "  Skype

! videoconference with webcams "  Skype "  Polycom

Going to now look at a PC-2-PC Internet phone example in detail

October 18, 10

Interactive Multimedia: Internet Phone

! speaker’s audio: alternating talk spurts, silent periods. "  64 kbps during talk spurt "  pkts generated only during talk spurts "  20 msec chunks at 8 Kbytes/sec: 160 bytes

data ! application-layer header added to each chunk. ! chunk+header encapsulated into UDP segment. ! application sends UDP segment into socket every

20 msec during talkspurt

October 18, 10

Internet Phone: Packet Loss and Delay

! network loss: IP datagram lost due to network congestion (router buffer overflow)

! delay loss: IP datagram arrives too late for playout at receiver "  delays: processing, queueing in network; end-

system (sender, receiver) delays "  typical maximum tolerable delay: 400 ms

! loss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.

October 18, 10

Internet Phone: Fixed Playout Delay

! receiver attempts to playout each chunk exactly q msecs after chunk was generated. "  chunk has time stamp t: play out chunk at t+q . "  chunk arrives after t+q: data arrives too late

for playout, data “lost” ! tradeoff in choosing q:

"  large q: less packet loss "  small q: better interactive experience

October 18, 10

Fixed Playout Delay

!  sender generates packets every 20 msec during talk spurt. !  first packet received at time r !  first playout schedule: begins at p !  second playout schedule: begins at p’

October 18, 10

Adaptive Playout Delay (1)

dynamic estimate of average delay at receiver:

where u is a fixed constant (e.g., u = .01).

!  Goal: minimize playout delay, keeping delay loss rate low !  Approach: adaptive playout delay adjustment:

"  estimate network delay, adjust playout delay at beginning of each talk spurt.

"  silent periods compressed and elongated. "  chunks still played out every 20 msec during talk spurt.

October 18, 10

Adaptive playout delay (2)

!  also useful to estimate average deviation of delay, vi :

!  estimates di , vi calculated for every received packet but used only at start of talk spurt

!  for first packet in talk spurt, playout time is:

where K is positive constant

!  remaining packets in talk spurt are played out periodically

October 18, 10

Adaptive Playout (3)

Q: How does receiver determine whether packet is first in a talkspurt?

! if no loss, receiver looks at successive timestamps. "  difference of successive stamps > 20 msec -->talk

spurt begins. ! with loss possible, receiver must look at both time

stamps and sequence numbers. "  difference of successive stamps > 20 msec and

sequence numbers without gaps --> talk spurt begins.

October 18, 10

Recovery from packet loss (1)

Forward Error Correction (FEC): simple scheme

! for every group of n chunks create redundant chunk by exclusive OR-ing n original chunks

! send out n+1 chunks, increasing bandwidth by factor 1/n.

! can reconstruct original n chunks if at most one lost chunk from n+1 chunks

! playout delay: enough time to receive all n+1 packets

! tradeoff: "  increase n, less

bandwidth waste "  increase n, longer

playout delay "  increase n, higher

probability that 2 or more chunks will be lost

October 18, 10

Recovery from packet loss (2) 2nd FEC scheme !  “piggyback lower quality stream” !  send lower resolution audio stream as redundant information !  e.g., nominal stream PCM at 64 kbps and redundant stream GSM at 13 kbps.

!  whenever there is non-consecutive loss, receiver can conceal the loss. !  can also append (n-1)st and (n-2)nd low-bit rate chunk

October 18, 10

Recovery from packet loss (3)

Interleaving !  chunks divided into smaller

units !  for example, four 5 msec units

per chunk !  packet contains small units

from different chunks

!  if packet lost, still have most of every chunk

!  no redundancy overhead, but increases playout delay

October 18, 10

Overlay solutions

! QoS can also be provided by using overlay solutions (application layer)

! Consider "  Overlay node placement wrt. network topology "  Replication

! Examples "  RON Reliable Overlay Network "  Content distribution networks (CDN)

29 October 18, 10 30

RON: Resilient Overlay Networks

Premise: by building application overlay network, can increase performance and reliability of routing

Two-hop (application-level) Berkeley-to-Princeton route

application-layer router

Princeton Yale

Berkeley

October 18, 10 • 31

RON Can Outperform IP Routing

! IP routing does not adapt to congestion "  But RON can reroute when the direct path is congested

! IP routing is sometimes slow to converge "  But RON can quickly direct traffic through intermediary

! IP routing depends on AS routing policies "  But RON may pick paths that circumvent policies

! Then again, RON has its own overheads "  Packets go in and out at intermediate nodes

o  Performance degradation, load on hosts, and financial cost "  Probing overhead to monitor the virtual links

o  Limits RON to deployments with a small number of nodes

October 18, 10

Content distribution networks (CDNs)

Content replication !  challenging to stream large

files (e.g., video) from single origin server in real time

!  solution: replicate content at hundreds of servers throughout Internet "  content downloaded to CDN

servers ahead of time "  placing content “close” to

user avoids impairments (loss, delay) of sending content over long paths

"  CDN server typically in edge/access network

origin server in North America

CDN distribution node

CDN server in S. America CDN server

in Europe

CDN server in Asia

October 18, 10

Content distribution networks (CDNs)

Content replication ! CDN (e.g., Akamai)

customer is the content provider (e.g., CNN)

! CDN replicates customers’ content in CDN servers.

! when provider updates content, CDN updates servers

origin server in North America

CDN distribution node

CDN server in S. America CDN server

in Europe

CDN server in Asia

• October 18, 10

CDN example

origin server (www.foo.com)

! distributes HTML ! replaces: http://www.foo.com/sports.ruth.gif

with http://www.cdn.com/www.foo.com/sports/ruth.gif

CDN company (cdn.com) !  distributes gif files !  uses its authoritative

DNS server to route redirect requests

HTTP request for www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

origin server

CDN’s authoritative DNS server

CDN server near client

client

October 18, 10

More about CDNs routing requests ! CDN creates a “map”, indicating distances from

leaf ISPs and CDN nodes ! when query arrives at authoritative DNS server:

"  server determines ISP from which query originates "  uses “map” to determine best CDN server

! CDN nodes create application-layer overlay network

October 18, 10

Outline

! What is QoS? ! Overview of QoS mechanisms ! Application level techniques

"  Media streaming example case o  Client or server based techniques

"  Overlays "  CDN

! Network-layer techniques "  Queuing, policing, resource reservation, … "  DiffServ, IntServ, RSVP "  Multiprotocol Label Switching (MPLS)

October 18, 10

Providing Multiple Classes of Service !  thus far: making the best of best effort service

"  one-size fits all service model ! alternative: multiple classes of service

"  partition traffic into classes "  network treats different classes of traffic differently

(analogy: VIP service vs regular service)

• 0111

! granularity: differential service among multiple classes, not among individual connections

! history: ToS bits

October 18, 10

Multiple classes of service: scenario

R1 R2 H1

H2

H3

H4 1.5 Mbps link R1 output

interface queue

October 18, 10

Scenario 1: mixed FTP and audio ! Example: 1Mbps IP phone, FTP share 1.5 Mbps link.

"  bursts of FTP can congest router, cause audio loss "  want to give priority to audio over FTP

packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly

Principle 1

R1 R2

October 18, 10

Principles for QOS Guarantees (more)

! what if applications misbehave? (audio sends higher than declared rate) "  policing: force source adherence to bandwidth allocations

! marking and policing at network edge:

provide protection (isolation) for one class from others Principle 2

R1 R2

1.5 Mbps link

1 Mbps phone

packet marking and policing

October 18, 10

Principles for QOS Guarantees (more)

! Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows don’t use their allocation

While providing isolation, it is desirable to use resources as efficiently as possible

Principle 3

R1 R2

1.5 Mbps link

1 Mbps phone

1 Mbps logical link

0.5 Mbps logical link

October 18, 10

Scheduling And Policing Mechanisms ! scheduling: choose next packet to send on link ! FIFO (first in first out) scheduling: send in order

of arrival to queue "  discard policy: if packet arrives to full queue: who to

discard? o  Tail drop: drop arriving packet o  priority: drop/remove on priority basis o  random: drop/remove randomly

October 18, 10

Scheduling Policies: more Priority scheduling: transmit highest priority

queued packet ! multiple classes, with different priorities

"  class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..

October 18, 10

Scheduling Policies: still more round robin scheduling: ! multiple classes ! cyclically scan class queues, serving one from

each class (if available)

October 18, 10

Scheduling Policies: still more Weighted Fair Queuing: ! generalized Round Robin ! each class gets weighted amount of service in

each cycle

October 18, 10

Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three common-used criteria: ! (Long term) Average Rate: how many pkts can be

sent per unit time (in the long run) "  crucial question: what is the interval length: 100

packets per sec or 6000 packets per min have same average!

! Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 pps peak rate

! (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

October 18, 10

Policing Mechanisms Token Bucket: limit input to specified Burst Size

and Average Rate.

! bucket can hold b tokens ! tokens generated at rate r token/sec unless

bucket full ! over interval of length t: number of packets

admitted less than or equal to (r t + b). October 18, 10

Policing Mechanisms (more) ! token bucket, WFQ combine to provide guaranteed

upper bound on delay, i.e., QoS guarantee!

WFQ

token rate, r

bucket size, b per-flow rate, R

D = b/R max

arriving traffic

October 18, 10

IETF Differentiated Services ! want “qualitative” service classes

"  “behaves like a wire” "  relative service distinction: Platinum, Gold, Silver

! scalability: simple functions in network core, relatively complex functions at edge routers (or hosts) "  signaling, maintaining per-flow router state

difficult with large number of flows ! don’t define define service classes, provide

functional components to build service classes

October 18, 10

Core router: ! per class traffic

management !  buffering and scheduling

based on marking at edge !  preference given to in-

profile packets

Diffserv Architecture Edge router: ! per-flow traffic

management ! marks packets as in-profile

and out-profile

scheduling

. . .

r

b

marking

October 18, 10

Edge-router Packet Marking

User packets

Rate A

B

! profile: pre-negotiated rate A, bucket size B ! packet marking at edge based on per-flow profile

Possible usage of marking: ! class-based marking: packets of different classes

marked differently !  intra-class marking: conforming portion of flow marked

differently than non-conforming one

October 18, 10

Classification and Conditioning

! Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6

! 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive

! 2 bits are currently unused

October 18, 10

Classification and Conditioning

may be desirable to limit traffic injection rate of some class:

! user declares traffic profile (e.g., rate, burst size) ! traffic metered, shaped if non-conforming

October 18, 10

Forwarding (PHB)

! PHB result in a different observable (measurable) forwarding performance behavior

! PHB does not specify what mechanisms to use to ensure required PHB performance behavior

! Examples: "  Class A gets x% of outgoing link bandwidth over time

intervals of a specified length "  Class A packets leave first before packets from class B

October 18, 10

Forwarding (PHB)

PHBs being developed: ! Expedited Forwarding: pkt departure rate of a class

equals or exceeds specified rate "  logical link with a minimum guaranteed rate

! Assured Forwarding: 4 classes of traffic "  each guaranteed minimum amount of bandwidth "  each with three drop preference partitions

October 18, 10

Expedited Forwarding

!  Expedited packets experience a traffic-free network (low loss, low latency, low jitter, and assured bandwidth (premium service)

! Strict priority queuing

56

October 18, 10

Assured Forwarding !  A possible implementation of the data flow for assured forwarding

is shown below. !  AF PHB delivers the packet with high assurance as long as its class

does not exceed the a subscribed rate !  Use e.g. WFQ scheduling with RED

57 October 18, 10

Principles for QOS Guarantees (more)

! Basic fact of life: can not support traffic demands beyond link capacity

Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs

Principle 4

R1 R2

1.5 Mbps link

1 Mbps phone

1 Mbps phone

October 18, 10

QoS guarantee scenario ! Resource reservation

"  call setup, signaling (RSVP) "  traffic, QoS declaration "  per-element admission control

QoS-sensitive scheduling (e.g.,

WFQ)

request/ reply

October 18, 10

! architecture for providing QOS guarantees in IP networks for individual application sessions

! resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s

! admit/deny new call setup requests:

Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

IETF Integrated Services

October 18, 10

Call Admission

Arriving session must : ! declare its QOS requirement

"  R-spec: defines the QOS being requested ! characterize traffic it will send into network

"  T-spec: defines traffic characteristics ! signaling protocol: needed to carry R-spec and

T-spec to routers (where reservation is required) "  RSVP

October 18, 10

Intserv QoS: Service models [rfc2211, rfc 2212]

Guaranteed service: ! worst case traffic arrival:

leaky-bucket-policed source ! simple (mathematically

provable) bound on delay [Parekh 1992, Cruz 1988]

Controlled load service: !  "a quality of service closely

approximating the QoS that same flow would receive from an unloaded network element."

WFQ

token rate, r

bucket size, b per-flow rate, R

D = b/R max

arriving traffic

October 18, 10

Signaling in the Internet

connectionless (stateless)

forwarding by IP routers

best effort service

no network signaling protocols

in initial IP design

+ =

! New requirement: reserve resources along end-to-end path (end system, routers) for QoS

! RSVP: Resource Reservation Protocol [RFC 2205] "  “ … allow users to communicate requirements to network in

robust and efficient way.” i.e., signaling ! ! earlier Internet Signaling protocol: ST-II [RFC 1819]

October 18, 10

RSVP Design Goals 1.  accommodate heterogeneous receivers (different

bandwidth along paths) 2.  accommodate different applications with

different resource requirements 3.  make multicast a first class service, with

adaptation to multicast group membership 4.  leverage existing multicast/unicast routing, with

adaptation to changes in underlying unicast, multicast routes

5.  control protocol overhead to grow (at worst) linear in # receivers

6.  modular design for heterogeneous underlying technologies

October 18, 10

RSVP: does not…

! specify how resources are to be reserved "  rather: a mechanism for communicating needs

! determine routes packets will take "  that’s the job of routing protocols "  signaling decoupled from routing

! interact with forwarding of packets "  separation of control (signaling) and data (forwarding)

planes

October 18, 10

RSVP: overview of operation ! senders, receiver join a multicast group

"  done outside of RSVP "  senders need not join group

! sender-to-network signaling "  path message: make sender presence known to routers "  path teardown: delete sender’s path state from routers

! receiver-to-network signaling "  reservation message: reserve resources from sender(s) to

receiver "  reservation teardown: remove receiver reservations

! network-to-end-system signaling "  path error "  reservation error

October 18, 10

IntServ: Scalability Issues

!  RSVP signaling Overhead "  One PATH/RESV per flow for each refresh period (soft

state)

!  Processing overhead "  Routers have to classify, police and queue each flow

! State information stored in routers "  Flow identification (using IP address, port etc) "  Previous hop identification "  Reservation Status "  Reserved Resources

67 October 18, 10

Multiprotocol Label Switching (MPLS)

! Mainly used for traffic engineering "  Allocate specific path and network resources to specific types of

traffic ensuring QoS ! Sort of on layer 2.5

"  Above: IPv4, IPv6, IPX, AppleTalk "  Below: Ethernet, Token Ring, FDDI, ATM, Frame Relay, PPP

! Data transmission occurs on Label Switched Paths (LSP) "  Labels are distributed before data transmission using Label

Distribution Protocol (LDP), or RSVP, or piggybacked on BGP and OSPF

! FEC (Forward Equivalence Class) "  Representation of group of packets that share the same

requirements for their transport "  Assignment of FEC to a packet is done once only as it enters into

the network

68

October 18, 10

Model for MPLS Network !  Convergence of connection oriented forwarding techniques and

Internet’s routing protocols !  Route at edge, switch at core

LSR = Label Switched Router LER = Label Edge Router LSP = Label Switched Path

LSP

LSP

LSR

LER

October 18, 10

Separate forwarding and control

70

Forwarding:

Label Swapping

Control:

IP Router Software

Control:

IP Router Software

Forwarding:

Longest-match Lookup

Control:

ATM Forum Software

Forwarding:

Label Swapping

IP Router MPLS ATM Switch

Exact match instead of longest prefix match (like IP) #  faster forwarding

October 18, 10

MPLS Forwarding

71 October 18, 10

MPLS Operation

72

1a. Routing protocols (e.g. OSPF-TE) exchange reachability to destination networks

1b. Label Distribution Protocol (LDP) establishes label mappings to destination network

2. Ingress LER receives packet and “label”s packets

IP

IP 10

3. LSR forwards packets using label swapping

IP 20

4. LER at egress removes label and delivers packet

IP

MPLS Domain

Ingress

Egress

October 18, 10

MPLS Labels ! Label assignment decisions are based on forwarding criteria

like "  Destination unicast routing "  Traffic engineering "  Multicast "  Virtual Private Network "  Quality of Service

73

A Label could be embedded in the header of the DL layer like ATM (VPI/VCI) and FR (DLCI) or could be between DL and IP as shown below:

Bottom of Stack (first label in stack) October 18, 10

Label and FEC Relationship

!  FEC (Forwarding Equivalence Class): Assigned on the basis of IP addresses, port numbers or TOS bits.

!  FEC could be associated with all the flows destined to an egress LSR.

74

Assignment of FEC to a packet is done by ingress router

R4 could send a packet with Label=L1, but it would mean a different FEC

October 18, 10

Label Merging !  Label Switched Path (LSP): A unidirectional connection through

multiple LSRs. !  Label Merging: The replacement of multiple incoming labels for a

particular FEC with a single outgoing label. !  Labels are "downstream-assigned", and label bindings are

distributed in the "downstream to upstream“ direction.

75

Multi-point to Single point tree routed at Egress router

October 18, 10

!  A Packet can have several labels one after the other before the IP header. (Why? Tunneling)

76

(Multiple Levels of Nesting) (Tunnel 1 may be for the Enterprise with 1a for VoIP data, 1b for billing, and 1c for alarm & provisioning)

R1 R2 R3 R4

IP

3

R2A R2B R2C

7 2 6 2 8 2 4 IP

Push Swap & Push Swap Pop & Swap Pop

LSP Hierarchy

October 18, 10

Label Distribution

77

!  Establishes and Maintains a LSP that includes establishment of Label/FEC bindings between LSRs in the LSP.

!  A downstream LSR can directly distribute Label/FEC (unsolicited downstream).

!  An upstream LSR requests a downstream for Label/FEC (downstream on demand).

!  Protocols like LDP, RSVP-TE are used to distribute Labels in the LSP

October 18, 10

Label Distribution

78

!  Label Distribution Protocol (LDP) [RFC 3036] "  An LSR sends HELLO messages over UDP periodically to its

neighbors to discover LDP peers (routing protocol tells about peers) "  Upon discovery, it establishes a TCP connection to its peer "  Two peers then may negotiate Session parameters (label

distribution option, valid label ranges, and valid timers) "  They may then exchange LDP messages over the session (label

request, label mapping, label withdraw etc) !  RSVP-TE (Resource Reservation Protocol-Traffic Extension)

[RFC 3209] "  Path message includes a label request object, and Resv message

contains a label object "  Follows a downstream-on-demand model to distribute labels "  Path message could contain an Explicit Route Object (ERO) to

specify list of nodes "  Priorities can be assigned to LSPs, where a higher one can preempt

a lower one

October 18, 10

MPLS Protection

! Dynamic routing restores the traffic (upon a failure) based on the convergence time of the protocol "  Convergence can be slow

! Set up secondary backup paths in addition to primary working paths "  End-to-end protection

! May need really fast recovery for mission critical or high priority data "  Fast reroute: Setup detour paths around failed links/nodes "  Temporary recovery until backup path takes over

79 October 18, 10

IntServ, DiffServ and MPLS !  An RSVP request (say guaranteed service) from one domain could be mapped to an

appropriate DiffServ PHB at another domain that again could be mapped to a possible MPLS FEC at the edge of another MPLS domain.

80

October 18, 10

Generalized MPLS (GMPLS)

! MPLS – the base technology (for packet switched nws)

! GMPLS – extension of MPLS to provide the control plane (signaling and routing) for devices that switching in any of these domains: packet, time, wavelength and fiber.

81 October 18, 10

Is Internet QoS a failure and why?

! Some IP QoS mechanisms are utilized "  E.g. DiffServ, MPLS can be used in private networks

(ISPs) ! Globally Internet has no end-to-end QoS ! Some guesses of reasons for failure

"  not manageable across competing domains "  not configurable by normal users (or apps writers) "  no sufficient business model for ISPs "  no initial gain "  not incrementally deployable "  increase system vulnerability and resilience

82

October 18, 10

Wrapping up

! Some applications require a certain QoS level "  Different metrics important for different apps "  Service availability is important also

! QoS mechanisms developed on various layers "  Application, transport, network

! Today’s Internet is best effort in practice "  No end-to-end QoS guarantees possible

o  Would require usage and deployment of nw-layer techniques "  Application and transport level techniques used to make the

best out of best effort ! Some hop by hop (nw-layer) mechanisms used in private

networks

83 October 18, 10

References 1.  Andrew S. Tanenbaum, Computer Networks, Fourth Edition, Pearson Education, 2006. 2.  James F. Kurose, and Keith W. Ross: Computer Networking: A Top-Down Approach Featuring the Internet, Third Edition, Pearson Education,

2006. 3.  Alberto Leon-Garcia and Indra Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, Second Edition, Tata McGraw-

Hill, 2005. 4.  IP QoS Architectures and Protocols, Packet Broadband Network Handbook, Digital Engineering Library, McGraw Hill, 2004. 5.  Congestion Control and Quality of Service, Data Communication and Networking, Digital Engineering Library, McGraw Hill, 2006. 6.  Curado, M. and Monteiro, E. , "A Survey of QoS Routing Algorithms", in Proc. of the International Conference on Information Technology

(ICIT2004), December 2004 7.  Manner Jukka, Lopez A, Mihailovi A, Velayos H, Hepworth E, and Y Khouaja, Evaluation of Mobility and QoS Interaction, Computer Networks

Volume 38, Issue 2, 5 Feb 2002, pp. 137-163. 8.  Anup Kumar Talukdar, B. R. Badrinath, and Arup Acharya, MRSVP: A Resource Reservation Protocol for an Integrated Services Network with

Mobile Hosts, Wireless Networks, 7, 5–19, 2001. 9.  Rajeev Koodli, and Charles E. Perkins, Fast Handovers and Context Transfers in Mobile Networks, ACM SIGCOMM Computer Communications

Review, Special Issue on Wireless Extensions to Internet, 2001. 10.  J. Hillebrand, C.Prehofer, R. Bless, M. Zitterbart, Quality-of-Service Signaling for Next-Generation IP-based Mobile Networks, IEEE

Communications Magazine, June 2004. 11.  Seoung-Bum Lee, G. Ahn, X. Zhang and A. T. Campbell, INSIGNIA: An IP-Based Quality of Service Framework For Mobile Ad Hoc Networks,

Journal of Parallel and Distributed Computing, 2000. 12.  Chittaranjan Hota, Sanjay Jha, G Raghurama, Distributed Dynamic Resource Management in IP VPNs to Guarantee Quality of Service, IEEE

ICON 2004, Singapore. 13.  RFC 2205: Resource Reservation Protocol, Braden, Zhang et al. 14.  RFC 3031: Multiprotocol Label Switching (MPLS), Rosen, Viswanathan and Callon. 15.  RFC 2475: An Architecture for Differentiated Services, S. Blake, D. Black et al. 16.  RFC 4080: Next Steps in Signaling (NSIS): Framework, R. Hancock, G. Karagiannis et al., 2005. 17.  RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne et al., 1998 18.  GMPLS tutorial: http://www.iec.org/online/tutorials/gmpls/

84