Computer Networks: Mechanisms for Quality of Service

Computer Networks:Mechanisms for Quality of

Service

Ivan Marsic

Rutgers University

Chapter 5 - Mechanisms for Quality-of-Service

Mechanisms forQuality-of-Service

Chapter 5

Topic:Scheduling

Max-Min Fair Share

Fair Queuing (FQ)

Weighted Fair Queuing (WFQ)

Why Scheduling?

• To prevent aggressive or misbehaving sources from overtaking network resources

• To provide preferential service to packets

from preferred sources

Scheduler

Classifier Scheduler

Transmitter(Server)

Arriving packets

Class n queue

Class 1 queue (Waiting line)

Class 2 queue

Packet dropwhen queue full

Schedulingdiscipline

Scheduler Design Concerns

• Classification policy for forming the queues:– Priority based

– Source identity based

– Flow identity based (source-destination pair)

– …

• Scheduling policy for taking packets into service:– Round robin

– Work conserving vs. Non-work conserving

Fair Share of a Resource

desired: 1/8

desired: 1/3

desired:2/3

P3

P2

P1

Max-Min Fair Share (1)

desired: 1/8

Fair share: 1/3 each

1. Satisfy customers who need less than their fair share2. Split the remainder equally among the remaining customers

Return surplus:1/3 1/8 = 5/24

New fair sharefor P2 & P3:

1/3 + ½ (5/24) each

P1

P3

P2


received: 1/8

Fair share:1/3 + ½ (5/24) each


Return surplus:1/3 + ½ (5/24) 1/3= ½ (5/24)

Remainder of

1/3 + 2 ½ (5/24)

goes to P2

P1

P3

P2


received: 1/8

Final fair distribution:

received: 1/3

P1

P3

P2

received: 1/3 + 5/24

deficit: 1/8

Max-Min Fair Share

desired: 1/8

desired: 1/3

desired:2/3

P3

P2

P1

desired: 1/8

Fair share: 1/3 each


Return surplus:1/3 1/8 = 5/24

New fair sharefor P2 & P3:

1/3 + ½ (5/24) each

P1

P3

P2

received: 1/8

Final fair distribution:

received: 1/3

P1

P3

P2

received: 1/3 + 5/24

deficit: 1/8

received: 1/8

Fair share:1/3 + ½ (5/24) each


Return surplus:1/3 + ½ (5/24) 1/3= ½ (5/24)

Remainder of

1/3 + 2 ½ (5/24)

goes to P2

P1

P3

P2

ba

c d

Example 5.1: Max-Min Fair Share

Link capacity= 1 Mbps

Wi-Fi transmitter(Server)

Application 1

Application 2

Application 3

Application 4

8 packets per secL1 = 2048 bytes

40 pkts/sL4 = 1 KB

25 pkts/sL2 = 2 KB

50 pkts/sL3 = 512 bytes

Link capacity= 1 Mbps

Wi-Fi transmitter(Server)

Application 1

Application 2

Application 3

Application 4

8 packets per secL1 = 2048 bytes

40 pkts/sL4 = 1 KB

25 pkts/sL2 = 2 KB

50 pkts/sL3 = 512 bytes50 pkts/sL3 = 512 bytes

Example 5.1: Max-Min Fair Share

8 2048 + 25 2048 + 50 512 + 40 1024 = 134,144 bytes/sec = 1,073,152 bits/secAppl. A Appl. B Appl. C Appl. D Total demand

available capacity of the link is C = 1 Mbps = 1,000,000 bits/sec

Sources Demands [bps]

Balances after 1st round

Allocation #2 [bps]

Balances after 2nd round

Allocation #3 (Final) [bps]

Final balances

Application 1 131,072 bps 118,928 bps 131,072 0 131,072 bps 0

Application 2 409,600 bps 159,600 bps 332,064 77,536 bps 336,448 bps 73,152 bps

Application 3 204,800 bps 45,200 bps 204,800 0 204,800 bps 0

