[26202] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: A call for the future. Was: Re: Verio Decides what parts of the

daemon@ATHENA.MIT.EDU (Andrew Bender)
Thu Dec 9 13:21:34 1999

Message-ID: <384FF2B1.34D4E49E@tns-inc.com>
Date: Thu, 09 Dec 1999 13:19:29 -0500
From: Andrew Bender <abender@tns-inc.com>
MIME-Version: 1.0
To: gherbert@crl.com
Cc: nanog@merit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu


In the design of contemporary core routers, table maintenance and packet
processing are discrete functions. 

The maintenance of comprehensive routing information that includes a superset of
best paths is common practice, with proven benefits. However, it is neither
necessary nor desirable to consult this database for a forwarding decision.
Instead, the fastpath need only have knowledge of the best next hop matching a
DA prefix. 

Whatever changes we believe to be in store for the table population, this is
unlikely to affect the typical number of adjacencies for a core router. Assuming
also that  we continue to use IPv4 for a while, the "input length" of composite
information for the FIB could be less than 7 bytes for unicast routes. For the
2.5E5 best paths discussed, this equates to approximately 1.4MB. 

Also, since the matching (ideally) yields a singular, exclusive result, this
matching operation is easily "parallelized" , in hardware or otherwise; observed
work need not even be linear with FIB size.

In short, the technical obstacles presented by high table / route population are
no greater for forwarding logic than for the control plane.

Regards,
Andrew Bender
Total Network Solutions, Inc.

> Date: Mon, 06 Dec 1999 18:27:07 -0800
> From: George Herbert <gherbert@crl.com>
> 
> The issue isn't in storing hundreds of thousands, millions,
> or tens of millions of routes.  This is, all things considered,
> a piece of cake.
> 
> The issue is getting the route out of storage, for each packet coming
> through the router, at a rate of millions of packets per second for
> each core router.  Each IP core router is doing about the same
> lookup work as the whole combined PSTN network is for all of its
> freely routed numbers.  It is, or should be, quite viable... but not
> easy, as we've all found.
> 
> - -george william herbert
> gherbert@crl.com
>


home help back first fref pref prev next nref lref last post