The Routing Over Large Clouds Mailing List Archive by date[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
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
|
|