Application 4 327,680 bps 77,680 bps 332,064 4,384 bps 327,680 bps 0

Weighted Max-Min Fair Share:Source weights : w1 = 0.5, w2 = 2, w3 = 1.75, and w4 = 0.75

Src Demands Allocation #1 [bps]

Balances after 1st round

Allocation #2 [bps]

Balances after 2nd round

Allocation #3 (Final) [bps]

Final balances

1 131,072 bps 100,000 31,072 122,338 8,734 bps 131,072 bps 0

2 409,600 bps 400,000 9,600 489,354 79,754 bps 409,600 bps 0

3 204,800 bps 350,000 145,200 204,800 0 204,800 bps 0

4 327,680 bps 150,000 177,680 183,508 144,172 bps 254,528 bps 73,152 bps

Implementing MMFS with Packets

• Problem: Packets are of different length, arrive randomly, and must be transmitted atomically, as a whole– Packets cannot be split in pieces to satisfy the

MMFS bandwidth allocation

• Solution: Fair Queuing (FQ)

Example: Airport Check-in

First-classpassengers

?Customerin service

Server

Waiting lines (queues)

XE,1 = 2XE,2 = 5Service times: XE,3 = 3

Service time: XF,1 = 8

Economy-classpassengers

Classification

Bit-by-bit GPS

Transmitter(Server)

Flow 1 queue

Flow 2 queue

Flow 3 queue

Bit-by-bitround robinservice

FQ: Run an imaginary GPS simulation, to find when packet transmission would be finished if its bits could be transmitted one-by-one

Bit-by-bit GPS

GPS Transmitter(imaginary)

Flow 1 queue

Flow 2 queue

Flow 3 queue

Bit-by-bitround robinservice

Server

pkt A 3,1

pkt A2,2 | pkt A2,1

1st

bit

from

pkt

A2,

1

1st

bit

from

pkt

A3,

1

2nd

bit

from

pkt

A2,

1

2nd

bit

from

pkt

A3,

1

3rd

bit

from

pkt

A2,

1

1st

bit

from

pkt

A2,

2

2nd

bit

from

pkt

A2,

2

3-bit packets

2-bit packets

1st round2nd round

3rd round4th round

5th round

1st ro

und

2nd

roun

d

3rd

roun

d

4th

roun

d

packetA2,1

packetA2,2

FQ Transmitter(real)

Flow 1 queue

Flow 2 queue

Flow 3 queue

Packet-by-packetround robinservice

Server

pkt A 3,1

pkt A2,2 | pkt A2,1

packetA3,1

1st round2nd round3rd round

1st ro

und

2nd

roun

d

3rd

roun

d

(a)

(b)

Bit-by-bit GPS -- Example

Flow 1

Flow 2

Flow 3

Time

Roundnumber

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

L1 = 3 bits

L2 = 3 bits

L3 = 2 bits

3 41 2

A1,1

A2,1

A2,2

A3,1

A3,2

86 75

Waiting

Ai,j Arrival

Service

Finish

Waiting

Ai,j Arrival

Service

Finish

GPS Round Number vs. Time

10 2 3 4 5 6 7 8 9 10 11 12 13 14

Time t

Ro

un

d n

um

be

r R

(t)

1

2

3

4

5

6

7

8

F2(t)

F1(t)

F3(t)

Roundnumber

slope

= 1

/1

slope = 1/2

slope = 1/3

slope

= 1

/1

slope = 1/2

Example 5.3: GPS Round Numbers

Flo

w 1

:

Flo

w 2

:

Flo

w 3

:

Flo

w 4

: 0 1 2 3 4 5

0

1

2

3

4

1/2

1/1

P1,1, P3,1Time t

Rou

nd

num

ber

R(t

)a

2 3 4 5 6 7 8 9 10 11

1/1

1/3

1/1

P2,1, P4,1Time tF

low

1:

Flo

w 2

:

Flo

w 3

:

Flo

w 4

:

1

2

3

4

5

6

Rou

nd

num

ber

R(t

)b

4,096 bytes@Flow3t = 12






Packet sizeFlow IDArrival time







Packet sizeFlow IDArrival time

Example 5.3: GPS Round Numbers (Cont’d)

Flo

w 1

:

Flo

w 2

:

Flo

w 3

:

Flo

w 4

: 0 1 2 3 4 5 6 7 8 9 10 11 12

0

1

2

3

4

5

6

7

1/2

1/1

1/3

1/4

1/1

13

P 1,1, P

3,1

P 2,1, P

4,1

P 3,2

P 3,3

Rou

nd

num

ber

R(t

)

Time t

0 16,384

@10 4,096

@33 16,384

@23 8,192

@46 4,096

@312 4,096

@3

Example 5.3: Fair Queuing

Flow 1

Flow 2

Flow 3

Time [ms]

L1 = 2 KB

L2 = 2 KB

L3 = 512 B

Flow 4

L4 = 1 KB

0 4.096 8.192 12.288 16.384 20.480 24.576 28.672 32.768 36.864 40.96 45.056 49.152 53.248

Waiting

Ai,j Arrival

Service

A1,1

A2,1

A3,1

A3,2

A4,1

A3,3A3,3

Example 4.4: Fair Queuing (1)

TimeA1,2 A1,3 A1,4 A1,8

A2,2 A2,4

A4,2 A4,3 A4,4 A4,5 A4,6 A4,7 A4,8 A4,9 A4,19

0 1 sec

A3,2 A3,3 A3,4 A3,5 A3,6 A3,7 A3,8 A3,9 A3,10 A3,33A3,32A3,11

Flow 1

Flow 2

Flow 3

Flow 4

A1,1

A2,1

A4,1

A3,1

Example 4.4: Fair Queuing (2b)

Time [msec]

111.11

Flow 1

Flow 2

Flow 3

Flow 4

A1,1

A4,2 A4,3

A3,4 A3,5

X1,1X4,2 X3,4

A3,6

128.71 146.31

Packet intransmission

W3,4 W3,5 ?

W4,3 ?

?

181.15

111.11

125

142.86

156.25 111.11

166.67

W1,1

W3,6

Topic:Policing

Leaky Bucket Algorithm

Delay Magnitude & Variability

Time

Del

ay

Average delay

Traffic pattern 1

Traffic pattern 2

Leaky Bucket

tokens generatedat rate r [tokens/sec]

bucket holdsup to b tokens

1 token dispensed for each packet

token-operated turnstile

(a) (b)packet

b = bucket capacity

r tokens/sec

Tokenwaiting area

Token dispenser (bucket)

Tokengenerator

Regulator

arrivingpackets

to network

b = bucket capacity

r tokens/sec

Tokenwaiting area

Token dispenser (bucket)

Tokengenerator

Regulator

arrivingpackets

to network

Topic:Active Queue Management

Random Early Detection (RED) Explicit Congestion Notification (ECN)

Why Active Queue Management

Co

nge

stio

n W

ind

ow

s

Synchronized TCP senders De-synchronized TCP senders

Time Time

Re

sour

ce u

sage

(a) (b)

Random Early Detection (RED)

Router buffer

(a)

Packet currently in service

Head of the queue

Random-drop zone:Packets might be dropped

ThresholdMin(Drop start location)

ThresholdMax

To network

Never droppedAlways dropped

Arriving packets

(b)

Server

(drop)Ptemp(drop)Ptemp

AverageQLen

ThresholdMin ThresholdMax0

1.0

Full

PmaxPmax


AverageQLen(t) = (1) AverageQLen(t1) MeasuredQLen(t)

)(

)()(

minmax

minmaxtemp ThresholdThreshold

ThresholdnAverageQLePnAverageQLeP

)(1

)()(

temp

temp

nAverageQLePcount

nAverageQLePnAverageQLeP

(5.6)

(5.4)

(5.5)


Listing 5-1: Summary of the RED algorithm.

Set count = 1

For each newly arrived packet, do:

1. Calculate AvgQLen using equation (5.4)

2. If Thrmin AvgQLen Thrmax

a) increment count count 1

