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 partners of GEANT project - SURFnet (Netherlands) and DeIC (Denmark). Top-level RADIUS Servers are deployed using Radiator software. |
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.
Supporting infrastructure
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 GEANT project partner - SRCE. 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. Information about F-Ticks, as well as the collected data, is available via the F-Ticks website [F-Ticks].
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
The information stored in the eduroam database is collected with the help from NROs and includes: 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. Information about the eduroam database design and data collection practice is available via the website [eduroam Database]. A web interface to the database is implemented, which 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)
The OT runs and maintains a Trouble Ticketing System (TTS) [TTS] in order to document its work, and to allow authorised users from the predefined user groups to report any irregularities in the eduroam service.
eduroam Website
The eduroam website [eduroam] 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