IPv6 Technology and Advanced Services 19/10/2004 IPv6 Technology and Advanced Services IPv6 Quality...

IPv6 Technology and Advanced Services 19/10/2004

IPv6 Technology and Advanced Services

IPv6 Quality of Service

Dimitris Primpas ([email protected])

Computer Engineer, M.Sc.

Research Academic Computer Technology Institute (CTI)

Research Unit 6 (ru6.cti.gr)


Quality of Service

— IP Networks

— best effort service

— Congestion

— No guarantees to delay sensitive applications

— Solution: Quality of Service (QoS)

«The capability of a network’s element to provide to an aggregation (of flows) the guarantee that the service’s demands can be

achieved with given (high) possibility»


QoS metrics— Bandwidth

— maximum burst size— peak bandwidth— minimum guaranteed bandwidth— average bandwidth

— Delay

— Transmission time— Delay time

— jitter (IP packet delay variation)

— packet loss

— QoS architectures (IntServ & DiffServ)


IntServ Architecture

— Proposed by Internet Engineering Task Force (IETF)

— Most important points

— Resource control

— Admission control

— Resource Reservation Protocol (RSVP)

— Signaling

— PATH and RESV messages

— Proposed Services: Guaranteed & Controlled Load


DiffServ Architecture

— Per Hop Behavior (PHB)— Expedited Forwarding (EF) και Assured Forwarding (AF)

— Mechanisms— Packet classification

• IPv6 Traffic Class, IPv4 ToS, MPLS (EXP field)

— Packet marking

— metering (token bucket)

— Policing and shaping

— Queue management


DiffServ Services— Edge and Core routers

— Enabling traffic conditioning mechanisms on edge routers

— Queue scheduling mechanisms on all routers

— trusted domains

— EF-based (EF PHB)— IP Premium

• DSCP τιμή 101110 • Strict policing using token bucket• High priority

— AF based (AF PHB)— Every class gets certain resources— Policing and marking into at least 3 classes (green, yellow, red packets)


Packet classification in IPv4

— Based on IPv4 header— Field DSCP (TOS octet) which is 6bits

— 64 possible combinations -> 64 classes

DSCP unused

6 bits 2 bits


Packet classification in IPv6

— Based on IPv6 header— DSCP field that

belongs to Traffic Class

— flow label (for flow classification) – standardized recently with RFC 3697

Payload length Next header Hop limit

IP Destination

IP Sender

ver Traffic Class Flow Label

0 4 12 3116 248


Differences in IPv4 and IPv6

— In theory: the packet classification— Using the additional field “flow label”

— Using the DSCP

— In practice:— Only a fraction of QoS mechanisms in IPv4 are currently

implemented for IPv6

— This depends on the network operators and their products

— As the usage of the IPv6 increases, this problem will be eliminated


Flow label usage (I)

— RFC 3697 J. Rajahalme, A.Conta, B. Carpenter, S. Deering (March 2004)

— Changes the traditional way to make flow classification— Traditionally: IP sender, IP receiver, ports, transport protocol

— Now based only in IP header information

— 3-tuple: flow label, sender address, destination address

— Flow label 20bits field

— Packets with flow label=0, do not belong to a flow


Flow label usage (II)

— Flow state expires after 120 seconds— Except the lifetime has been defined longer— Flow has been refreshed explicitly

— Nodes that do not support flow specific treatment should ignore the field

— To enable flow label based classification:— Each unrelated transport connection and application data

stream move to a new flow— Node that does not assign traffic to flows, marks the flow label

with 0


Flow label usage (III)

— Flow label value reuse (critical)— Select new value in a well defined sequence (sequential,

pseudo- random)

— Flow state establishment (critical)— Established in all IPv6 nodes or a subset of IPv6 nodes

— Methods for state establishment are under investigation

— 2 requirements for co-existence:• Provide the means for flow state clean up. Also, signaling based methods

where the source is involved, should allow the definition of longer lifetimes• Support recover in case the flow state cannot be supported.


Flow label usage (IV)

— Security issues:— Denial of service attacks— Theft of service attacks by unauthorized traffic

• Spoofing the flow label value (only on valid nodes that uses the correct source address)

• Spoofing the 3-tuple (flow label, source address, destination address). This can be done in an intermediate router or in a host that does not subject in ingress filtering.

— Only applications with an appropriate privilege in a sending host should be entitled to set a non zero flow label

• Operating system dependent• Related policy and authorization mechanisms also required


Flow label usage (V)

— Security issues:— Ipsec protocol does not include the flow label in its

cryptographic calculations — Ipsec tunnel mode:

• Contains 2 IP headers: outer header supplied by the tunnel ingress node and an inner header supplied by the original source of the packet.

• In the IPsec tunnel, intermediate nodes operates only in outer header’s flow label

• IPsec protocol requires that during decapsulation in the egress node of the Ipsec tunnel, the flow label in the inner header can not change.

— Flow label does nothing to eliminate the need for packet filtering based on headers past the IP header (firewalls, filtering routers)


IPv6 QoS case study

— 6NET network

— CTI’s network in the Greek part

