SEEREN2 Summer School

Heraklion, Sept 25th

Routing Issues: QoS/CoS

Jean-Marc Uzé
Liaison Research & Education, EMEA
[email protected]

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 1

 Agenda: QoS/CoS Workshop

ƒ Module 1: Overview of QoS/CoS

ƒ Module 2: JUNOS QoS implementation (J/M/T-
Series)
ƒ Module 3: Introduction to JUNOS CLI
ƒ Module 4: GEANT2 QoS services Implementation

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 2

 What is QoS?
ƒ Methods to utilize existing network capacity efficiently
and meet performance requirements and achieve the
maximum traffic throughput

“Managed unfairness”

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 3

 To QoS or CoS?
ƒ Class of service (CoS) and quality of service (QoS) work
together to ensure transmission requirements of various
traffic types
ƒ Routers use CoS to ensure and enforce end to end
network QoS requirements

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 4

 Why network QoS?
ƒ Bandwidth isn’t free and all traffic is not equal
ƒ Migration continues toward converged network, with multiple
services over IP
ƒ Need to distinguish between the multiple services on the converged
network infrastructure
ƒ Examples: voice and real-time video
ƒ Customers will pay for better service
ƒ Packet delivery guarantees
ƒ latency and jitter guarantees
ƒ QoS can smooth out peaks to utilize existing bandwidth better

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 5

 Why router CoS?
ƒ Routers are statistical multiplexing devices (unlike
telephone switches), so can become congested
• i.e., more traffic can want to go out a link than there is
bandwidth on that link
ƒ So you need buffer memory
ƒ In a well-functioning network, buffer memory will be
empty most of the time
• Buffers are to absorb temporary bursts
ƒ Sustained congestion is unacceptable
• Is more of a capacity planning issue

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 6

 Why router CoS?
ƒ A link can have more than one transmit queue
• Need a queue servicing algorithm to arbitrate
the queues’ access to the link
ƒ So congestion can be isolated to one queue
• i.e., one class can be congested while
another is not
ƒ But even the worst class still can’t have
sustained congestion
• i.e., need careful provisioning per class

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 7

 What is CoS not!?
ƒ Bottom Line: CoS does NOT create Bandwidth

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 8

 Why deploying QoS in R&E Networks?
ƒ Bandwidth management allows you to support different
communities and usage, by offering multiple service
classes over a shared infrastructure, such as a
converged IP/MPLS network
ƒ A converged network allows you to reduce operating
expenses, to use multiple access technologies, and to
offer a wide range of integrated products, such as
Internet access, VPN access, and videoconferencing,
GRID support, etc…
ƒ Over-provisioning is not always here
ƒ Even if over-provisioning is there, you can’t avoid
punctual overload (GRID, failure in the network etc.)
ƒ It’s a business decision for you, not a technical decision

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 9

 The Old Edge

ATM
Edge
Fra
me
Rel Core
ay PE1

PE2
Ethernet
PE3

PE4

TDM
Raw

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 10

 Consolidated Multi-Service Edge
ATM
Mobile Core ERX, M & T Series
Consolidation Strategy
GE aligned around MPLS

Metro Ethernet

DS0, T1/E1, OC3, OC12

IP/MPLS
ATM/FR

ATM/FR, POS, GE

Layer 2/3 VPN ERX/M-series T-series

ATM/FR, POS, GE

VoIP
ATM Voice

Internet Access

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 11

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 12

 Definition of Network QoS Parameters
ƒ Quality-of-service parameters for networks include:
• Throughput (bandwidth)
• End-to-end data carrying capacity

• Delay (latency)
• End-to-end delay for data delivery (forwarding, queuing, propagation, serialization)

• Delay variation (jitter)

• Variation in end-to-end delays caused partly by packet queuing

• Loss
• Percentage of packets not delivered, usually related to congestion

ƒ Network QoS parameters affect and limit the user’s perception of

application performance
• Most applications are not aware of network CoS

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 13

 How does a router influence these
parameters (Delay) ?
Propagation 5ms per 1000 km over optical fiber.
delay
time difference between receiving a packet on an incoming
Switching interface and enqueuing of the packet in the scheduler of its
delay outbound interface. ~10-50 us

Serialization time taken to clock a packet onto a link, depends on link speed
delay and packet size, can’t do better than line rate. E.g. 1500 byte
packet for oc-48 = 5us
Scheduling/
Queueing time difference between enquiring the packet of the outbound
delay: interface scheduler and the start of clocking the packet onto
the outbound link.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 14

 Delay budget
ƒ Common goal to support VOIP is a delay budget of 150msec from
mouth to ear.
• Propagation delay for the widest diameter in the network could
be up to (for a national network in the US) 30msec one-way.

ƒ Common goal for business-critical interactive data applications is

one second.
• ~700 ms for server processing
• ~300 ms for network RTT.
• Good understanding of application is required for better
estimates.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 15

 Serialization Delays (in msec) by
