GRNET - NTUA Scalable, efficient, personalized, end-to-end QoS Provisioning Polyrakis Andreas [email protected] Dimitrios Kalogeras [email protected] 21.03.2002 Contents Motives & Targets Approach LAN Archtiecture WAN Architecture Demo 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 Projects’ Targets «Almost» Automatic QoS Provisioning per User /Application Almost ~ • Atomated Administratevelly • (Semi) automated from user Personalized service Allocation from Administrator User’s request End-to-End (inter-domain) Basic Assumptions Approach LAN – WAN WAN: Architecture Diffserv LAN: Architecture RSVP A Border router (congestion) in LAN Internal LAN Overprovisioned – GigE Congestion on egress of WAN’s POPs Approach LAN problem Authentication Personalization Signaling DiffServ marking of egress traffic Check ingress traffic BEFORE admitting Trust Model Egress - Shengen Model Check on Exit Ingress – Visa Model Check on entrance I.e.: Gold traffic between NTUA UoP Check fron NTUA on Exit Free transit in GRnet Check from UoP on entrance 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 DiffServ Domain Server Server LAN LAN Server Laptop computer Tower PC LAN Approach Modelling Profiles Set of allowed QoS configuration • Assigned (default QoS Policy) • Requested (Rights for QoS Requests) Application of Profiles on Users Policies Logging of requirements Application of Policies on routers Policies + Profiles + Authentication info (+user requests) Implementation of Targets Implementation – Policies QoS Policy – Modular QoS CLI (MQC) Classes – group of traffic with ACLs Action – “priority – Bandwidth” Olympic Metal “Gold, Silver, Bronze” Preconfigured ratio G-S-B Implementation - LDAP Profiles Flow Description , Possible CLasses) Assigned – Requested More conditions Users ε profiles user Profile apolyr apolyr apolyr apolyr kkalev dkalo dkalo dkalo dkalo Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP Req Gold TCP Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP Name LocalIP LocalPort RemoteIP RemotePort Protocol Direction Type Class MaxDayUser MaxDayTot Between Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 all all all all 0.0.0.0/0 147.102.0.0/16 0.0.0.0/0 0.0.0.0/0 all all all all tcp udp all FTP both both both both R R R A Gold Gold Silver Silver 15 15 15 40 60 60 60 180 00:-24:00 07:00-17:00 07:00-17:00 00:-24:00 user Name LocalIP LocalPort RemoteIP RemotePort Protocol apolyr apolyr apolyr apolyr kkalev dkalo dkalo dkalo dkalo Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP Req Gold TCP Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 all all all all all all all all all 0.0.0.0/0 147.102.0.0/16 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 147.102.0.0/16 0.0.0.0/0 0.0.0.0/0 all all all all all all all all all tcp udp all FTP tcp tcp udp all FTP PDP Monitoring & Accounting Direction Type Class both both both both both both user both apolyr both apolyr both R Gold R Gold R Silver A Silver R Gold R Gold Name R Gold Req Gold TCP R Silver Req UDP to ntua A GoldSilver apolyr apolyr kkalev dkalo dkalo dkalo dkalo Req Silver IP Assigned Silver FTP Req Gold TCP Req Gold TCP Req Gold UDP to ntua Req Silver IP Assigned Silver FTP MaxDayUser MaxDayTot Between 15 15 15 40 15 15 15 15 40 60 60 60 180 60 60 60 60 180 00:-24:00 07:00-17:00 07:00-17:00 00:-24:00 00:-24:00 00:-24:00 07:00-17:00 07:00-17:00 00:-24:00 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 Implementation – Policy Server Central Server Policy Decision Point (PDP) Data Base Implemetation - DataBase Authentication Information Registered resources from (IP, Ports) User Profiles from LDAP User’s Request ACL for (MQC) • Furthermore: Statisitics, monitoring data Implementation - PDP Data Combination in DataBase ACLs Creation Uploading ACLs on router Step 1: Database clean up Step 2: monitoring-accounting application. Policy inactivation when daily usage has expired user Class User’s profile Step 3: Revision of acl table expired users ( authenticated resources) expired requests, requests of expired deleted users of policies of deleted users Of policies with class not matching acls Deletion if old rows Rename of old entries to new ones Creation of new rows Step 4: Creation of incoming and outgoing acl Step 5: Upload of acls on TFTP and HTTP server Step6 6: Comand router to download outgoing acl Basic LAN Architecture WAN Approach Extension of QoS Requests on Backbone Installation of incoming policy of every member according to his requirement Configuration of 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) WAN - Architecture UpStream NRN’s Policies LDAP Policies Configuration Commands NRN Directory NRN Policy Server NRN NRN 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 and GRNET Demo http://linux.noc.ntua.gr/qos Acknowledgements Kostas Kalevras Thanasis Douitsis Rania labrou Ευχαριστούμε!!! Ερωτήσεις ????
© Copyright 2026 Paperzz