1 / 24

IPv6 Technology and Advanced Services

IPv6 Technology and Advanced Services. IPv6 Quality of Service Dimitris Primpas ( primpas@cti.gr ) 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

sandro
Download Presentation

IPv6 Technology and Advanced Services

An Image/Link below is provided (as is) to download presentation 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv6 Technology and Advanced Services IPv6 Quality of Service Dimitris Primpas (primpas@cti.gr) Computer Engineer, M.Sc. Research Academic Computer Technology Institute (CTI) Research Unit 6 (ru6.cti.gr)

  2. 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»

  3. 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)

  4. 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

  5. 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

  6. 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)

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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.

  13. 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

  14. 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)

  15. 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

  16. 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

  17. 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)

  18. 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??

  19. 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

  20. 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

  21. 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)

  22. 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??

  23. 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

  24. Questions? Thank you Dimitris Primpas (primpas@cti.gr) Research Academic Computer Technology Institute Research Unit 6

More Related