Re: int-serv over e.g. ATM

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Mark W Garrett writes:
> 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 would seem to be a Real Good Idea if the API reflected the
int-serv semantics.  It would also be nice if the same API existed for
both a direct attachment and QoS delivered through RSVP.

[ ... some stuff that Mark wrote deleted ... ]
> 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?

Having a different API for each "reference configuration" or worse yet
different semantics for each, would not be a good thing IMO.  The
purpose of bring the ROLC work to the attention of int-serv and rsvp
is that ROLC appears to have started in that direction.

Curtis