Subject: Re: questions about INT SERV

From: Juha Heinanen <[email-masked]>
Date: Thu, 26 Oct 1995 21:11:10 +0200

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

craig,

thanks for the explanation, but it doesn't make ANY sense to me.  why
would a user care if there exists a router from which the services are
asked from?  the application should ask a particular service from the
network, not from a router.  the host would then decide how that service
can be delivered, either directly using a QoS aware link layer, such as
ATM, or indirectly using a set of routers running a protocol such as
RSVP.  it is a very big mistake if you assume that services are always
provided by a router network.  the API should be independent of RSVP/ATM
or whatever people invent next.  isn't this consistent with the message
that lixia sent to the rolc list earlier today?

-- juha

ps. i'm not on this list, so CC to me if i have misunderstod your
message.

---

From: David Clark <[email-masked]>
Date: Thu, 26 Oct 95 17:22:49 -0400

Juha,
   I suspect that we are talking past each other. It has been the Internet
approach to allow hosts to interface to specific network technology via a
network independent (i.e. Internet) interface. So we put the ATM driver under
IP, not next to it. I have assumed that in the case of specific QoS, it will
work the same way. The application/TCP or whatever will make a service request
of RSVP. RSVP will in turn make a request of the networks and routers below it to
instantiate the service. We have always assumed that both the routers and the
networks themselves have to be a part of the bandwidth control architecture.
When a router is controlled, RSVP runs in the router. When a lower level
technology is controlled, like Ethernet (yes, it can be done) or ATM, the
control must exist in the driver for the network. This is hinted at the the
draft docs, but not perhaps as well as it might be. 

Dave

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 27 Oct 1995 15:52:57 +0200

Juha, I suspect that we are talking past each other. It has been the
   Internet approach to allow hosts to interface to specific network
   technology via a network independent (i.e. Internet) interface. So we
   put the ATM driver under IP, not next to it. I have assumed that in
   the case of specific QoS, it will work the same way. 

right, this is my understanding as well.

   The application/TCP or whatever will make a service request of RSVP. RSVP
   will in turn make a request of the networks and routers below it to
   instantiate the service. 

here i'm not sure if i agree.  people have told me that RSVP is a
protocol to reserve resources from a ROUTER network.  if there is no
routers between the source and the destination, but they can reach each
other directly via a QoS aware fabric, like ATM, then there should not
be any reason to use RSVP.  the stack should therefore look like:

            application
                 |
              int-serv
               /  \              ...
            RSVP  ATM Signaling  ...
             |        |
           router    ATM
          network  network

this is what i understod from the message by craig and lixia.  craig
made it very clear that int-serv is an ATM/RSVP/etc. independent thing.

-- juha

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 27 Oct 95 15:12:57 +0000

>made it very clear that int-serv is an ATM/RSVP/etc. independent thing.

hmmm - i think that this is a little too "literal" for my taste

what is wrong with having a resource reservation API like RSVP that
applications always use - it might be that the RSVP module in trying
to establish a reservation to an IP dfirectly attached destiantion
then invokes Q.2931 (or similar) direct.......

in another case, for example (this is the opposite extreme)

- say you have 10 machiens which are RSVP
and capable CBQ or other resource controlled IP implementations on
output, attached directly vbia a 'legacy' LAN like an ethernet - they
can implement the resource control function and get higher utilsiation
out of the LAN than otherwise.....

i don't think unifying the APIs for a q.2931 style and an RSVP style
reservation protocol is at all easy, and i prefer "pushing" the q.2931
style ones down to a lower (ARP like) Level for IP users

for some notes on this see
ftp://cs.ucl.ac.uk/darpa/ietf_atm.ps
and some slides at
ftp://cs.ucl.ac.uk/darpa/rsvpq.ps

 jon

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 27 Oct 1995 17:43:18 +0200

if rsvp is truely general purpose, then it is ok to use int-serv as the
application api and rsvp as the resource reservation api.  but people
have let me understod that rsvp is a protocol to reserve resources from
the router network and i therefore suspect that it is not ideal for
reserving resources in the case there is end-to-end atm connectivity.

well, we already have int-serv api and craig said in a message he sent
to rolc list, that direct mapping from int-serv to atm shouldn't be
difficult.  if so, we can junk rsvp in the end-to-end atm case. or is
that against the religion of this list ...

-- juha

---

From: David Clark <[email-masked]>
Date: Fri, 27 Oct 95 11:54:57 -0400

Your picture makes very clear where we misunderstand each other. You draw
int-serv as a software layer in the protocol modularity. That is not how we
think of it. I proposed, two IETF meeting ago, that we should create such a
layer (I called it the Resource Manager). The app would call it, and it would
figure out what to do. People went with the approach that RSVP implemented that
function. The app calls RSVP, and it calls the subnet driver to configure the
locally attached network, and sends RSVP packets to configure the intermediate
routers (if any).

