1 / 23

Quality-of-Service Support for Mobile Users using NSIS

Quality-of-Service Support for Mobile Users using NSIS. Roland Bless, Martin Röhricht Networking 2009, Aachen. Motivation. More and more resource demanding Internet applications and multimedia streams video broadcasts, Voice-over-IP, IPTV Inherent need for Quality-of-Service guarantees

george
Télécharger la présentation

Quality-of-Service Support for Mobile Users using NSIS

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. Quality-of-Service Supportfor Mobile Users using NSIS Roland Bless, Martin Röhricht Networking 2009, Aachen

  2. Motivation • More and more resource demanding Internet applications and multimedia streams • video broadcasts, Voice-over-IP, IPTV • Inherent need for Quality-of-Service guarantees • across administrative domains • signaling protocol needed  RSVP, NSIS • lacking mobility support of earlier signaling protocols like RSVP • Increasing popularity of mobile Internet devices • Laptops, mobile phones (iPhone), PDAs • MobileIP allows for mobility in IP-based networks • adjusts data path transparently • Goal: Enable Quality-of-Service in mobile environments Networking 2009, Aachen

  3. Main Challenges • Resource reservations need to be setup on the new path • as quickly as possible • by using same/adapted QoS parameters • release resource reservations on old path • Tight interworking needed between mobility management and signaling protocol • QoS signaling should work seamlessly with handovers across access nodes Networking 2009, Aachen

  4. MobileIP – Overview Logical Flow Home Network Correspondent Network CN AR1 HA MN HoA Non-RouteOptimized Flow Route-optimized flows Tunnel Flow Tunneled Flow Path before movement Cross-over node Foreign Network A Foreign Network B MN New CoA AR2 MN Old CoA AR3 Handover Networking 2009, Aachen

  5. Next Steps in Signaling – Overview Data flow QoS NSLP Signaling • Two-layer approach • QoS NSLP • NTLP, i.e. GIST • path-coupled signaling • signaling node discovery • message transport(unreliable, reliable,secure) NSISSignaling Layer (NSLP) SignalingApplication 1 (QoS) Signaling Application2 (NAT FW) General Internet Signalling Transport (GIST) NSISTransportLayer (NTLP) TLS UDP TCP SCTP DCCP IPsec IPv4/IPv6 Networking 2009, Aachen

  6. Problems • NSIS protocol suite provides • Basic mobility support: Session-ID remains constant even if a flow’s addresses change • Re-establishment of a reservation along a new path • Main problems to solve • get triggers from mobility events • get the current addressing information • provide internal interfaces required to provide the necessary information • Solution focuses on MobileIPv6 as mobility management solution Networking 2009, Aachen

  7. Mobility Scenarios • Mobile node is sender and initiator/responder • mobility events may trigger QoS NSLP actions • emit new RESERVE or QUERY message • QSPEC may be adapted, constant Session ID • Mobile node is receiver and initiator/responder • difficult to notify sender (CN), i.e. to signal in upstream direction • path not known in advance • difficult to determine cross-over node • flow address may change • profile in first-hop router must be updated at sender side • available QoS at new Access Router may differ • re-negotiation along whole path required Networking 2009, Aachen

  8. Solutions to Mobility Problems • Mobility-aware applications (e.g., SIP) could provide the necessary triggers • Assumption: MobileIPv6 as mobility management protocol • Provides transparent support for transport protocols/applications • Flow descriptor in QoS NSLP requires knowledge of current Care-of Address • contradicts use of Mobile IP that hides mobility • Mobility is not transparent to QoS NSLP, e.g., must also consider • overhead added by MobileIP for QoS reservations (additional headers) • source address selection • Main problem: notification of mobility events to QoS NSLP Networking 2009, Aachen

  9. FlowInfoService Module • New approach: add FlowInfoService module • allows to request information about flows, e.g., current care-of-addresses, sizes of additional headers • must get updates if addresses change Application Flow Info Request: (source addr, dest. addr) NSIS Protocols QoS NSLP Reply/Notification: • Original flow= (source addr, dest. addr) • Flow status= {none, tunneled, routeopt.} • New flow= (source addr, dest. addr) • Overhead [bytes] GIST Flow Information Service UDP SCTP TCP MIPv6d Networking 2009, Aachen

  10. Evaluation – Setup Movement AR1 Network Home Network HA V 5 V 4 V 7 V 8 AR1 V 10 CN V 13 V 14 AR2 AR2 Network V 15 V 16 V 1 AR3 Network V 17 MN AR3 Virtual Environment on PC 1 VLANs Physical Gigabit Ethernet Link Smart Switch (FreeBSD 7) PC 2 Packet Dumps Networking 2009, Aachen

  11. Evaluation – Performance Benchmarks I • 50 consecutive movements of the MN between AR3 to AR2 to AR1 and back • Reservation setup and tear down of old path Networking 2009, Aachen

  12. Evaluation – Performance Benchmarks II • Receiver-initiated Reservation • setup delay for reservation from Access Router 1 Networking 2009, Aachen

  13. Evaluation – Performance Benchmarks III • Delay for tear down of old reservation Networking 2009, Aachen

  14. Evaluation – Performance Benchmarks IV • Added additional delay between AR1/AR2 (50ms) and AR2/AR3 (25ms) • Setup Delay Overhead ≤ 10% Networking 2009, Aachen

  15. Conclusion & Outlook • QoS support for mobile users viable • NSIS QoS NSLP is prepared for mobility • Mobility triggers required • Flow Information Service • Low additional overhead • Code freely available: http://nsis-ka.org Outlook • Repeating measurements in real testbed • Seamless QoS support: Anticipated Handover • Requires protocol extensions • Ongoing implementation effort Networking 2009, Aachen

  16. Thanks! Questions? www.tm.uka.de/itm

  17. Backup Networking 2009, Aachen

  18. Path divergence after movement Sender ISP Domain A ISP Domain B ISP Domain C CN ARO Flow fo CN AROMN Flow fn CN ARNMN Downstream Cross-over node Flow MN CN Upstream Cross-over node ISP Domain D ISP Domain E MN ARN Receiver • Upstream and downstream signaling paths may differ • may result in different cross-over nodes Networking 2009, Aachen

  19. MN=Sender, Sender-Initiated RN1 RNi RO1 RCR ROj Sender Receiver MN ARO ARN CN Mobility Trigger RESERVE RESERVE RESERVE RESERVE RESERVE RESERVE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE Networking 2009, Aachen

  20. MN=Sender, Receiver-Initiated RN1 RNi RO1 RCR ROj Sender Receiver MN ARO ARN CN Mobility Trigger QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) RESERVE RESERVE RESERVE RESERVE RESERVE RESERVE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE Networking 2009, Aachen

  21. MN=Receiver, Sender-Initiated RN1 RNi RO1 RCR ROj Receiver Sender MN ARO ARN CN Binding Update Mobility Trigger RESERVE RESERVE RESERVE RESERVE RESERVE RESERVE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE Networking 2009, Aachen

  22. MN=receiver, receiver-initiated RN1 RNi RO1 RCR ROj Receiver Sender MN ARO Binding Update ARN CN Mobility Trigger QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) QUERY (R=1) RESERVE RESERVE RESERVE RESERVE RESERVE RESERVE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE RESPONSE Networking 2009, Aachen

  23. Trigger Overhead • time between the BindingUpdate/BindingAcknowledgement and GISTQuery that starts the signaling process: • MN 1.93ms • CN 2.54ms Networking 2009, Aachen

More Related