From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr  1 14:06:11 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00112
	for <iptel-archive@odin.ietf.org>; Thu, 1 Apr 1999 14:06:10 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id BEB5E52AA; Thu,  1 Apr 1999 13:17:24 -0500 (EST)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2A5A952C1; Thu,  1 Apr 1999 13:17:24 -0500 (EST)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <002101be7c6c$126dcad0$1d646e0a@w01w010.millenicom.net>
From: "Can Kiral" <ckiral@millenicom.net>
To: <iptel@lists.research.bell-labs.com>
Subject: international costs
Date: Thu, 1 Apr 1999 20:18:21 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01BE7C7C.C9ADC4B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01BE7C7C.C9ADC4B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Do you know where I can get interconnection rates, settlement & =
accounting rates, and traffic directions of international telcos?

Thnks

Can Kiral


------=_NextPart_000_001E_01BE7C7C.C9ADC4B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Do you know where I can get =
interconnection=20
rates, settlement &amp; accounting rates, and traffic directions of=20
international telcos?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Thnks</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Can Kiral</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001E_01BE7C7C.C9ADC4B0--


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 04:49:00 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00073
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 04:48:59 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 15D5E52B7; Tue,  6 Apr 1999 04:43:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6D67E52C1; Tue,  6 Apr 1999 04:43:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <001501be8008$e1f6e3a0$c21aa4a4@vipin.wipsys.soft.net>
Reply-To: "Vipin  Palawat" <vipinpal@wipsys.soft.net>
From: "Vipin  Palawat" <vipinpal@wipsys.soft.net>
To: "Arjun RC" <archow@hss.hns.com>
Cc: <iptel@lists.research.bell-labs.com>
Subject: Re: SIP clarification
Date: Tue, 6 Apr 1999 14:08:44 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Arjun,

As my understanding, the REGISTERation request should be followed by a 2XX
success response or some 4XX/5XX/6XX error response from SIP server to
acknowledge the
sucessful registration or error.

If your message get lost or due to some other reason you did'nt get the
response back then you have to retransmit the message again and wait for
time out of response.

Regards
Vipin...
________________________________________________
Have  a  Nice  Day!!!

Vipin  Palawat
Wipro  Infotech :Enterprise Solutions (Telecom Division)
K-312, 5th Block , Koramangala,
Bangalore - 560 095 (India)
Ph: 91-80-5538301 Extn:2419
mailto:vipinpal@wipsys.soft.net

-----Original Message-----
From: Arjun RC <archow@hss.hns.com>
To: iptel@lists.research.bell-labs.com <iptel@lists.research.bell-labs.com>
Date: Tuesday, April 06, 1999 1:55 PM
Subject: SIP clarification


Hi,
we are  trying to implement a minimal version of SIP on UDP and have the
following
doubt:

The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with
the SIP Server.
However, it does not show the server sending a response (e.g 200 OK) for
the same. (16.1 pg 120)

However, section 10.4.1, pg 90 states that REGISTER should be
retransmitted. Hence it seems logical that a response should be returned.

Could anyone pls clarify the exact procedure (ie whether as response
follows a register request)

Thx
Cheers
ARC



---------
This message came from the IETF IPTEL Working Group Mailing List.



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 05:39:04 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00341
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 05:39:04 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 6DEF752C6; Tue,  6 Apr 1999 05:33:12 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C3ECC52C7; Tue,  6 Apr 1999 05:33:11 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Tue, 6 Apr 1999 15:00:08 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: iptel@lists.research.bell-labs.com
Cc: Vipin_Palawat <vipinpal@wipsys.soft.net>
Subject: Re: SIP clarification
In-Reply-To: <6525674B.0030ED37.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904061456420.18796-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi Vipin,
Thanks for the clarification -- this is what we have assumed and
implemented. The example must have been a overlook -- its was there in the
Jan 099 Draft as well as the more recent RFC.

Cheers
ARC
 
 On Tue, 6 Apr -1, Vipin_Palawat wrote:
Vipin> As my understanding, the REGISTERation request should be
Vipin> followed by a 2XX success response or some 4XX/5XX/6XX error
Vipin> response from SIP server to acknowledge the sucessful
Vipin> registration or error. If your message get lost or due to

--
I am grateful that I am not as judgmental as all those
censorious, self-righteous people around me
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 06:07:01 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00533
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 06:07:01 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 2845152BB; Tue,  6 Apr 1999 04:07:14 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9533D52BF; Tue,  6 Apr 1999 04:07:13 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: archow@hss.hns.com
To: iptel@lists.research.bell-labs.com
Date: Tue, 6 Apr 1999 04:05:56 -0400
Message-Id: <19990406080704.79B2E52BB@lists.research.bell-labs.com>
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 07:05:38 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00942
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 07:05:37 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 7389C52BF; Tue,  6 Apr 1999 04:09:35 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 99B9352C1; Tue,  6 Apr 1999 04:09:34 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Tue, 6 Apr 1999 13:26:04 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: iptel@lists.research.bell-labs.com
Subject: SIP clarification
Message-ID: <Pine.LNX.4.05.9904061320001.15459-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi,
we are  trying to implement a minimal version of SIP on UDP and have the
following
doubt:

The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with
the SIP Server.
However, it does not show the server sending a response (e.g 200 OK) for
the same. (16.1 pg 120)

However, section 10.4.1, pg 90 states that REGISTER should be
retransmitted. Hence it seems logical that a response should be returned.

Could anyone pls clarify the exact procedure (ie whether as response
follows a register request)

Thx
Cheers
ARC 



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 08:51:57 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04951
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 08:51:57 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 1130B52C3; Tue,  6 Apr 1999 08:47:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 7B16752C8; Tue,  6 Apr 1999 08:47:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Tue, 6 Apr 1999 05:46:03 -0700 (PDT)
From: Yahoo!Clubs <clubsbot@yahoo-inc.com>
Message-Id: <199904061246.FAA13438@e2.clubs.yahoo.com>
To: iptel@lists.research.bell-labs.com
Reply-To: ramiro_g@mailexcite.com
Subject: You're invited!
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hello!

You have been invited by elparto to join the Listed 
Yahoo! Club named "Internet Telephony".

To become a member of this club, just go to the
Web address below:
http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i&

You need to go to the address above to join the club,
but you can take a look at the club by going to:
http://clubs.yahoo.com/clubs/internettelephony

You can learn more about elparto by
looking at the Yahoo! Public Profile:
http://profiles.yahoo.com/elparto

A Yahoo! Club is a great way to bring friends, family or
anyone you know together using the latest in Web
technologies. Club members are able to take advantage of
a club's private chat room, message boards and other
features. You can also create your own free club focused
on any interest, such as hobbies, families and industry
associations.

Clubs are either listed or unlisted. Listed clubs are
available to the public while unlisted clubs are
available exclusively to those who receive invitations.

If you have no interest in joining this club, there is
no need for you to do anything. You will not be
enrolled as a member.

Thanks,

The Yahoo! Clubs team
http://clubs.yahoo.com/


P.S. If you need some help on getting started, go to:

http://help.yahoo.com/help/clubs/


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 15:05:50 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15442
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 15:05:49 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id F338352CA; Tue,  6 Apr 1999 14:33:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BDC0452CD; Tue,  6 Apr 1999 14:33:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <370A530B.8D95825B@cisco.com>
Date: Tue, 06 Apr 1999 11:31:39 -0700
From: "Hussein F. Salama" <hsalama@cisco.com>
Reply-To: hsalama@cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.research.bell-labs.com
Subject: Evaluation of the gateway location proposals
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Iptellers,

The consensus during the Minneapolis IPTEL meeting was that more
detailed comparison of the two gateway location proposals is needed.
Below I am providing an evaluation of the two proposals: GLP/SCSP and
TBGP/BGP.

1. Introduction:
GLP is based on SCSP which is a generic link-state based protocol for
synchronizing the databases of a server group. GLP uses SCSP's message
formats and defines new fields specific for call routing and gateway
location. GLP uses SCSP's transport mechanism only for intra-domain
synchronization of LSs. For inter-domain communication, GLP proposes a
model that's based on BGP. At runtime, GLP defines a server group (the
set of LSs) which uses SCSP for synchronization and update
advertisement, i.e., GLP is a user of SCSP.

TBGP is based on the BGP-4 and its multi-protocol extensions. It uses
BGP's transport mechanism for both inter-domain and intra-domain. TBGP
uses the same message formats defined by BGP, and benefits from the
attributes already defined 
in BGP. In addition, TBGP defines new attributes to serve the specific
goals of call routing and gateway location. With regards to
implementation, BGP and TBGP are completely independent protocols. The
two protocols do not interfere with each other at runtime. A TBGP
speaker (or LS) does not have to be a BGP speaker.

2. Reliability:
GLP runs on a reliable transport, e.g. TCP. In addition, GLP/SCSP uses
request/response transactions.  Responses are not simple Acks. They are
long messages. This significant overhead is needed with intra-domain
link-state protocols to achieve transitive closure and to make sure that
all LSs in a domain have synced up following a routing change. However,
it is still a significant overhead that may be avoided. The
request/response mechanism does not add any benefit for inter-domain
GLP.	

TBGP, on the other hand, relies on TCP for reliability. It uses Update
messages only with no responses. This is sufficient.

3. Inter-Domain Topologies:
Both protocols can support any general topology.

4. Intra-Domain Topologies:
GLP can support any general topology.

TBGP requires either a full mesh configuration or the use of route
reflectors or confederations. It is possible to configure each TBGP
speaker in a domain as a route reflector, and thereby to support any
general topology.	

Questions: 
- What's so bad about route reflectors and confederations? 
- What's the need for supporting a general topology? All that's required
is synchronizing the LSs of the same domain. It doesn't matter how they
interconnected, as long as there sufficient redundancy in the topology.

5. Loop Avoidance:
5.1 Intra-domain Loop Detection: 
GLP detects loops using SCSP's Originator ID and Sequence Number fields.

For TBGP, internal updates are limited to one hop only in case of  a
mesh, therefore there is no danger of loops. With route reflectors,
loops are detected using the Originator_ID and Cluster_List attributes.

5.2 Inter domain Loop Detection:
Nothing defined for GLP yet.

TBGP uses BGP's AS_PATH (or call it AD_PATH) attribute to detect
inter-domain loops.

6. Hold-down Timers and Route Flaps:
GLP/SCSP does not specify any mechanisms for avoiding route flaps.

TBGP leverages BGP's well defined mechanisms for reducing route flaps.
BGP defines two timers: 
- MinRouteAdvertismentInterval (min. time between successive
advertisements of routes to the same destination from the same TBGP
speaker).
- MinASOriginationInterval (min. time between two successive
advertisements of routing changes within the TBGP speaker's own AD).

7. Policy Enforcement:
GLP/SCSP does not specify any mechanisms for enforcing policies on the
routes being advertised.

BGP defines two useful attributes which are leveraged by TBGP:
Multi_Exit_Disc and Local_Pref.

Multi_Exit_Disc is used by an advertising AD with multiple entry points
to indicate to its neighbors which entry point(s) into that domain are
preferred.

Local_Pref is used locally within an AD with multiple exit points to
indicate which exit point(s) towards a certain destination are
preferred.

8. Coping with Aggregation Side Effects:
GLP/SCSP does not specify any mechanisms.

TBGP can leverage two attributes already defined in BGP: Aggregator and
Atomic_Aggregate.

The Aggregator attribute indicates that an advertised prefix is an
aggregate, and includes the number of the aggregating AD and the
aggregating TBGP speaker's IP address.

The Atomic_Aggregate attribute indicates that aggregation has resulted
in loss of information for this prefix and therefore deaggregation is
not appropriate.
 
9. Addressing Formats:
GLP proposes to advertise E.164 ranges. During the meeting, it has been
agreed that E.164 prefixes are more space-efficient.

The multi-protocol extensions for BGP-4 (RFC 2283) have already defined
fields for advertising E.164 prefixes in BGP messages. These extensions
are used by TBGP.

10. Leveraging Existing Attributes:	
Most of BGP-4's fields and attributes can be used by TBGP, as evident
from the above discussion. Still there are some attributes which are of
no use to TBGP. for example the layer 3 NEXT_HOP attribute.

GLP, on the other hand, will have to redefine several of BGP's existing
attributes within the SCSP's message formats. Consider for example, the
policy attributes and aggregation attributes discussed above. Also SCSP
defines several mandatory fields which are redundant or of no use for
GLP. E.g., the Sender ID and Recvr ID are not needed in every Update
messages. The peers already recognize each other. Also the Cache Key
field is not needed since the tables will be indexed by the E.164
prefixes.

TBGP can define its own message formats and remove any useless fields
from the current BGP messages, because BGP and TBGP are separate
protocols. On the other hand, GLP can not remove useless fields from
SCSP messages, because it is just a another user of SCSP.

11. Protocol Phases:	
GLP/SCSP has three phases: Hello, Cache Alignment, and Update. 

TBGP/BGP consists of two phases only: Hello and Update. It uses the same
mechanisms of the update phase for aligning the call routing tables when
a new connection between wo peers is established.

12. Security Consideration:	
Both protocols define optional fields to include authentication data.
Both of them  permit the use of different authentication mechanisms, and
both provide sufficient space to include the 128-bit MD5 digests. 

However, TBGP messages can't carry authentication data larger than 128
bits, while SCSP messages can.

13. Routing Experience:
This is not a feature of the protocol, but I think it is worth repeating
that SCSP was not designed for, and was never used for, inter-domain
routing.

On the other hand, BGP has been specifically designed for inter-domain
routing. It (a) is known to work, (b) is widely deployed in the
Internet, (c) has an extensive operational experience, and (d) known to
scale.

Comments, objections, questions? 

Hussein

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 15:29:07 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15769
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 15:29:07 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 193F952CC; Tue,  6 Apr 1999 15:23:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 88E0E52CE; Tue,  6 Apr 1999 15:23:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <370A5E88.3B7F5269@dnrc.bell-labs.com>
Date: Tue, 06 Apr 1999 15:20:40 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Vipin Palawat <vipinpal@wipsys.soft.net>
Cc: Arjun RC <archow@hss.hns.com>, iptel@lists.research.bell-labs.com
Subject: Re: SIP clarification
References: <001501be8008$e1f6e3a0$c21aa4a4@vipin.wipsys.soft.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes, REGISTER like all other requests is responded to. The reliability
mechanisms for all non-INVITE requests are described in section 10.4.

In general, SIP issues like this are for the mmusic list,
confctrl@isi.edu, not iptel.

-Jonathan R.

Vipin Palawat wrote:
> 
> Hello Arjun,
> 
> As my understanding, the REGISTERation request should be followed by a 2XX
> success response or some 4XX/5XX/6XX error response from SIP server to
> acknowledge the
> sucessful registration or error.
> 
> If your message get lost or due to some other reason you did'nt get the
> response back then you have to retransmit the message again and wait for
> time out of response.
> 
> Regards
> Vipin...
> ________________________________________________
> Have  a  Nice  Day!!!
> 
> Vipin  Palawat
> Wipro  Infotech :Enterprise Solutions (Telecom Division)
> K-312, 5th Block , Koramangala,
> Bangalore - 560 095 (India)
> Ph: 91-80-5538301 Extn:2419
> mailto:vipinpal@wipsys.soft.net
> 
> -----Original Message-----
> From: Arjun RC <archow@hss.hns.com>
> To: iptel@lists.research.bell-labs.com <iptel@lists.research.bell-labs.com>
> Date: Tuesday, April 06, 1999 1:55 PM
> Subject: SIP clarification
> 
> Hi,
> we are  trying to implement a minimal version of SIP on UDP and have the
> following
> doubt:
> 
> The RFC (2543) dated Mar '99 sights an example of Users REGISTERing with
> the SIP Server.
> However, it does not show the server sending a response (e.g 200 OK) for
> the same. (16.1 pg 120)
> 
> However, section 10.4.1, pg 90 states that REGISTER should be
> retransmitted. Hence it seems logical that a response should be returned.
> 
> Could anyone pls clarify the exact procedure (ie whether as response
> follows a register request)
> 
> Thx
> Cheers
> ARC
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 15:58:57 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16207
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 15:58:57 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 77B8952CE; Tue,  6 Apr 1999 15:54:08 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E49F252CF; Tue,  6 Apr 1999 15:54:07 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Posted-Date: Tue, 6 Apr 1999 12:51:43 -0700 (MST)
Message-ID: <370A6640.66532C9B@agcs.com>
Date: Tue, 06 Apr 1999 12:53:36 -0700
From: "Nagaraj Vn" <vittaln@agcs.com>
Organization: AG Communication Systems
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: iptel@lists.research.bell-labs.com
Subject: [Fwd: H323 RAS signalling and call signal transport address]
Content-Type: multipart/mixed; boundary="------------85EE4487C899F647C1F22260"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------85EE4487C899F647C1F22260
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------85EE4487C899F647C1F22260
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <370A240F.55A0A2F3@agcs.com>
Date: Tue, 06 Apr 1999 08:11:11 -0700
From: Nagaraj Vn <vittaln@agcs.com>
Organization: AG Communication Systems
X-Mailer: Mozilla 4.05 [en] (WinNT; U)
MIME-Version: 1.0
To: h323implementors@imtc.org
Subject: H323 RAS signalling and call signal transport address
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am working on a VOIP project and looking into RAS messages defined in
H.225. My question is about the Terminal Registration with a Gatekeeper
using RRQ.

The terminal has to send the call signal Transport address in the RRQ
message. Does this mean that the terminal would be listening on the TCP
transport address and the Gatekeeper can Connect to it to establish the
2way TCP connection?  My thought is that the Terminal should be
listening on the call signal Transport address otherwise the Gatekeeper
cannot offer a terminating call to the Terminal.

If above is true, then what is the use of the callSignal Transport
address field in the RCF message sent by Gatekeeper? My initial
understanding was that the Gatekeeper will be listening on the
callSignal Transport address it sends in the RCF message to handle
incoming calls. But, TCP being a 2way connection, and if what I
mentioned in the first paragraph is true, then why should both the
gatekeeper and the terminal be listening on 2 different TCP callSignal
address?

As the terminal should always initiate the RRQ in Gatekeeper routed call
model, and the callSignal Transport address is mandatory in RRQ, the
Gatekeeper can CONNECT to this TCP address before sending RCF, if doing
preGrantedARQ, OR CONNECT to this TCP address when sending ACF OR when
Gatekeeper is ready to offer a call to the terminal.

Any comments are welcome.

Thanks


--------------85EE4487C899F647C1F22260--


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 17:41:36 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18142
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 17:41:35 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 94EA852D2; Tue,  6 Apr 1999 17:34:42 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id EB1D752D4; Tue,  6 Apr 1999 17:34:41 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <370A7D51.C74400E9@dnrc.bell-labs.com>
Date: Tue, 06 Apr 1999 17:32:01 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Jerry Scharf <scharf@vayu.net>
Cc: iptel@lists.research.bell-labs.com
Subject: Re: is there a better list to ask H.323 questions of
References: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

This is not the right list. This list is for the iptel working group in
IETF. Please use the h323 implementors list for h.323 questions.

Thanks,
Jonathan R.

Jerry Scharf wrote:
> 
> I have seen several questions on H.323 go by here. I have one on V2 and was
> wondering if there is a better place to ask it or if here is the right
> place.
> 
> thanks,
> jerry
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 18:05:43 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18709
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 18:05:43 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5D04952CD; Tue,  6 Apr 1999 17:27:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BE5E752CF; Tue,  6 Apr 1999 17:27:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: "Jerry Scharf" <scharf@vayu.net>
To: <iptel@lists.research.bell-labs.com>
Subject: is there a better list to ask H.323 questions of
Date: Tue, 6 Apr 1999 14:27:09 -0700
Message-ID: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have seen several questions on H.323 go by here. I have one on V2 and was
wondering if there is a better place to ask it or if here is the right
place.

thanks,
jerry


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 18:47:46 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19618
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 18:47:43 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 9609452D0; Tue,  6 Apr 1999 18:43:22 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id F2A1052CB; Tue,  6 Apr 1999 18:43:21 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: Buenos Aires New Travel <info@newtravel.com.ar>
To: <iptel@lists.research.bell-labs.com>
Message-Id: <18161.236256.81913681 iptel@lists.research.bell-labs.com>
Subject:  Abri - Mayo / Tarifas Aereas
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 6 Apr 1999 19:41:51 -0300
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Estimados Amigos:
Les hacemos llegar los mejores precios a los principales destinos para el resto de 
la temporada baja:

San Pablo $ 222.- Canadian , Valido por 30 dias , hasta el 24/06
Rio de Janeiro $ 240.- Vasp , Valido por 90 dias , hasta el 20/07
Santiago de Chile $ 130.- KLM , Air France , British Airways , Valido por 30 dias
Miami $ 549.- , Vasp , valido por 90 dias
New York $ 649 Lunes a miercoles - $ 699 Jueves a Domingos , Aerolineas 
Argentinas, valido 30 dias , hasta 31/5
Madrid $ 799.- Spain Air , Valido por 30 dias.
Paris $ 849 , 30 dias , 29/4
Londres $ 849.- , 30 dias , 31/05
Roma $ 845 , valido 14 dias , hasta 30/04
Sydney (Australia) , $ 1099.- valido 21 dias hasta el 31/05
Frankfurt $ 845.- Valido 14 dias KLM

Cabotaje : Todas las cias aereas.

Reservas Hoteleras en todo el mundo, con confirmacion y pago en Buenos Aires.

Buenos Aires New Travel
Esmeralda 1269 - 1007 - Capital Federal
Tels. 4312-5004 / 4315-8148 / 4312-6160 / 4313-2490
E-Mail: info@newtravel.com.ar  /  reservas@newtravel.com.ar
______________________________________________________________________
Le pedimos disculpas si este mensaje no es de su interes,para no recibir este 
mensaje nuevamente conteste el mismo con OUT en el subject.
______________________________________________________________________
<Date>



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr  6 18:57:08 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19780
	for <iptel-archive@odin.ietf.org>; Tue, 6 Apr 1999 18:57:07 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id C2DD852D1; Tue,  6 Apr 1999 18:51:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 20AD352CB; Tue,  6 Apr 1999 18:51:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <199904062249.PAA07911@ca.mew.com>
X-Sender: claude@158.118.11.12
X-Mailer: Macintosh Eudora Pro Version 3.1.1-Jr2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 6 Apr 1999 15:49:27 -0700
To: iptel@lists.research.bell-labs.com
From: Claude Huss <claude@mew.com>
Subject: remove me from this list
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk




---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 00:25:53 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24146
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 00:25:53 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 6DB5E52CB; Wed,  7 Apr 1999 00:17:52 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5B71E52D7; Wed,  7 Apr 1999 00:17:51 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: archow@hss.hns.com
To: iptel@lists.research.bell-labs.com
Date: Wed, 7 Apr 1999 00:15:12 -0400
Message-Id: <19990407041711.5ED8C52CB@lists.research.bell-labs.com>
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 00:32:30 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24240
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 00:32:28 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 2E8ED52D4; Wed,  7 Apr 1999 00:18:08 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 85FDF52D3; Wed,  7 Apr 1999 00:17:59 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Wed, 7 Apr 1999 09:27:45 +0530 (IST)
From: Arjun RC <archow@hss.hns.com>
To: Nagaraj_Vn <vittaln@agcs.com>
Cc: iptel@lists.research.bell-labs.com
Subject: Re: [Fwd: H323 RAS signalling and call signal transport address]
In-Reply-To: <6525674B.006E605D.00@sampark.hss.hns.com>
Message-ID: <Pine.LNX.4.05.9904070923280.22363-100000@hss068.hss.hns.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


Hi Nagraj,


On Wed, 7 Apr -1, Nagaraj_Vn wrote:
Nag> If above is true, then what is the use of the callSignal Transport
Nag> address field in the RCF message sent by Gatekeeper? My initial

When a terminal does a RRQ it does not know whether it will be a caller or
callee in a call. For example, if A wants to call B thru GK,
A needs to know the CallSigAddr of GK and GK needs to know the CallSigAddr
of B. So here, the GK needs to know the CallSigAddr of a terminal and a
terminal needs to know the CallSigAddr of GK.
I think that is why both specify their CallSigAddr at the time of
Registration.

Please correct me if Im wrong.

Cheers
ARC

In accord to UNIX philosophy, PERL gives you enough rope to hang
yourself.  
		      - Larry Wall, Randal Schwartz (Camel Book) 
------------------------------+----------------------------------+
(O): Hughes Software Systems  |(R): 68/G, 2nd Narayanappa Block, |
146, Prestige Opal Bldng,     |R.T. Nagar,                       |
Infantry Rd, Bangalore-560001 |Bangalore-560032                  |
Ph:+91-80-2286390/91/92       |Ph:+91-80-3430565                 |
------------------------------+----------------------------------+
http://arjun.cjb.net, http://hss068.hss.hns.com (intra HSS)



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 01:32:35 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24662
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 01:32:33 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 733B452B7; Wed,  7 Apr 1999 01:26:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BCFD852BB; Wed,  7 Apr 1999 01:26:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <370AEC61.DE67E7F5@dnrc.bell-labs.com>
Date: Wed, 07 Apr 1999 01:25:53 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: list iptel <iptel@lists.research.bell-labs.com>
Subject: Minutes of Minneapolis meeting
Content-Type: multipart/mixed; boundary="------------FDBE1B152AEFB8CFB4B332D8"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------FDBE1B152AEFB8CFB4B332D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks,

I've finished a first draft of the minutes, which are enlosed with this
email. Comments, omissions, or errors are welcome. I'd also ask those
who are mentioned by name in the minutes (Jonathan Lennox, Matt Squire,
Hussein Salama, Scott Petrack, Dave Oran, Gur Kimchi, Jim Luciani) to
give this a more careful read and make sure you have not been misquoted.

Unfortunately, these are due end of the day today, so I need feedback
asap. Sorry for the short notice, I only received the minutes recently.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
--------------FDBE1B152AEFB8CFB4B332D8
Content-Type: text/plain; charset=us-ascii; name="iptel_minutes_mar99.txt"
Content-Disposition: inline; filename="iptel_minutes_mar99.txt"
Content-Transfer-Encoding: 7bit

iptel Meeting Minutes
44th IETF
Minneapolis, MN
Tuesday, Mar 16 1300-1515

Minutes prepared by:
Jonathan Rosenberg

Minutes taken by:
Joerg Ott

The iptel working group met for a single, busy, two hour
session. There were neraly 200 people in attendance. The session was
multicast on the mbone.

The meeting started with agenda bashing. The original agenda was
reordered. Squire disussed the open attribute issues first, and then
he discussed the SCSP approach for GLP. Following that, Hussein Salama
presented the TBGP approach for GLP. Jonathan Lennox then discussed
CPL transport issues, followed by the CPL itself.

GLP Data Representation Issues
------------------------------

Matt Squire, Nortel Networks
Slides at http://www.bell-labs.com/mailing-lists/iptel/glp_data.ppt

[Slide 2] There are a number of things required for the GLP routing
objects. The phone number prefix is the most important one, and then
there are a number of attributes that describe the route to this
prefix. Some of these are optional, and some should be mandatory.

[Slide 3] One of the main issues is how to represent phone
numbers. There has been much discussion of this on the list. The
encoding must be determined, along with the set that can be
represented (range, prefix, regular expression), and whether we need
"black holes". For the encoding, the proposal was to use a hex (i.e.,
4 bits) representation for each digit, as this was more compact than
the other proposals (char = 8 bits per number, or BCD of 8 bits per
number). The general sense that encoding determination was premature,
since there hadn't been sufficient discussion on the list in this in
particular. Furthermore, the encoding should depend on how we do
aggregation and what the numbers represent. 

Then, the tough issue of number representation (ranges, prefixes, or
regexp) was presented. It was first argued that ranges were not much
more useful than prefixes. However, Scott Petrack raised an
interesting requirement. A certain ISP owns every 123-4567 number in
each area code in the US, used as their "universal dialup number". A
gateway might like to service a number like this, but it can't be
represented with either ranges or prefixes. Regular expressions could
work. However, David Oran raised the important point that the
definition of "longest prefix match" is ill defined in the case of
regular expressions. Some notion of this concept would be needed in
order to enable routing to properly occur.

The discussion then moved to the issue of "black holes"; the problem
being that a set of prefixes might not be aggregatable since one of
the numbers needed to perform the aggregation simply doesn't
exist. This prefix is essentially a "black hole" in the numbering space. The
question is - do we worry about this, and if so, what to do? The issue
is related to whether aggregation is performed semantically (the LS
knows the structuring of numbering plans, and groups together numbers
which are groupable, by region, for example) or syntactically (based
purely on redundancy in the bits, like is done with IP addresses). The
question of what does it mean to "not exist" was raised. Are these
numbers which will never exist, or temporarily out of service? What
happens if an LS advertises a route to an aggregate since it thinks
one of the routes that was aggregated doesn't exist anyway, but it
actually does? Another issue is whether these black holes might
explicitly be communicated as part of the route itself. It wasn't
clear that this was useful.

It was mentioned that the representation should support syntactic
aggregation, but that semantic aggregation was allowed. An LS could
advertise any prefix so long as it was sure it could reach that
prefix, however this determination is made. Effectively, advertising a
prefix was a "promise" of the ability to deliver service to this
prefix.

There was no consensus on any of these issues. It was agreed more
discussion is needed on the list.

[Slide 4] The next issue was what kind of numbers are allowed in
GLP. Consensus was reached on the list that routable PSTN numbers are
certainly included. There was apparent consensus that private numbers
were not permitted (GLP being an inter-domain protocol). The open
issue was with numbers like 800 numbers, or numbers which did not have
global uniqueness (800 numbers are like this, how they are routed
depends on where the call comes from). It was proposed [slide 5] that
the LS need not understand the properties of these various numbers,
and that any properties be conveyed by attributes. Matts' slides
discussed the various ways in which a particular number might be
treated based on caller locale, private numbering plans, time of day,
and so on [slides 6,7,8,9].

After some discussion, there seemed to be consensus that for numbers
which were not globally unique, we add an attribute (perhaps not
called scope, a term over-abused on the list) which effectively makes
the number unique. This attribute is, in fact, considered as nothing
but an extension of the number itself, so the same aggregation rules
for numbers apply to it.

As for time of day sensitivity, there seemed to be consensus to keep
these things out of GLP. It was recognized that there was a need for a
"translation service", which would take a number like an 800 number,
and based on any number of parameters provided by a user, result in a
translation to a routable PSTN number. Then, GLP could be used to find
the gateway towards this routing number. This translation service
seemed to be within the scope of the enum group, under formation. 

The next issue discussed was that of lifetime [Slide 10]. Gateway
objects may have finite lifetimes. For example, an 800 number may only
be valid for a certain amount of time. So, do we include the lifetime
in the routing object as an attribute, or should the advertising LS
simply withdraw the route when it expires. There was general consensus
that the route should be explicitly withdrawn, and there would be no
lifetime attribute. This is consistent with existing routing
protocols.

An interesting and related issue was brought up. In GLP, an LS need
not change the next hop for a route it propagates. So, in the
following case:

GW1 -----> LSA ------> LSB

LSA knows of GW1, and sends an advertisement for it to LSB. The next
hop is listed as "GW1" in the advertisement to LSB. Now, if the peer
relationship between LSA and LSB is lost, should LSB assume the route
to GW1 is also lost? Since LSA is not a next hop for signaling, its
status as up or down has no bearing on whether the call can be
completed or not. There was no consensus on this issue.

The next issue was signaling protocols. These are an attribute of a
gateway [slide 11]. The question was which protocols? There was
consensus that H.323 and SIP were yes. Since MGCP is a control
protocol, and not a signaling protocol, MGCP seemed unneeded, along
with SGCP and IPDC, its predecessors. With H.323, the question was
whether RAS and Q.931 were separate or not. There was no decision. It
was agreed that we would provide a few tags, and define IANA
procedures for registering new ones for future signaling protocols.

The final attribute issue discussed was capacity [slide 12]. The
questions are absolute vs. relative, static vs. dynamic, and whether
its a path, gateway attribute, or both. Also whether the metric is
dimensioned or dimensionless. There was consensus at the last meeting
that this metric was not dynamic, but represented the total capacity
of the gateway. There was no objection to the decision to use a
dimension for the metric in order to allow vendors to independently
set the metric and use comparable values. There was no consensus on
what the dimension should be (calls, bits/sec, etc.).

Unfortunately, time ran out and the next presentation began.


Gateway Location Protocol based on SCSP
---------------------------------------
Matt Squire, Nortel Networks
http://www.bell-labs.com/mailing-lists/iptel/glp_scsp.ppt

Matt presented his arguments on why SCSP was a good choice as a basis
for GLP. First off, GLP is an inter-domain protocol, so one
immediately thinks of BGP. However, this is not a layer 3 protocol,
and there are differences, so a different approach is warranted. SCSP
provides database synchronization among autonomous servers. SCSP
defines a server group (SG) as a collection of servers being
synchronized. The idea with SCSP is that for interdomain exchanges,
the SG has two, and exactly two, servers - the two peers. For interior
exchange among GLP LS's in the same domain, there is a different
SG [Slide 2]. SCSP supports arbitrary topologies for this interior
synchronization.  

The model of a GLP LS was shown [Slide 3]. Through various server
groups, it learns about gateways, and based on policy decisions,
propagates these to other server groups. 

Matt then presented the reasons why GLP is not BGP:

1. BGP must always provide a next hop on the same LAN. However, since
GLP is at a higher level, there is an underlying IP transport service.
So, an LS can choose to not modify the next hop at all; it can be
bypassed all together for signaling. The only reasons to actually
change it are for (1) aggregation, or (2) collection of billing
information from the signaling messages [Slide 4,5].

2. In BGP, if there are two routes to a destination, only one is
propagated. Basically, routes are "homogeneous" - they are all the
same. Not true in GLP. Routes for the same prefix may be different if
their attributes (like signaling protocol) are different, and so both
may need to be propagated. BGP doesn't do this. [slide 6]

3. In BGP, the FIB is extracted purely based on destination
address. This doesn't work in GLP. A "FIB" would need to also look at
the parameters of the call signaling to determine which route is
appropriate. Thats because GLP routes call signaling messages, which
are much more complex than IP packets. [slide 7]

4. Efficiency and scaling requirements differ (fewer call setup
messages compared to packets) [Slide 8]. However, Dave Oran pointed
out that an LS may also route voice packets. He argued that this was
useful for firewall traversal, and would motivate providing next hop
information in general for GLP, for both signaling and media (next hop
at the layer 7, GLP, definition).

Next, Matt argued why SCSP was a good choice:

1. SCSP separates the synchronization of data from the semantics of
the data itself [slide 9]. This is perfect for GLP, where we need a
generic sync mechanism, and then need to add GLP specific attributes
and data on top. SCSP was designed to be a "core" component, with
instances defined for specific applications.

2. SCSP supports arbitrarily connected topologies for intra-domain
synchronization [slide 10]

3. SCSP can run on any transport [slide 11]

There was little discussion at this point; most of it followed the
presentation on TBGP.

Telephony Border Gateway Protocol (TBGP)
----------------------------------------
Hussein F. Salama, Cisco, hsalama@cisco.com

Quick TBGP overview [Slide 2]
- based on BGP-4 and its multiprotocol extensions
- reliability, peering relationships, loop detection mechanisms
- advertised reachability of PSTN destinations and IP destinations
- multi-hop call routing.  egress gw is just another hop on call route
- route selection. intermediate domains apply policy on call route
  network admin control route selection
- route aggregation

BGP itself does not solve all the GLP problems. We propose an
extension sthat taskes care of additonal needs. 

The first question is whether TBGP and BGP4 are the same (i.e., do we
introduce telephone numbers into existing, running, BGP-4
systems). Answer is NO. TBGP runs separately from BGP4. But, we
leverage experience from the specification to make a good protocol
[slide 4]. 

TBGP supports multiple protocol types (SIP, H.323), route aggregation,
route selection etc. How to handle the case where the media flows
through the LS? [slide 5]

Dave Oran then proposed a scheme for dynamic capacity metrics. The
idea is that when a gateway has used all its capacity, it withraws
routes to itself with its peers. When it has capacity, it puts it
back. Normally, you need route-dampeners at next hops, so some of this
oscillation would be avoided. This provides a way to propagate a
sort-of-dynamic metric, but in a more scalable way. There were
concerns raised about the scalability of this solution, and no
consensus was reached on whether to do this.

Hussein then discussed the Intra-domain vs. inter-domain call routing
scenarios [slide 7]. He argued that these are much different problems,
and that intra domain worries most about QoS and multihop call
routing, while inter-domain worries about policy and cost, and QoS is
much different. Thus, he countered the argument that SCSP was good
since it helps solve the intra-domain problem. We should leave the
intra-domain problem to another group, and weigh the protocols based
on their ability to do inter-domain.

The remainder of Hussein's slides focused on attribute issues, and
since these were discussed already they were skipped.

Concusions
- TBGP satisfies all tranport requirements of the GLP framework
- attributes are yet to be defined
- well tested and scales well - we know how this works!
- intra-domain call route is a separate problem

Jim Luciani argued that SCSP's strength is to allow for arbitrary
topologies, and that it could handle intra-domain QoS issues. Someone
argued that since SCSP was similar to OSPF, it wouldn't handle things
like AS path, which were needed in an inter-domain case. This was
countered with the argument that we could make AS-path just another
attribute that gets synchronized by SCSP between peers, and get this
functionality. 

Another strength of SCSP was that the nodes that are synchronized
don't need to understand the semantics of the data being synchronized,
that is handled by the higher layers.

The question was asked as to whether there were commercial and
interoperable implementations of SCSP. The answer (from Jim) - yes,
they are out there, and yes they are commercial.

It was concluded that in the inter-domain case, the type of
information being carried by BGP and SCSP would be similar, and thus
the differences between the protocols was at a much more detailed
level. 

To resolve the issue, the chair asked the authors to do a "homework
assignment", and work on understanding detailed differences between
the two proposals. This will then be taken to the list.

At this point, the group left discussions of the GLP, and focused on
the CPL. The first presentation was on transport.

CPL and CGI Transport in SIP Register Paylaod
---------------------------------------------
Jonathan Lennox, Columbia University
http://www.bell-labs.com/mailing-lists/iptel/sipreg-minneapolis1.pdf

Jonathan quickly went over his slides. The basic idea was that the CPL
is uploaded to the server in a REGISTER message. There is a single
server per user. The main issue is persistene. Normally, a SIP
registration times out, and disappears unless refreshed. But, CPL's
would not time out. They would be uploaded once, and never re-uploaded
when the registration itself is refreshed.

This generated some discussion about whether this model was right. One
idea (Gur Kimchi) was that the REGISTER contains a script for the
client, and when it registers, that script is used. When the client
goes away, and the registration expires, so does its script, and then
we use the script that was previously in place.

Scott Petrack argued as to why do this in SIP at all? Why can't I use
ftp, or http, or whatever? Clearly REGISTER was not meant to send user
logic to a server. The answer was that SIP provides much of the
transport service we need. It gives authentication, it uses the same
identifiers we need to tie the script to a user, and its the same
application. However, there was agreement that there need not be a
single transport mechanism.

Another issue was whether the "one-script" model is sufficient. We may
need more. Jonathan R. raised the concern, however, that if more than
one script exists, how would the server know which to execute when the
call arrives? Rather, there is a single top level script, and the user
can upload multiple files which get linked in to the script at
specific points. This is really mutiple files, still a single script
though. 

Dave Oran raised an important issue - that there is a difference
between a *user* and a *client*. The client is one instance of the
user. Both clients (like my cell phone or work PC) and users may have
logic they'd like to upload. So, the framework should allow for
scripts for users and clients.

Scott Petrack added further that a single user may have multiple
scripts, each at a different server. 

Jonathan Lennox then continued with his presentation, focusing on some
of the open issues.

It was suggested that even SNMP might be used for transport, and that
the MIB specifies the script.

Given the various options for transport, there was consensus that the
transport problems should not be tackled in iptel. Rather, if someone
wanted to use protocol X for transport of CPL, the CPL transport would
be done in the group specifying protocol X. Jonathan Lennox was asked
to repeat his presentation to mmusic for this reason.

The next presentation was on the CPL itself.

Call Processing Language
------------------------
Jonathan Lennox, Columbia University
http://www.bell-labs.com/mailing-lists/iptel/cpl-minneapolis1.pdf

Jonathan began by showing that the CPL model is based on a DAG
(directly acyclic graph), which describes the flow for a service. Each
node is a decision or an action, and the outputs represent decision
results or action results [slide 2]

He then summarized the features [slide 4]. There are switches for
making decisions (based on time, or by string matches of fields in the
request messages), and actions, such as proxy, redirect, and
respond. There is also a location action for setting the destination
of a proxy or redirect, and a lookup action for querying a
database. There are also non-SIP actions, such as notify and log.

Scott Petrack raised the issue about whether XML is an efficient
representation. Jonathan L.'s response was that the XML is for
transmission. Once it arrives at the server, it is parsed and stored
in some internal format which can be efficiently executed. Thus, the
parsing overhead is suffered only on registrations. Gur suggested a
binary representation instead.

Gur also asked if the script is persistent during the call. The answer
was not in this version; the script is "done" once the call is
established. We have left hooks for future scripts to specify services
after the call is established.

Matt Cannon asked if the script could specify logic for OPTIONS. Right
now, no; but this could easily be added. Another question was whether
the CPL should support decisions based on media types for the call
(audio, video, etc.). There seemed to be consensus that this was a
good thing to have.

Jonathan then continued with the open issues. URL matching is
currently done by string matching, which is nicely general but not
very efficient, and it is hard to do certain things. Supporting URL
specific decisions means that the script may no longer be H.323/SIP
independent. 

Time switches also presented problems. Timezones are especially
difficult, since there is no registry of names for timezones. So, the
CPL assumes that the user and server sit in the same timezones. A
question was asked as to why not just represent timezones as an offset
from GMT? The answer is daylight savings time makes this offset
variable.

Jonathan L. asked the question about whether CPL should be
configurable about whether to do recursion. Dave Oran responded that
this stuff is really new, and we should absolutely stick with KISS,
get something out the door, get some operational experience, and then
build on that. So, the answer to the original question seemed no -
there was consensus that specifying SIP recursion or not was outside
the scope of CPL.


With that, the meeting concluded.

--------------FDBE1B152AEFB8CFB4B332D8--


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 05:26:15 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02521
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 05:26:15 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id BC28C52BB; Wed,  7 Apr 1999 05:21:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 221C452BF; Wed,  7 Apr 1999 05:21:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.5.32.19990407111742.007b1210@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 07 Apr 1999 11:17:42 +0200
To: conf@colmar.colmar.uha.fr
From: Conf ICATM99 <conf@colmar.uha.fr>
Subject: ICATM99 - Preliminary Program
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02521

Please feel free to circulate this following preliminary program of ICATM99
to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM99.html for
more information). 
Accept our sincere apologies if you receive multiple copies.

------------------------------------------------------------------

TECHNICAL PROGRAM

08:00 - 18:00 Conference Registration

Monday June 21

08:30 - 09:00	Opening Address 

09:00 - 10:00 Tutorial Session 1
Chair: M. Lee

Mobile and Wireless ATM Networks - Third Generation Systems (UMTS/IMT2000)
G. Omiyar, GTE Telecom, Egypt

10:00 - 10:30 Coffee Break

10:30 - 11:30 Tutorial Session 2
Chair: S. Rao

Rich VPNs: the Best win-win Deal between a Carrier and its Customers
S. Ritzenthaler, Newbridge, France

11:30 - 12:30 Tutorial Session 3
Chair: J. Crowcroft

Implementing Ipv6 over ATM
M. Souissi, F. Dupont, B. Leroy, INRIA Rocquencourt, France

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 15:30 Wireless ATM 1
Chair: G.S. Kuo

A Hybrid Data/Header Interleaving Strategy for Wireless ATM Networks
S.T. Sheu, T.F. Sheu, TamKang University, China

A Deadlock Model for a Multi-Service Medium access Protocol Employing
Multi-Slot N-ARY Stack Algorithm (MSSTART)
F. Cameron, M. Zukerman, University of Melbourne, Australia

Optimal DLC Protocol Configuration for Realistic Broadband Fixed Wireless
Access Networks based on ATM
S. Mangold, Aachen University of Technology, Germany

14:00 - 15:30 Flow Control in ATM: ABR 1
Chair: P. Rolin

Guaranteeing Fairness and Protection in ABR by Means of Fair Queuing
L.A. Guijarro, J.R. Vidal, J.Martinez, University of Valencia, Spain

Fluid Analysis of a TCP Connection over ABR, in Presence of Exogenous Flow
J.L. Costeux, CNET, France

Bidirectional ABR Mechanism
P. Homan, J. Bester, University of Ljubljana, Slovenia

15:30 - 15:45 Coffee Break

15:45 - 17:15 Wireless ATM 2
Chair: G. Omidyar

Routing Protocols for Wireless Ad hoc ATM Networks
A. Hettich, A. Kadelka, H. Kukulies, Aachen University of Technology, Germany

Hand-Off and Synchronization Protocol for Supporting Multimedia
Communications in an ATM based Wireless Network
A. Leon, M. Esteve, J.C. Guerri, C. Palau, A. Pajares, Polytechnic
University of Valencia, Spain

A Flexible Signaling Protocol for Supporting Switched AAL Type 2
Connections in UMTS Terrestrial Radio Access Networks
I.. Szabo, Ericsson, Hungary

15:45 - 17:15 Flow Control in ATM: ABR 2
Chair: G. Pujolle

Evaluation of the Virtual Source/Virtual Destination-Technique for
Available Bit Rate Traffic in ATM-Networks
J. Baalmann, C. Cseh, University of Technology Aachen, Germany

ABR Rate Control for Multimedia Traffic using Microeconomics
E.W. Fulp, D.S. Reeves, North Carolina State University, USA

Evaluation of the TCP Traffic over the ABR Service Targeted to Support Mass
Storage Applications
I. Mountzouris, G. Orphanos, A. Birbas, S. Koubias, G. Papadopoulos,
University of Patras, Greece

17:15 - 17:30 Coffee Break

17:30 - 19:00 Management
Chair: S. Rao

Model-Based-Diagnosis for Fault Management in ATM Networks
F. Krief, A. Osmani, Institut Galilée, France

A Model of Fault Messages for Maintenance of UNI/NNI Resources in HANbit
ACE64 ATM Switching System
G. Kwon, ETRI, Korea

Dynamic Management of Routing Tables and Connection Re-routing in ATM Networks
S. Kumar, S.V. Raghavan, Indian Institute of Technology Madras, India


17:30 - 19:00 Multicast
Chair: J.J. Pansiot

Compound VC Mechanism for native Multicast in ATM Networks
J. Mangues-Bafalluy, J. Domingo-Pascual, Polytechnic University of
Catalunya, Spain

IPv6 Multicasting over ATM Testbed
J.S. Silva, N. Veiga, S. Duarte, F. Boavida, University of Coimbra, Portugal

Design and Analysis of Multicast Delivery to Provide VCR Functionality in
Video-on Demand Systems
W. Poo, K.T. Lo, The Hong Kong Polytechnic University, Hong Kong ; J. Feng,
City University of Hong Kong, Hong Kong


Tuesday June 22

09:00 - 10:30 Real-Time Traffic
Chair: M. Dickmann

A Method for Accurate Time Synchronization through In-Service Monitoring in
ATM Networks
D. Vidal, University of the Balearic Islands, Spain

Delay Jitter Guarantee for Real-Time Communications with ATM Network
Z. Mammeri, University Paul Sabatier, France

Hierarchical Vector Clock: Scalable Plausible Clock for Detecting Causality
in Large Distributed Systems
D.A. Khotimsky, Lucent Technologies, USA ; I.A. Zhuklinets, Mozhaysky
Academy, Russia

09:00 - 10:30 IP over ATM 1
Chair: G. Girardi

Shortcutting IP Flows over Large ATM Networks
J. Schmitt, L. Wolf, M. Karsten, R. Steinmetz, Darmstadt University of
Technology, Germany ; Y.O. Lorcy, C. Siebel, Deutsche Telekom, Germany

Measurement-Based Simulation Model for TCP over ATM
G. Seres, T. Elteto, A. Olah, Ericsson telecommunications, Hungary

On the Efficiency of Packet telephony over IP and ATM
M. Baldi, F. Risso, Polytechnic of Torino, Italy

10:30 - 11:00 Coffee Break

11:00 - 12:30 Traffic Control
Chair: D. Kofman

Networks Performance Based Connection Admission Control Model in ATM
Networks: Immediate and Future Reservation Approaches
M. Nour, University of Montreal, Canada ; A. Hafid University of Western
Ontario, Canada ; M. Gendreau, University of Montreal, Canada

Validating novel CAC algorithms on ATM testbeds
J. Levendovszky, Z. Elek, C. Vegso, Technical University of Budapest, Hungary

The Design of an Object-Oriented Simulation Tool for Evaluating ATM Network
Resource Control Scheme
J. Soldatos, D. Vergados, E. Vayias, N. Mitrou, National Technical
University of Athens, Greece

11:00 - 12:30 IP over ATM 2
Chair: F. Vanney

A Framework for Testing IP QoS over ATM Networks: Implementation and
Practical Experiences
N. Kroth, L. Mark, J. Tiemann, GMD, Germany

A Study on Advanced Asynchronous Transfer Mode for High-Speed Computer
Communication Networks
K. Toyoshima, K. Hayashi, NTT, Japan

VTOA/VoIP/ISDN Telephony Gateway
A.M. Grilo, P.M. Carvalho, L.M. Medeiros, M.S. Nunes, INESC, Portugal

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 15:30 Quality of Service
Chair: A. Benslimane

Efficient Buffer Management and Scheduling in a Combined IntServ and
DiffServ Architecture: a Performance Study
G. Mamais, M. Markaki, G. Politis, I.S. Venieris, National Technical
University of Athens, Greece

Interaction of RSVP with ATM for the Support of Shortcut QoS Virtual Channels
R. Cocca, S. Salsano, CoRiTeL, Italy ; M. Listanti, University of Rome, Italy

Interactive Services over HFC Networks
M.I. Borges Ribeiro, F. Fontes, J. Bastos, J. Loureiro, Portugal Telecom,
Portugal

14:00 - 15:30 IP over ATM 3
Chair: M. Stuttgen

Analysis on IP Label Switching Technology in Future Broadband Internet
G.S. Kuo, H.C. Cheng, National Central University, Taiwan

Analysis of Internet Services in IP over ATM Networks
J. Aracil, M. Izal, D. Morato, University of Navarra, Spain

Simulation and Analysis of IP/ATM Switching and Routing
M.Z. Santos, L.G. Kiatake, F. Meylan, S.T. Kofuji, University of Sao Pailo,
Brazil ; J.P. Coutiat, LAAS-CNRS, France

15:30 - 15:45 Coffee Break

15:45 - 17:15 Scheduling
Chair: R. Muraine

Flow Service Order: A Computationally Inexpensive Packet Scheduling
Algorithm to Guarantee QoS for Real-Time Traffic
S.R. Kulkarni, Indian Institute of Technology, India

A Feasible Scheduling Algorithm for Per-VC Queuing ATM Switches
P. Zhou, W.W. Yang, Nortel Networks, Canada

Digital Neural Cell Schedulers for ATM Switch
S.M. Lee, J.H. Chung, Y.C. Kim, M.M. Lee, Dongshin University, Korea

15:45 - 17:15 User Applications
Chair: M. Potts

ATM-Based Infrastructure for Teleteaching at University
A. Klein, F. Bodendorf, University of Erlangen-Nuremberg, Germany

Desktop Videoconferencing Performance and Quality of Service Evaluation on
an ATM-based Metropolitan Area Network: OASICE Case Study
H. Tobiet, Clemessy, France ; P. Lorenz, University of Haute Alsace, France

Connecting Heterogeneous Supercomputers in Broadband Networks
E. Pless, F. Hommes, GMD, Germany

17:15 - 17:30 Coffee Break

17:30 - 19:00 Management and multiplexing
Chair: Z. Mammeri

A Management System Providing Real Distribution of Management Tasks with
Time and Space Independence
F. Fontes, Portugal Telecom, Portugal ; T. De Miguel, A. Azcorra,
University of Madrid, Spain

Implementing Inverse Multiplexing for ATM
A. Pires, Mitel Corporation, Canada

The Heap-Sort Based ATM Cells Spacer
T. Ha-Duong, MET, France

17:30 - 19:00 Protocols and Routing
Chair: P. Droz

Minimum Equivalent Subspanner Algorithms for Topology Aggregation in ATM
Networks
W. Chiou Lee, Motorola, USA

Shared-Medium Architecture for ATM Local Network
M. Soto, S. Sallent, Polytechnic University of Catalonia, Spain

Analysis of the Crankback Probability in a Hierarchical PNNI Network
J.L. Rougier, D. Kofman, ENST, France ; A.R. Ragozini, University of
Napoli, Italy ; A. Gravey, CNET, France

20:00 Gala Dinner - Restaurant Meistermann

Wednesday June 23

09:00 - 10:30 Intelligent Networks
Chair: P. Lorenz

Design and Implementation of an Intelligent Peripheral for Broadband
Multimedia Applications
H. Brandt, P. Todorova, GMD, Germany

A TINA-Based Platform for Service Deployment and Usage
J. P.C. Verhoosel, Telematics Institute, The Netherlands ; H.J. Batteram,
J.L. Bakker, Lucents Technologies, The Netherlands

Performance of the fair Intelligent Congestion Control for TCP Applications
over ATM Networks
D.B. Hoang, Q. Yu, University of Sydney, Australia

09:00 - 10:30 ATM Switches 1
Chair: Z. Hulicki

RCES: A Replication/Contention/Elimination Strategy for Replication
Baseline ATM Switch Architectures
S.T. Sheu, Y.R. Chuang, TamKang University, China

Advanced Frame Recovery in Switched Connection Inverse Multiplexing for ATM
F.M. Chiussi, D.A. Khotimsky, S. Krishnan, Lucent Technologies, USA

Implementation of an ATM Switch for PSTN/N-ISDN Services
X. Gong, P. Zhang, W. Wang, S. Cheng, university of Posts and Telecom, China

10:30 - 11:00 Coffee Break

11:00 - 12:30 Error Detection and Correction
Chair: O. Charles

Implementation of an Error Detection-Recovery System based on Multimedia
Collaboration Works: EDRS
E.N. Ko, Sung Kyun Kwan University, South Korea

New Error Control Enhancing Technique for Wireless ATM Networks
M.M. Al-Khatib, M. Bayoumi, USL, USA

A Parallel Reed-Solomon Coding/Decoding Structure for an ADSL Modem with
Increased Interleaving for ATM Applications
S. Toptchiyski, D. Sofos, V. Stylianakis, University of Patras, Greece

11:00 - 12:30 ATM Switches 2
Chair: S. Ritzenthaler

An Efficient Address Assignment Strategy for Shared Multibuffer ATM Switches
P.G. Lee, W.C. Kang, Y.H. Choi, Hongik University, Korea

Implementation of Bifurcated Buffering in Input Buffer Banyan ATM Switch
I.D. Radusinovic, Z.R. Petrovic, M.Pejanovic-Djurisic, University of
Montenegro, Yugoslavia

An Approximate Analysis of a Shared Buffer ATM Switch using Input Process
Aggregation Technique
J.Kim, C.H. Jun, Pohang University of Science and Technology, Korea ; K.P.
Jun, Electronics and Telecommunications Research Institute, Korea

12:30 - 14:00 Lunch - Restaurant Universitaire

14:00 - 16:00 Performance
Chair: H. Tobiet

Performance Evaluation of a RR Switch for ABR Service
D.H. Kim, Y.Z. Cho, Kyungpook National University, Korea

Performance Models for IP Switching
J. Zheng, V.O.K. Li, University of Hong Kong, Hong Kong

Inverse Multiplexing for ATM Operation, Applications and Performance
Evaluation Issues
M. Aguilar-Igartua, J. Garcia-Haro, M. Postigo-Boix, Polytechnic University
of Catalonia, Spain

Performance Evaluation of Packet Discard Schemes in ATM Switches in
Heterogeneous Traffic Environment
Z. Jing, L. Li, University of Electronic Science and Technology, China ; H.
Sun, Center for Advanced Computing and Communications, China

14:00 - 16:00 Video over ATM
Chair: J. Montiel

Error Resilient Protocol Architecture for the MPEG-2 Video Transmission
over ATM Networks
P. Cuenca, A. Garrido, F. Quiles, University of Castilla-La Mancha, Spain ;
L. Orozco-Barbosa, University of Ottawa, Canada

De-Jittering in the transport of MPEG-4 and MPEG-2 Video over ATM
K. Shuaib, T. Saadawi, M. Lee, City College of New York, USA, B. Basch, GTE
Laboratories, USA

Proactive Management of MPEG Traffic in ATM Networks using Time Sequenced
RLS Filters
T.S. Randhawa, British Columbia Group, Canada ; R.H.S. Hardy, Simon Fraser
University, Canada

Linear Codes for End to end Cell Loss Recovery in VBR Video Transmission
over ATM Networks
Z. Alkhalifa, V.S.S. Nair, Southern Methodist University, USA

16:00 Closing Session

	ICATM'99 Registration Form
	Please mail the complete Registration Form to :
	Pascal LORENZ / ICATM'99
	IUT/GTR - 34 rue du Grillenbreit - 68008 Colmar, France
	Phone : 33 (0)3 89 20 23 66   Fax : 33 (0)3 89 20 23 59   Mobile: 33 (0)6
03 65 80 42
	Email : lorenz@colmar.uha.fr


Title: _______ First Name: _____________ Last Name: ______________________ 

Institution: ___________________________________________________________ 

Street Address: ________________________________________________________ 

