The IP over ATM Mailing List Archive by date

[Philippe Oechslin <oechslin@lrc.epfl.ch>]

mannie@helios.iihe.rtt.be said:
> As far as I understand your proposition, you rely on application 
> protocols to negotiate session identification (e.g. ports) through 
> normal IP over ATM operation, then you may open a VC with a dedicated 
> QOS "between" the negotiated ports and map that VC with the session. 
> Am I right ? 
Yes.

> But it seems that another proposition, SINP 
> (draft-goto-sinp-01.txt) allows to do the same thing and even more ? 
> SINP is a small signalling protocol allowing to identify the session 
> associated with a VC supporting guaranteed QOS (notify and inquiry 
> messages) before opening that VC (thru best effort) or just before 
> sending traffic on that VC. (correct ?) One of the advantages of SINP 
> is to solve the session identification problem below the application 
> level, in the same way for all aplications.

Hello Eric,

SINP and Arequipa don't do the same thing:

  SINP labels a set of VCCs which cary a flow of QoS sensitive data
  between a caller and a callee. The VCCs are terminated at each
  intermediate system (CSR) where data handled by an implementation of
  RSVP, STII or any other flow-specific protocol. SINP makes sure that
  the intermediate VCCs are all labeled for exclusive use by a given
  data-flow. SINP itself, however, does not prevent that different
  flows use the same VC, it relies on other applications (eg. RSVP) to
  use the labels consistently.

  Arequipa establishes a direct (inter LIS) ATM connection between
  caller and callee. Arequipa makes sure that a connection is used
  exclusively by the application which requested it. It does not need
  explicit labels since it 'binds' the VC to a socket pair. Arequipa
  does not interact with any intermediate system, nor does it need
  RSVP to guarantee QoS. 

SINP and Arequipa solve different problems:

  SINP labels VCs to assist RSVP, STII or other applications in their
  management of VCs.

  Arequipa allows ATM attached hosts to profit from guaranteed QoS on
  direct ATM connections without help from RSVP or NHRP.

Neither of both can replace the other. They are two different things. 

  cheers,

   Philippe

--
oechslin@di.epfl.ch