b) calculate the drop probability for this packet using equation

(5.6)

c) decide if to drop the packet (Y/N) and drop it if decided YES

d) if in step c) the packet is dropped, reset count 0

3. Else if Thrmax AvgQLen

a) drop the packet and reset count 0

4. Otherwise, reset count 1

End of the for loop

Explicit Congestion Notification (ECN)

• Want: avoid dropping packets as a way of notifying the senders of congestion

• Need: avoid sending direct messages to senders because it makes congestion worse

• Solution: piggyback notifications to sender on DATA packets flowing to receiver; receiver will piggyback notifications to ACKs

ECN details: RFC 3168


Routers work only with IP (not TCP), so …• Need to modify IP header format to support [router receiver] ECN notifications• Need to modify TCP header format to support [receiver sender] ECN notifications

Router needs to notify the TCP sender of incipient congestion, so it piggybacks an ECN notification on the data packet.

The TCP receiver should send the ECN notification back to the sender, piggybacked on the ACK packet.

(congested)

Data Data + ECN for sender

TCPSender

TCP Receiver

Router i Router j

notification:

congestion!

Data + ECN for sender

ACK + ECN for senderACK + ECN for senderACK + ECN for sender

(a)


Not enough to modify the IP header format:The Sender would not know if the ECN notification is for the Sender or for the Receiver;It would not matter if both data and ACK packets travelled over the same path, because it would be relevant for both.But, packets may take different paths, so Sender must know if the ECN is for itself or Receiver.

Having two bits, one for “forward” (data) path and one for “reverse” (ACK) path would not solve the problem, because routers cannot distinguish “forward/reverse” – the distinction makes sense only to the TCP layer (not available on routers)!

Therefore, must modify TCP header format to allow the Receiver to notify the Sender

(congested)

Data Data + ECN bit set

TCPSender

TCP Receiver

Data + ECN bit set

ACK + ECN bit setACK + ECN bit set

(b)

IPv4 Header

8-bit differentiatedservices (DS)

16-bit datagram length(in bytes)

16-bit datagram identification

options (if any)

data

0 15 16 31

8-bit time to live(TTL)

16-bit header checksum

13-bit fragment offset

4-bitversionnumber

20bytes

4-bitheaderlength

32-bit destination IP address

32-bit source IP address

8-bit user protocol

unused

DF

MF

7 8

flags

Modify IP Header Format for ECN

• Need two bits:– One for the congested router to notify the Sender of an incipient

congestion– One for the Sender to notify routers that it is ECN capable

(because otherwise the router’s notification would not make difference)

• Note: If routers applied ECN regardless of whether Senders are ECN-capable, then non-ECN-capable senders get a free ride (no packets dropped when congestion, just ECN bit set!) and would not have incentive to upgrade to ECN– So, apply RED to packets from non-ECN-capable senders

6-bit diff.services

16-bit datagram length(in bytes)

16-bit datagram identification

0 15 16 31

13-bit fragment offset

4-bitversionnumber

4-bitheaderlength

unused

DF

MF

7 8

flags

ECT

CE

IPv4 Packet Header + ECN Field

14 15 ECT CE 0 0 = Not-ECT 0 1 = ECT(1) 1 0 = ECT(0) 1 1 = CE, cong. experienced

ECT

CE

ECN Field

(a)

Detecting a Misbehaving Node

Sender can alternate between the ECT(0) / ECT(1) codepoints to discover if a misbehaving node (another router or Receiver) is erasing the CE codepoint.The misbehaving node would not be repeatedly able to correctly reconstruct the Sender’s ECT dodepoint.More likely, repeated erasure of the CE codepoint would be soon discovered by the Sender.

