The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Jan> msg00275



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

arequipa

  • From: Eric Mannie <mannie@helios.iihe.rtt.be>
  • Date: Tue, 30 Jan 1996 19:17:11 +0100
  • Cc: ip-atm <ip-atm@matmos.hpl.hp.com> (Non Receipt Notification Requested)
  • X400-Content-Type: P2-1984 (2)
  • X400-Mts-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;960130181711]
  • X400-Originator: mannie@helios.iihe.rtt.be
  • X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Wed, 31 Jan 1996 09:54:15 +0100
  • X400-Received: by mta elem5 in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Tue, 30 Jan 1996 19:17:11 +0100
  • X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Tue, 30 Jan 1996 19:17:11 +0100
  • X400-Recipients: non-disclosure:;

Hello,

About draft-ietf-ipatm-arequipa-00.txt (Werner Almesberger),,

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

Is it possible to clarify your proposition in comparison with SINP ?

Regards,

Eric Mannie
mannie@helios.iihe.rtt.be
Brussels University, Belgium.