Changes between Version 43 and Version 44 of 2ndInstMeasWork

07/18/10 18:34:16 (9 years ago)



  • 2ndInstMeasWork

    v43 v44  
    212212  *agreed to organize first discussion and writing
    214 Define an approach based on OMF/OML and S3:
    215   HTTP(S)[[BR]]
    216   REST vs SOAP[[BR]]
    217   Authorization by credentials or ?  If credentials, how to revoke?[[BR]]
    218   Pass XML fragments[[BR]]
    219   Define basic API[[BR]]
     214Most instrumentation services follow the following steps: (1) request,
     215(2) measure, (3) process, (4) transport, and (5) retrieve. A user of
     216the instrumentation service will request certain measurements, which
     217results in the provisioning and configuration of measurement
     218probes. The probes generate a set or a stream of measurement data
     219which may be further processed and potentially transported to a
     220different location. Finally, the results of the requested measurements
     221are stored in one or more repositories from which they can be
     222retrieved and/or queried by authorized users, tools and services,
     223either immediately (real-time) or at a later time (history).[[BR]]
     225Depending on usage scenarios and objectives, several different
     226architectures for instrumentation and measurement can emerge.  Current
     227GENI instrumentation projects leverage a number of popular tools to
     228construct their service. For example, the Scalable Sensing Service
     229project (S3) implements "sensor pods" (measurement points) as
     230cgi scripts accessible through any web-server that supports cgi. Boa,
     231a light-weight open source web-server, is currently used.  Therefore,
     232starting/stopping the sensor pods is simply accomplished by starting
     233and stopping the server.  This framework enables convenient third
     234party measurements; that is, measurements between two nodes can be
     235initiated by a third node.  Periodic measurements are configured as
     236"cron" jobs on the sensor pods.  A sensing information manager ensures
     237the liveness of the service using vxargs. The sensing information
     238manager also collects the measurements from the sensor pods using
     239rsync, and stores them in a data store (S3).[[BR]]
     241In contrast, OML (OMLTridentCom,OMLwiki) takes a distributed
     242stream-based approach. Probes are assumed to produce a stream of
     243measurement tuples which are streamed through a configurable set of
     244filters and caches to a repository. The repository, like S3, provides
     245a web service interface allowing users and other services to retrieve
     246the results (pull mode). However, users/services can also directly
     247subscribe to a stream for operation in push mode. OML is integrated
     248into the OMF control framework to simplify configuration of the entire
     249distributed setup, as well as provide to support for "steerable"
     250experiments, where the orchestration of an experiment can be
     251influenced by the simultaneously collected measurements.[[BR]]
     253Another instrumentation service currently in GENI is perfSONAR, which
     254sits somewhere in the middle. Various distributed monitoring services
     255are "wrapped" into individual web services called "Measurement Points"
     256(MPs) which return their results using the Open Grid Forum's Network
     257Measurement Working Group (NMWG) XML schema. A set of other services,
     258such as the Measurement Archive, Lookup, Authentication, Topology,
     259Transformation, and Resource Protector provide a comprehensive suite
     260of services.  perfSONAR is migrating to Representational State
     261Transfer (REST), viewed as a lighter-weight service-oriented
     262architecture over existing web service technologies, e.g.,
     263SOAP. XML-RPC and SNMP are also leveraged in several current
     264measurement projects.[[BR]]
     268There are essentially two types of measurement APIs: one concerning
     269itself with the configuration of the various elements and services
     270participating in the measurement and monitoring activities, and the
     271other facilitating the transfer of the measurement data itself.[[BR]]
     273The provisioning and configuration of instrumentation functionality in
     274a large federated environment serving many experimenters and spanning
     275many countries with their respective legal frameworks is clearly a
     276complex undertaking.  However, at a fundamental level, instrumentation
     277requires discovering, provisioning, and configuring resources, within
     278the constraints of policies and user privileges. This is essentially
     279functionality that the GENI control framework (CF) is (or will be)
     280providing.  What is not covered by the CF is the protocol for encoding
     281and transporting measurement data between entities. Here, we must
     282differentiate between two types of operations: the push or streaming,
     283and the pull or requesting mode of operation. Both are not unique to
     284this domain and there are several standards and widely used solutions.[[BR]]
     286OML will soon be using the Internet Protocol Flow Information Export
     287(IPFIX) protocol standardized by the IETF for streaming measurements
     288from an exporter to a collector. perfSONAR, as discussed above, is
     289using SOAP and the Open Grid Forum's Network Measurement Working Group
     290(NMWG) XML schema for returning measurements back to a requester.  In
     291OML, once an application has been modified to integrate OML
     292measurements, two possible configurations are possible: passing
     293general arguments on the command line of the enhanced application, or
     294using an XML configuration file. The XML configuration file allows
     295the user to multiplex the measurement stream and apply different
     296filters inside the application and between Measurement Points
     302(S3) P. Yalagandula, P. Sharma, S. Banerjee, S. Basu, and S.-J Lee.
     303S3: A scalable sensing service for monitoring large networked
     304systems.  In Proceedings of the ACM SIGCOMM Workshop on Internet
     305Network Management (INM), Sept. 2006.[[BR]]
     307(OMLTridentCom) J. White, G. Jourjon, T. Rakatoarivelo, M. Ott.
     308Measurement Architectures for Network Experiments with Disconnected
     309Mobile Nodes.  In Proceedings of TridentCom, 2009.[[BR]]
    221315===  Topic 6  GENI I&M  Interfaces and Protocols (APIs):  Data Flows and Data File Transfers ===