Mikrotik & OC-3 Connection

Mon Jul 5 00:40:59 UTC 2010

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 -