City: __________ State: ____________ Zip: ___________ Country: ____________ 

Phone: ____________________________ Fax: ______________________________ 

Email : ____________________________ 

Arrival Date :     ____ June 1999 at _____ 
Departure Date :   ____ June 1999 at _____ 

Conference Registration Fees: 

The Full registration fees include: attendance to the Conference, coffee
breaks, 3 lunches, the gala dinner and the preprints. 

Academic rate:                

IEE, IEEE, SEE Member                    2400 FF                      
_________ FF 
(Membership # __________) 

non member                               2600 FF                      
__________ FF 

Industry rate:                           4000 FF                      
__________ FF 

Additional Conference Proceedings (FF 400):                           
__________FF 

Additional Gala Dinner (FF 300):                                      
__________FF 
  

                                   Total French Francs ..............  
_________ 

Payment of Fees: 

__ By Foreign Check in French Francs to "Office du Tourisme de Colmar". 

__ By Bank Transfer to: Caisse d'Epargne d'Alsace, Avenue de la République,
68000 Colmar - France. Bank code: 16705 - Counter code: 09017 - Account
number: 04100568821 - Key: 23 - Account name: Office du Tourisme de Colmar
- Transfer Swift : BFCE FR PP 317 

__ By Credit Card: 
     __ Mastercard 
     __ Visa 
     __ American Express 

Card number: _________________________ 
Expiration date: _________ 

Signature: 
  





---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 10:53:23 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09789
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 10:53:22 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 2B1C352C1; Wed,  7 Apr 1999 10:48:01 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9ABC452C2; Wed,  7 Apr 1999 10:48:00 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <370B6F76.ACF59EF2@dnrc.bell-labs.com>
Date: Wed, 07 Apr 1999 10:45:10 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
Cc: Jerry Scharf <scharf@vayu.net>, iptel@lists.research.bell-labs.com
Subject: Re: is there a better list to ask H.323 questions of
References: <E32BD2062DAFD1119CFD0000F804F31702C049DE@cosexch003.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'm not on the list; I know of its existence but don't know how to join.
Perhaps someone who is on this list can send instructions?

Thanks,
Jonathan R.

> Hoefelmeyer, Ralph (MCI) wrote:
> 
> It might help to tell everyone how to join the h323 implementers list
> ...
> 
>      -----Original Message-----
>      From:   Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
>      Sent:   Tuesday, April 06, 1999 3:32 PM
>      To:     Jerry Scharf
>      Cc:     iptel@lists.research.bell-labs.com
>      Subject:        Re: is there a better list to ask H.323 questions
>      of
> 
>      This is not the right list. This list is for the iptel working
>      group in
>      IETF. Please use the h323 implementors list for h.323 questions.
> 
>      Thanks,
>      Jonathan R.
> 
>      Jerry Scharf wrote:
>      >
>      > I have seen several questions on H.323 go by here. I have one
>      on V2 and was
>      > wondering if there is a better place to ask it or if here is
>      the right
>      > place.
>      >
>      > thanks,
>      > jerry
>      >
>      > ---------
>      > This message came from the IETF IPTEL Working Group Mailing
>      List.
> 
>      --
>      Jonathan D. Rosenberg                       Lucent Technologies
>      Member of Technical Staff                   101 Crawfords Corner
>      Rd.
>      High Speed Networks Research                Holmdel, NJ 07733
>      FAX:   (732) 834-5379                       Rm. 4C-526
>      EMAIL: jdrosen@bell-labs.com
>      URL: http://www.cs.columbia.edu/~jdrosen
> 
>      ---------
>      This message came from the IETF IPTEL Working Group Mailing List.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 11:06:21 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10026
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 11:06:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id D3FB352BF; Wed,  7 Apr 1999 11:01:14 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3CCE852C5; Wed,  7 Apr 1999 11:01:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.1.32.19990407085343.00be58f0@pop3.mail.mci.com>
X-Sender: lgrimald@pop3.mail.mci.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 07 Apr 1999 08:53:43 -0600
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
From: Linda Grimaldi <Linda.Grimaldi@wcom.com>
Subject: Re: Minutes of Minneapolis meeting
Cc: list iptel <iptel@lists.research.bell-labs.com>
In-Reply-To: <370AEC61.DE67E7F5@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


Folks,

Regarding this excerpt from the meeting minutes, I don't see why supporting URL
matching precludes using H.323.  H.323v2 does support URLs as addresses in the alias
fields. As long as other location types and generic string matching are also supported,
it shouldn't be a problem.

Also, while the timezone problem may be sticky, the assumption about the
server and the user being in the same time zone makes the feature almost
unusable, in my opinion.  Seems to me that if the server knows the timezone
it is in and it knows the timezone the user is in (user would presumably have
to register updates as he moves around), it should be possible to calculate
the difference.  Time zone registrations include the state of daylight savings
time (eg, EST vs EDT) and the calculation can be table driven, matching
the time zone registered with the offset from GMT.  I think this would work- there
are probably better ways- but unless this issue is solved, there is precious little
utility in TOD matching.

Linda
 
At 01:25 AM 4/7/99 -0400, Jonathan Rosenberg wrote:
>Folks,
>
>>
>Jonathan then continued with the open issues. URL matching is
>currently done by string matching, which is nicely general but not
>very efficient, and it is hard to do certain things. Supporting URL
>specific decisions means that the script may no longer be H.323/SIP
>independent. 
>
>Time switches also presented problems. Timezones are especially
>difficult, since there is no registry of names for timezones. So, the
>CPL assumes that the user and server sit in the same timezones. A
>question was asked as to why not just represent timezones as an offset
>from GMT? The answer is daylight savings time makes this offset
>variable.
>

Linda Grimaldi

MCI WorldCom
2424 Garden of the Gods Road
Colorado Springs, CO  80919
Tel. 719-592-9588
Email: linda.grimaldi@mci.com

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 11:10:25 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10101
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 11:10:24 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id D772F52AA; Wed,  7 Apr 1999 10:35:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 42D2552C1; Wed,  7 Apr 1999 10:35:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <E32BD2062DAFD1119CFD0000F804F31702C049DE@cosexch003.mcit.com>
From: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        Jerry Scharf <scharf@vayu.net>
Cc: iptel@lists.research.bell-labs.com
Subject: RE: is there a better list to ask H.323 questions of
Date: Wed, 7 Apr 1999 15:34:50 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE8103.CB084778"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE8103.CB084778
Content-Type: text/plain

It might help to tell everyone how to join the h323 implementers list ...

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> Sent:	Tuesday, April 06, 1999 3:32 PM
> To:	Jerry Scharf
> Cc:	iptel@lists.research.bell-labs.com
> Subject:	Re: is there a better list to ask H.323 questions of
> 
> This is not the right list. This list is for the iptel working group in
> IETF. Please use the h323 implementors list for h.323 questions.
> 
> Thanks,
> Jonathan R.
> 
> Jerry Scharf wrote:
> > 
> > I have seen several questions on H.323 go by here. I have one on V2 and
> was
> > wondering if there is a better place to ask it or if here is the right
> > place.
> > 
> > thanks,
> > jerry
> > 
> > ---------
> > This message came from the IETF IPTEL Working Group Mailing List.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: jdrosen@bell-labs.com
> URL: http://www.cs.columbia.edu/~jdrosen
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE8103.CB084778
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: is there a better list to ask H.323 questions of</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">It might help to tell =
everyone how to join the</FONT> <FONT SIZE=3D2 FACE=3D"Courier =
New">h323 implementers list ...</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jonathan Rosenberg =
[SMTP:jdrosen@dnrc.bell-labs.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, April 06, 1999 3:32 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Jerry Scharf</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">iptel@lists.research.bell-labs.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: is there a better list to ask =
H.323 questions of</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This is not the right list. This =
list is for the iptel working group in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">IETF. Please use the h323 =
implementors list for h.323 questions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Jonathan R.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Jerry Scharf wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; I have seen several =
questions on H.323 go by here. I have one on V2 and was</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; wondering if there is a =
better place to ask it or if here is the right</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; place.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; jerry</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; ---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; This message came from the =
IETF IPTEL Working Group Mailing List.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Lucent Technologies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Member of Technical =
Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 Crawfords Corner =
Rd.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">High Speed Networks =
Research&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; Holmdel, NJ 07733</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">FAX:&nbsp;&nbsp; (732) =
834-5379&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Rm. 4C-526</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">EMAIL: =
jdrosen@bell-labs.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">URL:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A></FONT></U>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">This message came from the IETF =
IPTEL Working Group Mailing List.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE8103.CB084778--

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 11:11:04 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10147
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 11:11:03 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id C4F8152D7; Wed,  7 Apr 1999 11:09:24 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2102C52CF; Wed,  7 Apr 1999 11:09:21 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Wed, 7 Apr 1999 17:08:47 +0200 (MET DST)
From: Krijn Mossel <kmossel@lucent.com>
X-Sender: kmossel@hvss122.nl.lucent.com
Reply-To: Krijn Mossel <kmossel@lucent.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>,
        Jerry Scharf <scharf@vayu.net>, iptel@lists.research.bell-labs.com
Subject: Re: is there a better list to ask H.323 questions of
In-Reply-To: <370B6F76.ACF59EF2@dnrc.bell-labs.com>
Message-ID: <Pine.GSO.4.10.9904071705250.9651-100000@hvss122.nl.lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Anyone wanting to join the H.323 Implementors' mailing list should send 
an e-mail to h323implementors-request@imtc.org with "info" in the body.

Krijn Mossel

On Wed, 7 Apr 1999, Jonathan Rosenberg wrote:

> I'm not on the list; I know of its existence but don't know how to join.
> Perhaps someone who is on this list can send instructions?
> 
> Thanks,
> Jonathan R.
> 
> > Hoefelmeyer, Ralph (MCI) wrote:
> > 
> > It might help to tell everyone how to join the h323 implementers list


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 11:51:48 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11007
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 11:51:47 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3845852C5; Wed,  7 Apr 1999 11:45:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8E6A752C6; Wed,  7 Apr 1999 11:45:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <199904071544.LAA20181@mailhost.corpeast.BayNetworks.COM>
X-Sender: jluciani@bl-mail2.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 07 Apr 1999 11:44:55 -0400
To: list iptel <iptel@lists.research.bell-labs.com>
From: "JAMES V. LUCIANI" <jluciani@NortelNetworks.com>
Subject: Re: Minutes of Minneapolis meeting
In-Reply-To: <370AEC61.DE67E7F5@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Have not done a careful inspection but did notice a boo boo...

>The question was asked as to whether there were commercial and
>interoperable implementations of SCSP. The answer (from Jim) - yes,
>they are out there, and yes they are commercial.

I was not the one who said this, but I subsequently found out that it is
correct.  Not sure if I should mention companies and products without the
consent of those companies... However, if anyone has implementation info
that they want to share please do so.

FWIW, SCSP is used for LNNI, standards based NHRP NHS synch, ATM ARP sync
and a few others.

==JIm

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr  7 12:01:54 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11197
	for <iptel-archive@odin.ietf.org>; Wed, 7 Apr 1999 12:01:53 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 45C0F52C6; Wed,  7 Apr 1999 11:47:38 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5F69E52C7; Wed,  7 Apr 1999 11:47:37 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <003501be810d$e9f10f80$346999ce@orit.radvision.com>
Reply-To: "Orit Levin" <orit@radvision.com>
From: "Orit Levin" <orit@radvision.com>
To: "Jonathan Rosenberg" <jdrosen@dnrc.bell-labs.com>,
        "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
Cc: "Jerry Scharf" <scharf@vayu.net>, <iptel@lists.research.bell-labs.com>
Subject: Re: is there a better list to ask H.323 questions of
Date: Wed, 7 Apr 1999 11:47:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Below is the description for two mailing lists:
implementors and H.323 general list

----------------
"h323implementors@imtc.org"

You must send any posted email to the list with
h323implementors@imtc.org.

To send a message to the imtc-members list, send an email message to the

"h323implementors@imtc.org"
To subscribe to this list, just send an
email message to majordomo@imtc.org in the message body simply type:

"subscribe imtc-h.323 implementors  (email address)"

To unsubscribe yourself from the list, send an email message to
majordomo@imtc.org
in the message body simply type:

"unsubscribe imtc-h.323 implementors    (email address)"

To insure "spam" mail is kept to a minimum, only people subscribed to the
list will be able to post to it.

Beck Horacek will be maintaing all mail lists.  Please do not hesitate to
contact her should you have any further comments or questions, at

+1.925.277.1320.
Interprise Ventures/IMTC
-------------------------------------------------
To send  a message to  all the people  currently subscribed to  the list,
just  send mail  to ITU-SG16@MAILBAG.INTEL.COM.  This is  called "sending
mail to the list", because you send mail to a single address and LISTSERV
makes  copies  for all  the  people  who  have subscribed.  This  address
(ITU-SG16@MAILBAG.INTEL.COM) is also called  the "list address". You must
never try to send any command to that address, as it would be distributed
to all the people  who have subscribed. All commands must  be sent to the
"LISTSERV address",  LISTSERV@MAILBAG.INTEL.COM. It is very  important to
understand  the difference  between the  two, but  fortunately it  is not
complicated. The LISTSERV address is like  a FAX number that connects you
to  a machine,  whereas the  list  address is  like a  normal voice  line
connecting you to a person. If you make a mistake and dial the FAX number
when you wanted to talk to someone on the phone, you will quickly realize
that you  used the wrong  number and call again.  No harm will  have been
done. If on the other hand  you accidentally make your FAX call someone's
voice  line,  the  person  receiving the  call  will  be  inconvenienced,
especially if your FAX then re-dials  every 5 minutes. The fact that most
people will eventually connect the FAX machine to the voice line to allow
the FAX  to go through  and make  the calls stop  does not mean  that you
should continue to send FAXes to  the voice number. People would just get
mad at you.  It works pretty much  the same way with  mailing lists, with
the difference  that you are calling  hundreds or thousands of  people at
the same  time, and consequently  you can expect a  lot of people  to get
upset if you consistently send commands to the list address.

You  may leave  the list  at  any time  by sending  a "SIGNOFF  ITU-SG16"
command to LISTSERV@MAILBAG.INTEL.COM. You can also tell LISTSERV how you
want it to confirm  the receipt of messages you send to  the list. If you
do not trust the system, send a "SET ITU-SG16 REPRO" command and LISTSERV
will send you a  copy of your own messages, so that you  can see that the
message was distributed and did not get damaged on the way. After a while
you  may find  that this  is getting  annoying, especially  if your  mail
program does not  tell you that the  message is from you  when it informs
you that new mail has arrived from  ITU-SG16. If you send a "SET ITU-SG16
ACK  NOREPRO" command,  LISTSERV will  mail you  a short  acknowledgement
instead, which will  look different in your mailbox  directory. With most
mail programs you  will know immediately that this  is an acknowledgement
you can read later. Finally, you can turn off acknowledgements completely
with "SET ITU-SG16 NOACK NOREPRO".

Following  instructions from  the list  owner, your  subscription options
have been  set to "REPRO MIME"  rather than the usual  LISTSERV defaults.
For more information about subscription  options, send a "QUERY ITU-SG16"
command to LISTSERV@MAILBAG.INTEL.COM.

Contributions sent to this list are automatically archived. You can get a
list  of the  available  archive  files by  sending  an "INDEX  ITU-SG16"
command  to LISTSERV@MAILBAG.INTEL.COM.  You can  then order  these files
with  a "GET  ITU-SG16  LOGxxxx" command,  or  using LISTSERV's  database
search facilities. Send  an "INFO DATABASE" command  for more information
on the latter.

This  list is  available  in digest  form.  If you  wish  to receive  the
digested  version of  the  postings,  just issue  a  SET ITU-SG16  DIGEST
command.

More  information on  LISTSERV  commands  can be  found  in the  LISTSERV
reference  card, which  you can  retrieve  by sending  an "INFO  REFCARD"
command to LISTSERV@MAILBAG.INTEL.COM.
-------------------------------------------------

Orit Levin
RADVision Inc.,
575 Corporate Drive - Suite 420
Mahwah, NJ 07430
Tel:    201-529-4300 (230)
Fax:   201-529-3516
-----Original Message-----
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
To: Hoefelmeyer, Ralph (MCI) <Ralph.Hoefelmeyer@wcom.com>
Cc: Jerry Scharf <scharf@vayu.net>; iptel@lists.research.bell-labs.com
<iptel@lists.research.bell-labs.com>
Date: Wednesday, April 07, 1999 10:47 AM
Subject: Re: is there a better list to ask H.323 questions of


>I'm not on the list; I know of its existence but don't know how to join.
>Perhaps someone who is on this list can send instructions?
>
>Thanks,
>Jonathan R.
>
>> Hoefelmeyer, Ralph (MCI) wrote:
>>
>> It might help to tell everyone how to join the h323 implementers list
>> ...
>>
>>      -----Original Message-----
>>      From:   Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
>>      Sent:   Tuesday, April 06, 1999 3:32 PM
>>      To:     Jerry Scharf
>>      Cc:     iptel@lists.research.bell-labs.com
>>      Subject:        Re: is there a better list to ask H.323 questions
>>      of
>>
>>      This is not the right list. This list is for the iptel working
>>      group in
>>      IETF. Please use the h323 implementors list for h.323 questions.
>>
>>      Thanks,
>>      Jonathan R.
>>
>>      Jerry Scharf wrote:
>>      >
>>      > I have seen several questions on H.323 go by here. I have one
>>      on V2 and was
>>      > wondering if there is a better place to ask it or if here is
>>      the right
>>      > place.
>>      >
>>      > thanks,
>>      > jerry
>>      >
>>      > ---------
>>      > This message came from the IETF IPTEL Working Group Mailing
>>      List.
>>
>>      --
>>      Jonathan D. Rosenberg                       Lucent Technologies
>>      Member of Technical Staff                   101 Crawfords Corner
>>      Rd.
>>      High Speed Networks Research                Holmdel, NJ 07733
>>      FAX:   (732) 834-5379                       Rm. 4C-526
>>      EMAIL: jdrosen@bell-labs.com
>>      URL: http://www.cs.columbia.edu/~jdrosen
>>
>>      ---------
>>      This message came from the IETF IPTEL Working Group Mailing List.
>
>--
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX:   (732) 834-5379                       Rm. 4C-526
>EMAIL: jdrosen@bell-labs.com
>URL: http://www.cs.columbia.edu/~jdrosen
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr  8 12:03:55 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03991
	for <iptel-archive@odin.ietf.org>; Thu, 8 Apr 1999 12:03:55 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3E00052B7; Thu,  8 Apr 1999 11:07:50 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8B70C52C2; Thu,  8 Apr 1999 11:07:49 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.3.32.19990407104333.00863690@pop.ozemail.com.au>
X-Sender: dclowes@pop.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 07 Apr 1999 10:43:33 +1000
To: "Jerry Scharf" <scharf@vayu.net>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: Re: is there a better list to ask H.323 questions of
Cc: <iptel@lists.research.bell-labs.com>
In-Reply-To: <005d01be8074$3a7413c0$1ebd98cc@leda.vayu.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

If you want to join the H323 implementors mailing list,
you can send mail to <Majordomo@imtc.org> with the following
command in the body of your email message:

    subscribe h323implementors

or from another account:

    subscribe h323implementors <email-address>

At 14:27 1999-04-06 -0700, Jerry Scharf wrote:
>I have seen several questions on H.323 go by here. I have one on V2 and was
>wondering if there is a better place to ask it or if here is the right
>place.
>
>thanks,
>jerry
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>
>

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr  8 12:30:03 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04165
	for <iptel-archive@odin.ietf.org>; Thu, 8 Apr 1999 12:30:02 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id A2E7152C2; Thu,  8 Apr 1999 12:23:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E8E4652C3; Thu,  8 Apr 1999 12:23:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.32.19990408121635.00881600@bl-mail1.corpeast.baynetworks.com>
X-Sender: msquire@bl-mail1.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 08 Apr 1999 12:16:38 -0400
To: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
From: Matt Squire <msquire@nortelnetworks.com>
Subject: Re: Evaluation of Gateway Location proposals
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk



I'm already sorry for the length of this message, but I had to
respond...

So here are my comments on your comparison.  Not surprisingly, I have a
different view on several important aspects.  

>
>1. Introduction:
>GLP is based on SCSP which is a generic link-state based protocol for
>synchronizing the databases of a server group. GLP uses SCSP's message
>formats and defines new fields specific for call routing and gateway
>location. GLP uses SCSP's transport mechanism only for intra-domain
>synchronization of LSs. For inter-domain communication, GLP proposes a
>model that's based on BGP. At runtime, GLP defines a server group (the
>set of LSs) which uses SCSP for synchronization and update
>advertisement, i.e., GLP is a user of SCSP.
>
>TBGP is based on the BGP-4 and its multi-protocol extensions. It uses
>BGP's transport mechanism for both inter-domain and intra-domain. TBGP
>uses the same message formats defined by BGP, and benefits from the
>attributes already defined 
>in BGP. In addition, TBGP defines new attributes to serve the specific
>goals of call routing and gateway location. With regards to
>implementation, BGP and TBGP are completely independent protocols. The
>two protocols do not interfere with each other at runtime. A TBGP
>speaker (or LS) does not have to be a BGP speaker.

I've tried to make this clear before, but have evidently not succceeded
in full.  GLP is based on the combination of BGP4 and SCSP, not just
SCSP.  SCSP is just used to move the data between servers and replaces
the BGP transport mechansism.  Behavior above the
synchronization/transport is based on BGP4 as catered to the needs of IP
telephony.  

Both proposals have the same basic BGP architecture for an LS:

   |-----------------------------------------|
   |            Local routes                 |
   |                 /\                      |
   |                  |                      |
   |               Decision                  |
   |                Process                  |
   |               /\     |                  |
   |                |     \/                 |
   |         in-routes  out-routes           |
   |-----------------------------------------|

Both proposals have a decision process based on local policies.  Both
proposals have routing objects which carry phone numbers, next-hops, and
all kinds of other attributes.  Any attribute supported in one proposal
can be made to work in the other proposal.  

Lets look at some of the basic aspects of BGP4 (I'm just paging through
the BGP spec now, so this list is not intended to be complete).  
  1) Attributes
  2) Transport/communications (ie open, keep-alive, update, notification)
  3) FSMs
  4) Update processing (decision process, update-send, route selection)

I'll briefly discuss each aspect below before getting into more specific
comments on your comparison later.  


1) Attributes

I fully recognize that the attribute set as listed in the GLP draft is
incomplete.  I've concentrated the initial draft on the potential new 
attributes for iptel that do not exist in BGP.  Other BGP attributes
will be forthcoming, 

The TBGP draft has taken the approach that everything in BGP is fair
game for iptel, and has assumed that other BGP attributes will work for
us just fine.  Although I agree that other BGP attributes are fair game,
I've taken the approach that we need to inspect every BGP attribute in
terms of the problem we are trying to solve, and have not assumed that
they will work as defined in BGP4.  BGP4 attributes that exist have been
defined for a reason, so we need to understand that reason, see how it
applies to call-routing, and adjust the attribute appropriately.

The 7 attributes defined in the BGP4 RFC are ORIGIN, NEXT_HOP, AS_PATH,
MED, LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR.  Just running through
some thoughts off the top of my head:

 A) NEXT_HOP.  We've already had discussions how the concept of a BGP4
 next-hop differs from an iptel next-hop.  GLP is not a hop-by-hop
 routing protocol like BGP4, and this has impacts on many aspects of the
 protocol.

 B) AS_PATH.  I've already agreed that we need something like the
 AS_PATH.  But we've also had discussions on the list about whether we
 want to talk about the path that the advertisement took, the path that
 call-routing messages will take, or both.  In BGP4, this attribute
 serves both purposes.  Do we need one or both kinds of paths?  How does
 this affect other aspects of the protocol (route preferences and
 selection, loop prevention, attribute propagation, etc.)?  Our
 definition of what paths we need has an effect on other aspects of the
 protocol.

 C) MED.  The multi-exit discard attribute is used in BGP4 to differentiate
 multiple links between neighboring ASs so that one link is 'preferred'
 over the other.  But we don't route hop-by-hop, and that brings up some
 issues.  How is MED used when an routing advertisement contains a
 next-hop that is not in the advertising domain?  In other words, is MED
 a property of the advertisement path, or of the potential signalling
 path, or what exactly?  In any case, I think its definition as in BGP4
 would need some reworking.

 D) ATOMIC_AGGREGATE.  Atomic aggregate is used to indicate that a
 "less-specific NLRI" has been chosen without selecting a 'more specific
 NLRI".  GLP needs to have multi-attributed routing decisions, hence the
 concept of more/less specific is not dependent only on the addresses/NLRI.
 Also, we have yet to agree that what we want is address prefixes - if
 we choose something else, then things get even more confusing.  In
 general, the NLRI-centric nature of BGP is too restrictive for our
 needs.

So I have issues with 4 of the 7 well-defined attributes of BGP4 as they
are defined and used within BGP4.  The application of these attributes
to GLP is not the same as it is in BGP4.  We don't route hop-by-hop, we
use mutli-valued routing decisions, etc.  These differences affect many
aspects of the protocol, including attribute definitions and processing.
Every attribute needs to be re-examined in our context before we ok its
use.

I think we've taken different approaches to including other BGP
attributes in our proposals.  I wanted to understand the reasons behind
every attribute, see how it applies to iptel, and then come up with an
attribute that works for us.  I think you've taken the approach that all
attributes are ok and we can fix how they work later.  In either case, I
hope we agree that the BGP4 definitions of some of its attributes are
not sufficient for iptel.  We need something like them, but not exactly
the same thing.

Independent of the manner in which we choose to implement GLP, we need
something like BGP, but not really BGP.  We have to write an entirely
new specification, we can't just reference BGP and say that we're
redefining these attributes, this process, these algorithms, etc.  In
either implementation scenario, to say that GLP has something because
BGP has it is a flawed approach until we've performed analysis of the
feature and how it is effected by things like the fact that GLP isn't a
hop-by-hop routing algorithm, that the GLP routing decision is based on
things other than the NLRI, etc.  

In general, attribute decisions are independent of the differences
between the proposals.  I knew my proposal was lacking in attributes
when I wrote it.  I also think the TBGP proposal needs to redefine BGP4
attributes for our purposes and not to just reference their use in BGP4.
We need a new protocol, not a reference to BGP4.  

I also believe that any attribute can work with either approach.


2) Transport/communications.

Will address later.


3) FSMs.  These basicly describe how one gets to the 'established'
state, so these are really dependent on the transport/communications.


4) Update processing (decision process, update-send)

  4a) Decision process.  The BGP4 decision process is NLRI-centric.
  This must be changed to support multi-attributed routing decisions.
  We certainly want to maintain the structure of the decision process of
  BGP4, but it CAN NOT be the same decision process.  BGP4s decision
  process must be made more general to support our requirements.  The
  whole concept of what aggregation is and how it is performed is
  completely differnet for GLP than it is for BGP4.  We have strings not
  bits, we have routes with attributes, we have black holes, we haven't
  agreed on prefixes as our destination representation, etc.  Our
  decision process is not the same as the BGP4 decision process.

  4b) Update-send. Again, we should keep the structure but we have to
  get rid of the NLRI-centric aspects.  Things like jitter, advertisement
  frequency, etc., can be handled independently of the transport (UPDATE
  vs SCSP).  Although this is not in the first draft of GLP, it would
  need to go in there.  
  

>
>2. Reliability:
>GLP runs on a reliable transport, e.g. TCP. In addition, GLP/SCSP uses
>request/response transactions.  Responses are not simple Acks. They are
>long messages. This significant overhead is needed with intra-domain
>link-state protocols to achieve transitive closure and to make sure that
>all LSs in a domain have synced up following a routing change. However,
>it is still a significant overhead that may be avoided. The
>request/response mechanism does not add any benefit for inter-domain
>GLP.  
>
>TBGP, on the other hand, relies on TCP for reliability. It uses Update
>messages only with no responses. This is sufficient.
>

Onto a discussion of transport.  To me, this is the major functional
difference between the proposals.  

To begin, I strongly disagree with your last statement.  TCP provides
transport reliability, it does NOT provide for reliable communications
between applications.  Look at the numerous protocols that the IETF has
defined over TCP.  The majority of them have recognized the difference
between application reliability and transport reliability, and include
things like acks, timeouts, retries, etc.  

Generally, BGP4 implementations don't use off-the-rack TCP/IP stacks.
In order to achieve application reliability using just TCP, you really
have to integrate your application with the TCP stack.  BGP4 TCP/IP stacks
are finely tuned for BGP, the OS is catered toward routing and routing
protocols, etc.  They don't use a standard socket type interface over
TCP-IP because they would lose their reliability.  

TCP is not sufficient for application reliability unless you application
is integrated with TCP.  Whatever we do, I hope we recognize this fact
and avoid the pitfall of forcing GLP developers to hack the TCP stack
because we don't build application reliability.  

