Seeren Cos Junos Module1

SEEREN2 Summer School Heraklion, Sept 25th Routing Issues: QoS/CoS
Jean-Marc Uz Liaison Research & Education, EMEA juze@juniper.net
Copyright 2006 Juniper Networks, Inc.
www.juniper.net
Agenda: QoS/CoS Workshop

Module 1: Overview of QoS/CoS Module 2: JUNOS QoS implementation (J/M/TSeries) Module 3: Introduction to JUNOS CLI Module 4: GEANT2 QoS services Implementation
www.juniper.net
What is QoS?
Methods to utilize existing network capacity efficiently and meet performance requirements and achieve the maximum traffic throughput Managed unfairness
www.juniper.net
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
www.juniper.net
Why network QoS?

Bandwidth isnt 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
www.juniper.net
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
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 cant have sustained congestion i.e., need careful provisioning per class
www.juniper.net
What is CoS not!?

Bottom Line: CoS does NOT create Bandwidth
www.juniper.net
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 cant avoid punctual overload (GRID, failure in the network etc.) Its a business decision for you, not a technical decision
The Old Edge
ATM Fra me Rel ay
Edge
PE1 PE2
Core
Ethernet
PE3 PE4
TDM Raw
www.juniper.net
10
Consolidated Multi-Service Edge

Mobile Core
ATM
GE
Metro Ethernet
ERX, M & T Series Consolidation Strategy aligned around MPLS
DS0, T1/E1, OC3, OC12
IP/MPLS
ATM/FR
ATM/FR, POS, GE
Layer 2/3 VPN
ERX/M-series ATM/FR, POS, GE
T-series
VoIP ATM Voice
Internet Access
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
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 users perception of application performance
Most applications are not aware of network CoS
www.juniper.net
13
How does a router influence these parameters (Delay) ?

Propagation delay Switching delay Serialization delay Scheduling/ Queueing delay: 5ms per 1000 km over optical fiber. time difference between receiving a packet on an incoming interface and enqueuing of the packet in the scheduler of its outbound interface. ~10-50 us time taken to clock a packet onto a link, depends on link speed and packet size, cant do better than line rate. E.g. 1500 byte packet for oc-48 = 5us time difference between enquiring the packet of the outbound interface scheduler and the start of clocking the packet onto the outbound link.
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.
www.juniper.net
15
Serialization Delays (in msec) by Link Speed and Packet Size

Packet size in bytes DS-1 40 256 320 512 1500 4470 9180 0.2073 1.3264 1.6580 2.6528 7.7720 23.1606 47.5648 DS-3 0.0072 0.0458 0.0572 0.0916 0.2682 0.7994 1.6416 Link Speed OC-3 0.0021 0.0132 0.0165 0.0264 0.0774 0.2307 0.4738 OC-12 0.0005 0.0033 0.0041 0.0066 0.0193 0.0575 0.1181 OC-48 0.0001 0.0008 0.0010 0.0016 0.0048 0.0144 0.0295 OC-192 0.0000 0.0002 0.0003 0.0004 0.0012 0.0036 0.0074
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
Serialisation delay (Link bandwidth) Forward delay Queuing delay (COS configuration) (Lookup and ASIC)
Propagation delay (Distance)
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.
www.juniper.net
18
A visual on the source of jitter

Best-effort queue starts being serviced right before a VoIP packet arrives
Time t: 1st VOIP is serviced
Best effort VoIP
VoIP packet has to wait for best-effort packet to be serviced
Time t+x: Best effort is serviced and VOIP just arrives

Best effort VoIP Arrive Service
Wait time depends on size of best-effort packet
Time t+x+y: VOIP is serviced after Best effort.

Best effort VoIP Service
This happens hop-by-hop
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
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
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 dont 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
www.juniper.net
22
Traffic flow Disharmony

What isnt queue management? =>FIFO/Tail drop. Example bandwidth mismatch problem from Intra AS peers to Exchange points or Core towards edge.
STM-64 STM-1
Packet drop
Bit bucket
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 Howeverthis theory is based upon close interaction TCP==Application, not necessary the whole truth
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 thats 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
www.juniper.net
25
TCP, Slow start function

If loss/RTT timeout sender half datagram and size Slow start, probe of connection Multiple/massive TCP drops and resulting duplicated ACKs from receiver force TCP Slowstart
Sender
Receiver
www.juniper.net
26
TCP flow control 1

