Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2017-07-13,master

commit d4e4cf6f2313c72888e9984a9b330ad08b98385e Author: Marek Lindner mareklindner@neomailbox.ch Date: Sun May 22 20:43:59 2011 +0000

doc: batman-adv/Client-announcement

d4e4cf6f2313c72888e9984a9b330ad08b98385e batman-adv/Client-announcement.textile | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index de7e155a..0c1e6cd9 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -55,14 +55,9 @@ node correctly handle the appended buffer.

In case of unavailability of the last OGM transtable buffer the node will answer with the full table.

-h2. TT_REQUEST forward breaking: - -To avoid unicast storming in case of multiple TT_REQUEST traversing the network, each node on the path of such message will inspect it and decide -whether it has the correct information to answer with. To check this, the intermediate node has to inspect the TT_REQUEST and compare the ttvn and the -tt_data (that is the tt_crc in this case) fields with its own information. If the destination's ttvn it knows is equal to the requested the ttvn and the -tt_crc matches as well, then the intermediate node can directly reply to the request (with the full table of the destination or the last OGM buffer if -needed and possible). If something didn't match, the node will forward the packet to the nexthop in the path to the destination (as a simple unicast -packet). +h2. TT_REQUEST forwarding: + +To reduce the overhead of the table request operations, each node on the path of a TT_REQUEST message will inspect the contents and decide whether it has the correct information to answer the request directly without forwarding the TT_REQUEST any further. The ttvn and the crc16 checksum contained in the request message provide sufficient means to verify if it matches with the locally available information. If they match the node can directly reply to the request (with the full table of the destination's translation table or the changeset of the last ttvn if possible). If something didn't match, the node will forward the packet to the nexthop in the path to the destination.

h2. TT consistency: