Re: int-serv over e.g. ATM

[[e-mail]]

[ ... snip ... ]

	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).

[ ... snip ... ]

	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.

	Regards,
	-Mark

Mark,

The RSVP group at ISI is looking at these issues.  Right now we are
concentrating on the second issue ("reference configurations" other
than #1).  We will be talking about our status in the IP over ATM
working group meeting at the Dallas IETF.

Cheers,
Steve