() But then how can the congested router notify the Receiver about the congestion?-- The router cannot distinguish between “Sender” and “Receiver”– for it all IP packets are just IP packets!?Note that RFC 3168 does not say that misbehaving node detection is based on a simple reflection of ECT() codepoints by the Receiver. Instead, it only says: “The ECN nonce allows the development of mechanisms for the sender to probabilistically verify that network elements are not erasing the CE codepoint…”

(congested)

Data, ECT(1)

Misbehavingnode

Data, CE Data, ECT(0)

ACK, ECT(0)ACK, ECT(0) ACK, ECT(0)

TCPSender

TCPReceiver

Discover mis-

behavior

()

TCP Header

16-bit source port number 16-bit destination port number

32-bit sequence number

flags

options (if any)

TCP segment data (if any)

0 15 16 31

16-bit TCP checksum 16-bit urgent data pointer

16-bit advertised receive window size4-bit

headerlength

unused(6 bits)

URG

ACK

PSH

RST

SYN

FIN

20bytes

32-bitacknowledgement number

TC

P p

ayl

oad

TC

P h

eade

r

16-bit source port number 16-bit destination port number

32-bit sequence number

flags

0 15 16 31

16-bit advertised receive window size4-bit

headerlength

reserved(4 bits)

URG

ACK

PSH

RST

SYN

FIN

32-bitacknowledgement number

CWR

ECE

Modify TCP Header

8 9

CWR

CWR = Sender informs Receiver that CongWin reduced

ECE

ECE = ECN echo, Receiver informs Sender when CE received

(b)


An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets.

An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet.

The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender.

The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped.

The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.

3

1

2

4

5

(congested)

Data, ECT(1) Data, CE Data, CE

ACK, ECEACK, CE, ECE ACK, ECE

TCPSender

TCPReceiver

congestionnotification

for Receiver ()

congestion notificationfor Sender

ECN-Echo for Sender

1 2

34 5

() The congested router cannot notify the Receiver about the congestion using “pure” ACK packets, because they must use codepoint “00,” indicates a not-ECT-capable source

Topic:Multiprotocol Label Switching

(MPLS)

Constraint-based routing

Traffic engineering

Virtual private networks (VPNs)

MPLS Operation: Supporting Tunnels

Egress LSR(or, exit)MPLS domain

B

C

D

G

LSR = Label switching routerFEC = Forwarding equivalence classLSP = Label switched pathLFIB = Label forwarding information base

MPLS label

Link-layer hdr

IP header

IP payload

LFIB H

F

E

Ingress (or, entry) LSR

of a tunnel denoted by LSP

Flow of IPdatagrams(denoted

by FEC)

A

Egress LSR(or, exit)MPLS domain

B

C

D

G

LSR = Label switching routerFEC = Forwarding equivalence classLSP = Label switched pathLFIB = Label forwarding information base

MPLS label

Link-layer hdr

IP header

IP payload

LFIB H

F

E

Ingress (or, entry) LSR

of a tunnel denoted by LSP

Flow of IPdatagrams(denoted

by FEC)

A

How Is MPLS Switching Different From IP Forwarding?

• MPLS labels are simple integer numbers– IP addresses are hierarchically structured (dotted

decimal notation)

• Matching MPLS labels is simpler because they are fixed length; can be directly indexed into an array– IP network prefixes are variable length; require search

for a longest match

• MPLS switching table needs to have entries only for the adjacent routers– IP forwarding table needs to have entries for all

network prefixes in the world!

Label Switched Path

packets belongingto the same FEC

LSP (Label Switched Path = tunnel)

segment 1

label = 5

segment 2

label = 17segment 3

label = 6

ONE WAYONE WAY

(Forwarding Equivalence Class)ENTER

EXIT

MPLS Protocol Layering

Network/IP layer –Forwardingplane

Data plane

Network/IP layer –Forwardingplane

Data plane

Link layer plane(Network’s physicaltopology)

LSREdgeLSR

LSR

EdgeLSR

EdgeLSR

A

B C

D

EF

G


