Fwd: Don's edge routers

[Dennis Allard]

This is the follow up to my previous email in the thread having subject: Re: networking

This is my second point:

(2) INTRODUCE A CONCEPT OF EDGE ROUTERS THAT COULD AUGMENT EXISTING CISCO ROUTERS (et.al.)

(note the original date this email was posted)

---------- Forwarded message ---------
From: allard <all...@oceanpark.com>
Date: Wed, Dec 4, 2002 at 1:05 PM
Subject: Don's edge routers
To: Don Cohen <don-oc...@isis.cs3-inc.com>
Cc: K. Narayanaswamy <sw...@cs3-inc.com>

I felt a need to write up an abstract of Don's idea for
what I'm calling edge routers.   Here is that abstract.


Restatement of problem.

A problem is that high speed networks operate at speeds too fast to
permit implementing fair service by replacing the high speed routers
in those networks by CS3 linux routers, since the linux routers are
not fast enough.  In addition, network operators already have routers
in place and will resist replacing them by new technology.


Abstract of solution.

Network operators may be receptive to *augmenting* their existing
routing infrastructure by *adding* devices that significantly improve
the networks ability to thwart DDoS.

Don's solution targets the edges of high speed networks, where an edge
is the wire that connects a router of one network operator (e.g.
Sprint) to a router of another network operator (e.g. AT&T).  I will
call the routers at either end of such a high speed wire CISCO routers
(for obvious reasons, but think of it as an abstract label).

The basic idea.

What if things appeared to the CISCO routers as though every packet
coming in were *from* one of a very small number of source IP
addresses and to one of a very small number or destination IP
addresses?  Based on that reduced set of source/destination
combinations, it would be possible to use WFQ (Weighted Fair Queueing)
as part of a means to implement fair service to wires connecting the
network to the outside world.  Of course, real packets are from myriad
to myriad IP addresses.  So, the idea is to surround the CISCO routers
by proxy hosts which encapsulate the real traffic into traffic that is
from an incoming place on the edge of the network to an outgoing place
on the edge of the network.  In this way, WFQ can be applied.  The
devil is in the details.

The wire is high speed, so the solution involves splitting the wire
into N wires via a dumb switch to pump packets through what I will
call 'edge routers'.  An edge router a called a 'router' because it
does a very minimal type of routing, described below.

The basic idea then is that an edge router, Rin, accepts an incoming
packet, determines the corresponding edge router, Rout, via which the
packet will exit the operator network, then encapsulates the packet
and forwards it to the downstream CISCO router such that the CISCO
router thinks it is from Rin to Rout, enabling use of WFQ to provide
fair service.

In more detail...

Notation:  P[saddr, daddr] denotes a packet P having source IP address
saddr and destination IP address daddr.

When an IP packet P[s, d(P)] arrives on the high speed wire, it is
switched via dumb round robin to one of N edge routers, Rin. Rin
maintains a cache of destination IP numbers, DCACHE, mapping an IP
number to the corresponding edge router, Rout, via which packets
having that d(P) as destination exit the network (we assume that a
given destination IP address will be routed by the network to the same
outgoing edge wire for long periods of time.  Rin sees if d(P) is in
DCACHE.  If not (first time Rin has seen d(P)), Rin has no clue to
which Rout P should be sent to. In this first seen case, Rin
*discovers* Rout via a separate phase by first *semi-encapsulating* P
into a packet P1[Rin,d(P)].  P1[Rin,d(P)] is injected into the network
which routes it to *some* edge router, Rout.  Rout sees P1 and (via
special marking in the semi-encapsulation) knows to send a return
packet, P2[Rout,Rin], back to Rin that serves to inform Rin that all
packets having destination d(P) should be sent to Rout.  Rin uses that
information to update its cache with 'd(P) => Rout.  Once that is
done, things proceed as normal for the rest of the processing of this
first packet having destination d(P) and all subsequent packets having
destination d(P) as follows.  P is encapsulated into a packet
P3[Rin,Rout] and injected into the network.  The network will then
route P3[Rin,Rout] to Rout which (via special marking in the
encapsulation) will know to unencapsulate and forward the original
P[s, d(P)] to a switch that forwards the outgoing packet out on a high
speed wire.

The CISCO infrastructure will therefore only see traffic that appears
to be from one edge router to another edge router.  Since the
population of edge routers is relatively finite, it becomes possible
to use WFQ to control the amount of service given to the various
combinations of source and destinations that will exist in all packets
(except the special semi-encapsulated ones).  Since all traffic on a
given wire is encapsulated, all such traffic will be subject to an
amount of service determined by WFQ.

Assumption and Questions
------------------------

I think the idea is to have each incoming high speed wire be one
'place'.

Can Rin use knowledge to a connected PEIP neighborhood to proxy as
more that one source address in order to use WFQ to allocate service
to > 1 upstream place?


--
Dennis G. Allard                               telephone: 1.310.399.4740
Ocean Park Software                                 http://oceanpark.com
________________________________________________________________________

[Dennis Allard]

There was one optimization that bears mentioning:

Dennis wrote, in a  follow up to of my message to Don:

An obvious optimization, which you probably either already
told me about or would have, is that the semi-encapsulated
packet need not be resent via a full encapsulation since
Rout can just go ahead and forward it as if it had been
fully encapsulated, in addition to replying to Rin so Rin
can update its cache.

This has the added advantage of solving the problem of
what happens when more than on packet to d(P) arrives
at Rin before Rin gets back a reply to the first semi-
encapsulation.  It just keeps sending semi-encapsulations
until it gets back a reply and updates the cache.