Link Speed and Packet Size
Packet size Link Speed
in bytes

DS-1 DS-3 OC-3 OC-12 OC-48 OC-192

40 0.2073 0.0072 0.0021 0.0005 0.0001 0.0000

256 1.3264 0.0458 0.0132 0.0033 0.0008 0.0002

320 1.6580 0.0572 0.0165 0.0041 0.0010 0.0003

512 2.6528 0.0916 0.0264 0.0066 0.0016 0.0004

1500 7.7720 0.2682 0.0774 0.0193 0.0048 0.0012

4470 23.1606 0.7994 0.2307 0.0575 0.0144 0.0036

9180 47.5648 1.6416 0.4738 0.1181 0.0295 0.0074

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 16

 Delay calculation
ƒ This is mostly the operators hard homework…
ƒ Example 1500 byte packet take ~6ms to put out on E1 speed wire…
1500 byte out on STM1 speed take ~0.08ms. But 1500 byte take
~190ms to put out to the wire on 64kbps ds0. The speed of light take
~70ms over the Atlantic etc… forwarding delay through M series is
~8us etc…
Forward delay
Queuing delay
Serialisation delay (COS configuration) (Lookup and ASIC)
(Link bandwidth)

Propagation delay
(Distance)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 17

 How does a router influence these
parameters (Jitter) ?
ƒ Jitter is the variation in delay over time

ƒ The primary contributor to jitter is the variability of

queuing/scheduling delay over time

ƒ Conclusion: Jitter matters more on slower links, and

bigger packets hurt most

ƒ Typical jitter budget for backbone is 5 to 10 msec.

assuming 10 backbone hops, it is a jitter budget of 500 to
1000 us per hop.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 18

 A visual on the source of jitter
ƒ Best-effort queue starts being
Time “t”: 1st VOIP is serviced
serviced right before a VoIP
packet arrives Best effort

VoIP

• VoIP packet has to wait for Time “t+x”: Best effort is serviced
and VOIP just arrives
best-effort packet to be
Service
serviced Best effort

VoIP Arrive

• Wait time depends on size Time “t+x+y”: VOIP is serviced after

of best-effort packet Best effort.
Best effort

VoIP
ƒ This happens hop-by-hop Service

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 19

 How does a router influence these
parameters (Loss)?
ƒ Packets can be lost in two primary ways
• Congestion – a packet wants to go out a certain port but the
associated transmit queue is 100% full
• Errors – a packet gets corrupted such that some hop in the path
needs to drop the packet
ƒ In practice for TCP, packet loss almost always means congestion
• equilibrium of maximum bandwidth without congestion; multiple
TCPs doing this in parallel results in fair allocation of bottleneck
bandwidth
ƒ A loss of 2 consecutive 20ms samples of voice is perceptible
degradation

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 20

 How does a router influence these
parameters (Loss)? contd.
ƒ Throughput commitments between ingress/egress port pairs is way
easier to offer than from an ingress port to “anywhere”
• Specifically, ensure the “committed” traffic has
adequate allocated bandwidth along the path
ƒ What to do with traffic sent along that path above the agreed-upon
rate is a policy question
• Drop it on ingress (to the network cloud) using a
policer
• Pass it on with increased drop probability
• Buffer and “shape” it on ingress

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 21

 How does a router influence these
parameters (Throughput)?
ƒ Routers affect throughput by allocating different bandwidth, buffer
sizes and scheduling/drop priorities to different traffic classes
ƒ In best-effort routers don’t actively do anything
• Assume that TCP detects/reacts to loss in a way that results in
fairness
ƒ Several ways of provisioning throughput to traffic classes
• E.g., strict priority of one class over others
• E.g., prioritize one class, but cap it to prevent starvation
• E.g., equal prioritization but different bandwidths
• Hybrids of the above
• All of the above require that routers have multiple queues

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 22

 Traffic flow Disharmony
ƒ What isn’t queue management? =>FIFO/Tail drop.
ƒ Example bandwidth mismatch problem from Intra AS
peers to Exchange points or Core towards edge.

STM-1
STM-64

“Bit bucket”
Packet drop

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 23

 TCP the major flow
ƒ A TCP sender reacts to a lost packet by slowing its
sending rate (packet loss indicates congestion)
ƒ If waiting until a queue is full and then doing 100% tail
drop -> causes lots of TCP senders to slow down -
>Global synchronization
ƒ After everyone slows down the link is underutilized -
>The same link that “should be” 100% filled
ƒ However…this theory is based upon close interaction
TCP==Application, not necessary the whole truth…

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 24

 Random Early Detection
