[Bridge] bridge protocol family

[Bridge] bridge protocol family

[Benoit PAPILLAULT]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello there,

I've been studying routing protocol during my studies, like OSPF, BGP, 
EGP, IGP, RIP, OLSR...... All those protocols are based on the routing 
table concept and each of them has its own way to compute routing table 
which is then used by the Linux kernel. But this is for IPv4 (or IPv6), 
ie layer 3.

I'm new at layer2 and I've read 802.1D-2004, learning STP and RSTP. I'd 
like to know if there are some other protocols (be it standard or 
proprietary) that achieve this goal of connecting layer2 cloud. Is there 
a concept of routing table at layer2?

Regards,
Benoit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIMdl+OR6EySwP7oIRArESAJ4w5908pH7Z9IRAQOwz3wdcftA84wCePfkK
vBX9yupof+1IXip3C8q0OOo=
=rLUK
-----END PGP SIGNATURE-----

Re: [Bridge] bridge protocol family

[Malcolm Scott]

At 21:48 yesterday, Benoit PAPILLAULT wrote:

> I'm new at layer2 and I've read 802.1D-2004, learning STP and RSTP. I'd
> like to know if there are some other protocols (be it standard or
> proprietary) that achieve this goal of connecting layer2 cloud. Is there
> a concept of routing table at layer2?

This is somewhat off-topic for the list but I'll answer anyway...

Most existing layer 2 protocols don't do routing.  The closest thing an 
Ethernet switch/bridge has to a routing table is the MAC address table, 
indicating on which port a particular host can be found.

There have been efforts to add IP-style routing to layer 2 (Rbridges etc., 
and indeed my own work which is yet to be published) but they're not in 
common use and were never adopted as standards.

If you're interested in this topic, I suggest we continue this discussion 
off-list.

Malcolm

-- 
Malcolm Scott
Research Assistant
University of Cambridge Computer Laboratory

[Bridge] New Custom Protocol on Ethernet Layer

[Zoran s]

Hi everyone,

I need a help. I started recently investigating
ethernet layer. I have specific problem to solve. I'll
try to describe this problem, so you can see what is
all about. I do not know if this problem belongs to
bridging, certainly by its definition it is close to
it.

I have some ideas how to do this. But I would
appreciate any thought you might have, any direction.

The problem: there are number of workstations (up to
200) connected by LAN - ethernet, and they all are
running an application which is in need of real-time
updates. Within every timer tick defined (2
miliseconds) every workstation needs to communicate
certain data (broadcast) so all others can take these
data, compute data via algorithm and store such data
in their own proprietary database. The round time is
the same time (all 200 stations need to communicate
their data in this time frame).

One of the solutions to the problem will be to write
specific application in user space (choose some spare
ports, make UDP datagram and send it over as IP
broadcast). But I am affraid the turnaround time might
change from 2 miliseconds to 0.5 miliseconds, even
less. Then the Real Time processing could become an
issue.

Instead using user space, I think the better way to
handle this problem is to keep data inside the
ethernet layer itself. Saying this, the solution to
this problem will be to create specific customised
vendor destination address which will act similar to
broadcast (well known all ones) mechanismus, so each
workstation receiving this packet will be delivering
data to the specific for this case database cash,
embedded in ethernet layer, same way ARP works. The
application can access the data through driver
mechanismus (bypassing higher layers of IP protocol
stack), specificaly written for this case.

I start looking and exploring /net/core/dev.c, but I
don't see ARP entry code in there. Could anybody,
please, give me an advice where to look for ARP
resolution so I can explore further implementation
changes inside the kernel protocol stack (I need to
add entry which will do similar things).

The reason I sent this @ is that I think the bridging
implementation is in the same set of files (very close
to ARP), as a different option, so somebody might know
where to fit the entry for the idea I just described.

If there are misconceptions in my @ I appologise for
my ignorance related to this matter.

Best Regards,
Zoran



      

Re: [Bridge] New Custom Protocol on Ethernet Layer

[Stephen Hemminger]

On Fri, 30 May 2008 06:32:41 -0700 (PDT)
Zoran s <s_zoran@yahoo.com> wrote:

> Hi everyone,
> 
> I need a help. I started recently investigating
> ethernet layer. I have specific problem to solve. I'll
> try to describe this problem, so you can see what is
> all about. I do not know if this problem belongs to
> bridging, certainly by its definition it is close to
> it.
> 
> I have some ideas how to do this. But I would
> appreciate any thought you might have, any direction.
> 
> The problem: there are number of workstations (up to
> 200) connected by LAN - ethernet, and they all are
> running an application which is in need of real-time
> updates. Within every timer tick defined (2
> miliseconds) every workstation needs to communicate
> certain data (broadcast) so all others can take these
> data, compute data via algorithm and store such data
> in their own proprietary database. The round time is
> the same time (all 200 stations need to communicate
> their data in this time frame).
> 
> One of the solutions to the problem will be to write
> specific application in user space (choose some spare
> ports, make UDP datagram and send it over as IP
> broadcast). But I am affraid the turnaround time might
> change from 2 miliseconds to 0.5 miliseconds, even
> less. Then the Real Time processing could become an
> issue.
> 
> Instead using user space, I think the better way to
> handle this problem is to keep data inside the
> ethernet layer itself. Saying this, the solution to
> this problem will be to create specific customised
> vendor destination address which will act similar to
> broadcast (well known all ones) mechanismus, so each
> workstation receiving this packet will be delivering
> data to the specific for this case database cash,
> embedded in ethernet layer, same way ARP works. The
> application can access the data through driver
> mechanismus (bypassing higher layers of IP protocol
> stack), specificaly written for this case.

You don't need to do it in kernel to get real time performance.
You do need to have all nodes using something like the Linux-rt
kernel (http://rt.wiki.kernel.org/index.php/Main_Page) and use
appropriate QoS (see IP_TOS), and make sure all your infrastructure
is capable.

> I start looking and exploring /net/core/dev.c, but I
> don't see ARP entry code in there. Could anybody,
> please, give me an advice where to look for ARP
> resolution so I can explore further implementation
> changes inside the kernel protocol stack (I need to
> add entry which will do similar things).

ARP is handled by the dst (route cache), not a recommended
place.

> The reason I sent this @ is that I think the bridging
> implementation is in the same set of files (very close
> to ARP), as a different option, so somebody might know
> where to fit the entry for the idea I just described.

No bridging is handled by br_hook.

> If there are misconceptions in my @ I appologise for
> my ignorance related to this matter.
> 
> Best Regards,
> Zoran
> 
> 
> 
>       
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge