PerfSONAR Specification

From GEANT2-JRA1 Wiki

Contents

perfSONAR Specifications: Messages and Protocols

About

This document presents the different standards with which any perfSONAR implementation needs to comply. It summarizes the different services identified for the perfSONAR framework and then details messages and protocols required for the communication between these services. This document ensures the quality of perfSONAR development because any implementation must conform with rules described herein.

For perfSONAR design goals see PerfSONAR_About#Design_Goals


perfSONAR Services

Currently Developed Services

The perfSONAR framework uses an SOA (services-oriented architecture). Services currently designed are described in the next sub-sections.

  • Measurement Point Service
    • The Measurement Point (MP) service is in charge of providing measurement data currently either not being measured or stored in an archive. It “creates” measurement data either by initiating active measurement tests or querying passive measurement devices. An MP is a standard interface “wrapper” around one or more measurement tool/capabilities. Formally, it does not store or transform (i.e. aggregate/correlate/filter) existing data, although, in practice, a particular implementation may do that “under the hood” (typically by a functionality of the underlying measurement tool). An MP is, basically, a place where some data are being metered. It can be, for example, a piece of hardware located in the core of the network to get precise data and deterministic behaviour of the network, but also can be software installed at the edge of the network on the hosts to perform end-to-end measurements.
  • Measurement Archive Service
    • A Measurement Archive (MA) service is used to publish historical monitoring data which are stored in an archive. It acts as a wrapper around an existing data archive to provide data to the outside world. The archive can be, for example, a network’s Round Robin Database (RRD) or a proprietary database of a Network Management System (NMS). Additionally, an MA can publish information produced by MP services. It does not create (generate new raw data) or transform (i.e. aggregate/correlate/filter) any data.
  • Lookup Service
    • Currently, it is difficult to discover and cumbersome to use the tests and measurement capabilities of multiple networks, even if they have been made publicly available. The Lookup Service (LS) enables users to discover other services (MP, MA, Authentication service, etc.) and, in particular, the tools, capabilities, or data covered by those services. The LS gives the requestor all information required to find and contact the necessary services. In essence, the LS acts as a service directory, where services can advertise themselves (provide their lookup information) and requestors are able to find any service they need. Some information about services can be hidden but high-level information should be exposed, so unauthorized users can determine if it is “interesting” (i.e. worth seeking authenticated access) or not. The LS is a key element of the perfSONAR measurement framework because it allows every independent service to be a visible part of the system. New services identify themselves to the community by registering with an LS and tender their capabilities, subject to locally-determined policies, or are withdrawn from the community without disrupting the interaction between other services.

Future Services

Following services have already been conceived but are not yet completely designed and cannot be integrated in the framework because of the lack of adequate protocols. They are described in the following sub-sections so that the full picture with future enhancements is well understood by the reader.

  • Authentication Service
    • Some domains may wish to restrict access to service capabilities for some groups of users. The Authentication Service (AS) provides the authentication (AuthN) functionality for the framework as well as an attribute authority (attribute authority is a component of the authentication server that decides which attribute can be disclosed to a resource). With those information provided by the LS, the local service will be able to provide access to a set of functionalities to a user based on the group of which he/she is a part (indicated by the attributes) and the service local authorisation policy. The detailed design and implementation of Authentication (AuthN) and Authorization (AuthZ) are being made in collaboration with GN2 JRA5 [JRA5] activity: Ubiquity (Mobility) and Roaming Access to Services.
  • Topology Service
    • The Topology Service (ToS) is used to make network topology information available to the framework. Typically, visualisation clients can make use of such information to retrieve the topology for the creation of network maps. The ToS is a specific example of a Transformation Service (TS). It collects topological information from a variety of sources and uses algorithms to deduce the network topology. The ToS also reflects multiple network layers. That is, topology described on the domain level through network to wavelengths and the physical level should be possible. In addition to the network topology, it contains geographic information, such as GPS coordinates. For more generic information on the goals and expectations for the future, see: http://www.perfsonar.net/jra1-wiki/index.php/Topology_Service_resources.
  • Transformation Service
    • The TS is used to pipeline and modify data between the other services within the framework. It can be used to perform any function upon data. It fits between data producers (e.g. MPs, MAs, or other services) and data consumers (e.g. MAs, other services, or Clients) and is, itself, both a data consumer (which receives and makes use of some data) and producer (which “produces” and sends some data). Therefore, a TS acts as both a publisher (sends data) and a subscriber (asks for and receives data). There is a variety of potential functions that a TS might provide including aggregation, correlation, filtering, and translation of data. For example, a TS might compress datasets from the more recent high resolution data to less recent lower resolution data and publish that data to an MA service. A TS also might read from multiple data producers to create a specific correlation. A very simplistic data analysis example would be a threshold detection operation, which then pushes data out for the purposes of triggering a NOC (Network Operational Centre) alarm.
  • Resource Protector Service
    • The Resource Protector (RP) service is used to arbitrate the consumption of limited resources, such as network bandwidth. It also has a scheduling component to deal with the consumption of time-dependant resources. When measurement activities are involved, resources may be related to the measurement infrastructure or ordinary network resources. The RP can allocate portions of a resource based upon configuration rules and schedule the time-dependent resources. Services that consume resources can contact the RP to have them allocated. The primary example of this is the MP. Because RPs reduce scheduling flexibility, by design, an RP should be deployed only to protect limited resources. In other words, some MP services do not have to contact an RP at all or only have to contact it for requesting access to a limited number of resources. One has to note that every MP has the ability to manage its own resources locally, based on local information (CPU, memory of the MP, or authorisation level of the measurement requester). The service can be configured to contact an RP that has been configured to protect a local network link if some tests have to be performed along the path.

Messages and Protocols

This section describes the detailed workings of the services that are part of the perfSONAR package: LS, MA, and MP. It also provides a block of general information that relates to all of the services.

Generalities

Multiple Lookup Services: Protocols

Measurement Archive: Protocols

Measurement Point: Messages and Protocols


References

General Framework Design - http://monstera.man.poznan.pl/jra1-wiki/images/9/95/GN2-05-057v5.pdf

Base services detailed design - http://monstera.man.poznan.pl/jra1-wiki/images/d/d8/GN2-05-279v12.pdf

Personal tools