Embed Size (px)
Citation preview
MONIPÊ SERVICE ENABLING PERFSONAR DEPLOYMENT
IN BRAZILIAN CUSTOMER SITES THROUGH THE USE OF
LOW-COST DEVICES AND VIRTUAL ENVIRONMENT TO
SUPPORT MONITORING OF LAST MILE CONNECTIVITY Iara Machado
1, Fausto Vetter
1, Alex Moura
1, Michael Stanton
1,4, Edison Tadeu Lopes Melo
2,
Guilherme Eliseu Rhoden 3, Murilo Vetter
3, Rodrigo Pescador
3, Paulo Brandtner
3, Luis Cordeiro
3
1 Rede Nacional de Ensino e Pesquisa (RNP)
Rua Lauro Müller, 116 sala 1103
22290-906 – Botafogo – Rio de Janeiro – RJ – Brasil
Phone Number: +55 21 2102-9660
{iara, fausto.vetter, alex, michael}@rnp.br
2 Universidade Federal de Santa Catarina (UFSC)
SeTIC – Campus Universitário – Trindade
Caixa Postal 476 – 88.040-900 – Florianópolis – SC – Brasil
3 Ponto de Presença da RNP em Santa Catarina (PoP-SC)
SeTIC – Campus Universitário – Trindade
Caixa Postal 476 – 88.040-900 – Florianópolis – SC – Brasil
{rhoden, murilo, pescador, paulo, luis}@pop-sc.rnp.br
4 On secondment from Computing Institute,
Universidade Federal Fluminense (UFF)
Paper type Technical paper
Abstract MonIPÊ is a network performance measurement service developed by RNP (Rede Nacional de Ensino e
Pesquisa), the Brazilian Research and Education Network (NREN). This service uses the perfSONAR protocol
and the same measurement tools used by similar initiatives from other academic networks around the world, such
as Internet2, ESnet and GÉANT. The service has been developed since 2002, mainly focusing on measuring the
links of the backbone. In 2013, intending to expand the reachability of the service towards clients, the MonIPÊ
service has been revised to improve the service architecture to enable such goal. The main results include the
development of a measurement portal and a low cost, small form-factor measurement kit, besides the usage of
virtual environment to enable measurements. This paper presents an historical view of the service,
contextualising the reader with the efforts made by RNP. This is followed by the presentation of the main results
obtained in the MonIPÊ revision. Next, RIPE Atlas, a similar service, is presented and both services are
compared. The main focus of this paper follows, presenting the pilot done to evaluate the MonIPÊ service
proposed, focusing on implementation, measurement results and users feedback. The paper finishes observing
about future work and acknowledgements.
Keywords perfSONAR, MonIPÊ, Miniature Computing, Rasberry Pi, CuBox, Computer Networks, Performance
Monitoring
1. Introduction
RNP (Rede Nacional de Ensino e Pesquisa) (RNP, 2013), the Brazilian NREN (Stanton, et al., 2010), supports
quality of service and measurement endeavours since 2002, when the first research and development working
group was established to study and develop an infrastructure to deliver passive flow measurements for its
backbone network (RNP, 2002). In 2003, these efforts included active measurements and studies with passive
capture cards (RNP, 2003).
The first prototype of a measurement infrastructure was developed in 2004, delivering piPEs-BR and nSLA, the
latter being an environment to monitor Service Level Agreements (SLAs) (RNP, 2004). Between 2005 and 2007,
this environment was made compatible with perfSONAR (ESNet, et al., 2013), an emerging protocol defined by
NRENs around the world to enable the performance monitoring data sharing. The main components developed
were the Command Line Measurement Point (CL-MP), Internet Computer Network Eye (ICE) and CactiSONAR
(RNP, 2005), which were piloted in few Points of Presence (PoPs) of RNP network and for the EELA project.
Following these developments, between 2008 and 2009, RNP deployed the monitoring service experimentally, to
improve the evaluation of the solution developed and ensure the service would meet the users’ needs. Finally,
between 2010 and 2012, the service was deployed in all PoPs of RNP and became a production service (RNP,
2014). The delivered service enabled the monitoring of the backbone links. The service was composed of a
measurement portal and several latency and achievable bandwidth Measurement Points (MPs). The infrastructure
deployed in the PoPs consisted of two servers and a GPS antenna for clock synchronisation.
With the aim of extending the service to reach the last mile of the connectivity to RNP customers, the MonIPÊ
service was revised in 2013 to ensure that performance measurements could reach the customers connecting to
the backbone (RNP, 2013). The main intention was to reduce the burden of deployment, reduce the investment
cost of the necessary infrastructure to deliver the service, and improve the user experience of the service. This
paper presents details of the results achieved since 2013.
2. MonIPÊ Service: Extending to the customer site
The customer sites connecting to the RNP backbone were the main focus of the MonIPÊ project in 2013. The
main objective was to enable them to deploy their own measurement infrastructure to measure their connection
to the closest PoP of the RNP backbone and perceive the quality of the service delivered to them through the
usage of network metrics. The main results of the development efforts were:
A low cost, low power consumption, small form-factor measurement kit, illustrated in Figure 1,
composed of a latency MP built using the credit-card-sized single-board computer Raspberry Pi
(Raspberry Pi Foundation, 2013), a low cost GPS antenna from Adafruit (Adafruit Industries, 2013)
and an achievable bandwidth MP built using a mini desktop provided by SolidRun known as CuBox
(SolidRun, 2013);
The homologation of MPs to run in a virtual environment;
The evaluation of 10 Gbps enabled MPs, and
A new user interface to control and display the results of the measurements being done using the
service.
Figure 1 Low Cost Measurement Kit.
The new user interface, seen below in Fig. 2, is called “perfSONAR Measurement Portal”. This interface is a
web-based portal that allows the user to navigate through different portals in different domains, trigger on-
demand tests, retrieve results of stored on-demand tests, and retrieve data from archived regular tests.
Figure 2 perfSONAR Measurement Portal.
The monitoring tools developed and used in the MonIPÊ service are compatible with similar developments
carried out jointly by Internet2 (Internet2, 2013) and ESnet (ESnet, 2013), and by GÉANT (GÉANT, 2013),
respectively known as perfSONAR-PS (Internet2; ESnet; SLAC; FNAL; University of Delaware; Pittsburgh
Supercomputing Center, 2013) and perfSONAR MDM (GÉANT, 2013).
Based on the results achieved, in 2013 the MonIPÊ service was revised and restructured to expand its coverage
and make the performance service available to its customers. It is expected that access to this service will enable
users to run measurement tests in different scenarios:
International: from 1G and 10G enabled MPs to other NRENs;
Backbone: between different PoPs, and
Customer site: from the closest PoP to the customer campus.
Measurements can be scheduled using the service in different manners:
On-demand: solicited through a user request for network diagnostics and investigation;
Periodic: scheduled and stored for a specific amount of time ideal for specific evaluations and periodic
diagnostics, and
Permanent: scheduled and stored for long term enabling a proactive performance measurement
approach.
The scheduling mechanisms allowed by the service include:
Point-to-Point: allows measurements from the default MP of the Measurement Portal to any other MP;
Point-to-Multipoint: allows measurements from the default MP of the Measurement Portal to a defined
set of other MPs, and
Multipoint-to-Multipoint: allows measurements in matrix using a defined group of MPs.
The main metrics delivered by the service are:
Packet loss;
One-way delay;
Round trip time;
TCP achievable bandwidth, and
UDP bandwidth.
The technical architecture of the MonIPÊ service is structured in different levels:
International: 10G enabled MPs;
Backbone: measurements portal, information services (perfSONAR Lookup Service), virtual MPs and
some 10G enabled MPs located at the PoPs, and
Customer site: low cost measurement kit.
3. RIPE Atlas
The MonIPÊ service, as proposed, is similar to another service proposed by the RIPE Network Coordination
Centre (NCC, 2014), known as RIPE Atlas (NCC, 2014). The main objective of RIPE Atlas, according to their
website, is to build an Internet measurement network employing a global network of probes that measure Internet
connectivity and reachability, providing understanding of the state of the Internet in real time.
RIPE Atlas goals are (NCC, 2014): provide users active measurements to baseline their network; enable on-
demand individual measurements to vantage points; produce Internet traffic maps and usage of other data by the
technical community; and act as a trusted source of data regarding real-life, active measurements.
The main concepts of the RIPE Atlas service (NCC, 2014) are:
User: anyone accessing RIPE Atlas maps and statistics;
Host: anyone connecting a probe to their home (or other) network, and
Sponsor: an individual or organisation providing financial support for a number of probes.
The technical infrastructure of the RIPE Atlas service is composed of (NCC, 2014):
Anchor: an enhanced RIPE Atlas probe with more measurement capacity, besides being a regional
measurement target within the greater RIPE Atlas network, and
Probe: a tiny hardware device that runs measurements in the RIPE Atlas system and reports these
measurements to the data collection components.
The metrics provided by the RIPE Atlas service are (NCC, 2014):
Probe network configuration information;
Current, total and history probe uptime;
Round trip time measurements (on IPv4) to the first and second hops;
Ping measurements to a number of predetermined destinations;
Traceroute measurements to a number of predetermined destinations;
DNS queries to root DNS servers, and
SSL queries to a number of predetermined destinations.
4. MonIPÊ and RIPE Atlas Comparison
Both MonIPÊ and RIPE Atlas services are similar in the set of components used by each service and in how both
services are offered. The main difference is in the set of metrics each service delivers. MonIPÊ requires precise
clock information to deliver the set of metrics offered by the service, due to the inclusion of one-way delay,
while RIPE Atlas does not have this requirement. This makes RIPE Atlas simpler to deploy in the end user site.
In spite of this, the MonIPÊ service ends up delivering a more complete view of the network performance to the
end user, as it includes more network-centred metrics. Table 1 presents a high level comparison of the MonIPÊ
and RIPE Atlas service.
MonIPÊ Service RIPE Atlas
Focus Network Performance
Measurements
Active Measurements
Main Components Information services and
Measurement Points
Anchors and Probes
Service Use Cases International, Backbone and
Customer sites
User, Host and Sponsor
Service Sponsor RNP RIPE NCC
Metrics Packet loss
One-way delay
Round trip time
TCP achievable
bandwidth
UDP bandwidth
Configuration information
Uptime
Round trip time
Traceroute
DNS query
SSL query
Scheduling On-demand, Periodic and
Permanent
Point-to-Point, Point-to-
Multipoint and
Multipoint-to-Multipoint
Predefined measurements
User defined
measurements
Programmatic Interface perfSONAR NMWG RIPE Atlas REST API
Table 1 Comparison of MonIPÊ and RIPE Atlas services.
MonIPÊ and RIPE Atlas services are very similar in infrastructure and could be used complementarily. The main
difference between the services is their focus: MonIPÊ is a service for measuring network performance, while
the RIPE Atlas service offers fewer performance measurements but enables measurement of Internet
connectivity and reachability.
5. MonIPÊ Service Infrastructure
The MonIPÊ service focus on the end customer was evaluated in a pilot. This pilot phase was preceded by an
evaluation phase, carried out in a laboratory environment, to define the final components needed. This allowed
the definition of a service infrastructure: RNP, PoP and Customer site, as seen in Figure 3.
Figure 3 Service infrastructure.
At the RNP level, two virtual servers are employed, each used respectively for the RNP Measurement Portal and
a perfSONAR Measurement Archive (MA). The MA deployed at the RNP level is used to store measurements
scheduled between PoPs.
The components employed at the PoP level are two virtual servers, one for a MA and one for a MP, and a
measurement portal for the PoP. To ensure the high precision of the measurements performed at the PoP,
existing GPS antennas deployed in all RNP PoPs are used. Virtualisation is enabled thanks to the ability to use
the physical serial port of the virtual servers to synchronise the clock. These virtual servers are connected to two
dedicated network interfaces for delay and throughput measurements.
The kit hardware, as mentioned previously, is composed by low cost, small-form factor PCs: CuBox, a
Raspberry Pi and an Adafruit GPS antenna. The kit is used to attend the customer site level of the service
infrastructure. The main reasons to select each component were:
CuBox: possesses a 1 Gbps network interface, enabling the measurement of achievable bandwidth. In
practice, this hardware only reaches about 500 Mbps, as evaluated in the laboratory. These rates were
considered adequate for most RNP customers;
Raspberry Pi: this hardware includes a serial port enabling connectivity to the GPS Antenna, and
Adafruit GPS Antenna: this antenna allows the provisioning of the pulse per second (PPS) signal,
enabling high precision one way delay measurements.
6. MonIPÊ Service Pilot
After the evaluation of the components and the definition of the service infrastructure, the pilot MonIPÊ service
presented in this paper was deployed in a few customer sites connected to two RNP PoPs. The PoPs have
deployed a PoP MP, while the customer sites have deployed the low cost measurement kits built and provided by
the MonIPÊ project. The 10 Gbps capable MP was not part of this first pilot.
6.1 Pilot Participants
Table 2 presents the participants in the pilot:
Participant Connecting PoP Bandwidth
Point of Presence of RNP in Minas Gerais (PoP-MG) 10 Gbps
Instituto de Desenvolvimento Sustentável Mamirauá PoP-MG 8 Mbps1
Universidade Federal de Viçosa (UFV) PoP-MG 310 Mbps
Point of Presence of RNP in Santa Catarina (PoP-SC) 10 Gbps
Instituto Federal Catarinense (IFC) - Videira PoP-SC 4 Mbps
(Upgrading to 20 Mbps)
Laboratório de Camarões Marinhos (LCM) –
Universidade Federal de Santa Catarina (UFSC)
PoP-SC 10 Mbps
Table 2 Measurement Pilot Participants.
Figure 4 presents a map containing the PoPs (green markings) and the customer sites (red markings) that
participated in the pilot:
1 The connection is a geostationary satellite link with very high latency.
Figure 4 Pilot Participants Map.
6.2 Pilot Implementation
The pilot was carried out between October and December 2013. The first action was a kick-off meeting to
present the pilot to the participating teams. The main goals of the pilot were: deploy the infrastructure; schedule
permanent tests between PoPs and between each PoP and its directly connected customer sites; and allow on-
demand test execution using the infrastructure.
After the kick-off meeting, PoPs and customer sites have received the equipment to be physically installed in
their premises, as oriented by the project support team. Figure 5 shows the infrastructure deployed for the pilot:
Figure 5 Pilot Infrastructure.
Figure 6, Figure 7, Figure 8 and Figure 9 present one deployment example in IFC Videira.
Figure 6 Adafruit GPS Antenna installed in IFC Videira.
MonIPÊ Pilot
MP PoP
GPS
MP PoP
GPS
Delay(Raspberry PI)
Bandwidth(Cubox)
GPS(Adafruit
)
UFV
Delay(Raspberry PI)
Bandwidth(Cubox)
GPS(Adafruit
)
Mamirauá IFC-Videira
Delay(Raspberry PI)
Bandwidth(Cubox)
GPS(Adafruit
)
LCM
Delay(Raspberry PI)
Bandwidth(Cubox)
GPS(Adafruit
)
PoP-MG PoP-SC
IPÊ Network
BackboneScenario
CustomerSite
Scenario
CustomerSite
Scenario
On Demand Tests
Figure 7 Low Cost Measurement Kit (CuBox, SSD Disk and Raspberry Pi) installed in IFC Videira.
Figure 8 Raspberry Pi component installed in IFC Videira.
Figure 9 CuBox component installed in IFC Videira.
6.3 Pilot Evaluation Criteria
The pilot was evaluated against the following criteria:
deployment of the low cost measurement kits carried out by the customer sites following the guidance
of the development team;
the developed solution attends the proposed scenarios;
the scheduled measurements executed accordingly, and
proper clock synchronisation for the delay MPs.
Due to time constraints, the MPs located in each PoP were not tuned for best performance between them, as this
would require a considerable investment of time, which was instead spent on fixing bugs in the software
developed.
6.4 Pilot Measurement Plans
The scheduling plan defined for the pilot was defined as presented in Table 3.
RNP Portal
Metric TCP Achievable
Bandwidth
One-way Delay Round trip Time
Scheduling Mechanism Multipoint-to-Multipoint Multipoint-to-Multipoint Multipoint-to-Multipoint
Frequency 60 minutes Continuous 5 minutes
Test Methodology 10 Seconds per Test 10 Packets per Second 10 Packets per Test
Scenario Backbone Backbone Backbone
Sites PoP-MG; PoP-SC PoP-MG; PoP-SC PoP-MG; PoP-SC
PoP-SC Portal
Metric TCP Achievable
Bandwidth
One-way Delay Round trip Time
Scheduling Mechanism Point-to-Point Point-to-Point Point-to-Point
Frequency 60 minutes Continuous 5 minutes
Test Methodology 10 Seconds per Test 10 Packets per Second 10 Packets per Test
Scenario Customer site Customer site Customer site
Sites PoP-SC; Videira; UFSC PoP-SC; Videira; UFSC PoP-SC; Videira; UFSC
PoP-MG Portal
Metric TCP Achievable
Bandwidth
One-way Delay Round trip Time
Scheduling Mechanism Point-to-Point Point-to-Multipoint Point-to-Multipoint
Frequency 60 minutes Continuous 5 minutes
Test Methodology 10 Seconds per Test 10 Packets per Second 10 Packets per Test
Scenario Customer site Customer site Customer site
Sites PoP-MG; Mamirauá;
UFV
PoP-MG; Mamirauá;
UFV
PoP-MG; Mamirauá;
UFV
Table 3 Pilot Measurement Schedule Plan.
Pilot users were encouraged to use the MonIPÊ service to run on-demand tests between the pilot MPs to evaluate
the usability of the Measurement Portal developed.
6.5 Pilot Results
The main results of the pilot were:
The solution developed was deployed as planned in all participants involved in the pilot, with the
exception of LCM-UFSC, as the low-cost measurement kit allocated there was used for improvement of
the software developed;
UFSC has installed the developed software in a notebook allocated to the project, which was used for
testing between the Florianópolis campus and PoP-SC;
There were some problems in:
o UFV:
the Raspberry Pi was damaged during transport to the customer site, but the local
team managed to glue the broken component and the kit is working properly;
the SSD memory failed and was replaced by an USB stick lent by the customer site.
o Mamirauá:
There were software bugs preventing proper configuration of the measurement points.
This was repaired by updating the measurement portal software stack.
o IFC Videira:
The Operating System (OS) image running from the SD flash card located in the
Raspberry Pi became corrupted and was replaced by the support team of the project.
Given the short period of the pilot, the results are very preliminary and more measurements are needed
to guarantee proper functioning of the low cost measurement kit for a longer period. In spite of this, the
results are considered appropriate for measuring the connectivity of the customer directly connected to
the Ipê network.
During the pilot, the backbone and customer site scenarios have been validated, while the international scenario
was postponed for future evaluations.
6.6 Pilot Measurement Results
Some measurement results obtained during the pilot are presented below.
6.6.1 Backbone Scenario
To evaluate the Backbone Scenario, measurements were scheduled between PoP-SC and PoP-MG in the RNP
Portal, according to the Pilot Measurement Plan presented in Table 3. The graphs below presents measurement
results as follows:
a) Scheduled TCP achievable bandwidth measurements every hour in both directions:
TCP Achievable Bandwidth from PoP-SC to PoP-MG:
TCP Achievable Bandwidth from PoP-MG to PoP-SC:
b) Scheduled continuous one-way delay measurements in both directions:
One-way Delay from PoP-SC to PoP-MG:
One-way Delay from PoP-MG to PoP-SC:
c) Scheduled round trip time measurements every 5 minutes in both directions:
Round trip Time from PoP-SC to PoP-MG:
Round trip Time from PoP-MG to PoP-SC:
6.6.2 Customer site Scenario
To evaluate the Customer site Scenario, measurements were scheduled between the participating PoPs and the
selected customers, according the Pilot Measurement Plan presented in Table 3. The graphs below presents
measurement results as follows:
a) Scheduled TCP achievable bandwidth measurements every hour in both directions between PoP-SC and
IFC Videira:
TCP Achievable Bandwidth from PoP-SC to IFC Videira:
TCP Achievable Bandwidth from IFC Videira to PoP-SC:
b) Scheduled TCP achievable bandwidth measurements every hour in both directions between PoP-
MG and UFV:
TCP Achievable Bandwidth from PoP-MG to UFV:
TCP Achievable Bandwidth from UFV to PoP-MG:
c) Scheduled TCP achievable bandwidth measurements every hour in both directions between PoP-
MG and Mamirauá:
TCP Achievable Bandwidth from PoP-MG to Mamirauá:
TCP Achievable Bandwidth from Mamirauá to PoP-MG:
d) Scheduled continuous one-way delay measurements in both directions between PoP-MG and
UFV:
One-way Delay from PoP-MG to UFV:
One-way Delay from UFV to PoP-MG:
e) Scheduled round trip time measurements every 5 minutes in both directions between PoP-MG
and Mamirauá:
Round trip Time from PoP-MG to Mamirauá:
Round trip Time from Mamirauá to PoP-MG:
6.6.3 On Demand Measurements
Besides the permanent measurements scheduled during the pilot, some users were requested to perform on-
demand tests to evaluate the service functionalities. Some results are presented below.
One-way Delay from PoP-SC to IFC Videira:
The measurement below was requested by a pilot user from PoP-SC to IFC Videira to measure one-way
delay using the one-way delay summary view. This view permits a statistical analysis of the delay
between both measurement points. The measurement requested used a bucket width of 0,001 seconds (1
millisecond) to categorise the packet count for each single packet and was requested using 2000 packets.
TCP Achievable Bandwidth from PoP-SC to IFC Videira:
The measurement below was requested by a pilot user from PoP-SC to IFC Videira to measure TCP
achievable bandwidth. The requested measurement presents the receiving and sending measurement
results, using TCP protocol, considering an interval of 1 second for reporting statistics and during 600
seconds.
Round trip Time from Mamirauá to IFC Videira:
The measurement below was requested by a pilot user from Mamirauá to IFC Videira to measure round
trip time. The requested measurement presents delay measurement every millisecond for 100 packets.
6.7 Pilot Conclusions and Lessons Learnt
The main conclusions and lessons learnt after running the pilot were:
All components must be sent to the customer in proper packing to avoid damage to the hardware during
transport, preferably not attaching even small components;
Data loss observed in the graphs must be investigated, as it might be caused by: development issues in
the perfSONAR framework, MA or MP services or the Measurement Portal software, or hardware or
operating system resources;
A monitoring infrastructure for the service components is required before the service can enter into
production;
The main focus of the pilot was to validate the measurement functionality and execution, and bug-fixing
of components;
Customisation of the measurement environment is still required to improve the quality of the
measurements, because the time frame of the pilot was insufficient to permit fine tuning of the
measurements to achieve optimal results, and
In general, the pilot results were considered remarkable, as most of the issues found during the pilot
were problems of real world environments and the only way to evaluate the service properly was to run
the pilot in such conditions.
6.8 Pilot Users Feedback
After the pilot was finished, an interview was carried out with some of the users to gather their feedback about
the pilot. One representative of each team was interviewed and the main results were:
All interviewees considered the service highly relevant to their sites;
The metric considered most relevant was TCP achievable bandwidth;
The measurement scheduling considered most relevant was on-demand, mainly because most users are
not used to analysing these metrics in a regular fashion;
Some new features requested by the users include:
o Scheduling of tests between sites;
o Support for the traceroute tool;
o Support for measurements of link availability, and
o Support for SNMP interface counters.
The main user feedback was about the following topics:
o Deployment process:
Considered simple, even though some hardware and software issues were identified
during the process;
Deployment and configuration documentation provided by the project was considered
adequate;
Suggestions for improvement of the deployment process, the low-cost measurement
kit and the software developed, and
The participants considered virtualisation as a possible deployment distribution to be
used in their environment.
o Service Experience:
More explanation is needed to enable proper use of the service by its users;
The interface was considered intuitive and easy to use;
A monitoring infrastructure is required to ensure availability of all components, and
Training and usage guides are required to disseminate the service.
o Usage of the service by the customer sites:
Point-to-point measurements between their sites;
Integration of the service metrics into the customer’s monitoring portal;
Expansion of the customer site level to include other sites of the same customer, and
Usage of the service by the technical staff to investigate and troubleshoot problems.
o General comments about the MonIPÊ service:
The customers considered well-structured the mechanism to execute measurements
using the MonIPÊ service, as previously they either were not used to execute or they
were executed on ad-hoc basis;
The customer sites were already considering using the metrics provided by the
service;
Performance issues are end-to-end, between sites and/or organisations, and
The usability of the service is impacted by the little customer staff knowledge about
network performance.
7. Future Work
Following these results, the roadmap includes improvements in the measurements portal interface to support new
tools such as traceroute and Network Diagnostics Tester (NDT). Besides that, there is an effort underway to
build a new low-cost measurement point to run both delay and achievable bandwidth tests on the same device,
using separate network interfaces. In terms of deployment, planning includes the migration to a virtualized
environment at PoPs, the deployment of some 10G enabled MPs at selected PoPs and on international
connections and the spread of a higher number of low cost measurement kits to attend metro and campus
networks of research and education organisations throughout Brazil.
Acknowledgements
The authors of this paper would like to thank the RNP Point of Presence in Santa Catarina (PoP-SC) for support
in the development of the components of the MonIPÊ Service. Furthermore, the authors would also like to thank
the organisations participating in the pilot phase and their staff, here named: RNP Point of Presence in Minas
Gerais (PoP-MG), Instituto de Desenvolvimento Sustentável Mamirauá, Universidade Federal de Viçosa (UFV),
RNP Point of Presence in Santa Catarina (PoP-SC), Instituto Federal Catarinense (IFC) – Videira and
Laboratório de Camarões Marinhos (LCM) – Universidade Federal de Santa Catarina (UFSC).
References
Adafruit Industries, 2013. GPS Antenna. [Online]
Available at: http://www.adafruit.com/products/960
[Accessed 2013].
ESNet; GÉANT; Internet2; RNP, 2013. perfSONAR. [Online]
Available at: http://www.perfsonar.net/
[Accessed 2013].
ESnet, 2013. Energy Sciences Network. [Online]
Available at: http://www.es.net/
[Accessed 2013].
GÉANT, 2013. GÉANT Project. [Online]
Available at: http://www.geant.net/
[Accessed 2013].
GÉANT, 2013. perfSONAR: GÉANT Services. [Online]
Available at: http://perfsonar.geant.net/
[Accessed 2013].
Internet2; ESnet; SLAC; FNAL; University of Delaware; Pittsburgh Supercomputing Center, 2013. perfSONAR-
PS | network performance monitoring services. [Online]
Available at: http://psps.perfsonar.net/
[Accessed 2013].
Internet2, 2013. Internet2. [Online]
Available at: http://www.internet2.edu/
[Accessed 2013].
NCC, R., 2014. Frequently Asked Questions (FAQ) - RIPE Atlas - RIPE Network Coordination Centre. [Online]
Available at: https://atlas.ripe.net/about/faq/
[Accessed 2014].
NCC, R., 2014. RIPE Atlas - RIPE Network Coordination Centre. [Online]
Available at: https://atlas.ripe.net/
[Accessed 2014].
NCC, R., 2014. RIPE Network Coordination Centre. [Online]
Available at: https://www.ripe.net/
[Accessed 2014].
NCC, R., 2014. What is RIPE Atlas? - RIPE Atlas - RIPE Network Coordination Centre. [Online]
Available at: https://atlas.ripe.net/about/
[Accessed 2014].
Raspberry Pi Foundation, 2013. Raspberry Pi Website. [Online]
Available at: http://www.raspberrypi.org/
[Accessed 2013].
RNP, 2002. GT-QoS. [Online]
Available at: http://www.rnp.br/pd/gts2002-2003/gt-qos.html
[Accessed 2013].
RNP, 2003. GT-QoS2. [Online]
Available at: http://www.rnp.br/pd/gts2003-2004/gt-qos2.html
[Accessed 2013].
RNP, 2004. GT Medições. [Online]
Available at: http://www.rnp.br/pd/gts2004-2005/medicoes.html
[Accessed 2013].
RNP, 2005. GT Medições 2. [Online]
Available at: http://www.rnp.br/pd/gts2005-2006/medicoes.html
[Accessed 2013].
RNP, 2013. MonIPÊ. [Online]
Available at: http://wiki.rnp.br/display/monipe2013/Home
[Accessed 2013].
RNP, 2013. Rede Nacional de Ensino e Pesquisa. [Online]
Available at: http://www.rnp.br/
[Accessed 2013].
RNP, 2014. Wiki - MonIPÊ. [Online]
Available at: http://wiki.monipe.rnp.br/
[Accessed 2014].
SolidRun, 2013. CuBox. [Online]
Available at: http://www.solid-run.com/cubox
[Accessed 2013].
Stanton, M. A. et al., 2010. RNP: a brief look at the Brazilian NREN. TERENA Networking Conference
(TNC2010) - Living the network life (Selected papers), Volume 1.
Biographies
Iara Machado is Adjunct Director of Advanced Internet in the Directorate of R&D at RNP. She joined RNP in
2002, and since then has coordinated the development of Advanced Application projects in close collaboration
with the Brazilian networking research community. Before this she worked for more than 19 years at the former
state-owned long-distance telecommunications company as a Management System Architect. Iara Machado
graduated in Physics from the UFRJ - University Federal of Rio de Janeiro - and has a Master's Degree in
Computer Science from UFF - University Federal Fluminense. She also has a MBA from UFRJ.
Fausto Vetter is Research and Development Coordinator in the Directorate of R&D at RNP since 2012. He has
experience on Network Management Systems (NMS’s) and Operational Support Systems (OSS’s). Currently, he
is mainly involved in the following projects: Science DMZ, MonIPÊ, CIPÓ and CT-MON. Before joining RNP,
he has worked for DANTE involved mainly in perfSONAR-MDM deployment for the LHC-OPN and NRENs
and in the design and deployment of a management infrastructure for the GÉANT backbone. He holds a
Bachelor in Science Degree in Information Systems from the Federal University of Santa Catarina (UFSC).
Alex S. Moura is Manager of R&D at RNP. First, in 1995, as System Administrator, later as RNP’s and
RedCLARA’s Senior Network Engineer and, since 2011, collaborates in advancing networking services for
collaborative and distributed science and education research in ongoing projects including the Advanced Internet
Programme, Future Internet and Advanced Testbed Network initiatives as well as Software-Defined Networking,
OSCARS and perfSONAR. Alex’s research interests includes network virtualization, software-defined
networking, cloud computing and network security and performance. His experience in the private sector
includes network engineering and security in Tier 3 Internet Data Centers. Alex holds a degree in informatics
and MSc in Information Systems from Federal University of Rio de Janeiro State (Unirio).
Michael Stanton is Director of R&D at RNP. He has also worked for more than 40 years as a professor in
postgraduate and research programs in Computer Science and Networking, and has participated actively in the
creation and development of research and education networking in Brazil since its inception. Since 2002, he has
been on secondment to RNP from the Computing Institute of the Universidade Federal Fluminense (UFF). He
holds a BA and PhD in mathematics from the University of Cambridge, England. In 2011, he was awarded a
three year CNPq fellowship for Productivity in Technological Development and Innovative Outreach, renewed
in 2014 for another three years.
Edison Tadeu Lopes Melo is superintendent at SeTIC/UFSC (Superintendence of Electronic Governance and
Information Technology and Communication of the Federal University of Santa Catarina (UFSC) and
administrative coordinator of the Point of Presence of RNP at Santa Catarina (PoP-SC) and of the Research and
Education Metropolitan Network in the region of Florianópolis/SC (REMEP-FLN). Graduated in Computer
Science and has a Masters in Science in Computer Systems from Federal University of Santa Catarina. He works
in IT projects since 1981.
Guilherme Eliseu Rhoden has over 10 years of experience in computer networks. He holds a Bachelor in
Science degree in Computer Science from UFPEL (1999) and Masters in Computer Science from UFSC (2002).
He works in UFSC network since 2003 and is network analyst at PoP-SC/RNP. Currently holds technical
coordination hole in PoP-SC/RNP and PIX/SC. He has participated in several research groups, such as GT-QoS,
GT-Measurements, MonIPÊ (current) and Future RNP – MonCircuitos (current). He was responsible for the
technical implementation of REMEP-FLN. He also offers business consulting services in networks and IP
telephony.
Murilo Vetter is a network analyst of Metropolitan Network for Education and Research in the Region of
Florianópolis (REMEP-FLN). He is the development coordinator of MonIPÊ, working on research projects
relating to monitoring conventional IP networks (MonIPÊ) and hybrid IP networks (MonCircuitos). Previously,
Murilo participated as developer in the RNP Working Group on Network Measurements [2005-2007]; developer
in the RNP Experimental Service MonIPÊ [2008-2009]; and development leader in the RNP Production Service
MonIPÊ [2010-2012]. Murilo holds an undergraduate degree in Computer Science from UFSC and he is
pursuing a master's degree at Federal University of Santa Catarina (UFSC).
Rodrigo Pescador is operations analyst at Point of Presence of RNP in Santa Catarina (PoP-SC) since 2008. He
is responsible for the technical infrastructure of MonIPÊ. He holds a Bachelor in Science Degree in Information
Systems from the Federal University of Santa Catarina (UFSC).
Paulo Brandtner is web developer at Federal University of Santa Catarina (UFSC). He is currently developing
MonIPÊ and Fone@RNP. He has worked as collaborator and developer for the Point of Presence of RNP in
Santa Catarina (PoP-SC). He holds a Bachelor in Science Degree in Information Systems from the Federal
University of Santa Catarina (UFSC).
Luis Cordeiro is web developer at the Point of Presence of RNP in Santa Catarina (PoP-SC). He is currently
developing for MonIPÊ and Fone@RNP projects. He holds a Bachelor in Science Degree in Information
Systems from the Federal University of Santa Catarina (UFSC).
