PC Router Research Tool
What is a PC Router Research Tool?
The PC Router is a tool for investigating new routing algorithms. The
fundamental idea is to use a dual-processor PC system to facilitate the
development of router code. One processor runs unix and the other processor
is dedicated to routing.
This implementation is based on FreeBSD and uses Intel Pro 100/B network cards.
The router processor runs a loop polling a list of devices to see if there
is work to be done. There is supporting code in the driver and minor
modifications to the boot-up code and the TCP/IP protocol code. The protocols
themselves are not changed, only which code runs on which processor.
Design Info - Packet Flows
There are several packet flows to consider. The simplest flow to understand
is routed packet: a packet arrives on an interface, its destination is looked
up in the routing table, and it is sent out an interface.
The minor variations on this are
- A packet arrives destined for the unix processor
- A packet is generated by the unix processor
- A packet's destination is not in the routing table
In the case of the locally generated outbound packet, the router processor
sends it to the appropriate interface.
In the case of the locally destined packet, the router processor queues
it to the unix processor and sends an interprocessor interrupt to the unix
processor.
In the case of the unroutable packet, the router processor also queues it
to the unix processor, sends an interprocessor interrupt, and lets the
full-fledged routing code in the unix processor deal with the packet.
More Design Info - Buffer Management
At boot up time, each interface has several mbufs assigned to it. Each
mbuf is tagged with the id of the interface to which it belongs. Initially
an mbuf is set up to receive data on an interface. When it is full, it
is queued to other subsystems for further processing and is, probably,
enqueued on an interface for transmission. When the transmission is complete,
the mbuf is returned to the interface that owned it originally.
What were the hard parts?
Conceptually this tool was straight forward to design. The challenges
were
- Understanding Intel's I/O Apic Architecture, which describes how
interrupts are managed.
- Figuring out that some of the interprocessor interrupts were getting lost
- Realizing that the version of FreeBSD that I was using considered some of
my hardware to be rogue and it didn't program the clock properly which
looked like the system console wasn't working. Luckily later versions of
FreeBSD had the fix and I could easily retrofit it.
- Realizing that I had to be majorly careful with MBUF flags.
- Figuring out that the interprocessor interrupt handler code didn't
save all the registers.
What's left to do?
- Measure the throughput and latency of this system
- Upgrade the existing (Intel) driver to support the current Intel cards
- Upgrade it to a more recent release of FreeBSD
- Add more drivers
Questions and comments to Dorothy Curtis
dcurtis@lcs.mit.edu