Subject: Aggregation of Internet Integrated Services State

From: Steven Berson <[email-masked]>
Date: Wed, 18 Mar 1998 17:21:21 -0800 (PST)

A more polished version of our work on aggregating internet
integrated services state is available from

	http://www.isi.edu/~berson/iwqos.ps

Since this scheme is based on autonomous regions and RSVP, much more
flexibility is achieved than the differentiated services schemes that
are being proposed.  This flexibility will prove to be necessary as
demands for new types of network service qualities arise.

The abstract is included below

	The Internet Integrated Services (IIS) architecture has a
	fundamental scaling problem in that per flow state is
	maintained at all routers and end-systems supporting a flow.
	This paper examines the use of aggregation as a technique
	to reduce the amount of state needed to provide IIS.  In our
	approach, routers at the edge of a region doing aggregation
	keep detailed IIS state, while in the interior of this region,
	routers keep a greatly reduced amount of state.  Packets will
	be tagged at the network edge with scheduling information
	that will be used in place of the detailed IIS state.
	The aggregation scheme described will allow large scale
	deployment of IIS without overloading routers with state and
	associated processing.

Steve

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 21 Mar 98 0:57:59 JST

Steve Berson;

> 	http://www.isi.edu/~berson/iwqos.ps

..... OK. You have been still working on it.....

I'm afraid your are a victim of common mistake that aggregation
is easy by ignoring all the important differences as long as you
don't have to seggregate.

However, the seggregation is inevitable.

To make the seggregation possible, some information must be
preserved with some rigid structure, which needs a large table
(beyond domain boundary, for examle) to cause scalability problems
(to destroy all the false merit of inter/intra domain separation).

Or, the seggregation point must perform IP header checking on
all packets of a flow consulting an unaggregated table. On border
routers, where performance is needed most, all the packets of
all the flows must be checked that way.

With multicast shared reservation, the problem is a little more
obvious. That is, policing after merging MUST be done with a
seggregated merged flow.

Another notable mistake like yours is Yakov's topology driven
label switching, which must actually look up routing tables
in destination domains on demand, that is, is flow driven.

						Masataka Ohta