ƒ Rather than wait for total congestion and then tail drop at
100%, how about notice congestion and react with
dropping randomly?
ƒ Prevents total congestion because some people slow
down
ƒ Prevents global synchronization
ƒ Keeps utilization at ~100% because no taildrops and
synchronization problems. But that’s the theory…
ƒ RED scheme efficiency depends upon application.
Essentially session have to be long lived, or that RED is
flow aware and not just packet aware…

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 25

 TCP, Slow start function
If loss/RTT timeout
sender half datagram and size

Slow start, Multiple/massive TCP drops

probe of connection and resulting duplicated ACK’s from receiver
force TCP Slowstart

Sender Receiver

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 26

 TCP flow control 1
ƒ TCP and application interaction in practise, long
lived session FTP !
ƒ RED is very efficient !
24 6.539281 192.168.1.100 -> 1.1.1.11 FTP Response: 150 Opening BINARY mode data connection for 'x' (14095132 bytes).
25 6.539676 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
26 6.633393 1.1.1.11 -> 192.168.1.100 TCP 4983 > 21 [ACK] Seq=1270128481 Ack=2726329842 Win=17376 Len=0
27 6.633438 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467594828 Win=17376 Len=0
28 6.633813 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
29 6.633998 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
30 6.637189 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467597724 Win=17376 Len=0
31 6.637518 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
32 6.637690 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
33 6.637862 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
34 6.641390 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467600620 Win=17376 Len=0
[…]

57 6.661649 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes

58 6.661828 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
59 6.662000 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
60 6.662280 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
61 6.662439 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
62 6.662591 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
63 6.662860 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
64 6.663044 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes
65 6.663122 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467623788 Win=17376 Len=0
[…]

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 27

 TCP flow control 2
ƒ HTTP… where is the long lived session ?
ƒ RED ? To be efficient its more multiple levels of
taildrop…
158 33.614381 192.168.0.200 -> 207.17.137.68 HTTP GET /solutions/literature/app_note/350005.pdf HTTP/1.1
159 33.848019 207.17.137.68 -> 192.168.0.200 TCP http > 1297 [ACK] Seq=2713032788 Ack=576311475 Win=24616 Len=0
160 33.876638 207.17.137.68 -> 192.168.0.200 HTTP HTTP/1.1 200 OK
161 33.969018 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713033035 Win=17376 Len=0
162 34.200987 207.17.137.68 -> 192.168.0.200 HTTP Continuation
163 34.224733 207.17.137.68 -> 192.168.0.200 HTTP Continuation
164 34.224918 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=14480 Len=0
165 34.229408 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=17376 Len=0
166 34.459063 207.17.137.68 -> 192.168.0.200 HTTP Continuation
167 34.482887 207.17.137.68 -> 192.168.0.200 HTTP Continuation
168 34.483069 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713037379 Win=17376 Len=0
169 34.507076 207.17.137.68 -> 192.168.0.200 HTTP Continuation
170 34.507252 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=14480 Len=0
171 34.519431 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=17376 Len=0
172 34.707686 207.17.137.68 -> 192.168.0.200 HTTP Continuation
173 34.732468 207.17.137.68 -> 192.168.0.200 HTTP Continuation
174 34.732639 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713042675 Win=15928 Len=0
175 34.756276 207.17.137.68 -> 192.168.0.200 HTTP Continuation
176 34.779185 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713044123 Win=17376 Len=0
177 34.780125 207.17.137.68 -> 192.168.0.200 HTTP Continuation
178 34.804460 207.17.137.68 -> 192.168.0.200 HTTP Continuation
179 34.804618 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=14480 Len=0
180 34.809485 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=17376 Len=0
Copyright © 2006 Juniper Networks, Inc. www.juniper.net 28
[…]
 UDP
Dataforward

Sender Receiver

Applications ACK...maybe

ƒ UDP guarantee nothing, no response to taildrops or

Random drops (RED) from endhost. But hard contracts
can impact missbehaved UDP. Policing most effective !
ƒ Small overhead. Stateless, easy to re-route
ƒ No segment control, best effort.
ƒ Application responsable for control, timestamp ex with
RTP header or application ACK’s

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 29

 TFTP,
Example of old UDP implementation
ƒ Application ACK for each 516 byte
datasegment…
emilie# tcpdump -i fxp1
tcpdump: listening on fxp1
13:09:48.040923 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.042117 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
13:09:48.042512 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.043619 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
13:09:48.044046 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.045151 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
13:09:48.045547 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.046654 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
13:09:48.047044 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.048155 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
13:09:48.048548 192.168.1.100.2134 > 1.1.1.11.2472: udp 516
13:09:48.049666 1.1.1.11.2472 > 192.168.1.100.2134: udp 4
[…]

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 30

 Realtime 1
Multicast/RTP header
ƒ Perhaps not delay sensitive (End-station playback
buffering) but loss sensitive and can be bursty.

