Seeren Cos Junos Module1

7/31/2019 Seeren Cos Junos Module1

1/75


2/75

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

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


3/75


What is QoS? Methods to utilize existing network capacity efficiently

and meet performance requirements and achieve themaximum traffic throughput

Managed unfairness


4/75


To QoS or CoS? Class of service (CoS) and quality of service (QoS) work

together to ensure transmission requirements of varioustraffic types

Routers use CoS to ensure and enforce end to endnetwork QoS requirements


5/75


Why network QoS? Bandwidth isnt free and all traffic is not equal

Migration continues toward converged network, with multipleservices over IP

Need to distinguish between the multiple services on the convergednetwork 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


6/75


7/757Copyright 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 arbitratethe queues access to the link

So congestion can be isolated to one queue

i.e., one class can be congested whileanother is not

But even the worst class still cant havesustained congestion

i.e., need careful provisioning per class



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



Why deploying QoS in R&E Networks?

Bandwidth management allows you to support differentcommunities and usage, by offering multiple serviceclasses 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 tooffer a wide range of integrated products, such asInternet access, VPN access, and videoconferencing,GRID support, etc

Over-provisioning is not always here

Even if over-provisioning is there, you cant avoidpunctual overload (GRID, failure in the network etc.)

Its a business decision for you, not a technical decision



EdgeEdge

CoreCore

The Old Edge

RawTDM

RawTDM

PE4PE4

FrameRelay

FrameRelay

PE2PE2

PE1PE1

ATMATM

PE3PE3

EthernetEthernet



Consolidated Multi-Service EdgeMobil e CoreMobil e Core

Layer 2/ 3 VPNLayer 2/ 3 VPN

DS0, T1/ E1, OC3, OC12DS0, T1/ E1, OC3, OC12

ATM/ FRATM/ FR

VoIPVoIP

ATM VoiceATM Voice

I nt ernet AccessI nt ernet Access

ATM/ FR, POS, GEATM/ FR, POS, GE

Metro Et hernetMetro Et hernet

I P/ MPLS

ATM/ FR, POS, GEATM/ FR, POS, GE

GEGE

ERX, M & T Ser ies

Consolidation Strategy

aligned around MPLS

ATMATM

ERX/ M-series T-series



Module 1: Overview of QoS/CoS Introduction on CoS and QoS

QoS parameters and Impact on Protocols andApplications

ToS

Intserv

Diffserv

MPLS Traffic Engineering

MPLS Diffserv TE



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 ofapplication performance

Most applications are not aware of network CoS



How does a router influence these

parameters (Delay) ?Propagationdelay

Switchingdelay

Serializationdelay

Scheduling/

Queueingdelay:

5ms per 1000 km over optical fiber.

time difference between receiving a packet on an incominginterface and enqueuing of the packet in the scheduler of itsoutbound interface. ~10-50 us

time taken to clock a packet onto a link, depends on link speedand packet size, cant do better than line rate. E.g. 1500 bytepacket for oc-48 = 5us

time difference between enquiring the packet of the outboundinterface scheduler and the start of clocking the packet ontothe outbound link.


15/75


16/75


Serialization Delays (in msec) by

Link Speed and Packet SizePacket size

in bytes

Link Speed

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


17/75


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

Propagation delay

(Distance)

Serialisation delay

(Link bandwidth)

Queuing delay

(COS configuration)

Forward delay

(Lookup and ASIC)


18/75



parameters (Jitter) ? Jitter is the variation in delay over time

The primary contributor to jitter is the variability ofqueuing/scheduling delay over time

Conclusion: Jitter matters more on slower links, andbigger packets hurt most

Typical jitter budget for backbone is 5 to 10 msec.assuming 10 backbone hops, it is a jitter budget of 500 to1000 us per hop.


19/75


A visual on the source of jitter Best-effort queue starts being

serviced right before a VoIPpacket arrives

