The HTN Protocol

1
The HTN Protocol

• Alasdair Allan1,2, Karsten Bischoff 3, Martin
  Burgdorf 4, Brad Cavanagh5, Damien Christian6,
  Neil Clay 4, Rob Dickens 7, Frossie Economou5,
  Mehri Fadavi8, Stephen Fraser4, Thomas Granzer9,
  Sandy Grosvenor10, Frederic V. Hessman11, Tim
  Jenness5, Anuradha Koratkar12, Matthew Lehner13,
  Chris Mottram4, Tim Naylor1, Eric S. Saunders1,
  Nikolaos Solomos14,15, Iain A. Steele 4, Georg
  Tuparev16, W. Thomas Vestrand17, Robert R.
  White17, Sarah Yost18
• 1School of Physics, University of Exeter, Stocker
  Road, Exeter, EX4 4QL, U.K.
• 2Royal Observatory, University of Edinburgh,
  Edinburgh, U.K.
• 3Teleskoptechnik Halfmann, Gessertshausener
  Strasse, 8D-86356 Neusäss-Vogelsang, Germany
• 4Astrophysics Research Institute, Liverpool JMU,
  Twelve Quays House, Egerton Wharf, Birkenhead,
  CH41 1LD, U.K.
• 5Joint Astronomy Centre, 660 N. Aohoku Place,
  University Park, Hilo, Hawaii, 96720, U.S.A.
• 6Department of Physics Astronomy, Queen's
  University Belfast, County Antrim, BT7 1NN, U.K.
• 7Latterfrosken Software Development Ltd., 32
  Bradford Street, Walsall, West Midlands, WS1 3QA,
  U.K.
• 8Jackson State University, P.O. Box 17660,
  Jackson, Mississippi 39217, U.S.A.
• 9AIP, An der Sternwarte 16, D-14482 Potsdam,
  Germany
• 10NASA/Goddard Space Flight Center, Greenbelt, MD
  2077, U.S.A.
• 11Inst. f. Astrophysik, Georg-August-Universität,
  Friedrich-Hund-Platz 1, 37077 Göttingen, Germany
• 12University of Maryland, Baltimore County, 5523
  Research Park Drive, Suite 320, Baltimore, MD
  21228, U.S.A.
• 13Harvard-Smithsonian Center for Astrophysics, 60
  Garden Street, Cambridge, MA 02138, U.S.A.
• 14Physics Sector, Hellenic Naval Academy, Piraeus
  18503, Greece
• 15National Astronomy Centre, Ainos Mountain,
  Kefallinia Island, Greece
• 16Tuparev Technologies Inc., Sofijski Geroj 3,
  Vh.2, 4th Floor, Apt. 27, 1612 Sofia, Bulgaria
• 17Los Alamos National Laboratory, Los Alamos, NM
  875444, U.S.A.
• 18University of Michigan, Randall Laboratory, 450
  Church Street, Ann Arbor, Michigan 48109-1040,
  U.S.A.

2
The standard

• The protocol standard has two parts
• the ltRTMLgt document
• when to exchange these documents
• The protocol is independent of the underlying
  transport mechanism used to carry the documents
• In order for the negotiation to be tracked, it is
  mandated by the standard that each dialogue has a
  unique and permanent identifier

3
ltRTMLgt standard

• Adopted as the document standard for the HTN
• Remote Telescope Mark-up Language (RTML)
• RTML 1.1 Experimentally used by HOU
• RTML 2.1 The official version of RTML
• RTML 2.2 Branch of 2.1 (a.k.a RTML eSTAR)
• RTML 3 Major re-write of the standard

4
Protocol standard

• Resource discovery
• Where are the telescopes?
• Phase 0
• What services/capabilities do the telescopes
  provide?
• Phase I
• Exchange of preliminary requests, and scoring
  responses, to evaluate the ability of the
  telescope to perform the desired observations.
• Phase II
• Exchange of observation request and the
  corresponding confirmation or rejection of the
  observing request.
• Data return
• Return of data and final status of the
  observations.

5
How does it work?
CREDIT Liverpool John Moores University
CREDIT The eSTAR Project
User Software
Telescope Software
User Interface
All other communications
The Grid
Resource discovery

• Resource discovery
• Phase 0
• Phase I (scoring)
• Phase II (observing)
• Data return

6
More formally

• Resource discovery
• Phase 0
• Phase I (scoring)
• Phase II (observing)
• Data return