166 [172.16.2.60] [239.239.239.119] 1494 0:00:29.242 0.007.079 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30316,T=317895538,SSRC=2233125814
167 [172.16.2.60] [239.239.239.119] 1494 0:00:29.247 0.005.675 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30317,T=317895538,SSRC=2233125814
168 [172.16.2.60] [239.239.239.119] 1494 0:00:29.253 0.006.041 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30318,T=317895538,SSRC=2233125814
169 [172.16.2.60] [239.239.239.119] 1494 0:00:29.259 0.006.023 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30319,T=317895538,SSRC=2233125814
170 [172.16.2.60] [239.239.239.119] 1494 0:00:29.265 0.006.040 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30320,T=317895538,SSRC=2233125814
171 [172.16.2.60] [239.239.239.119] 1494 0:00:29.271 0.006.061 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30321,T=317895538,SSRC=2233125814
172 [172.16.2.60] [239.239.239.119] 1494 0:00:29.277 0.006.025 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30322,T=317895538,SSRC=2233125814
173 [172.16.2.60] [239.239.239.119] 1494 0:00:29.283 0.006.031 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30323,T=317895538,SSRC=2233125814
174 [172.16.2.60] [239.239.239.119] 1494 0:00:29.290 0.006.036 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30324,T=317895538,SSRC=2233125814
[…]

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 31

 Realtime 2
VOIP or Voice trunking
ƒ Has requirements for delay and jitter (variation in
delay)
ƒ Assumes careful provisioning of the realtime traffic -
>over-provisioning that service/queue can result in
wider jitter !

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 32

 VoIP…
Frame Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summa
7 [192.168.1.2] [1.1.1.1] 60 0:00:13.608 3.607.930 2000-06-07 15:11:40 TCP: D=1720 S=11018 SYN SEQ=502840112 LEN=0 WIN=4128
8 [1.1.1.1] [192.168.1.2] 60 0:00:13.610 0.001.196 2000-06-07 15:11:40 TCP: D=11018 S=1720 SYN ACK=502840113 SEQ=449596568 LEN=0 WIN=4128
9 [192.168.1.2] [1.1.1.1] 60 0:00:13.612 0.002.361 2000-06-07 15:11:40 TCP: D=1720 S=11018 ACK=449596569 WIN=4128
10 [192.168.1.2] [1.1.1.1] 117 0:00:13.623 0.010.694 2000-06-07 15:11:40 H225USR: type=Setup userid=126 length=38
11 [1.1.1.1] [192.168.1.2] 115 0:00:13.632 0.009.512 2000-06-07 15:11:40 H225USR: type=Alerting userid=126 length=42
12 [192.168.1.2] [192.168.1.1] 60 0:00:13.641 0.008.246 2000-06-07 15:11:40 TCP: D=11017 S=11019 SYN SEQ=502875512 LEN=0 WIN=4128
13 [192.168.1.1] [192.168.1.2] 60 0:00:13.642 0.001.215 2000-06-07 15:11:40 TCP: D=11019 S=11017 SYN ACK=502875513 SEQ=449628639 LEN=0 WIN=4128
14 [192.168.1.2] [192.168.1.1] 60 0:00:13.648 0.005.918 2000-06-07 15:11:40 TCP: D=11017 S=11019 ACK=449628640 WIN=4128
15 [192.168.1.1] [192.168.1.2] 60 0:00:13.652 0.004.748 2000-06-07 15:11:40 TCP: D=11019 S=11017 ACK=502875513 SEQ=449628640 LEN=4 WIN=4128
16 [192.168.1.2] [192.168.1.1] 60 0:00:13.658 0.005.942 2000-06-07 15:11:40 TCP: D=11017 S=11019 ACK=449628640 SEQ=502875513 LEN=4 WIN=4128
17 [192.168.1.2] [1.1.1.1] 60 0:00:13.836 0.177.682 2000-06-07 15:11:40 TCP: D=1720 S=11018 ACK=449596630 WIN=4067
18 [192.168.1.1] [192.168.1.2] 60 0:00:13.857 0.020.896 2000-06-07 15:11:40 TCP: D=11019 S=11017 ACK=502875517 WIN=4124
19 [192.168.1.2] [192.168.1.1] 103 0:00:13.861 0.004.032 2000-06-07 15:11:40 H245: Type=Request, Terminal Capability Set
20 [192.168.1.1] [192.168.1.2] 161 0:00:13.862 0.001.097 2000-06-07 15:11:40 H245: Type=Request, Terminal Capability Set
21 [192.168.1.2] [192.168.1.1] 60 0:00:13.882 0.020.283 2000-06-07 15:11:40 TCP: D=11017 S=11019 ACK=449628751 SEQ=502875566 LEN=4 WIN=4017
22 [192.168.1.1] [192.168.1.2] 67 0:00:13.883 0.001.084 2000-06-07 15:11:40 H245: Type=Request, Open Logical Channel
23 [192.168.1.2] [192.168.1.1] 63 0:00:13.889 0.006.040 2000-06-07 15:11:40 H245: Type=Response, Terminal Capability Set Ack Function Not Understood
24 [192.168.1.1] [192.168.1.2] 60 0:00:13.893 0.003.321 2000-06-07 15:11:40 TCP: D=11019 S=11017 ACK=502875579 SEQ=449628764 LEN=4 WIN=4062
25 [192.168.1.2] [192.168.1.1] 77 0:00:13.907 0.014.486 2000-06-07 15:11:40 H245: Type=Request, Open Logical Channel
26 [192.168.1.1] [192.168.1.2] 73 0:00:13.908 0.001.066 2000-06-07 15:11:40 H245: Type=Request, Conference Request
27 [192.168.1.2] [192.168.1.1] 60 0:00:13.921 0.013.157 2000-06-07 15:11:41 TCP: D=11017 S=11019 ACK=449628787 SEQ=502875602 LEN=4 WIN=3981
28 [192.168.1.1] [192.168.1.2] 85 0:00:13.923 0.001.130 2000-06-07 15:11:41 H245: Type=Response, Open Logical Channel Ack
29 [192.168.1.2] [192.168.1.1] 77 0:00:13.925 0.002.460 2000-06-07 15:11:41 H245: Type=Response, Open Logical Channel Ack
30 [192.168.1.1] [192.168.1.2] 214 0:00:13.946 0.021.002 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12046,T=2045780809,SSRC=367853825
31 [192.168.1.1] [192.168.1.2] 214 0:00:13.965 0.019.385 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12047,T=2045780969,SSRC=367853825
32 [192.168.1.1] [192.168.1.2] 214 0:00:13.985 0.019.964 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12048,T=2045781129,SSRC=367853825
33 [192.168.1.1] [192.168.1.2] 214 0:00:14.005 0.020.006 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12049,T=2045781289,SSRC=367853825
34 [192.168.1.1] [192.168.1.2] 214 0:00:14.025 0.020.007 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12050,T=2045781449,SSRC=367853825
35 [192.168.1.1] [192.168.1.2] 214 0:00:14.045 0.020.018 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12051,T=2045781609,SSRC=367853825
36 [192.168.1.1] [192.168.1.2] 214 0:00:14.066 0.020.910 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12052,T=2045781769,SSRC=367853825
37 [192.168.1.1] [192.168.1.2] 214 0:00:14.085 0.019.092 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12053,T=2045781929,SSRC=367853825
38 [192.168.1.1] [192.168.1.2] 214 0:00:14.105 0.020.025 2000-06-07 15:11:41 RTP: PT=PCMA,SEQ=12054,T=2045782089,SSRC=367853825
39 [192.168.1.1] [192.168.1.2] 60 0:00:14.125 0.019.525 2000-06-07 15:11:41 TCP: D=11019 S=11017 ACK=502875629 WIN=4012

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 33

 Mobile Networks
