The GIMPS API contains a primitive to allow GIMPS to report
what is equivalent to the number of IP hops between the
receiving node and the GIMPS peer that sent a signaling
message (see Appendix D.2). This could be required to
emulate RSVP-like functionality in support of IntServ where
the existence of non-IntServ capable hops needs to be
discovered.  However, the GIMPS protocol itself does not
currently contain functionality to support this aspect of
the API. 

The protocol functionality required for this is logically
quite simple: a sending node inserts the IP TTL used in the
GIMPS message, and the reciever compares this with the IP
TTL in the received signaling message.  A value > 1
indicates a non-GIMPS node between. However, there are some
subtleties to make it possible to report this consistently
to signaling applications:

1) The basic approach only provides a meaningful answer for
downstream query messages.  For upstream messages, because
of asymmetric routing, it would be necessary for the sending
node to insert the 'non-GIMPS-capable hop count' value it
has learned directly in the message, which would be used
directly at the receiver without comparing with the received
TTL at the IP layer.

2) It is not usually possible to extract IP layer TTL
information for data arriving over transport protocols such
as TCP, and strictly it is not meaningful to do so. 
Therefore, rather than reporting a fresh value for every
message, the incapable hop count would have to be calculated
by GIMPS on query/response exchanges and then stored in the
routing state table so it can be reported to signaling
applications for each message regardless of which mode was
actually used for that message.

It needs to be evaluated whether this degree of protocol and
implementation complexity is justified by the value of the
information obtained.