Changes between Initial Version and Version 1 of Topic5


Ignore:
Timestamp:
11/17/10 12:09:54 (13 years ago)
Author:
hmussman@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Topic5

    v1 v1  
     1=== Topic 5  GENI I&M  Interfaces and Protocols (APIs):  Manage Services  ===
     2
     3Team members:
     4  Vic Thomas - BBN/GPO  (yes)[[BR]]
     5  Ivan Seskar – Rutgers WINLAB  (yes)[[BR]]
     6  Max Ott – NICTA  (yes, by phone)[[BR]]
     7  Sonia Fahmy* – Purdue  (yes)[[BR]]
     8  Giridhar Manepalli - CNRI   (yes)[[BR]]
     9 
     10  *agreed to organize first discussion and writing
     11
     12Most instrumentation services follow the following steps: (1) request,
     13(2) measure, (3) process, (4) transport, and (5) retrieve. A user of
     14the instrumentation service will request certain measurements, which
     15results in the provisioning and configuration of measurement
     16probes. The probes generate a set or a stream of measurement data
     17which may be further processed and potentially transported to a
     18different location. Finally, the results of the requested measurements
     19are stored in one or more repositories from which they can be
     20retrieved and/or queried by authorized users, tools and services,
     21either immediately (real-time) or at a later time (history).[[BR]]
     22
     23Depending on usage scenarios and objectives, several different
     24architectures for instrumentation and measurement can emerge.  Current
     25GENI instrumentation projects leverage a number of popular tools to
     26construct their service. For example, the Scalable Sensing Service
     27project (S3) implements "sensor pods" (measurement points) as
     28cgi scripts accessible through any web-server that supports cgi. Boa,
     29a light-weight open source web-server, is currently used.  Therefore,
     30starting/stopping the sensor pods is simply accomplished by starting
     31and stopping the server.  This framework enables convenient third
     32party measurements; that is, measurements between two nodes can be
     33initiated by a third node.  Periodic measurements are configured as
     34"cron" jobs on the sensor pods.  A sensing information manager ensures
     35the liveness of the service using vxargs. The sensing information
     36manager also collects the measurements from the sensor pods using
     37rsync, and stores them in a data store (S3).[[BR]]
     38
     39In contrast, OML (OMLTridentCom,OMLwiki) takes a distributed
     40stream-based approach. Probes are assumed to produce a stream of
     41measurement tuples which are streamed through a configurable set of
     42filters and caches to a repository. The repository, like S3, provides
     43a web service interface allowing users and other services to retrieve
     44the results (pull mode). However, users/services can also directly
     45subscribe to a stream for operation in push mode. OML is integrated
     46into the OMF control framework to simplify configuration of the entire
     47distributed setup, as well as provide to support for "steerable"
     48experiments, where the orchestration of an experiment can be
     49influenced by the simultaneously collected measurements.[[BR]]
     50
     51Another instrumentation service currently in GENI is perfSONAR, which
     52sits somewhere in the middle. Various distributed monitoring services
     53are "wrapped" into individual web services called "Measurement Points"
     54(MPs) which return their results using the Open Grid Forum's Network
     55Measurement Working Group (NMWG) XML schema. A set of other services,
     56such as the Measurement Archive, Lookup, Authentication, Topology,
     57Transformation, and Resource Protector provide a comprehensive suite
     58of services.  perfSONAR is migrating to Representational State
     59Transfer (REST), viewed as a lighter-weight service-oriented
     60architecture over existing web service technologies, e.g.,
     61SOAP. XML-RPC and SNMP are also leveraged in several current
     62measurement projects.[[BR]]
     63
     64APIs[[BR]]
     65
     66There are essentially two types of measurement APIs: one concerning
     67itself with the configuration of the various elements and services
     68participating in the measurement and monitoring activities, and the
     69other facilitating the transfer of the measurement data itself.[[BR]]
     70
     71The provisioning and configuration of instrumentation functionality in
     72a large federated environment serving many experimenters and spanning
     73many countries with their respective legal frameworks is clearly a
     74complex undertaking.  However, at a fundamental level, instrumentation
     75requires discovering, provisioning, and configuring resources, within
     76the constraints of policies and user privileges. This is essentially
     77functionality that the GENI control framework (CF) is (or will be)
     78providing.  What is not covered by the CF is the protocol for encoding
     79and transporting measurement data between entities. Here, we must
     80differentiate between two types of operations: the push or streaming,
     81and the pull or requesting mode of operation. Both are not unique to
     82this domain and there are several standards and widely used solutions.[[BR]]
     83
     84OML will soon be using the Internet Protocol Flow Information Export
     85(IPFIX) protocol standardized by the IETF for streaming measurements
     86from an exporter to a collector. perfSONAR, as discussed above, is
     87using SOAP and the Open Grid Forum's Network Measurement Working Group
     88(NMWG) XML schema for returning measurements back to a requester.  In
     89OML, once an application has been modified to integrate OML
     90measurements, two possible configurations are possible: passing
     91general arguments on the command line of the enhanced application, or
     92using an XML configuration file. The XML configuration file allows
     93the user to multiplex the measurement stream and apply different
     94filters inside the application and between Measurement Points
     95(OMLTridentCom,OMLwiki).[[BR]]
     96
     97
     98References:[[BR]]
     99
     100(S3) P. Yalagandula, P. Sharma, S. Banerjee, S. Basu, and S.-J Lee.
     101S3: A scalable sensing service for monitoring large networked
     102systems.  In Proceedings of the ACM SIGCOMM Workshop on Internet
     103Network Management (INM), Sept. 2006.[[BR]]
     104
     105(OMLTridentCom) J. White, G. Jourjon, T. Rakatoarivelo, M. Ott.
     106Measurement Architectures for Network Experiments with Disconnected
     107Mobile Nodes.  In Proceedings of TridentCom, 2009.[[BR]]
     108
     109(OMLwiki) http://omf.mytestbed.net/wiki/oml/Documentation
     110