On the other hand, SCSP is sufficient.  SCSP was designed to get
information from A to B (and to C, D, ...).  When used between just two
servers, as you point out later, it has more than is needed.  We could
certainly build another reliable transport protocol by adding retries,
timeouts, acks, etc., into the BGP4 transport.  If restricted to
point-to-point relationships, then it would have less overhead than
SCSP.  

I just question why we would want to do this.  The IETF has already
defined SCSP as a general method of moving data between servers.  Why
not just use a defined protocol instead of defining JARAP (just another
reliable application protocol).  The overhead of SCSP's generality is not
wasted if we use that generality within a domain.  Using SCSP frees us
from worrying about transport and allows us to concentrate on what data
we need and how we should process it.  These are really the novel iptel
specific aspects.  Moving data around has been done many times by many
protocols in many ways.  We don't have to build another one.

The use of SCSP would replace the open, update, and keep-alive in BGP4.
This decision is independent of the changes required of BGP4 above
transport, which I discussed earlier.  However, deciding how version
negotiation and error notification work when using SCSP is yet TBD.  These
functions are provided in the BGP4 transport which would need some work
in my suggested approach.


>3. Inter-Domain Topologies:
>Both protocols can support any general topology.
>
>4. Intra-Domain Topologies:
>GLP can support any general topology.
>
>TBGP requires either a full mesh configuration or the use of route
>reflectors or confederations. It is possible to configure each TBGP
>speaker in a domain as a route reflector, and thereby to support any
>general topology.  
>
>Questions: 
>- What's so bad about route reflectors and confederations? 
>- What's the need for supporting a general topology? All that's required
>is synchronizing the LSs of the same domain. It doesn't matter how they
>interconnected, as long as there sufficient redundancy in the topology.
>

Some people evidently think route reflecting has some downsides.  See 
draft-dube-route-reflection-harmful-00.txt "Route Reflection Considered
Harmful".  

In general, I think unnecessary restrictions are, in a word,
unnecessary.  They limit deployment scenarios.  BGP4s topological
restrictions are a reflection of its choice of transport, not of the
routing processes above them.  

We are designing a new protocol.  We need to leverage the experience of
BGP, both good and bad.  That means we don't have to make the same
mistakes.  In hindsight, the original BGP restriction on meshes was bad
thing.  There have been numerous proposals over the years to fix it
(route reflectors, route servers, confederations, clusters, etc).
However, all of these proposals have had to live within the confines of
interoperability with existing BGP.  We don't have to be interoperable
with existing BGP implementations.  We have the freedom to fix this
problem in a more general way without interoperability concerns.  

GLP needs to get information from every server to every other server
within the domain.  That is the problem we have to solve.  If we
recognize that this is the issue, and that we don't have to limit
ourselves to solutions that are compatible with BGP1 through BGP4, then
we can do better than what was done in BGP.  Let's step out of the box
and look at the problem without the BGP interop constraints.  


>5. Loop Avoidance:
>5.1 Intra-domain Loop Detection: 
>5.2 Inter domain Loop Detection:
>6. Hold-down Timers and Route Flaps:
>7. Policy Enforcement:
>8. Coping with Aggregation Side Effects:
> 

These are all attribute issues that can be addressed by either approach.
TBGP does need to define new formats, in my approach we would.  With
either approach, we also need to re-examine the exact definition of the
attributes and modify them as appropriate.


>9. Addressing Formats:
>GLP proposes to advertise E.164 ranges. During the meeting, it has been
>agreed that E.164 prefixes are more space-efficient.
>
>The multi-protocol extensions for BGP-4 (RFC 2283) have already defined
>fields for advertising E.164 prefixes in BGP messages. These extensions
>are used by TBGP.

Although we agreed that prefixes are more space efficient, I don't think
we agreed that prefixes are the way to go.  I think it was Scott that
brought up the point of a company having the same number in many area
codes.  Although I have nothing against a decision for prefixes, I just
don't think it was agreed upon.  

>
>10. Leveraging Existing Attributes:  
>Most of BGP-4's fields and attributes can be used by TBGP, as evident
>from the above discussion. Still there are some attributes which are of
>no use to TBGP. for example the layer 3 NEXT_HOP attribute.
>
>GLP, on the other hand, will have to redefine several of BGP's existing
>attributes within the SCSP's message formats. Consider for example, the
>policy attributes and aggregation attributes discussed above. Also SCSP
>defines several mandatory fields which are redundant or of no use for
>GLP. E.g., the Sender ID and Recvr ID are not needed in every Update
>messages. The peers already recognize each other. Also the Cache Key
>field is not needed since the tables will be indexed by the E.164
>prefixes.

As I mention above, there are subtle points with several attributes
that arise because call routing differs from ip routing.  Yes, TBGP can
use the same attribute format.  I don't consider this particular
important.  We still need to look at every attribute and redefine it as
necessary.  Formats are the least of our obstacles.

SCSP fields are necessary for general database sync.  In a peer-to-peer
inter-domain link, you mention some that are redundant.  In the
intra-domain case where there are multiple servers, these fields are
required.  

The cache key is a very useful and compact identifier for a data object.
One can issue updates or withdraws on the data object without having to
understand the data.  This means that one can withdraw a route by
performing a lookup on the cache key instead of an e164 address.  This
allows for a more efficient lookup for changing an existing data object.
Yes, its redundant, but for a reason.

>
>TBGP can define its own message formats and remove any useless fields
>from the current BGP messages, because BGP and TBGP are separate
>protocols. On the other hand, GLP can not remove useless fields from
>SCSP messages, because it is just a another user of SCSP.

The other view is that TBGP MUST define its own message formats and
remove useless fields from BGP messages.  With SCSP we only define the
data, not the protocol. To me, that means more work with the TBGP approach.

I certainly agree that we could a protocol with less overhead than SCSP.
See my previous arguments on why the BGP transport is insufficient for
applications.

>
>11. Protocol Phases:  
>GLP/SCSP has three phases: Hello, Cache Alignment, and Update. 
>
>TBGP/BGP consists of two phases only: Hello and Update. It uses the same
>mechanisms of the update phase for aligning the call routing tables when
>a new connection between wo peers is established.
>
>12. Security Consideration:  
>Both protocols define optional fields to include authentication data.
>Both of them  permit the use of different authentication mechanisms, and
>both provide sufficient space to include the 128-bit MD5 digests. 
>
>However, TBGP messages can't carry authentication data larger than 128
>bits, while SCSP messages can.
>
>13. Routing Experience:
>This is not a feature of the protocol, but I think it is worth repeating
>that SCSP was not designed for, and was never used for, inter-domain
>routing.
>
>On the other hand, BGP has been specifically designed for inter-domain
>routing. It (a) is known to work, (b) is widely deployed in the
>Internet, (c) has an extensive operational experience, and (d) known to
>scale.

First, SCSP is not being proposed as an inter-domain routing protocol.
It is being proposed as a method of moving data between servers.  The
data that it is being proposed to move is data that will be used for
routing.   So although you're right in that SCSP isn't a routing
protocol of any sorts, I'm not proposing that it be made one.  I want to
separate the routing process from the process of moving the data around,
so that this wg can build the routing process and algorithms.  SCSP
frees us from worrying about moving the data around.  To me, this is a
good thing.  

Second, you're absolutely right about BGP.  But TBGP is not BGP.  Its a
new protocol.  It has different attributes, different aggregation
algorithms, different route selection, different routing decisions, etc.
I consider it flawed logic to assume that a property of BGP translates
into the same property in TBGP.  We have no operational experience with
TBGP, for example.

Yes BGP works.  But that's because of the experience developed over the
years in its aggregation algorithms, routing decisions, experience with
internet routing deployment and address distribution, etc.  The IETF
does not have years of experience with deployed call routing protocols.
We don't have experience with the aggregation algorithms for the
aggregation of strings and multi-valued routing objects.  We don't have
that experience with multi-valued routing decisions and processes.  We
can't rely on our handing out addresses in certain ways to help with
aggregation.  Etc, etc, etc.  

This is a new problem.  We need to leverage our experience with BGP, but
not be restricted by it, or to just assume that what is good for ip
routing is good for call routing.  



In my opinion, there are really two major differences between the
proposals.  The first is ideological.  I took the approach that we have
to re-examine every attribute in BGP before accepting it, you took the
approach where we accept it and re-examine it later.  I think we both
agree that this is a new protocol that requires a new spec, and that
cannot just reference BGP4 to describe its behavior.  We each want to
leverage BGPs attributes.  TBGP has an easier job cause it leverages the
formats as well as the function, where with my proposal we have to
redefine formats.

The second aspect is the transport issue.  I am in strong disagreement
with the assumption that TCP provides application reliability.   Hence,
as an application protocol, BGP4's reliability measures are not
sufficient.  I proposed SCSP to give us this reliabilty and to free us
from worring about transport issues such as retries, timeouts, etc.
SCSP also has beneficial side effects as an intra-domain distribution
system.  If the wg feels that we'd rather design our own reliable
application protocol, then I could live with that.  I think we'd be
wasting effort that could be better applied to other iptel problems, but
these things happen.  

Counting on TCP for application reliability is just a bad idea.

- Matt



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr  8 21:05:46 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09058
	for <iptel-archive@odin.ietf.org>; Thu, 8 Apr 1999 21:05:46 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id DB46452C3; Thu,  8 Apr 1999 19:19:32 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 22F7352BB; Thu,  8 Apr 1999 19:19:28 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <1B08859602C8D211B66F0000C0769CFA0A487E@njc240po03.ho.att.com>
From: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>
To: "'diff-serv@baynetworks.com'" <diff-serv@baynetworks.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "'pint@lists.research.bell-labs.com'" <pint@lists.research.bell-labs.com>
Cc: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>
Subject: Invitation
Date: Thu, 8 Apr 1999 19:14:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hello,

My name is Jerry Ash and I'm the Rapporteur of ITU-T Study Group 2, Question
2 on routing.  At the 12/98 IETF meeting in Orlando, I presented some
on-going ITU-T work entitled "E.MM -- Routing of Multimedia Connections when
Interworking with TDM-, ATM-, and IP-Based Networks"
(<draft-ash-itu-qos-routing-00.txt>).  As highlighted in our discussions,
routing models in TDM-, ATM- and IP-based networks have evolved differently.
However, as TDM-based PSTNs interwork more with IP and ATM networks, and
perhaps evolve to incorporate IP/ATM technology themselves, we are
interested in exploring the evolution of routing standards in such cases.
As outlined in the liaison, we welcome the participation of the IETF in
these on-going routing topics and recommendations.

As a follow-up to that invitation, the E.MM Draft Recommendation (see
abstract below) and other routing topics will next be discussed at the May
4-14, 1999 ITU-T Study Group 2 meeting in Geneva.  Question 2 on Routing
meets on 5/6, 5/7, and 5/10, and we invite contributions to and
participation in these meetings and recommendations.  In that regard, I
would be happy to supply more detailed information on meeting logistics
and/or a Word-version copy of the currently proposed E.MM Draft
Recommendation.

Thanks very much,
Regards,
Jerry Ash
------------------------------------------------------------
Gerald R. (Jerry) Ash
Rapporteur, ITU-T Study Group 2, Question 2 (Routing)
AT&T 
Manager, Routing Evolution
Network Architecture & Development
Room MT E3-3C37
200 Laurel Avenue
Middletown, NJ 07748
USA
Telephone  732-420-4578
Fax            732-368-6687
Email          gash@att.com
------------------------------------------------------------

TITLE: E.MM - Routing of Multimedia Connections when Interworking with TDM-,
ATM-,  and IP-Based Networks


ABSTRACT

There are many network operators who have implemented multiple networks
using different protocols, which include Public Switched Telephone Networks
(PSTNs) which use Time Division Multiplexing (TDM) technology, Asynchronous
Transfer Mode (ATM) technology, and/or Internet Protocol (IP) technology.
The very rapid growth of data services driven primarily by multimedia
internet services has led in turn to the rapid growth of ATM and IP
technology being implemented and/or planned for PSTNs.  Also there is
interest in carrying traditional PSTN voice services over ATM- and IP-based
networks, leading to the convergence in many instances of voice and data
services onto a common network.  However there is also a growing need to
address the interworking of voice and data services over TDM-, ATM,- and
IP-based PSTN networks, as all these network types will continue to exist
and grow.  This Recommendation addresses the routing aspects of interworking
between these networks, and includes considerations of a) numbering, b) path
selection, c) quality-of-service (QoS) resource management, and d) signaling
and information exchange messaging.

The most effective routing functionalities employed within each network type
are recommended for application across network types, to enable and ease
interworking and include the following: a) the E.164/NSAP based
numbering/addressing method applied successfully in TDM- and ATM-based
networks, b) the automatic generation of routing tables based on network
topology and status applied successfully in TDM-, ATM-, and IP-based
networks, c) the dynamic path selection methods applied successfully in
TDM-based networks, d) the routing table design information exchange
messaging applied successfully in TDM-based networks, e) the QoS resource
management methods applied successfully in TDM-based networks, f) the
automatic update and synchronization of topology database methods applied
successfully in ATM- and IP-based networks, g) the topology update
information exchange messaging methods applied successfully in ATM- and
IP-based networks, and h) the connection/bandwidth-allocation control
signaling methods applied successfully in ATM-based networks.  The latter
includes originating switch controlled (source) routing, specification of
via and destination switches in a designated-transit-list/explicit-route
parameter in the setup message, and return of control to the originating
switch with a crankback/bandwidth-not-available parameter in the release
message.  Adapting these capabilities, or their equivalents, for use within
each network type and for interworking between network types builds on these
well studied, documented, deployed, and proven methods.  It also increases
the likelihood of backward compatibility to existing capabilities as new
interworking standards are adopted and implemented.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr  9 08:06:52 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01734
	for <iptel-archive@odin.ietf.org>; Fri, 9 Apr 1999 08:06:52 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 1E73E52B7; Thu,  8 Apr 1999 22:55:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8B9AD52C1; Thu,  8 Apr 1999 22:55:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <199904090250.TAA04986@mailman.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Thu, 08 Apr 1999 22:44:34 -0400
To: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: Invitation
In-Reply-To: <1B08859602C8D211B66F0000C0769CFA0A487E@njc240po03.ho.att.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Thanks for the invitation.  I have a couple of questions below:

At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote:
>Hello,
...snip...
>The most effective routing functionalities employed within each network type
>are recommended for application across network types, to enable and ease
>interworking and include the following: a) the E.164/NSAP based
>numbering/addressing method applied successfully in TDM- and ATM-based
>networks, b) the automatic generation of routing tables based on network
>topology and status applied successfully in TDM-, ATM-, and IP-based
>networks, c) the dynamic path selection methods applied successfully in
>TDM-based networks, d) the routing table design information exchange
>messaging applied successfully in TDM-based networks, e) the QoS resource
>management methods applied successfully in TDM-based networks, f) the
>automatic update and synchronization of topology database methods applied
>successfully in ATM- and IP-based networks, g) the topology update
>information exchange messaging methods applied successfully in ATM- and
>IP-based networks, and h) the connection/bandwidth-allocation control
>signaling methods applied successfully in ATM-based networks.  The latter
>includes originating switch controlled (source) routing, specification of
>via and destination switches in a designated-transit-list/explicit-route
>parameter in the setup message, and return of control to the originating
>switch with a crankback/bandwidth-not-available parameter in the release
>message.  Adapting these capabilities, or their equivalents, for use within
>each network type and for interworking between network types builds on these
>well studied, documented, deployed, and proven methods.  It also increases
>the likelihood of backward compatibility to existing capabilities as new
>interworking standards are adopted and implemented.
...snip...

For b), c) and d), could you point me to the standards that describe the
protocols and algorithms used for these capabilities in the TDM network?
For example, what protocol is used for routing table design information
exchange messaging between switches?  This way we can read up on them
before the meeting.


Thanks,
Chip
--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085 
Cisco Systems              Consulting Eng. - Telco   
Reality - Love it or Leave it.			
--------------------------------------------------

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr  9 09:06:24 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02232
	for <iptel-archive@odin.ietf.org>; Fri, 9 Apr 1999 09:06:23 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id F252652BB; Fri,  9 Apr 1999 09:01:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5AF2752BF; Fri,  9 Apr 1999 09:01:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <1B08859602C8D211B66F0000C0769CFA0A4886@njc240po03.ho.att.com>
From: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>
To: "'Chip Sharp'" <chsharp@cisco.com>
Cc: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
Subject: RE: Invitation
Date: Fri, 9 Apr 1999 08:58:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Chip,
As discussed in the E.MM draft, ITU-T Recommendations E.170, E.177, and
E.DYN (draft) address items b), c), and d).  E.MM seeks standardization of
effective routing functionalities for interworking, including information
exchange, that derive from standards/practice across TDM/ATM/IP network
types.  The draft contains more information and references.
Thanks,
Jerry Ash

> -----Original Message-----
> From:	Chip Sharp [SMTP:chsharp@cisco.com]
> Sent:	Thursday, April 08, 1999 10:45 PM
> To:	Ash, Gerald R (Jerry), NNAD; 'iptel@lists.research.bell-labs.com'
> Subject:	Re: Invitation
> 
> Thanks for the invitation.  I have a couple of questions below:
> 
> At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote:
> >Hello,
> ...snip...
> >The most effective routing functionalities employed within each network
> type
> >are recommended for application across network types, to enable and ease
> >interworking and include the following: a) the E.164/NSAP based
> >numbering/addressing method applied successfully in TDM- and ATM-based
> >networks, b) the automatic generation of routing tables based on network
> >topology and status applied successfully in TDM-, ATM-, and IP-based
> >networks, c) the dynamic path selection methods applied successfully in
> >TDM-based networks, d) the routing table design information exchange
> >messaging applied successfully in TDM-based networks, e) the QoS resource
> >management methods applied successfully in TDM-based networks, f) the
> >automatic update and synchronization of topology database methods applied
> >successfully in ATM- and IP-based networks, g) the topology update
> >information exchange messaging methods applied successfully in ATM- and
> >IP-based networks, and h) the connection/bandwidth-allocation control
> >signaling methods applied successfully in ATM-based networks.  The latter
> >includes originating switch controlled (source) routing, specification of
> >via and destination switches in a designated-transit-list/explicit-route
> >parameter in the setup message, and return of control to the originating
> >switch with a crankback/bandwidth-not-available parameter in the release
> >message.  Adapting these capabilities, or their equivalents, for use
> within
> >each network type and for interworking between network types builds on
> these
> >well studied, documented, deployed, and proven methods.  It also
> increases
> >the likelihood of backward compatibility to existing capabilities as new
> >interworking standards are adopted and implemented.
> ...snip...
> 
> For b), c) and d), could you point me to the standards that describe the
> protocols and algorithms used for these capabilities in the TDM network?
> For example, what protocol is used for routing table design information
> exchange messaging between switches?  This way we can read up on them
> before the meeting.
> 
> 
> Thanks,
> Chip
> --------------------------------------------------
> Chip Sharp                 voice: +1 (919) 851-2085 
> Cisco Systems              Consulting Eng. - Telco   
> Reality - Love it or Leave it.			
> --------------------------------------------------
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr  9 10:58:22 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03229
	for <iptel-archive@odin.ietf.org>; Fri, 9 Apr 1999 10:58:21 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 280F152B7; Fri,  9 Apr 1999 10:53:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 7FA0F52C1; Fri,  9 Apr 1999 10:53:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: Rahul_Chopra@3com.com
X-Lotus-FromDomain: 3COM
To: Chip Sharp <chsharp@cisco.com>
Cc: "Ash, Gerald R (Jerry), NNAD" <gash@att.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
Message-ID: <8825674E.0051A6CB.00@hqoutbound.ops.3com.com>
Date: Fri, 9 Apr 1999 09:47:54 -0500
Subject: Re: Invitation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk



Ash, Chip:
I would appreciate a pointer to what CS pointed too.
Thanks.
Rahul Chopra




Chip Sharp <chsharp@cisco.com> on 04/08/99 09:44:34 PM

To:   "Ash, Gerald R , "'iptel @lists.research.bell-labs.com'"
      <iptel@lists.research.bell-labs.com>
cc:    (Rahul Chopra/MW/US/3Com)
Subject:  Re: Invitation




Thanks for the invitation.  I have a couple of questions below:

At 07:14 PM 4/8/99 -0400, Ash, Gerald R (Jerry), NNAD wrote:
>Hello,
...snip...
>The most effective routing functionalities employed within each network type
>are recommended for application across network types, to enable and ease
>interworking and include the following: a) the E.164/NSAP based
>numbering/addressing method applied successfully in TDM- and ATM-based
>networks, b) the automatic generation of routing tables based on network
>topology and status applied successfully in TDM-, ATM-, and IP-based
>networks, c) the dynamic path selection methods applied successfully in
>TDM-based networks, d) the routing table design information exchange
>messaging applied successfully in TDM-based networks, e) the QoS resource
>management methods applied successfully in TDM-based networks, f) the
>automatic update and synchronization of topology database methods applied
>successfully in ATM- and IP-based networks, g) the topology update
>information exchange messaging methods applied successfully in ATM- and
>IP-based networks, and h) the connection/bandwidth-allocation control
>signaling methods applied successfully in ATM-based networks.  The latter
>includes originating switch controlled (source) routing, specification of
>via and destination switches in a designated-transit-list/explicit-route
>parameter in the setup message, and return of control to the originating
>switch with a crankback/bandwidth-not-available parameter in the release
>message.  Adapting these capabilities, or their equivalents, for use within
>each network type and for interworking between network types builds on these
>well studied, documented, deployed, and proven methods.  It also increases
>the likelihood of backward compatibility to existing capabilities as new
>interworking standards are adopted and implemented.
...snip...

For b), c) and d), could you point me to the standards that describe the
protocols and algorithms used for these capabilities in the TDM network?
For example, what protocol is used for routing table design information
exchange messaging between switches?  This way we can read up on them
before the meeting.


Thanks,
Chip
--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085
Cisco Systems              Consulting Eng. - Telco
Reality - Love it or Leave it.
--------------------------------------------------

---------
This message came from the IETF IPTEL Working Group Mailing List.






---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Sat Apr 10 12:56:03 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21944
	for <iptel-archive@odin.ietf.org>; Sat, 10 Apr 1999 12:56:03 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id DF6EE52BB; Sat, 10 Apr 1999 11:57:25 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 481EB52C1; Sat, 10 Apr 1999 11:57:24 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
X-Internal-ID: 370E72C200003FDD
Message-ID: <370E72C200003FDD@mailnew.fibertel.com.ar> (added by mailnew.fibertel.com.ar)
Date: Sat, 10 Apr 1999 12:56:47 -0300
From: Finanzas <finanzas.mail@poboxes.com>
Subject: Seminarios Aplicativos de CÂlculo Financiero.
Reply-To: finanzas.mail@poboxes.com
To: iptel@lists.research.bell-labs.com
X-Mailer: dbMail v1.3b1 by Mach5 Software. Please report spamming to dbspam@mach5.com.
Content-Transfer-Encoding: Quoted-Printable
MIME-Version: 1.0
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: Quoted-Printable

AT.:
iptel@lists.research.bell-labs.com

TO:=20
GERENCIA DE ADMINISTRACION Y FINANZAS
GERENCIA GENERAL
GERENCIA COMERCIAL
GERENCIA DE COMPRAS

ATENCION: Seminarios Aplicativos de C=E1lculo Financiero.

OBJETO: El seminario apunta a resolver pr=E1cticamente los problemas de
c=E1lculo financiero que se le presentan a una empresa mediante el uso de=
 la m=E1s
poderosa herramienta de software de c=E1lculo financiero del mercado arge=
ntino.
(Incluye en la matricula la provisi=F3n de la herramienta mencionada).

DICTADOS POR: Profesionales en Ciencias Econ=F3micas con Expertise en la
materia.

LUGAR DE REALIZACION: Capital Federal. Interior ver Capacitaci=F3n a
Distancia.

MATERIAL DIDACTICO QUE SE ENTREGA: 25 ejercicios con su soluci=F3n, 1
Software estructurado con su correspondiente manual de uso (100 p=E1g.) y=
 el
Certificado del Seminario.

DURACION: 4 hs., con servicio de cafeter=EDa.

MATRICULA: $ 100,-- + IVA (Incluye el software).

FECHAS Y HORARIOS DISPONIBLES:

Ma=F1ana:
13-04
15-04
16-04
20-04
22-04
23-04
27-04
29-04
30-04

Tarde:
15-04
16-04
22-04
23-04
29-04
30-04

Los horarios son:  9 a 13 hs. o 15 a 19 hs.

TOPICOS DEL SEMINARIO APLICATIVO:

- C=E1lculos Generales.
- Unificaci=F3n de vencimientos.
- Diversificaci=F3n de vencimientos.
- Equivalencias de Tasas de Inter=E9s.
- Aritm=E9tica de Fechas.
- Rentas e Imposiciones.
- Sistemas de Amortizaci=F3n.
- Planes Financieros.
- Carteras de Acciones.
- T=EDtulos P=FAblicos.
- D=EDas Promedio de Pago.
- Descuento de cheques y facturas.

CUPOS LIMITADOS: M=E1ximo 4 asistentes por seminario, confirme ya su
asistencia por e-mail a:
finanzas.mail@poboxes.com

A los interesados rogamos enviar los datos siguientes y nos pondremos en
contacto.

NOMBRE Y APELLIDO:
EMPRESA:
CARGO:
TELEFONO:

----------------------------------------------------

CAPACITACION A DISTANCIA:

Si Ud. no tiene tiempo para asistir al seminario o es del interior y no
puede viajar a Capital, puede solicitar nuestro "Pack de Capacitaci=F3n a
Distancia", que le permitir=E1, en poco tiempo, una eficaz utilizaci=F3n =
de nuestro
software de c=E1lculo financiero.

PACK DE AUTOAPRENDIZAJE:

COSTO: $ 100,-- + $ 15,-- (gastos de env=EDo contrareembolso) + IVA.

CONTIENE:=20

- Software de C=E1lculo Financiero (1 disquete 3,5" con el software para
instalar en cualquier PC).
- Manual de uso con m=FAltiples ejercicios.
- 25 ejercicios resueltos del seminario (planteos y soluciones).
- Gu=EDa oral de instalaci=F3n y de utilizaci=F3n de cada una de las
herramientas.
- Certificado del seminario.

A los interesados en adquirir el pack, rogamos indicar:

NOMBRE Y APELLIDO:
DIRECCION DE ENVIO:
LOCALIDAD:
PROVINCIA:
CP:
PAIS:
CANTIDAD SOLICITADA:
EMPRESA:
CARGO:
DIRECCION DE FACTURACION:
CUIT:
COND. IVA:
TELEFONOS:
OBS.:

Cordialmente,

Lic. Andrea Alluvi
Depto. Marketing


Si este mensaje no es de su inter=E9s env=EDe un e-mail con el asunto:

BAJAR  iptel@lists.research.bell-labs.com

a finanzas.mail@poboxes.com



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 14 22:30:46 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12330
	for <iptel-archive@odin.ietf.org>; Wed, 14 Apr 1999 22:30:46 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 2189252C5; Wed, 14 Apr 1999 22:25:30 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3983952B7; Wed, 14 Apr 1999 22:25:26 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <199904150220.TAA18108@mailman.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 14 Apr 1999 22:20:11 -0400
To: iptel@lists.research.bell-labs.com
From: Chip Sharp <chsharp@cisco.com>
Subject: CPL Proposed to ITU SG16
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

FYI,
At the last US State Dept ITAC-D meeting, a contribution was brought in
submitting CPL to ITU SG16 for consideration.  I believe the drafts were
attached.  Unfortunately I didn't get a copy and I had to leave before the
discussion was ended so I don't know how it turned out.
Thus I believe it might be an item of discussion in Santiago.

Chip
--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085 
Cisco Systems              Consulting Eng. - Telco   
Reality - Love it or Leave it.			
--------------------------------------------------

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 14 22:37:43 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13059
	for <iptel-archive@odin.ietf.org>; Wed, 14 Apr 1999 22:37:43 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id B625A52C1; Wed, 14 Apr 1999 22:25:26 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D9F6B52C3; Wed, 14 Apr 1999 22:25:24 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <009401be86e7$ca5b48e0$741f0e0a@telkom.go.id>
From: "Henri Setiawan" <henry@risti.telkom.co.id>
To: "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
References: <3.0.32.19990324082921.0079a390@bl-mail1.corpeast.baynetworks.com> <36F9AF74.F360B23A@dnrc.bell-labs.com>
Subject: Measurement and testing parameter
Date: Thu, 15 Apr 1999 09:29:29 +0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear folks,

May be you have been evaluating several vendors solution on VoIP. Is there
anyone have been testing the equipments ? Can you share about the
measurement methods and testing parameter to classify the performance of the
equipment ? Also, if you know the measurement equipment for testing please
let me know.

Other case, please explain to me how can we measure MOS ?

Thank you

Henri Setiawan
R&D of PT Telkom Indonesia



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 14 22:46:34 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13234
	for <iptel-archive@odin.ietf.org>; Wed, 14 Apr 1999 22:46:34 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5E9A752C7; Wed, 14 Apr 1999 22:31:24 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8530152CB; Wed, 14 Apr 1999 22:31:23 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <00c001be86e8$8478da80$741f0e0a@telkom.go.id>
From: "Henri Setiawan" <henry@risti.telkom.co.id>
To: <h323implementors@imtc.org>
Cc: <iptel@lists.research.bell-labs.com>
References: <370A240F.55A0A2F3@agcs.com>
Subject: H.323 testing
Date: Thu, 15 Apr 1999 09:34:39 +0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear folks,

We plan to test several VoIP products for H.323 compliment. Is there anyone
have done this test ? Please inform me regarding the methods, testing
parameters and equipment to test.

Thanks

Henri S
R&D of PT Telkom Indonesia.




---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 13:56:23 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09919
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 13:56:23 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 213AC52C8; Thu, 15 Apr 1999 13:51:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5E06252CB; Thu, 15 Apr 1999 13:51:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990415175021.10504.rocketmail@web110.yahoomail.com>
Date: Thu, 15 Apr 1999 10:50:21 -0700 (PDT)
From: Tom Gray <tom_gray_intp@yahoo.com>
Subject: RE: Measurement and testing parameter
To: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk



--- "Hoefelmeyer, Ralph (MCI)" <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
wrote:

> 
> What does "YM_M4I5S3S_4" stand for? 
> 


YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes the
perceived quality of the voice connection. It has five categories going
from Excellent to Unacceptable. This is an important aspect of
YM_M4I5S3S_6 telephony since it will assess the capability of various
YM_M4I5S3S_7 to meet human expectations. It will also be a measure of
YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 14:05:33 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10294
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 14:05:32 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id CE01C52D0; Thu, 15 Apr 1999 13:55:24 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CBE1152CE; Thu, 15 Apr 1999 13:55:23 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <E32BD2062DAFD1119CFD0000F804F31702C04A77@cosexch003.mcit.com>
From: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
To: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Measurement and testing parameter
Date: Thu, 15 Apr 1999 17:53:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE8768.E183226E"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE8768.E183226E
Content-Type: text/plain

Tom,
Thanks.  So this MOS would be primarily dependent on the codex, assuming the
transport layers delivers all of the packets?
Please clarify your message, as you can see below it came through garbled.
Cordially,
Ralph

> -----Original Message-----
> From:	Tom Gray [SMTP:tom_gray_intp@yahoo.com]
> Sent:	Thursday, April 15, 1999 11:50 AM
> To:	Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF Mailing List
> Subject:	RE: Measurement and testing parameter
> 
> 
> 
> --- "Hoefelmeyer, Ralph (MCI)" <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
> wrote:
> 
> > 
> > What does "YM_M4I5S3S_4" stand for? 
> > 
> 
> 
> YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes the
> perceived quality of the voice connection. It has five categories going
> from Excellent to Unacceptable. This is an important aspect of
> YM_M4I5S3S_6 telephony since it will assess the capability of various
> YM_M4I5S3S_7 to meet human expectations. It will also be a measure of
> YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol.
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