LSREdgeLSREdgeLSR

LSRLSR

EdgeLSREdgeLSR

EdgeLSREdgeLSR

A

B C

D

EF

G

MPLS layer plane

MPLS domain

LSP 1

LSP 2

LSP 3

LSP = Label switched pathLSR = Label switching router

ONE WAY

MPLS layer plane

MPLS domain

LSP 1

LSP 2

LSP 3

LSP = Label switched pathLSR = Label switching router

ONE WAYONE WAY

Network/IP layer –Routing plane LSR

EdgeLSR

EdgeLSR

EdgeLSR

Control plane

Network/IP layer –Routing plane LSRLSR

EdgeLSREdgeLSR

EdgeLSREdgeLSR

EdgeLSREdgeLSR

Control planeNetworklayer

Link layer

MPLS layer

Network layer

Link layer

MPLS layer

Network layer

MPLS Label Format

Link layer

MPLS layer

Network layer

Link layer

MPLS layer

Network layer

Link-layerheader

MPLSlabel

Network-layerheader

Payload

Label value Exp S TTL

bits: 20 3 1 8

32 bits (4 bytes)

MPLS Label Format

Link layer

MPLS layer

Network layer

Labe

lT

TL

Labe

lT

TL

Labe

lT

TL

Link-layerheader

IPheader

IPpayload

Label stack

Top label(S=0)

Bottom label(S=1)

Intermediate label(S=0)

Label informationbase (LIB)

Routing table

Fro

m

To

IP forwarding table

Destin. prefix Out port

Label forwarding information base (LFIB)

Dest. prefix In label Out label Out port

(from peer LSRs)

(not used in MPLS,except by edge LSRs)

(from routing protocols)

Label Bindings, LIB, and LFIB

LSR

LSP path setup & Label binding

In label Out label Out port


LFIB(C)

Dest. Prefix Out label Out port

96.1.1.13

EdgeLSR

LSR EdgeLSR

A B D HC96.1.1.13

4 2 5 1 3

Label req.96.1.1/24

Label req.96.1.1/24

EdgeLSR

LSR EdgeLSR

A B D H

Network96.1.1/24


C96.1.1.13

LFIB(B) LFIB(D)

4 2 5 1 3

EdgeLSR

LSR EdgeLSR

A B D H

Network96.1.1/24


C96.1.1.13

LFIB(B) LFIB(D)

LFIB(C)

Port4

Port2 5 1 3

LIB binding:96.1.1/24 17

96.1.1/24

517

49

9

Pfx: 96.1.1/24Label = 17

Pfx: 96.1.1/24Label = 9

(a)

(b)

(c)


179


In label Out label Out portIn label Out label Out port

LFIB(C)

Dest. Prefix Out label Out portDest. Prefix Out label Out port

96.1.1.13

EdgeLSREdgeLSR

LSRLSR EdgeLSREdgeLSR

A B D HC96.1.1.1396.1.1.13

4 2 5 1 3

Label req.96.1.1/24Label req.96.1.1/24

Label req.96.1.1/24Label req.96.1.1/24

EdgeLSREdgeLSR


A B D H

Network96.1.1/24


C96.1.1.1396.1.1.13

LFIB(B) LFIB(D)

4 2 5 1 3

EdgeLSREdgeLSR


A B D H

Network96.1.1/24


C96.1.1.1396.1.1.13

LFIB(B) LFIB(D)

LFIB(C)

Port4

Port2 5 1 3

LIB binding:96.1.1/24 17

96.1.1/24

517

49

9

Pfx: 96.1.1/24Label = 17

Pfx: 96.1.1/24Label = 17

Pfx: 96.1.1/24Label = 9

Pfx: 96.1.1/24Label = 9

(a)

(b)

(c)


179

Data pkt held waiting

Forwarding labeled packets


LFIB(C)

EdgeLSR

LSR EdgeLSR

A B D H

Network96.1.1/24


C

LFIB(B)

D’s IP Forwarding table

