int-serv over e.g. ATM

[Mark W Garrett <[e-mail]>]

In the recent discussion of IP with QOS over ATM with QOS
(which migrated from rolc to int-serv), there seems to be
some confusion about APIs and the relation between the two
technologies with respect to QOS/Traffic.  I see comments
that suggest that people think RSVP or int-serv *is* the
API, or that they are somehow protocol layers in a stack
that the data pass through.

My understanding is that the API is a piece of software in
the O.S that hooks to the application, interprets the
needs of the application, and formulates a message to send
across the network.  That message reserves resources and
describes the QOS and traffic characteristics of the flow to
the various network elements.  RSVP specifies the syntax of
such messages, and int-serv provides the semantics of the
message, and perhaps a bit more about what happens on the
API side and in the network element.  The data itself doesn't
"pass through" rsvp or int-serv "layers" in any sense.  There
may be bits in protocol headers which help implement int-serv
or rsvp functions, but it doesn't make those things data-path
protocols.

It seems to me that RSVP is completely analogous to
Signalling in ATM and int-serv is analogous to Traffic
Management, as networking technology functions,
specification documents, and as working groups.  Of course
there are significant differences in the style of the
technical solutions (e.g. softstate, etc).  Is there any
inaccuracy in this mapping (apart from not wanting to be
incriminated by association...)?

There is another piece which we seem to lack clear
vocabulary for.  That is the mechanism which sits at the
edge of e.g. the ATM cloud, and transforms the rsvp/int-serv
description of traffic and QOS, into something meaningful
for the purpose of forwarding packets across the subnet.
Note that when you have a host directly connected to an ATM
network as part of a private enterprise network, this
QOS/traffic translation function may be implemented with
more direct knowledge of the capabilities of the attached
subnetwork.  People on different sides with argue about how
much of the ATM QOS capability is abstracted away by this
translation.  That's a good discussion to have, but let's get
a clearer model of what and where this function is.

Can people comment on what work is going on in any of {RSVP,
int-serv, rolc, IPATM, MPOA (ATM Forum)} working groups
toward creating such an API or the QOS-translation
interface?  (I know of one item, which is rfc1821 by Borden
Crawley, Davie, and Batsell, which discusses the two types
of QOS descriptions and lays out some issues for interoperation).


On another related point, if we look at some of the recent
dialog, it's obvious that people are carrying around
different assumptions about their networks.  Here's a few
pictures of the world (some people call these things
"reference configurations"):

1)	ES - Rtr(s) - ES
2)	ES - LAN - ES
3)	ES - LAN - Rtr(s) - LAN - ES
4)	ES - LAN - Pub-ATM - LAN - ES
5)	ES - LAN - Pvt-ATM - LAN - ES
6)	ES - LAN - Pvt-ATM - Rtr(s) - LAN - ES
7)	ES - LAN - Rtr(s) - Pub-ATM - Rtr(s) - LAN - ES
8)	ES - Pvt-ATM - Rtr(s) - Pvt-ATM - ES
9)	ES - Pvt-ATM - Pub-ATM - Pvt-ATM - ES
10)	ES - Pvt-ATM - ES

ES	= End system with IP address
LAN	= Traditional broadcast-type LAN (ethernet, FDDI), not including ATM
Rtr(s)	= IP Router or several routers connected by dedicated links
Pvt-ATM	= private ATM cloud (part of enterprise network)
Pub-ATM	= public ATM cloud (or concatenation of such)

Now, most discussions of int-serv and rsvp *seem* to
concentrate on the first configuration.  (Conversely, if you
look at most ATM Forum documents, everything in the world
looks like #9.) There have been some mumblings about taking
into account the limitations and capabilities of LANs,
presumably including ATM.  Perhaps being more explicit
about our assumptions will help these discussions.


Comments?


Regards,
-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			[phone]
Mark W. Garrett		445 South St.			[e-mail]
			Morristown NJ 07960-6438  USA	     (FAX [phone])
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------