Re: [Tipc-discussion] How good is TIPC on various topologies ?

[Jon M. <jon...@er...>]

Hi,
First, about 64-bit addresses: The current node address format is
32 bit: 8 bits zone, 12 bits cluster and 12 bits node. So even
if driver.c reveives an int, it will not accept node numbers
above 4095.
Hence, to extend this to include an (Ethernet) MAC-address would require
a
node address size of 8+12+48 = 68 bits, not 64.

Neither does a TIPC node address map 1-to-1 on a MAC address.
In a system with redundant ethernets (or other bearers) a node address
will represent at least 2 MAC addresses, and theoretically up to 8. 

And, TIPC is no bound to ethernet only. There will soon be "MAC" 
addresses of 144 bits (TCP port number + IPv6 address) when we start
to carry TIPC over IPv6.

Conclusion: Not a very good idea, even if we disregard the 
compatibility issue, which can not be ignored.

For further responses, see below.


Kevin Kaichuan He wrote:


Will TIPC works well with the following topology ?



PC1       PC2        PC3

 |eth0     |eth0      |eth0

 |________hub_________|

Yes, this is the basic topology envisaged.








How about the following topology ? Will client

on PC1 reach server on PC4 automatically via PC3 ?



                        eth1              eth0

PC1       PC2        PC3--------- hub2 -----PC4

 |eth0     |eth0      |eth0

 |________hub1________|

Only if you define PC4 to be in a different cluster than the
rest, or a slave node. A cluster is per definition a domain 
where there is full connectivity. (Don't try this with the 
current code, that part of it is broken now, but it will be 
fixed.)






How about the following topology where a self-loop

exists ?

   eth1

PC1---------

 |eth0     |

 |________hub

  

You may never connect two TIPC activated interfaces from a node 
to the same switch. In this particular case it will do  no harm, since 
a node never tries to establish connections to itself.




How about the following toplogy where a loop between two

PCs exist ?  Essentially the following toplogy exists

when STP is turned off. If TIPC can tolerate this topoplogy

we may not need a underlying STP to resolve L2 loops.



  eth1           eth0

PC1---------  /----PC2---|

 |eth0     | /           |

 |________switch_________|

TIPC only uses the interfaces you tell it to use, so if you
configure the two nodes to use only one of their interfaces for
TIPC (any of them, -and you may of course still use both for 
IP traffic), it will work fine.

If, however, you try to activate both interfaces for TIPC, the result
will be utter havoc. Then the TIPC address of  PC1 will represent two 
interfaces on the same LAN, and the two links starting on PC2 will be 
very confused when they try to find their counterpart in PC1. Some
messages 
will come from link PC1/eth0, others from link PC1/eth1, and you will
see the two links starting wobbling up and down as result.

===> If you have two interfaces, and you want TIPC to use both, you must
also have two switches. (Anything else would not make sense anyway,
the whole idea with this is to avoid single point of failures.)

Regards /jon

 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.