VoIP packet has to wait forbest-effort packet to beserviced

Wait time depends on size

of best-effort packet

This happens hop-by-hop

Best eff ortBest eff ort

VoIPVoIP

Best eff ortBest eff ort

VoIPVoIP

TimeTime t+ xt+ x : Best effor t is serviced: Best effor t is serviced

and VOI P j ust arr ivesand VOI P j ust arri ves

ServiceService

Best effortBest effort

VoIPVoIP

TimeTime t + x + yt + x + y : VOI P is serviced af t er: VOI P is serviced af t er

Best effort .Best effort .

ServiceService

ArriveArrive

TimeTime tt : 1: 1stst VOI P is serv icedVOI P is serviced


20/75



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 bottleneckbandwidth

A loss of 2 consecutive 20ms samples of voice is perceptibledegradation


21/75



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


22/75


23/75


Traffic flow Disharmony What isnt queue management? =>FIFO/Tail drop.

Example bandwidth mismatch problem from Intra ASpeers to Exchange points or Core towards edge.

STM-1STM-64

Bit bucketPacket drop


24/75


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% taildrop -> 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 interactionTCP==Application, not necessary the whole truth


25/75


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 andsynchronization problems. But thats the theory

RED scheme efficiency depends upon application.Essentially session have to be long lived, or that RED isflow aware and not just packet aware


26/75


TCP, Slow start function

Slow st art ,probe of connect ion

I f loss/ RTT t imeoutsender half datagram and size

Mult iple/ massive TCP dropsand result ing duplicat ed ACKs from receiverforce TCP Slow start

Sender Receiver


27/75


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 bytes26 6.633393 1.1.1.11 -> 192.168.1.100 TCP 4983 > 21 [ACK] Seq=1270128481 Ack=2726329842 Win=17376 Len=027 6.633438 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467594828 Win=17376 Len=028 6.633813 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes29 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=031 6.637518 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes32 6.637690 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes33 6.637862 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes34 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 bytes59 6.662000 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes60 6.662280 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes61 6.662439 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes62 6.662591 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes63 6.662860 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes64 6.663044 192.168.1.100 -> 1.1.1.11 FTP-DATA FTP Data: 1448 bytes65 6.663122 1.1.1.11 -> 192.168.1.100 TCP 51345 > 20 [ACK] Seq=1310902396 Ack=3467623788 Win=17376 Len=0[]


28/75


TCP flow control 2 HTTP where is the long lived session ?

RED ? To be efficient its more multiple levels oftaildrop

158 33.614381 192.168.0.200 -> 207.17.137.68 HTTP GET /solutions/literature/app_note/350005.pdf HTTP/1.1159 33.848019 207.17.137.68 -> 192.168.0.200 TCP http > 1297 [ACK] Seq=2713032788 Ack=576311475 Win=24616 Len=0160 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=0162 34.200987 207.17.137.68 -> 192.168.0.200 HTTP Continuation163 34.224733 207.17.137.68 -> 192.168.0.200 HTTP Continuation164 34.224918 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=14480 Len=0165 34.229408 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713035931 Win=17376 Len=0166 34.459063 207.17.137.68 -> 192.168.0.200 HTTP Continuation167 34.482887 207.17.137.68 -> 192.168.0.200 HTTP Continuation168 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 Continuation170 34.507252 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=14480 Len=0171 34.519431 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713040275 Win=17376 Len=0172 34.707686 207.17.137.68 -> 192.168.0.200 HTTP Continuation173 34.732468 207.17.137.68 -> 192.168.0.200 HTTP Continuation174 34.732639 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713042675 Win=15928 Len=0175 34.756276 207.17.137.68 -> 192.168.0.200 HTTP Continuation176 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 Continuation178 34.804460 207.17.137.68 -> 192.168.0.200 HTTP Continuation179 34.804618 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=14480 Len=0180 34.809485 192.168.0.200 -> 207.17.137.68 TCP 1297 > http [ACK] Seq=576311475 Ack=2713047019 Win=17376 Len=0


