1. ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ

2. Service Level Agreement A Service Level Agreement (SLA) is a formal definition of the relationship that exists between a service provider and its customer. A SLA can be defined and used in the context of any industry, and is used to specify what the customer could expect from the provider, the obligations of the customer as well as the provider, performance, availability and security objectives of the service, as well as the procedures to be followed to ensure compliance with the SLA. Service level agreements are often used when corporations outsource functions considered outside the scope of their own core competencies to third party service providers.

3. A service level agreement would typically contain the following information: A description of the nature of service to be provided The expected performance level of the service, specifically its reliability and responsiveness The procedure for reporting problems with the service The time-frame for response and problem resolution The process for monitoring and reporting the service level The consequences for the service provider not meeting its obligations Escape clauses and constraints Not all of the components of a SLA may be present in all contracts, but a good SLA would provide an overview of the different items that can go wrong with the provided service, and attempt to cover those situations as part of the SLA agreement. Service Level Agreement

4. One-Way Delay (OWD) Round-Trip Time (RTT) Delay Variation or "Jitter" and RTT Variation Packet Loss – Interfaces error and drops Maximum Transfer Unit (MTU) Path MTU Link Utilization – IP bandwidth utilization and achievable TCP throughput. Network Performance Metrics

5. One – Way Delay per-hop One-Way Delay One-Way Delay per-link delay:per-node delay: propagation delay forwarding delay serialization delay queuing delay additional delays

6. Delay Variation Describes the level of disturbance of packet arrival times Comparison to “ideal” pattern IP Delay Variation Metric (IPDV) (RFC 3393) Delays for equally-sized packets Delay depends on packet size due to serialization delay Critical for real time applications (audio/video) Caused by: Queuing on routers (especially on CPU-based router architectures) Collision avoidance (shared Ethernet) Link-level retransmission (802.11 wireless LANs) Delay Variation (“Jitter”)

7. Round-Trip Time (RTT) A to B one way delays + B to A one way delays + time for B to respond to A. Packet Loss One-way Packet Loss Metric for IPPM (RFC 2680) Caused by: Congestion : severe congestion overflows queues and leads to packet drops (gradually or burst). Errors: corruption, packets modified in-transit (noisy lines etc.), checksum failure on receiving end. Round-Trip Time & PacketLoss

8. Packet Reordering Caused by: Alternative routes Router internal parallelism Packet size Maximum Transfer Unit (MTU) Common MTUs: 1500 bytes (Ethernet, 802.11 WLAN) 4470 bytes (FDDI, common default for POS and serial links) 9000 bytes (Internet2 and GÉANT convention, limit of some Gigabit Ethernet adapters) 9180 bytes (ATM, SMDS) Path MTU The MTU supported by a path The minimum of MTUs of links along the path Performance TCP / STCP applications might have performance impact Real-time media applications experience more serious problems Packet Reordering, MTU & Performance

9. Be able to monitor the services deployed IPv4/IPv6. Multicast/unicast. IP QoS. VPN/point-to-point connections. Emulate behavior close from the one from the application used. Different tools used within each networks Need to abstract the data from the type of measurement tools used through a well define interface. Inter-operability between tools. Results Requirements

10. Traceroute-like Tools : traceroute, MTR, PingPlotter, lft, tracepath, traceproto Bandwidth Measurement Tools : pchar, Iperf, bwctl, Netperf, RUDE/CRUDE, ttcp, NDT, DSL Reports Active Measurement Boxes : DFN/GEANT2 HADES (formerly IPPM) RIPE TTM RENATER QoSMetrics Passive Measurement Tools : SNMP Device Polling: MRTG, Cricket NetFlow-based: flow-tools etc. Packet Capture and Analysis Tools: tcpdump, Wireshark/Ethereal, jnettop Measurement Tools

11. OWD, OWPL, IPDV, traceroute –DFN IPPM IPv4, IPv6, IP QoS, on-demand. But also RIPE TTM for IPv4 and IPv6. http://www-win.rrze.uni-erlangen.de/ippm/ TCP/UDP throughput –I2 BWCTL/iperf IPv4, IPv6, on-demand. http://abilene.internet2.edu/observatory/data-views.html IP link utilization, link capacity, interface errors, interface drops – from existing DB. IPv4, IPv6, (multicast?) On-demand. Netflow –under investigation IPv4, IPv6. Info (working document): http://monstera.man.poznan.pl/wiki/index.php/JRA1_D3.4_Flow_Monitoring Packet capture tools – HW: 10Gbps DAG cards, SW: Scampi framework. Info (working document): http://monstera.man.poznan.pl/wiki/index.php/Passive FYI: Global Performance Measurement Points directory Info: http://e2epi.internet2.edu/pipes/pmp/pmp-dir.html Measurement Tools

13. perfSONAR (Performance focused Service Oriented Network monitoring ARchitecture) system Is a joint effort of GÉANT2-JRA1, Internet2, and ESnet The solution is deployed and further elaborated in European Research Backbone Géant Connected European National Research and Education Networks Internet2’s Abilene network ESnet (Energy Sciences network in US) RNP (Brasilian NREN) Open source development also for other interested networks Name reflects the choice of Service Oriented Architecture PerfSONAR System