TCP and application interaction in practise, long lived session FTP ! RED is very efficient !
24 25 26 27 28 29 30 31 32 33 34 [] 57 58 59 60 61 62 63 64 65 [] 6.539281 192.168.1.100 -> 1.1.1.11 FTP Response: 150 Opening BINARY mode data connection for 'x' (14095132 bytes). 6.539676 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.633393 1.1.1.11 -> 192.168.1.100 TCP 4983 > 21 [ACK] Seq=1270128481 Ack=2726329842 Win=17376 Len=0 6.633438 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467594828 Win=17376 Len=0 6.633813 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.633998 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.637189 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467597724 Win=17376 Len=0 6.637518 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.637690 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.637862 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.641390 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467600620 Win=17376 Len=0
6.661649 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.661828 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.662000 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.662280 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.662439 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.662591 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.662860 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.663044 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes 6.663122 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467623788 Win=17376 Len=0
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 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 33.614381 192.168.0.200 -> 207.17.137.68 HTTP GET /solutions/literature/app_note/350005.pdf HTTP/1.1 33.848019 207.17.137.68 -> 192.168.0.200 TCP http > 1297 [ACK] Seq=2713032788 Ack=576311475 Win=24616 Len=0 33.876638 207.17.137.68 -> 192.168.0.200 HTTP HTTP/1.1 200 OK 33.969018 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713033035 Win=17376 Len=0 34.200987 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.224733 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.224918 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=14480 Len=0 34.229408 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=17376 Len=0 34.459063 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.482887 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.483069 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713037379 Win=17376 Len=0 34.507076 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.507252 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=14480 Len=0 34.519431 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=17376 Len=0 34.707686 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.732468 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.732639 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713042675 Win=15928 Len=0 34.756276 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.779185 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713044123 Win=17376 Len=0 34.780125 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.804460 207.17.137.68 -> 192.168.0.200 HTTP Continuation 34.804618 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=14480 Len=0 34.809485 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=17376 Len=0
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 ACKs
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 []
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 167 168 169 170 171 172 173 174 [] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [172.16.2.60] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] [239.239.239.119] 1494 0:00:29.242 1494 0:00:29.247 1494 0:00:29.253 1494 0:00:29.259 1494 0:00:29.265 1494 0:00:29.271 1494 0:00:29.277 1494 0:00:29.283 1494 0:00:29.290 0.007.079 0.005.675 0.006.041 0.006.023 0.006.040 0.006.061 0.006.025 0.006.031 0.006.036 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30316,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30317,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30318,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30319,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30320,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30321,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30322,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30323,T=317895538,SSRC=2233125814 2000-04-05 12:23:26 RTP: PT=MPV video,SEQ=30324,T=317895538,SSRC=2233125814
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 !
www.juniper.net
32
VoIP
Frame 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 Source Address [192.168.1.2] [1.1.1.1] [192.168.1.2] [192.168.1.2] [1.1.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] [192.168.1.1] Dest. Address [1.1.1.1] [192.168.1.2] [1.1.1.1] [1.1.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [1.1.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.1] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] [192.168.1.2] Size Rel. Time 60 0:00:13.608 60 0:00:13.610 60 0:00:13.612 117 0:00:13.623 115 0:00:13.632 60 0:00:13.641 60 0:00:13.642 60 0:00:13.648 60 0:00:13.652 60 0:00:13.658 60 0:00:13.836 60 0:00:13.857 103 0:00:13.861 161 0:00:13.862 60 0:00:13.882 67 0:00:13.883 63 0:00:13.889 60 0:00:13.893 77 0:00:13.907 73 0:00:13.908 60 0:00:13.921 85 0:00:13.923 77 0:00:13.925 214 0:00:13.946 214 0:00:13.965 214 0:00:13.985 214 0:00:14.005 214 0:00:14.025 214 0:00:14.045 214 0:00:14.066 214 0:00:14.085 214 0:00:14.105 60 0:00:14.125 Delta Time 3.607.930 0.001.196 0.002.361 0.010.694 0.009.512 0.008.246 0.001.215 0.005.918 0.004.748 0.005.942 0.177.682 0.020.896 0.004.032 0.001.097 0.020.283 0.001.084 0.006.040 0.003.321 0.014.486 0.001.066 0.013.157 0.001.130 0.002.460 0.021.002 0.019.385 0.019.964 0.020.006 0.020.007 0.020.018 0.020.910 0.019.092 0.020.025 0.019.525 Abs. Time 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:40 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 2000-06-07 15:11:41 Summa TCP: D=1720 S=11018 SYN SEQ=502840112 LEN=0 WIN=4128 TCP: D=11018 S=1720 SYN ACK=502840113 SEQ=449596568 LEN=0 WIN=4128 TCP: D=1720 S=11018 ACK=449596569 WIN=4128 H225USR: type=Setup userid=126 length=38 H225USR: type=Alerting userid=126 length=42 TCP: D=11017 S=11019 SYN SEQ=502875512 LEN=0 WIN=4128 TCP: D=11019 S=11017 SYN ACK=502875513 SEQ=449628639 LEN=0 WIN=4128 TCP: D=11017 S=11019 ACK=449628640 WIN=4128 TCP: D=11019 S=11017 ACK=502875513 SEQ=449628640 LEN=4 WIN=4128 TCP: D=11017 S=11019 ACK=449628640 SEQ=502875513 LEN=4 WIN=4128 TCP: D=1720 S=11018 ACK=449596630 WIN=4067 TCP: D=11019 S=11017 ACK=502875517 WIN=4124 H245: Type=Request, Terminal Capability Set H245: Type=Request, Terminal Capability Set TCP: D=11017 S=11019 ACK=449628751 SEQ=502875566 LEN=4 WIN=4017 H245: Type=Request, Open Logical Channel H245: Type=Response, Terminal Capability Set Ack Function Not Understood TCP: D=11019 S=11017 ACK=502875579 SEQ=449628764 LEN=4 WIN=4062 H245: Type=Request, Open Logical Channel H245: Type=Request, Conference Request TCP: D=11017 S=11019 ACK=449628787 SEQ=502875602 LEN=4 WIN=3981 H245: Type=Response, Open Logical Channel Ack H245: Type=Response, Open Logical Channel Ack RTP: PT=PCMA,SEQ=12046,T=2045780809,SSRC=367853825 RTP: PT=PCMA,SEQ=12047,T=2045780969,SSRC=367853825 RTP: PT=PCMA,SEQ=12048,T=2045781129,SSRC=367853825 RTP: PT=PCMA,SEQ=12049,T=2045781289,SSRC=367853825 RTP: PT=PCMA,SEQ=12050,T=2045781449,SSRC=367853825 RTP: PT=PCMA,SEQ=12051,T=2045781609,SSRC=367853825 RTP: PT=PCMA,SEQ=12052,T=2045781769,SSRC=367853825 RTP: PT=PCMA,SEQ=12053,T=2045781929,SSRC=367853825 RTP: PT=PCMA,SEQ=12054,T=2045782089,SSRC=367853825 TCP: D=11019 S=11017 ACK=502875629 WIN=4012
www.juniper.net
33
Mobile Networks
UMTS Infrastructure IP Infrastructure
UMTS Terrestrial Radio Access Network UTRAN
BTS RNC MSC/VLR Corporate / VPNs
HLR SGSN
Internet GGSN Backbone MS
GW PSTN,ISDN PLMN
ISP Service Co-location
The important note for IP freaks, Its transported over packet based IP networks !
www.juniper.net
34

