Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
IPv6 Technology and Advanced Services IPv6 Quality of Service Dimitris Primpas (firstname.lastname@example.org) 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 • minimumguaranteedbandwidth • average bandwidth • Delay • Transmission time • Delay time • jitter (IP packet delay variation) • packet loss • QoS architectures (IntServ & DiffServ)
IntServ Architecture • Proposed byInternet Engineering Task Force (IETF) • Most important points • Resource control • Admission control • Resource Reservation Protocol (RSVP) • Signaling • PATH andRESV 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 andCore routers • Enablingtraffic conditioning mechanisms onedge 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 • FieldDSCP (TOS octet) which is 6bits • 64 possible combinations -> 64 classes unused DSCP 6 bits 2 bits
Packet classification in IPv6 • Based onIPv6 header • DSCP field that belongs toTraffic Class • flow label (for flow classification) – standardized recently withRFC3697 31 0 4 8 12 16 24 ver Traffic Class Flow Label Next header Payload length Hop limit IP Sender IP Destination
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
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
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 • Background traffic • UDP traffic had many packet losses (2%) • TCP also straggled if we compare it with previous experiments (throughput representation)
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??
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@example.com) Research Academic Computer Technology Institute Research Unit 6