The Routing Over Large Clouds Mailing List Archive by date

[Craig Partridge <craig@aland.bbn.com>]

Hi folks:

Allison Mankin kindly forwarded to me some notes from this list which
had questions about the Integrated Services and RSVP WG's activities.

I can't speak for RSVP, but let me try to summarize very briefly what's
up in INT SERV.

We're in the very late stages of proposing a set of standards that make
it possible to request special services from routers on behalf of flows.
That last sentence was carefully crafted -- the idea is that some entity,
a host, a network management station, a user sitting at a router's console, 
asks the router if it can support a particular quality of service for a
particular flow.  RSVP is developing a setup protocol that allows applications
to make these request end-to-end, by talking with a series of routers in
a path.  INT SERV is primarily focussed on what happens at each router and
is agnostic about what set up mechanism is used.  (If one wants a justification
for this idea -- one might imagine that, beyond RSVP -- which sets up
flows dynamically, one might imagine something like IP PVCs, in which a
management station creates a permanent flow between two points).

I should note that INT SERV is currently planning to issue specs for three
different styles of service: controlled delay (in which the router simply
promises to manage your delay a bit), predictive service (in which the
router promises to manage your delay and tells you what range of delays
to expect), and guaranteed (in which the router makes a firm promise 
about the maximum delay your traffic will receive).  The specs indicate
what information needs to be given to a router to request using a service
with a given QoS, and how the router is to behave if it accepts the
request.

INT SERV will also issue a spec for a flow spec, which is a data structure
intended to allow you to specify the service (controlled delay, predictive,
or guaranteed) and QoS you desire.

After these specs are done, one of the next fun challenges is to work with
the various MAC layer experts to determine how IP-layer QoS will get mapped
to MAC layer QoS (e.g., how to map the INT SERV QoS into an ATM Q.2931
Call Parameters; how to use 802.13's features for guarantees; how to handle
MAC layers that can only partially provide guarantees, like Ethernet).
Several people have already been working on these problems, and so far
they look tractable -- to take an easy example, the IP QoS for all the
services so far uses a token bucket to express traffic behavior -- and
as we all know, token bucket maps perfectly into ATM's GCRA algorithm, so
mapping IP to ATM should not be horribly difficult (famous last words...)

Craig