The relevant functionality has been implemented in the -05 version. (See Section
5.2.2 and Appendix C.4.3.)

The proposed resolution here is to implement this functionality, within the
basic framework established in Issue 30.

In detail:

GIMPS messages which manipulate routing state (Q/R/C) messages contain extra
information along with the routing state lifetime, i.e. the TTL. Note that it
may be needed in the Confirm (in case of query being sent in the upstream
direction, the confirm is the first chance to report the measured TTL from the
response). In particular, it must be possible to carry it in C-mode messages
(for reporting).

In a downstream message, the sender inserts the original TTL of the IP datagram,
or 0 if measurement will not be possible (e.g. if the encapsulation makes it
meaningless or the implementation cannot access the information at all). The
receiver should compare this with the TTL in the received datagram and store the
result as part of the routing state.

In an upstream message, the sender inserts the current value of its measured TTL
(taken from the routing state), or 0 if there is no measured value available.
The receiver should record this value in its routing state.

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.