On Sun, Jul 04, 2010, Michael Sokolov wrote:
> OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router
> thread.
It's ok. I'll trade you Russian for Australian currency. I don't know
which is going to be better in the long run.
> With non-Ethernet WAN interfaces one really needs an extra layer of
> highly configurable software functionality sandwiched in between the
> hardware interface unit and the ifconfig layer. The physical hardware
> interface is a synchronous serial bit stream processor that sends and
> receives either HDLC frames or ATM cells, and that is where the
Hey, sounds like FreeBSD's NetGraph!
> hardware-dictated part ends. Let's take the case of HDLC as it's more
> pleasant than ATM: in the case of HDLC the software layer between the
> HDLC controller and the ifconfig layer needs to do the following:
>
> * Let the user choose the encapsulation, and there are many choices:
> Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR
> (RFC 1973), ATM FUNI, etc.
ng_<encapsulation_module>
> * If it's a Frame Relay encapsulation, let the user configure DLCIs.
> Oh, and there can be more than one, hence there may be multiple
> ifconfig-able entities on the same FR interface.
ng_<some other module>
> * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated
> and true routed circuits; our software layer should support both, as
> as well as the possibility of mixing the two on different FR interfaces
> or different DLCIs on the same interface. These two modes need to
> look different to the ifconfig layer: if it's a bridged encapsulation,
> ifconfig needs to see a virtual Ethernet interface ("virteth0" or
> "macwan0"); if it's a true routed encapsulation, ifconfig needs to see
> a MAC-less and ARP-less point-to-point interface like "ipwan0".
ng_bridge, IIRC
> * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation)
> if the underlying hardware is capable of both (like Freescale MPC862
> and MPC866). Let's provide a user to switch between the two with a
> simple software command, and let's provide as much commonality as
> possible between the two configurations: let's support all RFC 1483
> encapsulations on HDLC via FUNI, but make the configuration commands
> look just like ATM. Let's also support FRF.5 by allowing one to take
> an ATM PVC and treat its payload as a virtual HDLC interface, with
> possibly many FR DLCIs inside.
I think there's ng_<atm> stuff; I could be wrong. There should be functional
ATM code in FreeBSD and if so, I'd be surprised to find it isn't linked into
netgraph.
> I would love to be corrected on this, but I am not aware of anyone having
> implemented all of the above for Linux (or for any BSD variant) in a
> clean and generalized manner. Instead what we see is that each vendor
> of a PCI card for some non-Ethernet WAN interface has their own ad hoc
> solution which typically comes nowhere close to what I've outlined above
> in terms of generality and flexibility.
FreeBSD netgraph. It's clean, it's generalised, it's just not very well
documented.
> Now here is something I'd like to build which will attempt to solve this
> mess. I'd like to build a modular WAN router based on the MPC866 chip
> from Freescale, former Motorola. MPC866 is a PowerPC with one very neat
> twist: it has 4 serial communication controller (SCC) cores on chip.
> Each SCC has a traditional 7-wire serial interface coming out of it (Rx
> data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both
> HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell
> delineation for a raw bit stream and octet-by-octet cell delineation for
> use with a framer that provides octet boundaries.)
Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn
FreeBSD into it somehow, help tidy up the code to do whateveer you need
and start leveraging the very powerful network stack FreeBSD has.
FreeBSD-head has support for multiple routing tables which I believe
you can just dump netgraph interface nodes into to support VRFs.
I'm peripehrally doing something similar as a prototype using FreeBSD/MIPS
on ubiquiti hardware - but I'm mostly squeezing my squid fork onto it
and making it work "right". :)
Adrian
> My modular router would be rather unique in that the interface to the
> pluggable WAN modules would not be PCI or anything of that sort, instead
> it would be the 7-wire serial interface coming from an MPC866 SCC, and
> there would be 4 possible daughtercard slots corresponding to the 4 SCCs.
>
> When the interface for pluggable WAN modules is something like PCI, the
> HDLC or ATM (including SAR) core has to be reimplemented anew by everyone
> who wants to build a new WAN module for a different flavor of Layer 1
> physical interface, and I find it wasteful. The proliferation of such
> reinvented-wheel HDLC/ATM reimplementations is precisely the reason why
> there is no universally-accepted standardized framework for non-Ethernet
> WAN interfaces in Linux or *BSD.
>
> But if the cores implementing HDLC and ATM SAR reside inside the CPU
> chip like they do with MPC86x processors, we can have ONE well-written
> generic driver for these cores, and it will work exactly the same way
> and provide exactly the same array of configurable Layer 2 options to
> the user regardless of which Layer 1 interface is used: we can build
> daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized
> circuitry on each of these daughtercards will only concern itself with
> Layer 1, not with HDLC or ATM SAR.
>
> I would greatly appreciate any leads/ideas/suggestions as to who might
> possibly be interested in funding such a project. :-)
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