------_=_NextPart_001_01BE8768.E183226E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: Measurement and testing parameter</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Tom,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Thanks.&nbsp; So this MOS =
would be primarily dependent on the codex, assuming the transport =
layers delivers all of the packets?</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Please clarify your message, =
as you can see below it came through garbled.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Cordially,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Ralph</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tom Gray [SMTP:tom_gray_intp@yahoo.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, April 15, 1999 11:50 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF =
Mailing List</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: Measurement and testing =
parameter</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">--- &quot;Hoefelmeyer, Ralph =
(MCI)&quot; &lt;Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; What does =
&quot;YM_M4I5S3S_4&quot; stand for? </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_5 is Mean Opinion =
Score. It is a metric which denotes the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">perceived quality of the voice =
connection. It has five categories going</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">from Excellent to Unacceptable. =
This is an important aspect of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_6 telephony since it =
will assess the capability of various</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_7 to meet human =
expectations. It will also be a measure of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_8 beyond compliance =
to the YM_M4I5S3S_9 protocol.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">_________________________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Get your free @yahoo.com =
address at<U> </U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New"><A HREF=3D"http://mail.yahoo.com" =
TARGET=3D"_blank">http://mail.yahoo.com</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE8768.E183226E--

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 14:22:23 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10740
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 14:22:23 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 2FE3E52C6; Thu, 15 Apr 1999 14:17:14 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6942A52CB; Thu, 15 Apr 1999 14:17:13 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <37162DBF.D04ED3B9@enfm.utcc.utoronto.ca>
Date: 	Thu, 15 Apr 1999 14:19:43 -0400
From: Sam Mokbel <smokbel@enfm.utcc.utoronto.ca>
Organization: ONet Networking
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
Cc: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: Measurement and testing parameter
References: <E32BD2062DAFD1119CFD0000F804F31702C04A77@cosexch003.mcit.com>
Content-Type: multipart/alternative; boundary="------------FBA654F9D5477BA1CB4F8388"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


--------------FBA654F9D5477BA1CB4F8388
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ralph,

Even if the transport layer delivers all packets that does not
necessarily mean that it is not having an effect on the MOS. The delay
and delay variations of the packet arrival time can have a significant
effect on MOS.

Hoefelmeyer, Ralph (MCI) wrote:

>
>
> Tom,
> Thanks.  So this MOS would be primarily dependent on the codex,
> assuming the transport layers delivers all of the packets?
>
> Please clarify your message, as you can see below it came through
> garbled.
> Cordially,
> Ralph
>
>      -----Original Message-----
>      From:   Tom Gray [SMTP:tom_gray_intp@yahoo.com]
>      Sent:   Thursday, April 15, 1999 11:50 AM
>      To:     Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF
>      Mailing List
>      Subject:        RE: Measurement and testing parameter
>
>
>      --- "Hoefelmeyer, Ralph (MCI)"
>      <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
>      wrote:
>
>      >
>      > What does "YM_M4I5S3S_4" stand for?
>      >
>
>      YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which denotes
>      the
>      perceived quality of the voice connection. It has five categories
>      going
>      from Excellent to Unacceptable. This is an important aspect of
>      YM_M4I5S3S_6 telephony since it will assess the capability of
>      various
>      YM_M4I5S3S_7 to meet human expectations. It will also be a
>      measure of
>      YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol.
>
>      _________________________________________________________
>      Do You Yahoo!?
>      Get your free @yahoo.com address at http://mail.yahoo.com
>
--
Sam Mokbel
University of Toronto
External Networking and Facilities Management
4 Bancroft Ave., Room 101
Toronto, Ontario M5S 1C1
Tel: (416) 978-3328 Fax: (416) 978-6620


--------------FBA654F9D5477BA1CB4F8388
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Ralph,
<P>Even if the transport layer delivers all packets that does not necessarily
mean that it is not having an effect on the MOS. The delay and delay variations
of the packet arrival time can have a significant effect on MOS.
<P>Hoefelmeyer, Ralph (MCI) wrote:
<BLOCKQUOTE TYPE=CITE>&nbsp;
<P><FONT FACE="Arial"><FONT COLOR="#0000FF">Tom,</FONT></FONT>
<BR><FONT FACE="Arial"><FONT COLOR="#0000FF">Thanks.&nbsp; So this MOS
would be primarily dependent on the codex, assuming the transport layers
delivers all of the packets?</FONT></FONT>
<P><FONT FACE="Arial"><FONT COLOR="#0000FF">Please clarify your message,
as you can see below it came through garbled.</FONT></FONT>
<BR><FONT FACE="Arial"><FONT COLOR="#0000FF">Cordially,</FONT></FONT>
<BR><FONT FACE="Arial"><FONT COLOR="#0000FF">Ralph</FONT></FONT>
<UL><FONT FACE="Arial"><FONT SIZE=-2>-----Original Message-----</FONT></FONT>
<BR><B><FONT FACE="Arial"><FONT SIZE=-2>From:&nbsp;&nbsp;</FONT></FONT></B>
<FONT FACE="Arial"><FONT SIZE=-2>Tom Gray [SMTP:tom_gray_intp@yahoo.com]</FONT></FONT>
<BR><B><FONT FACE="Arial"><FONT SIZE=-2>Sent:&nbsp;&nbsp;</FONT></FONT></B>
<FONT FACE="Arial"><FONT SIZE=-2>Thursday, April 15, 1999 11:50 AM</FONT></FONT>
<BR><B><FONT FACE="Arial"><FONT SIZE=-2>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT></B>
<FONT FACE="Arial"><FONT SIZE=-2>Hoefelmeyer, Ralph (MCI); 'Henri Setiawan';
IPTEL IETF Mailing List</FONT></FONT>
<BR><B><FONT FACE="Arial"><FONT SIZE=-2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></FONT></B>
<FONT FACE="Arial"><FONT SIZE=-2>RE: Measurement and testing parameter</FONT></FONT>
<BR>&nbsp;
<P><FONT FACE="Courier New"><FONT SIZE=-1>--- "Hoefelmeyer, Ralph (MCI)"
&lt;Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com></FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>wrote:</FONT></FONT>
<P><FONT FACE="Courier New"><FONT SIZE=-1>></FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>> What does "YM_M4I5S3S_4" stand
for?</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>></FONT></FONT>
<P><FONT FACE="Courier New"><FONT SIZE=-1>YM_M4I5S3S_5 is Mean Opinion
Score. It is a metric which denotes the</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>perceived quality of the voice
connection. It has five categories going</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>from Excellent to Unacceptable.
This is an important aspect of</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>YM_M4I5S3S_6 telephony since
it will assess the capability of various</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>YM_M4I5S3S_7 to meet human expectations.
It will also be a measure of</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>YM_M4I5S3S_8 beyond compliance
to the YM_M4I5S3S_9 protocol.</FONT></FONT>
<P><FONT FACE="Courier New"><FONT SIZE=-1>_________________________________________________________</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>Do You Yahoo!?</FONT></FONT>
<BR><FONT FACE="Courier New"><FONT SIZE=-1>Get your free @yahoo.com address
at<U> <FONT COLOR="#0000FF"><A HREF="http://mail.yahoo.com" TARGET="_blank">http://mail.yahoo.com</A></FONT></U></FONT></FONT></UL>
</BLOCKQUOTE>

<P>--
<BR>Sam Mokbel
<BR>University of Toronto
<BR>External Networking and Facilities Management
<BR>4 Bancroft Ave., Room 101
<BR>Toronto, Ontario M5S 1C1
<BR>Tel: (416) 978-3328 Fax: (416) 978-6620
<BR>&nbsp;</HTML>

--------------FBA654F9D5477BA1CB4F8388--


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 14:54:08 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11704
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 14:54:08 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5F3A752CA; Thu, 15 Apr 1999 13:35:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B948252CB; Thu, 15 Apr 1999 13:35:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <E32BD2062DAFD1119CFD0000F804F31702C04A73@cosexch003.mcit.com>
From: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
To: "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Measurement and testing parameter
Date: Thu, 15 Apr 1999 17:34:15 -0000
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE8766.2F750166"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE8766.2F750166
Content-Type: text/plain

Henri,
The predominant testing method is to determine interoperability between
differing vendors equipment.  Simply hook up the devices to a LAN, and
across a small WAN, set up the IP addresses correctly, and start calling.
Measure call setup times, time to process an address translation, time to
set up the RTP channel, etc.  One uses LAN analyzers to measure the various
latencies, and to view the protocol exchanges.  Hewlett-Packard has an H.323
analyzer in Beta now.  I do not know of a SIP analyzer yet.
This is for an IP centric network implementation.  For testing between a
circuit switched network and a packet based network, I do not know what one
uses to watch telephony switch message exchanges.
The problem in the SIP world is that there are lots of prototypes and no
product on the market that I can buy today.   If someone knows differently,
please let me know ASAP. 
There are some H.323 devices, but even here, there is not much for
production devices.  Erricson has an H.323 Gatekeeper in use in Norway, but
it is an NT box. There are other H.323 gatekeepers out there, but they have
all of the problems one expects with H.323/RAS etc. (elemedia, RadVision,
Cisco). Some are simply software elements one places on a server, others are
proprietary hardware and software solutions.
You should keep a watch out on the URL
http://www.cs.columbia.edu/~hgs/sip/bakeoff.html   for the results of the
SIP Bake-off, an interoperability event held last week in New York City.

What does "MOS" stand for? 

Cordially,
Ralph

Ralph S. Hoefelmeyer
MCI WorldCom Engineer


> -----Original Message-----
> From:	Henri Setiawan [SMTP:henry@risti.telkom.co.id]
> Sent:	Wednesday, April 14, 1999 8:29 PM
> To:	IPTEL IETF Mailing List
> Subject:	Measurement and testing parameter
> 
> Dear folks,
> 
> May be you have been evaluating several vendors solution on VoIP. Is there
> anyone have been testing the equipments ? Can you share about the
> measurement methods and testing parameter to classify the performance of
> the
> equipment ? Also, if you know the measurement equipment for testing please
> let me know.
> 
> Other case, please explain to me how can we measure MOS ?
> 
> Thank you
> 
> Henri Setiawan
> R&D of PT Telkom Indonesia
> 
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE8766.2F750166
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: Measurement and testing parameter</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Henri,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">The predominant testing =
method is to determine interoperability between differing vendors =
equipment.&nbsp; Simply hook up the devices to a LAN, and across a =
small WAN, set up the IP addresses correctly, and start calling.&nbsp; =
Measure call setup times, time to process an address translation, time =
to set up the RTP channel, etc.&nbsp; One uses LAN analyzers to measure =
the various latencies, and to view the protocol exchanges.&nbsp; =
Hewlett-Packard has an H.323 analyzer in Beta now.&nbsp; I do not know =
of a SIP analyzer yet.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">This is for an IP centric =
network implementation.&nbsp; For testing between a circuit switched =
network and a packet based network, I do not know what one uses to =
watch telephony switch message exchanges.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">The problem in the SIP world =
is that there are lots of prototypes and no product on the market that =
I can buy today.&nbsp;&nbsp; If someone knows differently, please let =
me know ASAP. </FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">There are some H.323 devices, =
but even here, there is not much for production devices.&nbsp; Erricson =
has an H.323 Gatekeeper in use in Norway, but it is an NT box. There =
are other H.323 gatekeepers out there, but they have all of the =
problems one expects with H.323/RAS etc. (elemedia, RadVision, Cisco). =
Some are simply software elements one places on a server, others are =
proprietary hardware and software solutions.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">You should keep a watch out =
on the URL<U> <A =
HREF=3D"http://www.cs.columbia.edu/~hgs/sip/bakeoff.html" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs/sip/bakeoff.html</A></=
U>&nbsp;&nbsp; for the results of the SIP Bake-off, an interoperability =
event held last week in New York City.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">What does &quot;MOS&quot; =
stand for? </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Cordially,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Ralph</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Ralph S. Hoefelmeyer</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">MCI WorldCom Engineer</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Henri Setiawan =
[SMTP:henry@risti.telkom.co.id]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, April 14, 1999 8:29 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">IPTEL IETF Mailing List</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Measurement and testing =
parameter</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Dear folks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">May be you have been evaluating =
several vendors solution on VoIP. Is there</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">anyone have been testing the =
equipments ? Can you share about the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">measurement methods and testing =
parameter to classify the performance of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">equipment ? Also, if you know =
the measurement equipment for testing please</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">let me know.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Other case, please explain to me =
how can we measure MOS ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Thank you</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Henri Setiawan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">R&amp;D of PT Telkom =
Indonesia</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">This message came from the IETF =
IPTEL Working Group Mailing List.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE8766.2F750166--

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 15:01:44 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11958
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 15:01:43 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id AE43452CB; Thu, 15 Apr 1999 14:51:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 16C5F52CC; Thu, 15 Apr 1999 14:51:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <E32BD2062DAFD1119CFD0000F804F31702C04A80@cosexch003.mcit.com>
From: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
To: "'Sam Mokbel'" <smokbel@enfm.utcc.utoronto.ca>
Cc: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Measurement and testing parameter
Date: Thu, 15 Apr 1999 18:48:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE8770.961BFD7A"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE8770.961BFD7A
Content-Type: text/plain

Sam,
Shouldn't the codec smooth this out?  I am a network and software person,
not a telephony expert ... yet, working on it.
I would think there would be a buffering function within the codec to smooth
the delay & delay variations out.  Of course, if the delay is to long
(whatever that means), then there is a noticeable gap in the voice stream.
Thanks,
Ralph

> -----Original Message-----
> From:	Sam Mokbel [SMTP:smokbel@enfm.utcc.utoronto.ca]
> Sent:	Thursday, April 15, 1999 12:20 PM
> To:	Hoefelmeyer, Ralph (MCI)
> Cc:	'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing List
> Subject:	Re: Measurement and testing parameter
> 
> Ralph, 
> 
> Even if the transport layer delivers all packets that does not necessarily
> mean that it is not having an effect on the MOS. The delay and delay
> variations of the packet arrival time can have a significant effect on
> MOS. 
> 
> Hoefelmeyer, Ralph (MCI) wrote: 
> 
> 	  
> 
> 	Tom, 
> 	Thanks.  So this MOS would be primarily dependent on the codex,
> assuming the transport layers delivers all of the packets? 
> 
> 	Please clarify your message, as you can see below it came through
> garbled. 
> 	Cordially, 
> 	Ralph 
> 
> 		-----Original Message----- 
> 	From:   Tom Gray [SMTP:tom_gray_intp@yahoo.com] 
> 	Sent:   Thursday, April 15, 1999 11:50 AM 
> 	To:     Hoefelmeyer, Ralph (MCI); 'Henri Setiawan'; IPTEL IETF
> Mailing List 
> 	Subject:        RE: Measurement and testing parameter 
> 	  
> 
> 		--- "Hoefelmeyer, Ralph (MCI)"
> <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com> 
> 	wrote: 
> 
> 		> 
> 	> What does "YM_M4I5S3S_4" stand for? 
> 	> 
> 
> 		YM_M4I5S3S_5 is Mean Opinion Score. It is a metric which
> denotes the 
> 	perceived quality of the voice connection. It has five categories
> going 
> 	from Excellent to Unacceptable. This is an important aspect of 
> 	YM_M4I5S3S_6 telephony since it will assess the capability of
> various 
> 	YM_M4I5S3S_7 to meet human expectations. It will also be a measure
> of 
> 	YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9 protocol. 
> 
> 		_________________________________________________________ 
> 	Do You Yahoo!? 
> 	Get your free @yahoo.com address at <http://mail.yahoo.com>
> 
> -- 
> Sam Mokbel 
> University of Toronto 
> External Networking and Facilities Management 
> 4 Bancroft Ave., Room 101 
> Toronto, Ontario M5S 1C1 
> Tel: (416) 978-3328 Fax: (416) 978-6620 
>  

------_=_NextPart_001_01BE8770.961BFD7A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2569.0">
<TITLE>RE: Measurement and testing parameter</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Sam,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Shouldn't the codec smooth =
this out?&nbsp; I am a network and software person, not a telephony =
expert ... yet, working on it.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">I would think there would be =
a buffering function within the codec to smooth the delay &amp; delay =
variations out.&nbsp; Of course, if the delay is to long (whatever that =
means), then there is a noticeable gap in the voice stream.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Thanks,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Ralph</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sam Mokbel =
[SMTP:smokbel@enfm.utcc.utoronto.ca]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, April 15, 1999 12:20 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Hoefelmeyer, Ralph (MCI)</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing =
List</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Measurement and testing =
parameter</FONT>
</P>

<P><FONT FACE=3D"Arial">Ralph, </FONT>
</P>

<P><FONT FACE=3D"Arial">Even if the transport layer delivers all =
packets that does not necessarily mean that it is not having an effect =
on the MOS. The delay and delay variations of the packet arrival time =
can have a significant effect on MOS. </FONT></P>

<P><FONT FACE=3D"Arial">Hoefelmeyer, Ralph (MCI) wrote: </FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial">=A0 </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Tom,</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Thanks.=A0 So this MOS =
would be primarily dependent on the codex, assuming the transport =
layers delivers all of the packets?</FONT><FONT FACE=3D"Arial"> =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Please clarify your message, =
as you can see below it came through garbled.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Cordially,</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Arial">Ralph</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Tom Gray =
[SMTP:tom_gray_intp@yahoo.com]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Thursday, April =
15, 1999 11:50 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Hoefelmeyer, Ralph =
(MCI); 'Henri Setiawan'; IPTEL IETF Mailing List</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">RE: Measurement =
and testing parameter</FONT><FONT FACE=3D"Arial"><BR>
=A0 </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">--- &quot;Hoefelmeyer, Ralph (MCI)&quot; =
&lt;Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com&gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">wrote:</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&gt;</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">&gt; What does =
&quot;YM_M4I5S3S_4&quot; stand for?</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">YM_M4I5S3S_5 is Mean Opinion Score. It is a metric =
which denotes the</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">perceived quality of the =
voice connection. It has five categories going</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">from Excellent to =
Unacceptable. This is an important aspect of</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_6 telephony since =
it will assess the capability of various</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_7 to meet human =
expectations. It will also be a measure of</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">YM_M4I5S3S_8 beyond =
compliance to the YM_M4I5S3S_9 protocol.</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier =
New">_________________________________________________________</FONT><FO=
NT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Do You Yahoo!?</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Get your free @yahoo.com =
address at<U> </U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">&lt;<A HREF=3D"http://mail.yahoo.com" =
TARGET=3D"_blank">http://mail.yahoo.com</A>&gt;</FONT></U>
</P>
</UL>
<P><FONT FACE=3D"Arial">--<BR>
Sam Mokbel<BR>
University of Toronto<BR>
External Networking and Facilities Management<BR>
4 Bancroft Ave., Room 101<BR>
Toronto, Ontario M5S 1C1<BR>
Tel: (416) 978-3328 Fax: (416) 978-6620<BR>
=A0</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE8770.961BFD7A--

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 15:13:56 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12269
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 15:13:56 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 57F1152CF; Thu, 15 Apr 1999 15:05:26 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9996552D1; Thu, 15 Apr 1999 15:05:25 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990415190353.24243.rocketmail@web118.yahoomail.com>
Date: Thu, 15 Apr 1999 12:03:53 -0700 (PDT)
From: Tom Gray <tom_gray_intp@yahoo.com>
Subject: RE: Measurement and testing parameter
To: Tom Gray <tom_gray_intp@yahoo.com>,
        "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


Yahoo seems to have a strange sense of humour. its spell checker
changed my English words to some strange internal representaion. Here
is another attempt.

> What does "MOS" stand for? 
> 
 

MOS is Mean Opinion Score. It is a metric which denotes the perceived
quality of the voice connection. It has five categories going from
Excellent to Unacceptable. This is an important aspect of IP telephony
since it will assess the capability of various
implementations to meet human expectations. It will also be a measure
of interoperability beyond compliance to the signaling protocol.
 


> M-O-S is Mean Opinion Score. It is a metric
> which denotes the
> perceived quality of the voice connection. It has
> five categories going
> from Excellent to Unacceptable. This is an important
> aspect of
>IP telephony since it will assess the
> capability of various
>  to meet human expectations. It will
> also be a measure of
> YM_M4I5S3S_8 beyond compliance to the YM_M4I5S3S_9
> protocol.
> 
--- Tom Gray <tom_gray_intp@yahoo.com> wrote:
> 
> 
> --- "Hoefelmeyer, Ralph (MCI)"
> <Ralph.YM_M4I5S3S_2@YM_M4I5S3S_3.com>
> wrote:

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 15:22:03 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12609
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 15:22:03 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 536C052B7; Thu, 15 Apr 1999 15:13:22 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8950252D5; Thu, 15 Apr 1999 15:13:21 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <37163A83.1BDF44B2@enfm.utcc.utoronto.ca>
Date: 	Thu, 15 Apr 1999 15:14:11 -0400
From: Sam Mokbel <smokbel@enfm.utcc.utoronto.ca>
Organization: ONet Networking
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
Cc: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: Measurement and testing parameter
References: <E32BD2062DAFD1119CFD0000F804F31702C04A80@cosexch003.mcit.com>
Content-Type: multipart/alternative; boundary="------------3C3D8B6678CAEFDA23C55E82"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


--------------3C3D8B6678CAEFDA23C55E82
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sure, the Codec may be able to smooth out a lot of the jitter and delay.
There are limits however to how long you can buffer and introduce
additional engineered delays. I have seen suggestions that delays in
excess of 150ms are not acceptable because they are noticeable to the
human ear, assuming that echo is dealt with properly. Current data
traffic patterns and networking protocols may introduce delays in excess
of 150ms.

Hoefelmeyer, Ralph (MCI) wrote:

>
>
> Sam,
> Shouldn't the codec smooth this out?  I am a network and software
> person, not a telephony expert ... yet, working on it.
>
> I would think there would be a buffering function within the codec to
> smooth the delay & delay variations out.  Of course, if the delay is
> to long (whatever that means), then there is a noticeable gap in the
> voice stream.
>
> Thanks,

--
Sam Mokbel
University of Toronto
External Networking and Facilities Management
4 Bancroft Ave., Room 101
Toronto, Ontario M5S 1C1
Tel: (416) 978-3328 Fax: (416) 978-6620


--------------3C3D8B6678CAEFDA23C55E82
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Sure, the Codec may be able to smooth out a lot of the jitter and delay.
There are limits however to how long you can buffer and introduce additional
engineered delays. I have seen suggestions that delays in excess of 150ms
are not acceptable because they are noticeable to the human ear, assuming
that echo is dealt with properly. Current data traffic patterns and networking
protocols may introduce delays in excess of 150ms.
<P>Hoefelmeyer, Ralph (MCI) wrote:
<BLOCKQUOTE TYPE=CITE>&nbsp;
<P><FONT FACE="Arial"><FONT COLOR="#0000FF">Sam,</FONT></FONT>
<BR><FONT FACE="Arial"><FONT COLOR="#0000FF">Shouldn't the codec smooth
this out?&nbsp; I am a network and software person, not a telephony expert
... yet, working on it.</FONT></FONT>
<P><FONT FACE="Arial"><FONT COLOR="#0000FF">I would think there would be
a buffering function within the codec to smooth the delay &amp; delay variations
out.&nbsp; Of course, if the delay is to long (whatever that means), then
there is a noticeable gap in the voice stream.</FONT></FONT>
<P><FONT FACE="Arial"><FONT COLOR="#0000FF">Thanks,</FONT></FONT></BLOCKQUOTE>

<P>--
<BR>Sam Mokbel
<BR>University of Toronto
<BR>External Networking and Facilities Management
<BR>4 Bancroft Ave., Room 101
<BR>Toronto, Ontario M5S 1C1
<BR>Tel: (416) 978-3328 Fax: (416) 978-6620
<BR>&nbsp;</HTML>

--------------3C3D8B6678CAEFDA23C55E82--


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 17:00:15 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14430
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 17:00:15 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id C829152D3; Thu, 15 Apr 1999 16:55:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 208F252D4; Thu, 15 Apr 1999 16:55:17 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <D1B671237B8FD2118D040000F804C47413BE20@omzexch009.mcit.com>
From: "DelRegno, Christopher (MCI)" <Nick.DelRegno@wcom.com>
To: "'Sam Mokbel'" <smokbel@enfm.utcc.utoronto.ca>,
        "Hoefelmeyer, Ralph (MCI)" <Ralph.Hoefelmeyer@wcom.com>
Cc: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Measurement and testing parameter
Date: Thu, 15 Apr 1999 20:50:37 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BE8781.9DC9E3DC"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE8781.9DC9E3DC
Content-Type: text/plain;
	charset="windows-1252"

Regarding PSTN signalling test equipment, there are many such devices from
HP, etc.  I have not seen one however that can simultaneously test both
sides of a IP/PSTN call.
 
MOS, as noted below, is Mean Opinion Score.  Notice, Opinion.  MOS is an
objective way of measuring the subjective nature of voice quality and the
individual's experience.  MOS, from a provider's perspective should be
measured end-to-end, since this is what the user experience will be based
on.  In codec development, we rely on MOS testing to determine the relative
quality of that codec as compared to PCM.  Further, in network analysis, MOS
can be used to determine the quality of one network technology versus
another, or one carrier's network vs. another.
 
Traditionally, true MOS testing is very expensive.  Most people use more
limited, predictive testing such as DAM testing.  These types of tests
suggest what type of MOS score would result from a true evaluation, without
the cost.  However, DAM testing and the like doesn't guarantee the MOS
score; it is only a predictor, and usually a pretty good one.
 
While codecs may be able to smooth out network impairments within reason,
they cannot smooth out ALL network impairments.  Networks can vary wildly
depending upon architecture, protocols, QOS, etc.  For example, if latency
increases too much, today's echo cancellors may not have a way to
compensate, thereby increasing the echo.  While every other parameter may be
on target, this one problem will significantly affect the overall quality.
 
I am sorry to say that there is no one device that can measure MOS on the
fly, to my knowledge.  Most testing requires the development of test cases
and test content, running that content through pristine networks and
conditions and then comparing the results with the results from varying
codecs, network impairments, etc.  Not necessarily an easy process.
 
Hope that helps.
 
Nick
Christopher N. "Nick" DelRegno 
MCI WorldCom, Access Technology Development 
400 International Pkwy, 1010/041 
Richardson, TX  75081-6606 
Tel: 972-729-3411 
Fax: 972-907-8784 
Email: Nick.DelRegno@mci.com 

 
 

-----Original Message-----
From: Sam Mokbel [mailto:smokbel@enfm.utcc.utoronto.ca]
Sent: Thursday, April 15, 1999 12:14 PM
To: Hoefelmeyer, Ralph (MCI)
Cc: 'Tom Gray'; 'Henri Setiawan'; IPTEL IETF Mailing List
Subject: Re: Measurement and testing parameter


Sure, the Codec may be able to smooth out a lot of the jitter and delay.
There are limits however to how long you can buffer and introduce additional
engineered delays. I have seen suggestions that delays in excess of 150ms
are not acceptable because they are noticeable to the human ear, assuming
that echo is dealt with properly. Current data traffic patterns and
networking protocols may introduce delays in excess of 150ms. 

Hoefelmeyer, Ralph (MCI) wrote: 


  

Sam, 
Shouldn't the codec smooth this out?  I am a network and software person,
not a telephony expert ... yet, working on it. 


I would think there would be a buffering function within the codec to smooth
the delay & delay variations out.  Of course, if the delay is to long
(whatever that means), then there is a noticeable gap in the voice stream. 


Thanks,

-- 
Sam Mokbel 
University of Toronto 
External Networking and Facilities Management 
4 Bancroft Ave., Room 101 
Toronto, Ontario M5S 1C1 
Tel: (416) 978-3328 Fax: (416) 978-6620 
  


------_=_NextPart_001_01BE8781.9DC9E3DC
Content-Type: text/html;
	charset="windows-1252"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">


<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999>Regarding PSTN signalling test equipment, there are 
many such devices from HP, etc.&nbsp; I have not seen one however that can 
simultaneously test both sides of a IP/PSTN call.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360002320-15041999>MOS, 
as noted below, is Mean Opinion Score.&nbsp; Notice, Opinion.&nbsp; MOS is an 
objective way of measuring the subjective nature of voice quality and the 
individual's experience.&nbsp; MOS, from a provider's perspective should be 
measured end-to-end, since this is what the user experience will be based 
on.&nbsp; In codec development, we rely on MOS testing to determine the relative 
quality of that codec as compared to PCM.&nbsp; Further, in network analysis, 
MOS can be used to determine the quality of one network technology versus 
another, or one carrier's network vs. another.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999>Traditionally, true MOS testing is very 
expensive.&nbsp; Most people use more limited, predictive testing such as DAM 
testing.&nbsp; These types of tests suggest what type of MOS score would result 
from a true evaluation, without the cost.&nbsp; However, DAM testing and the 
like doesn't guarantee the MOS score; it is only a predictor, and usually a 
pretty good one.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360002320-15041999>While 
codecs may be able to smooth out network impairments within reason, they cannot 
smooth out ALL network impairments.&nbsp; Networks can vary wildly depending 
upon architecture, protocols, QOS, etc.&nbsp; For example, if latency increases 
too much, today's echo cancellors may not have&nbsp;a way to compensate, thereby 
increasing the echo.&nbsp; While every other parameter may be on target, this 
one problem will significantly affect the overall quality.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360002320-15041999>I am 
sorry to say that there is no one device that can measure MOS on the fly, to my 
knowledge.&nbsp; Most testing requires the development of test cases and test 
content, running that content through pristine networks and conditions and then 
comparing the results with the results from varying codecs, network impairments, 
etc.&nbsp; Not necessarily an easy process.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360002320-15041999>Hope 
that helps.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999>Nick</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360002320-15041999>
<P><FONT face=Arial size=2>Christopher N. "Nick" DelRegno</FONT> <BR><FONT 
face=Arial size=2>MCI WorldCom, Access Technology Development</FONT> <BR><FONT 
face=Arial size=2>400 International Pkwy, 1010/041</FONT> <BR><FONT face=Arial 
size=2>Richardson, TX&nbsp; 75081-6606</FONT> <BR><FONT face=Arial size=2>Tel: 
972-729-3411</FONT> <BR><FONT face=Arial size=2>Fax: 972-907-8784</FONT> 
<BR><FONT face=Arial size=2>Email: Nick.DelRegno@mci.com</FONT> 
</P></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=360002320-15041999></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Sam Mokbel 
  [mailto:smokbel@enfm.utcc.utoronto.ca]<BR><B>Sent:</B> Thursday, April 15, 
  1999 12:14 PM<BR><B>To:</B> Hoefelmeyer, Ralph (MCI)<BR><B>Cc:</B> 'Tom Gray'; 
  'Henri Setiawan'; IPTEL IETF Mailing List<BR><B>Subject:</B> Re: Measurement 
  and testing parameter<BR><BR></DIV></FONT>Sure, the Codec may be able to 
  smooth out a lot of the jitter and delay. There are limits however to how long 
  you can buffer and introduce additional engineered delays. I have seen 
  suggestions that delays in excess of 150ms are not acceptable because they are 
  noticeable to the human ear, assuming that echo is dealt with properly. 
  Current data traffic patterns and networking protocols may introduce delays in 
  excess of 150ms. 
  <P>Hoefelmeyer, Ralph (MCI) wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp; 
    <P><FONT face=Arial><FONT color=#0000ff>Sam,</FONT></FONT> <BR><FONT 
    face=Arial><FONT color=#0000ff>Shouldn't the codec smooth this out?&nbsp; I 
    am a network and software person, not a telephony expert ... yet, working on 
    it.</FONT></FONT> 
    <P><FONT face=Arial><FONT color=#0000ff>I would think there would be a 
    buffering function within the codec to smooth the delay &amp; delay 
    variations out.&nbsp; Of course, if the delay is to long (whatever that 
    means), then there is a noticeable gap in the voice stream.</FONT></FONT> 
    <P><FONT face=Arial><FONT color=#0000ff>Thanks,</FONT></FONT></P></BLOCKQUOTE>
  <P>-- <BR>Sam Mokbel <BR>University of Toronto <BR>External Networking and 
  Facilities Management <BR>4 Bancroft Ave., Room 101 <BR>Toronto, Ontario M5S 
  1C1 <BR>Tel: (416) 978-3328 Fax: (416) 978-6620 <BR>&nbsp; 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BE8781.9DC9E3DC--

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 15 17:45:48 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15162
	for <iptel-archive@odin.ietf.org>; Thu, 15 Apr 1999 17:45:48 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id EC67F52D2; Thu, 15 Apr 1999 17:41:17 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5D0F852D5; Thu, 15 Apr 1999 17:41:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
X-Lotus-FromDomain: TERADYNE
From: "Kevin Davis" <Kevin_Davis@notes.teradyne.com>
To: iptel@lists.research.bell-labs.com
Message-ID: <85256754.0076F481.00@notes.teradyne.com>
Date: Thu, 15 Apr 1999 17:40:47 -0400
Subject: MOS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


>>MOS is Mean Opinion Score. It is a metric which denotes the
>>perceived quality of the voice connection. It has five
>>categories going from Excellent to Unacceptable. This is
>>an important aspect of IP telephony ....


As Tom has pointed out, MOS is a measure of percieved quality.
The ITU-T calls it a "subjective" measure, which is to say
it depends upon human listeners.
In contrast to MOS, there is also an "objective" measure;
see ITU-T P.861 - PSQM (Perceptual Speech Quality Measure).
Both MOS and PSQM both will provide a numerical value
to represent the quality level, there is no single function
which maps one to the other.

  P.861 section 10.1
  "Since the relationship between the MOS and PSQM values
  is not necessarily the same for different languages or even
  for different subjective tests within a language, it is
  difficult to determine a unique function which transforms
  the PSQM value to the estimated MOS value."

The objective measure (PSQM) estimates the subjective measure.
The latter (human perception of quality) is presumably what
everyone really wants to know, but the it is the former which
can be automated and provide higher consistency.

  P.861 section 10.1
  "It is difficult to compare the MOSs obtained in different
  subjective experiments since subjective judgement is
  affected by the experimental settings ...."



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 16 12:30:26 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06659
	for <iptel-archive@odin.ietf.org>; Fri, 16 Apr 1999 12:30:25 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id B4B7152CC; Fri, 16 Apr 1999 12:25:14 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 302A552CD; Fri, 16 Apr 1999 12:25:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990416162402.13813.rocketmail@web117.yahoomail.com>
Date: Fri, 16 Apr 1999 09:24:02 -0700 (PDT)
From: Tom Gray <tom_gray_intp@yahoo.com>
Subject: RE: Measurement and testing parameter
To: "'Tom Gray'" <tom_gray_intp@yahoo.com>,
        "'Henri Setiawan'" <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk



It should be remembered that MOS is based on the. subjective opinions
of real people about the quality of a voice connection. It is therefore
based on their expectations of the service. With experience these
expectations tend to rise and the expectations of the performance of
teh PSTN network have risen over the years making MOS more stringent as
time goes by.

An MOS for IP tlephony needs to be developed to coincde with the
expecations of the people who use it and the decision makers who will
buy it. It is likely that these people, given IP telephony's other
advantages, will not expect or require the same level of service from
IPTel as the PSTN. Direct use of a PSTN MOS is probably not predictive
or useful.

Tom Gray

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 16 23:39:15 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21702
	for <iptel-archive@odin.ietf.org>; Fri, 16 Apr 1999 23:39:15 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id E6D7D52CD; Fri, 16 Apr 1999 22:47:22 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4CA5952D1; Fri, 16 Apr 1999 22:47:20 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: "Joe" <goldcd@iqemail.com>
Subject: IMPORTANTE !
To: goldlist943e@research.bell-labs.com
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Fri, 16 Apr 1999 22:23:53 -0500
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <19990417024704.F3E9C52CD@lists.research.bell-labs.com>
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21702

--------------------------------
   BASES DE DATOS EN CD-ROM
   PARA MARKETING POR EMAIL
--------------------------------
10.000  EMAILS ARGENTINOS  $  99
20.000  EMAILS ARGENTINOS  $ 199
30.000  EMAILS ARGENTINOS  $ 299
--------------------------------
    DATOS ACTUALIZADOS !!!
--------------------------------
     LLAME AL 4312-9666
--------------------------------

Los precios NO incluyen el IVA
Oferta Valida hasta el 31/06/99

//////////////////////////////////////////////////////////////
REMOVE AT mailto:offlist@isleuthmail.com
//////////////////////////////////////////////////////////////




---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Mon Apr 19 10:00:21 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14663
	for <iptel-archive@odin.ietf.org>; Mon, 19 Apr 1999 10:00:20 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 7C2A452BB; Mon, 19 Apr 1999 08:33:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E65D352BF; Mon, 19 Apr 1999 08:33:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id>
From: "Henri Setiawan" <henry@risti.telkom.co.id>
To: "Tom Gray" <tom_gray_intp@yahoo.com>,
        "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
References: <19990416162402.13813.rocketmail@web117.yahoomail.com>
Subject: Re: Measurement and testing parameter
Date: Mon, 19 Apr 1999 19:38:09 +0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Tom,

Thank you for your respon regarding my question on measurement and testing
parameter, on my understanding tha MOS is not the only parameter to test
VoIP products. So, what do you think about the other parameter ? Like delay,
jitter, Codec or others QoS parameter ? According to you if we are only the
user, what we must aware on this technology ? Testing the products one by
one or just waiting until the technology is mature ?

By the way what do you think about using VoIP as asubstitute for to date
exchange ? Do you have any concept on this ?

Thanks

Henri S

----- Original Message -----
From: Tom Gray <tom_gray_intp@yahoo.com>
To: 'Tom Gray' <tom_gray_intp@yahoo.com>; 'Henri Setiawan'
<henry@risti.telkom.co.id>; IPTEL IETF Mailing List
<iptel@lists.research.bell-labs.com>
Sent: Friday, April 16, 1999 2324
Subject: RE: Measurement and testing parameter


>
>
> It should be remembered that MOS is based on the. subjective opinions
> of real people about the quality of a voice connection. It is therefore
> based on their expectations of the service. With experience these
> expectations tend to rise and the expectations of the performance of
> teh PSTN network have risen over the years making MOS more stringent as
> time goes by.
>
> An MOS for IP tlephony needs to be developed to coincde with the
> expecations of the people who use it and the decision makers who will
> buy it. It is likely that these people, given IP telephony's other
> advantages, will not expect or require the same level of service from
> IPTel as the PSTN. Direct use of a PSTN MOS is probably not predictive
> or useful.
>
> Tom Gray
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 02:07:49 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29517
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 02:07:48 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id B518852BF; Tue, 20 Apr 1999 02:01:14 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1F6B752C1; Tue, 20 Apr 1999 02:01:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <371C262F.D1C8C969@indosat.net.id>
Date: Tue, 20 Apr 1999 14:01:03 +0700
From: Perry Erick Renaldo <equest@indosat.net.id>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: IPtel Forum <iptel@lists.research.bell-labs.com>
Subject: Re: Measurement and testing parameter
References: <19990416162402.13813.rocketmail@web117.yahoomail.com> <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henry,
If you want to test data-net product in order to get a clearer view on
its performance you might need a standard test methodology. Robert
Mandeville has developed a standard test methodology and approved by the
IETF under the spell of RFC 2285. Might be a help.



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 02:40:12 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02644
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 02:40:12 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id C09D652C1; Tue, 20 Apr 1999 02:35:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 136B452C2; Tue, 20 Apr 1999 02:35:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <019601be8af8$58916a40$741f0e0a@telkom.go.id>
From: "Henri Setiawan" <henry@risti.telkom.co.id>
To: "Perry Erick Renaldo" <equest@indosat.net.id>,
        "IPtel Forum" <iptel@lists.research.bell-labs.com>
References: <19990416162402.13813.rocketmail@web117.yahoomail.com> <033f01be8a61$7d3d9040$741f0e0a@telkom.go.id> <371C262F.D1C8C969@indosat.net.id>
Subject: Re: Measurement and testing parameter
Date: Tue, 20 Apr 1999 13:38:04 +0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks for your help.

By the way, is there anyone who have the standard test methodology either it
was release by IETF or other standard body or proprietary by vendor ? Please
share with me.

Regards,

Henri S

----- Original Message -----
From: Perry Erick Renaldo <equest@indosat.net.id>
To: IPtel Forum <iptel@lists.research.bell-labs.com>
Sent: Tuesday, April 20, 1999 1401
Subject: Re: Measurement and testing parameter


> Henry,
> If you want to test data-net product in order to get a clearer view on
> its performance you might need a standard test methodology. Robert
> Mandeville has developed a standard test methodology and approved by the
> IETF under the spell of RFC 2285. Might be a help.
>
>
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 05:58:42 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03626
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 05:58:42 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 044D252B7; Tue, 20 Apr 1999 05:53:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6BB4152C3; Tue, 20 Apr 1999 05:53:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <C51ED84B6F47D211917A0000F8BCBD11011AA851@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Henri Setiawan <henry@risti.telkom.co.id>,
        Perry Erick Renaldo <equest@indosat.net.id>,
        IPtel Forum <iptel@lists.research.bell-labs.com>
Subject: RE: Measurement and testing parameter
Date: Tue, 20 Apr 1999 04:51:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

ITU-T Study Group 12 are the experts on this stuff.  For further
information, have a look at
http://www.itu.int/itudoc/itu-t/com12/index.html

> -----Original Message-----
> From:	Henri Setiawan [SMTP:henry@risti.telkom.co.id]
> Sent:	Tuesday, April 20, 1999 2:38 AM
> To:	Perry Erick Renaldo; IPtel Forum
> Subject:	Re: Measurement and testing parameter
> 
> Thanks for your help.
> 
> By the way, is there anyone who have the standard test methodology either
> it
> was release by IETF or other standard body or proprietary by vendor ?
> Please
> share with me.
> 
> Regards,
> 
> Henri S
> 
> ----- Original Message -----
> From: Perry Erick Renaldo <equest@indosat.net.id>
> To: IPtel Forum <iptel@lists.research.bell-labs.com>
> Sent: Tuesday, April 20, 1999 1401
> Subject: Re: Measurement and testing parameter
> 
> 
> > Henry,
> > If you want to test data-net product in order to get a clearer view on
> > its performance you might need a standard test methodology. Robert
> > Mandeville has developed a standard test methodology and approved by the
> > IETF under the spell of RFC 2285. Might be a help.
> >
> >
> >
> > ---------
> > This message came from the IETF IPTEL Working Group Mailing List.
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 16:39:02 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18016
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 16:39:02 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 77DB852C5; Tue, 20 Apr 1999 16:31:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D1E9952C7; Tue, 20 Apr 1999 16:31:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.5.32.19990420130905.01b429c0@stardust.com>
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 20 Apr 1999 13:09:05 -0700
To: iptel@lists.research.bell-labs.com
From: Marty Bickford <martinb@stardust.com>
Subject: Education/Research Passes to iBAND2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hello Everyone,

Stardust Forums is giving away a number of education and research passes to
iBAND2. This technical conference is focused on Quality of Service-based
Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered
QoS & IP Multicast, Billing for Premium Services, & more

If you fit this category, simply drop me some email. Of course, if you do
work for an ISP, enterprise or vendor....you're invited too.

Below are some of the highlights of iBAND2.

Sincerely,
Marty Bickford
Conference Director

-----------------------------------------------------------------

iBAND2 - The Internet Bandwidth Management Summit
May 23-25, 1999 in San Francisco, California
http://www.stardust.com/iband2/

-----------------------------------------------------------------

iBAND2 is a one-of-a-kind technical conference where attendees are immersed
in the new Internet bandwidth technologies around the clock. It is your
chance to explore the latest about smart bandwidth--it's not just about
speed. Learn about the new bandwidth management technologies, deployment
strategies, and business opportunities. Share the latest in-depth
information not available anywhere else.

If you are responsible for managing and growing network bandwidth, head for
iBAND2. Explore ideas, insights and experiences with peers, partners and
experts. Hear from the best and brightest minds in the Internet space.

A must attend event for IP Network Professionals in enterprise, ISPs, and
carrier organizations. Are you an enterprise executive looking to harness
your network? Are you a network professional examining the future of your
network? Are you a service provider looking to sell additional services and
not just bandwidth?

Discover how you can make and save money by offering new business services.
Join us at iBAND2.

    Scroll down for details or click on a link.

TECHNOLOGIES COVERED & WHITE PAPER
    http://www.stardust.com/iband2/tech_resources.htm

QUALITY OF SERVICE (QoS) NETWORK SHOWCASE
    http://www.stardust.com/iband2/qos-showcase.htm

FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS
    http://www.stardust.com/iband2/diamond.htm

LEADING INTERNET TECHNOLOGISTS AT iBAND2 & THE AGENDA
    http://www.stardust.com/iband2/sessions.htm

REGISTER TODAY & SAVE
    https://www.stardust.com/events/iband2/registration.htm



TECHNOLOGIES COVERED & THE INTERNET BANDWIDTH
MANAGEMENT WHITE PAPER
--------------------------
iBAND2 is a one-of-a-kind technical and educational event, exploring the
latest about smart bandwidth-- its not just about speed. Learn about the
new bandwidth management technologies, deployment strategies, and business
opportunities. Share the latest in-depth information not available anywhere
else. Explore ideas with peers, partners and experts.

Hot topics:
* QoS, IP Multicast, DIFFSERV, RSVP, Policy, COPS, Directory
    Standards and Schema
* Quality of Service-based Traffic Management, Measuring &
    Monitoring Traffic, Interdomain & Peered QoS & IP Multicast,
    Billing for Premium Services
* Traffic prioritization, Voice over IP, SLA's, VPN's, Call Centers.
    Streaming Media, and more.

Internet Bandwidth Management White Paper:
Technologies, applications and business opportunities are the focus of an
up-to-date 24 page white paper produced for iBAND. Download it today for
free: http://www.stardust.com/iband2/whitepaper.hm


QUALITY OF SERVICE (QoS) NETWORK SHOWCASE
-----------------------------------------
15 vendors are collaborating to build an end-to-end QoS Network. Attendees
will experience the benefits and comparisons between applications with QoS
enabled and disabled in a saturated network environment.  Discuss the
options and capabilities with the engineers who designed and built this
extensive network.  View policy management, directory services, traffic
management and monitoring and more.

http://www.stardust.com/iband2/qos-showcase.htm

Participating companies include: 3Com, Cisco, Extreme, IPHighway, IPivot,
Lucent, Microsoft, IBM, Intel, Novell, Orchestream, Qosnetics, Xedia,
Netcom Systems, Nortel, and more.


FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS
-----------------------------------------
We know you can't attend more than one session at a time. In addition to
receiving all materials electronically, Diamond Attendees receive a FREE
Portable Conference Player (MP3 Player). We'll also include conference
sessions from iBAND98 and MCAST99.

http://www.stardust.com/iband2/diamond.htm


THE LEADERS & THEIR SESSIONS
----------------------------------------------
Who will be there? Leading Internet technologists from the IETF, vendor and
service providers.

Our keynote:
Scott Bradner of Harvard University.
Mr. Bradner is the co director of the Transport Area in the IETF, is a
member of the IESG, and an elected trustee of the Internet Society where he
serves as the Vice President for Standards. He was also co director of the
IETF IP next generation effort and is coeditor of "IPng: Internet Protocol
Next Generation" from Addison-Wesley.

Other distinguished presenters include:
* Radia Perlman, Sun Microsystems
* Shai Herzog, IPHighway
* Bob Quinn, Stardust Forums
* Winston Bumpus, Novell & DMTF
* Benjamin Teitelbaum, Internet2
* Hal Sandick, Nortel
* Yoram Bernet, Microsoft
* Vasilis Theoharakis, 3Com
* Rod Murchison, Newbridge
* Ashley Stephenson, Xedia Corporation
* Ed Perry, Hewlett-Packard
* Charlie Muirhead, Orchestream
* Mark Fishburn, NetCom Systems
* Doug Sherman, 3Com
* Adam Dunstan, Avici Systems
* Tom Clarkson, IPivot
* Jude O'Reilly, Aventail
* Jeff Young, Cable & Wireless
* Vijay Srinivasan, Torrent Networking Technologies
* J. Christopher Landes, Lucent
* and of course...many more.

Click here for more details about the technical conference
http://www.stardust.com/iband2/sessions.htm


REGISTER
----------------------------------------------
ACT FAST.  Sign up before April 23rd and save $200
http://www.stardust.com/iband2/

Nortel Networksis the Platinum Sponsor, IP Multicast Initiative & the
Quality of Service Forum are Alliance Sponsors, and America's Network, Data
Communications, InternetWeek and tele.com are Publication Sponsors of iBAND2.

Contact Stardust Forums at (408)879-8080 with any questions regarding iBAND2.

See you there.
---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust Forums - http://www.stardust.com

iBAND2(sm) - The Internet Bandwidth Management Summit

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 23:04:03 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23757
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 23:04:03 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id CD0F852CC; Tue, 20 Apr 1999 22:57:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4882952CD; Tue, 20 Apr 1999 22:57:16 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: "Eric Ho" <eho@fore.com>
To: "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
Cc: "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
Subject: H.323 with ATM
Date: Wed, 21 Apr 1999 10:53:30 +0800
Message-ID: <000001be8ba2$231ba650$0f2d90a9@eho-laptop.fore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <371D3C02.40DE9000@dnrc.bell-labs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.fore.com id WAA13374
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23757

Hi,

Could anyone please advise how VoIP is going to run over ATM
(i.e., what kind of encapsulation or native ATM)?

Thanks in advance!

eh


 

=====================================================================
Eric Ho                                         Direct: +852-27222766
FORE Systems, Inc.                                Main: +852-27222722




---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 20 23:46:03 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24437
	for <iptel-archive@odin.ietf.org>; Tue, 20 Apr 1999 23:46:02 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3425252C7; Tue, 20 Apr 1999 22:46:46 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 88B2C52CC; Tue, 20 Apr 1999 22:46:45 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <371D3C02.40DE9000@dnrc.bell-labs.com>
Date: Tue, 20 Apr 1999 22:46:26 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Organization: Bell Laboratories
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Matt Squire <msquire@nortelnetworks.com>
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: Evaluation of Gateway Location proposals
References: <3.0.32.19990408121635.00881600@bl-mail1.corpeast.baynetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Matt Squire wrote:
> 
> I'm already sorry for the length of this message, but I had to
> respond...
> 
> So here are my comments on your comparison.  Not surprisingly, I have a
> different view on several important aspects.

Let me summarize here:

1. I think we all agree that attributes will need to be treated, one at
a time, thought out, and specified, for GLP. The difference between
Matt's and Hussein's approach is one of direction - starting with BGP
and modifying, or taking a more fresh approach. In the end, it doesn't
really matter. So, for this thread, lets focus on things not having to
do with attributes (which includes AS_PATH, MED, NEXT_HOP, etc.)

2. Matt raised numerous transport issues (TCP or not TCP). I think its
fair to say we want to avoid designing a new transport protocol. There
is work underway elsewhere (sigtran and slums) to do this, which we can
leverage. It would seem to me that if something new is needed, this
would also be independent of whether the protocol baseline is BGP or
SCSP, since presumably one could use this new transport protocol with
either.

3. To me, the MAIN differences between a BGP based approach and SCSP
based approach are:
  a. how the data is synchronized between peers
  b. the intra-domain topology

I think we are clear on (b), so (a) is the issue to explore. Hussein had
made reference to a 2-stage exchange only being needed with BGP, while
its three with SCSP. These are the kind of differences I think we need
to explore here. I'd invite both authors to comment on the differences
in how the data is exchanged and updated between peers. Lets stick with
inter-domain for the moment...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 07:18:30 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03262
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 07:18:29 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id EFDF552CD; Wed, 21 Apr 1999 07:13:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6606D52CF; Wed, 21 Apr 1999 07:13:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
X-Mailer: exmh version 2.0.2
To: Eric Ho <eho@fore.com>
Cc: iptel@lists.research.bell-labs.com
Subject: Re: H.323 with ATM
In-reply-to: Your message of "Wed, 21 Apr 1999 10:53:30 +0800." <000001be8ba2$231ba650$0f2d90a9@eho-laptop.fore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 Apr 1999 12:11:09 +0100
Message-ID: <6555.924693069@cs.ucl.ac.uk>
From: Nadia KAUSAR <N.Kausar@cs.ucl.ac.uk>
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi

I believe some people in a company called INESC are looking at various aspects 
of H.323 conferencing over ATM.  also if it is H.323 conferencing and ATM 
issues you are interested in may be h323implementors@imtc.org  will be a 
better mailing list?

thanks
Nadia



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 08:32:37 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03984
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 08:32:36 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id A31A552CE; Wed, 21 Apr 1999 08:27:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0D78E52D1; Wed, 21 Apr 1999 08:27:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: gregboop@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Eric Ho" <eho@fore.com>
Cc: "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
Message-ID: <8525675A.004453F1.00@d54mta03.raleigh.ibm.com>
Date: Wed, 21 Apr 1999 08:26:16 -0400
Subject: Re: H.323 with ATM
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk



For VoIP using H.323; Annex C of the H.323 specification
describes how to implement VoIP for ATM. A better mailing
list  to discuss H.323 however will be h323implementors@imtc.org.

Best Regards,

- Greg Boop
   Mgr - VoIP Development
   IBM NHD
   RTP, NC, USA
   +1 919 254 0319
    gregboop@us.ibm.com



"Eric Ho" <eho@fore.com> on 04/20/99 10:53:30 PM

To:   "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com>
cc:   "IPTEL IETF Mailing List" <iptel@lists.research.bell-labs.com> (bcc:
      Gregory Boop/Raleigh/IBM)
Subject:  H.323 with ATM





Hi,

Could anyone please advise how VoIP is going to run over ATM
(i.e., what kind of encapsulation or native ATM)?

Thanks in advance!

eh




=====================================================================
Eric Ho                                         Direct: +852-27222766
FORE Systems, Inc.                                Main: +852-27222722




---------
This message came from the IETF IPTEL Working Group Mailing List.




---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 10:18:55 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07139
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 10:18:55 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 0616C52D1; Wed, 21 Apr 1999 10:11:25 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4D0A552D4; Wed, 21 Apr 1999 10:11:24 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990421141140.16996.rocketmail@web114.yahoomail.com>
Date: Wed, 21 Apr 1999 07:11:40 -0700 (PDT)
From: Abhishek Singh <arsingh@yahoo.com>
Subject: Re: H.323 with ATM
To: Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi Eric,

There is work going on in the ATM Forum and it is
called RMOA(realtime multimedia over ATM). Seems
pretty good way for H.323 transport over ATM. Not
aware of SIP efforts though.

cheers
Abhishek

--- Eric Ho <eho@fore.com> wrote:
> Hi,
> 
> Could anyone please advise how VoIP is going to run
> over ATM
> (i.e., what kind of encapsulation or native ATM)?
> 
> Thanks in advance!
> 
> eh
> 
> 
>  
> 
>
=====================================================================
> Eric Ho                                        
> Direct: +852-27222766
> FORE Systems, Inc.                               
> Main: +852-27222722
> 
> 
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group
> Mailing List.
> 

===
Go to 
http://abhishekrs.eCode.com 
to pick up my online Business Card.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 10:35:42 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07584
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 10:35:42 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 608D652D3; Wed, 21 Apr 1999 10:19:21 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B999A52D4; Wed, 21 Apr 1999 10:19:20 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <371DDE44.CBB66640@cs.columbia.edu>
Date: Wed, 21 Apr 1999 10:18:44 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Abhishek Singh <arsingh@yahoo.com>
Cc: Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: H.323 with ATM
References: <19990421141140.16996.rocketmail@web114.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Abhishek Singh wrote:
> 
> Hi Eric,
> 
> There is work going on in the ATM Forum and it is
> called RMOA(realtime multimedia over ATM). Seems
> pretty good way for H.323 transport over ATM. Not
> aware of SIP efforts though.
> 
This topis doesn't really belong here, but to answer the question:

There is no particular need to specify how SIP works with ATM, as it
works just fine either with ATM transport for media or for sending SIP
across (say) AAL5. The only minor item to be settled is how to represent
ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that
problem.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 11:16:54 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08748
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 11:16:53 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3F1A152CF; Wed, 21 Apr 1999 11:11:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 992A752D6; Wed, 21 Apr 1999 11:11:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990421151314.4011.rocketmail@web129.yahoomail.com>
Date: Wed, 21 Apr 1999 08:13:14 -0700 (PDT)
From: Abhishek Singh <arsingh@yahoo.com>
Subject: Re: H.323 with ATM
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi Henning,

RMOA is rather revolutiory. I know SIP would work over
any damn thing, but so would H.323. But the beauty of
RMOA work is that instead of using RTP/UDP/IP over ATM
in an unintelligent way it does use the QOS feautures
of ATM rather than using RTP. At the same time it also
carries the RTP/UDP/IP headers(compressed) to ensure
interoperability with non ATM networks(ie translating
it back at the egress). They use something called Real
Time AAL5. The same concept could be extended to SIP
without much(any) effort. Wonder if anybody is doing
that.

cheers
Abhishek

--- Henning Schulzrinne <schulzrinne@cs.columbia.edu>
wrote:
> Abhishek Singh wrote:
> > 
> > Hi Eric,
> > 
> > There is work going on in the ATM Forum and it is
> > called RMOA(realtime multimedia over ATM). Seems
> > pretty good way for H.323 transport over ATM. Not
> > aware of SIP efforts though.
> > 
> This topis doesn't really belong here, but to answer
> the question:
> 
> There is no particular need to specify how SIP works
> with ATM, as it
> works just fine either with ATM transport for media
> or for sending SIP
> across (say) AAL5. The only minor item to be settled
> is how to represent
> ATM addresses in SDP. Presumably, H.332-for-ATM will
> have to solve that
> problem.
> 
> 
> -- 
> Henning Schulzrinne  
> http://www.cs.columbia.edu/~hgs
> 
> ---------
> This message came from the IETF IPTEL Working Group
> Mailing List.
> 

===
Go to 
http://abhishekrs.eCode.com 
to pick up my online Business Card.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 12:06:05 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10038
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 12:06:04 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 7FBF452D5; Wed, 21 Apr 1999 10:11:35 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D6F1552D3; Wed, 21 Apr 1999 10:11:28 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990421141140.16996.rocketmail@web114.yahoomail.com>
Date: Wed, 21 Apr 1999 07:11:40 -0700 (PDT)
From: Abhishek Singh <arsingh@yahoo.com>
Subject: Re: H.323 with ATM
To: Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Hi Eric,

There is work going on in the ATM Forum and it is
called RMOA(realtime multimedia over ATM). Seems
pretty good way for H.323 transport over ATM. Not
aware of SIP efforts though.

cheers
Abhishek

--- Eric Ho <eho@fore.com> wrote:
> Hi,
> 
> Could anyone please advise how VoIP is going to run
> over ATM
> (i.e., what kind of encapsulation or native ATM)?
> 
> Thanks in advance!
> 
> eh
> 
> 
>  
> 
>
=====================================================================
> Eric Ho                                        
> Direct: +852-27222766
> FORE Systems, Inc.                               
> Main: +852-27222722
> 
> 
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group
> Mailing List.
> 

===
Go to 
http://abhishekrs.eCode.com 
to pick up my online Business Card.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 12:30:36 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10701
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 12:30:35 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 961F152D4; Wed, 21 Apr 1999 12:23:25 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D663052D7; Wed, 21 Apr 1999 12:23:24 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Cc: Abhishek Singh <arsingh@yahoo.com>, Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Message-ID: <371DFA05.E4037B20@lucent.com>
Date: Wed, 21 Apr 1999 11:17:09 -0500
From: "ronald h. davis" <ronaldd@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.05 [en]C-EMS-1.4  (WinNT; U)
MIME-Version: 1.0
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Original-CC: Abhishek Singh <arsingh@yahoo.com>, Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: H.323 with ATM
References: <19990421141140.16996.rocketmail@web114.yahoomail.com> <371DDE44.CBB66640@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henning Schulzrinne wrote:
> 
> There is no particular need to specify how SIP works with ATM, as it
> works just fine either with ATM transport for media or for sending SIP
> across (say) AAL5. The only minor item to be settled is how to represent
> ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that
> problem.
> 

the simple answer to h.323 over atm is to say that any ip over atm
mechanism can be used (classical ip over atm, mpoa, &c.).  in this
way, atm is invisible to h.323.  however, annex c of h.323 goes further
to define a method of carrying media channels directly over atm without
the udp/ip overhead (i.e. rtp over aal 5).

maybe you could fill us in, but i'm going to assume that there is no
such specification for sip and therefore sip over atm uses ip over atm
methods.

--
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       ronald.h.davis@lucent.com
author of "atm for public networks" published by mcgraw-hill
     http://www.amazon.com/exec/obidos/ASIN/0071344764

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 13:02:30 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11860
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 13:02:30 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 1F74D52D7; Wed, 21 Apr 1999 12:57:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 76B2D52D8; Wed, 21 Apr 1999 12:57:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <371E0304.4968B3CE@cs.columbia.edu>
Date: Wed, 21 Apr 1999 12:55:32 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "ronald h. davis" <ronaldd@lucent.com>
Cc: Abhishek Singh <arsingh@yahoo.com>, Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>,
        mmusic@isi.edu
Subject: Re: H.323 with ATM
References: <19990421141140.16996.rocketmail@web114.yahoomail.com> <371DDE44.CBB66640@cs.columbia.edu> <371DFA05.E4037B20@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

"ronald h. davis" wrote:
> 
> Henning Schulzrinne wrote:
> >
> > There is no particular need to specify how SIP works with ATM, as it
> > works just fine either with ATM transport for media or for sending SIP
> > across (say) AAL5. The only minor item to be settled is how to represent
> > ATM addresses in SDP. Presumably, H.332-for-ATM will have to solve that
> > problem.
> >
> 
> the simple answer to h.323 over atm is to say that any ip over atm
> mechanism can be used (classical ip over atm, mpoa, &c.).  in this
> way, atm is invisible to h.323.  however, annex c of h.323 goes further
> to define a method of carrying media channels directly over atm without
> the udp/ip overhead (i.e. rtp over aal 5).
> 
> maybe you could fill us in, but i'm going to assume that there is no
> such specification for sip and therefore sip over atm uses ip over atm
> methods.

That is incorrect. As discussed in more technical detail in the SIP FAQ
or various papers, SIP as a *signaling* protocol runs over any
packet-based medium (or indeed, any digital bit stream), even without
the presence of IP or UDP. As a protocol, it also doesn't care whether
the media streams use IP, ATM, or PSTN (see the PINT WG for details).
Thus, one possible approach is to run SIP over UDP/IP and voice over
ATM, as that avoids having to set up a VC just for signaling.

You'll run into timeout problems, but you could send SIP by carrier
pigeon, bottle mail, Tanenbaum's tape-in-station-wagon transport
protocol or FedEx.

Since SIP does not depend on RTP (it does not specify a complete
application scenario as H.323 does), it could just as easily set up on
RMOA connection across ATM, with the caveat of SDP naming conventions
being needed.

This should really move to mmusic...
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Wed Apr 21 19:05:59 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27862
	for <iptel-archive@odin.ietf.org>; Wed, 21 Apr 1999 19:05:59 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 3FC4C52D6; Wed, 21 Apr 1999 17:08:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 944B652D9; Wed, 21 Apr 1999 17:08:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <371E3DA7.7A52475C@dnrc.bell-labs.com>
Date: Wed, 21 Apr 1999 17:05:43 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Abhishek Singh <arsingh@yahoo.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: Re: H.323 with ATM
References: <19990421151314.4011.rocketmail@web129.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Abhishek Singh wrote:
> 
> Hi Henning,
> 
> RMOA is rather revolutiory. I know SIP would work over
> any damn thing, but so would H.323. But the beauty of
> RMOA work is that instead of using RTP/UDP/IP over ATM
> in an unintelligent way it does use the QOS feautures
> of ATM rather than using RTP.

Rather than using RTP?? RTP doesn't provide QoS... There is nothing
which prevents you from taking an RTP packet at an ATM boundary,
extracting it, and sending it over an ATM VC that has some QoS
associated with it (CBR or something), RTP in tact. Whether or not you
compress RTP is a separate issue.

Of course, this poor edge box now has to do some application level
processing instead of being a pure layer 3/2 device. Any end to end
security will make it impossible for the box to find the RTP packets as
well. It seems like it would be easier to stay at layer 3, and establish
VC's based on RSVP or diffserv, or something like that... but thats a
separate issue.

-Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 22 05:38:16 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10724
	for <iptel-archive@odin.ietf.org>; Thu, 22 Apr 1999 05:38:16 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 8427452C3; Thu, 22 Apr 1999 05:31:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E394B52D9; Thu, 22 Apr 1999 05:31:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <99Apr23.002657idt.113796@firewall.radvision.rad.co.il>
From: Ami Amir <amir@radvision.rad.co.il>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Abhishek Singh <arsingh@yahoo.com>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: H.323 with ATM
Date: Thu, 22 Apr 1999 12:28:06 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

Am I just butting in?

H.323 Annex C is all about how to run H.323 over ATM. 

FYI

Ami

	-----Original Message-----
	From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
	Sent:	Thursday, April 22, 1999 12:06 AM
	To:	Abhishek Singh
	Cc:	Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List
	Subject:	Re: H.323 with ATM

	Abhishek Singh wrote:
	> 
	> Hi Henning,
	> 
	> RMOA is rather revolutiory. I know SIP would work over
	> any damn thing, but so would H.323. But the beauty of
	> RMOA work is that instead of using RTP/UDP/IP over ATM
	> in an unintelligent way it does use the QOS feautures
	> of ATM rather than using RTP.

	Rather than using RTP?? RTP doesn't provide QoS... There is nothing
	which prevents you from taking an RTP packet at an ATM boundary,
	extracting it, and sending it over an ATM VC that has some QoS
	associated with it (CBR or something), RTP in tact. Whether or not
you
	compress RTP is a separate issue.

	Of course, this poor edge box now has to do some application level
	processing instead of being a pure layer 3/2 device. Any end to end
	security will make it impossible for the box to find the RTP packets
as
	well. It seems like it would be easier to stay at layer 3, and
establish
	VC's based on RSVP or diffserv, or something like that... but thats
a
	separate issue.

	-Jonathan R.



	-- 
	Jonathan D. Rosenberg                       Lucent Technologies
	Member of Technical Staff                   101 Crawfords Corner Rd.
	High Speed Networks Research                Holmdel, NJ 07733
	FAX:   (732) 834-5379                       Rm. 4C-526
	EMAIL: jdrosen@bell-labs.com
	URL: http://www.cs.columbia.edu/~jdrosen

	---------
	This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 22 08:33:04 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12738
	for <iptel-archive@odin.ietf.org>; Thu, 22 Apr 1999 08:33:04 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 26E6052DB; Thu, 22 Apr 1999 08:27:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 78C1852DD; Thu, 22 Apr 1999 08:27:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Date: Thu, 22 Apr 1999 10:03:31 -0400 (EDT)
From: "Francois D. Menard" <fm-listproc@uyquist.fmmo.ca>
To: Ami Amir <amir@radvision.rad.co.il>
Cc: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
        Abhishek Singh <arsingh@yahoo.com>,
        Henning Schulzrinne <schulzrinne@cs.columbia.edu>,
        Eric Ho <eho@fore.com>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: H.323 with ATM
In-Reply-To: <99Apr23.002657idt.113796@firewall.radvision.rad.co.il>
Message-ID: <Pine.LNX.3.95.990422100255.20667C-100000@uyquist.fmmo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


How does that align with the ATM Forum document written by Francois Audet
of Nortel ?

-=Francois=-

On Thu, 22 Apr 1999, Ami Amir wrote:

> Am I just butting in?
> 
> H.323 Annex C is all about how to run H.323 over ATM. 
> 
> FYI
> 
> Ami
> 
> 	-----Original Message-----
> 	From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> 	Sent:	Thursday, April 22, 1999 12:06 AM
> 	To:	Abhishek Singh
> 	Cc:	Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List
> 	Subject:	Re: H.323 with ATM
> 
> 	Abhishek Singh wrote:
> 	> 
> 	> Hi Henning,
> 	> 
> 	> RMOA is rather revolutiory. I know SIP would work over
> 	> any damn thing, but so would H.323. But the beauty of
> 	> RMOA work is that instead of using RTP/UDP/IP over ATM
> 	> in an unintelligent way it does use the QOS feautures
> 	> of ATM rather than using RTP.
> 
> 	Rather than using RTP?? RTP doesn't provide QoS... There is nothing
> 	which prevents you from taking an RTP packet at an ATM boundary,
> 	extracting it, and sending it over an ATM VC that has some QoS
> 	associated with it (CBR or something), RTP in tact. Whether or not
> you
> 	compress RTP is a separate issue.
> 
> 	Of course, this poor edge box now has to do some application level
> 	processing instead of being a pure layer 3/2 device. Any end to end
> 	security will make it impossible for the box to find the RTP packets
> as
> 	well. It seems like it would be easier to stay at layer 3, and
> establish
> 	VC's based on RSVP or diffserv, or something like that... but thats
> a
> 	separate issue.
> 
> 	-Jonathan R.
> 
> 
> 
> 	-- 
> 	Jonathan D. Rosenberg                       Lucent Technologies
> 	Member of Technical Staff                   101 Crawfords Corner Rd.
> 	High Speed Networks Research                Holmdel, NJ 07733
> 	FAX:   (732) 834-5379                       Rm. 4C-526
> 	EMAIL: jdrosen@bell-labs.com
> 	URL: http://www.cs.columbia.edu/~jdrosen
> 
> 	---------
> 	This message came from the IETF IPTEL Working Group Mailing List.
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
> 


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 22 16:33:45 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28589
	for <iptel-archive@odin.ietf.org>; Thu, 22 Apr 1999 16:33:42 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 32F3552DE; Thu, 22 Apr 1999 16:27:31 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 82F3D52DF; Thu, 22 Apr 1999 16:27:30 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
Cc: "Mo Zonoun" <mzonoun@nortelnetworks.com>
Subject: RE: H.323 with ATM
Date: Thu, 22 Apr 1999 15:25:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28589

The RMOA "Gateway for H.323 Media Transport Over ATM" is essentially a 
finished document now and needs only to go throught the final ballot.

H.323 Annex C assumes ATM end-to-end. The ATM Forum document focuses more
on the case where the edges are not ATM. The intention is that ITU-T 
H.323v3 incorporates the ATM Forum's specification.

In Annex C, the terminals themselves are ATM aware, so setting up SVCs
is easier. In the ATM Forum's specification, it is a bit more difficult to
figure out when to setup the SVCs, and how to used them bi-directionnaly.

What Jonathan said is absolutely true.

There is basically two parts to the spec: one dealing with how to set-up
SVCs based on H.245/H.225.0 information, and the other on RTP header 
compression transported over AAL5 (the compression mechanism is derived
from RTP/UDP/IP compression over PPP).

(I would have preferred to have the document splitted in two)

These two parts are distinct: the compession part could be used with other
protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger, 
well, I guess it needs more thinking. I guess it also depends on the
philosophy of what you want to do: do you need an explicit association
between the SVC and the "call/connection" at the H.225.0/H.245 or not?

-----
François Audet  Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com
Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com 



> -----Original Message-----
> From: Francois D. Menard [mailto:fm-listproc@uyquist.fmmo.ca] 
> Sent: Thursday, April 22, 1999 7:04 AM
> To: Ami Amir
> Cc: Jonathan Rosenberg; Abhishek Singh; Henning Schulzrinne; Eric Ho;
> IPTEL IETF Mailing List
> Subject: RE: H.323 with ATM
> 
> 
> 
> How does that align with the ATM Forum document written by 
> Francois Audet
> of Nortel ?
> 
> -=Francois=-
> 
> On Thu, 22 Apr 1999, Ami Amir wrote:
> 
> > Am I just butting in?
> > 
> > H.323 Annex C is all about how to run H.323 over ATM. 
> > 
> > FYI
> > 
> > Ami
> > 
> > 	-----Original Message-----
> > 	From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
> > 	Sent:	Thursday, April 22, 1999 12:06 AM
> > 	To:	Abhishek Singh
> > 	Cc:	Henning Schulzrinne; Eric Ho; IPTEL IETF Mailing List
> > 	Subject:	Re: H.323 with ATM
> > 
> > 	Abhishek Singh wrote:
> > 	> 
> > 	> Hi Henning,
> > 	> 
> > 	> RMOA is rather revolutiory. I know SIP would work over
> > 	> any damn thing, but so would H.323. But the beauty of
> > 	> RMOA work is that instead of using RTP/UDP/IP over ATM
> > 	> in an unintelligent way it does use the QOS feautures
> > 	> of ATM rather than using RTP.
> > 
> > 	Rather than using RTP?? RTP doesn't provide QoS... 
> There is nothing
> > 	which prevents you from taking an RTP packet at an ATM boundary,
> > 	extracting it, and sending it over an ATM VC that has some QoS
> > 	associated with it (CBR or something), RTP in tact. 
> Whether or not
> > you
> > 	compress RTP is a separate issue.
> > 
> > 	Of course, this poor edge box now has to do some 
> application level
> > 	processing instead of being a pure layer 3/2 device. 
> Any end to end
> > 	security will make it impossible for the box to find 
> the RTP packets
> > as
> > 	well. It seems like it would be easier to stay at layer 3, and
> > establish
> > 	VC's based on RSVP or diffserv, or something like 
> that... but thats
> > a
> > 	separate issue.

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 23 09:06:12 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15453
	for <iptel-archive@odin.ietf.org>; Fri, 23 Apr 1999 09:06:11 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 56A3E52CA; Fri, 23 Apr 1999 09:00:13 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C0E0D52D2; Fri, 23 Apr 1999 09:00:12 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Cc: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        Mo Zonoun <mzonoun@nortelnetworks.com>
Message-ID: <37206D2B.C63083DD@lucent.com>
Date: Fri, 23 Apr 1999 07:52:59 -0500
From: "ronald h. davis" <ronaldd@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.05 [en]C-EMS-1.4  (WinNT; U)
MIME-Version: 1.0
To: Francois Audet <audet@nortelnetworks.com>
Original-CC: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        Mo Zonoun <mzonoun@nortelnetworks.com>
Subject: Re: H.323 with ATM
References: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois Audet wrote:
> 
> The RMOA "Gateway for H.323 Media Transport Over ATM" is essentially a
> finished document now and needs only to go throught the final ballot.
> 
> H.323 Annex C assumes ATM end-to-end. The ATM Forum document focuses more
> on the case where the edges are not ATM. The intention is that ITU-T
> H.323v3 incorporates the ATM Forum's specification.
> 

but from h.323 and h.323 annex c you can derive the same case as is
described in the atm forum document.  as i read the document, the c/d 
effectively implements the gatekeeper routed model for h.225/h.245 
channels.


> These two parts are distinct: the compession part could be used with other
> protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger,
> well, I guess it needs more thinking. I guess it also depends on the
> philosophy of what you want to do: do you need an explicit association
> between the SVC and the "call/connection" at the H.225.0/H.245 or not?
> 

i'm a bit confused about the question but i would say that the
answer is most definitely; if you're going to split call control
signalling and bearer connection control signalling, then you need
some means of correlating the two.  i don't think this was the issue
that jonathan had in mind but i say this because in the version of
the atm forum contribution that i have, there was no mention of use
of the broadband high layer information element or generic identifier
transport information element to do this correlation.  let me qualify
this by saying that my copy is from october...

as far as using rsvp or diffserv as a trigger for svc establishment,
i would think that you would want to be able to do that as well if
the intent is to have some means of providing end-to-end qos across
atm and ip network boundaries.  but this is the case of doing ip over
atm which annex c sought to avoid.  the annex c approach does get into
application layer processing at the interworking node as jonathan
mentioned, but you save the ip overhead.  there is an internet draft by 
garrett, et. al. which describes the interworking of controlled load 
service and guaranteed service with atm.

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       ronald.h.davis@lucent.com
author of "atm for public networks" published by mcgraw-hill
     http://www.amazon.com/exec/obidos/ASIN/0071344764

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 23 10:15:41 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17913
	for <iptel-archive@odin.ietf.org>; Fri, 23 Apr 1999 10:15:40 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 4DB5952C6; Fri, 23 Apr 1999 10:07:50 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id AF06152C8; Fri, 23 Apr 1999 10:07:49 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <37207E0F.159BF0B1@dnrc.bell-labs.com>
Date: Fri, 23 Apr 1999 10:05:03 -0400
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: "ronald h. davis" <ronaldd@lucent.com>
Cc: Francois Audet <audet@nortelnetworks.com>,
        "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        Mo Zonoun <mzonoun@nortelnetworks.com>
Subject: Re: H.323 with ATM
References: <63E0DAD7784FD21188310000F80824B36FC8CD@zmpkdx02.us.nortel.com> <37206D2B.C63083DD@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

ronald h. davis wrote:
> 
> > These two parts are distinct: the compession part could be used with other
> > protocols like SIP of MEGACO. As far as diffserv or RSVP as the trigger,
> > well, I guess it needs more thinking. I guess it also depends on the
> > philosophy of what you want to do: do you need an explicit association
> > between the SVC and the "call/connection" at the H.225.0/H.245 or not?
> >
> 
> i'm a bit confused about the question but i would say that the
> answer is most definitely; if you're going to split call control
> signalling and bearer connection control signalling, then you need
> some means of correlating the two. 

No, I don't think you need this explicit association. For regular IP
over ATM, its completely absent. Remember, this case here is not ATM end
to end (in which case you *would* need it), but rather IP on the
periphery, with an ATM cloud in the middle (at least, this is my
interpretation, correct me if I have completely misunderstood the model
here). When the RSVP hits the ATM cloud, it causes an SVC to be set up
(of course, RSVP and UNI signaling are in the opposite directions, but
that can be handled).  RTP packets come in, are sent through this SVC
(possibly being compressed), and then completely reproduced (IP header
and all), and the far end. They are then carried over normal IP to the
end. The recipient wouldn't even notice that there was an SVC. 

The great advantage of using RSVP or diffserv as a trigger for SVC
establishment is that is application independent. Lets not forget that
IP telephony is only one of many IP apps which will need QoS. By making
this QoS mechanism H.323 specific, you narrow the scope of the service
that can be provided (only H.323, and only the version you support),
make this edge box more complex, and in general break the end to end
model.

-Jonathan R.



-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Mon Apr 26 12:15:01 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19266
	for <iptel-archive@odin.ietf.org>; Mon, 26 Apr 1999 12:15:01 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 4ADAE52BB; Mon, 26 Apr 1999 12:09:16 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id AFCB252BF; Mon, 26 Apr 1999 12:09:15 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <63E0DAD7784FD21188310000F80824B36FC8D3@zmpkdx02.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'ronald h. davis'" <ronaldd@lucent.com>
Cc: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "Mo Zonoun" <mzonoun@nortelnetworks.com>
Subject: RE: H.323 with ATM
Date: Mon, 26 Apr 1999 11:06:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

> but from h.323 and h.323 annex c you can derive the same case as is
> described in the atm forum document.  as i read the document, the c/d 
> effectively implements the gatekeeper routed model for h.225/h.245 
> channels.

Yes. That is what we did. There are some additional complications on the
signalling side since in Annex C, the terminal "knows" when to set-up
SVCs. In the ATM Forum specification, the gateway relies on signalling
to set-up the SVCs.

The intention was not to superseed the Annex C specification, but to 
extend its application to cases involving ATM gateways, and also to add
header compression. That is the reason why it will likely be included in 
the next version of H.323 (probably as a reference).

> i'm a bit confused about the question but i would say that the
> answer is most definitely; if you're going to split call control
> signalling and bearer connection control signalling, then you need
> some means of correlating the two.  i don't think this was the issue
> that jonathan had in mind but i say this because in the version of
> the atm forum contribution that i have, there was no mention of use
> of the broadband high layer information element or generic identifier
> transport information element to do this correlation.  let me qualify
> this by saying that my copy is from october...

Final version (April) includes the GIT. The reason why the B-HLI was
not in there was because we knew from ITU-T SG11 that Annex C's use
of B-HLI was troublesome and something had to be changed.

> as far as using rsvp or diffserv as a trigger for svc establishment,
> i would think that you would want to be able to do that as well if
> the intent is to have some means of providing end-to-end qos across
> atm and ip network boundaries.  but this is the case of doing ip over
> atm which annex c sought to avoid.  the annex c approach does get into
> application layer processing at the interworking node as jonathan
> mentioned, but you save the ip overhead.  there is an 
> internet draft by 
> garrett, et. al. which describes the interworking of controlled load 
> service and guaranteed service with atm.

Agreed. There are probably cases for both approaches. This is what I
meant origninally.

---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Mon Apr 26 12:24:45 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19332
	for <iptel-archive@odin.ietf.org>; Mon, 26 Apr 1999 12:24:45 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 12BF552C2; Mon, 26 Apr 1999 12:17:33 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 549A152BF; Mon, 26 Apr 1999 12:17:31 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <63E0DAD7784FD21188310000F80824B36FC8D5@zmpkdx02.us.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dnrc.bell-labs.com>,
        "ronald h. davis" <ronaldd@lucent.com>
Cc: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>,
        "Mo Zonoun" <mzonoun@nortelnetworks.com>
Subject: RE: H.323 with ATM
Date: Mon, 26 Apr 1999 12:16:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

> No, I don't think you need this explicit association. For regular IP
> over ATM, its completely absent. Remember, this case here is 
> not ATM end
> to end (in which case you *would* need it), but rather IP on the
> periphery, with an ATM cloud in the middle (at least, this is my
> interpretation, correct me if I have completely misunderstood 
> the model
> here). When the RSVP hits the ATM cloud, it causes an SVC to be set up
> (of course, RSVP and UNI signaling are in the opposite directions, but
> that can be handled).  RTP packets come in, are sent through this SVC
> (possibly being compressed), and then completely reproduced (IP header
> and all), and the far end. They are then carried over normal IP to the
> end. The recipient wouldn't even notice that there was an SVC. 

Yes, the model is the ATM cloud in the middle, the IP networks on the edges.

> The great advantage of using RSVP or diffserv as a trigger for SVC
> establishment is that is application independent. Lets not forget that
> IP telephony is only one of many IP apps which will need QoS. 
> By making
> this QoS mechanism H.323 specific, you narrow the scope of the service
> that can be provided (only H.323, and only the version you support),
> make this edge box more complex, and in general break the end to end
> model.

We looked at using lower-layer mechanism at the beginning, but couldn't find
satisfactory methods. RSVP was felt as not being sufficiently deployed,
diffserv
didn't exist at the time.

One of the issues was how to force the connection to go through the gateway.

That being said, I would agree with you that there are probably ways to
set-up 
individual SVCs based on some lower-level protocols as you mentioned.

The H.245 method has the advantage of being very precise on what type of
connection
will be required at the SVC level. It does, however, as you note, have the 
disadvantage that the gateway has to maintain a substantial amount of
software (the
H.323 stack). As such, it would be a relatively complex device.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Tue Apr 27 19:14:06 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02419
	for <iptel-archive@odin.ietf.org>; Tue, 27 Apr 1999 19:14:05 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5E7CB52B7; Tue, 27 Apr 1999 19:09:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id ADFE752C1; Tue, 27 Apr 1999 19:09:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <19990427230803.6554.rocketmail@web105.yahoomail.com>
Date: Tue, 27 Apr 1999 16:08:02 -0700 (PDT)
From: Tom Gray <tom_gray_intp@yahoo.com>
Subject: Re: Measurement and testing parameter
To: Henri Setiawan <henry@risti.telkom.co.id>,
        IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk

MOS is a subjective measurement of speech quality. It will be assessed
for all sorts of network conditions. For the PSTN network, the most
significant impairments found were loss, noise and echo so MOS is set
for them. Other impairments have only an almost negligible effect
compared to the big 3. Jitter is accomodated by delay so I would assume
that it would fall under that parameter. There would probably have to
be measurements to understand the effects of other network and codec
impairments as well. After that is understood, relationships can be
established so that thre can be a repeatable predidctions which will
translate between network conditions and human perceived quality.

--- Henri Setiawan <henry@risti.telkom.co.id> wrote:
> Dear Tom,
> 
> Thank you for your respon regarding my question on
> measurement and testing
> parameter, on my understanding tha MOS is not the
> only parameter to test
> VoIP products. So, what do you think about the other
> parameter ? Like delay,
> jitter, Codec or others QoS parameter ? According to
> you if we are only the
> user, what we must aware on this technology ?
> Testing the products one by
> one or just waiting until the technology is mature ?
> 
> By the way what do you think about using VoIP as
> asubstitute for to date
> exchange ? Do you have any concept on this ?
> 
> Thanks
> 
> Henri S
> 
> ----- Original Message -----
> From: Tom Gray <tom_gray_intp@yahoo.com>
> To: 'Tom Gray' <tom_gray_intp@yahoo.com>; 'Henri
> Setiawan'
> <henry@risti.telkom.co.id>; IPTEL IETF Mailing List
> <iptel@lists.research.bell-labs.com>
> Sent: Friday, April 16, 1999 2324
> Subject: RE: Measurement and testing parameter
> 
> 
> >
> >
> > It should be remembered that MOS is based on the.
> subjective opinions
> > of real people about the quality of a voice
> connection. It is therefore
> > based on their expectations of the service. With
> experience these
> > expectations tend to rise and the expectations of
> the performance of
> > teh PSTN network have risen over the years making
> MOS more stringent as
> > time goes by.
> >
> > An MOS for IP tlephony needs to be developed to
> coincde with the
> > expecations of the people who use it and the
> decision makers who will
> > buy it. It is likely that these people, given IP
> telephony's other
> > advantages, will not expect or require the same
> level of service from
> > IPTel as the PSTN. Direct use of a PSTN MOS is
> probably not predictive
> > or useful.
> >
> > Tom Gray
> >
> >
> _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at
> http://mail.yahoo.com
> >
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Thu Apr 29 14:02:47 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26795
	for <iptel-archive@odin.ietf.org>; Thu, 29 Apr 1999 14:02:46 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 5BF1A52C1; Thu, 29 Apr 1999 13:55:19 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BB74352C3; Thu, 29 Apr 1999 13:55:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-Id: <3.0.32.19990429134554.0088f100@bl-mail1.corpeast.baynetworks.com>
X-Sender: msquire@bl-mail1.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Apr 1999 13:45:55 -0400
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
From: Matt Squire <msquire@nortelnetworks.com>
Subject: Re: Evaluation of Gateway Location proposals
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk


>
>2. Matt raised numerous transport issues (TCP or not TCP). I think its
>fair to say we want to avoid designing a new transport protocol. There
>is work underway elsewhere (sigtran and slums) to do this, which we can
>leverage. It would seem to me that if something new is needed, this
>would also be independent of whether the protocol baseline is BGP or
>SCSP, since presumably one could use this new transport protocol with
>either.
>

I certainly agree that we don't want a new transport protocol.  But well
short of designing a new transport is to design reliability into our
application protocol (ie with acks, timeouts, re-transmissions, etc), just
like most other application protocols.  

>3. To me, the MAIN differences between a BGP based approach and SCSP
>based approach are:
>  a. how the data is synchronized between peers
>  b. the intra-domain topology
>
>I think we are clear on (b), so (a) is the issue to explore. Hussein had
>made reference to a 2-stage exchange only being needed with BGP, while
>its three with SCSP. These are the kind of differences I think we need
>to explore here. I'd invite both authors to comment on the differences
>in how the data is exchanged and updated between peers. Lets stick with
>inter-domain for the moment...
>

Here's a brief synopsis of the data exchanges for each alternative.  In
both cases, the exchanges are just peer-to-peer.  


BGP
***  

  BGP1) OPEN.  OPEN messages are exchanged to bring the link up.