29/75


UDP

UDP guarantee nothing, no response to taildrops or

Random drops (RED) from endhost. But hard contractscan impact missbehaved UDP. Policing most effective !

Small overhead. Stateless, easy to re-route

No segment control, best effort.

Application responsable for control, timestamp ex withRTP header or application ACKs

Applications ACK...maybe

Dataforward

Sender Receiver


30/75


TFTP,

Example of old UDP implementation Application ACK for each 516 byte

datasegment

emilie# tcpdump -i fxp1tcpdump: listening on fxp113:09:48.040923 192.168.1.100.2134 > 1.1.1.11.2472: udp 51613:09:48.042117 1.1.1.11.2472 > 192.168.1.100.2134: udp 413:09:48.042512 192.168.1.100.2134 > 1.1.1.11.2472: udp 51613:09:48.043619 1.1.1.11.2472 > 192.168.1.100.2134: udp 413:09:48.044046 192.168.1.100.2134 > 1.1.1.11.2472: udp 51613:09:48.045151 1.1.1.11.2472 > 192.168.1.100.2134: udp 413:09:48.045547 192.168.1.100.2134 > 1.1.1.11.2472: udp 51613: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 51613:09:48.048155 1.1.1.11.2472 > 192.168.1.100.2134: udp 413:09:48.048548 192.168.1.100.2134 > 1.1.1.11.2472: udp 51613:09:48.049666 1.1.1.11.2472 > 192.168.1.100.2134: udp 4[]


31/75


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





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=2233125814172 [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



[]


32/75


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 inwider jitter !


33/75

Mobile Networks


34/75


Mobile NetworksUMTS

InfrastructureI P I nfrastructure

UMTS TerrestrialRadio Access

Network

UTRAN

PSTN,I SDN PLMN

HLR

SGSN

GGSN

MSC/ VLR

GW

RNC

BTS

Internet

I SP Serv ice

Co-location

Backbone

Corpor ate / VPNs

MS

The import ant note for I P freaks,

I t s t ransported over packet based I P netw orks !


35/75




ToS

Intserv

Diffserv


MPLS Diffserv TE


36/75


RFC 791TOS fieldBits 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 - Network Control

110 - Internetwork Control

101 - CRITIC/ECP

100 - Flash Override

011 - Flash010 - Immediate

001 - Priority

000 - Routine

RFC 791 (circa1981) defined thetype-of-servicefield in the IPheader:

3-bitprecedencefield to prioritizediscards

IP precedence / 802 1p


37/75


IP precedence / 802.1pDLC: ----- 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 -----


38/75




ToS

Intserv

Diffserv


MPLS Diffserv TE

IntServ (circa 1994)


39/75


IntServ (circa 1994)

The IETFs first attempt at extending IP for other thanbest-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 senderinitialize path request, but its the receiver who do thereservation. The reservation is hop per hop.

RSVP Reservation from

Receiver (H-323 Gateway)

RSVP Path Message fromSender (H323 terminal)

VoIPGateway

PSTN

VoI Pnode

Host


40/75


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 (FixedFilter)and if re-routing occur, the reservation falls for all FFreservations -> massive re-signaling.

Everyone learned a lot, but IntServ was never deployed

Scalability of both the control and data planes consideredpoor

But RSVP becomes successful with MPLS

RSVP signaling is used to put up Traffic-Engineer LSP insteadwith success (aggregated traffic)

See later


41/75




ToS

Intserv

Diffserv


MPLS Diffserv TE

DiffServ Emerges


42/75


g DiffServ architecture defined in RFCs 2474/2475 (circa 1998)

Same approach as the precedence bits but more classes andlevels (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

IP ToSRFC 791

DiffServRFC 2474

IP Precedence ReservedD T R

DiffServ Code Point Reserved

0 1 2 4 5 6 73

MSB LSB


43/75


DiffServ Terminology

Key DiffServ terms:

Behavior aggregate (BA): Classification based onDSCP

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 significantbits of the DS field

Per-hop behavior (PHB): The per-hop forwardingtreatment associated with a given BA

DiffServ Model


44/75


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)SchedulingPolicingMarking

Classification (BA)SchedulingPolicingMarking/Rewrite

Classification (BA)SchedulingPolicingMarking/Rewrite

Classification (BA)SchedulingPolicing


45/75


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 | 00101010 | 010010 | 011010 | 100010 |

Medium Drop Prec | 00110100 | 010100 | 011100 | 100100 |

High Drop Prec | 00111110 | 010110 | 011110 | 100110 |

+----------+----------+----------+----------+


46/75


RFC 2598 (EF PHB)RFC 2598 An Expedited Forwarding PHB June 19991. 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.


47/75


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 simplepriority 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 roundrobin [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.

DSCP


48/75


SC

Internet ProtocolVersion: 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: 0x72a6Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 253Protocol: ICMP (0x01)

Header checksum: 0x86ec (correct)

Source: 1.1.1.3 (1.1.1.3)

Destination: 192.168.1.2 (192.168.1.2)

MPLS Exp


49/75


MPLS ExpEthernet IIDestination: 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: 1MPLS 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 setFragment 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)


50/75



Introduction on CoS and QoS


ToS

Intserv

Diffserv


MPLS Diffserv TE

Constraint-Based Routing


51/75


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 paththat meets the constraints

IngressLSR

User defined LSPconstraints

EgressLSR

Constraint-Based Routing: Service Model


52/75


Routing t able

Ext ended I GP

1) Store information fr om I GP flooding

