IPv6 Technology and Advanced Services 19/10/2004 IPv6 Technology and Advanced Services IPv6 Quality of Service Dimitris Primpas Computer Engineer, M.Sc. Research Academic Computer Technology Institute (CTI) Research Unit 6 (ru6.cti.gr)

IPv6 Technology and Advanced Services 19/10/2004 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»

IPv6 Technology and Advanced Services 19/10/2004 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)

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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 τιμή 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)

IPv6 Technology and Advanced Services 19/10/2004 Packet classification in IPv4 —Based on IPv4 header —Field DSCP (TOS octet) which is 6bits —64 possible combinations -> 64 classes DSCP unused 6 bits2 bits

IPv6 Technology and Advanced Services 19/10/2004 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 verTraffic ClassFlow Label

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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.

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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)

IPv6 Technology and Advanced Services 19/10/2004 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??

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 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 —1 st scenario: Minthreshold = 30, maxthreshold = 50, dropping possibility = 10%, max queue size = 75 packets —2 nd scenario: Minthreshold = 55, maxthreshold = 75, dropping possibility = 10%, max queue size = 75 packets

IPv6 Technology and Advanced Services 19/10/2004 Results for WRED (scenario 1) —Foreground traffic —Real time data (OpenH323) & additional UDP traffic (700Kbps) —Excellent quality of videoconference —Background traffic —UDP traffic had many packet losses (2%) —TCP also straggled if we compare it with previous experiments (throughput representation)

IPv6 Technology and Advanced Services 19/10/2004 Results for WRED (scenario 2) —Foreground traffic —Real time data (OpenH323) & additional UDP traffic (700Kbps) —Excellent quality of videoconference —Background traffic —UDP traffic had less packet losses (0.90%) —TCP straggled less —Investigate its impact on foreground traffic if we approach priority’s upper bound??

IPv6 Technology and Advanced Services 19/10/2004 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

IPv6 Technology and Advanced Services 19/10/2004 Questions? Thank you Dimitris Primpas Research Academic Computer Technology Institute Research Unit 6