Re: Networking design proposal

[Hisham Kotry]

--- Niels Möller <nisse@lysator.liu.se> wrote:
> Michal 'hramrach' Suchanek <hramrach_l@centrum.cz>
> writes:
>  
> The interface for reading raw ethernet frames should
> primarily filter
> on ethernet type code and ethernet addresses. If
> there are several
> processes (say, two completely independent
> ip-stacks) that want to use
> the same ethernet hardware and the same ethernet
> address, then the
> simplest way is to have the ethernet driver deliver
> each received
> frames to *both* processes.

With two in-dependent ip-stacks you'll probably need
to do more work on the socket interface, as each would
act on every call to any function of the socket API.
Besides, a stack started after another wouldn't know
about the currently exsisting connections and would
probably tear-down connections with RST or FIN packets
(assuming TCP) to the sending host, while it shouldn't
have, the case of having two seperate stacks
implementing the same L3 protocol on the same NIC
doesn't seem feasible to me, nor usefull.

> Or you can do something more clever with filters
> that look into packet
> contents (I've heard that some network cards even
> has some hardware
> support for that), but if you do that I think you
> want a nice general
> interface, and not code knowledge about the inside
> of ip packets into
> the ethernet driver.

Well, smart NICs support hardware classification, and
you could implement the hardware-type/mac-address
registration in either software or hardware thru the
same interface assuming device drivers will have some
logic (well, they will anyway, atleast to support
multiple protocol-stacks they'll need to do some basic
early demultiplexing). One nice (patented) apparoach
taken by Solidum[1] is to give their NIC a packet
description in a high-level language to tell it what
you're interested in. The patent prevents you from
using *their* language to do it, but it doesn't mean
you can't do it in another form, infact Cisco sells
PDLM modules for their high-end routers nowadays.

> > But that is why they register their IPs with L2,
> isn't it? You need the 
> > same for an ordinary ip packet.
> 
> They layer 4 code will register the ip addresses
> it's interested in,
> in some way or the other, with the layer 3 code.

Doubt that, it'd be nicer if they just register
themselves by providing a function that'd be called
whenever the number they're interested in appears in
the IP-protocol field. I don't see why a L4 transaltor
would want to view/ignore any specific packet.

> But
> I don't think the
> layer three code should need to know about port
> numbers (just like I
> don't think the ethernet driver should need to know
> about ip
> addresses). In both cases a general interface for
> matching packet
> contents would be nice, but it shouldn't be added
> unless it's really
> needed.

It could be done, but its use would be optional to
every translator (and the one below it). One previous
ULN used a function that took a packet anda
description as arguments, it returned a parse tree of
the packet's contents, this -as stated in the
project's presentation- reduced protocol development
time while having acceptable performance, the main
point was that TCP/IP wasn't complicated (and thus
never needed such an apparoach) but other protocols
are and such an apparaoch would save protocol
developer's trouble with offsets, alignment,
bit-shifting etc.. People are weird.

Anyway, it seems weird to discuss any implementation
wories now without having a basic design for the
buffer pool manager, the packet format (anyone recall
all those flame-fests about mbufs vs. skbs?), reducing
the amount of context switches (going back and forth
between the stack and device driver) assoctiated with
routing in ULNs? etc.. [2]

We shouldn't argue how L4 translators(or modules for
that matter) would interact with L3 when we don't even
have a decent interface for buffer handling.

Just my opinion,
kotry

[1]
http://www.alternic.org/drafts/drafts-n-o/draft-nossik-pax-pdl-00.html

[2]http://www.zib.de/hupfeld/Diplomarbeit.pdf

> I don't see that as a problem. In fact I would
> expect the generation
> of host-unreachable and connection-refused to
> usually happen at
> different *machines* (the destination of my packets,
> and some router
> on the (broken) path across the network,
> respectively). So having them
> sometimes be generated by different processes on the
> same machine
> doesn't seem odd to me at all.
> 
> Regards,
> /Niels
> 
> 
> _______________________________________________
> Bug-hurd mailing list
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2