7
Resource discovery

• Simple distributed flat files
• By definition, there is no master registry and
  the registry system operates on a peer-to-peer
  basis.

soap.foo.edu7070 soap
urn/node_agent handle_rtml sftp.bar.edu2222
sftp /pub/incoming
www.monet.edu80 http
/handlertml.cgi POST ip.monet.edu7000
soap urn/node_agent
handle_rtml ip.raptor.lanl.gov4001 tcp
www.telescope-networks.org register
http//www.telescope-networks.org/register.dat
optional
8
Phase 0

• Discover information that may be relevant to the
  construction of an observing request
• An ltRTMLgt document describing the resource is
  returned in response to this query
• instrument capability and constraints
• optionally include a list of ltRTMLgt documents and
  tags which the resource understands
• method by which telescope time is allocated

optional
9
Phase I (scoring)

• Allows the user to evaluate the predicted
  performance
• The user dispatches an ltRTMLgt document of type
  inquiry detailing the observations that they
  wish performed.
• In response the telescope will return another
  ltRTMLgt document, of type offer with a tagged
  scoring block
• Indicates how well the telescope feels it can
  fulfill the potential observing request.

optional
10
Score

• Worst case the score is a crude estimate of the
  generic chance of obtaining the requested
  observation
• Does not indicate whether the observation might
  be made immediately or at some distant time in
  the future
• Ideally respond with a score block detailing its
  capability to perform the observations
• cumulative probability distribution
• differential probability distribution (optional)
• Some indication of cost of the observation?

11
Phase 2 (observing)

• Only mandatory step, the user may skip some or
  all of the proceeding steps and make their
  observation requests directly to an already known
  telescope
• To make an observation request, the user
  dispatches an ltRTMLgt document of type request
  to telescope
• In reply to an observation request the telescope
  will return an ltRTMLgt document of type confirm
  or reject
• Rejection documents may contain information as to
  the nature of the rejection, but this is not
  mandated

mandatory
12
Data return

• An optional ltRTMLgt message of type update will
  be dispatched to the user by the telescope when
  something of note has occurred
• that data has been taken
• the end of a series of exposures
• At the end of observations, or the resource's
  attempts to obtain them, a mandatory complete,
  incomplete or fail message must be dispatched
  back the user.

mandatory
13
Data return

• Complete
• all the data has been taken.
• Incomplete
• some of the requested data was taken.
• Fail
• no data has been taken
• the data taken is (probably) useless
• reasons explaining why no data has been taken

14
Replacing ltRTMLgt

• Resource discovery
• Phase 0
• Phase I (scoring)
• Phase II (observing)
• Data return

15
ltTransportgt standard

• Created for the VOEvent Net prototype
• Used for network house keeping tasks
• ACK
• IAMALIVE
• Not meant to replace ltRTMLgt or ltVOEventgt messages
• What should we use it for in the HTN?
• registry requests?
• Phase 0 requests?
• acknowledgment of asynchronous requests

16
Example ACK message
lt?xml version"1.0" encoding"UTF-8"?gt lttrnTransp
ort role"ack" version"0.1"
xmlnstrn"http//www.telescope-networks.org/xml/T
ransport/v0.1" xmlnsxsi"http//www.w3.org/2
001/XMLSchema-instance" xsischemaLocation"ht
tp//www.telescope-networks.org/xml/Transport/v0.1
"gt ltOrigingtivo//uk.org.estar/pl.edu.ogleOGLE-20
06-BLG-296lt/Origingt ltResponsegtivo//talons.lanl/lt
/Responsegt ltTimeStampgt2005-04-15T235959lt/TimeSta
mpgt ltMetagt ltGroup name"Server Parameters" gt
ltParam namehost" value"astro.lanl.gov" /gt
ltParam nameport" value"43003" /gt lt/Groupgt
ltParam namestored" ucd"meta.ref.url"
value"query.pl?idOGLE-2006-BLG-296
/gt lt/Metagt lt/trnTransportgt
17
Transport standards

• Became clear during the meeting that the protocol
  for exchanging messages must be entirely neutral
  with respect to the underlying transport
  protocols
• Future-proofs us against technological advancement

18
Transport standards

• The VOEvent group came to the same conclusion
• But they did specify default transport standard
  for the backbone network.
• vanilla TCP (and RSS)
• Should we do the same?
• eSTAR is already doing both SOAP and TCP

19
Questions?