This page contains service description outlining how and where service should be used, targeted users, service delivery model and service elements and topology. RESPONSIBLE: Information provided in this page is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by service_name Service Manager, with exception of CBA which remains the responsibility of business development team. |
Service description
Add brief description of the service, how and where service should be used, typical or key use cases or scenarios (for various groups/levels of end users) and other relevant overview information
Users
Add definition of who are the targeted users, estimate about possible number of users etc.
Contacts
All operations, business development and stakeholders contacts
| Service Manager | Deputy Service Manager | L1 support | L2 support | L3 support |
|---|---|---|---|---|
Service delivery model
Add explanation about organisation of service delivery
Service Elements
Service Elements, with brief description and links to products, resource instances and software stack of the service, indicating the software components types - if they are internally (in-house) developed, OSS or commercial off-the-shelf software. Service elements can be grouped in two following categories:
Technology infrastructure
The confederation infrastructure relies on a distributed set of AAA servers. The current configuration uses RADIUS as the AAA protocol. There are various transport protocols to carry RADIUS payloads, as of May 2012, the following protocols exist: RADIUS/UDP, RADIUS/TCP, RADIUS/DTLS and RADIUS/TLS. eduroam supports transport over RADIUS/UDP and RADIUS/TLS, and recommends the use of RADIUS/TLS. Routing of RADIUS messages, independently of the transport used, is implemented in two ways: a baseline routing model, based on a hierarchy of RADIUS servers, and a dynamic-routing model, based on DNS service discovery. The dynamic-routing model is only supported over RADIUS/TLS.
Full explanation of technology infrastructure is provided at in eduroam Service Definition.
European Top-level RADIUS Servers (ETLRS) for the European Confederation are operated by SURFnet (Netherlands) and DeIC (Denmark). Top-level RADIUS Servers are deployed using Radiator software.
Supporting infrastructure
Each server has a list of connected, federation top-level domains (.nl, .dk, .hr, .de etc.) serving the appropriate NRENs. The servers also maintain exception rules for domains whose federation membership is not immediately identifiable in the realm (typically gTLD realms such as ’.edu’, ‘.eu’, ‘.net’, etc.). The servers accept requests for the federation domains they are responsible for, and subsequently forward them to the associated RADIUS server for that federation, and transport the response (i.e. result of the authentication request) back. Requests for the federation domains that the servers are not responsible for are forwarded to the proper federation TLRS.
Monitoring, Diagnostics and Metering
The basic purpose of the eduroam monitoring, diagnostics and metering service is:
- to test the functionality of the FLRSs, TLRSs and the whole confederation infrastructure.
- to collect information about the authentication traffic from the FLRSs.
Information is provided via the monitoring website that is operated by SRCE (Croatia). Monitoring website is an in-house development for GEANT project, developed and maintained by SRCE. Source code is available at ?
The eduroam monitoring and diagnostics element reports the results of the tests, both as a colour-coded map and as graphs showing the response-time behaviour. An alert system is also implemented in order to inform OT and NRO responsible stuff about any malfunctions in the service as soon as they occur.
The metering element relies on the F-Ticks tool that is also part of monitoring website, f-ticks section. F-ticks tool is an in-house development for GEANT project, developed and maintained by SRCE. Source code is available at ?
Some of those are public, while others are restricted to predefined user groups. The decision on the availability of the information lies with the eduroam Steering Group (SG). The eduroam monitoring, diagnostics and metering service is run and maintained by the Operations Team (OT).
eduroam Database
eduroam database stores information about eduroam service such as:
- NRO representatives and respective contacts.
- eduroam SP and IdP official contacts.
- Information about eduroam Service Providers (SP location, technical info).
- Monitoring information.
- Information about the usage of the service.
It is the obligation of the NROs to provide the above mentioned information.
Information about the eduroam database design and data collection practice is available via the monitoring website, database section. eduroam database is an in-house development for GEANT project, developed and maintained by SRCE. Source code is available at ?
A web interface to the database is implemented, and it allows various views of the database content. Some of these are public, while others are restricted to predefined user groups. The decision on the availability of the information lies with the eduroam SG. Data exchange with other applications related to the eduroam service is subject to prior approval by the eduroam SG. The eduroam database and its web interface is run and maintained by the OT.
Trouble Ticketing System (TTS)
Trouble Ticketing System (TTS) is used for the eduroam OT in order to document its work, and to allow authorised users from the predefined user groups to report any irregularities in the eduroam service. Ovo vise ne postoji !???
eduroam Website
The eduroam website is run and maintained by the OT. It is the central information point for eduroam users at the same time providing information and links for all user groups (see Section 3, Users).
Cost Benefit Analysis
Provide URL to last valid CBA