IMF GEC13 QSR


Overview

This wiki page serves as the Status Report following GEC13 for the IMF project.

  • Draft created by Rudra Dutta on March 29, 2012
  • Edited by IMF team March 29 - April 2, 2012
  • Final version released on April 2, 2012

The IMF project continued to work on the goals and milestones identified for the project for Spiral 4.

The main functionalities we achieved between GEC12 and GEC13 are:

  • Creating a version of the Openfire XMPP server that supports GENI style certificates for entity authentication and credential verification (IMF Messaging Service)
  • Creating OMF style EC and RC modules that communicate using the above IMF Messaging Service instead of OMF XMPP
  • A sample "empty" client for the IMF Messaging Service
  • A simple repository service built by extending the "empty" client

These were demonstrated successfully at GEC13. The demo is documented at  GEC13 Demo Session Page.

Major Accomplishments

Milestones Achieved

  • IMF: S4.c Demonstration at GEC13 and Experimenter Outreach
  • IMF: S4.d Documentation and Code Release

Deliverables made

Description of work performed during last quarter

IMF project achievements for this second part of Spiral 4 consist of:

  • Creating a version of the Openfire XMPP server that supports GENI style certificates for entity authentication and credential verification (IMF Messaging Service)
  • Creating OMF style EC and RC modules that communicate using the above IMF Messaging Service instead of OMF XMPP
  • A sample "empty" client for the IMF Messaging Service
  • A simple repository service built by extending the "empty" client
  • Demonstrating new capabilities at GEC13

Activities and Findings

Location/context of IMF modules at GEC13

The figure above shows the context of each of the modules we describe briefly below. More detailed documentation, code, and installation instructions are in the "Code Release" section below on this wiki.

The IMF Messaging Service runs by itself as a server. All other modules are clients to it, and require for it to be running and accessible, but do not require each other.

IMF Extended Openfire XMPP Server (IMF Messaging Service)

Th IMF Messaging Service is expected to run in some management server, typically outside slices. In the GEC13 demo, this ran on a management server on the BEN facility at RENCI.

It holds a certificate for at least one GENI Certifying Authority. That is, it "recognizes" the authority of (is prepared to accept certificates issued by) this GENI CA. It may hold certificates for multiple GENI CAs.

When a client attempt to initiate a secure connection to it, the IMF Messaging Service expects that client to produce a certificate which is signed by the GENI CA. If not, the connection is refused. We call this entity authentication.

Having successfully connected to the IMF Messaging Service, a client would attempt to either publish to a topic (node), or subscribe to it. The IMF Messaging Server expects credentials to find previously stored credentials for the authenticated entity corresponding to each such action ("pub_<topic>" and "sub_<topic>" credentials). Otherwise these actions are refused. Credentials are stored in a location known to the IMF Messaging Service. We refer to this process of credential verification as authorization.

Both certificates and credentials can be created by the gcf tool, which has been extended for the purpose.

In order to make this work, the JIDs of clients have to match the prefix of the filename storing the arbitrary generated credentials. Thus in this view, the JIDs of the clients are not meant to have significance to humans, whereas the topic names are.

"Empty" Sample Client to IMF Messaging Service

A simple XMPP client which behave according to the expectations of the IMF Messaging Service as above. This can be used as sample code for building messaging clients with the authentication and authorization capabilities. In the GEC13 demo, this ran off a standalone laptop at the demo site.

To access the IMF Messaging Service, the client must have access to a public IP interface of the server running the IMF Messaging Service. Alternatively, if the server is in a VPN, it needs access to that VPN; etc. In our GEC13 demo, the server was in a VPN to which the laptop had been given access.

OMF EC and RC using IMF Messaging Service

In the OMF system, the Experiment Controller (EC) and Resource Controller (RC) communicate to each other through an XMPP server. The XMPP topics are bootstrapped by the OMF Aggregate Manager (AM). The EC locates the XMPP server by prior secure HTTP interaction with the AM. In the GENI context, the OMF EC and RC can be expected to run in VMs within slices.

We created modules similar to the OMF EC and RC, that communicate through the IMF Messaging System, and using authentication and authorization as above. The topic bootstrapping is currently manual. Our implementation conforms with OMF 5.4; OMF is currently moving to 6.0 which should eliminate the secure HTTP step, and we will reexamine our implementation in light of that change when available.

In the GEC13 demo, these ran in an ORCA slice created with Flukes; on distinct VMs of the same slice, which had VPN access to the IMF Messaging Service server.

Repository Service using IMF Messaging Service

A client built on the sample client, which subscribes to some particular topic, then locally archives every message that is published on that topic. In the GEC13 demo, it ran on a standalone laptop at the demo site, which had VPN access to the IMF Messaging Service server.

The repository server attempts to be accommodating of messages to be archived. If the XML message contains a particular preamble, the Repository Service attempts to parse the XML to find out what table to store the message into, and divide the message into column values. If this preamble is missing, the Repository Service simply stores the entire message as one field in a default table, indexed only by timestamp and sender.

IMF Optical Measurement Handler using IMF Messaging Service

This is the IMF Measurement Handler (with PubSub? Manager) with appropriate physical optical substrate interface modules to extract measurement data from various optical substrates, such as Polatis switches and Infinera DTNs, that we successfully demonstrated at GEC8 and following. It has been updated to use the IMF Messaging Service, rather than an inbuilt XMPP server, and use authentication and authorization. This must run on a machine that has access to the management interfaces of the optical hardware - typically this would imply physical proximity, and RS232 connection or similar. In the GEC13 demo, this ran on a dedicated server on BEN at RENCI.

This code module also makes the "SimpleIMFSubscriber" target, which can consume and display the optical port power and other readings being generated and published by the Measurement Handler/PSM, updated to use the IMF Messaging Service.

Project Participants

  • Rudra Dutta, George Rouskas, Ashutosh Grewal, Ahmet Can Babaoglu (NCSU)
  • Anirban Mandal, Shu Huang, Ilia Baldine (RENCI)
  • Keren Bergman, Michael Wang, Cathy Chen (Columbia U)

Publications

Integrated post-GEC report and code documentation (this wiki)

Outreach

Participants of the IMF team attended GECs as well as meetings of the Instrumentation and Measurement Working Group as possible. We have previously collaborated with the GENI LEARN project team; deploying IMF in LEARN remains a longer-term goal. We plan to collaborate with the NetKarma project and NICTA message signing, as encouraged by GPO.

Collaborations

The IMF team continued to collaborate with Deniz Gurkan of the GENI project LEARN.

Other contributions

None.

Code Release

Code Snapshot

The GEC13 demo modules of the IMF system can be built the following. Above we provided a high-level view of the location and use of the different modules, here we include more detailed documentation on each (these documents are also included in the zip files themselves).

IMF Extended Openfire XMPP Server (IMF Messaging Service)

"Empty" Sample Client to IMF Messaging Service

OMF EC and RC using IMF Messaging Service

Repository Service using IMF Messaging Service

IMF Optical Measurement Handler using IMF Messaging Service

The IMF Measurement Handlers is configured to be running on the BEN testbed, to retrieve port power and BER measurements made on Polatis and Infinera switches. To successfully run this, you need VPN access to the management plane network of BEN. Get in touch with the IMF team to obtain this access, if you need it.

Documentation and Release Notes

Notes on this wiki, plus detailed documentation as described above.

Attachments