Now this picture raises the issue that RSVP does not, by the current modularity,
know about the semantics of the service. And that point, I suspect, is why it is
tempting to draw an int-serv layer above RSVP. But people, after some (enough?)
thought, concluded that you don't actually have to understand the semantics at
that point. What you have to do is pass the state down to the lower levels. So
the ATM driver will get the service request expressed as RSVP expresses it, and
will translate this into Q.931 just as it would at an intermediate router.

If, as we design and code this, we discover that we need a layer at the host
that understands the semantics of the service (beyond what the app needs to
know) then we will need to add a layer such as you draw.  And if we want to
isolate the app from the decision to use RSVP, and make it possible to replace
that setup protocol with another dynamically, we will need such a layer.

Dave

---

From: Steve Jackowski <[email-masked]>
Date: Fri, 27 Oct 1995 08:55:40 -0900 (PDT)

Juha,

> be any reason to use RSVP.  the stack should therefore look like:

First, let me refer you to RFC 1821: Realtime Service 
In IP-ATM networks.  The key to using in an IP network 
is to ensure that there is consistency in the 
implementation in:

1) host to host (ATM only)
2) Host to host (IP hosts across ATM Network)
3) IP host to ATM host and vice versa across mixed 
networks (internets and ATM nets).

Right now, the proposed solution to ensure bandwidth 
and QoS for existing and new application in these 
environments is to use a reservation protocol to 
ensure consistent signalling.  RFC 1821 examines the 
issues with RSVP and ST-2.  

My company is in process of implementing an ST-2 
version for a major PTT that indeed, allows the 
application (or uses a proxy agent and filter for 
existing IP applications), to request QoS and 
bandwidth.  If the host is an ATM connected host, the 
DL layer sets up virtual circuits with appropriate 
bandwidth and QoS based on the flowspecs in the 
reservation requests.  If the host is an 
internet-based host, when the reservation request hits 
the router, the router sets up the vcs in a similar 
manner.  By including the reservation protocol, we 
ensure that we can supply end-to-end QoS and Bandwidth 
guarantees.  

We will be doing the same thing for RSVP as it 
stablizes and as we resolve some of the ATM scaling 
issues for RSVP (again see RFC 1821). Also, I will be 
publishing a description of how to use reservation 
protocols with ATM in a proposed informational RFC 
shortly.

I'd also point you to the latest Internet Draft on IP 
over ATM framework which was prepared just a few weeks 
ago.  It identifies many of the issues and, I belive 
does help justify the postioning of IP nd use of 
reservation protocol as a critical part of ATM usage 
in the internet.

Steve

---

From: Craig Partridge <[email-masked]>
Date: Fri, 27 Oct 95 09:36:30 -0700

Juha:

    INT SERV is RSVP independent but the layering is different.  It looks
more something like this (though other options are possible for how the
application reaches the INT SERV additions in the IP layer).

	    Application
		/\
	       /  RSVP/ST2+/SNMP <-- anything you use to request services
	      /  /  /             (which use UDP, etc to cross network
      UDP/TCP/etc  /               and communicate direct with INT SERV
	       \  /                locally).
		\/
	    IP  +  INT  SERV
	    |    |         |
           ATM  Ethernet  FDDI

The upper layer relations one can futz with in various ways, but the lowest
part is pretty stable.  INT SERV enhances IP, and manages the layer 2 
protocols like ATM to achieve the Integrated Services Goal.

The independence of upper layer protocols is that INT SERV doesn't care
what protocol you use to create the QoS requests -- RSVP, ST2, SNMP,
typing at your router console, Application system call, whatever.

Craig

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 27 Oct 95 16:18:27 +0000

>that against the religion of this list ...
 
how would you propose to map the recevier based request and 
wild card srtye filters to what ATM can offer?

i think at the very least you will need an RSVP stub that translates
applications view of the reservation architectural semantics.....
even though the int-serv and ATM QOS models are reasonably
alignable....the topological significance of where the reservation is
and for who (how many together) it is exactly does bear thninking
about

imagine a scenario where a bunch of hoistrs are conencted both by
'conventional' IP links, and by ATM (like most sites with ATM ,we stil
lhave ethernet and fddi between a lot of our machines as a safety
net), why should the hosts have to care about any differences?

on the matter of 'religion':

the only religion i detect here is a religious avoidance to merge the
rsvp and int-serv groups til they reach closure on the separate well
defined bits of their work - unfortunately, this has led to certain
gaps in the work appearing every now an then...perhaps this is one ...

 jon

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 27 Oct 1995 15:52:57 +0200

application
                 |
              int-serv
               /  \              ...
            RSVP  ATM Signaling  ...
             |        |
           router    ATM
          network  network