14. Reasons for Service Oriented Architecture in the middle layer (“Service Layer”): Large task can be split into independent “services” Can be developed separately Easier to maintain afterwards Services can be added/dropped at runtime Flexibility of deployment (e.g. NREN may use GEANT Lookup Service to advertise services) Different implementations possible (e.g. using different programming languages) PerfSONAR System The Choice of Service Oriented Architecture

15. Measurement Point Service (MP) Measurement Archive Service (MA) Lookup Service Allows the client to discover the existing services and other LSservices. Dynamic: services registration themselves to the LS and mention their capabilities, they can also leave or be removed if a service gets down. Authentication Service (GN2-JRA5) Authentication functionality for the framework Users can have several role, the authorisation is done based on the user roles. Trust relationship between networks Transformation Service Transform the data (aggregation, concatenation, correlation, translation, etc). Topology Service Make the network topology information available to the framework. Find the closest MP, provide topology information for visualisation tools Resource protection Service Arbitrate the consumption of limited resources PerfSONAR System Services

17. GENERAL CASELOCAL BWCTLD UNAVAILABLE

18. What Is It? A resource allocation and scheduling daemon for arbitration of iperf tests Bwctl controls the throughput tests by adding resource allocation and scheduling policy controls. Problem Statement Users want to verify available bandwidth from their site to another. Methodology: Verify available bandwidth from each endpoint to points in the middle to determine problem area. Implementation Applications bwctld daemon bwctl client Built upon protocol abstraction library Supports one-off applications Allows authentication/policy hooks to be incorporated

19. Metrics Throughput (Mbps) Parameters "interval" the report interval (bwctl option -i) "protocol" either udp or tcp, default is tcp (bwctl option -u for udp) "bufferSize" size of read/write buffer (bwctl option -l) "windowSize" size of tcp window / udp socket receive buffer (bwctl option -w) "duration" duration of test, default is 10 seconds (bwctl option -t) "bandwidth" limits udp send rate (bwctl option -b) "ToS" specifies ToS bit (bwctl option -S) "login" if authentication is needed. "password" dito Methods On-demand testing with php-based BWCTL-client (web-GUI) BWCTL Throughput Measurement

20. [ 15] local 147.102.13.77 port 5001 connected with 147.102.13.75 port 5001 [ ID] Interval Transfer Bandwidth [ 15] 0.0-10.0 sec 116957184 Bytes 93343208 bits/sec [ 15] MSS size 1448 bytes (MTU 1500 bytes, ethernet) bwctl: stop_exec: 3469448542.020009 [ 5] local 147.102.13.75 port 5001 connected with 147.102.13.77 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 116957184 Bytes 93538771 bits/sec [ 5] MSS size 1448 bytes (MTU 1500 bytes, ethernet) bwctl: stop_exec: 3469448541.018142

24. What Is It? OWD or One-Way PING A control protocol A test protocol A sample implementation of both Why the OWAMP protocol? Find problems in the network Congestion usually happens in one direction first… Routing (asymmetric, or just changes) SNMP polling intervals mask high queue levels that active probes can show There have been many implementations to do One-Way delay over the years (Surveyor, Ripe…) The problem has been interoperability. http://www.ietf.org/internet-drafts/draft-ietf-ippmowdp-014.txt

25. OWAMP Control protocol Supports authentication and authorization Used to configure tests Endpoint controlled port numbers Extremely configurable send schedule Configurable packet sizes Used to start/stop tests Used to retrieve results Provisions for dealing with partial session results OWAMP Test protocol Packets can be “open”, “authenticated”, or “encrypted” Sample Implementation Applications owampd daemon owping client Built upon protocol abstraction library Supports one-off applications Allows authentication/policy hooks to be incorporated

26. --- owping statistics from [dhcp-75.netmode.ece.ntua.gr]:59382 to [147.102.13.77]:35770 --- SID: 93660d4dcecb984136ad1d045d58ef75 first: 2009-12-10T17:54:42.364 last: 2009-12-10T17:54:52.998 100 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = -1.31/-1.2/-0.642 ms, (err=2.86 ms) one-way jitter = 0.1 ms (P95-P50) TTL not reported no reordering --- owping statistics from [147.102.13.77]:56641 to [dhcp-75.netmode.ece.ntua.gr]:51684 --- SID: 93660d4bcecb98413cf85be0ccbf222f first: 2009-12-10T17:54:42.386 last: 2009-12-10T17:54:53.041 100 sent, 0 lost (0.000%), 0 duplicates one-way delay min/median/max = 1.72/2.1/13.9 ms, (err=2.86 ms) one-way jitter = 6.3 ms (P95-P50) TTL not reported no reordering

29. Set Up of BWCTL and OWAMP daemons (bwctld and owampd) that run constantly in the background listening and accepting incoming measurement connections Scheduling with cron to conduct measurements using owping and bwctl to a specific target host every 5 minutes Measurement data are collected and stored in a RRD DataBase and in a MySQL DataBase Using Apache Tomcat a Graphical user is provided that exhibits the latest current measurement results and the ability to dynamically select the measurement date is offered We utilize the behavior prediction algorithm of RRDTool to predict future measurement behavior and to ensure SLA conformance Implementation