Subject: Re: questions about INT SERV

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

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

rsvp is a protocol to reserve resources over the Internet.

(BTW what is a "router network" ?  we seem to have different pictuers
of the world :)

My last msg explained why I dont think you should junk RSVP even in case
there is end-to-end atm connectivity.

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

That is certainly against my religion :-)

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 28 Oct 1995 21:38:23 PDT

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

right, that *was* my assumption in the earlier msg.

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

well, here is your original picture:

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

and there is indeed a API for ATM, which is a new subnet type.

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

My point is that there should be an IP level signaling protocol
above ATM; whether it is RSVP or something else (e.g. ST2 :) is a
secondary question here.

> in your picture int-serv api is not shown at 
> all.  instead it is replaced by rsvp:  

That's true.
I thought Dave's msg explained well about whether int-serv should be a
layer or not.
int-serv defines the QoS request that's passed to RSVP.

> if int-serv is what craig claims, then IP applications are using it to 
> express their qos requirements.

complete agreement here.

>  these requirements can then be 
> implemented in many different ways depending on how the destination is 
> reachable.  

this is where the disagreement is.

> you propose that no matter how the destination is reachable, rsvp is 
> always used.

I said an IP signaling protocol should always be used (I did
explicitly mention ST2 as another choice :)

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

I call ATM a subnet technology.  IP is on top of all subnets.
Yes you may consider it a matter of opinion or religion.  I firmly
believe that ATM, as all other subnet technologes, comes and goes, and
I wish applications programmers dont have to be bothered with that detail.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 30 Oct 1995 09:57:29 PST

> Hi Lixia,
> 
> I was a bit confused here, so I want to make sure I understand you
> correctly.
> 
> If there's some notion of using ATM signalling as a universal,
> end-to-end way to get QoS from an IP network, I agree that this is a
> silly idea.

That's my current understanding of Juha's position; of course he'll
correct me if I misunderstand.

> If RSVP is the IP signalling protocol (not such a silly idea), ATM
> signalling _is_ still needed so you get the desired service from the
> ATM subnet.  ATM signalling does not need to be replaced with IP
> signalling.  It should just be considered a part of the subnet layer.
> 
> Are we on the same page?

yes we are on the same page.  RSVP must talk to the subnet signaling
protocol, if there is one, to get the QoS service across that subnet.

Lixia