5 1 3

96.1.1/24

517

49

9

(a)

96.1.1.13 9 96.1.1.13 17

EdgeLSR

LSR EdgeLSR

A B D H

Network96.1.1/24

C

3


96.1.1/24 49


5179

(b)

96.1.1.13 96.1.1.13

Destin. Prefix Out port

96.1.1/24 3

Port4

Port2

96.1.1.13

In label Out label Out portIn label Out label Out port

LFIB(C)

EdgeLSREdgeLSR


A B D H

Network96.1.1/24


C

LFIB(B)

D’s IP Forwarding table

5 1 3

96.1.1/24

517

49

9

(a)

96.1.1.13 996.1.1.13 9 96.1.1.13 1796.1.1.13 17

EdgeLSREdgeLSR


A B D H

Network96.1.1/24

C

3


96.1.1/24 49


96.1.1/24 49


5179


5179

(b)

96.1.1.1396.1.1.13 96.1.1.1396.1.1.13


96.1.1/24 3


96.1.1/24 3

Port4

Port2

96.1.1.13

LSP Topologies


A

MPLS layer plane

LSP-1: H G E F

B

C

DE H

G JI

F

LSP-1

LSP-2MPLS domain

LSP-2: AB C

D E G J

LSP-2: AB C

D E G J

LSR Control Plane

Network-layerrouting protocols

(e.g., OSPF, BGP, PIM)

Procedures for binding FECs to labels

Label-binding distribution protocol

Maintenance of LFIB (label forwarding information base)

FECFEC--toto--nextnext--hop hop mappingmapping

FECFEC--toto--labellabelmappingmapping

Methods for Label Distribution

LSR ALSR B

Request for Binding

Label-to-FEC Binding

1

2

(a)

LSR ALSR B

Label-to-FEC Binding

(b)

Unsolicited DownstreamLabel Distribution

On-demand DownstreamLabel Distribution

User constraints: Link attributes: - Link color - Reserved bandwidth

LSP attributes: - Link color - Bandwidth - Explicit route - Hop limitations - Admin weight / Priority

CSPF Computations

Extended Link State Routing Protocol

Constrained Shortest Path First (CSPF) Computation

Routing table

Traffic Engineering

Database (TED)(shared by all routers in TE

domain)

RSVP-TE Signaling for LSP setup

Explicit Route Object (ERO)

The computation of explicit routes (known as Explicit Route Objects or EROs) is done using a distributed Traffic Engineering Database (TED). The TED database contains all IP addresses, links and current bandwidth reservation states.

TED

CE = customer edge routerPE = provider edge router

How CSPF Works

• Instead of just a single cost for a link between two neighbors, there's also:– Bandwidth– Link attributes– Administrative weight

CSPF: Example

Without taking bandwidth into account, Router A's best path to Router D is A C B D, with a total cost of 3.

7100 Mbps

1150 Mbps

140 Mbps

C

A

B

D

150 Mbps

cost=10bandwidth=100 Mbps

Constraint: minimum path bandwidth of 90 Mbps

Need path A D

Build A’s routing table using CSPF

Step Confirmed path set Tentative set Comments

0 (A, 0, , N/A) Initially, A is the only member of Confirmed(A),

with a distance of 0, a next hop of self, and the

bandwidth set to Not/Available.

1 (A, 0, , N/A) (B, 10, B, 100) Put A’s neighbors in the Tentative(A) set. Note

that (C, 1, C, 50) was not added to Tentative

because it does not meet the minimum bandwidth

requirement.

2 (A, 0, , N/A),

(B, 10, B, 100)

(D, 11, B, 100) Move B to the Confirmed set, and put B’s

neighbors in the Tentative set. Again, (C, 11, B,

40) was not added to Tentative because it does

not meet the minimum bandwidth requirement.

3 (A, 0, , N/A),

(B, 10, B, 100),

(D, 11, B, 100)

Move D to the Confirmed set. At this point, the

tunnel endpoint (D) is in Confirmed, so we are

