Subject: Re: questions about INT SERV

From: Lixia Zhang <[email-masked]>
Date: Fri, 27 Oct 1995 15:14:56 PDT

there are so many mailing lists to catch up these days, and I
always find myself falling behind...

> here i'm not sure if i agree.  people have told me that RSVP is a
> protocol to reserve resources from a ROUTER network.

RSVP is a protocol that let you make reservation request at IP layer.

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

If the source and destination are *not* IP boxes, then this entire
business should not have been discussed within IETF.

So I assume that your sournce and destination are IP-speakers
themselves.  The very good reason that they should talk about QoS
through RSVP is that

- There is a vast Internet out there and most of the other IP hosts
  are *not* on the same ATM net, and RSVP is the protocol to speak if
  you want express your QoS request in reaching the rest of the world.

  (yes you may replace RSVP above with ST2 :)

- I then go further claiming that you should only speak RSVP on all
  QoS matters even in cases that both the source and destination are
  on the same ATMnet.  This is to avoid the situation as you drew
  below:

> the stack should therefore look like:
> 
>             application
>                  |
>               int-serv
>                /  \              ...
>             RSVP  ATM Signaling  ...
>              |        |
>            router    ATM
>           network  network

(Dave already talked about the issue of whether int-serv is a layer)

the problem with your picture is that, why should the appliction be
aware of a technology-specific ATM signaling?  What if a BTM shows up
next year, are you gonna end up with 

                  application
               /   /  |   \   \
              /   /   |    \   \
            ATM  BTM  CTM  DTM  ...

???  (that would certainly keep one busy :)

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

No that pictuer was not what I said.  To quote from my original msg: 

      Yes RSVP is a protocol that makes reservations on IP boxes; hosts
      are IP-speaking boxes too.  Therefore I do consider RSVP API as a
      general QoS-capable host API.
 
      As I said already, some parts of the greater Internet may be made of
      ATM subnets, therefore RSVP necessarily has to handle all the issues
      of interfacing with ATM.  And when BTM shows up, RSVP, as a resource
      reservation protocol for the Internet, is obligated to handle that
      too.
 
      Why should we have a separate API for a new subnet type?  I do not
      recall we ever had an Ethernet API.

that really describes a picture of 

             application
                  |
                 RSVP
              /   |  \   \
        Ethernet ATM BTM  ....

(caveat: I could be wrong about Ethernet API, could have been one;
RSVP in the picture could also be replaced ST2, although I dont think
that's the right protocol but at least it is architectually consistent
here)

Lixia

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 28 Oct 1995 22:10:36 +0300

> business should not have been discussed within IETF.

lixia, in the whole discussion we have always assumed that the host are 
ip hosts.

> ???  (that would certainly keep one busy :)

and
>       recall we ever had an Ethernet API.

based on the above it is clear that you are reading your email too 
fast.  i have never proposed having a separate api for a new subnet 
type, which also many other people on this list immediately understod.

my stack was based on craig's message where he said that int-serv is 
general purpose, rsvp independent api which applications use to make 
reservation requests.  in your picture int-serv api is not shown at 
 
> that really describes a picture of

if int-serv is what craig claims, then IP applications are using it to 
express their qos requirements.  these requirements can then be 
implemented in many different ways depending on how the destination is 
reachable.  

you propose that no matter how the destination is reachable, rsvp is 
always used.  i suggested that we could first check how the destination 
is reachable and then use an appropriate reservation protocol to do the 
work.

in your model atm is below rsvp and in mine atm SIGNALING and rsvp are 
at the same level. how you relate them is a matter of opinion or 
religion, since there is there no way you could avoid the host making 
the split at some level of the protocol stack.

-- juha