1 / 24

Scalable, efficient, personalized, end-to-end QoS Provisioning

Polyrakis Andreas apolyr@noc.ntua.gr Dimitrios Kalogeras dkalo@noc.ntua.gr 21.03.2002. Scalable, efficient, personalized, end-to-end QoS Provisioning. GRNET - NTUA. Contents. Motives & Targets Approach LAN Archtiecture WAN Architecture Demo. Motives. Issues in QoS Provisioning

dnassar
Download Presentation

Scalable, efficient, personalized, end-to-end QoS Provisioning

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. Polyrakis Andreasapolyr@noc.ntua.gr Dimitrios Kalogerasdkalo@noc.ntua.gr 21.03.2002 Scalable, efficient, personalized, end-to-end QoS Provisioning GRNET - NTUA

  2. Contents • Motives & Targets • Approach • LAN Archtiecture • WAN Architecture • Demo

  3. Motives • Issues in QoS Provisioning • Personalization vs Automation • (LDAP  policies) • Personalization vs Scalability • (personalized policies  inter-domain signaling) • Scalability vs Automation • (DiffServ  RSVP) • Automation vs Personalization • (RSVP  LDAP) • Requirements • Scalable • Personalized • Automated (efficient) • End-to-End

  4. Projects’ Targets • «Almost» AutomaticQoS Provisioning perUser /Application • Almost ~ • Atomated Administratevelly • (Semi) automated from user • Personalizedservice • Allocation from Administrator • User’s request • End-to-End (inter-domain)

  5. Basic Assumptions • ApproachLAN – WAN • WAN: ArchitectureDiffserv • LAN:ArchitectureRSVP • ABorderrouter (congestion) inLAN • Internal LANOverprovisioned – GigE • Congestion onegress of WAN’s POPs

  6. Approach • LAN problem • Authentication • Personalization • Signaling • DiffServ markingof egress traffic • Check ingress traffic BEFOREadmitting

  7. Trust Model • Egress- Shengen Model • Check onExit • Ingress– VisaModel • Check on entrance • I.e.: Gold traffic betweenNTUAUoP • Check fron NTUA on Exit • Free transit in GRnet • Check from UoP on entrance

  8. End-2-End? • QoS Request • Accept and Process from LAN PDP • LAN Installation- Automatic Reception from WAN • Reception of reverse traffic on WAΝ’s PoP • Symmetric Procedure on the other end provides Bidirectional end-2-end Qos

  9. LAN Approach

  10. Modelling • Profiles • Set ofallowedQoS configuration • Assigned (default QoS Policy) • Requested (Rights forQoS Requests) • Application of Profiles on Users • Policies • Logging of requirements • Application of Policies on routers • Policies + Profiles + Authentication info (+user requests)Implementation of Targets

  11. Implementation – Policies • QoS Policy – Modular QoS CLI (MQC) • Classes – group of traffic with ACLs • Action – “priority – Bandwidth” • Olympic Metal “Gold, Silver, Bronze” • Preconfigured ratioG-S-B

  12. Implementation - LDAP • Profiles • Flow Description , Possible CLasses) • Assigned – Requested • More conditions • Users ε profiles PDP Monitoring &Accounting

  13. Implementation – User Interface • Thin Client – Fat Server • Web application • Secure Authentication ( Username, Password), secure cookies, One-Time Passwords • Soft-state (RSVP Like) • Signaling (manual) • Automated signaling via RSVP not yet implemented

  14. Implementation – Policy Server • Central Server • Policy Decision Point (PDP) • Data Base

  15. Implemetation - DataBase • AuthenticationInformation • Registered resources from (IP, Ports) • User Profiles from LDAP • User’s Request • ACL for (MQC) • Furthermore: Statisitics, monitoring data

  16. Implementation - PDP • Data Combination in DataBase • ACLs Creation • UploadingACLsonrouter • Step 1:Database clean up • expired users (authenticated resources) • expired requests, requests of expired deletedusers • of policies of deleted users • Of policies with class not matchingacls • Step 2:monitoring-accounting application. Policy inactivation when daily usage has expired • user • Class • User’s profile • Step 3:Revision of acl table • Deletion if oldrows • Rename of old entries to new ones • Creation of newrows • Step 4:Creation of incoming and outgoing acl • Step 5:Upload of aclsonTFTPand HTTP server • Step6 6:Comand router to download outgoing acl

  17. Basic LAN Architecture

  18. WAN Approach

  19. Extension ofQoS RequestsonBackbone • Installation of incoming policy of every memberaccording to his requirement • Configurationof every member on backbone LDAP • Connected Router • Static / Dynamic Policy • Dynamic {url, refresh rate} • Communication with member PDP • Easy application on Internet connection (Geant) • Policy communication with ( HTTP)

  20. WAN - Architecture

  21. Extension of QoS on Remote side • Check Incoming policy from every member • Autonomy • NO Backbone management (installation …) • Symmetric implementation on outgoing policy • Extension: Automatic Installation of reverse direction SLAs • Between members • Between members andGRNET

  22. Demohttp://linux.noc.ntua.gr/qos

  23. Acknowledgements • Kostas Kalevras • Thanasis Douitsis • Rania labrou

  24. Ευχαριστούμε!!! ? Ερωτήσεις ????

More Related