[RRG] ID: SRAM-based IP forwarding eliminates the need for Route Aggregation

[Robin Whittle <rw@firstpr.com.au>]

I have written "draft-whittle-sram-ip-forwarding-01" (30 March 2007)
which is best accessed at:

  http://www.firstpr.com.au/ip/sram-ip-forwarding/

since at present, the IETF system only has version 00.


I propose a simple Static RAM based architecture for the packet
classification system of all routers in the Default Free Zone -
ideally to be a standard part of new high-end routers from 2010
onwards.  This would not replace the current forwarding system, but
would enable each router interface to classify Internet user
traffic packets in a single clock cycle, determining which interface
each packet should be sent to.  This is less computationally
intensive than handling an MPLS packet.

Once these routers are widely deployed, address space can be
assigned and prefixes advertised without concern about route
disaggregation.

This will allow much greater flexibility in address utilisation,
including freedom to advertise IPv4 subnets down to /24 without
regard to network topology.  This won't solve every problem in
routing and addressing, but I think it will solve the most difficult
one: the need for rapid forwarding of each packet according to the
rules for potentially millions of separately advertised prefixes.
Routers will still need larger RIB CPU and memory capacities to
handle the much larger number of BGP advertised prefixes which this
proposal is intended to bring about.  There are also potential
difficulties with the stability of BGP with a greatly increased
number of routers and advertised prefixes.

The system can classify incoming packets at 250 million packets a
second, using 7/8 of a single 72 Mbit Static RAM chip for each
interface of routers with up to 14 interfaces. These chips are
currently in mass production and cost about USD$70.  Power
consumption would probably be about 1 watt for a 40Gbps interface.
Two chips would be needed in each interface for routers with between
15 and 510 interfaces.

For IPv4, the system provides a separate memory location to hold the
Forwarding Equivalence Class (FEC) for each of the 14,680,064 /24
prefixes from 0.0.0.0 to 223.225.225.0.  The idea is to handle all
Internet user packets in the DFZ in this way, with the few packets
(such as for inter-router traffic) whose forwarding is governed by
rules for prefixes longer than /24 being handled by the router's
conventional packet classification techniques.  Each /24 in which
conventional techniques needed to be applied would be flagged as
such by having a particular value of FEC in that /24's SRAM location.

The 32 bit IPv4 address length and the convention of limiting BGP
prefixes to no longer than /24 result in 24 bits of address to
consider when determining which interface to forward each packet to.
 It is a fortunate coincidence that this is ideally suited to
current production SRAMs.

For IPv6, FEC depends on too many address bits for this SRAM
approach to be practical.  I propose some alternatives, such as a
special subset of 2000::/3 in which routers would use SRAM
forwarding.  This address space would have no requirement for route
aggregation, and I anticipate that in the long term most IPv6
traffic would migrate to this range.  It may
be possible to have a good IPv6 arrangement - such as SRAM IP
forwarding for 2 million /35s, each of which provides 8192 /48 user
networks, (16 billion user networks) - simply by using the 1/8 of
the SRAM which is not required for IPv4.

This would allow Provider Independent address assignments for
hundreds of thousands of ISPs and AS end-users, for both IPv4 and
IPv6, with fast, low-power packet forwarding no matter how much the
address space is broken up for BGP advertised prefixes, within the
/24 or /35 limits.  One important benefit of the new scheme would be
that addresses could be assigned by RIRs in small increments to ISPs
and AS end-users, since it would not matter how much route
disaggregation results.  This would make it much easier to use
available address space efficiently, since there would be no need to
assign big blocks based on a several year projection of each user's
needs.


I have a background in electronics, programming,
telecommunications technical writing and privacy advocacy.  I have
worked on telecommunications standards committees, but I have not
been involved in the IETF before.

This is an unusual proposal: to coordinate router design, Internet
address management policy and BGP routing policy according to the
capacity of specific memory chips.  I hope you find it interesting!


 Regards

  - Robin


 Melbourne Australia      http://www.firstpr.com.au/ip/







--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg