The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Oct> msg00113



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

Last Call for draft-ietf-rolc-apr-00.txt

  • From: Hiroshi Esaki <hiroshi@ctr.columbia.edu>
  • Date: Thu, 26 Oct 1995 13:15:21 -0400 (EDT)
  • CC: curtis@ans.net, yakov@cisco.com, rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Hi, 


My concern on the use of NHRP for host (attached to NBMA net) with APR 
model is why we must have another procedure and API compared to the 
current procedure performed at host. 
Currently, the host decides local or remote based on address mask, by 
my understanding.  But, when we introduce APR concept, I think, host will
know APR mask and will decides whether the destination host is inside
or outside of APR domain based on address prefix information. 
For me, the use of NHRP for the host to establish direct VCC between 
the hosts sitting on the difference IP subnet seems require completely 
different procedure from the conventional IP datagram transmission 
procedure. 
  Regarding the use of native NBMA (e.g.,ATM) interface, what is the 
benefit to use native NBMA interface for the application ? 
Overhead of IP header ?  
 

   > To exploit capabilities provided by the SVC-based Data Link
   > subnetworks we propose to allow SVC management to be directly
   > controlled by applications,
  :> This is a bad idea and runs counter to rsvp and int-serv directions.
 >> What we mean here is QoS requirements of applications that may be
 >> expressed through RSVP.  In keeping with the int-serv work, we should
 >> not assume RSVP to be the only mechanism to specify QoS.  It is not
 >> counter to rsvp or int-serv directions.

RSVP would be one of protocols to specify QoS. 
However, why you must define another API ? 
Why you can not use RSVP over ATM for end-to-end VCC ? 


 >> The implication is that QoS requirements would be considered as a
 >> guide to setup SVCs.  Yes, there is also a belief that an SVC would
 >> provide better QoS (e.g. delay) since it avoids IP level handling
 >> costs at intermediate nodes.
Whether SVC can provide better QOS (e.g."loss") will depend on 
the capability of NBMA, I think.   If NBMA network can not provide 
better quality for long-haul SVC than the quality for short-haul VC 
for hop-by-hop channel, we will prefer to use IP hop-by-hop channel.  


  :: While it would be hard to say that the ATM SVCs are *always* more 
  :: desirable, I think it would be fair to say that there are QoS 
  :: requirements where ATM SVC would be preferred to IP hop-by-hop 
  :: resource reservations.  It all depends on the QoS requirements.
You may say to use SVC or to use IP hop-by-hop resource reservation 
is completely host's local decision.:-) 
I think, since the decision is done by end-host's decision, even when 
the SVC has poorer quality service 


Regards, 

Hiroshi Esaki