done. END.

Tiebreakers in CSPF

Tiebreakers between paths, in order:

1. Take the path with the largest minimum available bandwidth.

2. If there is still a tie, take the path with the lowest hop count (the number of routers in the path).

3. If there is still a tie, take one path at random.

CSPF: Example

1100 Mbps

cost=2 bandwidth=100 Mbps

150 Mbps

7150 Mbps

4150 Mbps

4150 Mbps

4100

1100 Mbps

490 Mbps

2150 Mbps

4100 Mbps

4150

H

A

B

F

C

D E

G

I

Constraint: minimum path bandwidth of 80 Mbps

Need path A F

Tiebreakers in CSPF

Tiebreakers between paths, in order:

1. Take the path with the largest minimum available bandwidth.

2. If there is still a tie, take the path with the lowest hop count (the number of routers in the path).

3. If there is still a tie, take one path at random.

Possible Paths from A to F

Path name Routers in path Path length Minimum bandwidth on path (in Mbps)

P1 ABCF 274=13 Min{100, 150, 150} = 100

P2 ADEF 214=7 Min{150, 50, 150} = 50

P3 ADGHF 2114=8 Min{150, 100, 100, 100} = 100

P4 AHF 44=8 Min{90, 100} = 90

P5 AHGDEF41114=1

1Min{150, 100, 100, 50, 150} = 50

P6 AIF 44=8 Min{100, 150} = 100

1100 Mbps

cost=2 bandwidth=100 Mbps

150 Mbps

7150 Mbps

4150 Mbps

4150 Mbps

4100

1100 Mbps

490 Mbps

2150 Mbps

4100 Mbps

4150

H

A

B

F

C

D E

G

I

Apply tiebreakers to select best path

User constraints: Link attributes: - Link color - Reserved bandwidth

LSP attributes: - Link color - Bandwidth - Explicit route - Hop limitations - Admin weight / Priority

CSPF Computations

Extended Link State Routing Protocol

Constrained Shortest Path First (CSPF) Computation

Routing table

Traffic Engineering

Database (TED)(shared by all routers in TE

domain)

RSVP-TE Signaling for LSP setup

Explicit Route Object (ERO)

The computation of explicit routes (known as Explicit Route Objects or EROs) is done using a distributed Traffic Engineering Database (TED). The TED database contains all IP addresses, links and current bandwidth reservation states.

TED

MPLS / DS-TE

IP Network 1w/ DiffServ

IP Network 2w/ DiffServ

MPLS Domainw/ DiffServ TE

LSRLSR

LSRLSR

EgressLSR

EgressLSR

Incoming port(from IP network)

Outgoing port(to MPLS network)

IP header,DiffServ field:traffic class

MPLS label,EXT field:

LSP color

IngressLSR

IngressLSR

MPLS VPN: The Problem

10.1/16

10.1/16

10.2/16

10.2/16

10.3/16

10.3/16

Provider NetworkCustomer 1

Site 1

Customer 1Site 2

Customer 1Site 3

Customer 2Site 3

Customer 2Site 1

Customer 2Site 2

MPLS VPN: The Model

10.1/16

10.1/16

10.2/16

10.2/16

10.3/16

10.3/16

Customer 1Site 1

Customer 2Site 1

Customer 2Site 3

Customer 1Site 3

Customer 2Site 2

Customer 1Site 2

Customer 1Virtual Network

Customer 2Virtual Network

MPLS is used to tunnel data across a network of MPLS-enabled routers

MPLS VPN: The Solution

10.1/16

10.1/16

10.2/16

10.2/16

10.3/16

10.3/16

Customer 1Site 1

Customer 1Site 2

Customer 1Site 3

Customer 2Site 3

Customer 2Site 1

Customer 2Site 2

VRF 1

VRF 1

VRF 1

VRF 2

VRF 2

VRF 2

MPLS LSP

MPLS LSP

Documents

Computer Networks: Mechanisms for Quality of Service