UMTS
Infrastructure
IP Infrastructure

RNC MSC/VLR
UMTS Terrestrial Corporate / VPN’s
Radio Access
Network
UTRAN

HLR
BTS SGSN

Internet

GGSN
Backbone

MS

GW ISP Service
PSTN,ISDN PLMN Co-location

The important note for IP freaks,

It’s transported over packet based IP networks !

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 34

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 35

 RFC 791…TOS field
Bits 0-2: Precedence.
ƒ RFC 791 (circa Bit
Bits
3: 0 = Normal Delay, 1 = Low Delay.
4: 0 = Normal Throughput, 1 = High Throughput.
1981) defined the Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
type-of-service
0 1 2 3 4 5 6 7
field in the IP +-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
header: | PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
• 3-bit +-----+-----+-----+-----+-----+-----+-----+-----+

precedence Precedence

field to prioritize 111

110
-
-
Network Control
Internetwork Control
discards 101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 36

 IP precedence / 802.1p
DLC: ----- DLC Header -----
DLC: Frame 4 arrived at 23:07:49.0045; frame size is 759 (02F7 hex) bytes.
DLC: Destination = Multicast 01005E020168
DLC: Source = Station 0030962EB724
8021Q: ----- 802.1Q Packet -----
8021Q: Tag Protocol Type = 8100
8021Q: Tag Control Information = 8002
8021Q: User Priority = 4
8021Q: Tunnel Type = 0 (Ethernet frame)
8021Q: VLAN ID = 2
8021Q: Ethertype = 0800 (IP)
IP: ----- IP Header -----
IP: Version = 4, header length = 20 bytes
IP: Type of service = 80
IP: 100. .... = flash override
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 741 bytes
IP: Identification = 17077
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 14 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 5C84 (correct)
IP: Source address = [192.168.1.100]
IP: Destination address = [224.2.1.104]
IP: No options
UDP: ----- UDP Header -----

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 37

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 38

 IntServ (circa 1994)
ƒ The IETF’s first attempt at extending IP for other than
best-effort services
• Host based RSVP signaling used to describe specific QoS
requirements to the network
• Routers reserve resources and do packet-by-packet classification
to match packets to the appropriate resources