— Cisco router 7206

— Cisco router 3640

— 2 network switches, various pc

— CISCO IOS 12.2(13)T

ATHENSCisco 7206

THESSALONIKI

Cisco 7206

NTUACisco 7206

3Mbit ATM PVC

Gigabit Ethernet

to Munich

ATHENSGSR 12016

POS

6NET

local CTI network

Cisco 3640

CTI-PATRACisco 7206

1Mbit ATM PVC

10Mbs


Goals

— Test an EF based service for real time applications

— Investigate classification mechanism

— Investigate prioritization mechanism

— Investigate policing mechanism

— Test all the mechanism under different traffic loads

— Test the WRED mechanism on the background traffic

— Investigate mechanism’s operation

— Investigate its impact on QoS service


Experimental Procedure

— Traffic generated with Iperf traffic generator

— IPv6 UDP traffic• Periodic UDP traffic with specific bandwidth

— IPv6 TCP traffic• Try to sent with the bigger rate it can

— Real time traffic

— IPv6 traffic created by OpenPhone (videoconference traffic using OpenH323)

— Investigation of network’s performance

— Congested when traffic load is up to 8Mb (10Mb link)


Testing the EF based service with real time traffic

— Performed tests with real time traffic (by OpenH323)

— Background traffic• Mix of TCP and UDP traffic generated by Iperf

— Foreground traffic• Real time traffic generated by openphone (on testing scenario)• Real time traffic generated by openphone (on testing scenario) and

additionally UDP traffic generated by Iperf (300Kbps)

— Expected result:

— Throughput of foreground traffic and of TCP’s background traffic??

— Quality of videoconference data??


Results with real time data

— Videoconference:

— excellent quality

— Few packet losses

— Average throughput 300Kbps

— Background traffic

— UDP: tries to earn bandwidth from the remaining

— TCP: adjust its rate to the remaining bandwidth

TCP throughput

0200000400000600000800000

10000001200000

tim

e(s

ec)

36

,97

68

53

43

,91

59

2

51

,67

23

07

59

,31

75

85

67

,07

51

77

75

,37

91

6

83

,30

37

29

91

,30

21

09

98

,83

73

42

10

7,0

06

89

114

,80

61

4

12

3,0

75

52

13

0,6

25

29

13

8,6

04

11

14

6,7

92

81

time (sec)

thro

ug

hp

ut

(by

tes

/se

c)

TCP throughput


Investigation of WRED mechanism

— WRED mechanism

— Min threshold, max threshold, dropping possibility

— Investigate its impact on foreground traffic

— Investigate its impact on background traffic

— Performed 2 testing scenarios

— 1st scenario:• Minthreshold = 30, maxthreshold = 50, dropping possibility = 10%, max queue size = 75

packets

— 2nd scenario:• Minthreshold = 55, maxthreshold = 75, dropping possibility = 10%, max queue size = 75

packets


Results for WRED (scenario 1)

— Foreground traffic

— Real time data (OpenH323) & additional UDP traffic (700Kbps)

— Excellent quality of videoconference


— UDP traffic had many packet losses (2%)

— TCP also straggled if we compare it with previous experiments (throughput representation)

TCP throughput

0200000400000600000800000

10000001200000

time

(s)

11,9

4679

8

23,9

3284

8

38,4

2993

1

52,8

0110

9

67,6

2517

1

82,5

777

96,9

5438

4

112,

5352

92

126,

8801

99

141,

6963

5

157,

3920

82

171,

1629

59

185,

1934

3

198,

8364

31

214,

4675

92

229,

6113

92

time (sec)

thro

ughp

ut (b

ytes

/sec

)

TCP throughput


Results for WRED (scenario 2)

— Foreground traffic

— Real time data (OpenH323) & additional UDP traffic (700Kbps)

— Excellent quality of videoconference


— UDP traffic had less packet losses (0.90%)

— TCP straggled less

— Investigate its impact on foreground traffic if we approach priority’s upper bound??

throughput

0200000400000600000800000

10000001200000

time

(s)

15,4

5425

526

,319

967

39,5

8291

450

,246

195

63,2

1058

478

,567

228

93,1

3155

210

8,07

5704

121,

4209

2813

6,27

3041

151,

0166

9716

4,38

5322

179,

2781

5819

3,65

9296

208,

6780

1122

3,47

5609

time (sec)th

roug

hput

(byt

es/s

ec)

throughput


Overall - Conclusions

— QoS support in IPv6 provides extended capabilities (using flow label) especially for real time applications

— The QoS work in IPv6 still needs a lot of effort

— Next steps:— Network operators must support all (and new) the queue

management mechanisms in IPv6

— Provide methods for flow state establishment

— Investigate security issues of flow label


Questions?

Thank you

Dimitris Primpas ([email protected])

Research Academic Computer Technology Institute

Research Unit 6

IPv6 Technology and Advanced Services 19/10/2004 IPv6 Technology and Advanced Services IPv6 Quality...

Documents

Transcript of IPv6 Technology and Advanced Services 19/10/2004 IPv6 Technology and Advanced Services IPv6 Quality...