Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 58745e0db7451bc4444a244de669ce1032012499 Author: Marek Lindner mareklindner@neomailbox.ch Date: Mon May 23 02:23:26 2011 +0000
doc: batman-adv/Client-announcement
58745e0db7451bc4444a244de669ce1032012499 batman-adv/Client-announcement.textile | 41 ++++++++++++++-------------------- 1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index b86a5e8a..e9d25fee 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -33,42 +33,35 @@ The tt change entry format: </pre>
These changes are also appended to the 2 following OGMs if there were no new changes in the meantime, thereby increasing the chance for neighbor node to receive the changes in the event of packet loss. If a node receives an OGM containing a new ttvn without the changeset (e.g. it missed all 3 OGMs with the changeset or the changeset exceeded the packet size) or the crc16 checksum does not match it can issue a table request. In particular a node can ask for two different information: -- The originator's full local table -- The last set of changes from the current ttvn. - -This distinction is done using the TT_FULL_TABLE bit of the bitwise **flag field** in the TT_QUERY packet. - -The originator that receives the TT_REQUEST message will reply with a TT_RESPONSE to which the node will append the requested data. - -The TT_REQUEST message will contain the following fields: -In particular the TT_REQUEST/TT_REPONSE messages are two subtypes of the TT_QUERY message which has the following format: +* The originator's full local table +* The changeset of the current ttvn. + +The tt request format: +* Packet type: Initialize this field with the NDP packet type. +* Version: Set your internal compatibility version. +* Destination Address: Address of the host this packet should be forwarded to. +* TTL: Time-To-Live field decreased by with one with each hop. Packet is to be discarded when counter reaches 0. +* Flags: The flag field is used to distinguish between a TT_REQUEST and a TT_RESPONSE and to inform whether the message is asking for/carrying a full local table or only the changeset of the current ttvn. +* Source Address: Address of the host sending this message. +* TTVN: If the message is of type TT_REQUEST this field specifies the request translation table version number. If it is of type TT_RESPONSE it contains the ttvn of the data in the reply. +* TT Data: If the message is of type TT_REQUEST this field is filled with the crc16 checksum of the specified ttvn. If it is of type TT_RESPONSE this field is set to the number of entries the message is carrying. This information is needed to let the receiver node correctly handle the appended buffer.
<pre> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Packet Type | Version | Destination... | + | Packet Type | Version | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | + | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTL | Flags | Source... | + | TTL | Flags | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | + | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTVN | TT_Data | + | TTVN | TT Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </pre>
-The flag field is used to distinguish between a TT_REQUEST and a TT_RESPONSE and to inform whether the TT_QUERY message is asking for/carrying a full local table or only the last OGM transtable buffer. - -The ttvn field is used to inform about the ttvn is asking for/replying with. -So, in case of OGM buffer request, this value will be set to the ttvn associated to the buffer the node needs. - -The tt_data field has different content in case of TT_REQUEST or TT_RESPONSE. -If the message is a TT_REQUEST, this field is set to the tt_crc value (for details about this value, please read the TT consistency section) that the -requesting node received by means of the OGM from the destination (of this TT_REQUEST). -If the message is a TT_RESPONSE then this field is set to the number of entries the message is carrying. This information is needed to let the receiver -node correctly handle the appended buffer.
In case of unavailability of the last OGM transtable buffer the node will answer with the full table.