• RSVP function is basic in “turnaround” order. The sender

initialize path request, but it´s the receiver who do the
reservation. The reservation is hop per hop.

RSVP Path Message from

Sender (H323 terminal)

VoIP
node PSTN

VoIP
RSVP Reservation from Gateway
Host Receiver (H-323 Gateway)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 39

 From IntServ to… RSVP
ƒ Router to router this works fine and with limited number of sessions.
With several routers in chain with host-route reservations FF (Fixed
Filter)…and if re-routing occur, the reservation falls for all FF
reservations -> massive re-signaling.
ƒ Everyone learned a lot, but IntServ was never deployed
• Scalability of both the control and data planes considered
poor

ƒ But RSVP becomes successful with MPLS

• RSVP signaling is used to put up Traffic-Engineer LSP instead
with success (aggregated traffic)
• See later…

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 40

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 41

 DiffServ Emerges
ƒ DiffServ architecture defined in RFCs 2474/2475 (circa 1998)
• Same approach as the precedence bits – but more classes and
levels (AF PHB) and definitions of service (EF PHB)
• Precedence-DSCP interopable based on class stucture…the
droplevels however can cause problem
• Redefined the IPv4 ToS field to support a 6-bit DiffServ code point
• DiffServ has no signaling component
• DiffServ deals only with aggregate flows
MSB LSB

IP ToS
RFC 791 IP Precedence D T R Reserved

0 1 2 3 4 5 6 7
DiffServ
DiffServ Code Point Reserved
RFC 2474

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 42

 DiffServ Terminology

ƒ Key DiffServ terms:

• Behavior aggregate (BA): Classification based on
DSCP
• Packets with a common DSCP belong to the same BA
• DiffServ (DS) field: The original IPv4 ToS byte
• DiffServ code points (DSCPs) occupy the 6 most significant
bits of the DS field
• Per-hop behavior (PHB): The per-hop forwarding
treatment associated with a given BA

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 43

 DiffServ Model
• Applications or edge devices classify and mark packets with
appropriate Diff-Serv code point values (DSCP)
• Edge devices make admission control (i.e. CAC) to maintain the
QoS for each class and prevent network overload
• Edge devices use classifiers or DSCP to select PHB which is to
be experienced by each packet it forwards
• Core devices use DSCP to select PHB which is to be
experienced by each packet it forwards
• DSCP and Multi-Field Classifiers are based on policies defined
according to SLA
Classification (MF) Classification (BA) Classification (BA) Classification (BA)
Scheduling Scheduling Scheduling Scheduling
Policing Policing Policing Policing
Marking Marking/Rewrite Marking/Rewrite

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 44

 RFC 2597 (AF PHB)
RFC 2597 Assured Forwarding PHB Group June 1999

Recommended codepoints for the four general use AF classes are given
below. These codepoints do not overlap with any other general use PHB
groups.

The RECOMMENDED values of the AF codepoints are as follows: AF11 = '

001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = '
010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = '
011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The
table below summarizes the recommended AF codepoint values.

Class 1 Class 2 Class 3 Class 4

+----------+----------+----------+----------+
Low Drop Prec | 00101
010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 00110
100 | 010100 | 011100 | 100100 |
High Drop Prec | 00111
110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 45

 RFC 2598 (EF PHB)
RFC 2598 An Expedited Forwarding PHB June 1999

1. Introduction

The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-
end service through DS domains.

Loss, latency and jitter are all due to the queues traffic experiences while transiting the
network. Therefore providing low loss, latency and jitter for some traffic aggregate means
ensuring that the aggregate sees no (or very small) queues. Queues arise when (short-term)
traffic arrival rate exceeds departure rate at some node.Thus a service that ensures no queues
for some aggregate is equivalent to bounding rates such that, at every transit node, the
aggregate's maximum arrival rate is less than that aggregate's minimum departure rate.

Creating such a service has two parts:

1) Configuring nodes so that the aggregate has a well-defined

minimum departure rate. ("Well-defined" means independent of
the dynamic state of the node. In particular, independent of
the intensity of other traffic at the node.)

2) Conditioning the aggregate (via policing and shaping) so that

its arrival rate at any node is always less than that node's
configured minimum departure rate.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 46

 RFC 2598 (EF PHB)…
2. Description of EF per-hop behavior

The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the
departure rate of the aggregate's packets from any diffserv node must equal or exceed a
configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any
other traffic attempting to transit the node. It SHOULD average at least the configured rate
when measured over any time interval equal to or longer than the time it takes to send an
output link MTU sized packet at the configured rate.

2.2 Example Mechanisms to Implement the EF PHB

Several types of queue scheduling mechanisms may be employed to deliver the forwarding behavior
and thus implement the EF PHB.

