Μελέτη και υλοποίηση υποδομής SLAs για το Πανευρωπαϊκό δίκτυο GEANT-2

Μελέτη και υλοποίηση υποδομής SLAs για το Πανευρωπαϊκό δίκτυο GEANT-2

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

Service Level AgreementA 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.

A service level agreement would typically contain the following information:

A description of the nature of service to be providedThe expected performance level of the service, specifically its reliability and responsivenessThe procedure for reporting problems with the serviceThe time-frame for response and problem resolutionThe process for monitoring and reporting the service levelThe consequences for the service provider not meeting its obligationsEscape 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

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

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

Delay VariationDescribes the level of disturbance of packet arrival timesComparison to “ideal” pattern

IP Delay Variation Metric (IPDV) (RFC 3393)Delays for equally-sized packetsDelay depends on packet size due to serialization delayCritical 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”)

Round-Trip Time (RTT)A to B one way delays +

B to A one way delays +time for B to respond to A.

Packet LossOne-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

Packet ReorderingCaused by: Alternative routes Router internal parallelism Packet sizeMaximum 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 pathPerformance TCP / STCP applications might have performance impact Real-time media applications experience more serious problems

Packet Reordering, MTU & Performance

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 networksNeed to abstract the data from the type of measurement tools used

through a well define interface. Inter-operability between tools.

Results Requirements

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

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

perfSONAR (Performance focused Service Oriented Network monitoring ARchitecture) systemIs a joint effort of GÉANT2-JRA1, Internet2, and ESnetThe 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 networksName reflects the choice of Service Oriented Architecture

PerfSONAR System

Reasons for Service Oriented Architecture in the middle layer (“Service Layer”):Large task can be split into independent “services”

Can be developed separatelyEasier to maintain afterwards

Services can be added/dropped at runtimeFlexibility of deployment (e.g. NREN may use GEANT

Lookup Service to advertise services)Different implementations possible (e.g. using different

programming languages)

PerfSONAR SystemThe Choice of Service Oriented Architecture

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 SystemServices

BWCTLGENERAL CASE LOCAL BWCTLD

UNAVAILABLE

• 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

BWCTLThroughput Measurement

MetricsThroughput (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)

BWCTLThroughput Measurement

[ 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

BWCTL

BWCTL

BWCTL

OWAMP

• 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

OWAMP

• 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 ImplementationApplications • owampd daemon • owping clientBuilt upon protocol abstraction library • Supports one-off applications • Allows authentication/policy hooks to be incorporated

OWAMP

--- owping statistics from [dhcp-75.netmode.ece.ntua.gr]:59382 to [147.102.13.77]:35770 ---SID: 93660d4dcecb984136ad1d045d58ef75first: 2009-12-10T17:54:42.364last: 2009-12-10T17:54:52.998100 sent, 0 lost (0.000%), 0 duplicatesone-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 reportedno reordering

--- owping statistics from [147.102.13.77]:56641 to [dhcp-75.netmode.ece.ntua.gr]:51684 ---SID: 93660d4bcecb98413cf85be0ccbf222ffirst: 2009-12-10T17:54:42.386last: 2009-12-10T17:54:53.041100 sent, 0 lost (0.000%), 0 duplicatesone-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 reportedno reordering

OWAMP

OWAMP

OWAMP

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

NetMonManager

NetMon 1

NetMon 2

NetMon 3

NetMon 4

NetMon 5

NetMon 6

End Nodes

Implementation

Implementation

Implementation

Implementation