-- juha

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 27 Oct 95 15:12:57 +0000

jon

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Oct 1995 15:50:53 -0400

>       UDP/TCP/etc  /               and communicate direct with INT SERV

You forgot HDLC or PPP on point to point links.  These are the most
common WAN links in the Internet by a long shot.

> typing at your router console, Application system call, whatever.

Int-serv has designed a format.  This could be the basis of the API
exchange, with the application passing this format down the stack.  At
that point a decision can be made as to whether to alter the
treatement of the flow.  Even if the next hop is the destination, it
may be useful to use RSVP, to pass the reservation all the way to the
sender.  (Maybe you can accept a zillion mbps of flow, but the sender
can't send at anywhere near that rate, so the sender not responding
may provide a hint to use a smaller VC).  The int-serv format also
happens to be the format forwarded by RSVP, which makes sense if
routers down the path will need to make a similar decision.

[ wrt API ] The current RSVP implementation is right now sort of a
"bag on the side" approach.  I'd much rather see it well integrated in
the long term, in something like a setsockopt(), where an ordered list
of reservation types and parameters can be pushed.  If none can be
acheived in some time period, the socket simply closes.  If you don't
want the socket to close, stick "best effort" at the end of the list.
A getsockopt() could be used to get the reservation currently in
effect for either the receiving side or the sending side (the merged
reservation coming to the sender from the receivers).  If you want
asynchronous notification of a reservation change, the normal
getsockopt() would not do the trick.  Adding a signal might be the
simplest solution, or something analogous to the routing socket might
be a consideration (though probably a pain to code).  There are
probably other more elegant and maybe simpler ways to do this (any
suggestions).

This would make the stack:

	Application
	    |  ^
	    v  |
	   kernel
	  |  ^	 |  ^
	  |  |	 v  |
	  |  |	RSVP/ST2+
	  |  |	 |  ^
	  v  |	 v  |
	 SVC management
	     |  ^
	     v  |
	    driver

A (very likely) implementation decision may be to put in an interface
similar to the routing interface that allows the complex configuration
and decisions to be acted upon outside of the kernel.  The application
would still talk to the socket and the RSVP daemon to a special (root
only) interface analogous to the routing socket.  The same applies to
SVC management (putting the decision outside the kernel).

The case discussed in ROLC would then be a special case (which some
people may choose to implement):

        Application
            |  ^
            v  |
           kernel
          |  ^
          v  |
         SVC management
             |  ^
             v  |
            driver

This has the disadvantage of being impossible to implement without
kernel source.  (Get an OS with affordable source :).  The case were
the information is passed OOB rather than through the socket interface
should be considered as a practical workaround to improve portability,
not an architecural feature.

What was really deing discussed in ROLC was how to describe the
architecture.  If described this way, at least those that choose to
leave out the reservation protocol piece can see that there might
still be some merit to using a standard interface to avoid writing a
base of software that is likely to be orphaned due to an interface
that covers their case equally as well and is more general.

Curtis

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 27 Oct 1995 17:43:18 +0200

-- juha

---

From: David Clark <[email-masked]>
Date: Fri, 27 Oct 95 11:54:57 -0400

Dave

---

From: Steve Jackowski <[email-masked]>
Date: Fri, 27 Oct 1995 08:55:40 -0900 (PDT)

Juha,

Steve

---

From: Hiroshi Esaki <[email-masked]>
Date: Fri, 27 Oct 1995 21:49:30 -0400 (EDT)

Hi, 

Let me compare a native ATM interface vs. RSVP/IP/ATM, from the view 
point of connectivity. 
Since ATM is just a datalink technology, even though ATM may be 
a large part of the Internet (owned e.g., by telephone companies), 
an ATM native interface can only provide a local connectivity for the 
Internet.  Here, the "local" may be a large geographical area, but 
it is not still global area.  
  On the contrary, RSVP/IP/ATM can provide us global connectivity, 
regardless which platforms source and destination host sit, "with 
SINGLE and UNIQUE interface", regardless where the source and 
destination hosts sit.    

  Some people seem to think, why it is not allowed to use a native 
datalink interface (i.e.,ATM interface) when source and destination 
hosts are directly reachable by datalink level.   I may say which 
application is using direct MAC interface to transmit the data over 
a common Ethernet, in these days ?    And, native telephone interface
is used for data communication between applications in these days ?   
I may think using a native ATM interface is make sense, only when 
ATM address (i.e.,NSAP address) with ATM interface gives a global 
connectivity.  
# I have recalled the words by Lixia long ago; ATM over IP or 
  IP over ATM.   I believe, it must be IP over ATM.  Then, the answer 
  seems to be obvious. 

Regards, 

Hiroshi Esaki