North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Routing, Forwarding, and the Legacy Internet
- From: Jim Fleming
- Date: Sun Sep 13 12:56:58 1998
From: John M. Brown <firstname.lastname@example.org>
To: email@example.com <firstname.lastname@example.org>
Date: Sunday, September 13, 1998 4:34 AM
Subject: Clean up your annoucements! Re: The Cidr Report
>Yup! (I agree with both of your points! :) )
>We should allow /24's into the route system and it wouldn't be as big of
>a deal if folks like AS701 and others cleaned up there routes.
>Many rural providers are going to be multi-homing and thus we are going
>to see an increase of /24 - /20 blocks.
You mention the "route" system. Many people feel that
the Internet does routing, when it really mostly does
forwarding. Imagine yourself standing inside of a busy
back-bone router. Packets arrive with a source and
destination address which are not likely local. Your
task is to forward the packet on the proper interface.
You do not add anything to the front of the packet to
"route it", you just forward it to the next best place
where the process happens again, and again, etc.
It is very unfortunate that routers from behind-the-times
companies are not designed to handle the large tables
required to do forwarding. Since you have suggested
that more /24s be allowed, you might want to consider
a different type of software design to handle a worst
case scenario. Let's imagine that ALL possible /24s
needed to be supported. Let's also imagine that your
forwarder (not router) could have up to 256 interfaces.
With 24 bits and a 1 byte wide table, you would need
16,777,216 bytes to describe all possible /24s and
the interface a packet should be forwarded on. That
is not a lot of memory in this day and age. Also, once
the table was filled in, the lookup would be very fast.
A packet would arrive, you would look at the most
significant 24 bits of the destination, pull out the 8
bit interface id and place it on the queue for that
interface to be forwarded as soon as the link was
Unfortunately, router companies do not build devices
that forward very well, and they also do not build
devices that do routing very well. Before we look at
routing, we should observe that most of the current
routing companies organize their route tables based
on assumptions about a sparse number of entries.
Because of that the algorithms can not be fast and
the processing required to make adjustments to their
data structures can be much greater than simple
changes to our hypothetical, brut-force, table above.
Because, of poor engineering and design assumptions
from the 80's when memory and processing was not
cheap, Internet network operators are stuck living
in a world where the rules are biased toward the
ancient legacy systems. Those rules not only help to
keep people in the mind-set where they buy the
legacy equipment, the rules also make it such that
large, legacy-laden, network providers are favored
over the small, more leading-edge ISPs.
In my opinion, this will all soon come to a point where
people realize that the Internet needs more routing
and less emphasis on forwarding. Sure, people could
try to get companies to build systems that forward
better, but that may not have as large a payoff as
the move to routing. Routing will likely work best at the
edges of the net and not in the core. Routing will
require more intelligence than forwarding. Routing
will be more involved in QoS and optimizing the
balance in ATM circuit switching and IP forwarding.
When the two are combined with processing power
and more sophisticated protocols, true routing can
occur. In the meantime, you are stuck with forwarding
and with machines that do not support the notion
that a huge number of /24s can be advertised.
Some day, this may not be the case.
Unir Corporation - http://www.unir.com