UserConstraints

3) Examine user defined const raint s

ConstrainedShor t est Path First

4) Calculat e the physical path f or t he LSP

Explicit route

5) Represent path as an explicit rout eRSVP signaling

6) Pass ERO to RSVP for signaling

2) Store t raff ic engineering inform ation

Traff ic engineeringDatabase (TED)

Operat ions Performed by t he I ngress LSR

Constraint-Based Routing: RSVP Signaling


53/75


I ngressLSR

EgressLSR

CSPF

ERO

RSVP

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

PATH

RESV

Constraint Based-Routing: Example 1


54/75


NewYork

Atlanta

Chicago

Seattle

LosAngeles

SanFrancisco

KansasCity

Dallaslabel-sw it ched-path SF_t o_NY {

t o New _York;fr om San_Francisco;admin-group { exclude green}cspf}

Constraint-Based Routing: Example 2


55/75


label-switched-path madrid_to_stockholm{

to Stockholm;from Madrid;admin-group { include red, green}cspf}

Paris

London

Stockholm

Madrid

Rome

Geneva

Munich

M d l 1 O i f Q S/C S


56/75



Introduction on CoS and QoS


ToS

Intserv

Diffserv


MPLS Diffserv TE

Wh TE i t h


57/75


When TE is not enough

Traffic engineering operates at an aggregate level across allclasses of service.

The applications that generate most revenue are usually tied tostrict SLAs, and require strict QoS (delay, jitter, loss).

Traffic engineering alone cannot solve all applicationscenarios. Examples:

Limiting the proportion of traffic on a link (for voiceservices)

Providing guaranteed bandwidth services

C Diff l th bl ?


58/75


Can Diffserv solve the problem?

DiffServ dictates the scheduling/queuingbehavior given to traffic at every hop, but

does not control the path the traffic is taking.

If links are congested packets will bedropped (cannot guarantee low-loss).

If queues are long, queuing delays are long(cannot guarantee overall-delay).

Q S i i i i


59/75


QoS using over-provisioning

If the amount of delay-sensitive traffic issmall 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?

QoS the req irements


60/75


QoS the requirements

If links are congested packets will be dropped ->avoid congestion by mapping the traffic to paths thathave enough resources, both in the steady-statecase and in the failure case.

