280 likes | 384 Views
Network Resource Scheduling Entity (Part of GRS project) Multi-domain QoS reservation scheduling and QoS signalling. NRSE Re-cap. Team Members. Richard Smith (Coach) Andy Liow Keiko Tada Toshihiro Aiyoshi. Why?. Guarantee Network Capacity Timely data transfer
E N D
Network Resource Scheduling Entity (Part of GRS project) Multi-domain QoS reservation scheduling and QoS signalling
NRSE Re-cap
Team Members • Richard Smith (Coach) • Andy Liow • Keiko Tada • Toshihiro Aiyoshi
Why? • Guarantee Network Capacity • Timely data transfer • Fine-grained QoS control • INTSERV & RSVP problems • DIFFSERV • micro-manage network capacity allocations at the edge of network
Background • GARA (General-purpose Architecture for Reservation and Allocation) • numerous resource reservation • widely used • limitations • GRS (Grid Resource Scheduling) – UCL • NRSE • DIFFSERV EF service, micro management • http://www.cs.ucl.ac.uk/research/grs/
Objectives • Decentralised QoS Reservation • Protected capacity • Specific deadline • DIFFSERV EF – aggregate traffic • Multiple Domain • Across various administrative domains
Objectives (2) • One NRSE per domain • Establish SLS, SLA • End user – NRSE • NRSE – NRSE • Local administrative controls & local policy • Real-time & Non-real-time requests • Flexibility in non-real-time requests
NRSE DEMO
Metaphor - airline booking agent • Passengers specify: • where flying from/to (source and destination IP addresses) • time they want to fly • class of seat (QoS service level). • The agent checks whether there are sufficient seats available and issues tickets. • For non-urgent journeys (non-realtime), the agent may be able to suggest an alternative flight • Agent contacts other agents transparently
Plan for demo • Running the NRSE • Booking a reservation • Reservation management • User authentication • Database internals • Testbed • Multidomain demo
Running the NRSE • Run database (if not already running) • Initialise database • Configure NRSE • Run NRSE
Booking a reservation • Run client • Add reservation • Explain parameters • Explain protocol and XML (see XML document)
XML <sla_user_nrse xmlns = "x-schema:sla_user_nrse-schema.xml"> <!-- Request identification --> <id> <timestamp>2003-05-19-22080000</timestamp> <req_no>1</req_no> <!-- e.g. 32 bit random number --> </id> <!-- Administrative information --> <user_info> <user_name>Andy Liow</user_name> <user_credentials></user_credentials> </user_info>
<!-- Optional. If this is not present, SLA should remain in place until explicitly removed. --> <time_span> <start_time>2003-05-19-0000</start_time> <end_time>2003-05-20-0000</end_time> </time_span> <filter> <src_ipv4>128.16.10.1</src_ipv4> <src_port>1284</src_port> <dst_ipv4>128.16.10.11</dst_ipv4> <dst_port>8080</dst_port> </filter> <!-- Traffic specifications --> <tspec> <!-- All rates in Kbps --> <peak_rate>1000</peak_rate> <token_rate>800</token_rate>
<!-- All rates in bytes --> <bucket_size>2048</bucket_size> <min_policed_unit>48</min_policed_unit> <max_pkt_size>1024</max_pkt_size> </tspec> <!-- Service specifications --> <qos> <quality>premium</quality> <!-- 'premium' = EF, 'low' = LBE --> <policing> <action>drop</action> <!-- For future. "delay" or "remark" possible --> </policing> <direction_mode>bidirectional</direction_mode> <!-- {uni|bi}directional --> <!-- multicast in future --> <flow_type>real_time</flow_type> <!-- {real|non_real}time --> </qos>
<notifications> <!-- Multiple instances of this are possible --> <notification_sink> <dst_ipv4>127.0.0.1</dst_ipv4> <dst_port>4000</dst_port> </notification_sink> <!-- Optional. Number of seconds before reservation start --> <start_notification>1</start_notification> <!-- Optional. Number of seconds before reservation end --> <end_notification>1</end_notification> <notification_flags service_qos_violation = "on" user_qos_violation = "on" abnormal_termination = "on" administrator_intervention = "on"/> </notifications>
Configuration interval = 1000 maxMessageSize = 10000 port = 10288 server = localhost JDBCconnection = jdbc:postgresql://kennedy.cs.ucl.ac.uk/taiyoshi JDBCuser = taiyoshi JDBCpassword = DBMS = PostgreSQL operatingSystem = Linux noOfIface = 2
bandwidth0 = 10000 bandwidth1 = 10000 ifaceName0 = eth0 ifaceName1 = eth0 ifaceDirection0 = in ifaceDirection1 = out ifaceRemote0 = true ifaceRemote1 = true useRemote = true remoteNRSEserver0 = 127.0.0.1 remoteNRSEserver1 = 127.0.0.1 remoteNRSEport0 = 10289 remoteNRSEport1 = 10289
Reservation Management • Run viewer • Add some more reservations • Query reservations • Delete reservations
User Authentication • Add user • Generate keys • Explain Cryptix • Add reservation with key • Add reservation with incorrect key
Database internals • Show reservation added, either graphically, or with psql
Non-realtime reservations • 19 May – 19 June: 7 Mbps • 19 August – 15 September: 6 Mbps • 19 May – 15 September: 5 Mbps • Realtime cannot be allocated… • … but try again with non-realtime
Testbed Explain routing
Multidomain reservation • Show different configurations • On router2 and router3: • Initialise database • Run tc-off • Run NRSE • Run SLSactivator yet • Run Iperf server on client2 • Run Iperf client on client3 (wait 30 secs)
Multidomain reservation (2) • Run GUI on client3 • Make immediate reservation (dest client 2 at 10.5.0.2) • Run SLSactivator on router2 and router3
Results • This is what is should look like….