Subject: int-serv over e.g. ATM

From: [email-masked] (Mark W Garrett)
Date: Mon, 6 Nov 1995 12:18:24 -0500

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			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 06 Nov 1995 17:58:11 -0500

> or rsvp functions, but it doesn't make those things data-path

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 ... ]
> about our assumptions will help these discussions.

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

---

From: Craig Partridge <[email-masked]>
Date: Mon, 06 Nov 95 16:34:33 -0800

Mark:
    
    I'll hazard a quick and personal answer to your hnote.

>    incriminated by association...)?

I think that's basically right.

>    for the purpose of forwarding packets across the subnet.

INT-SERV (in our charter) calls this "the subnet interface" and the
idea is that the cannonical IP-to-subnet interface would be enhanced
to allow the IP layer to convey QoS information to some subnet module
(in ATM, something like the Q.2931 signalling code supporting 1577
or MPOA) which would make the appropriate arrangements.

It is on the INT SERV agenda (our charter says we'll do it), but beyond
periodically pointing out that the QoS that IP is likely to hand to
the ATM subnet matches perfectly with the ATM GCRA parameters, I don't
believe much has been done.

    1)	ES - Rtr(s) - ES
    2)	ES - LAN - ES

My model says that INT SERV's model easily encompasses anything where
there's an IP device (ES or Rtr) on each side of the subnet (so 1,2,3,7,8,9,10).
Scenarios where there may be bridging in the path (namely 4,5,6)
are more troublesome because I don't know what QoS information crosses
the bridge.  If a LAN-ATM concatenation can do QoS, IP should be able to
use it.

Craig

---

From: Steve Deering <[email-masked]>
Date: Mon, 6 Nov 1995 20:13:58 PST

> 9)	ES - Pvt-ATM - Pub-ATM - Pvt-ATM - ES

Mark,

From an IP perspective, the model is:

        ES - link [- Rtr - link]* - ES

where [foo]* means zero or more repetitions of foo, and each link may be
any network technology (e.g., LAN, private or public ATM, X.25, PPP, or
even an IP-over-IP tunnel).  Concatenations of ATM networks without
intervening routers look like one link to IP, just like LANs concatented
by bridges.

(The above model is true for unicast only, of course.  The multicast case
is harder to illustrate, but instead of being a path it is a tree, with
arbitrary branching and arbitrary branch lengths.)

Any number of ATM links (private or public, in any order) may appear in a
path, each separated by any number of non-ATM links, and the ESs may
separated from any ATM links by any number of non-ATM links.

Designing for anything other than this most general model would be
unnecessarily restrictive and exceedingly foolish.

If there happens to be an IP application that requires a QoS reservation
(I personally have my doubts that such applications need exist, but I'll
suppress that for now), it uses RSVP to make the reservation end-to-end;
at each IP node along the path, including the initiating ES, the module
that processes RSVP invokes link-specific mechanisms (e.g., ATM signalling)
to satisfy the reservation across the next link in the path.  The IP
applications have no need to know about, let alone directly invoke, the
link-specific set-up mechanisms.

This is very elementary stuff that shouldn't have to be said, but your
message made me think that it might need saying, much to my surprise.

Steve