35
RFC 791TOS field

RFC 791 (circa 1981) defined the type-of-service field in the IP header: 3-bit precedence field to prioritize discards
Bits 0-2: Precedence. Bit 3: 0 = Normal Delay, 1 = Low Delay. Bits 4: 0 = Normal Throughput, 1 = High Throughput. Bits 5: 0 = Normal Relibility, 1 = High Relibility. Bit 6-7: Reserved for Future Use. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | PRECEDENCE | D | T | R | 0 | 0 | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Precedence 111 110 101 100 011 010 001 000 Network Control Internetwork Control CRITIC/ECP Flash Override Flash Immediate Priority Routine
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 -----
www.juniper.net
37

38
IntServ (circa 1994)

The IETFs 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 its the receiver who do the reservation. The reservation is hop per hop.
RSVP Path Message from Sender (H323 terminal)

VoIP node VoIP Gateway
PSTN
Host
RSVP Reservation from Receiver (H-323 Gateway)
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
www.juniper.net
40

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 stucturethe 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

0
IP Precedence
Reserved
DiffServ RFC 2474
1 2 3 4 DiffServ Code Point
6 7 Reserved
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
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) Scheduling Policing Marking Classification (BA) Scheduling Policing Marking/Rewrite Classification (BA) Scheduling Policing Marking/Rewrite Classification (BA) Scheduling Policing
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'. 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 | +----------+----------+----------+----------+ = ' = ' = ' The
www.juniper.net
45
RFC 2598 (EF PHB)

RFC 2598 1. Introduction An Expedited Forwarding PHB June 1999 The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-toend 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.
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.
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)
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)
www.juniper.net
49

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
51
Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSR
Extended IGP
Routing table
Traffic engineering Database (TED)
Constrained Shortest Path First
User Constraints
1) Store information from IGP flooding 2) Store traffic engineering information 3) Examine user defined constraints 4) Calculate the physical path for the LSP 5) Represent path as an explicit route 6) Pass ERO to RSVP for signaling
RSVP signaling Explicit route
www.juniper.net
52
Constraint-Based Routing: RSVP Signaling

CSPF ERO Egress LSR RESV
PATH
RSVP 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
53
Constraint Based-Routing: Example 1

Seattle
Chicago San Francisco Kansas City Los Angeles Atlanta
New York
label-switched-path SF_to_NY { to New_York; from San_Francisco; admin-group {exclude green} cspf}
Dallas
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
www.juniper.net
55

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
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).
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?
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
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.
61
Diffserv TE
Diffserv enables scalable network designs with multiple classes of service MPLS TE enables resource reservation, faulttolerance, 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
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
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
www.juniper.net
64
Support for Multiclass E-LSPs

LSR LDP/RSVP E-LSP AF1 EF AF1 EF LDP/RSVP
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
65
Support for single class E-LSPs

LSR EF
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
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 forwardingclass 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.

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)
www.juniper.net
68
Picking Eight TE-Classes
www.juniper.net
69
Constraint-Based Routing: Service Model

Operations Performed by the Ingress LSR
Extended IGP
Routing table
Traffic engineering Database (TED)
Constrained Shortest Path First
User Constraints
1) Store information from IGP flooding (BW per CT) 2) Store traffic engineering information 3) Examine user defined constraints (BW per CT) 4) Calculate the physical path for the LSP(s) 5) Represent path as an explicit route 6) Pass ERO to RSVP for signaling
RSVP signaling Explicit route
www.juniper.net
70
How is bandwidth accounted?

The IETF defined bandwidth models. They determine the partitioning of BW among the different CTs
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.
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
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)
www.juniper.net
74
Thank you
Jean-Marc Uz Liaison Research & Education, EMEA juze@juniper.net Mobile: +33615432512
31 Place Ronde, 92986 Paris-La-Defense, France
www.juniper.net
75

Seeren Cos Junos Module1

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Seeren Cos Junos Module1

Загружено:

Авторское право:

Доступные форматы

SEEREN2 Summer School Heraklion, Sept 25th Routing Issues: QoS/CoS

Jean-Marc Uz Liaison Research & Education, EMEA juze@juniper.net

Copyright 2006 Juniper Networks, Inc.

Agenda: QoS/CoS Workshop

Copyright 2006 Juniper Networks, Inc.

Copyright 2006 Juniper Networks, Inc.

Copyright 2006 Juniper Networks, Inc.

Why network QoS?

Copyright 2006 Juniper Networks, Inc.

Why router CoS?

Why router CoS?

Copyright 2006 Juniper Networks, Inc.

What is CoS not!?

Copyright 2006 Juniper Networks, Inc.

Why deploying QoS in R&E Networks?

The Old Edge

ATM Fra me Rel ay

Copyright 2006 Juniper Networks, Inc.

Consolidated Multi-Service Edge

ERX, M & T Series Consolidation Strategy aligned around MPLS

DS0, T1/E1, OC3, OC12

Layer 2/3 VPN

ERX/M-series ATM/FR, POS, GE

VoIP ATM Voice

Copyright 2006 Juniper Networks, Inc.

Module 1: Overview of QoS/CoS

Definition of Network QoS Parameters

Delay variation (jitter)

Copyright 2006 Juniper Networks, Inc.

How does a router influence these parameters (Delay) ?

Copyright 2006 Juniper Networks, Inc.

Copyright 2006 Juniper Networks, Inc.

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

Copyright 2006 Juniper Networks, Inc.

Propagation delay (Distance)

Copyright 2006 Juniper Networks, Inc.

How does a router influence these parameters (Jitter) ?

Copyright 2006 Juniper Networks, Inc.

A visual on the source of jitter

VoIP packet has to wait for best-effort packet to be serviced

Time t+x: Best effort is serviced and VOIP just arrives

Wait time depends on size of best-effort packet

Time t+x+y: VOIP is serviced after Best effort.

This happens hop-by-hop

Copyright 2006 Juniper Networks, Inc.

How does a router influence these parameters (Loss)?

Copyright 2006 Juniper Networks, Inc.

How does a router influence these parameters (Loss)? contd.

Copyright 2006 Juniper Networks, Inc.

How does a router influence these parameters (Throughput)?

Copyright 2006 Juniper Networks, Inc.

Traffic flow Disharmony

Copyright 2006 Juniper Networks, Inc.

TCP the major flow

Copyright 2006 Juniper Networks, Inc.

Random Early Detection

Copyright 2006 Juniper Networks, Inc.

TCP, Slow start function

Copyright 2006 Juniper Networks, Inc.

TCP flow control 1

Copyright 2006 Juniper Networks, Inc.

TCP flow control 2

Copyright 2006 Juniper Networks, Inc.