Mikrotik & OC-3 Connection

Sun Jul 4 18:28:47 UTC 2010

OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router
thread.

To make it clear where I'm coming from, I see the networking world from
the viewpoint of non-Ethernet WAN interfaces.  A world consisting of
nothing but Ethernet is too bland and boring for me to live in, and I
choose not to live in such an Ethernet-only world.

I do indeed like the good old ifconfig & route better than Cisco IOS
stuff: it's simpler, makes more sense to me, and fits my simple needs.
However, this model works well for Ethernet because it's very simple:
with Ethernet one generally has a 1:1 correspondence between the
physical hardware unit and the logical "network interface" unit visible
to ifconfig and the rest of the BSD/Linux network stack.  But that is
most definitely not the case for non-Ethernet WAN interfaces, and that
is where I see a big shortcoming in what's currently available in the
Linux router world.

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
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.

* 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.

* 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".

* 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 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.

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.)

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. :-)

MS