Issue30

Issue Title Proposed Modification to Low-Level Message Formats
Document: GIMPS Protocol Specification v04 Section: General
Category: Technical Priority: Must Fix
Status: Closed

Created on 2005-01-19.15:37:34 by reh, last changed 2005-03-02.16:20:46.

Messages
msg63 Author: reh Date: 2005-03-02.16:20:46
These changes were implemented in the -05 version.
msg45 Author: reh Date: 2005-01-21.09:45:03
(On point 5:) Actually, at least parts of the NAO are needed in the Confirm
message whichever mode it is sent in, in order to allow the responding node to
set up all relevant routing state even if it has forgotten all the information
in the initial Query. So, maybe the TTL should go here after all....
msg40 Author: reh Date: 2005-01-20.09:55:25
(On point 5:) Actually, a better place for this information is the routing state
lifetime, since this is carried in all messages which manipulate routing state,
whereas the NAO is only in the datagram mode ones.
msg36 Author: reh Date: 2005-01-19.15:37:34
A number of issues (at least 2, 3, 5, 8, 16, 18, 19) have interactions with the
low (close to IP layer) aspects of GIMPS message formatting. In order to prepare
for solutions to these issues, the following changes to the specification are
proposed; some are conceptual clarifications about the structure of the
protocol, and some are detailed changes of message or object layout.

1. The IP/transport layer encapsulation for a GIMPS message is assumed to have
no semantic significance for the signalling. The sender chooses the
encapsulation to provide the best likelihood that the message will be seen by
the correct peer (e.g. that it will follow the same path as the data); the
receiver can examine the encapsulation to derive information about the network
layer topology relevant to the signalling path, e.g. how many IP hops are
involved, or the IP address of the peer, or the presence of a NAT in the path.

2. Message Routing Methods must refer to a directed path in the network; the
Message Routing Information must implicitly include a source and destination
address and a direction relative to the path.

3. The D mode encapsulation will be derived from the MRI, but some
implementation freedom is needed (e.g. for source address selection). To allow
the receiver to analyse the encapsulation, the GIMPS header will include flags
to say how the IP header was constructed.

4. The role of a GIMPS D mode message will no longer be dependent on the
direction it is being sent in. Instead, the GIMPS header will include a message
type.

5. The routing state for a given MRI/NSLPID (for each direction) will be allowed
to include a measure of the distance to adjacent signalling peers (essentially,
IP hop count). This distance will therefore be measured and signalled by the
GIMPS Q/R/C exchange; it will be measured by messages in the 'forwards'
direction (relative to the MRI) and reported by messages in the reverse
direction. This information will be carried in the Node Addressing Object.
History
Date User Action Args
2005-03-02 16:20:47rehsetstatus: Pending -> Closed
messages: + msg63
2005-01-21 09:45:03rehsetmessages: + msg45
2005-01-20 09:55:26rehsetstatus: No Discussion -> Pending
messages: + msg40
2005-01-19 15:37:34rehcreate