Internet Drafts for SCTP and DDP are:
SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt)
DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt
charles Agboh wrote:
Hi all,
what is ddp and where can i get information on it.
charles
Terry L Anderson wrote:
Minutes of the Apr 20, 2000 Robustness teleconference call, 11:00 EDT
Present on the call: Tim Chen & Mahesh Bhan (and perhaps others)- Trillium Tim Sipsey - Aspect Rex Coldren & Terry Anderson - Lucent Randy Stewart & Qiaobing Xie - Motorola Paul Jones - Cicso
Next Meeting: Apr 27, 2000 EDT (15:00 UT/GMT) (see below for details).
Agenda:
- continue discussion of SCTP/DDP vs Annex E discussion
- Plans for Osaka
- next meeting
(Participants - if I have misrepresented the discussion, feel free to comment to the list)
SCTP/DDP vs Annex E: We continued earlier discussions on these underlying structures. It appears that we have two basic models:
- SCTP/DDP based transport using DDP and a distributed/shared memory
scheme (based on DDP) to allow a cluster of servers to provide a fault-tolerant "element", nearly transparent to the H.323 application layer. The application layer would have to "checkpoint" critical data at defined points so that backup servers can take over function with full state information. Message delivery is reliable end-to-end if each element-cluster guarantees delivery by a member of the cluster once acknowledged to the sender through SCTP.
- Annex E-based transport with added mechanism for end-to-end message
acknowledgement. Originator of a message would resend if far-end ack NOT received. How Annex E and application layer cooperated for this end-to-end ack, to be clarified. This ensures that the two end points agree on call state. We still need connection reestablishment mechanisms for backup elements and state recovery through application layer mechanisms (perhaps similar to Radvision proposal at Geneva).
There are intermediate solutions (DDP on Annex E, use of end-to-end ack with DDP-fault tolerant clusters, ...) that have not been rejected.
We decided that choose between these models and to make better progress we needed more precise statements of the solutions. See plans for this under Next Meeting.
Plans for Osaka: We did not complete this. It appears likely that we can have a document to present based on the SCTP/DDP mechanism. We may be able to complete a document based on Annex E. We have NOT determined whether we will choose or present BOTH with the study group. We will need to re-assess this on the next call.
Next Meeting: Apr 27, 11:00 EDT (15:00 UT/GMT). Randy & Qiaobing will provide a draft of their model for backup GK recovery using SCTP/DDP, including, if possible, a way to allow GW to recover SCTP to backup without using DDP (DDP only between members of the server pool).
Paul and Trillium participants will try to have a draft of a mechanism using Annex E & end-to-end confirmations.
--
Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
--
Charles Agboh
Universite Libre de Bruxelles Service Telematique et Communication Bd du Triomphe, CP 230 B-1050 Brussels Belgium
Tel. +32 2 6505717 Fax. +32 2 6505088, +32 2 6293816 RFC-822 : agboh@helios.iihe.ac.be
"Perilous to us all are the devices of an art deeper than we possess ourselves." --J.R.R Tolkien, The Two Towers
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla