You are an expert at summarizing long articles. Proceed to summarize the following text: 
we re assuming that you already know the basics of the qspn . if not , read the qspn document first : @xcite . the aim of netsukuku is to be a ( physical ) scalable mesh network , completely distributed and decentralised , anonymous and autonomous . the software , which must be executed by every node of the net , has to be unobtrusive . it has to use very few cpu and memory resources , in this way it will be possible to run it inside low - performance computers , like access points , embedded devices and old computers . if this requirements are met , netsukuku can be easily used to build a worldwide distributed , anonymous and not controlled network , separated from the internet , without the support of any servers , isps or control authorities . node : :    we call _ node _ any computer that is hooked up to the netsukuku    network . rnode : :    stands for remote node : given a node x , it is any other node directly    linked to x , i.e. it s a neighbour of x. map : :    a map is a file , kept by each node , which contains all the necessary    information about the network , f.e . routes and nodes status . example : +        a is the rnode of b. + b is the rnode of a and c. + c is the rnode of b. a simple topology , which does nt impose any structure on the network , can be memorised with a simple map . in this map , all the information regarding the nodes of the network have to be memorised . surely , this kind of map can not be utilised by netsukuku , because it would require too much memory . for example , even if we store just one route to reach one node and even if this route costs one byte , we would need 1 gb of memory for a network composed by @xmath2 nodes ( the current internet ) . for this reason , it s necessary to structure the network in a convenient topology .        first of all we ll subdivide the network in groups of 256 nodes and we ll use the following definitions :    gnode : :    means group node . it is a group of nodes , i.e. a set of nodes . each    node of the network belongs to just one gnode . +    a gnode contains a maximum of 256 nodes . +    by writing @xmath3 we mean that the node @xmath4    belongs to the gnode @xmath5 . bnode : :    stands for border node . it is a node which belongs to a gnode g , but    that is also directly linked to at least one node of another gnode ,    i.e. some of its rnodes belongs to different gnodes than its . +    by writing @xmath6 we mean that the bnode    @xmath7 belongs to the gnode @xmath5 . example : +    ]    @xmath8 , a is a node belonging to the gnode g , its rnode is b. + @xmath9 , b is a node belonging to the gnode @xmath10 , its rnode is a. + a is a bnode of g , while b is a bnode of @xmath10 . we further subdivide the network topology in _ groups of 256 groups of nodes _ and we continue to name them as gnode . + at this point , we repeat recursively this subdivision process until we can group all the nodes of the network into a single gnode .    doing so , we ve structured the network in @xmath11 levels ( from @xmath12 to @xmath4 ) . + in the base level ( level 0 ) , there are 256 single nodes . + in the first level ( level 1 ) , there are 256 normal gnodes . each of them contains 256 single nodes . + in the second ( level 2 ) , 256 gnodes of level 1 forms a single _ group of groups of nodes_. + in the third ( level 3 ) , there are 256 groups of 256 groups of 256 groups of 256 nodes . + continuing in this way , we arrive at the last level ( level @xmath4 ) , where there is a single group which contains the whole network . + the qspn algorithm is able to operate independently on any level , considering each gnode as a single node of level 0 . for this reason , we can view the netsukuku topology as a fractal , where each level is composed by single nodes . figure [ fig : fract_circle ] is an example of the fractal topology of netsukuku .        in this topology , each gnode contains four nodes , i.e. each group contains four elements . the network is structured in 6 levels . + the red elements , are single nodes ( level 0 ) . + four nodes forms a single group of nodes ( level 1 ) . + a single bright green circle is a group of groups of nodes ( level 2 ) . + the dark green circles are groups of groups of groups of nodes ( level 3 ) . + the dark blue circle are groups of groups of groups of groups of nodes ( level 4 ) . + finally , the bright blue circle is the gnode which contains the whole network ( level 5 ) . let s assign a numeric i d to each ( g)gnode , starting from the last level :    1 .   in the last level ( @xmath4 ) there s only one giant gnode , thus we assign to it the i d `` 0 '' . our global i d will be : @xmath13 2 . in @xmath14 there are 256 gnodes , which belongs to the gnode 0 of level @xmath4 , thus we assign them the ids from @xmath12 to @xmath15 . the global i d becomes : @xmath16 3 . we repeat the step 2 recursively gaining an i d of this form : @xmath17 4 . since the last level is always @xmath12 , we ll omit it and we ll consider only the first @xmath4 levels .    in a network with a maximum of @xmath18 nodes ( the maximum allowed by the ipv4 ) , there would be five levels ( @xmath19 ) , where each gnode will be composed by 256 nodes . therefore , the i d will be in the usual ip form : @xmath20 for example , a single node of level 0 of the network is : @xmath21 that said , each gnode of the network belongs to only one combination of gnodes of the various levels . in our previous example we have : @xmath22 where each @xmath23 corresponds to the gnode i d of the level @xmath24 . note that @xmath25 is the i d attributed to the single node , at level 0 . the advantages of using a fractal topology are clear . + the node @xmath26 , instead of memorising information about each node of the whole network , will keep only that regarding the gnodes where it belongs to . suppose the node @xmath26 had this i d : @xmath27 it will store in memory information regarding :    1 . the 256 single nodes which belongs to its same gnode of level 1 , or in other words , the 256 nodes of the gnode @xmath28 , 2 . the 256 gnodes gnodes which belongs to its same gnode of level 2 , of in other words , the 256 gnodes of the gnode @xmath29 , 3 .   finally , the 256 gnodes which belongs to the gnode @xmath30 . note that doing so , the node @xmath26 will be blind to all the other gnodes . for example , it wo nt know any information regarding the single nodes which belong to all the other gnodes of level 1 different from @xmath28 . + even with this lack of knowledge , as we ll see later , the node @xmath26 is still able to reach all the other nodes of the network . in conclusion , @xmath26 only needs @xmath31 entries in its map , instead of @xmath18 . to clarify the ideas suppose that each entry costs one byte . in the plain topology we needed @xmath32 , while in the fractal one we just need @xmath33 . netsukuku is both compatible with ipv4 and ipv6 . + in ipv4 there are a maximum of @xmath18 ips , thus we have five levels @xmath19 . + in ipv6 there are a maximum of @xmath34 ips , thus @xmath35 .      for simplicity we divide the map of the node @xmath26 , in the _ internal map _ and in the _ external _ one . the internal map contains information regarding the nodes belonging to @xmath28 . the external map describes all the other levels of the topology . the bnode map of the node @xmath26 contains the information regarding the bnodes of each level where @xmath26 belongs . some examples to clarify the ideas : + suppose that @xmath36    * a bnode of level 0 is a single node linked with two nodes of two different gnodes of level 1 . * the bnodes of level 0 , known by @xmath26 , are only that which belong to the gnode @xmath25 . they are all the nodes of @xmath25 which are linked to at least a gnode different from @xmath28 . the qspn , for each level , will build the routes necessary to connect each ( g)node to all the other ( g)nodes of the same level . the routes will be saved in the maps of each node . + if the node @xmath37 wants to reach a node @xmath38 which belongs to different gnodes , f.e . @xmath39 , it will add a cidr@xcite route in the routing table of the kernel : + _ all the packets whose destination is @xmath40 will be forwarded to the gateway @xmath41_. + we ll see later how the gateway @xmath41 is chosen . in the qspn document @xcite , we ve seen how a tracer packet works in a network composed by single nodes , i.e. a gnode of level 0 . + we ll now study its way of working on higher levels .      in the abstract sense a single node is an entity which :    1 .   receives input from its links 2 . stores it in its memory 3 . computes it 4 .   and sends the output of the computation over some of its links    thus any other entity which performs the same operations can be thought as a single node . + a gnode @xmath5 can act as a single node too .    1 .   a bnode @xmath42 , which belongs to @xmath5 , receives an input from its links . we call @xmath42 the _ ingress _ ( b)node . 2 . this input is flooded to all the nodes , of any level , of the gnode . the nodes will memorize the information contained in the input . + note that the flood is not a tp . the flooded pkt will be received only once by each node . 3 .   a bnode @xmath43 , of the same gnode , which is different from @xmath42 , receives the flooded input and computes it . we call @xmath43 the _ egress _ ( b)node . 4 . the bnode @xmath43 sends the output of its computation to its external links , i.e. avoiding those links which connect it to nodes of @xmath5 or to the same gnode which sent the input to @xmath42 . consider the network in figure [ fig : qspn_g3 ] . +    , @xmath44 and @xmath45    @xmath46 , @xmath44 , @xmath47 are gnodes of level 1 . @xmath48 and @xmath49 belong to @xmath46 . @xmath50 and @xmath51 belong to @xmath44 . @xmath52 belongs to @xmath47 . + suppose the node @xmath48 sends a tracer packet in level 1 . , which is a bnode , to simplify the example ] the following will happen :    1 . the tp is flooded in @xmath46 . 2 .   @xmath49 receives the tp and appends in it the i d of the gnode @xmath46 . 3 .   @xmath49 sends the tp to @xmath50 . @xmath50 receives it , updates its maps and floods it in @xmath44 . all the node belonging to @xmath44 will receive the tp , updating their maps . this same procedure is reiterated from step 2 , i.e. @xmath51 receives the tp , appends the i d of @xmath44 and so on until @xmath52 receives it . @xmath52 , noticing that its gnode hasnt any links to other gnodes than @xmath44 , will bounce back the tp to @xmath51 and at the same time will flood @xmath47 . the tp , with the same procedure , will return back to @xmath48 , completing the tp cycle . in order to use the @xmath53 ( qspn v2 ) in high levels , we need to be sure that a tp , flooded inside a lower gnode , will reach once and only once all the nodes of the same gnode . moreover , a good metric needs to be defined for the high levels : what is the rtt ( round - trip time ) and bandwidth capacity of the link between two gnodes , how is it measured ? consider the situation in figure [ fig:3bnodes ] . a and b are bnodes of the node @xmath46 , while @xmath54 is a bnode of the gnode @xmath44 . suppose c sends a tp to b. b floods it inside @xmath46 , thus @xmath55 receives it . at this point , @xmath55 sends the packet to all its external links , and thus to @xmath54 . @xmath54 will send the packet again to @xmath56 and the cycle will continue . + this situation can be avoided if an ingress bnode , before forwarding a packet to a an external gnode @xmath57 , checks if the packet has already traversed @xmath57 itself . if it has , the bnode wo nt forward it to @xmath57 . we will refer to rem ( route efficiency measure ) , as a value characterising the quality of a route . rem can be calculated in various ways , f.e . by taking in account the total rtt and the bw capacity of the route . we denote the rem of a route @xmath58 as @xmath59 .      from the point of view of the qspn v2 , the levels are `` flattened '' , because the propagation of ctps ignore the subdivisions of the network in gnodes and levels . the structure of the network remains unchanged , subdvided fractally in gnodes , but the exploration of the ctp does nt . a ctp does nt consider a gnode as a single , homogenous entity . it propagates itself between the single nodes , tracing a precise route formed by single hops , until it is considered interesting . in this way every node will have its own personal route to reach a specific gnode . the memory limits are respected , because the ctp , once it jumped over the border of a gnode , deletes the specific details that were useful by the nodes of the gnode . + we ll know describe the rules of the flat levels . + suppose we want to explore the level @xmath60 ( we already know how to explore @xmath61 ) . let @xmath62 be the gnode of level @xmath4 . the generic rule of the qspn v2 in high levels is :    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ when an ingress bnode @xmath7 of @xmath5 receives a ctp from a neighbouring bnode of @xmath63 , it appends in the packet its ip . the packet , called _ locked tracer packet _ is then flooded inside @xmath5 . the ltp of level @xmath4 , is a packet that is propagated with the same rules of the ctp , i.e if it is nt interesting it s dropped , but that is nt updated while it explores the levels inferior to @xmath4 . when the egress bnode @xmath64 , of @xmath5 receives the ltp , it changes it in a ctp , appends the i d of @xmath5 and forwards it to all its neighbouring gnodes . _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _    detailed rules :    1 .   when exploring the level @xmath4 , each inferior level must been already explored . + to accomplish this , it sufficies that a node , before sending / forwarding a ctp of level @xmath4 has already sent / forwarded at least a ctp of level @xmath14 . if it hasnt , it will queue the ctp of level @xmath4 . 2 .   suppose that the ingress bnode @xmath7 belonging to a gnode @xmath5 of level @xmath4 , has received a ctp of the same level , sent by the gnode @xmath10 . the following will happen : @xmath7 makes copy of the ctp , marking it as a ltp , appends in it its ip and floods it in @xmath5 . if @xmath7 is also linked to a gnode different from @xmath10 , it will respect the rule [ ruleegressbnode ] for egress bnodes . [ ruleegressbnode ] suppose that the egress bnode @xmath64 of @xmath5 receives the ltp sent by @xmath7 ( see above ) . @xmath64 transforms the ltp in a ctp , deletes the ip added by @xmath7 and sets ( in the tp ) the rem of @xmath65 as : @xmath66 finally , it forwards the ctp to all its external rnodes . 4 .   a node @xmath4 of @xmath5 , uses the received ltp to learn that @xmath7 is a bnode bordering on @xmath10 and to find out the route of level @xmath4 contained in the packet . it considers the rem of the route to reach @xmath10 equal to @xmath67 in other words , it saves in its map that @xmath68 . + @xmath4 forwards the ltp to its rnodes without modifying it . 5 .   the ltp respects the same rule of the qspn v2 : it is forwarded by a node only if it is carries interesting information , otherwise it is dropped . a node @xmath4 consider the ltp interesting if one of the following conditions is met : * the ltp contains the ip of a bnode @xmath7 , which was nt already known by @xmath4 . * the ltp contains a bnode already known by @xmath4 , but that borders on a new gnode @xmath69 : with this ltp , the node @xmath4 learns that it can reach @xmath69 by passing through the bnode . * the ltp contains the information of the death of a bnode which was used by @xmath4 to reach some gnodes . * the ltp contains a new gnode , which was previously unknown . * the ltp contains the information of the death of a gnode . * the ltp contains an improved route to reach a gnode . + note : the first three conditions are used by the nodes to build and update the bnode map . [ rule6 ] recall the situation of rule [ ruleegressbnode ] . + when the value @xmath70 changes considerably , both @xmath7 and @xmath64 sends a ctp of level @xmath4 to their external nodes tells @xmath7 and @xmath64 of the rem change ] . the ctp contains the new @xmath71 value . every node which used @xmath5 as hop of some routes , will consider the ctp interesting . + this rule permits the update of high levels . [ rule7 ] when a bnode @xmath7 ( of any level ) , which is a gnode of level @xmath72 , loses its external link to the gnode @xmath63 of level @xmath73 , when all its bnodes of level @xmath74 loses their link to @xmath63 . this is a recursive definition . ] loses one of its external links of level @xmath4 , a ctp is sent in the level @xmath14 . the ctp contains the information regarding the lost link . the ctp is forwarded by all the ( g)nodes that used the bnode @xmath7 in one of their saved routes to reach the lost link . + if @xmath7 was the unique bnode of its gnode @xmath5 bordering to gnode @xmath10 of level @xmath4 , then the link @xmath75 becomes broken . in this case a ctp of level @xmath4 is sent by @xmath10 and by the other bnodes of @xmath5 ] . + a dying bnode is equivalent to a bnode which loses all its external links . the only difference is that a ctp of level 0 is sent to inform the nodes of its gnode . we ll now describe some rules by giving an example ( see figure [ figexq2 ] ) . for simplicity , we ll use the ip notation : @xmath77 indicates the single node @xmath78 belonging to the gnode @xmath79 , belonging to the ggnode @xmath80 . using the symbolic notation : @xmath81 . we are also assuming that the routes are symmetric . _ case 1 : a new gnode join . _ + we are exploring the level 3 , which is formed by the gnodes @xmath82 . the level 2 , of each gnode , has been already explored .    * the gnode @xmath83 has just created the link to the gnode @xmath78 . the new physical link is maintained by the two single bnodes @xmath84 . * the bnode @xmath85 creates a ctp of level 3 , appends in it the i d `` @xmath78 '' and sends it to @xmath86 . * the bnode @xmath86 receives it . * * it reflects back a new ctp to @xmath85 , appending in it the i d `` @xmath83 '' . * * it appends in the received ctp , its ip , marks it as a ltp and sends it to its gnode . the ltp contains the path @xmath87 . * * * the node @xmath88 , receiving the ltp , learns the following : @xmath89 is a bnode of level 2 that can be used to reach @xmath78 , and @xmath86 is a bnode of its own gnode which borders on @xmath78 . it also learns its own rem for the route to @xmath78 : @xmath90 @xmath88 continues to forward the ltp ( without modifying it ) . * * * the ltp reaches the node @xmath91 , node of @xmath92 . @xmath91 , from the ltp learns that : @xmath89 is a bnode of level 2 that can be used to reach @xmath78 . since the level @xmath93 has been already explored , @xmath91 already knows a route to reach @xmath89 . * * * the ltp having reached all the nodes of @xmath83 ceases to being forwarded . * the bnode @xmath85 receives the reflected ctp sent by @xmath86 . * * it appends in it its ip , marks it as a ltp and sends it to its gnode . * * * the ltp is propagated in @xmath78 ( in the same way of the previous ltp ) . * the bnode @xmath94 , which borders on @xmath79 , receives the ltp . * * it modifies it in a ctp : it removes the ip @xmath85 and appends the i d @xmath78 . the ctp is now @xmath95 . finally , it sets the first rem of the ctp : @xmath96 the ctp is then sent to @xmath97 , bnode of @xmath79 . * the bnode @xmath97 receives the ctp . it sends a ltp in @xmath79 . * the bnode @xmath98 , which borders on @xmath80 , receives the ltp . it appends @xmath79 in it and sends it to @xmath80 . the ctp is now : @xmath99 . * a bnode of @xmath80 receives it , and reflect it to @xmath79 . it sends also the ltp to @xmath80 . * * the reflected ctp is finally received by the node @xmath86 , which sends the ltp to @xmath83 and reflects the ctp to @xmath85 . the bnode @xmath85 , drops immediately the ctp , because it does nt contain any interesting information . * the exploration is completed . suppose that a tp has been flooded inside the gnode @xmath5 . suppose also that the node @xmath3 receives two duplicate packets . + the @xmath53 instructs the node @xmath4 to keep forwarding only the interesting packets . a packet , which is a perfect copy of a packet already received , is always uninteresting . therefore , the node @xmath4 will drop the second copy of the received tp . however , in this case the node @xmath4 should not consider the rem values saved in the tp , because two tps , which have crossed the same gnodes in the same order , might have different rem values . + in conclusion , whenever two or more tps , which have crossed the same high level route , are received by a node of @xmath5 , only one of them will be forwarded . in this way , the successive nodes will receive only one copy of the same packet . when a part of the network changes considerably , the maps of the involved levels must be updated . every node has its own radar , which periodically sends a broadcast request to all its ( physical ) near nodes . by collecting the replies , the radar is able to determine the active rnodes of the node and the quality of its links .      in level 0 , a ctp is sent every time a node joins the network , dies or every time the change of the quality of a link exceeds a predefined delta value . the ctp is also is restricted to the gnode where it has been originated : a bnode wo nt send it to external nodes . + when a node joins , it wo nt send a ctp , only its rnodes will . their ctp will be directed to the node . more formally : + if the node @xmath4 joins , that is if the node @xmath4 creates a link with the nodes @xmath100 , with @xmath60 , then a ctp will be sent by each rnode @xmath101 _ only _ to @xmath4 . this means that if @xmath102 is connected to a node @xmath103 , when @xmath4 joins , @xmath102 will send the ctp only to @xmath4 and not to @xmath103 . + this saves the propagation of two ctp in the following situation : @xmath104 suppose that the node @xmath56 joins . as a consequence of the rule we ve described , the node @xmath54 will send a ctp to @xmath56 and @xmath55 to @xmath56 , thus only two distinct ctp are generated . their path is @xmath105 and the reverse . if instead the node @xmath56 sends a ctp to @xmath54 and then @xmath55 to @xmath56 , two distinct ctp will explore the same verse : @xmath106 and @xmath105 , the same is for the reverse , thus , in total , four distinct ctp are propagated . + let @xmath107 be a link . if its quality changes @xmath56 will send a ctp to @xmath55 and vice - versa . + when a node dies , all its rnodes will send a ctp to all their rnodes . the ctp will include , as the first hop , the i d of the dead node , with a flag which indicates its death . for example : @xmath108 if @xmath55 dies , then @xmath56 will send the following ctp to @xmath54 : @xmath109 + in order to prevent false positives , the nodes wo nt immediately send the ctp , but will wait a small amount of time . only if the change persists , they will send it .      the dynamics for the update of high levels are mainly governed by rule [ rule6 ] and [ rule7 ] of flat levels ( see [ sec : flat ] ) . in this paragraph , we ll specify some details . + rule [ rule6 ] says : `` when the value @xmath70 changes considerably , a new ctp is sent '' . by considerably we mean that the difference of the current rem value with the previous one exceedes a predefined threshold . more precisely : let @xmath110 be a route of level @xmath4 . if @xmath111 then the route has changed considerably . @xmath112 is proportional to @xmath4 , in this way the nodes will be more sensible to minor changes of lower levels and they will consider only relevant changes of higher levels . + also in high levels , a bnode wo nt immediately send a new ctp , but it will delay it for a small amount of time . a new node joins the network when it has been able to create at least one physical link to an active netsukuku node and when it has correctly executed the hooking procedure . in this paragraph , we describe loosely the hooking phase of a new node . suppose that the node @xmath4 has established a physical link to at least one netsukuku node . in order to become an active netsukuku node , @xmath4 has to _ hook _ to its rnodes .    during the hook , @xmath4 will exchange vital information with its rnodes , it will choose its new ip and it will finally become part of a gnode . the hook procedure is formed by these general steps :    1 . the node @xmath4 chooses an ip in the range of @xmath113 . it launches the first radar to see what its rnodes are . if not a single node is found , it creates a new gnode and ends hooking phase . 3 .   at this point , @xmath4 asks to its nearer rnode the list of all the available free nodes presents inside the gnode of the rnode . + if the rnode rejects the request ( the gnode might be full ) , the node @xmath4 contacts another rnode . @xmath4 chooses an ip from the received list of free nodes and sets it on its network interface . @xmath4 will then download the external map from the same rnode . looking at the external map , it will be able to determine if it has to create a new gnode . if it has , it creates it and ends the hooking . @xmath4 gets the internal and the bnode map from the same rnode . @xmath4 launches a second radar and updates its routing table . 8 . all the rnodes of @xmath4 send a ctp to update the maps . when a node creates a new gnode , it will choose a random gnode i d , and thus a random ip . + suppose that two isolated gnodes get the same gnode i d . when they will be linked , they ll enter in conflict . + the solution to this problem is to let each new gnode hook as a normal node would . you can find more information about this in the ntk_rfc 001@xcite . * ` march 2007 ` * * description of the flat levels ( sec . [ sec : flat ] ) * * section [ sec : netdyn - level0 ] `` network dynamics - level 0 '' expanded . * * section [ sec : netdyn - leveln ] `` network dynamics - level n '' updated : the references to the pre - flatlevels rem metric have been removed . * ` october 2006 ` + initial release . 99 qspn document : http://netsukuku.freaknet.org/doc/main_doc/qspn.pdf[qspn.pdf ] netsukuku website : http://netsukuku.freaknet.org/ cidr routing : http://en.wikipedia.org/wiki/classless_inter-domain_routing[classless_inter-domain_routing in wikipedia ] ntk_rfc 001 : http://lab.dyne.org/ntk_gnodes_contiguity[gnode contiguity ]
in this document , we describe the fractal structure of the netsukuku topology . 
 moreover , we show how it is possible to use the qspn v2 on the high levels of the fractal . 
 this document is part of netsukuku . 
 + copyright 2007 andrea lo pumo aka alpt @xmath0alpt@freaknet.org@xmath1 . 
 all rights reserved . 
 this document is free ; you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation ; either version 2 of the license , or ( at your option ) any later version . 
 this document is distributed in the hope that it will be useful , but without any warranty ; without even the implied warranty of merchantability or fitness for a particular purpose . 
 see the gnu general public license for more details . 
 you should have received a copy of the gnu general public license along with this document ; if not , write to the free software foundation , inc . 
 , 675 mass ave , cambridge , ma 02139 , usa .