If queues are long, queuing delays are long ->ensure that queues are short limit the amount ofdelay-sensitive traffic on a link.

In addition to DiffServ, need Traffic Engineering =>MPLS TE

The goal of MPLS DS TE


61/75


The goal of MPLS DS-TE

Support different queuing behaviors perDiffServ class, give different forwarding

behavior based on the class.

Do traffic engineering at a per-class levelrather than at an aggregate level.

Enforce different bandwidth constraints fordifferent classes of traffic.

Diffserv TE


62/75


Diffserv TE

Diffserv enables scalable network designs withmultiple classes of service

MPLS TE enables resource reservation, fault-tolerance, and optimization of transmissionresources

Diffserv TE combines the advantages of both

Result is the ability to give strict QoS guaranteeswhile optimizing the use of network resources

Diffserv TE


63/75


Diffserv TE

E-LSPs and L-LSPs are defined as part of Diffserv (RFC3270)

E-LSP means that drop and scheduling behavior (perhop behavior at each router) is determined by theEXP bits in the MPLS header

L-LSP means that drop and scheduling behavior (perhop behavior at each router) is determined by theMPLS label and EXP bits

Diffserv aware MPLS TE Dimensions


64/75


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 eachclass represented by EXP bits, is traffic engineered across thenetwork

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

Support for Multiclass E LSPs


65/75


Support for Multiclass E-LSPs

E-LSP

LSRLDP/RSVP LDP/RSVP

EF

AF1

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 areplaced into different queues

AF1

EF

Support for single class E-LSPs


66/75


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

E-LSPs

LSREF

BE

Terminology Class-type (CT)


67/75


Terminology Class-type (CT)

Class-Type (CT or traffic class): collection of traffic flows that willbe 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 CTin JUNOS.

Terminology: TE Class


68/75


Terminology: TE Class

Each IGP needs to advertise the availablebandwidth 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 storedand propagated for each link

IETF decided to limit the advertisements to 8

values (from possible 64 values) TE Class is defines as (CT, priority)

Picking Eight TE-Classes


69/75


Picking Eight TE Classes

Constraint-Based Routing: Service Model


70/75


Routing t able

Ext ended I GP

1) St ore informat ion from I GP f looding (BW per CT)

UserConstraints

3) Examine user defined const raint s (BW per CT)

ConstrainedShor t est Path First

4) Calculat e the physical path for t he LSP(s)

Explicit route

5) Represent pat h as an explicit rout eRSVP signaling

6) Pass ERO to RSVP for signaling

2) St ore t raff ic engineering inf ormation

Traff ic engineeringDatabase (TED)

Operat ions Performed by t he I ngress LSR

How is bandwidth accounted?


71/75


How is bandwidth accounted?

The IETF defined bandwidth models.

They determine the partitioning of BWamong the different CTs

Bandwidth Models


72/75


There are 2 bandwidth models

Maximum allocation model(MAM) each class is

dedicated an amount ofbandwidth and other classescannot take advantage ofunused bandwidth

Russian dolls model eachclass gets an amount ofbandwidth but lower priorityclasses can use thebandwidth of higher priorityclasses when that bandwidthis available.

Components of DS-TE


73/75


Components of DS TE

Three components:

1. Per-class traffic engineering RSVP extensions,

IGP extensions

2. Per-class input policing at the edge LSPPolicing

3. Per-class scheduling (one queue for all traffic of agiven class) Diffserv

Per-class traffic engineering + policing at the edge +dedicated queue = QoS

What is DS-TE good for?


74/75


at s S good o

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 CoreSolution)


75/75


Thank you

Jean-Marc UzLiaison Research & Education, EMEA

[email protected]: +33615432512

31 Place Ronde, 92986 Paris-La-Defense, France
mailto:[email protected]:[email protected]:[email protected]

Documents

Seeren Cos Junos Module1