Cell Relay Archive

Cell Relay Retreat>List Archive>month:1998-Sep> msg00333



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: RFI: QoS-aware IP over ATM sublayer and API?

  • From: "ronald h. davis" <ronaldd@lucent.com>
  • Date: Mon, 28 Sep 1998 11:25:46 -0500

albert.e.manfredi@boeing.com wrote:
> 
> RSVP does not incorporate the routing problem: how to find a route that meets
> the QoS needs, where other routes might not. That is a different topic. And
>

rsvp is just one component of the internet integrated services model
(actually, iis refers to a "resource reservation agent") so
determination of a route would be based upon the information in the
sender adspec which was previously sent.  the "routing agent" then
makes the decision about what route is to be used.  i don't see how
this model is logically unlike that used by pnni, or any other routing
algorithm that uses metrics.


> RSVP also allows tunnelling of RSVP traffic over non-RSVP-enabled routers,
> which creates the obvious vulnerability to any specified "guarantees."
> 

this is the same problem faced in classical ip over atm implementations
that cross logical ip subnets via routers.  for that matter, i would
imagine that you also face this same problem when nhrp resolution
requests return the atm address of an exit router that sends the
traffic on towards the destination over a non-atm network.


> 4. Finally, RSVP over ATM seems (to me) to be another complicated layered
> approach, where two inherently different QoS "guarantee" mechanisms are
> layered one on top of the other.
>

yes, very true.  for instance, estimation of rsvp parameters over atm
networks (the c and d parameters) can be quite complicated.

> One example is that even though ATM virtual
> circuits are inherently two-way, with QoS specified for each direction of the
> single circuit during the setup process, RSVP over ATM cannot make use of
> this ideal feature. RSVP must follow a procedure defined for datagram
> networks, using ATM signaling only to set up one-way paths and worrying about
> the return path with a different, RSVP process.
>

couldn't you use atm arp to determine that there is a vc to the ip 
destination and use that vc without setting up another one?

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       ronald.h.davis@lucent.com
"if you ain't the lead dog, the scenery never changes"  -- edmund wilson