Basically, two peers connect and send an open message to the other.  A peer
either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a
NOTIFICATION.  When your OPEN gets ack'd, the peer connection is considered
to be established (ie have bi-directional connectivity).  BGP can also
perform version negotiation and capabilities exchanges with the OPEN
messages. 
 
  BGP2) UPDATE.  Once a peer connection is established (via ack'd OPENs),
BGP peers exchange UPDATE messages.  UPDATE messages are the messages that
contain the routing information.  Each UPDATE message may contain a number
of withdrawn routes and a single feasible route.  A withdrawn route is a
route that should be removed from the peer's RIB-IN.  A withdrawn route is
defined by a address/prefix-length.  A feasible route is defined as the
NLRI (network layer reachability information, ie a list of
address/prefix-length combinations) and its attributes.   A key mandatory
attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI.
Basically, you send an UPDATE for each possible NEXT-HOP in your routing
database.  

KEEP-ALIVE messages are periodically going in the background to ensure that
the link is up.  

BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP
acknowledgment is considered sufficient.  


SCSP
****
  SCSP1) Hello.  Peers exchange Hello messages to ensure bi-directional
connectivity between peers.  This is equivalent to the BGP OPEN exchanges
but without anything like version negotiation or capabilities exchange.
Hello messages are also periodically exchanged in the background to ensure
the link us still up.  

  SCSP2) Cache Aligment.  SCSP distinguishes between the state where two
peers have had their databases synchronized and when they have not.  When a
peer connection first comes up (via Hello), the peers enter the Cache
Alignment phase where the entire databases must be exchanged.  First, there
is a negotiation to determine who is the master and slave of the peering
relationship.  Next, the peers exchange summary records with each other,
where a summary record is a short-version of the record - enough to
identify it, but doesn't have the real data.  This phase has no parallel in
BGP.  

  SCSP3) Cache State Update.  A server maintiains a list of the records
that it needs to get from its peer (the summary records in the previous
phase).  A server requests these records via a Solicit message (ie I need
the full record for these summary records).  The response to the the
request is a Update Request message containing some/all of the records.  A
server continues to send further Solicit messages for records that it has
not yet received.  A server ack's that the records have been received with
an Update Reply containing the summaries of recieved records.  The Update
Request messages are similar to the UPDATE messages of BGP.  

Acknowledgements in SCSP are done per-record (ie requests for a record are
acknowledged by sending the record, record transmissions are acknowledged
by sending a record summary in an Update Reply).  


SOME DIFFERENCES
****************

I think Hussein's "2 vs 3" stages are identified above.  SCSP has the added
stage of Cache Alignment where database summaries are exchanged.

BGP uses TCP, SCSP uses X (pick your transport).  

BGP exchanges and message formats are certainly more efficient, SCSP more
generic.  In the peer-to-peer case (ie inter-domain), some SCSP header
fields are redundant (example: reciever and sender ID).  

SCSP does per-record acks and requests, which is flexible, but can be a
pain in the ass and inefficient.  BGP UPDATE/NOTIFICATION messages are
unacknowledged and assume TCP provides reliability for the application.  

SCSP Update Requests can contain many records.  BGP UPDATEs contain a
single route (maybe multiple withdrawn routes).  

SCSP bases record identification on record summaries (source identifier,
cache 'key' for record), so to replace a record you keeep the record
summary and replace the data contents.  BGP identifies records based on the
contents (ie NLRI), so the data content is examined to determine new vs
replacement. 

BGP includes version negotiation and capabilities exchange in the peering
session establishment.  SCSP has no such concept, the function would have
to be included in the application above SCSP. 

Both use a similar keep-alive mechanism to determine peer status.  


SOME COMMENTARY
***************

My personal view is that TCP is not enough for reliable application
communications.  I haven't heard anyone else argue for or against this
position, so I'll stick with it.

In order to get application reliability from a lower layer, you need a
transport that either maintains the data or one that gives the application
control over the acks.  SLUMS is a potential transport that seems to take
the latter approach.   From the SLUMS BOF announcement, one of the in-scope
requirements is

    - ability for application to indicate "a reply is coming" versus
      "no more coming now, go ahead and ack, don't delay"

So SLUMS recognizes that apps may need to have input into the ack timing.
I don't know enough about sigtran yet to say anything.  

Another alternative is that we put reliability into GLP so that messages
(or records) get ack'd, retransmitted, timed-out, etc.  This is the
direction most other protocols have gone, and is as viable a solution as
anything else.  If we go this way, then we most likely need a "GLP Route
Reflector" spec, etc, to parallel BGP.  I don't think we can just say "we
want to use that attribute/feature of that protocol in a similar way."  The
fact that we're an incompatible protocol to BGP means that any features
that we want from BGP have to be recreated in a spec(s) for GLP.  This may
turn out to be mostly copying, or it may require some technical changes to
the underlying operation.  

I suggested SCSP because it seemed to solve our transport needs.  I
wouldn't argue that SCSP is a simple protocol.  We could build a reliable
protocol that is more efficient and less complicated than SCSP.  If SCSP
gets used for more things in the future, then the costs of its
implementation get leveraged as time passes.  I have no idea whether that
will or will not come to be.  It certainly has limited applications now.  

So SCSP may be an ugly shoe, but it looked like it fit.  I don't know
whether the cost/complexity of being one of the earlier applications of
SCSP is worth while.  I thought it might be.  I might have similar concerns
about SLUMS after it gets defined.  My crystal ball is a wee bit fuzzy at
the moment.  

But that's enough out of me.

- Matt



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 30 07:57:24 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21751
	for <iptel-archive@odin.ietf.org>; Fri, 30 Apr 1999 07:57:24 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id DF40752C5; Fri, 30 Apr 1999 06:51:18 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5261052C6; Fri, 30 Apr 1999 06:51:18 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
From: Jose Costa Requena <jose@tct.hut.fi>
Message-Id: <19990430134949jose@tct.hut.fi@default>
Date: Fri Apr 30 13:49:49 1999
Content-Type: text/plain
To: msquire@nortelnetworks.com
Subject: Re: Evaluation of Gateway Location proposals
Cc: iptel@lists.research.bell-labs.com
X-Mailer: Pronto E-Mail [ver 4.0.2.6]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

I just want to make some comments about the SCSP, because I have implemented 
it for distributed database synchronization.

The SCSP has generic messages format that could seems inefficient but in 
this way it can be used for many applications.

There are some header fields  that seem redundant like the receiver and 
sender ID in the Mandatory Common part. From the implementation point of 
view it is useful when we have to choose the right Finite State Machine 
(FSM) that has to attend the DCS from which we have received that message. 
Thus checking the Sender ID we select the FSM that is implemented as an 
idividual object and inside the FSM we can check if the Receiver ID belongs 
to the DCS list that has the FSM to know if the packet is from one server in 
the SG.

>SCSP does per-record acks and requests, which is flexible, but can be a
>pain in the ass and inefficient.  BGP UPDATE/NOTIFICATION messages are
>unacknowledged and assume TCP provides reliability for the application. 

That's right, the SCSP does a little excess of message transactions to reach 
a consistent state in the database. A good alternative is to use a TCP 
connection at the beginning just to check if the connectivity is 
bidirectional or not. Thus, when the Hello Finite machine (HFSM) transits to 
the waiting state we use UDP for the rest of transactions. The unreliability 
of the UDP is corrected with the excess of acks and requests.

Regarding the 2-stage exchange only being needed with BGP.
In the SCSP we have 3-stage, but in Cache Alignment that is the other stage 
that the SCSP performs there is performed an initially information 
alignment.It could be inefficient, but in that stage each peer exchange only 
the summaries of the total data, in this way the next stage knows exactly 
the records that are needed to be updated. Those summaries are stored in the 
CRL instead of allocating the total amount of information. 
This feature is more efficient in the case that the records are quite big, 
but I agree that it will be inefficient in the case that the summary is 
comparable to the total record that must be updated.

I hope that I have clarify some details that I have seen from the 
implementor point of view.

Best Regards.

Jose

Helsinki University of Technology
Laboratory of Telecommunications Technology
Jose Costa Requena
Research Scientist
Room: SG 227B
Tel: + 358 9 451 2475
email(internet): jose@tct.hut.fi



---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 30 14:33:27 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09716
	for <iptel-archive@odin.ietf.org>; Fri, 30 Apr 1999 14:33:26 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id F10E752C6; Fri, 30 Apr 1999 14:27:20 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5C65052C7; Fri, 30 Apr 1999 14:27:19 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <01BE934F.B76C9A80.amir@radvision.rad.co.il>
From: Ami Amir <amir@radvision.rad.co.il>
To: "'Matt Squire'" <msquire@NORTELNETWORKS.COM>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Evaluation of Gateway Location proposals
Date: Fri, 30 Apr 1999 19:59:37 +0300
Organization: RADVision
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

I am definitely NOT an expert - but one thing that should be kept in mind - 
the need to provide fault tollerance and redundancy. One cannot deploy a 
functional public phone system that deos not provide for redundancy at 
alkost every level.

Ami

-----Original Message-----
From:	Matt Squire [SMTP:msquire@NORTELNETWORKS.COM]
Sent:	Thursday, April 29, 1999 8:46 PM
To:	Jonathan Rosenberg
Cc:	IPTEL IETF Mailing List
Subject:	Re: Evaluation of Gateway Location proposals


>
>2. Matt raised numerous transport issues (TCP or not TCP). I think its
>fair to say we want to avoid designing a new transport protocol. There
>is work underway elsewhere (sigtran and slums) to do this, which we can
>leverage. It would seem to me that if something new is needed, this
>would also be independent of whether the protocol baseline is BGP or
>SCSP, since presumably one could use this new transport protocol with
>either.
>

I certainly agree that we don't want a new transport protocol.  But well
short of designing a new transport is to design reliability into our
application protocol (ie with acks, timeouts, re-transmissions, etc), just
like most other application protocols.

>3. To me, the MAIN differences between a BGP based approach and SCSP
>based approach are:
>  a. how the data is synchronized between peers
>  b. the intra-domain topology
>
>I think we are clear on (b), so (a) is the issue to explore. Hussein had
>made reference to a 2-stage exchange only being needed with BGP, while
>its three with SCSP. These are the kind of differences I think we need
>to explore here. I'd invite both authors to comment on the differences
>in how the data is exchanged and updated between peers. Lets stick with
>inter-domain for the moment...
>

Here's a brief synopsis of the data exchanges for each alternative.  In
both cases, the exchanges are just peer-to-peer.


BGP
***

  BGP1) OPEN.  OPEN messages are exchanged to bring the link up.
Basically, two peers connect and send an open message to the other.  A peer
either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a
NOTIFICATION.  When your OPEN gets ack'd, the peer connection is considered
to be established (ie have bi-directional connectivity).  BGP can also
perform version negotiation and capabilities exchanges with the OPEN
messages.

  BGP2) UPDATE.  Once a peer connection is established (via ack'd OPENs),
BGP peers exchange UPDATE messages.  UPDATE messages are the messages that
contain the routing information.  Each UPDATE message may contain a number
of withdrawn routes and a single feasible route.  A withdrawn route is a
route that should be removed from the peer's RIB-IN.  A withdrawn route is
defined by a address/prefix-length.  A feasible route is defined as the
NLRI (network layer reachability information, ie a list of
address/prefix-length combinations) and its attributes.   A key mandatory
attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI.
Basically, you send an UPDATE for each possible NEXT-HOP in your routing
database.

KEEP-ALIVE messages are periodically going in the background to ensure that
the link is up.

BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP
acknowledgment is considered sufficient.


SCSP
****
  SCSP1) Hello.  Peers exchange Hello messages to ensure bi-directional
connectivity between peers.  This is equivalent to the BGP OPEN exchanges
but without anything like version negotiation or capabilities exchange.
Hello messages are also periodically exchanged in the background to ensure
the link us still up.

  SCSP2) Cache Aligment.  SCSP distinguishes between the state where two
peers have had their databases synchronized and when they have not.  When a
peer connection first comes up (via Hello), the peers enter the Cache
Alignment phase where the entire databases must be exchanged.  First, there
is a negotiation to determine who is the master and slave of the peering
relationship.  Next, the peers exchange summary records with each other,
where a summary record is a short-version of the record - enough to
identify it, but doesn't have the real data.  This phase has no parallel in
BGP.

  SCSP3) Cache State Update.  A server maintiains a list of the records
that it needs to get from its peer (the summary records in the previous
phase).  A server requests these records via a Solicit message (ie I need
the full record for these summary records).  The response to the the
request is a Update Request message containing some/all of the records.  A
server continues to send further Solicit messages for records that it has
not yet received.  A server ack's that the records have been received with
an Update Reply containing the summaries of recieved records.  The Update
Request messages are similar to the UPDATE messages of BGP.

Acknowledgements in SCSP are done per-record (ie requests for a record are
acknowledged by sending the record, record transmissions are acknowledged
by sending a record summary in an Update Reply).


SOME DIFFERENCES
****************

I think Hussein's "2 vs 3" stages are identified above.  SCSP has the added
stage of Cache Alignment where database summaries are exchanged.

BGP uses TCP, SCSP uses X (pick your transport).

BGP exchanges and message formats are certainly more efficient, SCSP more
generic.  In the peer-to-peer case (ie inter-domain), some SCSP header
fields are redundant (example: reciever and sender ID).

SCSP does per-record acks and requests, which is flexible, but can be a
pain in the ass and inefficient.  BGP UPDATE/NOTIFICATION messages are
unacknowledged and assume TCP provides reliability for the application.

SCSP Update Requests can contain many records.  BGP UPDATEs contain a
single route (maybe multiple withdrawn routes).

SCSP bases record identification on record summaries (source identifier,
cache 'key' for record), so to replace a record you keeep the record
summary and replace the data contents.  BGP identifies records based on the
contents (ie NLRI), so the data content is examined to determine new vs
replacement.

BGP includes version negotiation and capabilities exchange in the peering
session establishment.  SCSP has no such concept, the function would have
to be included in the application above SCSP.

Both use a similar keep-alive mechanism to determine peer status.


SOME COMMENTARY
***************

My personal view is that TCP is not enough for reliable application
communications.  I haven't heard anyone else argue for or against this
position, so I'll stick with it.

In order to get application reliability from a lower layer, you need a
transport that either maintains the data or one that gives the application
control over the acks.  SLUMS is a potential transport that seems to take
the latter approach.   From the SLUMS BOF announcement, one of the in-scope
requirements is

    - ability for application to indicate "a reply is coming" versus
      "no more coming now, go ahead and ack, don't delay"

So SLUMS recognizes that apps may need to have input into the ack timing.
I don't know enough about sigtran yet to say anything.

Another alternative is that we put reliability into GLP so that messages
(or records) get ack'd, retransmitted, timed-out, etc.  This is the
direction most other protocols have gone, and is as viable a solution as
anything else.  If we go this way, then we most likely need a "GLP Route
Reflector" spec, etc, to parallel BGP.  I don't think we can just say "we
want to use that attribute/feature of that protocol in a similar way."  The
fact that we're an incompatible protocol to BGP means that any features
that we want from BGP have to be recreated in a spec(s) for GLP.  This may
turn out to be mostly copying, or it may require some technical changes to
the underlying operation.

I suggested SCSP because it seemed to solve our transport needs.  I
wouldn't argue that SCSP is a simple protocol.  We could build a reliable
protocol that is more efficient and less complicated than SCSP.  If SCSP
gets used for more things in the future, then the costs of its
implementation get leveraged as time passes.  I have no idea whether that
will or will not come to be.  It certainly has limited applications now.

So SCSP may be an ugly shoe, but it looked like it fit.  I don't know
whether the cost/complexity of being one of the earlier applications of
SCSP is worth while.  I thought it might be.  I might have similar concerns
about SLUMS after it gets defined.  My crystal ball is a wee bit fuzzy at
the moment.

But that's enough out of me.

- Matt



---------
This message came from the IETF IPTEL Working Group Mailing List.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 30 14:43:59 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09947
	for <iptel-archive@odin.ietf.org>; Fri, 30 Apr 1999 14:43:58 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 77A0352C7; Fri, 30 Apr 1999 14:35:26 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C15FA52CB; Fri, 30 Apr 1999 14:35:25 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <01BE9350.A07D8540.amir@radvision.rad.co.il>
From: Ami Amir <amir@radvision.rad.co.il>
To: "'Matt Squire'" <msquire@NORTELNETWORKS.COM>,
        Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: IPTEL IETF Mailing List <iptel@lists.research.bell-labs.com>
Subject: RE: Evaluation of Gateway Location proposals
Date: Fri, 30 Apr 1999 19:59:37 +0300
Organization: RADVision
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

I am definitely NOT an expert - but one thing that should be kept in mind - 
the need to provide fault tollerance and redundancy. One cannot deploy a 
functional public phone system that deos not provide for redundancy at 
alkost every level.

Ami

-----Original Message-----
From:	Matt Squire [SMTP:msquire@NORTELNETWORKS.COM]
Sent:	Thursday, April 29, 1999 8:46 PM
To:	Jonathan Rosenberg
Cc:	IPTEL IETF Mailing List
Subject:	Re: Evaluation of Gateway Location proposals


>
>2. Matt raised numerous transport issues (TCP or not TCP). I think its
>fair to say we want to avoid designing a new transport protocol. There
>is work underway elsewhere (sigtran and slums) to do this, which we can
>leverage. It would seem to me that if something new is needed, this
>would also be independent of whether the protocol baseline is BGP or
>SCSP, since presumably one could use this new transport protocol with
>either.
>

I certainly agree that we don't want a new transport protocol.  But well
short of designing a new transport is to design reliability into our
application protocol (ie with acks, timeouts, re-transmissions, etc), just
like most other application protocols.

>3. To me, the MAIN differences between a BGP based approach and SCSP
>based approach are:
>  a. how the data is synchronized between peers
>  b. the intra-domain topology
>
>I think we are clear on (b), so (a) is the issue to explore. Hussein had
>made reference to a 2-stage exchange only being needed with BGP, while
>its three with SCSP. These are the kind of differences I think we need
>to explore here. I'd invite both authors to comment on the differences
>in how the data is exchanged and updated between peers. Lets stick with
>inter-domain for the moment...
>

Here's a brief synopsis of the data exchanges for each alternative.  In
both cases, the exchanges are just peer-to-peer.


BGP
***

  BGP1) OPEN.  OPEN messages are exchanged to bring the link up.
Basically, two peers connect and send an open message to the other.  A peer
either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a
NOTIFICATION.  When your OPEN gets ack'd, the peer connection is considered
to be established (ie have bi-directional connectivity).  BGP can also
perform version negotiation and capabilities exchanges with the OPEN
messages.

  BGP2) UPDATE.  Once a peer connection is established (via ack'd OPENs),
BGP peers exchange UPDATE messages.  UPDATE messages are the messages that
contain the routing information.  Each UPDATE message may contain a number
of withdrawn routes and a single feasible route.  A withdrawn route is a
route that should be removed from the peer's RIB-IN.  A withdrawn route is
defined by a address/prefix-length.  A feasible route is defined as the
NLRI (network layer reachability information, ie a list of
address/prefix-length combinations) and its attributes.   A key mandatory
attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI.
Basically, you send an UPDATE for each possible NEXT-HOP in your routing
database.

KEEP-ALIVE messages are periodically going in the background to ensure that
the link is up.

BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP
acknowledgment is considered sufficient.


SCSP
****
  SCSP1) Hello.  Peers exchange Hello messages to ensure bi-directional
connectivity between peers.  This is equivalent to the BGP OPEN exchanges
but without anything like version negotiation or capabilities exchange.
Hello messages are also periodically exchanged in the background to ensure
the link us still up.

  SCSP2) Cache Aligment.  SCSP distinguishes between the state where two
peers have had their databases synchronized and when they have not.  When a
peer connection first comes up (via Hello), the peers enter the Cache
Alignment phase where the entire databases must be exchanged.  First, there
is a negotiation to determine who is the master and slave of the peering
relationship.  Next, the peers exchange summary records with each other,
where a summary record is a short-version of the record - enough to
identify it, but doesn't have the real data.  This phase has no parallel in
BGP.

  SCSP3) Cache State Update.  A server maintiains a list of the records
that it needs to get from its peer (the summary records in the previous
phase).  A server requests these records via a Solicit message (ie I need
the full record for these summary records).  The response to the the
request is a Update Request message containing some/all of the records.  A
server continues to send further Solicit messages for records that it has
not yet received.  A server ack's that the records have been received with
an Update Reply containing the summaries of recieved records.  The Update
Request messages are similar to the UPDATE messages of BGP.

Acknowledgements in SCSP are done per-record (ie requests for a record are
acknowledged by sending the record, record transmissions are acknowledged
by sending a record summary in an Update Reply).


SOME DIFFERENCES
****************

I think Hussein's "2 vs 3" stages are identified above.  SCSP has the added
stage of Cache Alignment where database summaries are exchanged.

BGP uses TCP, SCSP uses X (pick your transport).

BGP exchanges and message formats are certainly more efficient, SCSP more
generic.  In the peer-to-peer case (ie inter-domain), some SCSP header
fields are redundant (example: reciever and sender ID).

SCSP does per-record acks and requests, which is flexible, but can be a
pain in the ass and inefficient.  BGP UPDATE/NOTIFICATION messages are
unacknowledged and assume TCP provides reliability for the application.

SCSP Update Requests can contain many records.  BGP UPDATEs contain a
single route (maybe multiple withdrawn routes).

SCSP bases record identification on record summaries (source identifier,
cache 'key' for record), so to replace a record you keeep the record
summary and replace the data contents.  BGP identifies records based on the
contents (ie NLRI), so the data content is examined to determine new vs
replacement.

BGP includes version negotiation and capabilities exchange in the peering
session establishment.  SCSP has no such concept, the function would have
to be included in the application above SCSP.

Both use a similar keep-alive mechanism to determine peer status.


SOME COMMENTARY
***************

My personal view is that TCP is not enough for reliable application
communications.  I haven't heard anyone else argue for or against this
position, so I'll stick with it.

In order to get application reliability from a lower layer, you need a
transport that either maintains the data or one that gives the application
control over the acks.  SLUMS is a potential transport that seems to take
the latter approach.   From the SLUMS BOF announcement, one of the in-scope
requirements is

    - ability for application to indicate "a reply is coming" versus
      "no more coming now, go ahead and ack, don't delay"

So SLUMS recognizes that apps may need to have input into the ack timing.
I don't know enough about sigtran yet to say anything.

Another alternative is that we put reliability into GLP so that messages
(or records) get ack'd, retransmitted, timed-out, etc.  This is the
direction most other protocols have gone, and is as viable a solution as
anything else.  If we go this way, then we most likely need a "GLP Route
Reflector" spec, etc, to parallel BGP.  I don't think we can just say "we
want to use that attribute/feature of that protocol in a similar way."  The
fact that we're an incompatible protocol to BGP means that any features
that we want from BGP have to be recreated in a spec(s) for GLP.  This may
turn out to be mostly copying, or it may require some technical changes to
the underlying operation.

I suggested SCSP because it seemed to solve our transport needs.  I
wouldn't argue that SCSP is a simple protocol.  We could build a reliable
protocol that is more efficient and less complicated than SCSP.  If SCSP
gets used for more things in the future, then the costs of its
implementation get leveraged as time passes.  I have no idea whether that
will or will not come to be.  It certainly has limited applications now.

So SCSP may be an ugly shoe, but it looked like it fit.  I don't know
whether the cost/complexity of being one of the earlier applications of
SCSP is worth while.  I thought it might be.  I might have similar concerns
about SLUMS after it gets defined.  My crystal ball is a wee bit fuzzy at
the moment.

But that's enough out of me.

- Matt



---------
This message came from the IETF IPTEL Working Group Mailing List.


---------
This message came from the IETF IPTEL Working Group Mailing List.


From owner-iptel-outgoing@lists.research.bell-labs.com  Fri Apr 30 15:01:55 1999
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10302
	for <iptel-archive@odin.ietf.org>; Fri, 30 Apr 1999 15:01:54 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix)
	id 098AA52C8; Fri, 30 Apr 1999 14:57:15 -0400 (EDT)
Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6203952CA; Fri, 30 Apr 1999 14:57:14 -0400 (EDT)
Delivered-To: iptel-local@paperless.dnrc.bell-labs.com
Message-ID: <05b201be933a$fce9f590$511875c2@inescn.pt>
From: "Carlos Alberto Rodrigues e Silva" <cars@fe.up.pt>
To: <h323implementors@imtc.org>,
        "IP Telephony" <iptel@lists.research.bell-labs.com>
Subject: V/IP card
Date: Fri, 30 Apr 1999 19:55:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-iptel@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
I have a Voice Fax Gateway card to test, Micom V/IP CLEAR VOICE V/IP 2002
ISA FXE, and would like to know if there is any kind of developments in
Linux.
Thanks in advance.
Best regards,
    Carlos



---------
This message came from the IETF IPTEL Working Group Mailing List.