1) A simple priority queue [PQ] will give the appropriate behavior as long as there is no
higher priority queue that could preempt the EF for more than a packet time at the configured
rate.(This could be accomplished by having a rate policer such as a token bucket associated
with each priority queue to bound how much the queue can starve other traffic.) Eq Priority
Queueing

2) It's also possible to use a single queue in a group of queues serviced by a weighted round
robin [WRR]scheduler where the share of the output bandwidth assigned to the EF queue is equal
to the configured rate. This could be implemented, for example, using one PHB of a Class
Selector Compliant set of PHBs [RFC2474].

3) Another possible implementation is a CBQ [CBQ] scheduler that gives the EF queue priority up
to the configured rate.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 47

 DSCP
Internet Protocol
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4;
ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4
(0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 60
Identification: 0x72a6
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 253
Protocol: ICMP (0x01)
Header checksum: 0x86ec (correct)
Source: 1.1.1.3 (1.1.1.3)
Destination: 192.168.1.2 (192.168.1.2)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 48

 MPLS Exp
Ethernet II
Destination: 00:02:b3:22:38:63 (00:02:b3:22:38:63)
Source: 00:02:b3:22:38:52 (00:02:b3:22:38:52)
Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
MPLS Label: Unknown (100000)
MPLS Experimental Bits: 4
MPLS Bottom Of Label Stack: 1
MPLS TTL: 255
Internet Protocol
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xa991
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0x0d92 (correct)
Source: 1.1.1.1 (1.1.1.1)
Destination: 3.3.3.3 (3.3.3.3)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 49

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 50

 Constraint-Based Routing

Egress
LSR

Ingress
LSR

User defined LSP

constraints

ƒ Online LSP path calculation

ƒ Operator configures LSP constraints at ingress LSR
• Bandwidth reservation
• Include or exclude a specific link(s)
• Include specific node traversal(s)
ƒ Network actively participates in selecting an LSP path
that meets the constraints

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 51

 Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSR

Extended IGP

Traffic engineering Constrained User

Routing table
Database (TED) Shortest Path First Constraints

1) Store information from IGP flooding

2) Store traffic engineering information
Explicit route
3) Examine user defined constraints
4) Calculate the physical path for the LSP
5) Represent path as an explicit route
RSVP signaling
6) Pass ERO to RSVP for signaling

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 52

 Constraint-Based Routing: RSVP Signaling

CSPF

ERO Egress
PATH LSR

RSVP RESV

Ingress
LSR

ƒ Explicit route calculated by CSPF is handed to RSVP

• RSVP is unaware of how the ERO was calculated
ƒ RSVP establishes LSP
• PATH: Establish state and request label assignment
• RESV: Distribute labels & reserve resources

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 53

 Constraint Based-Routing: Example 1

Seattle

Chicago New
San York
Francisco

Kansas
City

Los Atlanta
Angeles

label-switched-path SF_to_NY { Dallas

to New_York;
from San_Francisco;
admin-group {exclude green}
cspf}

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 54

 Constraint-Based Routing: Example 2
label-switched-path madrid_to_stockholm{
to Stockholm;
from Madrid;
admin-group {include red, green}
cspf}

Stockholm
London

Paris
Munich

Madrid Geneva

Rome

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 55

 Module 1: Overview of QoS/CoS
ƒ Introduction on CoS and QoS
ƒ QoS parameters and Impact on Protocols and
Applications
ƒ ToS
ƒ Intserv
ƒ Diffserv
ƒ MPLS Traffic Engineering
ƒ MPLS Diffserv TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 56

 When TE is not enough
ƒ Traffic engineering operates at an aggregate level across all
classes of service.

ƒ The applications that generate most revenue are usually tied to

strict SLAs, and require strict QoS (delay, jitter, loss).

ƒ Traffic engineering alone cannot solve all application

scenarios. Examples:
• Limiting the proportion of traffic on a link (for voice
services)
• Providing guaranteed bandwidth services

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 57

 Can Diffserv solve the problem?
ƒ DiffServ dictates the scheduling/queuing
behavior given to traffic at every hop, but
does not control the path the traffic is taking.

ƒ If links are congested packets will be

dropped (cannot guarantee low-loss).

ƒ If queues are long, queuing delays are long

(cannot guarantee overall-delay).

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 58

 QoS using over-provisioning
ƒ If the amount of delay-sensitive traffic is
small and the available bandwidth is plentiful
– there is nothing to do, it just works.

ƒ Problems:
• Wastes a lot of resources.
• Problematic to guarantee for failure
scenarios.
• What happens when the traffic increases?

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 59

 QoS – the requirements
ƒ If links are congested packets will be dropped ->
avoid congestion by mapping the traffic to paths that
have enough resources, both in the steady-state
case and in the failure case.

ƒ If queues are long, queuing delays are long ->

ensure that queues are short – limit the amount of
delay-sensitive traffic on a link.

ƒ In addition to DiffServ, need Traffic Engineering =>

MPLS TE

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 60

 The goal of MPLS DS-TE
ƒ Support different queuing behaviors per
DiffServ class, give different forwarding
behavior based on the class.

ƒ Do traffic engineering at a per-class level

rather than at an aggregate level.

ƒ Enforce different bandwidth constraints for

different classes of traffic.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 61

 Diffserv TE
ƒ Diffserv enables scalable network designs with
multiple classes of service
ƒ MPLS TE enables resource reservation, fault-
tolerance, and optimization of transmission
resources
ƒ Diffserv TE combines the advantages of both
ƒ Result is the ability to give strict QoS guarantees
while optimizing the use of network resources

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 62

 Diffserv TE
ƒ E-LSPs and L-LSPs are defined as part of Diffserv (RFC
3270)
• E-LSP means that drop and scheduling behavior (per
hop behavior at each router) is determined by the
EXP bits in the MPLS header
• L-LSP means that drop and scheduling behavior (per
hop behavior at each router) is determined by the
MPLS label and EXP bits

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 63

 Diffserv-aware MPLS-TE Dimensions
ƒ There are 3 types of LSPs for Diffserv aware MPLS-TE
• Multi-class E-LSPs - An LSP with multiple classes, with each
class represented by EXP bits, is traffic engineered across the
network
• Single class E-LSPs - An LSP with a single class, with the class
represented by EXP bits, is traffic engineered across the network
• Single class L-LSPs - An LSP with a single class, with the class
represented by the label, is traffic engineered across the network
• There is often confusion among the last two

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 64

 Support for Multiclass E-LSPs

LSR
LDP/RSVP LDP/RSVP

E-LSP
AF1 AF1
EF EF

ƒ Support of EF and AF on single LSP

• EF and AF packets travel on single LSP (single label)
• Packets have different MPLS EXP values and are
placed into different queues

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 65

 Support for single class E-LSPs

EF
LSR

E-LSPs

BE

• Support of EF and AF on individual dedicated LSPs

• Example: EF and BE will each ride on separate E-LSP
• Packets have different MPLS EXP values and are placed into different queues
• Results in more LSPs in the core

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 66

 Terminology – Class-type (CT)
ƒ Class-Type (CT or traffic class): collection of traffic flows that will
be treated equivalently from a DS-TE perspective.

ƒ Maps to a queue, equivalent to the class-of-service “forwarding-

class” concept.
• CT0: Best effort
• CT1: Expedited forwarding
• CT2: Assured forwarding
• CT3: Network control

ƒ The CoS configuration determines the BW available for each CT

in JUNOS.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 67

 Terminology: TE Class
ƒ Each IGP needs to advertise the available
bandwidth per CT at each priority level on
every link
ƒ There are 8 CTs and 8 priority levels
resulting on 64 values that need to be stored
and propagated for each link
ƒ IETF decided to limit the advertisements to 8
values (from possible 64 values)
ƒ TE Class is defines as (CT, priority)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 68

 Picking Eight TE-Classes

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 69

 Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSR

Extended IGP

Traffic engineering Constrained User

Routing table
Database (TED) Shortest Path First Constraints

1) Store information from IGP flooding (BW per CT)

2) Store traffic engineering information

Explicit route
3) Examine user defined constraints (BW per CT)

4) Calculate the physical path for the LSP(s)

5) Represent path as an explicit route

RSVP signaling
6) Pass ERO to RSVP for signaling

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 70

 How is bandwidth accounted?

ƒ The IETF defined bandwidth models.

ƒ They determine the partitioning of BW

among the different CTs

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 71

 Bandwidth Models
ƒ There are 2 bandwidth models

• Maximum allocation model

(MAM) – each class is
dedicated an amount of
bandwidth and other classes
cannot take advantage of
unused bandwidth

• Russian dolls model – each

class gets an amount of
bandwidth but lower priority
classes can use the
bandwidth of higher priority
classes when that bandwidth
is available.

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 72

 Components of DS-TE
ƒ Three components:
1. Per-class traffic engineering – RSVP extensions,
IGP extensions
2. Per-class input policing at the edge – LSP
Policing
3. Per-class scheduling (one queue for all traffic of a
given class) – Diffserv

ƒ Per-class traffic engineering + policing at the edge +

dedicated queue = QoS

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 73

 What is DS-TE good for?
ƒ Guaranteed QoS for services – VoIP,
“guaranteed BW” service.

ƒ Quality-based transport of all traffic types

ƒ Emulating ATM and FR over MPLS (the

Juniper/Lucent Multiservice MPLS Core
Solution)

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 74

 Thank you
Jean-Marc Uzé
Liaison Research & Education, EMEA
[email protected]
Mobile: +33615432512
31 Place Ronde, 92986 Paris-La-Defense, France

Copyright © 2006 Juniper Networks, Inc. www.juniper.net 75