From extest-admin@lists.bell-labs.com  Wed Aug  1 04:59:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23010
	for <iptel-archive@odin.ietf.org>; Wed, 1 Aug 2001 04:59:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 70BB244343
	for <iptel-archive@lists.ietf.org>; Wed,  1 Aug 2001 05:00:37 -0400 (EDT)
Subject: lists.bell-labs.com mailing list memberships reminder
From: mailman-owner@lists.bell-labs.com
To: iptel-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: extest-admin@lists.bell-labs.com
Errors-To: extest-admin@lists.bell-labs.com
X-BeenThere: extest@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Message-Id: <20010801090037.70BB244343@lists.bell-labs.com>
Date: Wed,  1 Aug 2001 05:00:37 -0400 (EDT)

This is a reminder, sent out once a month, about your
lists.bell-labs.com mailing list memberships.  It includes your
subscription info and how to use it to change it or unsubscribe from a
list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, iptel-request@lists.bell-labs.com) containing
just the word 'help' in the message body, and an email message will be
sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@lists.bell-labs.com.  Thanks!

Passwords for iptel-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
iptel@lists.bell-labs.com                Gfcn      
http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org


From iptel-admin@lists.bell-labs.com  Thu Aug  2 09:51:03 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27456
	for <iptel-archive@odin.ietf.org>; Thu, 2 Aug 2001 09:51:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6CAEC44337; Thu,  2 Aug 2001 09:52:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from WIN2K-SRV-001.reddo.net (57.131.88.213.host.tele1europe.se [213.88.131.57])
	by lists.bell-labs.com (Postfix) with ESMTP id 297F044336
	for <iptel@lists.bell-labs.com>; Thu,  2 Aug 2001 05:17:35 -0400 (EDT)
Received: by WIN2K-SRV-001.reddo.net with Internet Mail Service (5.5.2650.21)
	id <QAJYFZ7C>; Thu, 2 Aug 2001 11:13:14 +0200
Message-ID: <8346B686B0DBC1469AA5307F8BABBB3F0C4DA5@WIN2K-SRV-001.reddo.net>
From: Xu Zhe <jerry@reddo.net>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] urgent: ip telphony traffic model
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 2 Aug 2001 11:13:13 +0200

hello,
some one has post this message but without answer. I also need the answer to
this, can someone help me?
Hi everybody, Is there any study that has tried to characterize the ip
telephony traffic? If yes, can somebody point me where I can find it? Thanks
in advance. 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  2 12:04:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03678
	for <iptel-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:04:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1DCEE4433D; Thu,  2 Aug 2001 11:35:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from telchemy.com (unknown [4.21.228.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 8681044336
	for <iptel@lists.bell-labs.com>; Thu,  2 Aug 2001 11:34:07 -0400 (EDT)
Received: from alansnotebook [12.88.174.22] by telchemy.com with ESMTP
  (SMTPD32-6.06) id A25A1CF023E; Thu, 02 Aug 2001 11:31:38 -0400
From: "Alan Clark" <alan@telchemy.com>
To: "Xu Zhe" <jerry@reddo.net>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Message-ID: <CPENLKPAMNPJOAGPMGDLOELCCGAA.alan@telchemy.com>
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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <8346B686B0DBC1469AA5307F8BABBB3F0C4DA5@WIN2K-SRV-001.reddo.net>
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 2 Aug 2001 11:35:27 -0400
Content-Transfer-Encoding: 7bit


Telchemy is currently conducting research in this area, building aggregate
VoIP traffic models for NS-2 as part of our work on performance analysis of
large scale VoIP networks.  We have done a fairly comprehensive literature
survey, are (re)doing analytical work and simulation studies.

We would be interested to exchange information with other research groups,
and will add a list of the references we have found to our web site
(www.telchemy.com) next week.

Alan Clark
alan@telchemy.com


-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Xu Zhe
Sent: Thursday, August 02, 2001 5:13 AM
To: 'iptel@lists.bell-labs.com'
Subject: [IPTEL] urgent: ip telphony traffic model


hello,
some one has post this message but without answer. I also need the answer to
this, can someone help me?
Hi everybody, Is there any study that has tried to characterize the ip
telephony traffic? If yes, can somebody point me where I can find it? Thanks
in advance.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  2 12:08:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03924
	for <iptel-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:08:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6519F44344; Thu,  2 Aug 2001 12:09:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from chuckie.dgms.com (chuckie.dgms.com [38.150.156.4])
	by lists.bell-labs.com (Postfix) with ESMTP id D05B744342
	for <iptel@lists.bell-labs.com>; Thu,  2 Aug 2001 12:08:36 -0400 (EDT)
Received: from ulticom.com (localhost [127.0.0.1])
	by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id MAA24884
	for <iptel@lists.bell-labs.com>; Thu, 2 Aug 2001 12:08:36 -0400 (EDT)
Message-ID: <3B697A91.BB4D4FF9@ulticom.com>
From: Vijaya Venkatachalam <vijaya@ulticom.com>
Organization: Ulticom, Inc.
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------55A69171D5FFFD3AB76151DD"
Subject: [IPTEL] TRIP:Initial Peer Discovery
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 02 Aug 2001 12:06:41 -0400


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

Hi,

I have a question regarding the discovery of external peers
in TRIP.

When the LS gets a Start Event (from either the operator or
the system), then how does it know which LS peer to establish
the connection with.

Are the list of external peers done by configuration?

Thanks,
Vijaya

--------------55A69171D5FFFD3AB76151DD
Content-Type: text/x-vcard; charset=us-ascii;
 name="vijaya.vcf"
Content-Description: Card for Vijaya Venkatachalam
Content-Disposition: attachment;
 filename="vijaya.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Venkatachalam;Vijaya
tel;fax:+1-856-866-2033
tel;work:+1-856-787-2853
x-mozilla-html:FALSE
url:www.ulticom.com
org:Ulticom, Inc.;Research & Development
adr:;;1020 Briggs Rd;Mt. Laurel;NJ;08054;USA
version:2.1
email;internet:vijaya@ulticom.com
fn:Vijaya Venkatachalam
end:vcard

--------------55A69171D5FFFD3AB76151DD--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  2 12:16:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04414
	for <iptel-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:16:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C4AA144348; Thu,  2 Aug 2001 12:17:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by lists.bell-labs.com (Postfix) with ESMTP id 42A0144343
	for <iptel@lists.bell-labs.com>; Thu,  2 Aug 2001 12:16:04 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f72GFLw3007186;
	Thu, 2 Aug 2001 12:15:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJRL2>; Thu, 2 Aug 2001 12:15:56 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D643C@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Vijaya Venkatachalam'" <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP:Initial Peer Discovery
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 2 Aug 2001 12:15:55 -0400

There is no discovery process for trip peers. It is always administratively
configured; this is because a trip peering relationship is almost always the
result of a prior business agreement.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
> Sent: Thursday, August 02, 2001 12:07 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP:Initial Peer Discovery
> 
> 
> Hi,
> 
> I have a question regarding the discovery of external peers
> in TRIP.
> 
> When the LS gets a Start Event (from either the operator or
> the system), then how does it know which LS peer to establish
> the connection with.
> 
> Are the list of external peers done by configuration?
> 
> Thanks,
> Vijaya
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  2 16:47:45 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18475
	for <iptel-archive@odin.ietf.org>; Thu, 2 Aug 2001 16:47:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AB64544341; Thu,  2 Aug 2001 16:12:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from web12304.mail.yahoo.com (web12304.mail.yahoo.com [216.136.173.102])
	by lists.bell-labs.com (Postfix) with SMTP id C87A944336
	for <iptel@lists.bell-labs.com>; Thu,  2 Aug 2001 16:11:34 -0400 (EDT)
Message-ID: <20010802201111.9619.qmail@web12304.mail.yahoo.com>
Received: from [134.193.6.247] by web12304.mail.yahoo.com; Thu, 02 Aug 2001 13:11:11 PDT
From: Karthik <kar_v78@yahoo.com>
Subject: Re: [IPTEL] urgent: ip telphony traffic model
To: Xu Zhe <jerry@reddo.net>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
In-Reply-To: <8346B686B0DBC1469AA5307F8BABBB3F0C4DA5@WIN2K-SRV-001.reddo.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 2 Aug 2001 13:11:11 -0700 (PDT)

Hi,
You might want to check this out....
http://www.isoc.org/inet99/4p/4p_2.htm

Regards,
Karthik.

--- Xu Zhe <jerry@reddo.net> wrote:
> hello,
> some one has post this message but without answer. I
> also need the answer to
> this, can someone help me?
> Hi everybody, Is there any study that has tried to
> characterize the ip
> telephony traffic? If yes, can somebody point me
> where I can find it? Thanks
> in advance. 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug  3 15:10:02 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24542
	for <iptel-archive@odin.ietf.org>; Fri, 3 Aug 2001 15:10:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6B6AD44346; Fri,  3 Aug 2001 15:11:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 6616C44336
	for <iptel@lists.bell-labs.com>; Fri,  3 Aug 2001 15:10:42 -0400 (EDT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GHI00950ALCZB@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Fri,  3 Aug 2001 19:10:25 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHI00I01AL1EF@pmismtp04.wcomnet.com>;
 Fri, 03 Aug 2001 19:10:24 +0000 (GMT)
Received: from hsinnreich ([166.44.139.80])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHI00G8OAIM6I@pmismtp04.wcomnet.com>; Fri,
 03 Aug 2001 19:10:09 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: <CPENLKPAMNPJOAGPMGDLOELCCGAA.alan@telchemy.com>
To: "'Alan Clark'" <alan@telchemy.com>, "'Xu Zhe'" <jerry@reddo.net>,
        iptel@lists.bell-labs.com
Message-id: <001001c11c4f$e93037d0$508b2ca6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 03 Aug 2001 21:08:45 +0200
Content-Transfer-Encoding: 7bit

Please help me understand:
Do you really want to separate VoIP traffic from other IP applications?
Can you separate it? Is it a good idea to balkanize the Internet for
various applications?

BTW: We already have separate voice network...

Thanks,Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA 

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> Sent: Thursday, August 02, 2001 5:35 PM
> To: Xu Zhe; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Telchemy is currently conducting research in this area,
> building aggregate VoIP traffic models for NS-2 as part of 
> our work on performance analysis of large scale VoIP 
> networks.  We have done a fairly comprehensive literature 
> survey, are (re)doing analytical work and simulation studies.
> 
> We would be interested to exchange information with other
> research groups, and will add a list of the references we 
> have found to our web site
> (www.telchemy.com) next week.
> 
> Alan Clark
> alan@telchemy.com
> 
> 
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> 
> Sent: Thursday, August 02, 2001 5:13 AM
> 
> To: 'iptel@lists.bell-labs.com'
> Subject: [IPTEL] urgent: ip telphony traffic model
> 
> 
> hello,
> some one has post this message but without answer. I also
> need the answer to this, can someone help me? Hi everybody, 
> Is there any study that has tried to characterize the ip 
> telephony traffic? If yes, can somebody point me where I can 
> find it? Thanks in advance.
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug  3 15:43:02 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25335
	for <iptel-archive@odin.ietf.org>; Fri, 3 Aug 2001 15:43:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 850E144356; Fri,  3 Aug 2001 15:44:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from telchemy.com (unknown [4.21.228.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 0F1C544354
	for <iptel@lists.bell-labs.com>; Fri,  3 Aug 2001 15:43:41 -0400 (EDT)
Received: from TELWS104 [209.186.15.20] by telchemy.com with ESMTP
  (SMTPD32-6.06) id AE661719012A; Fri, 03 Aug 2001 15:41:26 -0400
Reply-To: <alan@telchemy.com>
From: "Alan Clark" <alan@telchemy.com>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Xu Zhe'" <jerry@reddo.net>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Message-ID: <004b01c11c53$4001d610$6801a8c0@telchemy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <001001c11c4f$e93037d0$508b2ca6@open.wcomnet.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 3 Aug 2001 15:34:01 -0400
Content-Transfer-Encoding: 7bit


Henry

We are assuming that service providers such as Worldcom have a dedicated IP
network and are not using the Internet for long distance/ international
telephone traffic. From the discussions we have had with some of your
competitors it does appear to be a reasonable assumption that many service
providers plan to have a packet based backbone that may be used for both
voice and data traffic, and potentially for video.  It also appears a
reasonable assumption that you would want to preserve some separation
between voice and data services using either diffserv or MPLS in order that
you can prevent spikes in data traffic from causing excessive packet loss
and jitter in voice traffic.
We are modeling the behavior of aggregate VoIP streams and "interfering"
bulk data traffic over IP networks that use techniques such as CBQ, WRED
etc.  In general you would expect that segregating voice and data traffic
would eliminate QoS issues however there is still scope for some level of
interference - we are interested in both the nature of (even minor) network
impairments that may result from this scenario and in the "real time traffic
engineering" problem.

Regards

Alan




-----Original Message-----
From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
Sent: Friday, August 03, 2001 3:09 PM
To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model


Please help me understand:
Do you really want to separate VoIP traffic from other IP applications?
Can you separate it? Is it a good idea to balkanize the Internet for
various applications?

BTW: We already have separate voice network...

Thanks,Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> Sent: Thursday, August 02, 2001 5:35 PM
> To: Xu Zhe; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
>
>
>
> Telchemy is currently conducting research in this area,
> building aggregate VoIP traffic models for NS-2 as part of
> our work on performance analysis of large scale VoIP
> networks.  We have done a fairly comprehensive literature
> survey, are (re)doing analytical work and simulation studies.
>
> We would be interested to exchange information with other
> research groups, and will add a list of the references we
> have found to our web site
> (www.telchemy.com) next week.
>
> Alan Clark
> alan@telchemy.com
>
>
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
>
> Sent: Thursday, August 02, 2001 5:13 AM
>
> To: 'iptel@lists.bell-labs.com'
> Subject: [IPTEL] urgent: ip telphony traffic model
>
>
> hello,
> some one has post this message but without answer. I also
> need the answer to this, can someone help me? Hi everybody,
> Is there any study that has tried to characterize the ip
> telephony traffic? If yes, can somebody point me where I can
> find it? Thanks in advance.
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>
>
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug  3 15:48:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25462
	for <iptel-archive@odin.ietf.org>; Fri, 3 Aug 2001 15:48:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E521144363; Fri,  3 Aug 2001 15:45:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from web12307.mail.yahoo.com (web12307.mail.yahoo.com [216.136.173.105])
	by lists.bell-labs.com (Postfix) with SMTP id 88DBB4435F
	for <iptel@lists.bell-labs.com>; Fri,  3 Aug 2001 15:44:42 -0400 (EDT)
Message-ID: <20010803194439.77434.qmail@web12307.mail.yahoo.com>
Received: from [134.193.111.190] by web12307.mail.yahoo.com; Fri, 03 Aug 2001 12:44:39 PDT
From: Karthik <kar_v78@yahoo.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
To: Henry Sinnreich <henry.sinnreich@wcom.com>,
        "'Alan Clark'" <alan@telchemy.com>, "'Xu Zhe'" <jerry@reddo.net>,
        iptel@lists.bell-labs.com
In-Reply-To: <001001c11c4f$e93037d0$508b2ca6@open.wcomnet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 3 Aug 2001 12:44:39 -0700 (PDT)

The idea is to have some method for providing a
desired level of service to voice traffic when carried
over IP. It might seem to be redundant since there is
a separate voice network but to provide new services
like an interactive conferencing call with
simultaneous audio AND video is not possible with the
existing dedicated voice network whereas IP can easily
accodomate these.
The question of whether VoIP traffic can be separated
can not be answered in absolute terms as there are
different architectures like Integrated Services and
Differentiated Services which only define a framework
to classify packet traffic and accordingly provide
service but do not actually enforce them. There are
also protocols like MPLS and RSVP which perform the
actual packet marking and classification.
A good reference to get a broad overview of these
architectures would be :

Internet QoS: a big picture 
Xipeng Xiao; Ni, L.M. 
IEEE Network , Volume: 13 Issue: 2 , March-April 1999 

Regards,
Karthik.






--- Henry Sinnreich <henry.sinnreich@wcom.com> wrote:
> Please help me understand:
> Do you really want to separate VoIP traffic from
> other IP applications?
> Can you separate it? Is it a good idea to balkanize
> the Internet for
> various applications?
> 
> BTW: We already have separate voice network...
> 
> Thanks,Henry
> 
> Henry Sinnreich
> WorldCom
> 400 International Parkway
> Richardson, Texas 75081
> USA 
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com] On Behalf
> Of Alan Clark
> > Sent: Thursday, August 02, 2001 5:35 PM
> > To: Xu Zhe; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic
> model
> > 
> > 
> > 
> > Telchemy is currently conducting research in this
> area,
> > building aggregate VoIP traffic models for NS-2 as
> part of 
> > our work on performance analysis of large scale
> VoIP 
> > networks.  We have done a fairly comprehensive
> literature 
> > survey, are (re)doing analytical work and
> simulation studies.
> > 
> > We would be interested to exchange information
> with other
> > research groups, and will add a list of the
> references we 
> > have found to our web site
> > (www.telchemy.com) next week.
> > 
> > Alan Clark
> > alan@telchemy.com
> > 
> > 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com]> On
> Behalf Of Xu Zhe
> > 
> > Sent: Thursday, August 02, 2001 5:13 AM
> > 
> > To: 'iptel@lists.bell-labs.com'
> > Subject: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > hello,
> > some one has post this message but without answer.
> I also
> > need the answer to this, can someone help me? Hi
> everybody, 
> > Is there any study that has tried to characterize
> the ip 
> > telephony traffic? If yes, can somebody point me
> where I can 
> > find it? Thanks in advance.
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell->
> labs.com/mailman/listinfo/iptel
> > 
> > 
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell->
> labs.com/mailman/listinfo/iptel
> > 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


=====
-- Karthik Venkataraman --
Graduate Assistant, 
Networking Lab, UMKC
(816) 674-9612 (C)
(816) 235-2996 (O)

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug  3 16:35:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28619
	for <iptel-archive@odin.ietf.org>; Fri, 3 Aug 2001 16:35:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E474544354; Fri,  3 Aug 2001 16:36:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id BD71444336
	for <iptel@lists.bell-labs.com>; Fri,  3 Aug 2001 16:35:24 -0400 (EDT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GHI0016TEIZKV@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Fri,  3 Aug 2001 20:35:23 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHI00L01EI0B8@pmismtp04.wcomnet.com>;
 Fri, 03 Aug 2001 20:35:23 +0000 (GMT)
Received: from hsinnreich ([166.44.137.50])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHI00J3VEG1UN@pmismtp04.wcomnet.com>; Fri,
 03 Aug 2001 20:34:27 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: <20010803194439.77434.qmail@web12307.mail.yahoo.com>
To: "'Karthik'" <kar_v78@yahoo.com>, "'Alan Clark'" <alan@telchemy.com>,
        "'Xu Zhe'" <jerry@reddo.net>, iptel@lists.bell-labs.com
Message-id: <004501c11c5b$ad307400$508b2ca6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 03 Aug 2001 22:33:37 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28619

>audio AND video is not possible with the

Exactly! Now that you add video, why stop there and not add chat and
applications sharing, webcast data, SMIL webcasts during a conference
and what not. Where is the separation? There is none, the Internet IP
and transport layers should never know about the application, since it
is not doable IMHO. Actually, everything is doable, but does not
necessarily make sense.

Separating voice traffic over separate paths (MPLS) may be just a reflex
from the voice industry, but that does not make it right. Separating
traffic classes is OK, as in DiffServ, since it is scalable.

Henry

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Karthik
> Sent: Friday, August 03, 2001 9:45 PM
> To: Henry Sinnreich; 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> The idea is to have some method for providing a
> desired level of service to voice traffic when carried
> over IP. It might seem to be redundant since there is
> a separate voice network but to provide new services
> like an interactive conferencing call with
> simultaneous audio AND video is not possible with the existing 
> dedicated voice network whereas IP can easily accodomate these. The 
> question of whether VoIP traffic can be separated can not be answered 
> in absolute terms as there are different architectures like Integrated

> Services and Differentiated Services which only define a framework to
> classify packet traffic and accordingly provide service but 
> do not actually enforce them. There are also protocols like 
> MPLS and RSVP which perform the actual packet marking and 
> classification. A good reference to get a broad overview of 
> these architectures would be :
> 
> Internet QoS: a big picture
> Xipeng Xiao; Ni, L.M. 
> IEEE Network , Volume: 13 Issue: 2 , March-April 1999 
> 
> Regards,
> Karthik.
> 
> 
> 
> 
> 
> 
> --- Henry Sinnreich <henry.sinnreich@wcom.com> wrote:
> > Please help me understand:
> > Do you really want to separate VoIP traffic from
> > other IP applications?
> > Can you separate it? Is it a good idea to balkanize
> > the Internet for
> > various applications?
> > 
> > BTW: We already have separate voice network...
> > 
> > Thanks,Henry
> > 
> > Henry Sinnreich
> > WorldCom
> > 400 International Parkway
> > Richardson, Texas 75081
> > USA
> > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf
> > Of Alan Clark
> > > Sent: Thursday, August 02, 2001 5:35 PM
> > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic
> > model
> > > 
> > > 
> > > 
> > > Telchemy is currently conducting research in this
> > area,
> > > building aggregate VoIP traffic models for NS-2 as
> > part of
> > > our work on performance analysis of large scale
> > VoIP
> > > networks.  We have done a fairly comprehensive
> > literature
> > > survey, are (re)doing analytical work and
> > simulation studies.
> > > 
> > > We would be interested to exchange information
> > with other
> > > research groups, and will add a list of the
> > references we
> > > have found to our web site
> > > (www.telchemy.com) next week.
> > > 
> > > Alan Clark
> > > alan@telchemy.com
> > > 
> > > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com]> On
> > Behalf Of Xu Zhe
> > > 
> > > Sent: Thursday, August 02, 2001 5:13 AM
> > > 
> > > To: 'iptel@lists.bell-labs.com'
> > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > hello,
> > > some one has post this message but without answer.
> > I also
> > > need the answer to this, can someone help me? Hi
> > everybody,
> > > Is there any study that has tried to characterize
> > the ip
> > > telephony traffic? If yes, can somebody point me
> > where I can
> > > find it? Thanks in advance.
> > > 
> > > 
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com
> > > http://lists.bell->
> > labs.com/mailman/listinfo/iptel
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com
> > > http://lists.bell->
> > labs.com/mailman/listinfo/iptel
> > > 
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> 
> =====
> -- Karthik Venkataraman --
> Graduate Assistant,
> Networking Lab, UMKC
> (816) 674-9612 (C)
> (816) 235-2996 (O)
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with
> Yahoo! Messenger http://phonecard.yahoo.com/
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug  3 16:37:46 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28710
	for <iptel-archive@odin.ietf.org>; Fri, 3 Aug 2001 16:37:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2239444367; Fri,  3 Aug 2001 16:37:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id E0CB744360
	for <iptel@lists.bell-labs.com>; Fri,  3 Aug 2001 16:36:04 -0400 (EDT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GHI00M2EEK1WQ@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Fri,  3 Aug 2001 20:36:01 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHI00L01EIHJW@pmismtp04.wcomnet.com>;
 Fri, 03 Aug 2001 20:35:59 +0000 (GMT)
Received: from hsinnreich ([166.44.137.50])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHI00J3VEG1UN@pmismtp04.wcomnet.com>; Fri,
 03 Aug 2001 20:34:56 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: <004b01c11c53$4001d610$6801a8c0@telchemy.com>
To: alan@telchemy.com, "'Xu Zhe'" <jerry@reddo.net>, iptel@lists.bell-labs.com
Message-id: <004801c11c5b$c1579a30$508b2ca6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 03 Aug 2001 22:33:37 +0200
Content-Transfer-Encoding: 7bit

Alan, 

Segregating traffic over the Internet by application seems a strange
idea. Segregating by classes of traffic is OK and already dealt with by
DiffServ. Besides, predictions show that voice will amount to a small
percentage of overall IP traffic..., but maybe we can discuss at the
IETF.

Thanks, Henry

> -----Original Message-----
> From: Alan Clark [mailto:alan@telchemy.com] 
> Sent: Friday, August 03, 2001 9:34 PM
> To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Henry
> 
> We are assuming that service providers such as Worldcom have 
> a dedicated IP network and are not using the Internet for 
> long distance/ international telephone traffic. From the 
> discussions we have had with some of your competitors it does 
> appear to be a reasonable assumption that many service 
> providers plan to have a packet based backbone that may be 
> used for both voice and data traffic, and potentially for 
> video.  It also appears a reasonable assumption that you 
> would want to preserve some separation between voice and data 
> services using either diffserv or MPLS in order that you can 
> prevent spikes in data traffic from causing excessive packet 
> loss and jitter in voice traffic. We are modeling the 
> behavior of aggregate VoIP streams and "interfering" bulk 
> data traffic over IP networks that use techniques such as 
> CBQ, WRED etc.  In general you would expect that segregating 
> voice and data traffic would eliminate QoS issues however 
> there is still scope for some level of interference - we are 
> interested in both the nature of (even minor) network 
> impairments that may result from this scenario and in the 
> "real time traffic engineering" problem.
> 
> Regards
> 
> Alan
> 
> 
> 
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Friday, August 03, 2001 3:09 PM
> To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Please help me understand:
> Do you really want to separate VoIP traffic from other IP 
> applications? Can you separate it? Is it a good idea to 
> balkanize the Internet for various applications?
> 
> BTW: We already have separate voice network...
> 
> Thanks,Henry
> 
> Henry Sinnreich
> WorldCom
> 400 International Parkway
> Richardson, Texas 75081
> USA
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> > Sent: Thursday, August 02, 2001 5:35 PM
> > To: Xu Zhe; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> >
> > Telchemy is currently conducting research in this area, building 
> > aggregate VoIP traffic models for NS-2 as part of our work on 
> > performance analysis of large scale VoIP networks.  We have done a 
> > fairly comprehensive literature survey, are (re)doing 
> analytical work 
> > and simulation studies.
> >
> > We would be interested to exchange information with other research 
> > groups, and will add a list of the references we have found 
> to our web 
> > site
> > (www.telchemy.com) next week.
> >
> > Alan Clark
> > alan@telchemy.com
> >
> >
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> >
> > Sent: Thursday, August 02, 2001 5:13 AM
> >
> > To: 'iptel@lists.bell-labs.com'
> > Subject: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > hello,
> > some one has post this message but without answer. I also need the 
> > answer to this, can someone help me? Hi everybody, Is there 
> any study 
> > that has tried to characterize the ip telephony traffic? If 
> yes, can 
> > somebody point me where I can find it? Thanks in advance.
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-> labs.com/mailman/listinfo/iptel
> >
> >
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-> labs.com/mailman/listinfo/iptel
> >
> 
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Aug  6 16:27:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01108
	for <iptel-archive@odin.ietf.org>; Mon, 6 Aug 2001 16:27:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ABE5544338; Mon,  6 Aug 2001 16:29:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from WIN2K-SRV-001.reddo.net (57.131.88.213.host.tele1europe.se [213.88.131.57])
	by lists.bell-labs.com (Postfix) with ESMTP id 883CD44336
	for <iptel@lists.bell-labs.com>; Mon,  6 Aug 2001 03:48:04 -0400 (EDT)
Received: by WIN2K-SRV-001.reddo.net with Internet Mail Service (5.5.2650.21)
	id <Q1GSCZCW>; Mon, 6 Aug 2001 09:43:31 +0200
Message-ID: <8346B686B0DBC1469AA5307F8BABBB3F0C4DAF@WIN2K-SRV-001.reddo.net>
From: Jerry <jerry@reddo.net>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>
Cc: "'alan@telchemy.com'" <alan@telchemy.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 6 Aug 2001 09:43:26 +0200

hello Henry,

Of course IP layer does not know weather it is a voice or a chat or
something else, but I want to know it. Because we are trying to make our own
router, maybe it is important to know the "busy hour" traffic, the jatter
and other parameters. Then we can try to do some application simulation test
to our router.
This is why I want a voip model.

BRs,
XuZhe

-----Original Message-----
From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
Sent: Friday, August 03, 2001 10:34 PM
To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model


Alan, 

Segregating traffic over the Internet by application seems a strange
idea. Segregating by classes of traffic is OK and already dealt with by
DiffServ. Besides, predictions show that voice will amount to a small
percentage of overall IP traffic..., but maybe we can discuss at the
IETF.

Thanks, Henry

> -----Original Message-----
> From: Alan Clark [mailto:alan@telchemy.com] 
> Sent: Friday, August 03, 2001 9:34 PM
> To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Henry
> 
> We are assuming that service providers such as Worldcom have 
> a dedicated IP network and are not using the Internet for 
> long distance/ international telephone traffic. From the 
> discussions we have had with some of your competitors it does 
> appear to be a reasonable assumption that many service 
> providers plan to have a packet based backbone that may be 
> used for both voice and data traffic, and potentially for 
> video.  It also appears a reasonable assumption that you 
> would want to preserve some separation between voice and data 
> services using either diffserv or MPLS in order that you can 
> prevent spikes in data traffic from causing excessive packet 
> loss and jitter in voice traffic. We are modeling the 
> behavior of aggregate VoIP streams and "interfering" bulk 
> data traffic over IP networks that use techniques such as 
> CBQ, WRED etc.  In general you would expect that segregating 
> voice and data traffic would eliminate QoS issues however 
> there is still scope for some level of interference - we are 
> interested in both the nature of (even minor) network 
> impairments that may result from this scenario and in the 
> "real time traffic engineering" problem.
> 
> Regards
> 
> Alan
> 
> 
> 
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Friday, August 03, 2001 3:09 PM
> To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Please help me understand:
> Do you really want to separate VoIP traffic from other IP 
> applications? Can you separate it? Is it a good idea to 
> balkanize the Internet for various applications?
> 
> BTW: We already have separate voice network...
> 
> Thanks,Henry
> 
> Henry Sinnreich
> WorldCom
> 400 International Parkway
> Richardson, Texas 75081
> USA
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> > Sent: Thursday, August 02, 2001 5:35 PM
> > To: Xu Zhe; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> >
> > Telchemy is currently conducting research in this area, building 
> > aggregate VoIP traffic models for NS-2 as part of our work on 
> > performance analysis of large scale VoIP networks.  We have done a 
> > fairly comprehensive literature survey, are (re)doing 
> analytical work 
> > and simulation studies.
> >
> > We would be interested to exchange information with other research 
> > groups, and will add a list of the references we have found 
> to our web 
> > site
> > (www.telchemy.com) next week.
> >
> > Alan Clark
> > alan@telchemy.com
> >
> >
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> >
> > Sent: Thursday, August 02, 2001 5:13 AM
> >
> > To: 'iptel@lists.bell-labs.com'
> > Subject: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > hello,
> > some one has post this message but without answer. I also need the 
> > answer to this, can someone help me? Hi everybody, Is there 
> any study 
> > that has tried to characterize the ip telephony traffic? If 
> yes, can 
> > somebody point me where I can find it? Thanks in advance.
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-> labs.com/mailman/listinfo/iptel
> >
> >
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-> labs.com/mailman/listinfo/iptel
> >
> 
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 03:02:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26906
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 03:02:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 34B8844345; Tue,  7 Aug 2001 03:04:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id A82BA44340
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 03:03:14 -0400 (EDT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GHO00A76RLDM8@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Tue,  7 Aug 2001 07:03:14 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHO00J01RL9IE@pmismtp04.wcomnet.com>;
 Tue, 07 Aug 2001 07:03:13 +0000 (GMT)
Received: from hsinnreich ([166.42.40.10])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHO005NVRKZ0C@pmismtp04.wcomnet.com>; Tue,
 07 Aug 2001 07:03:03 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: <8346B686B0DBC1469AA5307F8BABBB3F0C4DAF@WIN2K-SRV-001.reddo.net>
To: "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Message-id: <001b01c11f0f$00495160$278921d9@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 08:02:59 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA26906

The busy hour voice traffic will most certainly be noise in the overall
IP traffic, both on the public Internet and in well engineered
enterprise networks. Not the to mention the presumed 97% unused fiber
capacity.

Would be interested if there are any numbers to the contrary, that is
voice traffic projections showing the load on the  Internet to be more
than noise levels compared to capacity or to total traffic load.

BTW: Why stop with at voice and not have special paths for multimedia?
For what else? 

Thanks, Henry

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> Sent: Monday, August 06, 2001 8:43 AM
> To: 'Henry Sinnreich'
> Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> hello Henry,
> 
> Of course IP layer does not know weather it is a voice or a 
> chat or something else, but I want to know it. Because we are 
> trying to make our own router, maybe it is important to know 
> the "busy hour" traffic, the jatter and other parameters. 
> Then we can try to do some application simulation test to our 
> router. This is why I want a voip model.
> 
> BRs,
> XuZhe
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Friday, August 03, 2001 10:34 PM
> To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Alan, 
> 
> Segregating traffic over the Internet by application seems a 
> strange idea. Segregating by classes of traffic is OK and 
> already dealt with by DiffServ. Besides, predictions show 
> that voice will amount to a small percentage of overall IP 
> traffic..., but maybe we can discuss at the IETF.
> 
> Thanks, Henry
> 
> > -----Original Message-----
> > From: Alan Clark [mailto:alan@telchemy.com]
> > Sent: Friday, August 03, 2001 9:34 PM
> > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > 
> > Henry
> > 
> > We are assuming that service providers such as Worldcom have
> > a dedicated IP network and are not using the Internet for 
> > long distance/ international telephone traffic. From the 
> > discussions we have had with some of your competitors it does 
> > appear to be a reasonable assumption that many service 
> > providers plan to have a packet based backbone that may be 
> > used for both voice and data traffic, and potentially for 
> > video.  It also appears a reasonable assumption that you 
> > would want to preserve some separation between voice and data 
> > services using either diffserv or MPLS in order that you can 
> > prevent spikes in data traffic from causing excessive packet 
> > loss and jitter in voice traffic. We are modeling the 
> > behavior of aggregate VoIP streams and "interfering" bulk 
> > data traffic over IP networks that use techniques such as 
> > CBQ, WRED etc.  In general you would expect that segregating 
> > voice and data traffic would eliminate QoS issues however 
> > there is still scope for some level of interference - we are 
> > interested in both the nature of (even minor) network 
> > impairments that may result from this scenario and in the 
> > "real time traffic engineering" problem.
> > 
> > Regards
> > 
> > Alan
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > Sent: Friday, August 03, 2001 3:09 PM
> > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > Please help me understand:
> > Do you really want to separate VoIP traffic from other IP
> > applications? Can you separate it? Is it a good idea to 
> > balkanize the Internet for various applications?
> > 
> > BTW: We already have separate voice network...
> > 
> > Thanks,Henry
> > 
> > Henry Sinnreich
> > WorldCom
> > 400 International Parkway
> > Richardson, Texas 75081
> > USA
> > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> > > Sent: Thursday, August 02, 2001 5:35 PM
> > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > >
> > > Telchemy is currently conducting research in this area, building
> > > aggregate VoIP traffic models for NS-2 as part of our work on 
> > > performance analysis of large scale VoIP networks.  We 
> have done a 
> > > fairly comprehensive literature survey, are (re)doing 
> > analytical work
> > > and simulation studies.
> > >
> > > We would be interested to exchange information with other research
> > > groups, and will add a list of the references we have found 
> > to our web
> > > site
> > > (www.telchemy.com) next week.
> > >
> > > Alan Clark
> > > alan@telchemy.com
> > >
> > >
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> > >
> > > Sent: Thursday, August 02, 2001 5:13 AM
> > >
> > > To: 'iptel@lists.bell-labs.com'
> > > Subject: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > > hello,
> > > some one has post this message but without answer. I also need the
> > > answer to this, can someone help me? Hi everybody, Is there 
> > any study
> > > that has tried to characterize the ip telephony traffic? If
> > yes, can
> > > somebody point me where I can find it? Thanks in advance.
> > >
> > >
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com
> > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com
> > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > >
> > 
> > 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 06:09:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29102
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 06:09:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9933D44340; Tue,  7 Aug 2001 06:11:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 61FC644336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 06:10:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA08114;
	Tue, 7 Aug 2001 06:10:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA10831;
	Tue, 7 Aug 2001 06:10:17 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRCD0A>; Tue, 7 Aug 2001 06:10:16 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57BECE@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 06:10:15 -0400

Henry

It's true that voice is likely to be a small fraction of overall traffic.
However, it may be a sizable percentage of premium traffic.

If video takes off, video WOULD be a sizeable percentage of traffic on
some large nets.

Brian

> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Tuesday, August 07, 2001 3:03 AM
> To: 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> The busy hour voice traffic will most certainly be noise in 
> the overall
> IP traffic, both on the public Internet and in well engineered
> enterprise networks. Not the to mention the presumed 97% unused fiber
> capacity.
> 
> Would be interested if there are any numbers to the contrary, that is
> voice traffic projections showing the load on the  Internet to be more
> than noise levels compared to capacity or to total traffic load.
> 
> BTW: Why stop with at voice and not have special paths for multimedia?
> For what else? 
> 
> Thanks, Henry
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > Sent: Monday, August 06, 2001 8:43 AM
> > To: 'Henry Sinnreich'
> > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > hello Henry,
> > 
> > Of course IP layer does not know weather it is a voice or a 
> > chat or something else, but I want to know it. Because we are 
> > trying to make our own router, maybe it is important to know 
> > the "busy hour" traffic, the jatter and other parameters. 
> > Then we can try to do some application simulation test to our 
> > router. This is why I want a voip model.
> > 
> > BRs,
> > XuZhe
> > 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > Sent: Friday, August 03, 2001 10:34 PM
> > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > Alan, 
> > 
> > Segregating traffic over the Internet by application seems a 
> > strange idea. Segregating by classes of traffic is OK and 
> > already dealt with by DiffServ. Besides, predictions show 
> > that voice will amount to a small percentage of overall IP 
> > traffic..., but maybe we can discuss at the IETF.
> > 
> > Thanks, Henry
> > 
> > > -----Original Message-----
> > > From: Alan Clark [mailto:alan@telchemy.com]
> > > Sent: Friday, August 03, 2001 9:34 PM
> > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > 
> > > Henry
> > > 
> > > We are assuming that service providers such as Worldcom have
> > > a dedicated IP network and are not using the Internet for 
> > > long distance/ international telephone traffic. From the 
> > > discussions we have had with some of your competitors it does 
> > > appear to be a reasonable assumption that many service 
> > > providers plan to have a packet based backbone that may be 
> > > used for both voice and data traffic, and potentially for 
> > > video.  It also appears a reasonable assumption that you 
> > > would want to preserve some separation between voice and data 
> > > services using either diffserv or MPLS in order that you can 
> > > prevent spikes in data traffic from causing excessive packet 
> > > loss and jitter in voice traffic. We are modeling the 
> > > behavior of aggregate VoIP streams and "interfering" bulk 
> > > data traffic over IP networks that use techniques such as 
> > > CBQ, WRED etc.  In general you would expect that segregating 
> > > voice and data traffic would eliminate QoS issues however 
> > > there is still scope for some level of interference - we are 
> > > interested in both the nature of (even minor) network 
> > > impairments that may result from this scenario and in the 
> > > "real time traffic engineering" problem.
> > > 
> > > Regards
> > > 
> > > Alan
> > > 
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > Sent: Friday, August 03, 2001 3:09 PM
> > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > Please help me understand:
> > > Do you really want to separate VoIP traffic from other IP
> > > applications? Can you separate it? Is it a good idea to 
> > > balkanize the Internet for various applications?
> > > 
> > > BTW: We already have separate voice network...
> > > 
> > > Thanks,Henry
> > > 
> > > Henry Sinnreich
> > > WorldCom
> > > 400 International Parkway
> > > Richardson, Texas 75081
> > > USA
> > > 
> > > > -----Original Message-----
> > > > From: iptel-admin@lists.bell-labs.com
> > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > >
> > > >
> > > >
> > > > Telchemy is currently conducting research in this area, building
> > > > aggregate VoIP traffic models for NS-2 as part of our work on 
> > > > performance analysis of large scale VoIP networks.  We 
> > have done a 
> > > > fairly comprehensive literature survey, are (re)doing 
> > > analytical work
> > > > and simulation studies.
> > > >
> > > > We would be interested to exchange information with 
> other research
> > > > groups, and will add a list of the references we have found 
> > > to our web
> > > > site
> > > > (www.telchemy.com) next week.
> > > >
> > > > Alan Clark
> > > > alan@telchemy.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: iptel-admin@lists.bell-labs.com
> > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> > > >
> > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > >
> > > > To: 'iptel@lists.bell-labs.com'
> > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > >
> > > >
> > > > hello,
> > > > some one has post this message but without answer. I 
> also need the
> > > > answer to this, can someone help me? Hi everybody, Is there 
> > > any study
> > > > that has tried to characterize the ip telephony traffic? If
> > > yes, can
> > > > somebody point me where I can find it? Thanks in advance.
> > > >
> > > >
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > IPTEL@lists.bell-labs.com
> > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > IPTEL@lists.bell-labs.com
> > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > >
> > > 
> > > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com 
> > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 07:25:16 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01036
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 07:25:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 610944434D; Tue,  7 Aug 2001 07:25:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by lists.bell-labs.com (Postfix) with SMTP id C2AFB44336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 07:24:21 -0400 (EDT)
Received: from host217-33-146-154.ietf.ignite.net (HELO kibotop) (217.33.146.154)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 11:24:20 -0000
X-Apparently-From: <kbodouhi@yahoo.com>
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: <iptel@lists.bell-labs.com>
Message-ID: <JJEOJFDNKAJPMKFNJCCGGEBNCKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [IPTEL] TRIP attributes
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 15:57:36 +0430
Content-Transfer-Encoding: 7bit


Hello all,

I would to suggest some attributes to be added to TRIP for local routing
process
to be able to make better decision for routing calls. On the overall what I
believe
is important for this purpose are as follows:

1- Gateway capacity ( included in Location protocol)
2- Gateway media ( Voice/Fax ? )
3- ASR and ACD and voice quality
4- Route stability
5- Rate ( I discussed this issue with Jonathan but it seems that his idea
was not to make things
complex and this also can not be categorize as one of TRIP functions. I
believe
adding this just like [currency, prefix, rate] will be sufficient enough for
most usages of
ITSPs and will alleviate cumbersome manual work that they are doing now to
some extent)

On the overall I believe to make things less complex , we should set aside
TRIP only for
interdomain routing betweens ITSPs and define a new less complex protocol
for intradomain.
Then we can easily enrich TRIP to satisfy needs of professional telephony
carriers.

Regards
Kiarash


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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 08:20:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02061
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 08:20:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3D28A4435E; Tue,  7 Aug 2001 08:22:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 5F5F844336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 08:21:03 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GHP00KAJ6AY44@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Tue,  7 Aug 2001 12:20:58 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GHP00L016AS6V@dgismtp02.wcomnet.com>;
 Tue, 07 Aug 2001 12:20:58 +0000 (GMT)
Received: from hsinnreich ([166.42.32.110])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GHP00DJU6AGOJ@dgismtp02.wcomnet.com>; Tue,
 07 Aug 2001 12:20:47 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: 
 <313680C9A886D511A06000204840E1CF57BECE@whq-msgusr-02.pit.comms.marconi.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>, "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Message-id: <000c01c11f3b$6319eee0$278921d9@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 13:20:40 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA02061

Brian,

> It's true that voice is likely to be a small fraction of 
> overall traffic. However, it may be a sizable percentage of 
> premium traffic.
I truly hope you are right and we will enjoy the business of premium
traffic. It does not follow however that one has to build special paths
across the Internet for premium services. Just like no special planes
are required for 1st class travel. 

And as mentioned, there are already circuit based networks there...

Henry 



> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
> Sent: Tuesday, August 07, 2001 11:10 AM
> To: 'Henry Sinnreich'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Henry
> 
> It's true that voice is likely to be a small fraction of 
> overall traffic. However, it may be a sizable percentage of 
> premium traffic.
> 
> If video takes off, video WOULD be a sizeable percentage of 
> traffic on some large nets.
> 
> Brian
> 
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > Sent: Tuesday, August 07, 2001 3:03 AM
> > To: 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > The busy hour voice traffic will most certainly be noise in
> > the overall
> > IP traffic, both on the public Internet and in well engineered
> > enterprise networks. Not the to mention the presumed 97% 
> unused fiber
> > capacity.
> > 
> > Would be interested if there are any numbers to the 
> contrary, that is 
> > voice traffic projections showing the load on the  Internet 
> to be more 
> > than noise levels compared to capacity or to total traffic load.
> > 
> > BTW: Why stop with at voice and not have special paths for 
> multimedia? 
> > For what else?
> > 
> > Thanks, Henry
> > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > > Sent: Monday, August 06, 2001 8:43 AM
> > > To: 'Henry Sinnreich'
> > > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > hello Henry,
> > > 
> > > Of course IP layer does not know weather it is a voice or a
> > > chat or something else, but I want to know it. Because we are 
> > > trying to make our own router, maybe it is important to know 
> > > the "busy hour" traffic, the jatter and other parameters. 
> > > Then we can try to do some application simulation test to our 
> > > router. This is why I want a voip model.
> > > 
> > > BRs,
> > > XuZhe
> > > 
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > Sent: Friday, August 03, 2001 10:34 PM
> > > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > Alan,
> > > 
> > > Segregating traffic over the Internet by application seems a
> > > strange idea. Segregating by classes of traffic is OK and 
> > > already dealt with by DiffServ. Besides, predictions show 
> > > that voice will amount to a small percentage of overall IP 
> > > traffic..., but maybe we can discuss at the IETF.
> > > 
> > > Thanks, Henry
> > > 
> > > > -----Original Message-----
> > > > From: Alan Clark [mailto:alan@telchemy.com]
> > > > Sent: Friday, August 03, 2001 9:34 PM
> > > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > 
> > > > 
> > > > 
> > > > Henry
> > > > 
> > > > We are assuming that service providers such as Worldcom have a 
> > > > dedicated IP network and are not using the Internet for long 
> > > > distance/ international telephone traffic. From the 
> discussions we 
> > > > have had with some of your competitors it does appear to be a 
> > > > reasonable assumption that many service providers plan 
> to have a 
> > > > packet based backbone that may be used for both voice and data 
> > > > traffic, and potentially for video.  It also appears a 
> reasonable 
> > > > assumption that you would want to preserve some 
> separation between 
> > > > voice and data services using either diffserv or MPLS in order 
> > > > that you can prevent spikes in data traffic from 
> causing excessive 
> > > > packet loss and jitter in voice traffic. We are modeling the
> > > > behavior of aggregate VoIP streams and "interfering" bulk 
> > > > data traffic over IP networks that use techniques such as 
> > > > CBQ, WRED etc.  In general you would expect that segregating 
> > > > voice and data traffic would eliminate QoS issues however 
> > > > there is still scope for some level of interference - we are 
> > > > interested in both the nature of (even minor) network 
> > > > impairments that may result from this scenario and in the 
> > > > "real time traffic engineering" problem.
> > > > 
> > > > Regards
> > > > 
> > > > Alan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > Sent: Friday, August 03, 2001 3:09 PM
> > > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > 
> > > > 
> > > > Please help me understand:
> > > > Do you really want to separate VoIP traffic from other IP 
> > > > applications? Can you separate it? Is it a good idea to 
> balkanize 
> > > > the Internet for various applications?
> > > > 
> > > > BTW: We already have separate voice network...
> > > > 
> > > > Thanks,Henry
> > > > 
> > > > Henry Sinnreich
> > > > WorldCom
> > > > 400 International Parkway
> > > > Richardson, Texas 75081
> > > > USA
> > > > 
> > > > > -----Original Message-----
> > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of 
> Alan Clark
> > > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > >
> > > > > Telchemy is currently conducting research in this 
> area, building 
> > > > > aggregate VoIP traffic models for NS-2 as part of our work on 
> > > > > performance analysis of large scale VoIP networks.  We
> > > have done a
> > > > > fairly comprehensive literature survey, are (re)doing
> > > > analytical work
> > > > > and simulation studies.
> > > > >
> > > > > We would be interested to exchange information with
> > other research
> > > > > groups, and will add a list of the references we have found
> > > > to our web
> > > > > site
> > > > > (www.telchemy.com) next week.
> > > > >
> > > > > Alan Clark
> > > > > alan@telchemy.com
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
> > > > >
> > > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > > >
> > > > > To: 'iptel@lists.bell-labs.com'
> > > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > hello,
> > > > > some one has post this message but without answer. I
> > also need the
> > > > > answer to this, can someone help me? Hi everybody, Is there
> > > > any study
> > > > > that has tried to characterize the ip telephony traffic? If
> > > > yes, can
> > > > > somebody point me where I can find it? Thanks in advance.
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IPTEL mailing list
> > > > > IPTEL@lists.bell-labs.com
> > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IPTEL mailing list
> > > > > IPTEL@lists.bell-labs.com
> > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > >
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com
> > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > 
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com 
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> > 
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 08:36:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02298
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 08:36:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8BADC4436B; Tue,  7 Aug 2001 08:38:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id AA8A244361
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 08:37:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA23186;
	Tue, 7 Aug 2001 08:37:47 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA13132;
	Tue, 7 Aug 2001 08:37:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRCK7M>; Tue, 7 Aug 2001 08:37:47 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57BED4@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 08:37:46 -0400

It may be that we do it with no special paths, but I suspect that
we will use things like different MPLS lsps for premium traffic in
many cases.

Whether we do or don't, understanding the traffic patterns is
important work.  I don't see much for the IETF to do with it
though.

Brian

> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Tuesday, August 07, 2001 8:21 AM
> To: 'Rosen, Brian'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Brian,
> 
> > It's true that voice is likely to be a small fraction of 
> > overall traffic. However, it may be a sizable percentage of 
> > premium traffic.
> I truly hope you are right and we will enjoy the business of premium
> traffic. It does not follow however that one has to build 
> special paths
> across the Internet for premium services. Just like no special planes
> are required for 1st class travel. 
> 
> And as mentioned, there are already circuit based networks there...
> 
> Henry 
> 
> 
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
> > Sent: Tuesday, August 07, 2001 11:10 AM
> > To: 'Henry Sinnreich'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > Henry
> > 
> > It's true that voice is likely to be a small fraction of 
> > overall traffic. However, it may be a sizable percentage of 
> > premium traffic.
> > 
> > If video takes off, video WOULD be a sizeable percentage of 
> > traffic on some large nets.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > Sent: Tuesday, August 07, 2001 3:03 AM
> > > To: 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > The busy hour voice traffic will most certainly be noise in
> > > the overall
> > > IP traffic, both on the public Internet and in well engineered
> > > enterprise networks. Not the to mention the presumed 97% 
> > unused fiber
> > > capacity.
> > > 
> > > Would be interested if there are any numbers to the 
> > contrary, that is 
> > > voice traffic projections showing the load on the  Internet 
> > to be more 
> > > than noise levels compared to capacity or to total traffic load.
> > > 
> > > BTW: Why stop with at voice and not have special paths for 
> > multimedia? 
> > > For what else?
> > > 
> > > Thanks, Henry
> > > 
> > > > -----Original Message-----
> > > > From: iptel-admin@lists.bell-labs.com
> > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > > > Sent: Monday, August 06, 2001 8:43 AM
> > > > To: 'Henry Sinnreich'
> > > > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > 
> > > > 
> > > > hello Henry,
> > > > 
> > > > Of course IP layer does not know weather it is a voice or a
> > > > chat or something else, but I want to know it. Because we are 
> > > > trying to make our own router, maybe it is important to know 
> > > > the "busy hour" traffic, the jatter and other parameters. 
> > > > Then we can try to do some application simulation test to our 
> > > > router. This is why I want a voip model.
> > > > 
> > > > BRs,
> > > > XuZhe
> > > > 
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > Sent: Friday, August 03, 2001 10:34 PM
> > > > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > 
> > > > 
> > > > Alan,
> > > > 
> > > > Segregating traffic over the Internet by application seems a
> > > > strange idea. Segregating by classes of traffic is OK and 
> > > > already dealt with by DiffServ. Besides, predictions show 
> > > > that voice will amount to a small percentage of overall IP 
> > > > traffic..., but maybe we can discuss at the IETF.
> > > > 
> > > > Thanks, Henry
> > > > 
> > > > > -----Original Message-----
> > > > > From: Alan Clark [mailto:alan@telchemy.com]
> > > > > Sent: Friday, August 03, 2001 9:34 PM
> > > > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > 
> > > > > 
> > > > > 
> > > > > Henry
> > > > > 
> > > > > We are assuming that service providers such as 
> Worldcom have a 
> > > > > dedicated IP network and are not using the Internet for long 
> > > > > distance/ international telephone traffic. From the 
> > discussions we 
> > > > > have had with some of your competitors it does appear to be a 
> > > > > reasonable assumption that many service providers plan 
> > to have a 
> > > > > packet based backbone that may be used for both voice 
> and data 
> > > > > traffic, and potentially for video.  It also appears a 
> > reasonable 
> > > > > assumption that you would want to preserve some 
> > separation between 
> > > > > voice and data services using either diffserv or MPLS 
> in order 
> > > > > that you can prevent spikes in data traffic from 
> > causing excessive 
> > > > > packet loss and jitter in voice traffic. We are modeling the
> > > > > behavior of aggregate VoIP streams and "interfering" bulk 
> > > > > data traffic over IP networks that use techniques such as 
> > > > > CBQ, WRED etc.  In general you would expect that segregating 
> > > > > voice and data traffic would eliminate QoS issues however 
> > > > > there is still scope for some level of interference - we are 
> > > > > interested in both the nature of (even minor) network 
> > > > > impairments that may result from this scenario and in the 
> > > > > "real time traffic engineering" problem.
> > > > > 
> > > > > Regards
> > > > > 
> > > > > Alan
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > Sent: Friday, August 03, 2001 3:09 PM
> > > > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > 
> > > > > 
> > > > > Please help me understand:
> > > > > Do you really want to separate VoIP traffic from other IP 
> > > > > applications? Can you separate it? Is it a good idea to 
> > balkanize 
> > > > > the Internet for various applications?
> > > > > 
> > > > > BTW: We already have separate voice network...
> > > > > 
> > > > > Thanks,Henry
> > > > > 
> > > > > Henry Sinnreich
> > > > > WorldCom
> > > > > 400 International Parkway
> > > > > Richardson, Texas 75081
> > > > > USA
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of 
> > Alan Clark
> > > > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > >
> > > > > > Telchemy is currently conducting research in this 
> > area, building 
> > > > > > aggregate VoIP traffic models for NS-2 as part of 
> our work on 
> > > > > > performance analysis of large scale VoIP networks.  We
> > > > have done a
> > > > > > fairly comprehensive literature survey, are (re)doing
> > > > > analytical work
> > > > > > and simulation studies.
> > > > > >
> > > > > > We would be interested to exchange information with
> > > other research
> > > > > > groups, and will add a list of the references we have found
> > > > > to our web
> > > > > > site
> > > > > > (www.telchemy.com) next week.
> > > > > >
> > > > > > Alan Clark
> > > > > > alan@telchemy.com
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf 
> Of Xu Zhe
> > > > > >
> > > > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > > > >
> > > > > > To: 'iptel@lists.bell-labs.com'
> > > > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > > hello,
> > > > > > some one has post this message but without answer. I
> > > also need the
> > > > > > answer to this, can someone help me? Hi everybody, Is there
> > > > > any study
> > > > > > that has tried to characterize the ip telephony traffic? If
> > > > > yes, can
> > > > > > somebody point me where I can find it? Thanks in advance.
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > IPTEL mailing list
> > > > > > IPTEL@lists.bell-labs.com
> > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > IPTEL mailing list
> > > > > > IPTEL@lists.bell-labs.com
> > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > >
> > > > > 
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > IPTEL@lists.bell-labs.com
> > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com 
> > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > > 
> > 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 10:08:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04399
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:08:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7151F44337; Tue,  7 Aug 2001 10:10:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from WIN2K-SRV-001.reddo.net (57.131.88.213.host.tele1europe.se [213.88.131.57])
	by lists.bell-labs.com (Postfix) with ESMTP id 9B4F544336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 04:24:23 -0400 (EDT)
Received: by WIN2K-SRV-001.reddo.net with Internet Mail Service (5.5.2650.21)
	id <Q1GSCZ2M>; Tue, 7 Aug 2001 10:19:47 +0200
Message-ID: <8346B686B0DBC1469AA5307F8BABBB3F0C4DB1@WIN2K-SRV-001.reddo.net>
From: Jerry <jerry@reddo.net>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>
Cc: iptel@lists.bell-labs.com, alan@telchemy.com
Subject: RE: [IPTEL] urgent: ip telephony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 10:19:46 +0200

hello Henry,

Just compare to a mobile network, there the busy hour (burst hour) traffic
is a very important factor for determine the network capacity. So the
service provider and device provider can determine what kind device they
need to use or to provide. And other factors such as call time or erlang are
also very important.
I think it should be simular in voice traffic. Of course multimedia is very
important and I will try to setup a model later.

BRs,

XuZhe

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 10:11:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04459
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:11:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E10D744371; Tue,  7 Aug 2001 10:10:06 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58])
	by lists.bell-labs.com (Postfix) with SMTP id E18B244336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 07:08:29 -0400 (EDT)
Received: from host217-33-146-154.ietf.ignite.net (HELO kibotop) (217.33.146.154)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 11:08:29 -0000
X-Apparently-From: <kbodouhi@yahoo.com>
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: <Sinnreich.henry.sinnreich@wcom.com>, <iptel@lists.bell-labs.com>
Message-ID: <JJEOJFDNKAJPMKFNJCCGEEBMCKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [IPTEL] (no subject)
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 15:41:44 +0430
Content-Transfer-Encoding: 7bit

>Please help me understand:
>Do you really want to separate VoIP traffic from other IP applications?
>Can you separate it? Is it a good idea to balkanize the Internet for
>various applications?

I believe the market will tell us what is needed and what is not. Currently
we have lots of ITSPs and clearing house systems that do all the jobs
manually
for routing VoIP. I don't believe such thing has happened to other
applications
as well but when it looks that it is needed for those, we can then discuss
it.
On the overall, I believe these networks in network (Internet) will increase
soon
in future and what I understood from Henry's word is that what will be the
destiny
of such complex maze like networks. I guess we have to resolve this problem
later
when it is going to happen. But I believe the whole idea of these virtual
networks
on top of IP is great thing and is a natural phenomena of internet influence
on
other applications.

>BTW: We already have separate voice network...

Regards
Kiarash Bodouhi

Solarson Enterprises



>Thanks,Henry

>Henry Sinnreich
>WorldCom
>400 International Parkway
>Richardson, Texas 75081
>USA

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Alan Clark
> Sent: Thursday, August 02, 2001 5:35 PM
> To: Xu Zhe; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
>
>
>
> Telchemy is currently conducting research in this area,
> building aggregate VoIP traffic models for NS-2 as part of
> our work on performance analysis of large scale VoIP
> networks.  We have done a fairly comprehensive literature
> survey, are (re)doing analytical work and simulation studies.
>
> We would be interested to exchange information with other
> research groups, and will add a list of the references we
> have found to our web site
> (www.telchemy.com) next week.
>
> Alan Clark
> alan@telchemy.com
>
>
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]> On Behalf Of Xu Zhe
>
> Sent: Thursday, August 02, 2001 5:13 AM
>
> To: 'iptel@lists.bell-labs.com'
> Subject: [IPTEL] urgent: ip telphony traffic model
>
>
> hello,
> some one has post this message but without answer. I also
> need the answer to this, can someone help me? Hi everybody,
> Is there any study that has tried to characterize the ip
> telephony traffic? If yes, can somebody point me where I can
> find it? Thanks in advance.
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>
>
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>



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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 10:36:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05013
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:36:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 68E924433B; Tue,  7 Aug 2001 10:38:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 425BE44336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 10:37:13 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GHP00DAKCLU59@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Tue,  7 Aug 2001 14:37:06 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHP00501CLQQ5@pmismtp01.wcomnet.com>;
 Tue, 07 Aug 2001 14:37:05 +0000 (GMT)
Received: from hsinnreich ([166.44.139.31])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHP002I3CL3M4@pmismtp01.wcomnet.com>; Tue,
 07 Aug 2001 14:36:47 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: 
 <313680C9A886D511A06000204840E1CF57BED4@whq-msgusr-02.pit.comms.marconi.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>, "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Message-id: <000201c11f4e$63cffdd0$1f8b2ca6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 15:36:41 +0100
Content-Transfer-Encoding: 7bit

Brian,
>I suspect
> that we will use things like different MPLS lsps for premium
> traffic in many cases.

Possibly agree, and the discriminator is not voice, but the word is
"premium" for whatever users want to pay more.

Henry

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Rosen, Brian
> Sent: Tuesday, August 07, 2001 1:38 PM
> To: 'Henry Sinnreich'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> It may be that we do it with no special paths, but I suspect that we 
> will use things like different MPLS lsps for premium traffic in many 
> cases.
> 
> Whether we do or don't, understanding the traffic patterns is 
> important work.  I don't see much for the IETF to do with it though.
> 
> Brian


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 10:38:23 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAB05058
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:38:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 231D24437A; Tue,  7 Aug 2001 10:38:06 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114])
	by lists.bell-labs.com (Postfix) with SMTP id 08DA244336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 10:37:49 -0400 (EDT)
Received: from host217-33-146-154.ietf.ignite.net (HELO kibotop) (217.33.146.154)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 14:37:48 -0000
X-Apparently-From: <kbodouhi@yahoo.com>
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: <alan@telchemy.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Message-ID: <JJEOJFDNKAJPMKFNJCCGMECBCKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <313680C9A886D511A06000204840E1CF57BED4@whq-msgusr-02.pit.comms.marconi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 19:11:02 +0430
Content-Transfer-Encoding: 7bit



Hi again,

Sorry. Now I got what Henry meant. For me it is like sitting and seeing
a movie in the middle. I hope you forgive me as a newcomer. I believe
the reality is that many carriers have already separated VoIP from Internet.
This is not good. As Henry mentioned we have already had circuit switched
networks with dedicated bandwidth and quality of service there.

Regards
Kiarash

  > -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Rosen, Brian
> Sent: Tue, August 07, 2001 5:08 PM
> To: 'Henry Sinnreich'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
>
>
> It may be that we do it with no special paths, but I suspect that
> we will use things like different MPLS lsps for premium traffic in
> many cases.
>
> Whether we do or don't, understanding the traffic patterns is
> important work.  I don't see much for the IETF to do with it
> though.
>
> Brian
>
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > Sent: Tuesday, August 07, 2001 8:21 AM
> > To: 'Rosen, Brian'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > Brian,
> >
> > > It's true that voice is likely to be a small fraction of
> > > overall traffic. However, it may be a sizable percentage of
> > > premium traffic.
> > I truly hope you are right and we will enjoy the business of premium
> > traffic. It does not follow however that one has to build
> > special paths
> > across the Internet for premium services. Just like no special planes
> > are required for 1st class travel.
> >
> > And as mentioned, there are already circuit based networks there...
> >
> > Henry
> >
> >
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Tuesday, August 07, 2001 11:10 AM
> > > To: 'Henry Sinnreich'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > > Henry
> > >
> > > It's true that voice is likely to be a small fraction of
> > > overall traffic. However, it may be a sizable percentage of
> > > premium traffic.
> > >
> > > If video takes off, video WOULD be a sizeable percentage of
> > > traffic on some large nets.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > Sent: Tuesday, August 07, 2001 3:03 AM
> > > > To: 'Jerry'
> > > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > >
> > > >
> > > > The busy hour voice traffic will most certainly be noise in
> > > > the overall
> > > > IP traffic, both on the public Internet and in well engineered
> > > > enterprise networks. Not the to mention the presumed 97%
> > > unused fiber
> > > > capacity.
> > > >
> > > > Would be interested if there are any numbers to the
> > > contrary, that is
> > > > voice traffic projections showing the load on the  Internet
> > > to be more
> > > > than noise levels compared to capacity or to total traffic load.
> > > >
> > > > BTW: Why stop with at voice and not have special paths for
> > > multimedia?
> > > > For what else?
> > > >
> > > > Thanks, Henry
> > > >
> > > > > -----Original Message-----
> > > > > From: iptel-admin@lists.bell-labs.com
> > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > > > > Sent: Monday, August 06, 2001 8:43 AM
> > > > > To: 'Henry Sinnreich'
> > > > > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > hello Henry,
> > > > >
> > > > > Of course IP layer does not know weather it is a voice or a
> > > > > chat or something else, but I want to know it. Because we are
> > > > > trying to make our own router, maybe it is important to know
> > > > > the "busy hour" traffic, the jatter and other parameters.
> > > > > Then we can try to do some application simulation test to our
> > > > > router. This is why I want a voip model.
> > > > >
> > > > > BRs,
> > > > > XuZhe
> > > > >
> > > > > -----Original Message-----
> > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > Sent: Friday, August 03, 2001 10:34 PM
> > > > > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > Alan,
> > > > >
> > > > > Segregating traffic over the Internet by application seems a
> > > > > strange idea. Segregating by classes of traffic is OK and
> > > > > already dealt with by DiffServ. Besides, predictions show
> > > > > that voice will amount to a small percentage of overall IP
> > > > > traffic..., but maybe we can discuss at the IETF.
> > > > >
> > > > > Thanks, Henry
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alan Clark [mailto:alan@telchemy.com]
> > > > > > Sent: Friday, August 03, 2001 9:34 PM
> > > > > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > >
> > > > > > Henry
> > > > > >
> > > > > > We are assuming that service providers such as
> > Worldcom have a
> > > > > > dedicated IP network and are not using the Internet for long
> > > > > > distance/ international telephone traffic. From the
> > > discussions we
> > > > > > have had with some of your competitors it does appear to be a
> > > > > > reasonable assumption that many service providers plan
> > > to have a
> > > > > > packet based backbone that may be used for both voice
> > and data
> > > > > > traffic, and potentially for video.  It also appears a
> > > reasonable
> > > > > > assumption that you would want to preserve some
> > > separation between
> > > > > > voice and data services using either diffserv or MPLS
> > in order
> > > > > > that you can prevent spikes in data traffic from
> > > causing excessive
> > > > > > packet loss and jitter in voice traffic. We are modeling the
> > > > > > behavior of aggregate VoIP streams and "interfering" bulk
> > > > > > data traffic over IP networks that use techniques such as
> > > > > > CBQ, WRED etc.  In general you would expect that segregating
> > > > > > voice and data traffic would eliminate QoS issues however
> > > > > > there is still scope for some level of interference - we are
> > > > > > interested in both the nature of (even minor) network
> > > > > > impairments that may result from this scenario and in the
> > > > > > "real time traffic engineering" problem.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > > Sent: Friday, August 03, 2001 3:09 PM
> > > > > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > > Please help me understand:
> > > > > > Do you really want to separate VoIP traffic from other IP
> > > > > > applications? Can you separate it? Is it a good idea to
> > > balkanize
> > > > > > the Internet for various applications?
> > > > > >
> > > > > > BTW: We already have separate voice network...
> > > > > >
> > > > > > Thanks,Henry
> > > > > >
> > > > > > Henry Sinnreich
> > > > > > WorldCom
> > > > > > 400 International Parkway
> > > > > > Richardson, Texas 75081
> > > > > > USA
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: iptel-admin@lists.bell-labs.com
> > > > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of
> > > Alan Clark
> > > > > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Telchemy is currently conducting research in this
> > > area, building
> > > > > > > aggregate VoIP traffic models for NS-2 as part of
> > our work on
> > > > > > > performance analysis of large scale VoIP networks.  We
> > > > > have done a
> > > > > > > fairly comprehensive literature survey, are (re)doing
> > > > > > analytical work
> > > > > > > and simulation studies.
> > > > > > >
> > > > > > > We would be interested to exchange information with
> > > > other research
> > > > > > > groups, and will add a list of the references we have found
> > > > > > to our web
> > > > > > > site
> > > > > > > (www.telchemy.com) next week.
> > > > > > >
> > > > > > > Alan Clark
> > > > > > > alan@telchemy.com
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: iptel-admin@lists.bell-labs.com
> > > > > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf
> > Of Xu Zhe
> > > > > > >
> > > > > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > > > > >
> > > > > > > To: 'iptel@lists.bell-labs.com'
> > > > > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > > hello,
> > > > > > > some one has post this message but without answer. I
> > > > also need the
> > > > > > > answer to this, can someone help me? Hi everybody, Is there
> > > > > > any study
> > > > > > > that has tried to characterize the ip telephony traffic? If
> > > > > > yes, can
> > > > > > > somebody point me where I can find it? Thanks in advance.
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > IPTEL mailing list
> > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > IPTEL mailing list
> > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IPTEL mailing list
> > > > > IPTEL@lists.bell-labs.com
> > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > IPTEL@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > > >
> > >
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> >
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 10:43:11 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05158
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:43:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DEB654437F; Tue,  7 Aug 2001 10:44:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58])
	by lists.bell-labs.com (Postfix) with SMTP id 701634436E
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 10:43:45 -0400 (EDT)
Received: from host217-33-146-154.ietf.ignite.net (HELO kibotop) (217.33.146.154)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 14:43:44 -0000
X-Apparently-From: <kbodouhi@yahoo.com>
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: "Henry Sinnreich" <henry.sinnreich@wcom.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: <alan@telchemy.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Message-ID: <JJEOJFDNKAJPMKFNJCCGGECCCKAA.kbodouhi@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000201c11f4e$63cffdd0$1f8b2ca6@open.wcomnet.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 19:16:59 +0430
Content-Transfer-Encoding: 7bit


Hi,

What if the percentage of this premium services become 70% of the actual
bandwidth. In that case, what will be called premium? The 70% part or that
30%?

Kiarash

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Henry Sinnreich
> Sent: Tue, August 07, 2001 7:07 PM
> To: 'Rosen, Brian'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> Brian,
> >I suspect
> > that we will use things like different MPLS lsps for premium
> > traffic in many cases.
> 
> Possibly agree, and the discriminator is not voice, but the word is
> "premium" for whatever users want to pay more.
> 
> Henry
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Rosen, Brian
> > Sent: Tuesday, August 07, 2001 1:38 PM
> > To: 'Henry Sinnreich'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > It may be that we do it with no special paths, but I suspect that we 
> > will use things like different MPLS lsps for premium traffic in many 
> > cases.
> > 
> > Whether we do or don't, understanding the traffic patterns is 
> > important work.  I don't see much for the IETF to do with it though.
> > 
> > Brian
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 11:38:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06528
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 11:38:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 93CD64433A; Tue,  7 Aug 2001 11:40:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id C1BB744336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 11:39:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23086;
	Tue, 7 Aug 2001 11:39:16 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15141;
	Tue, 7 Aug 2001 11:39:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRC5KJ>; Tue, 7 Aug 2001 11:39:03 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57BED9@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        Henry Sinnreich <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 11:38:10 -0400

I think we are getting pretty far ahead of ourselves, but it
could happen if we get a lot of, for example, video services.
Were that to happen, lots of the bits would be premium bits.
I'm not sure that we should spend a lot of time worrying 
about that now, but I also think we should be prepared to
deal with it some time in the not-too-distant future.
If that were to happen, we would have to lower the oversubscription
ratios we currently employ, and we would have to do much
better traffic engineering.

A part we need which we don't talk about much is policing.
Premium service only works if the network can limit the
amount of traffic marked premium.  The ability of routers
to police real time traffic is, aaah, limited.

I would point out that we could be embarrased by success --
if a large voice carrier decided to switch to a converged
network tomorrow, it would be the case that 50-90% of the
bits on its network would be voice bits.  The 10% number
that many toss around assumes the convergence happens over
time, at at the same time, the data traffic increases at
the rate it has been increasing.

The point Henry makes, which I agree with 100% is that WHAT
the traffic represents is not the descriminator on what
is done to the bits.  Premium data bits will be treated
as premium audio bits or premium video bits.

I do think that one big difference between audio/video and
the general purpose data bits is that there is the very 
real possibility of admission control.  That means only that
you can fail more appropriately (return busy rather than 
poor quality audio/video).  This is admission control on
a DiffServ network (admission control with IntServ is
already there).

Brian

> -----Original Message-----
> From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
> Sent: Tuesday, August 07, 2001 10:47 AM
> To: Henry Sinnreich; 'Rosen, Brian'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Hi,
> 
> What if the percentage of this premium services become 70% of 
> the actual
> bandwidth. In that case, what will be called premium? The 70% 
> part or that
> 30%?
> 
> Kiarash
> 
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Henry Sinnreich
> > Sent: Tue, August 07, 2001 7:07 PM
> > To: 'Rosen, Brian'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > Brian,
> > >I suspect
> > > that we will use things like different MPLS lsps for premium
> > > traffic in many cases.
> > 
> > Possibly agree, and the discriminator is not voice, but the word is
> > "premium" for whatever users want to pay more.
> > 
> > Henry
> > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com 
> > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Rosen, Brian
> > > Sent: Tuesday, August 07, 2001 1:38 PM
> > > To: 'Henry Sinnreich'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > It may be that we do it with no special paths, but I 
> suspect that we 
> > > will use things like different MPLS lsps for premium 
> traffic in many 
> > > cases.
> > > 
> > > Whether we do or don't, understanding the traffic patterns is 
> > > important work.  I don't see much for the IETF to do with 
> it though.
> > > 
> > > Brian
> > 
> > 
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 11:57:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06858
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 11:57:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4752F4436F; Tue,  7 Aug 2001 11:59:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailserver.sylantro.com (unknown [65.200.90.207])
	by lists.bell-labs.com (Postfix) with SMTP id 340494436E
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 11:58:07 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 07 Aug 2001 08:55:22 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <P0BQCS9X>; Tue, 7 Aug 2001 08:55:22 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBDA7BAB0@mailserver.sylantro.com>
From: "Joe Aiello" <Joe.Aiello@sylantro.com>
To: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 176ED0E0114700-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 08:55:14 -0700
Content-Transfer-Encoding: 7bit

I see the issue being a bit more problematic.  The current modeling would
show barely a percentage of VoIP on The Internet.  However, new service
providers are just now selling enhanced VoIP services.  Carriers are just
now looking at VoIP for enhanced services.  There will be a rich suite of
applications and services that just can not be done in the switched world
and certainly can not be done as quickly as in a packet world.  I foresee a
gradual increase to about one percent in the next 12 to 15 months.  When the
large service providers have a new infrastructure in place supporting large
gateways to the public switched network, there will likely be bulk surge in
VoIP usage over The Internet.  But that is likely to be only another one to
1.5 percent.

Before we see real usage, the service providers have to be sure it is toll
quality and can guarantee service levels.  That will take some time.  I
expect more short jumps on and off The Internet in a more controllable area.
This kind of usage will be hard to model.  Voice is rather easy to do.
Getting service providers to trust VoIP is not so easy.  Once they trust the
infrastructure, there will be some incremental changes to traffic as they
add video services and whatever else that can pump out.  I really expect us
to turn around one day and say "How did that happen" rather than us watch
the river rise.

Regards,
Joe Aiello

 -----Original Message-----
From: 	Kiarash Bodouhi [mailto:kbodouhi@yahoo.com] 
Sent:	Tuesday, August 07, 2001 7:41 AM
To:	Rosen, Brian; 'Henry Sinnreich'; 'Jerry'
Cc:	alan@telchemy.com; iptel@lists.bell-labs.com
Subject:	RE: [IPTEL] urgent: ip telphony traffic model



Hi again,

Sorry. Now I got what Henry meant. For me it is like sitting and seeing
a movie in the middle. I hope you forgive me as a newcomer. I believe
the reality is that many carriers have already separated VoIP from Internet.
This is not good. As Henry mentioned we have already had circuit switched
networks with dedicated bandwidth and quality of service there.

Regards
Kiarash

  > -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Rosen, Brian
> Sent: Tue, August 07, 2001 5:08 PM
> To: 'Henry Sinnreich'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
>
>
> It may be that we do it with no special paths, but I suspect that
> we will use things like different MPLS lsps for premium traffic in
> many cases.
>
> Whether we do or don't, understanding the traffic patterns is
> important work.  I don't see much for the IETF to do with it
> though.
>
> Brian
>
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > Sent: Tuesday, August 07, 2001 8:21 AM
> > To: 'Rosen, Brian'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > Brian,
> >
> > > It's true that voice is likely to be a small fraction of
> > > overall traffic. However, it may be a sizable percentage of
> > > premium traffic.
> > I truly hope you are right and we will enjoy the business of premium
> > traffic. It does not follow however that one has to build
> > special paths
> > across the Internet for premium services. Just like no special planes
> > are required for 1st class travel.
> >
> > And as mentioned, there are already circuit based networks there...
> >
> > Henry
> >
> >
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Tuesday, August 07, 2001 11:10 AM
> > > To: 'Henry Sinnreich'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > > Henry
> > >
> > > It's true that voice is likely to be a small fraction of
> > > overall traffic. However, it may be a sizable percentage of
> > > premium traffic.
> > >
> > > If video takes off, video WOULD be a sizeable percentage of
> > > traffic on some large nets.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > Sent: Tuesday, August 07, 2001 3:03 AM
> > > > To: 'Jerry'
> > > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > >
> > > >
> > > > The busy hour voice traffic will most certainly be noise in
> > > > the overall
> > > > IP traffic, both on the public Internet and in well engineered
> > > > enterprise networks. Not the to mention the presumed 97%
> > > unused fiber
> > > > capacity.
> > > >
> > > > Would be interested if there are any numbers to the
> > > contrary, that is
> > > > voice traffic projections showing the load on the  Internet
> > > to be more
> > > > than noise levels compared to capacity or to total traffic load.
> > > >
> > > > BTW: Why stop with at voice and not have special paths for
> > > multimedia?
> > > > For what else?
> > > >
> > > > Thanks, Henry
> > > >
> > > > > -----Original Message-----
> > > > > From: iptel-admin@lists.bell-labs.com
> > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > > > > Sent: Monday, August 06, 2001 8:43 AM
> > > > > To: 'Henry Sinnreich'
> > > > > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > hello Henry,
> > > > >
> > > > > Of course IP layer does not know weather it is a voice or a
> > > > > chat or something else, but I want to know it. Because we are
> > > > > trying to make our own router, maybe it is important to know
> > > > > the "busy hour" traffic, the jatter and other parameters.
> > > > > Then we can try to do some application simulation test to our
> > > > > router. This is why I want a voip model.
> > > > >
> > > > > BRs,
> > > > > XuZhe
> > > > >
> > > > > -----Original Message-----
> > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > Sent: Friday, August 03, 2001 10:34 PM
> > > > > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > Alan,
> > > > >
> > > > > Segregating traffic over the Internet by application seems a
> > > > > strange idea. Segregating by classes of traffic is OK and
> > > > > already dealt with by DiffServ. Besides, predictions show
> > > > > that voice will amount to a small percentage of overall IP
> > > > > traffic..., but maybe we can discuss at the IETF.
> > > > >
> > > > > Thanks, Henry
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alan Clark [mailto:alan@telchemy.com]
> > > > > > Sent: Friday, August 03, 2001 9:34 PM
> > > > > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > >
> > > > > > Henry
> > > > > >
> > > > > > We are assuming that service providers such as
> > Worldcom have a
> > > > > > dedicated IP network and are not using the Internet for long
> > > > > > distance/ international telephone traffic. From the
> > > discussions we
> > > > > > have had with some of your competitors it does appear to be a
> > > > > > reasonable assumption that many service providers plan
> > > to have a
> > > > > > packet based backbone that may be used for both voice
> > and data
> > > > > > traffic, and potentially for video.  It also appears a
> > > reasonable
> > > > > > assumption that you would want to preserve some
> > > separation between
> > > > > > voice and data services using either diffserv or MPLS
> > in order
> > > > > > that you can prevent spikes in data traffic from
> > > causing excessive
> > > > > > packet loss and jitter in voice traffic. We are modeling the
> > > > > > behavior of aggregate VoIP streams and "interfering" bulk
> > > > > > data traffic over IP networks that use techniques such as
> > > > > > CBQ, WRED etc.  In general you would expect that segregating
> > > > > > voice and data traffic would eliminate QoS issues however
> > > > > > there is still scope for some level of interference - we are
> > > > > > interested in both the nature of (even minor) network
> > > > > > impairments that may result from this scenario and in the
> > > > > > "real time traffic engineering" problem.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > > Sent: Friday, August 03, 2001 3:09 PM
> > > > > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > > Please help me understand:
> > > > > > Do you really want to separate VoIP traffic from other IP
> > > > > > applications? Can you separate it? Is it a good idea to
> > > balkanize
> > > > > > the Internet for various applications?
> > > > > >
> > > > > > BTW: We already have separate voice network...
> > > > > >
> > > > > > Thanks,Henry
> > > > > >
> > > > > > Henry Sinnreich
> > > > > > WorldCom
> > > > > > 400 International Parkway
> > > > > > Richardson, Texas 75081
> > > > > > USA
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: iptel-admin@lists.bell-labs.com
> > > > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of
> > > Alan Clark
> > > > > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Telchemy is currently conducting research in this
> > > area, building
> > > > > > > aggregate VoIP traffic models for NS-2 as part of
> > our work on
> > > > > > > performance analysis of large scale VoIP networks.  We
> > > > > have done a
> > > > > > > fairly comprehensive literature survey, are (re)doing
> > > > > > analytical work
> > > > > > > and simulation studies.
> > > > > > >
> > > > > > > We would be interested to exchange information with
> > > > other research
> > > > > > > groups, and will add a list of the references we have found
> > > > > > to our web
> > > > > > > site
> > > > > > > (www.telchemy.com) next week.
> > > > > > >
> > > > > > > Alan Clark
> > > > > > > alan@telchemy.com
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: iptel-admin@lists.bell-labs.com
> > > > > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf
> > Of Xu Zhe
> > > > > > >
> > > > > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > > > > >
> > > > > > > To: 'iptel@lists.bell-labs.com'
> > > > > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > > hello,
> > > > > > > some one has post this message but without answer. I
> > > > also need the
> > > > > > > answer to this, can someone help me? Hi everybody, Is there
> > > > > > any study
> > > > > > > that has tried to characterize the ip telephony traffic? If
> > > > > > yes, can
> > > > > > > somebody point me where I can find it? Thanks in advance.
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > IPTEL mailing list
> > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > IPTEL mailing list
> > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IPTEL mailing list
> > > > > IPTEL@lists.bell-labs.com
> > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > IPTEL@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > > >
> > >
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> >
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 12:11:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07291
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 12:11:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 49FB144379; Tue,  7 Aug 2001 12:13:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 9C0CC44379
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 12:12:56 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GHP00CFIH1I41@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Tue,  7 Aug 2001 16:12:54 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GHP00601H1CGA@dgismtp02.wcomnet.com>;
 Tue, 07 Aug 2001 16:12:54 +0000 (GMT)
Received: from hsinnreich ([166.42.40.76])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GHP002IPH112P@dgismtp02.wcomnet.com>; Tue,
 07 Aug 2001 16:12:38 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telephony traffic model
In-reply-to: <8346B686B0DBC1469AA5307F8BABBB3F0C4DB1@WIN2K-SRV-001.reddo.net>
To: "'Jerry'" <jerry@reddo.net>
Cc: iptel@lists.bell-labs.com, alan@telchemy.com
Message-id: <000001c11f5b$c8520cf0$278921d9@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 17:12:39 +0100
Content-Transfer-Encoding: 7bit

We have company in this discussion about building paths across the net.

See "Experts call MPLS bad for 'Net".
VPNs based on Multi-protocol Label Switching said to be risky. Backbone
mgmt. challenges also cited. By CAROLYN DUFFY MARSAN Network World,
08/06/01

http://www.nwfusion.com/news/2001/0806mpls.html

Henry



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 12:32:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07827
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 12:32:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6BD344433D; Tue,  7 Aug 2001 12:34:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 0988A44336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 12:33:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00885;
	Tue, 7 Aug 2001 12:33:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02221;
	Tue, 7 Aug 2001 12:33:22 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRC9LF>; Tue, 7 Aug 2001 12:33:20 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57BEDE@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: iptel@lists.bell-labs.com, alan@telchemy.com
Subject: RE: [IPTEL] urgent: ip telephony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 12:33:18 -0400

That discussion is whether address restrictions provide an
adequate Virtual PRIVATE Network.  Bellovin et. al. suggest
that privacy is only assured with encryption.  I agree with
him; VPNs by address restriction is not sufficiently private.
If you want Virtual PRIVATE (IP) Networks, use IPSEC.

This does not deal with whether it makes any sense to
understand traffic patterns of multimedia streams and/or
influence the routing of such streams. 

BTW, while I really do want to discuss these issues, it's
not in the IPTEL charter.  Of course, it's not in any
charter, mostly by design.

Brian

> -----Original Message-----
> From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> Sent: Tuesday, August 07, 2001 12:13 PM
> To: 'Jerry'
> Cc: iptel@lists.bell-labs.com; alan@telchemy.com
> Subject: RE: [IPTEL] urgent: ip telephony traffic model
> 
> 
> We have company in this discussion about building paths 
> across the net.
> 
> See "Experts call MPLS bad for 'Net".
> VPNs based on Multi-protocol Label Switching said to be 
> risky. Backbone
> mgmt. challenges also cited. By CAROLYN DUFFY MARSAN Network World,
> 08/06/01
> 
> http://www.nwfusion.com/news/2001/0806mpls.html
> 
> Henry
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 14:06:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09820
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 14:06:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 80AC34434A; Tue,  7 Aug 2001 14:08:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id AAD4344336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 14:07:29 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA06997;
	Tue, 7 Aug 2001 14:07:29 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA29478;
	Tue, 7 Aug 2001 14:07:26 -0400 (EDT)
Message-ID: <3B705983.C9FF2F58@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        Henry Sinnreich <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>, alan@telchemy.com,
        iptel@lists.bell-labs.com
Subject: Re: [IPTEL] urgent: ip telphony traffic model
References: <313680C9A886D511A06000204840E1CF57BED9@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 14:11:31 -0700
Content-Transfer-Encoding: 7bit

To amplify: Note that the policing behavior for premium traffic may well
depend on the traffic type. Dropping packets is fine for premium TCP,
but not for premium voice/video. (There, you'd want admission control.) 

> I do think that one big difference between audio/video and
> the general purpose data bits is that there is the very
> real possibility of admission control.  That means only that
> you can fail more appropriately (return busy rather than
> poor quality audio/video).  This is admission control on
> a DiffServ network (admission control with IntServ is
> already there).
>

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 14:41:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10776
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 14:41:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE44844376; Tue,  7 Aug 2001 14:43:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by lists.bell-labs.com (Postfix) with ESMTP id B660944336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 14:42:14 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19368; Tue, 7 Aug 2001 14:42:13 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-90.cisco.com [161.44.87.90])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ANB11096;
	Tue, 7 Aug 2001 14:42:13 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010807143525.02fbdf28@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
From: Michael Hammer <mhammer@cisco.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Cc: "Henry Sinnreich" <henry.sinnreich@wcom.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Jerry'" <jerry@reddo.net>, <alan@telchemy.com>,
        <iptel@lists.bell-labs.com>
In-Reply-To: <JJEOJFDNKAJPMKFNJCCGGECCCKAA.kbodouhi@yahoo.com>
References: <000201c11f4e$63cffdd0$1f8b2ca6@open.wcomnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 07 Aug 2001 14:45:12 -0400

Ever notice what happens when many carpoolers jump into the HOV lane only 
to watch that section of the pavement (capacity) fill up?  You can move the 
jersey barriers to add new lanes to the HOV, but that does not always solve 
the basic problem.

The key danger here will be the variability of the flows.  While voice has 
some on/off characteristics, it has a maximum upper bound on volume.  Video 
and other forms of real-time data may have larger jumps in traffic 
volume.  What happens when a scene change occurs and multiple end-points 
are tuned to that same live source?  Content distribution networks?  It's a 
complex problem.

Mike

At 07:16 PM 8/7/2001 +0430, Kiarash Bodouhi wrote:

>Hi,
>
>What if the percentage of this premium services become 70% of the actual
>bandwidth. In that case, what will be called premium? The 70% part or that
>30%?
>
>Kiarash
>
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Henry Sinnreich
> > Sent: Tue, August 07, 2001 7:07 PM
> > To: 'Rosen, Brian'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > Brian,
> > >I suspect
> > > that we will use things like different MPLS lsps for premium
> > > traffic in many cases.
> >
> > Possibly agree, and the discriminator is not voice, but the word is
> > "premium" for whatever users want to pay more.
> >
> > Henry
> >
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com
> > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Rosen, Brian
> > > Sent: Tuesday, August 07, 2001 1:38 PM
> > > To: 'Henry Sinnreich'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > > It may be that we do it with no special paths, but I suspect that we
> > > will use things like different MPLS lsps for premium traffic in many
> > > cases.
> > >
> > > Whether we do or don't, understanding the traffic patterns is
> > > important work.  I don't see much for the IETF to do with it though.
> > >
> > > Brian
> >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>_______________________________________________
>IPTEL mailing list
>IPTEL@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug  7 18:04:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13180
	for <iptel-archive@odin.ietf.org>; Tue, 7 Aug 2001 18:04:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9DC0244342; Tue,  7 Aug 2001 18:06:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by lists.bell-labs.com (Postfix) with ESMTP id 41B3544336
	for <iptel@lists.bell-labs.com>; Tue,  7 Aug 2001 18:05:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f77M51w3020959;
	Tue, 7 Aug 2001 18:05:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJ7JG>; Tue, 7 Aug 2001 18:05:39 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D64B4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "Bradner, Scott (E-mail)" <sob@harvard.edu>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] Call for proposals ends September 7
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Aug 2001 18:05:32 -0400

Folks,

We had some very heated discussions today in the iptel group regarding the
overall structure and approach for the "gateway registration" protocol. It
appears that there are at least two camps, one who wants to use the existing
draft, based on TRIP (draft-rs-trip-gw), and another who wants to use SLP,
although there is no specific proposal on the table at this time.

Since our deadlines are tight (and were based on the model that we had
consensus on the basic approach), we must resolve a fundamental discord like
this very rapidly - well in advance of the next IETF. In order to do that, I
have mandated that anyone who wishes to make a proposal for the "gateway
registration" protocol MUST submit an I-D with a concrete, well-thought-out
proposal by one month from TODAY. That means the proposals must be in the
archives by September 7, 2001, or we will not consider them.

I am serious about this deadline. iptel has been very, very bad in meeting
its deadlines, and I think we should take our new charter as an opportunity
to not make the same mistakes again.

I also encourage people to contribute requirements, since we will need them
in order to evaluate the proposals. I will split out the requirements from
draft-rs-trip-gw after IETF, and resubmit as a separate document. Please
send ideas to the list.

As part of the protocol proposals, please include concrete technical issues
with the current proposal. These should not be things like "too complex" or
"not meant for this problem", but rather statements like, "the current
proposal requires me to implement feature X, and feature X is not required
for this particular application". 

I will make minutes of the meeting available as soon as possible, so that
people can see what transpired.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 05:05:48 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08535
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:05:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C01F644348; Wed,  8 Aug 2001 05:05:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 9222644341
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 05:04:27 -0400 (EDT)
Received: from oranlt (rtp-vpn1-28.cisco.com [10.82.80.28])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7892pY05964;
	Wed, 8 Aug 2001 02:02:52 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: <alan@telchemy.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Organization: Cisco Systems
Message-ID: <006201c11fe9$4da2cb00$d58821d9@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
In-Reply-To: <313680C9A886D511A06000204840E1CF57BED9@whq-msgusr-02.pit.comms.marconi.com>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 05:05:40 -0400
Content-Transfer-Encoding: 7bit

Couple of small comments/questions embedded:

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Rosen, Brian
> Sent: Tuesday, August 07, 2001 11:38 AM
> To: 'Kiarash Bodouhi'; Henry Sinnreich; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> I think we are getting pretty far ahead of ourselves, but it 
> could happen if we get a lot of, for example, video services. 
> Were that to happen, lots of the bits would be premium bits. 
> I'm not sure that we should spend a lot of time worrying 
> about that now, but I also think we should be prepared to
> deal with it some time in the not-too-distant future.
> If that were to happen, we would have to lower the 
> oversubscription ratios we currently employ, and we would 
> have to do much better traffic engineering.
> 
> A part we need which we don't talk about much is policing. 
> Premium service only works if the network can limit the 
> amount of traffic marked premium.  The ability of routers to 
> police real time traffic is, aaah, limited.
> 
I certainly agree that policing is critical. What do you see as
"limited" in the policing capability of current routers? The routers I
know intimately can police class-based aggregates at wire rates for
pretty high values of "wire rate", and at the edge where the wire rates
are lower this isn't too challenging at all. In fact it's turned on by
default on the routers I know intimately. Is your "limited" comment
referring to the granularity of policing? Policing individual flows
(class based) at the edge (or at least at IP address granularity) is
doable on today's edge routers, and I would argue is not needed in the
core.

> I would point out that we could be embarrassed by success --
> if a large voice carrier decided to switch to a converged 
> network tomorrow, it would be the case that 50-90% of the 
> bits on its network would be voice bits.  The 10% number that 
> many toss around assumes the convergence happens over time, 
> at the same time, the data traffic increases at the rate 
> it has been increasing.
> 
> The point Henry makes, which I agree with 100% is that WHAT
> the traffic represents is not the discriminator on what
> is done to the bits.  Premium data bits will be treated
> as premium audio bits or premium video bits.
> 
> I do think that one big difference between audio/video and
> the general purpose data bits is that there is the very 
> real possibility of admission control.  That means only that 
> you can fail more appropriately (return busy rather than 
> poor quality audio/video).  This is admission control on
> a Diffserv network (admission control with Intserv is
> already there).
> 
Ah...you can do admission control on Diffserv by using RSVP with the
DCLASS object. It's important to not mix flow-based
classification/queuing versus class-based classification/queuing with
having admission control versus not having admission control. As long as
your network conforms to the architectural assumptions of diffserv
(bandwidth-rich clouds connected by bandwidth-controlled links) you can
do a fairly decent job of admission control if you ignore the focused
overload problem. You just look at RSVP passing through the inter-cloud
links and do class-based aggregate admission on those links.

Dave.
> Brian
> 
> > -----Original Message-----
> > From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
> > Sent: Tuesday, August 07, 2001 10:47 AM
> > To: Henry Sinnreich; 'Rosen, Brian'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > 
> > 
> > 
> > Hi,
> > 
> > What if the percentage of this premium services become 70% of
> > the actual
> > bandwidth. In that case, what will be called premium? The 70% 
> > part or that
> > 30%?
> > 
> > Kiarash
> > 
> > > -----Original Message-----
> > > From: iptel-admin@lists.bell-labs.com 
> > > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of 
> Henry Sinnreich
> > > Sent: Tue, August 07, 2001 7:07 PM
> > > To: 'Rosen, Brian'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > 
> > > 
> > > Brian,
> > > >I suspect
> > > > that we will use things like different MPLS lsps for premium  
> > > >traffic in many cases.
> > > 
> > > Possibly agree, and the discriminator is not voice, but 
> the word is 
> > > "premium" for whatever users want to pay more.
> > > 
> > > Henry
> > > 
> > > > -----Original Message-----
> > > > From: iptel-admin@lists.bell-labs.com
> > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of 
> Rosen, Brian
> > > > Sent: Tuesday, August 07, 2001 1:38 PM
> > > > To: 'Henry Sinnreich'; 'Jerry'
> > > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > 
> > > > 
> > > > It may be that we do it with no special paths, but I
> > suspect that we
> > > > will use things like different MPLS lsps for premium
> > traffic in many
> > > > cases.
> > > > 
> > > > Whether we do or don't, understanding the traffic patterns is
> > > > important work.  I don't see much for the IETF to do with 
> > it though.
> > > > 
> > > > Brian
> > > 
> > > 
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com 
> > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > 
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 05:37:19 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08947
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:37:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DF25E44374; Wed,  8 Aug 2001 05:11:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 90B4D4436E
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 05:10:41 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA09000;
	Wed, 8 Aug 2001 05:09:50 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id FAA04336;
	Wed, 8 Aug 2001 05:09:48 -0400 (EDT)
Message-ID: <3B712D00.21E962A6@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David R. Oran" <oran@cisco.com>
Cc: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>, alan@telchemy.com,
        iptel@lists.bell-labs.com
Subject: Re: [IPTEL] urgent: ip telphony traffic model
References: <006201c11fe9$4da2cb00$d58821d9@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 08 Aug 2001 05:13:52 -0700
Content-Transfer-Encoding: 7bit

What's the granularity of policing? Can I police at the DSCP/IP
interface/IP src/dest level?

> I certainly agree that policing is critical. What do you see as
> "limited" in the policing capability of current routers? The routers I
> know intimately can police class-based aggregates at wire rates for
> pretty high values of "wire rate", and at the edge where the wire rates
> are lower this isn't too challenging at all. In fact it's turned on by
> default on the routers I know intimately. Is your "limited" comment
> referring to the granularity of policing? Policing individual flows
> (class based) at the edge (or at least at IP address granularity) is
> doable on today's edge routers, and I would argue is not needed in the
> core.

It's needed at the interface level, i.e., I need to be able to say that
incoming interface 17 can't send more than X Mb/s of traffic to outgoing
interface 19.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 06:05:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09379
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:05:25 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82F1C44392; Wed,  8 Aug 2001 05:27:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id C39A344391
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 05:26:15 -0400 (EDT)
Received: from oranlt (rtp-vpn1-28.cisco.com [10.82.80.28])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f789PUY13457;
	Wed, 8 Aug 2001 02:25:31 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>, <alan@telchemy.com>,
        <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Organization: Cisco Systems
Message-ID: <006301c11fec$77c756a0$d58821d9@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
In-Reply-To: <3B712D00.21E962A6@cs.columbia.edu>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 05:28:18 -0400
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] 
> Sent: Wednesday, August 08, 2001 8:14 AM
> To: David R. Oran
> Cc: 'Rosen, Brian'; 'Kiarash Bodouhi'; 'Henry Sinnreich'; 
> 'Jerry'; alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] urgent: ip telphony traffic model
> 
> 
> What's the granularity of policing? Can I police at the 
> DSCP/IP interface/IP src/dest level?
>
Depends on the individual router platform. All the ones "I am intimately
familiar with" can do it at the DSCP/IP interface level. Some edge boxes
can do policing at the IP address level. Peoply who want to talk about
an particlar individual company's products should contact me privately,
as this isn't appropriate on an IETF list.

> > I certainly agree that policing is critical. What do you see as 
> > "limited" in the policing capability of current routers? 
> The routers I 
> > know intimately can police class-based aggregates at wire rates for 
> > pretty high values of "wire rate", and at the edge where the wire 
> > rates are lower this isn't too challenging at all. In fact 
> it's turned 
> > on by default on the routers I know intimately. Is your "limited" 
> > comment referring to the granularity of policing? Policing 
> individual 
> > flows (class based) at the edge (or at least at IP address 
> > granularity) is doable on today's edge routers, and I would 
> argue is 
> > not needed in the core.
> 
> It's needed at the interface level, i.e., I need to be able 
> to say that incoming interface 17 can't send more than X Mb/s 
> of traffic to outgoing interface 19.
>
Hmmm, if you believe the Diffserv model I don't think the policing has
to be "pairwise". Each interface either goes "into" the cloud, or "out
of" the cloud. So, I would police on an ingress interface to the ingress
policy for the cloud, and separately on an egress interface which exits
the cloud to the policy for the egress link.

Dave.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 06:17:06 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09523
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:17:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1FBFA4439A; Wed,  8 Aug 2001 05:38:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 9871844399
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 05:37:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05363;
	Wed, 8 Aug 2001 05:36:53 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA17935;
	Wed, 8 Aug 2001 05:36:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPR14QT>; Wed, 8 Aug 2001 05:36:53 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57BEF0@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'David R. Oran'" <oran@cisco.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: alan@telchemy.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] urgent: ip telphony traffic model
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 05:36:52 -0400

> I certainly agree that policing is critical. What do you see as
> "limited" in the policing capability of current routers? The routers I
> know intimately can police class-based aggregates at wire rates for
> pretty high values of "wire rate", and at the edge where the 
> wire rates
> are lower this isn't too challenging at all. In fact it's turned on by
> default on the routers I know intimately. Is your "limited" comment
> referring to the granularity of policing? Policing individual flows
> (class based) at the edge (or at least at IP address granularity) is
> doable on today's edge routers, and I would argue is not needed in the
> core.
The policing has to be done at the ingress into a carrier network.
So each individual customer flow must be policed.
If the outgoing flow of the egress router at the customer site could
be trusted, I agree it would be easier.
 
> > I do think that one big difference between audio/video and
> > the general purpose data bits is that there is the very 
> > real possibility of admission control.  That means only that 
> > you can fail more appropriately (return busy rather than 
> > poor quality audio/video).  This is admission control on
> > a Diffserv network (admission control with Intserv is
> > already there).
> > 
> Ah...you can do admission control on Diffserv by using RSVP with the
> DCLASS object. It's important to not mix flow-based
> classification/queuing versus class-based classification/queuing with
> having admission control versus not having admission control. 
> As long as
> your network conforms to the architectural assumptions of diffserv
> (bandwidth-rich clouds connected by bandwidth-controlled 
> links) you can
> do a fairly decent job of admission control if you ignore the focused
> overload problem. You just look at RSVP passing through the 
> inter-cloud
> links and do class-based aggregate admission on those links.
Not only do I believe that you can't ignore focused overload,
but I also doubt the viability of ISPs deploying DCLASS RSVP at the
level of a 64K audio stream.  We will see.

Brian 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 06:27:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09674
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 06:25:26 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 05D09443A2; Wed,  8 Aug 2001 05:58:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id D5878443A1
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 05:57:08 -0400 (EDT)
Received: from oranlt (rtp-vpn1-28.cisco.com [10.82.80.28])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f789tVY23156;
	Wed, 8 Aug 2001 02:55:33 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        "'Henry Sinnreich'" <henry.sinnreich@wcom.com>,
        "'Jerry'" <jerry@reddo.net>
Cc: <alan@telchemy.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
Organization: Cisco Systems
Message-ID: <006401c11ff0$aa569e60$d58821d9@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
In-Reply-To: <313680C9A886D511A06000204840E1CF57BEF0@whq-msgusr-02.pit.comms.marconi.com>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 05:58:19 -0400
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
> Sent: Wednesday, August 08, 2001 5:37 AM
> To: 'David R. Oran'; 'Kiarash Bodouhi'; 'Henry Sinnreich'; 'Jerry'
> Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> > I certainly agree that policing is critical. What do you see as 
> > "limited" in the policing capability of current routers? 
> The routers I 
> > know intimately can police class-based aggregates at wire rates for 
> > pretty high values of "wire rate", and at the edge where the wire 
> > rates are lower this isn't too challenging at all. In fact 
> it's turned 
> > on by default on the routers I know intimately. Is your "limited" 
> > comment referring to the granularity of policing? Policing 
> individual 
> > flows (class based) at the edge (or at least at IP address 
> > granularity) is doable on today's edge routers, and I would 
> argue is 
> > not needed in the core.
> The policing has to be done at the ingress into a carrier 
> network. 
Sure. This has to be done anyway to constrain customer bandwidth to the
contract as opposed to the speed of the physical interface between the
CE and PE. Everybody already does this today. The extra complexiy is
doing the policing on class-based aggregates rather than treating all
the customer's traffic identically. I'll reiterate that today's carrier
edge routers do this as part of their basic feature set.

> So each individual customer flow must be policed. 
I find your use of the term "customer flow" confusing. A given
customer's traffic consists of many simulataneous flows (unless you've
hidden the flows intentionally by stuffing them inside an IPSEC tunnel
at the CE, in which case you get what you asked for :-) ).

> If 
> the outgoing flow of the egress router at the customer site 
> could be trusted, I agree it would be easier.
> 
Well, for scalability yes, but I'm not making that assumption.

> > > I do think that one big difference between audio/video and the 
> > > general purpose data bits is that there is the very real 
> possibility 
> > > of admission control.  That means only that you can fail more 
> > > appropriately (return busy rather than poor quality 
> audio/video).  
> > > This is admission control on a Diffserv network 
> (admission control 
> > > with Intserv is already there).
> > > 
> > Ah...you can do admission control on Diffserv by using RSVP 
> with the 
> > DCLASS object. It's important to not mix flow-based 
> > classification/queuing versus class-based 
> classification/queuing with 
> > having admission control versus not having admission 
> control. As long 
> > as your network conforms to the architectural assumptions 
> of diffserv
> > (bandwidth-rich clouds connected by bandwidth-controlled 
> > links) you can
> > do a fairly decent job of admission control if you ignore 
> the focused
> > overload problem. You just look at RSVP passing through the 
> > inter-cloud
> > links and do class-based aggregate admission on those links.
> Not only do I believe that you can't ignore focused overload, 
Then by definition you don't believe in Diffserv. That's OK, (and I tend
to agree for many carrier cases) but people have to understand that
TANSTAAFL.

> but I also doubt the viability of ISPs deploying DCLASS RSVP 
> at the level of a 64K audio stream.  We will see.
>
Remember that you need RSVP protocol state at the edge boxes but *not*
flow state for this to work. You don't need RSVP protool state in the
core. In my depressed mode, I often dispair of the ISPs deploying
ANYTHING in the QoS domain. What I would argue is that once you write
and enforce QoS-sensitive SLAs, doing RSVP admission control at the
CE/PE boundary does not introduce significant extra complexity and in
fact might be simpler than other forms of SLA monitoring/enforcement.

Dave.

> Brian 
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 07:25:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10338
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 07:25:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8371244362; Wed,  8 Aug 2001 07:26:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by lists.bell-labs.com (Postfix) with ESMTP id BDD9344341
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 07:25:45 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f78BP9p02873;
	Wed, 8 Aug 2001 07:25:10 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id HAA19700; Wed, 8 Aug 2001 07:23:39 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <QNPJX2A2>; Wed, 8 Aug 2001 07:24:59 -0400
Message-ID: <E5B80B001D76D211879C00E0291077610990460C@njc240po05.mt.att.com>
From: "Roy, Radhika R, ALCTA" <rrroy@att.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "Bradner, Scott (E-mail)" <sob@harvard.edu>
Subject: RE: [IPTEL] Call for proposals ends September 7
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 07:24:51 -0400

Hi, Jonathan:

If I understand correctly, the proposals for contributions are as follows:

1. Requirements/Framework for development of the discovery/registration
protocol (to be used between SIP proxies and GWs)

2. Proposal for the gateway discovery/registration protocol (to be used
between SIP proxies and GWs)

Do the people need to submit proposals for both at the same time because it
is felt that the requirements stated in the draft (draft-rs-trip-gw) may not
be enough to evaluate the protocol?

A clarification will really be helpful.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, August 07, 2001 6:06 PM
To: 'iptel@lists.bell-labs.com'
Cc: Bradner, Scott (E-mail)
Subject: [IPTEL] Call for proposals ends September 7


Folks,

We had some very heated discussions today in the iptel group regarding the
overall structure and approach for the "gateway registration" protocol. It
appears that there are at least two camps, one who wants to use the existing
draft, based on TRIP (draft-rs-trip-gw), and another who wants to use SLP,
although there is no specific proposal on the table at this time.

Since our deadlines are tight (and were based on the model that we had
consensus on the basic approach), we must resolve a fundamental discord like
this very rapidly - well in advance of the next IETF. In order to do that, I
have mandated that anyone who wishes to make a proposal for the "gateway
registration" protocol MUST submit an I-D with a concrete, well-thought-out
proposal by one month from TODAY. That means the proposals must be in the
archives by September 7, 2001, or we will not consider them.

I am serious about this deadline. iptel has been very, very bad in meeting
its deadlines, and I think we should take our new charter as an opportunity
to not make the same mistakes again.

I also encourage people to contribute requirements, since we will need them
in order to evaluate the proposals. I will split out the requirements from
draft-rs-trip-gw after IETF, and resubmit as a separate document. Please
send ideas to the list.

As part of the protocol proposals, please include concrete technical issues
with the current proposal. These should not be things like "too complex" or
"not meant for this problem", but rather statements like, "the current
proposal requires me to implement feature X, and feature X is not required
for this particular application". 

I will make minutes of the meeting available as soon as possible, so that
people can see what transpired.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 10:31:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13635
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 10:31:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 00EA344341; Wed,  8 Aug 2001 10:32:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32])
	by lists.bell-labs.com (Postfix) with SMTP id AFB784433E
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 10:31:35 -0400 (EDT)
Received: from host217-33-146-154.ietf.ignite.net (HELO kibotop) (217.33.146.154)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Aug 2001 14:24:54 -0000
X-Apparently-From: <kbodouhi@yahoo.com>
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: <iptel@lists.bell-labs.com>
Message-ID: <JJEOJFDNKAJPMKFNJCCGIEDACKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Subject: [IPTEL] TRIP and something else...
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 18:58:09 +0430
Content-Transfer-Encoding: 7bit


Hello all,

I would like to state here that the point that Henning mentioned in
yesterday
meeting regarding setting aside TRIP as an interdomain only protocol and
making
another simpler protocol for intradomain is very important. As if we decide
to
separate these two then specification of TRIP will change some how. As
Jonathan
stated then we have to work out what will be needed and not needed for such
protocol.

Regarding the proxy specification and also gateways, what I was trying to
say as
moving some how the policy management from proxy to gateways was the fact
that it is a need to do traffic shaping both from source and destination. So
if we
decide to do this traffic shaping in proxies only then we need to add proxy
code
to gateways as well which I don't believe is a good idea. So we have to add
traffic
shaping feature ( the capacity and resource reporting and allocation ) both
on
proxy side and also the gateway side.

On the overall my approach would be that although gateways registering on  a
proxy
should be considered as a part of the proxy domain but in fact they should
have independent
policy management as well because it might be possible that a gateway be
registered
on two or more proxies and in that case we don't know which proxy will be in
charge
of policy. So we have to take out the policy features that are specifically
related to
gateway characteristics ( like capacity and dsp resources and so on..) from
proxies
to gateways.

Regards
Kiarash



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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 14:41:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18989
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 14:41:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 98CB044396; Wed,  8 Aug 2001 14:40:06 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from cam-po2.genuity.com (cam-po2.genuity.com [171.78.68.9])
	by lists.bell-labs.com (Postfix) with ESMTP id CE1DA4438F
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 14:15:59 -0400 (EDT)
Received: from ksethare_2 (dhcp113-156.genuity.com [171.78.113.156])
	by cam-po2.genuity.com (8.11.3/8.11.2) with SMTP id f78H9I903655
	for <iptel@lists.bell-labs.com>; Wed, 8 Aug 2001 13:09:28 -0400 (EDT)
Message-Id: <200108081709.f78H9I903655@cam-po2.genuity.com>
X-Recipient: <iptel@lists.bell-labs.com>
X-Sender: ksethare@po3.Genuity.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
To: iptel@lists.bell-labs.com
From: Elliot Eichen <elliot.eichen@genuity.com>(by way of Kerry Sethares <ksethare@genuity.com>)
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [IPTEL] Symposium on IP Telephony:  ICC 2002 / IPTel 2002
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 08 Aug 2001 13:02:00 -0400
Content-Transfer-Encoding: quoted-printable

<html>
<font face=3D"Courier New, Courier">Dear Colleague:<br>
<br>
As part of the IEEE Conference on Communications (ICC 2002), and <br>
in combination with IPTel 2002, a symposium on IP Telephony and <br>
Voice Over IP will be held in New York City, 28 April - 2 May, <br>
2002.=A0 This symposium is part of Symposium G: Multimedia Services and
<br>
VoIP - Services and Technologies.=A0 Participation in this symposium is
<br>
open to all registrants of ICC 2002 (i.e., separate registration is=20
<br>
not required).=A0 Please note that the paper submission deadline for the
<br>
symposium has been extended to 3 September 2001.<br>
<br>
Papers submitted for consideration should focus on topics <br>
related to IP Telephony services, and the technologies needed to <br>
implement those services.=A0 Examples of topics of interest <br>
include:<br>
<br>
Architecture and Protocols:<br>
- Advanced Feature/Call Routing<br>
- Protocol Interoperability<br>
- Network Scalability and Reliability<br>
<br>
Network Interworking<br>
- 3G Wireless<br>
- PSTN<br>
<br>
Applications and Services<br>
- IP-PBX / IP-Centrex<br>
- Messaging and Presence<br>
- Call Centers<br>
- Conferencing<br>
- IP-Telephone over Broadband Access<br>
- Desktop Integration and IP Telephony<br>
- Internet Gaming<br>
<br>
Security<br>
- Privacy and Encryption<br>
- Authorization and Authentication<br>
- Firewalls<br>
- Regulatory Requirements<br>
<br>
Operations Support Systems<br>
- Network Configuration and Management<br>
- Service Creation and Provisioning<br>
- Accounting<br>
<br>
Pilots and Deployments<br>
- Advanced Applications<br>
- Performance/Scalability/Robustness<br>
- User Experience<br>
<br>
Quality of Service<br>
- WAN/LAN/Application Layer QoS<br>
- Voice/Video Coding and Transmission<br>
<br>
The paper submission schedule and process is the same as for the <br>
general ICC 2002 conference.=A0 When submitting your paper through the
<br>
Automated Paper Submission System (all papers must be submitted <br>
electronically), please note that themes for IP Telephony and VoIP are
<br>
G10 through G16 on the drop down menu. <br>
<br>
Important Sites:<br>
----------------<br>
<br>
Call for Papers, Symposium on Multimedia and VoIP: <br>
<a href=3D"http://www.icc2002.com/MultimediaSymp.html"=
 eudora=3D"autourl">http://www.icc2002.com/MultimediaSymp.html</a><br>
<br>
Instructions for Authors:<br>
<a href=3D"http://www.icc2002.com/InfoForAuthors.html"=
 eudora=3D"autourl">http://www.icc2002.com/InfoForAuthors.html</a><br>
<br>
ICC 2002:<br>
<a href=3D"http://www.icc2002.com/"=
 eudora=3D"autourl">http://www.icc2002.com/</a><br>
<br>
IPTel 2002<br>
<a href=3D"http://www.iptel.org/2002/"=
 eudora=3D"autourl">http://www.iptel.org/2002/</a><br>
<br>
<br>
Best Regards:<br>
<br>
Elliot Eichen<br>
Co-Chair, Symposium on Multimedia and VoIP - Services and <br>
Technologies<br>
<br>
<br>
<br>
</font></html>


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 16:50:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21221
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 16:50:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 315C544346; Wed,  8 Aug 2001 16:52:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by lists.bell-labs.com (Postfix) with ESMTP id E2FAF4433E
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 16:51:21 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f78Kodw3024751;
	Wed, 8 Aug 2001 16:50:39 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJ0HW>; Wed, 8 Aug 2001 16:51:17 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D64C8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP and something else...
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 16:51:17 -0400



 

> -----Original Message-----
> From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
> Sent: Wednesday, August 08, 2001 3:28 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP and something else...
> 
> 
> 
> Hello all,
> 
> I would like to state here that the point that Henning mentioned in
> yesterday
> meeting regarding setting aside TRIP as an interdomain only 
> protocol and
> making
> another simpler protocol for intradomain is very important. 
> As if we decide
> to
> separate these two then specification of TRIP will change some how. As
> Jonathan
> stated then we have to work out what will be needed and not 
> needed for such
> protocol.

No, that is absolutely false.

TRIP has intradomain components and they are needed for the same reason that
I-BGP is a critical part of BGP. Absolutely postivitely NOTHING in TRIP
itself will change based on the outcome of this work. If we decide not to
use TRIP for gateway registration, all that means is that we do not use TRIP
for gateway registration.


-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 16:57:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21340
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 16:57:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4350E44359; Wed,  8 Aug 2001 16:59:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52])
	by lists.bell-labs.com (Postfix) with ESMTP id D1A2944358
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 16:58:41 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f78Kw1w3024803;
	Wed, 8 Aug 2001 16:58:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <QCDMJ02Z>; Wed, 8 Aug 2001 16:58:40 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D64CB@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Roy, Radhika R, ALCTA'" <rrroy@att.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "Bradner, Scott (E-mail)" <sob@harvard.edu>
Subject: RE: [IPTEL] Call for proposals ends September 7
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 8 Aug 2001 16:58:39 -0400



 

> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Wednesday, August 08, 2001 12:25 PM
> To: Jonathan Rosenberg; 'iptel@lists.bell-labs.com'
> Cc: Bradner, Scott (E-mail)
> Subject: RE: [IPTEL] Call for proposals ends September 7
> 
> 
> Hi, Jonathan:
> 
> If I understand correctly, the proposals for contributions 
> are as follows:
> 
> 1. Requirements/Framework for development of the 
> discovery/registration
> protocol (to be used between SIP proxies and GWs)
> 
> 2. Proposal for the gateway discovery/registration protocol 
> (to be used
> between SIP proxies and GWs)
> 
> Do the people need to submit proposals for both at the same 
> time because it
> is felt that the requirements stated in the draft 
> (draft-rs-trip-gw) may not
> be enough to evaluate the protocol?

No.

Proposals need to be made only on 2. In parallel, continously between now
and then, I'd like people to contribute and comment on overall requirements.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug  8 17:31:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21883
	for <iptel-archive@odin.ietf.org>; Wed, 8 Aug 2001 17:31:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 232A344356; Wed,  8 Aug 2001 17:33:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id C172E4433E
	for <iptel@lists.bell-labs.com>; Wed,  8 Aug 2001 17:32:54 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GHR003HPQITGO@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Wed,  8 Aug 2001 21:32:53 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GHR00G01QISQS@pmismtp01.wcomnet.com>;
 Wed, 08 Aug 2001 21:32:53 +0000 (GMT)
Received: from hsinnreich ([166.44.138.8])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GHR00ED3QGT2V@pmismtp01.wcomnet.com>; Wed,
 08 Aug 2001 21:32:39 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] urgent: ip telphony traffic model
In-reply-to: <79FEAA5FABA7D411BF580001023D1BBDA7BAB0@mailserver.sylantro.com>
To: "'Joe Aiello'" <Joe.Aiello@sylantro.com>,
        "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>
Cc: iptel@lists.bell-labs.com
Message-id: <000801c12051$a0a87940$088a2ca6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 08 Aug 2001 22:31:35 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA21883

Glad Joe Aiello has made such an excellent balanced assesment IMHO. Am
seeing the same happening.

Henry

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Joe Aiello
> Sent: Tuesday, August 07, 2001 4:55 PM
> To: Kiarash Bodouhi
> Cc: iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> I see the issue being a bit more problematic.  The current 
> modeling would show barely a percentage of VoIP on The 
> Internet.  However, new service providers are just now 
> selling enhanced VoIP services.  Carriers are just now 
> looking at VoIP for enhanced services.  There will be a rich 
> suite of applications and services that just can not be done 
> in the switched world and certainly can not be done as 
> quickly as in a packet world.  I foresee a gradual increase 
> to about one percent in the next 12 to 15 months.  When the 
> large service providers have a new infrastructure in place 
> supporting large gateways to the public switched network, 
> there will likely be bulk surge in VoIP usage over The 
> Internet.  But that is likely to be only another one to 1.5 percent.
> 
> Before we see real usage, the service providers have to be 
> sure it is toll quality and can guarantee service levels.  
> That will take some time.  I expect more short jumps on and 
> off The Internet in a more controllable area. This kind of 
> usage will be hard to model.  Voice is rather easy to do. 
> Getting service providers to trust VoIP is not so easy.  Once 
> they trust the infrastructure, there will be some incremental 
> changes to traffic as they add video services and whatever 
> else that can pump out.  I really expect us to turn around 
> one day and say "How did that happen" rather than us watch 
> the river rise.
> 
> Regards,
> Joe Aiello
> 
>  -----Original Message-----
> From: 	Kiarash Bodouhi [mailto:kbodouhi@yahoo.com] 
> Sent:	Tuesday, August 07, 2001 7:41 AM
> To:	Rosen, Brian; 'Henry Sinnreich'; 'Jerry'
> Cc:	alan@telchemy.com; iptel@lists.bell-labs.com
> Subject:	RE: [IPTEL] urgent: ip telphony traffic model
> 
> 
> 
> Hi again,
> 
> Sorry. Now I got what Henry meant. For me it is like sitting 
> and seeing a movie in the middle. I hope you forgive me as a 
> newcomer. I believe the reality is that many carriers have 
> already separated VoIP from Internet. This is not good. As 
> Henry mentioned we have already had circuit switched networks 
> with dedicated bandwidth and quality of service there.
> 
> Regards
> Kiarash
> 
>   > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com 
> > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Rosen, Brian
> > Sent: Tue, August 07, 2001 5:08 PM
> > To: 'Henry Sinnreich'; 'Jerry'
> > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> >
> >
> > It may be that we do it with no special paths, but I 
> suspect that we 
> > will use things like different MPLS lsps for premium 
> traffic in many 
> > cases.
> >
> > Whether we do or don't, understanding the traffic patterns is 
> > important work.  I don't see much for the IETF to do with it though.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > Sent: Tuesday, August 07, 2001 8:21 AM
> > > To: 'Rosen, Brian'; 'Jerry'
> > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > >
> > >
> > > Brian,
> > >
> > > > It's true that voice is likely to be a small fraction 
> of overall 
> > > > traffic. However, it may be a sizable percentage of premium 
> > > > traffic.
> > > I truly hope you are right and we will enjoy the business 
> of premium 
> > > traffic. It does not follow however that one has to build special 
> > > paths across the Internet for premium services. Just like 
> no special 
> > > planes are required for 1st class travel.
> > >
> > > And as mentioned, there are already circuit based 
> networks there...
> > >
> > > Henry
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Tuesday, August 07, 2001 11:10 AM
> > > > To: 'Henry Sinnreich'; 'Jerry'
> > > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > >
> > > >
> > > > Henry
> > > >
> > > > It's true that voice is likely to be a small fraction 
> of overall 
> > > > traffic. However, it may be a sizable percentage of premium 
> > > > traffic.
> > > >
> > > > If video takes off, video WOULD be a sizeable percentage of 
> > > > traffic on some large nets.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > Sent: Tuesday, August 07, 2001 3:03 AM
> > > > > To: 'Jerry'
> > > > > Cc: alan@telchemy.com; iptel@lists.bell-labs.com
> > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > >
> > > > >
> > > > > The busy hour voice traffic will most certainly be 
> noise in the 
> > > > > overall IP traffic, both on the public Internet and in well 
> > > > > engineered enterprise networks. Not the to mention 
> the presumed 
> > > > > 97%
> > > > unused fiber
> > > > > capacity.
> > > > >
> > > > > Would be interested if there are any numbers to the
> > > > contrary, that is
> > > > > voice traffic projections showing the load on the  Internet
> > > > to be more
> > > > > than noise levels compared to capacity or to total 
> traffic load.
> > > > >
> > > > > BTW: Why stop with at voice and not have special paths for
> > > > multimedia?
> > > > > For what else?
> > > > >
> > > > > Thanks, Henry
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Jerry
> > > > > > Sent: Monday, August 06, 2001 8:43 AM
> > > > > > To: 'Henry Sinnreich'
> > > > > > Cc: 'alan@telchemy.com'; 'iptel@lists.bell-labs.com'
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > > hello Henry,
> > > > > >
> > > > > > Of course IP layer does not know weather it is a voice or a 
> > > > > > chat or something else, but I want to know it. 
> Because we are 
> > > > > > trying to make our own router, maybe it is 
> important to know 
> > > > > > the "busy hour" traffic, the jatter and other 
> parameters. Then 
> > > > > > we can try to do some application simulation test to our 
> > > > > > router. This is why I want a voip model.
> > > > > >
> > > > > > BRs,
> > > > > > XuZhe
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > > Sent: Friday, August 03, 2001 10:34 PM
> > > > > > To: alan@telchemy.com; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > >
> > > > > >
> > > > > > Alan,
> > > > > >
> > > > > > Segregating traffic over the Internet by 
> application seems a 
> > > > > > strange idea. Segregating by classes of traffic is OK and 
> > > > > > already dealt with by DiffServ. Besides, 
> predictions show that 
> > > > > > voice will amount to a small percentage of overall IP 
> > > > > > traffic..., but maybe we can discuss at the IETF.
> > > > > >
> > > > > > Thanks, Henry
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Alan Clark [mailto:alan@telchemy.com]
> > > > > > > Sent: Friday, August 03, 2001 9:34 PM
> > > > > > > To: 'Henry Sinnreich'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Henry
> > > > > > >
> > > > > > > We are assuming that service providers such as
> > > Worldcom have a
> > > > > > > dedicated IP network and are not using the 
> Internet for long 
> > > > > > > distance/ international telephone traffic. From the
> > > > discussions we
> > > > > > > have had with some of your competitors it does 
> appear to be 
> > > > > > > a reasonable assumption that many service providers plan
> > > > to have a
> > > > > > > packet based backbone that may be used for both voice
> > > and data
> > > > > > > traffic, and potentially for video.  It also appears a
> > > > reasonable
> > > > > > > assumption that you would want to preserve some
> > > > separation between
> > > > > > > voice and data services using either diffserv or MPLS
> > > in order
> > > > > > > that you can prevent spikes in data traffic from
> > > > causing excessive
> > > > > > > packet loss and jitter in voice traffic. We are 
> modeling the 
> > > > > > > behavior of aggregate VoIP streams and "interfering" bulk 
> > > > > > > data traffic over IP networks that use techniques such as 
> > > > > > > CBQ, WRED etc.  In general you would expect that 
> segregating 
> > > > > > > voice and data traffic would eliminate QoS issues however 
> > > > > > > there is still scope for some level of 
> interference - we are 
> > > > > > > interested in both the nature of (even minor) network 
> > > > > > > impairments that may result from this scenario and in the 
> > > > > > > "real time traffic engineering" problem.
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Henry Sinnreich [mailto:henry.sinnreich@wcom.com]
> > > > > > > Sent: Friday, August 03, 2001 3:09 PM
> > > > > > > To: 'Alan Clark'; 'Xu Zhe'; iptel@lists.bell-labs.com
> > > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > > >
> > > > > > >
> > > > > > > Please help me understand:
> > > > > > > Do you really want to separate VoIP traffic from other IP 
> > > > > > > applications? Can you separate it? Is it a good idea to
> > > > balkanize
> > > > > > > the Internet for various applications?
> > > > > > >
> > > > > > > BTW: We already have separate voice network...
> > > > > > >
> > > > > > > Thanks,Henry
> > > > > > >
> > > > > > > Henry Sinnreich
> > > > > > > WorldCom
> > > > > > > 400 International Parkway
> > > > > > > Richardson, Texas 75081
> > > > > > > USA
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > > > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of
> > > > Alan Clark
> > > > > > > > Sent: Thursday, August 02, 2001 5:35 PM
> > > > > > > > To: Xu Zhe; iptel@lists.bell-labs.com
> > > > > > > > Subject: RE: [IPTEL] urgent: ip telphony traffic model
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Telchemy is currently conducting research in this
> > > > area, building
> > > > > > > > aggregate VoIP traffic models for NS-2 as part of
> > > our work on
> > > > > > > > performance analysis of large scale VoIP networks.  We
> > > > > > have done a
> > > > > > > > fairly comprehensive literature survey, are (re)doing
> > > > > > > analytical work
> > > > > > > > and simulation studies.
> > > > > > > >
> > > > > > > > We would be interested to exchange information with
> > > > > other research
> > > > > > > > groups, and will add a list of the references we have 
> > > > > > > > found
> > > > > > > to our web
> > > > > > > > site
> > > > > > > > (www.telchemy.com) next week.
> > > > > > > >
> > > > > > > > Alan Clark
> > > > > > > > alan@telchemy.com
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: iptel-admin@lists.bell-labs.com 
> > > > > > > > [mailto:iptel-admin@lists.bell-labs.com]> On Behalf
> > > Of Xu Zhe
> > > > > > > >
> > > > > > > > Sent: Thursday, August 02, 2001 5:13 AM
> > > > > > > >
> > > > > > > > To: 'iptel@lists.bell-labs.com'
> > > > > > > > Subject: [IPTEL] urgent: ip telphony traffic model
> > > > > > > >
> > > > > > > >
> > > > > > > > hello,
> > > > > > > > some one has post this message but without answer. I
> > > > > also need the
> > > > > > > > answer to this, can someone help me? Hi everybody, Is 
> > > > > > > > there
> > > > > > > any study
> > > > > > > > that has tried to characterize the ip telephony 
> traffic? 
> > > > > > > > If
> > > > > > > yes, can
> > > > > > > > somebody point me where I can find it? Thanks 
> in advance.
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > IPTEL mailing list
> > > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > IPTEL mailing list
> > > > > > > > IPTEL@lists.bell-labs.com
> > > > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > IPTEL mailing list
> > > > > > IPTEL@lists.bell-labs.com
> > > > > > http://lists.bell-> labs.com/mailman/listinfo/iptel
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IPTEL mailing list
> > > > > IPTEL@lists.bell-labs.com 
> > > > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > IPTEL mailing list
> > > IPTEL@lists.bell-labs.com 
> > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > >
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com 
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 10:57:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26006
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 10:57:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 884E044354; Thu,  9 Aug 2001 10:59:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from chuckie.dgms.com (chuckie.dgms.com [38.150.156.4])
	by lists.bell-labs.com (Postfix) with ESMTP id E664E44351
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 10:58:54 -0400 (EDT)
Received: from ulticom.com (localhost [127.0.0.1])
	by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA19098
	for <iptel@lists.bell-labs.com>; Thu, 9 Aug 2001 10:58:54 -0400 (EDT)
Message-ID: <3B72A4C4.A423B922@ulticom.com>
From: Vijaya Venkatachalam <vijaya@ulticom.com>
Organization: Ulticom, Inc.
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------9489E572EBD98EA9F70A4583"
Subject: [IPTEL] TRIP question
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 09 Aug 2001 10:57:08 -0400


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

Can one telephony destination be handled by more than one
telephony gateway.

If yes, then if both gateway1 & 2 can reach a telephony destination,
then how is it determined which is a better route to
reach that telephony destination, via gateway1 or gateway2.

Thanks.

--------------9489E572EBD98EA9F70A4583
Content-Type: text/x-vcard; charset=us-ascii;
 name="vijaya.vcf"
Content-Description: Card for Vijaya Venkatachalam
Content-Disposition: attachment;
 filename="vijaya.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Venkatachalam;Vijaya
tel;fax:+1-856-866-2033
tel;work:+1-856-787-2853
x-mozilla-html:FALSE
url:www.ulticom.com
org:Ulticom, Inc.;Research & Development
adr:;;1020 Briggs Rd;Mt. Laurel;NJ;08054;USA
version:2.1
email;internet:vijaya@ulticom.com
fn:Vijaya Venkatachalam
end:vcard

--------------9489E572EBD98EA9F70A4583--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 11:43:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27884
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 11:43:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ABB8A44355; Thu,  9 Aug 2001 11:45:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from relay1.bt.net (relay1.bt.net [194.72.6.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 0969144351
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 11:44:17 -0400 (EDT)
Received: from [217.33.146.154] (helo=kibotop)
	by relay1.bt.net with smtp (Exim 3.15 #1)
	id 15Uryj-0000MQ-00; Thu, 09 Aug 2001 16:44:09 +0100
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP and something else...
Message-ID: <JJEOJFDNKAJPMKFNJCCGAEDMCKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF020D64C8@DYN-EXCH-001.dynamicsoft.com>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 20:17:26 +0430
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
> Sent: Thu, August 09, 2001 1:21 AM
> To: 'Kiarash Bodouhi'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] TRIP and something else...
>
>
>
>
>
>
> > -----Original Message-----
> > From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
> > Sent: Wednesday, August 08, 2001 3:28 PM
> > To: iptel@lists.bell-labs.com
> > Subject: [IPTEL] TRIP and something else...
> >
> >
> >
> > Hello all,
> >
> > I would like to state here that the point that Henning mentioned in
> > yesterday
> > meeting regarding setting aside TRIP as an interdomain only
> > protocol and
> > making
> > another simpler protocol for intradomain is very important.
> > As if we decide
> > to
> > separate these two then specification of TRIP will change some how. As
> > Jonathan
> > stated then we have to work out what will be needed and not
> > needed for such
> > protocol.
>
> No, that is absolutely false.
>
> TRIP has intradomain components and they are needed for the same
> reason that
> I-BGP is a critical part of BGP. Absolutely postivitely NOTHING in TRIP
> itself will change based on the outcome of this work. If we decide not to
> use TRIP for gateway registration, all that means is that we do
> not use TRIP
> for gateway registration.

I agree with you completely. The thing I was going to mention is that we
shouldn't
make it richer for intradomain purposes. This is for the same reasons that
nobody
uses I-BGP solely for intradomain routing instead of OSPF or RIP. So I
suggest we
put gateway registration as a feature of some iradomain protocol that should
be
worked out exclusively for this reason.

Kiarash

>
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 13:12:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB00512
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:12:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A47C44351; Thu,  9 Aug 2001 13:14:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from integraonline.com (inet-1a-bvtn.integraonline.com [206.163.82.156])
	by lists.bell-labs.com (Postfix) with SMTP id 89E874434E
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 13:13:45 -0400 (EDT)
Received: (qmail 14140 invoked from network); 9 Aug 2001 17:13:43 -0000
Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender <Darby.Anderson@integratelecom.com>)
          by inet-1b-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP
          for <vijaya@ulticom.com>; 9 Aug 2001 17:13:43 -0000
Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21)
	id <QS468B6T>; Thu, 9 Aug 2001 10:13:44 -0700
Message-ID: <C4C5B6767D9B4E49AB448C67CF49F4A904D669@beaexch2.ads.integratelecom.com>
From: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
To: "'Vijaya Venkatachalam'" <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 10:13:41 -0700

According to what I understand of the Trip Protocol, this would be a viable
situation, the scenario youve given would be applicable in the real world if
you have on-net trunking to a particular destination, however not enough
volume to justify additional capacity, so you offload the overflow to
another carrier (ITAD in this circumstance), in which case it would seem
logical to assign a cost of 0 to your on-net trunking, and a higher route
cost to any/all other off-net route choices...??

Anyone else out there, please correct me if Im wrong

-Darby

-----Original Message-----
From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
Sent: Thursday, August 09, 2001 8:57 AM
To: iptel@lists.bell-labs.com
Subject: [IPTEL] TRIP question


Can one telephony destination be handled by more than one
telephony gateway.

If yes, then if both gateway1 & 2 can reach a telephony destination,
then how is it determined which is a better route to
reach that telephony destination, via gateway1 or gateway2.

Thanks.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 13:14:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00564
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:14:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D073F44381; Thu,  9 Aug 2001 13:16:01 -0400 (EDT)
Delivered-To: iptel@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 4E8AF4437C
	for <iptel@share.research.bell-labs.com>; Thu,  9 Aug 2001 13:15:54 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Aug  9 13:14:56 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id C1A0B44394; Thu,  9 Aug 2001 13:01:38 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from nj7460exch001h.wins.lucent.com (nj7460exch001h.ho.lucent.com [135.17.42.36])
	by lists.bell-labs.com (Postfix) with ESMTP id 8F41544393
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 13:01:38 -0400 (EDT)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21)
	id <QQ811ZD8>; Thu, 9 Aug 2001 13:01:38 -0400
Message-ID: <A1F1AD611488D411886400508B69AD5A015B3C75@MA8132EXCH001U>
From: "Ghai, Rajat (Rajat)" <rghai@lucent.com>
To: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 13:01:37 -0400

For the most part, it would be the policies at the proxy/LS
to decide which gateway to use.

thanks
Rajat Ghai

> >-----Original Message-----
> >From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
> >Sent: Thursday, August 09, 2001 10:57 AM
> >To: iptel@lists.bell-labs.com
> >Subject: [IPTEL] TRIP question
> >
> >
> >Can one telephony destination be handled by more than one
> >telephony gateway.
> >
> >If yes, then if both gateway1 & 2 can reach a telephony destination,
> >then how is it determined which is a better route to
> >reach that telephony destination, via gateway1 or gateway2.
> >
> >Thanks.
> >

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 13:22:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00798
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:22:58 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CE04944368; Thu,  9 Aug 2001 13:24:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 0F9744434E
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 13:23:29 -0400 (EDT)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f79HNSq01904;
	Thu, 9 Aug 2001 10:23:28 -0700 (PDT)
Received: from cisco.com ([10.19.104.244])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AGX02965 (AUTH hsalama);
	Thu, 9 Aug 2001 10:23:25 -0700 (PDT)
Message-ID: <3B72C6FD.77D9FFEE@cisco.com>
From: "Hussein F. Salama" <hsalama@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
Cc: "'Vijaya Venkatachalam'" <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: Re: [IPTEL] TRIP question
References: <C4C5B6767D9B4E49AB448C67CF49F4A904D669@beaexch2.ads.integratelecom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 09 Aug 2001 10:23:10 -0700
Content-Transfer-Encoding: 7bit

Offload/backup gateway is one case. Another case is that of two different ITSPs
advertising competing routes to the same destination, i.e. each of them will
have gateways that can terminate calls to this particular destination.

Hussein

"Anderson, Darby" wrote:

> According to what I understand of the Trip Protocol, this would be a viable
> situation, the scenario youve given would be applicable in the real world if
> you have on-net trunking to a particular destination, however not enough
> volume to justify additional capacity, so you offload the overflow to
> another carrier (ITAD in this circumstance), in which case it would seem
> logical to assign a cost of 0 to your on-net trunking, and a higher route
> cost to any/all other off-net route choices...??
>
> Anyone else out there, please correct me if Im wrong
>
> -Darby
>
> -----Original Message-----
> From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
> Sent: Thursday, August 09, 2001 8:57 AM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP question
>
> Can one telephony destination be handled by more than one
> telephony gateway.
>
> If yes, then if both gateway1 & 2 can reach a telephony destination,
> then how is it determined which is a better route to
> reach that telephony destination, via gateway1 or gateway2.
>
> Thanks.
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

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



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 13:50:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01476
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:50:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C409344370; Thu,  9 Aug 2001 13:52:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from integraonline.com (web-1-bvtn.integraonline.com [206.163.82.90])
	by lists.bell-labs.com (Postfix) with SMTP id CFC3F4434E
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 13:51:15 -0400 (EDT)
Received: (qmail 21625 invoked from network); 9 Aug 2001 17:51:15 -0000
Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender <Darby.Anderson@integratelecom.com>)
          by web-1-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP
          for <hsalama@cisco.com>; 9 Aug 2001 17:51:15 -0000
Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21)
	id <QS468CLQ>; Thu, 9 Aug 2001 10:51:14 -0700
Message-ID: <C4C5B6767D9B4E49AB448C67CF49F4A904D66A@beaexch2.ads.integratelecom.com>
From: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
To: "'Hussein F. Salama'" <hsalama@cisco.com>,
        "Anderson, Darby" <Darby.Anderson@integratelecom.com>
Cc: "'Vijaya Venkatachalam'" <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 10:51:14 -0700

Wouldent it be plausable in the Softswitch,SIP Controller, or whatever it is
that someone's using,when its using TRIP as an Egress protocol, that you
could assign a route cost to each destination? (I.E. I have on-net trunking
to destination 1 with a capacity of 24 chanels, I typically have 26-30 calls
in any given time to that area, Carrier A is giving me a price of .013 cents
a minute to destination 1, however Carrier B is giving me a price of .011
cents a minute to destination 1, thus my route would have priority to my
on-net trunking to destination 1, and would first route calls to Carrier B,
then if Carrier B was unable to handle the call, the Softswitch would pass
the call to Carrier A??)

-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: Thursday, August 09, 2001 11:23 AM
To: Anderson, Darby
Cc: 'Vijaya Venkatachalam'; iptel@lists.bell-labs.com
Subject: Re: [IPTEL] TRIP question


Offload/backup gateway is one case. Another case is that of two different
ITSPs
advertising competing routes to the same destination, i.e. each of them will
have gateways that can terminate calls to this particular destination.

Hussein

"Anderson, Darby" wrote:

> According to what I understand of the Trip Protocol, this would be a
viable
> situation, the scenario youve given would be applicable in the real world
if
> you have on-net trunking to a particular destination, however not enough
> volume to justify additional capacity, so you offload the overflow to
> another carrier (ITAD in this circumstance), in which case it would seem
> logical to assign a cost of 0 to your on-net trunking, and a higher route
> cost to any/all other off-net route choices...??
>
> Anyone else out there, please correct me if Im wrong
>
> -Darby
>
> -----Original Message-----
> From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
> Sent: Thursday, August 09, 2001 8:57 AM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP question
>
> Can one telephony destination be handled by more than one
> telephony gateway.
>
> If yes, then if both gateway1 & 2 can reach a telephony destination,
> then how is it determined which is a better route to
> reach that telephony destination, via gateway1 or gateway2.
>
> Thanks.
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

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



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 14:05:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01728
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 14:05:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A12FC4438C; Thu,  9 Aug 2001 14:07:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from integraonline.com (inet-1a-bvtn.integraonline.com [206.163.82.156])
	by lists.bell-labs.com (Postfix) with SMTP id 157F34434E
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 14:06:23 -0400 (EDT)
Received: (qmail 25440 invoked from network); 9 Aug 2001 18:06:21 -0000
Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender <Darby.Anderson@integratelecom.com>)
          by inet-1b-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP
          for <hsalama@cisco.com>; 9 Aug 2001 18:06:21 -0000
Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21)
	id <QS468CQF>; Thu, 9 Aug 2001 11:06:22 -0700
Message-ID: <C4C5B6767D9B4E49AB448C67CF49F4A904D66B@beaexch2.ads.integratelecom.com>
From: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
To: "Anderson, Darby" <Darby.Anderson@integratelecom.com>,
        "'Hussein F. Salama'" <hsalama@cisco.com>
Cc: "'Vijaya Venkatachalam'" <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 11:06:20 -0700

In which case, I pose the possibility, if someone were to have a larger
POP/POPs where in which they wanted to Colocate with multiple carriers, and
bring in many circuits from many carriers, and use the same LS, with
multiple VoIP Boxes to terminate the circuits with many differing
destinations, and many differing costs (due to different Carriers), would it
be possible to partition off a ancillary route table where I could make
comparisons between TRIP Packet based off-net call termination, Vs. a TRIP
Routed Circuit based on-net call termination to another carrier?

-----Original Message-----
From: Anderson, Darby [mailto:Darby.Anderson@integratelecom.com]
Sent: Thursday, August 09, 2001 11:51 AM
To: 'Hussein F. Salama'; Anderson, Darby
Cc: 'Vijaya Venkatachalam'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question


Wouldent it be plausable in the Softswitch,SIP Controller, or whatever it is
that someone's using,when its using TRIP as an Egress protocol, that you
could assign a route cost to each destination? (I.E. I have on-net trunking
to destination 1 with a capacity of 24 chanels, I typically have 26-30 calls
in any given time to that area, Carrier A is giving me a price of .013 cents
a minute to destination 1, however Carrier B is giving me a price of .011
cents a minute to destination 1, thus my route would have priority to my
on-net trunking to destination 1, and would first route calls to Carrier B,
then if Carrier B was unable to handle the call, the Softswitch would pass
the call to Carrier A??)

-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: Thursday, August 09, 2001 11:23 AM
To: Anderson, Darby
Cc: 'Vijaya Venkatachalam'; iptel@lists.bell-labs.com
Subject: Re: [IPTEL] TRIP question


Offload/backup gateway is one case. Another case is that of two different
ITSPs
advertising competing routes to the same destination, i.e. each of them will
have gateways that can terminate calls to this particular destination.

Hussein

"Anderson, Darby" wrote:

> According to what I understand of the Trip Protocol, this would be a
viable
> situation, the scenario youve given would be applicable in the real world
if
> you have on-net trunking to a particular destination, however not enough
> volume to justify additional capacity, so you offload the overflow to
> another carrier (ITAD in this circumstance), in which case it would seem
> logical to assign a cost of 0 to your on-net trunking, and a higher route
> cost to any/all other off-net route choices...??
>
> Anyone else out there, please correct me if Im wrong
>
> -Darby
>
> -----Original Message-----
> From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
> Sent: Thursday, August 09, 2001 8:57 AM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP question
>
> Can one telephony destination be handled by more than one
> telephony gateway.
>
> If yes, then if both gateway1 & 2 can reach a telephony destination,
> then how is it determined which is a better route to
> reach that telephony destination, via gateway1 or gateway2.
>
> Thanks.
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

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



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 15:24:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03527
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 15:24:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C0CDE4438D; Thu,  9 Aug 2001 15:26:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44])
	by lists.bell-labs.com (Postfix) with ESMTP id 6D1EC44369
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 15:25:40 -0400 (EDT)
Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net)
	by dfw-smtpout4.email.verio.net with esmtp
	id 15UvR0-0002ri-00; Thu, 09 Aug 2001 19:25:34 +0000
Received: from [217.33.141.139] (helo=TELXXIS.ccnet.com)
	by dfw-mmp1.email.verio.net with esmtp
	id 15UvQz-0000xv-00; Thu, 09 Aug 2001 19:25:33 +0000
Message-Id: <5.1.0.14.0.20010809120824.00a8e680@mail.ncal.verio.net>
X-Sender: brennan@mail.ncal.verio.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Anderson, Darby" <Darby.Anderson@integratelecom.com>,
        "'Vijaya Venkatachalam'" <vijaya@ulticom.com>
From: Richard Brennan <brennan@ccnet.com>
Subject: RE: [IPTEL] TRIP question
Cc: iptel@lists.bell-labs.com
In-Reply-To: <C4C5B6767D9B4E49AB448C67CF49F4A904D669@beaexch2.ads.integr
 atelecom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 09 Aug 2001 12:25:26 -0700

Darby, Vijaya et al...

Using "dummy" rates to force route determination sequences through
LCRs is a well established practice, i.e. 0 for preferred, 1 for 2nd choice,
2 for 3rd choice, 9999 for last.... etc.  These "costing" elements would
never be exposed on an inter-domain basis.

In practice, I think it unlikely that the GW could pass any useful real
"cost" information, since the burden of constantly re-provisioning this
into the GW or Client  on a monthly, daily, or even hourly basis would
be unworkable...

Imagine a "small" network of several hundred MGs deployed across
Europe, each serving mixed PSTN & Mobile termination to both large
cities and rural E.164 numbers...  Just keeping-up with the spot-rate
changes over this range of terminations is a monumental task.

- Richard Brennan


At 10:13 AM 8/9/2001, Anderson, Darby wrote:
>According to what I understand of the Trip Protocol, this would be a viable
>situation, the scenario youve given would be applicable in the real world if
>you have on-net trunking to a particular destination, however not enough
>volume to justify additional capacity, so you offload the overflow to
>another carrier (ITAD in this circumstance), in which case it would seem
>logical to assign a cost of 0 to your on-net trunking, and a higher route
>cost to any/all other off-net route choices...??
>
>Anyone else out there, please correct me if Im wrong
>
>-Darby
>
>-----Original Message-----
>From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
>Sent: Thursday, August 09, 2001 8:57 AM
>To: iptel@lists.bell-labs.com
>Subject: [IPTEL] TRIP question
>
>
>Can one telephony destination be handled by more than one
>telephony gateway.
>
>If yes, then if both gateway1 & 2 can reach a telephony destination,
>then how is it determined which is a better route to
>reach that telephony destination, via gateway1 or gateway2.
>
>Thanks.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 15:49:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03935
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 15:49:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EAC8F4439E; Thu,  9 Aug 2001 15:51:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from web3604.mail.yahoo.com (web3604.mail.yahoo.com [216.115.111.99])
	by lists.bell-labs.com (Postfix) with SMTP id 6A9C644369
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 15:50:11 -0400 (EDT)
Message-ID: <20010809195010.77642.qmail@web3604.mail.yahoo.com>
Received: from [38.150.156.102] by web3604.mail.yahoo.com; Thu, 09 Aug 2001 12:50:10 PDT
From: lakshmi <vlakshmi70@yahoo.com>
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [IPTEL] h.323 zone vs TRIP ITAD
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 12:50:10 -0700 (PDT)

Hi,

Does the ITAD in TRIP equivalent to
a zone in H.323?

Thanks,
vlakshmi.



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 16:03:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04338
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 16:03:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6FC80443A0; Thu,  9 Aug 2001 16:05:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from integraonline.com (web-1-bvtn.integraonline.com [206.163.82.90])
	by lists.bell-labs.com (Postfix) with SMTP id 8F012443A0
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 16:04:08 -0400 (EDT)
Received: (qmail 5328 invoked from network); 9 Aug 2001 20:04:06 -0000
Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender <Darby.Anderson@integratelecom.com>)
          by web-1-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP
          for <brennan@ccnet.com>; 9 Aug 2001 20:04:06 -0000
Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21)
	id <QS468D5P>; Thu, 9 Aug 2001 13:04:07 -0700
Message-ID: <C4C5B6767D9B4E49AB448C67CF49F4A904D66C@beaexch2.ads.integratelecom.com>
From: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
To: "'Richard Brennan'" <brennan@ccnet.com>,
        "Anderson, Darby" <Darby.Anderson@integratelecom.com>,
        "'Vijaya Venkatachalam'" <vijaya@ulticom.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 13:04:06 -0700

Well...   I would agree with you that keeping track of that data at the GW
level would be an administrative nightmare, and would be a minor improvement
at a LS level.I agree it would be allmost unmanageable, however what if that
were to be provisioned on the ITAD's decision making entity (Softswitch in
this case), where in which one could dictate that TDM T1, or E1's used as an
egress from the origination network, and an ingress into an intermediate, or
finial termination network (Yet another Tandem Trunking ((LD'ish)) Network)?

In that perspective one could keep track of the provisioning data at each
gateway, and deceide on routing patterns in addition to backward TDM
compatibility to carriers that are not interested in VoIP

-----Original Message-----
From: Richard Brennan [mailto:brennan@ccnet.com]
Sent: Thursday, August 09, 2001 1:25 PM
To: Anderson, Darby; 'Vijaya Venkatachalam'
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question


Darby, Vijaya et al...

Using "dummy" rates to force route determination sequences through
LCRs is a well established practice, i.e. 0 for preferred, 1 for 2nd choice,
2 for 3rd choice, 9999 for last.... etc.  These "costing" elements would
never be exposed on an inter-domain basis.

In practice, I think it unlikely that the GW could pass any useful real
"cost" information, since the burden of constantly re-provisioning this
into the GW or Client  on a monthly, daily, or even hourly basis would
be unworkable...

Imagine a "small" network of several hundred MGs deployed across
Europe, each serving mixed PSTN & Mobile termination to both large
cities and rural E.164 numbers...  Just keeping-up with the spot-rate
changes over this range of terminations is a monumental task.

- Richard Brennan


At 10:13 AM 8/9/2001, Anderson, Darby wrote:
>According to what I understand of the Trip Protocol, this would be a viable
>situation, the scenario youve given would be applicable in the real world
if
>you have on-net trunking to a particular destination, however not enough
>volume to justify additional capacity, so you offload the overflow to
>another carrier (ITAD in this circumstance), in which case it would seem
>logical to assign a cost of 0 to your on-net trunking, and a higher route
>cost to any/all other off-net route choices...??
>
>Anyone else out there, please correct me if Im wrong
>
>-Darby
>
>-----Original Message-----
>From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com]
>Sent: Thursday, August 09, 2001 8:57 AM
>To: iptel@lists.bell-labs.com
>Subject: [IPTEL] TRIP question
>
>
>Can one telephony destination be handled by more than one
>telephony gateway.
>
>If yes, then if both gateway1 & 2 can reach a telephony destination,
>then how is it determined which is a better route to
>reach that telephony destination, via gateway1 or gateway2.
>
>Thanks.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 17:38:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06084
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:38:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C887144388; Thu,  9 Aug 2001 17:40:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 0452544369
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 17:39:22 -0400 (EDT)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f79LdWJ23037;
	Thu, 9 Aug 2001 14:39:32 -0700 (PDT)
Received: from cisco.com (manjax-ultra5.cisco.com [128.107.138.93])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AHB03627 (AUTH manjax);
	Thu, 9 Aug 2001 14:39:19 -0700 (PDT)
Message-ID: <3B730307.A662E0C9@cisco.com>
From: Manjunath Bangalore <manjax@cisco.com>
Organization: Cisco Systems Inc., San Jose, CA
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: lakshmi <vlakshmi70@yahoo.com>
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] h.323 zone vs TRIP ITAD
References: <20010809195010.77642.qmail@web3604.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 09 Aug 2001 14:39:19 -0700
Content-Transfer-Encoding: 7bit

 Though I am not aware of any H.323 deployments yet using TRIP, I would
think a TRIP ITAD would typically correspond to multiple H.323 zones.

-Manjax

lakshmi wrote:

> Hi,
>
> Does the ITAD in TRIP equivalent to
> a zone in H.323?
>
> Thanks,
> vlakshmi.
>


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug  9 19:01:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06982
	for <iptel-archive@odin.ietf.org>; Thu, 9 Aug 2001 19:01:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5FA2744369; Thu,  9 Aug 2001 19:03:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id AA2E844357
	for <iptel@lists.bell-labs.com>; Thu,  9 Aug 2001 19:02:29 -0400 (EDT)
Received: from oranlt (rtp-vpn2-34.cisco.com [10.82.240.34])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f79N2hE26461;
	Thu, 9 Aug 2001 16:02:44 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'lakshmi'" <vlakshmi70@yahoo.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] h.323 zone vs TRIP ITAD
Organization: Cisco Systems
Message-ID: <006401c12127$d5cc1f10$d58821d9@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <20010809195010.77642.qmail@web3604.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Aug 2001 19:05:47 -0400
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of lakshmi
> Sent: Thursday, August 09, 2001 3:50 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] h.323 zone vs TRIP ITAD
> 
> 
> Hi,
> 
> Does the ITAD in TRIP equivalent to
> a zone in H.323?
>
No. 

For one thing, ITADS can get very large and zones can't.
There are some superficial similarities in that the boundaries of both
are defined administratively, but that's about it.

If I hadto come up with an analog to an ITAD in H.323, it would be a
colleciton of Border Gatekeepers all in the same administrativie domains
running Annex G.

Dave.
 
> Thanks,
> vlakshmi.
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger http://phonecard.yahoo.com/
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com 
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 10 05:00:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01612
	for <iptel-archive@odin.ietf.org>; Fri, 10 Aug 2001 05:00:56 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 30BBE44391; Fri, 10 Aug 2001 05:02:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by lists.bell-labs.com (Postfix) with ESMTP id B13074438F
	for <iptel@lists.bell-labs.com>; Fri, 10 Aug 2001 05:01:09 -0400 (EDT)
Received: from [217.33.146.154] (helo=kibotop)
	by relay2.bt.net with smtp (Exim 3.15 #1)
	id 15V89l-0001GF-00; Fri, 10 Aug 2001 10:00:38 +0100
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: "Vijaya Venkatachalam" <vijaya@ulticom.com>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP question
Message-ID: <JJEOJFDNKAJPMKFNJCCGGEEFCKAA.kbodouhi@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3B72A4C4.A423B922@ulticom.com>
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 10 Aug 2001 13:33:54 +0430
Content-Transfer-Encoding: 7bit


I believe the local implementation of routing process should be in a way
that can do a fair load balancing of equal metric routes. For non equal
routes, things like capacity, rate, quality ... will be important. The
traffic should be load balanced based on some algorithm like following:

1- If the capacity of one route is more, then the traffic should be load
balanced based on capacity ratios. So although the gateway with more
capacity
should be in the first it routing but that doesn't necessary means that
it receives whole traffic and if become full then we use second route.

2- The second group of metrics that are important are rate, quality and
administrative preference. Which for rate a lower one is preferred and
for quality the higher one. Each of these attributes should have a weight
factor which can be set by administrator.


Kiarash


> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Vijaya
> Venkatachalam
> Sent: Thu, August 09, 2001 7:27 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP question
>
>
> Can one telephony destination be handled by more than one
> telephony gateway.
>
> If yes, then if both gateway1 & 2 can reach a telephony destination,
> then how is it determined which is a better route to
> reach that telephony destination, via gateway1 or gateway2.
>
> Thanks.
>


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 10 11:47:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06719
	for <iptel-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:47:55 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7271B4435F; Fri, 10 Aug 2001 11:49:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from integraonline.com (web-2-bvtn.integraonline.com [206.163.82.91])
	by lists.bell-labs.com (Postfix) with SMTP id 6D5554435C
	for <iptel@lists.bell-labs.com>; Fri, 10 Aug 2001 11:48:14 -0400 (EDT)
Received: (qmail 23228 invoked from network); 10 Aug 2001 15:48:12 -0000
Received: from fw-1-bvtn.integratelecom.com (HELO beaexch2.ads.integratelecom.com) ([206.163.82.5]) (envelope-sender <Darby.Anderson@integratelecom.com>)
          by web-2-bvtn.integraonline.com (qmail-ldap-1.03) with SMTP
          for <vijaya@ulticom.com>; 10 Aug 2001 15:48:12 -0000
Received: by beaexch2.ads.integratelecom.com with Internet Mail Service (5.5.2650.21)
	id <QS468JKQ>; Fri, 10 Aug 2001 08:48:13 -0700
Message-ID: <C4C5B6767D9B4E49AB448C67CF49F4A904D66F@beaexch2.ads.integratelecom.com>
From: "Anderson, Darby" <Darby.Anderson@integratelecom.com>
To: "'Kiarash Bodouhi'" <kbodouhi@yahoo.com>,
        Vijaya Venkatachalam <vijaya@ulticom.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 10 Aug 2001 08:48:12 -0700

Ill raise one to that...

but if someone were to use the example I cited yesterday, where they tie
circuits from other LD networks into a Media GW, would there still be some
type of an ancillary route partition for recognizing that its 1/2 on packet
based TRIP, and dumps off the other 1/2 of the route to a TDM circuit on a
Media GW (E.G. Circuit data would reside on the GW, trunking data would
reside on the softswitch?)

-----Original Message-----
From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
Sent: Friday, August 10, 2001 3:04 AM
To: Vijaya Venkatachalam; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP question



I believe the local implementation of routing process should be in a way
that can do a fair load balancing of equal metric routes. For non equal
routes, things like capacity, rate, quality ... will be important. The
traffic should be load balanced based on some algorithm like following:

1- If the capacity of one route is more, then the traffic should be load
balanced based on capacity ratios. So although the gateway with more
capacity
should be in the first it routing but that doesn't necessary means that
it receives whole traffic and if become full then we use second route.

2- The second group of metrics that are important are rate, quality and
administrative preference. Which for rate a lower one is preferred and
for quality the higher one. Each of these attributes should have a weight
factor which can be set by administrator.


Kiarash


> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Vijaya
> Venkatachalam
> Sent: Thu, August 09, 2001 7:27 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP question
>
>
> Can one telephony destination be handled by more than one
> telephony gateway.
>
> If yes, then if both gateway1 & 2 can reach a telephony destination,
> then how is it determined which is a better route to
> reach that telephony destination, via gateway1 or gateway2.
>
> Thanks.
>


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Aug 13 06:38:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13201
	for <iptel-archive@odin.ietf.org>; Mon, 13 Aug 2001 06:38:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 26BF24433C; Mon, 13 Aug 2001 05:43:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from localhost.localdomain (unknown [195.146.53.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 532A54433C
	for <iptel@lists.bell-labs.com>; Mon, 13 Aug 2001 05:42:08 -0400 (EDT)
Received: from kibotop ([195.146.53.14])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id PAA16943;
	Mon, 13 Aug 2001 15:08:09 +0430
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: "Anderson, Darby" <Darby.Anderson@integratelecom.com>,
        "Vijaya Venkatachalam" <vijaya@ulticom.com>,
        <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP question
Message-ID: <JJEOJFDNKAJPMKFNJCCGOEFECKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <C4C5B6767D9B4E49AB448C67CF49F4A904D66F@beaexch2.ads.integratelecom.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Aug 2001 15:11:29 +0430
Content-Transfer-Encoding: 7bit


We can use random prefix codes to facilitate differentiation between
different routes or in situation like the one you cited. These prefixes
can be added easily at the ingress point and strip off at egress. Meanwhile
things line capacity can be grouped in a way that can easily
work with this scheme and recognizes different prefixes locally at gateways.

Kiarash

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Anderson, Darby
> Sent: Fri, August 10, 2001 8:18 PM
> To: 'Kiarash Bodouhi'; Vijaya Venkatachalam; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] TRIP question
>
>
> Ill raise one to that...
>
> but if someone were to use the example I cited yesterday, where they tie
> circuits from other LD networks into a Media GW, would there still be some
> type of an ancillary route partition for recognizing that its 1/2
> on packet
> based TRIP, and dumps off the other 1/2 of the route to a TDM circuit on a
> Media GW (E.G. Circuit data would reside on the GW, trunking data would
> reside on the softswitch?)
>
> -----Original Message-----
> From: Kiarash Bodouhi [mailto:kbodouhi@yahoo.com]
> Sent: Friday, August 10, 2001 3:04 AM
> To: Vijaya Venkatachalam; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] TRIP question
>
>
>
> I believe the local implementation of routing process should be in a way
> that can do a fair load balancing of equal metric routes. For non equal
> routes, things like capacity, rate, quality ... will be important. The
> traffic should be load balanced based on some algorithm like following:
>
> 1- If the capacity of one route is more, then the traffic should be load
> balanced based on capacity ratios. So although the gateway with more
> capacity
> should be in the first it routing but that doesn't necessary means that
> it receives whole traffic and if become full then we use second route.
>
> 2- The second group of metrics that are important are rate, quality and
> administrative preference. Which for rate a lower one is preferred and
> for quality the higher one. Each of these attributes should have a weight
> factor which can be set by administrator.
>
>
> Kiarash
>
>
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Vijaya
> > Venkatachalam
> > Sent: Thu, August 09, 2001 7:27 PM
> > To: iptel@lists.bell-labs.com
> > Subject: [IPTEL] TRIP question
> >
> >
> > Can one telephony destination be handled by more than one
> > telephony gateway.
> >
> > If yes, then if both gateway1 & 2 can reach a telephony destination,
> > then how is it determined which is a better route to
> > reach that telephony destination, via gateway1 or gateway2.
> >
> > Thanks.
> >
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Aug 20 16:52:19 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03548
	for <iptel-archive@odin.ietf.org>; Mon, 20 Aug 2001 16:52:19 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19A3644337; Mon, 20 Aug 2001 15:56:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id D2EAB44336
	for <iptel@lists.bell-labs.com>; Mon, 20 Aug 2001 15:55:10 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KKporN002253
	for <iptel@lists.bell-labs.com>; Mon, 20 Aug 2001 16:51:50 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RBX3AQBZ>; Mon, 20 Aug 2001 16:52:38 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D65A6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] minutes and slides from IETF 51
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 20 Aug 2001 16:52:37 -0400

Folks,

You can find a copy of the slides I presented at IETF 51 at:

http://www.jdrosen.net/papers/iptel_slides_51.ppt

Minutes for the meeting are below. Thanks to Mary Barnes for taking notes.
If there are any corrections, please let me know by the end of this week.

Thanks,
Jonathan R.

-------------
Minutes of the IP Telephony (iptel) Working Group
IETF 51
Minutes taken by: Mary Barnes
Minutes prepared by: Jonathan Rosenberg



The IP telephony (iptel) group met for a single, one hour session at
IETF 51. The proposed agenda was:

Agenda Bashing				5m
CPL and TRIP Status			5m
Charter Review				10m
TRIP for GW				10m

The agenda was agreed upon.

First up was a status update on TRIP and CPL. CPL is still blocked on
calsch issues. Scott Bradner indicated that he is hoping to get this
resolved finally. TRIP has been going through the IESG, with minor
comments getting incorporated. Scott indicated that IESG has, in fact,
approved TRIP for RFC.

The new charter is presented. There are two items, a TRIP MIB, due in
September 01, and "TRIP for gateways", also known as "TRIP-lite", due
to IESG Jan 02.

Next, is a discussion on the changes to the gateway registration draft since
the last iteration. These changes are:

*  Explicit requirements defined
*  Comparison with existing protocols
*  Inclusion of open issues
*  Removed DSP Capacity

DSP capacity was removed because its not clear how to use it, and can
be factored into the circuit capacity attribute. Concerns are raised
about its removal. Dave Oran made some arguments that the meaning of
the parameter wasn't important, so long as its statistics had specific
value. The chair indicated that unless it was well documented and
described, it would result in vendor tie-in between gateway and
proxy. Dave agreed to provide some more detailed definitions.

Next up, we discuss the requirements for the trip for gateways
protocol, in general terms:

1.	Fast call setup 
2.	Conveys failures of gateways rapidly
3.	Conveys restarts of gateways rapidly
4.	Proxy has some way to know available capacity
5.	Security: mutual authentication and integrity.  Privacy less
critical.
6.	Convey routing preferences
7.	Timeliness of attribute information
8.	Extensible attributes
9.	Efficient
10.	Centralization of policy  (Proxy server in front of the
gateways ultimately makes the decision on how the call is routed) 
11.	Proxies in ITAD make independent policy decisions.

Henning objects to requirement 5, stating that mutual authentication
isn't needed. He claims its at odds with privacy. The reason is that
Henning has a somewhat different model in mind. He is interested in an
enterprise problem, where a proxy dynamically discovers the gateways
it can route calls to. As such, mutual auth is a pain since its more
of an advertisement protocol. As such, Henning wants to add
auto-configuration as a requirement. Jonathan argues that this complicates
policy, since its hard to define policy over managing gateways that
you only later discover. Henning argues that this is not true - since
the gateways may go up or crash, there is already a need for policy
which handles the case where the number of gateways varies.

Next, Jonathan asks whether auto-discovery a requirement or not?
Some argue that this is needed anyway for scalability and
reliability. Dave asks who is discovering who? Are gateways
discovering proxies, or the other way around? There is some debate
about this.  Jonathan proposes that we make autodiscovery
orthogonal to TRIP - i.e., discover it somehow, then use TRIP-lite
between them. Henning objects to that also, since he doesn't want
three protocols where one will do. He indicates that the question is
whether existing protocols meet all of the requirements or not. Jon
Peterson asks about whether we are talking about auto-configuration or
auto-discovery - ie., are RIBs generated automatically from the
combination of policy + TRIBs? Jonathan indicates that this is not what we
are
talking about, and that this is an interesting question but for later
work.

The consensus of the room is that auto-discovery is not a bad thing,
but still not clear its needed.

Next, Jonathan presents the analysis of existing solutions. The focus
is on SLP, and he argues that there are two cases. In case 1, the
gateway is an SLP SA, and the proxy is a DA. In case 2, the gateway is
an SLP SA, and the proxy is a UA (there is no DA). Jonathan argues
that case 2 is bad, since it introduces delay and makes centralization
of policy hard. Henning argues that the UA can cache the service
replies. The reply is that service announcements had lifetimes, not
the service replies. He said that no, the service replies can remain
active without requerying. Jonathan argued that this is basically
approach 1, which makes more sense.

Rohan Mahy expresses concern about a terminology problem. Is a proxy
the same as LS in these discussions? The answer is yes, and that
Jonathan has been lazy with terminology. The proxy = the LS that is
managing the gateways.

Henning argues that the intra-domain problem is much different than
inter-domain, and that something like SLP is more appropriate
intra-domain. SLP is done already, and does autodiscovery and
propagation of attributes. Its also simpler, since TRIP is a very
complex protocol. Jonathan asks what aspects of TRIP are more than you need,
and would not be present in an SLP protocol. Henning responds that you
don't need the transition of information into an inter-domain
protocol, since there may not be one running. Jonathan argues that this is
not
a technical objection per se, since there is no cost to that aspect of
TRIP. The question is: if you use TRIP instead of SLP, what features
do you need to implement that otherwise wouldn't be needed (i.e., are
there because of the "legacy" TRIP usage). It wasn't clear what those
things were. Jonathan argued with Henning that both TRIP and SLP "exist", so
arguing about using an "existing" protocol is moot in this case. 

In order to move forward, the chair imposes the following decision:

1. we will have an open call for concrete, written up proposals in
Internet Drafts form, which must be received by September 7 (one month
from the meeting date). If there are no concrete proposals for SLP or
anything else, we will move forward with the current proposal. We have
tight deadlines and they need to be met. The proposals must outline
concrete things in the current proposal which are not needed, but must
be implemented because of "legacy" usage. Only concrete technical
statements will be accepted. Things like "too complex" or "won't
scale" are not acceptable.

2. requirements are critical for evaluation of the proposals. Please
contribute requirements to the list for discussion.

With that, the meeting closes.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug 22 07:07:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29604
	for <iptel-archive@odin.ietf.org>; Wed, 22 Aug 2001 07:07:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BF10544339; Wed, 22 Aug 2001 06:11:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from localhost.localdomain (unknown [195.146.53.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 3F7F744336
	for <iptel@lists.bell-labs.com>; Wed, 22 Aug 2001 06:10:18 -0400 (EDT)
Received: from kibotop ([195.146.53.14])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id PAA25448
	for <iptel@lists.bell-labs.com>; Wed, 22 Aug 2001 15:37:19 +0430
From: "Kiarash Bodouhi" <kbodouhi@yahoo.com>
To: <iptel@lists.bell-labs.com>
Message-ID: <JJEOJFDNKAJPMKFNJCCGAEJOCKAA.kbodouhi@yahoo.com>
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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Subject: [IPTEL] TRIP GW requirements
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Aug 2001 15:40:40 +0430
Content-Transfer-Encoding: 7bit



Hello all,

Following is a copy of all requirements stated in draft-rs-trip-gw-02.txt.
Although
TRIP seems to cover all requirements in comparison with other protocols
stated in
the document but it doesn't necessarily mean that this is the most
appropriate
protocol for this job. If we design a protocol based on UDP with much less
complexities and lighter for the gateways to handle then we can also meet
all
the requirements. If we would like to maintain the consistency of this new
protocol with TRIP itself we can easily use the same attributes with the
same semantics in the new UDP based protocol as well. I would like to bring
this important
point to your consideration that TRIP GW will be more important for today
usage of most of ITSPs. Because still many ITSPs can be categorized as
within
one ITADs and there are few of them which what to established complex
systems based on
different ITADs and various routing policies. So at this moment what ITSPs
need
is a good registration protocol that can carry the information that is
required
to make the best decision in the routing process in proxies with the
features
that is mentioned for TRIP GW.

   REQ 1: Fast: Call setup time is affected if the protocol
             requires communications between the proxy and the gateway
             at the actual time of call setup. Therefore, such
             communications should be minimized, ideally occurring before
             call setup.

- If we consider that registration request will be submitted as UDP message
containing necessary attributes from GW to LS then we will have much better
call setup time in comparison with TRIP which depends on TCP.

        REQ 2: Failure Detection: One of the most important pieces of
             information for the proxy to know is the availability of
             the gateway. There must be a way for the proxy to rapidly
             detect failures of gateways, so that alternates can be
             used.

- GW can generate UDP updates with the speed of the changes in the GW
important parameters like capacity,... . As these information are time
sensitive so a capacity update message which is lost will be no longer
valid for retransmission. This is where TCP makes problem  with
EC and flow control built in it. Also the UDP packet loss ratio will
be a good signal for the proxy to evaluate the link reliability of the
GW which can be considered in routing decision. For failure detection
we can set a maximum and minimum time for sending the updates and
when ever the LS stops getting the updates then the GW is down.

        REQ 3: Startup Detection: When a failed gateway recovers, there
             must be a way for the proxy to determine this rapidly and
             automatically, so that it can begin using it again to
             terminate calls.

- UDP is better( it is obvious)

        REQ 4: Capacity Knowledge: The proxy must have a way to
             determine with high probability, in advance of a call, that
             the gateway selected has sufficient capacity to terminate
             the call. Knowing this in advance of the call helps keep
             call setup delays uniform even during periods of heavy
             usage.

- This is an important issue. I would like to categorize capacity here and
see what will be important for this part although the things I am going to
mention here is not necessarily related to TRIP but should be considered
by vendors to see how a GW can calculate this capacity and report it to LS.
First, if the GW has got certain number of PSTN ports for terminating a
prefix that doesn't necessarily mean that the LS can use the whole capacity.
As the GW might be a part of two separate ITADs and the GW owner wants to
allocate specific number of ports to each of them. Second is that the owner
might want to assign some shared number of ports to two or more ITADs to
terminate
a prefix. In this case, gateway should be able to report capacity to each LS
in way that the traffic can fairly accepted and load balanced between them.
This is the point that the GW administrator will impose it's own policies
by giving desired information to the LSes. We have to make the GWs in a way
that we can configure the number of dedicated and shared ports for each
ITAD.
The port capacity can be segregated from other LS usage by adding random
prefixes
at ingress point and then stripping off these at engross. This prefixes
can also be used as a part of authentication system. On shared ports the
capacity
should be reported to LS based on average available capacity in certain
period
for the whole shared ports and the average number of calls terminated from
each ITADs.
I can be more specific in this part if anybody asks for more clarifications.

        REQ 5: Secure: The communications between the proxy and gateway
             need to provide mutual authentication and message
             integrity. Privacy may be required, but it is less
             critical. The associations between proxies and gateways are
             long lived.

- TRIP used IP Sec which is simply too much secure for this usage. I believe
a simple MD5 hash of a shared community string and the termination prefix
will
be enough. It decrease setup time and complexity of the protocol and it
should be mandatory in the implementation as the protocol without the
security
part is useless.

 REQ 6: Convey Routing Preferences: Each gateway is configured
             with set of POTS numbers that is capable of terminating to
             with a variety of costs. The information on which ranges of
             phone numbers a gateway can terminate to, and with what
             relative preference, need to be propagated to the proxy.


             OPEN ISSUE: It has been argued in the past that in
             real configurations, the proxy would be directly
             programmed with this information, rather than having
             the gateways propagate it to the proxy. As such, we
             need to debate whether this is really a requirement.

- The proxy should receive this information from GW but should have
the ability to over write them.

        REQ 7: Timeliness: The information that the proxy learns about
             the characteristics of the gateway - its availability,
             capacity, and route preferences - must be learned in a
             timely fashion. Here, timely is on the order of seconds or
             less.

-UDP based is better in this part as well.

        REQ 8: Extensible attributes: The proxy may need to know other
             information about the gateways - ISUP variant support,
             codec support, etc., in order to route a call to a gateway.
             The protocol has to provide a way for this kind of
             information to be easily added.


             OPEN ISSUE: This requirement may be moot if its
             decided that REQ 6 is not really a requirement.
             Effectively, if REQ 6 is not a requirement, we don't
             need propagation of static information from the
             gateway to the proxy. That would include additional
             attributes such as the ones mentioned here.


             OPEN ISSUE: Are these attributes characteristic of
             routes, or of the gateway itself? TRIP defines them as
             attributes of routes, and this means that they would
             be copied for each route that gets propagated. For
             other attributes, like capacity, it could not be
             copied, and the capacity would have to be divided
             amongst routes. How would that be done? Points to a
             potential open hold in TRIP usage for this
             application.

- This problem will also be resolved. GW specific information will be
received by LS but it is up to the LS to aggregate and distribute these
information to other LSes.

        REQ 9: Efficient: The protocol should not generate too much
             traffic.
             OPEN ISSUE: Need to quantify this.

- Although we might have to send more date on UDP but if you cpmpare that
to additional headers and information that TCP and IP Sec will add then
UDP will be a better option.

        REQ 10: Proxy Control: The protocol should put the proxy in
             control of making a decision about where the call should
             ultimately be routed. This facilitates distribution of
             information (from the gateways) but centralization of
             policy.

- No comment

        REQ 11: Independent Policies: The protocol should allow two
             different proxies within the same ITAD to make different
             decisions on which gateway to use for the same call. This
             might be desirable for load balancing purposes, for
             example.


             OPEN ISSUE: This is an important one to discuss, since
             it is the main differentiator between a routing
             protocol and a database protocol. If we don't need
             different proxies to get different answers about
             gateway availability depending on which proxy asks,
             its not a routing problem, and then TRIP may not be
             the ideal candidate for this usage!

- Load balancing should be done based on capacity ratios. In fact we need
such policy based answers to proxies in real world usage and we have to
define a solution for this.

Regards
Kiarash


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug 22 11:19:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13079
	for <iptel-archive@odin.ietf.org>; Wed, 22 Aug 2001 11:19:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AA97B44341; Wed, 22 Aug 2001 10:23:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id CD0EF44336
	for <iptel@lists.bell-labs.com>; Wed, 22 Aug 2001 10:22:14 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MFJArN015579
	for <iptel@lists.bell-labs.com>; Wed, 22 Aug 2001 11:19:10 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RBX3A4XZ>; Wed, 22 Aug 2001 11:19:59 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D660A@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] FW: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Aug 2001 11:19:59 -0400

Folks,

As we discussed in the meeting, the iptel group is currently chartered to
complete a TRIP MIB for submission to IESG in September of 2001. I am
committed to NOT missing the dates in our current charter, as we did an
awful job of meeting our deadlines for our initial deliverables. 

So, I would now like to open a two week working group last call for
draft-ietf-iptel-trip-mib-00.txt. Please send comments on this document to
the list within the next two weeks. I also want this document formally
reviewed, in detail, by a TRIP expert and a MIB expert. Thus, I am
requesting two volunteers (one TRIP expert, one MIB expert) to perform a
detailed review during the last call period. If I do not get two volunteers
by Monday Aug 27, I will tap people explicitly for the review, and use
excessive amounts of guilt and other forms of persuasion to convince them to
review it.

Please email me privately if you wish to do a detailed review.

Thanks,
Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, August 21, 2001 7:25 AM
Cc: iptel@lists.bell-labs.com
Subject: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: Management Information Base for Telephony Routing
over
                          IP (TRIP)
	Author(s)	: J. Jiang, D. Walker, D. Zinman
	Filename	: draft-ietf-iptel-trip-mib-00.txt
	Pages		: 40
	Date		: 20-Aug-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage for Telephony Routing over IP (TRIP) [2] devices.
Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4)
[3], the managed objects for TRIP are also modelled after RFC1657 -
Definitions of Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2 [4].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-trip-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trip-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug 23 10:57:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24830
	for <iptel-archive@odin.ietf.org>; Thu, 23 Aug 2001 10:57:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4848A4434C; Thu, 23 Aug 2001 10:01:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailer.wtmea.com (unknown [62.140.66.90])
	by lists.bell-labs.com (Postfix) with SMTP id 421A144336
	for <iptel@lists.bell-labs.com>; Tue, 21 Aug 2001 04:30:32 -0400 (EDT)
Received: (qmail 9474 invoked from network); 21 Aug 2001 09:30:00 -0000
Received: from elmouftares.wtmea.com (HELO ieee.org) (62.140.66.105)
  by wthome.wtmea.com with SMTP; 21 Aug 2001 09:30:00 -0000
Message-ID: <3B82290A.3D1A6D18@ieee.org>
From: Khaled Elsayed <khaled@ieee.org>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: khaled@ieee.org, michah@ieee.org
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: [IPTEL] CFP: IEEE Communications Magazine - Internet Techology Series
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Aug 2001 12:25:30 +0300
Content-Transfer-Encoding: 8bit

                 
Appologies if you receive multiple copies. 

HTML version of this CFP can be found at
http://inetserie.tripod.com/cfp.html


                 Call for Papers
             IEEE Communications Magazine
              Internet Technology Series
                   Series Editors
 Michah Lerner (AT&T) and Khaled Elsayed (Cairo University)
                       IP in 2005 
       Scalability, Programmability, and Virtualization 
                in the Internet


The scalable Internet presents challenges and paradoxes.
Scalable and malleable services leverage stateless
distributed control over the global address space. Transport
bindings nevertheless influence service behavior through the
control of access, the logical flow of information, as well
as the availability of diverse content. Such systems
challenge the traditional traffic engineering methods for
allocation of buffers and assignment of resources. The
Internet Technology series of the IEEE Communications
Magazine is calling for original tutorial papers about these
challenges and their resolution, and suggest the following
topics: 

- Scalability issues in BGP and routing tables 

- Clouds (native IP) vs. strings (MPLS) - Internet evolution
  choices 

- Programmable routers - architectures and services 

- Instantiation and Virtualization – IP services provide
  concrete capabilities through the structuring of
  resources. 

- Virtualization of the transport service layers - such as
  pervasive virtual private networks 

- Internet services - multilevel and location-aware mobile
  services, including voice over IP (VoIP) 

IEEE Communications Magazine is read by tens of thousands of
Communications Society members. The papers will be available
on the Internet through Communications Magazine Interactive,
the WWW edition of the magazine. Details about IEEE
Communications Magazine can be found at
http://www.comsoc.org/ci/. 
Sample publications published within the Internet Technology
Series can be found in the January 2001 and July 2001 issues
of the IEEE Communicarions Magazine. 

Tentative Schedule
 
 Manuscripts due: Nov 1, 2001 
Notification of acceptance: Jan 15, 2002  
(for the April 2002 issue) 
Final copy due: One month before final publication date 
Prospective Magazine issues: April, August, and Oct. 2002 

How to Submit Manuscripts
Article Style Information 
========================= 
Articles should be tutorial in nature and should be written
in a style comprehensible to readers outside the specialty
of the article. Articles may be edited for content, and will
be copyedited for compliance with the magazine's style
guidelines. Page proofs will be sent to the contact author
for final review prior to publication. 

Mathematical equations should not be used unless they are
vital to the presentation. Even then, they should be kept to
a minimum. If the article has numerous equations, please
contact the editor handling the manuscript. 

References should be included only to guide readers to more
information on the topic; the reference list should not
include every available source (a limit of ten references is
recommended). Use footnotes only where necessary. 

Articles should not exceed 4500 words. 

Figures and tables should be limited to a combined total of
six. If the article exceeds these recommended limits, please
contact the editor handling the manuscript. 

Submission 
========================= 
Electronic submission of manuscripts as either PDF
(preferred) or Postscript is required. Please send your
submission to both of the series editors: 
Khaled Elsayed: khaled@ieee.org 
Michah Lerner: michah@ieee.org

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug 23 11:00:22 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24993
	for <iptel-archive@odin.ietf.org>; Thu, 23 Aug 2001 11:00:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 436FA4435A; Thu, 23 Aug 2001 10:01:06 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 8AAB844336
	for <iptel@lists.bell-labs.com>; Tue, 21 Aug 2001 06:28:26 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04923;
	Tue, 21 Aug 2001 07:24:45 -0400 (EDT)
Message-Id: <200108211124.HAA04923@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: iptel@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-mib-00.txt
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Aug 2001 07:24:44 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: Management Information Base for Telephony Routing over
                          IP (TRIP)
	Author(s)	: J. Jiang, D. Walker, D. Zinman
	Filename	: draft-ietf-iptel-trip-mib-00.txt
	Pages		: 40
	Date		: 20-Aug-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage for Telephony Routing over IP (TRIP) [2] devices.
Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4)
[3], the managed objects for TRIP are also modelled after RFC1657 -
Definitions of Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2 [4].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-trip-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trip-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010820135620.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-trip-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-trip-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010820135620.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug 23 11:04:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25058
	for <iptel-archive@odin.ietf.org>; Thu, 23 Aug 2001 11:04:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9714F4435F; Thu, 23 Aug 2001 10:01:10 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147])
	by lists.bell-labs.com (Postfix) with ESMTP id EC92844336
	for <iptel@lists.bell-labs.com>; Wed, 22 Aug 2001 10:07:08 -0400 (EDT)
Received: from DAVID ([192.168.1.61]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id Q6BA7CJM; Wed, 22 Aug 2001 11:04:56 -0400
From: "David Zinman" <david@ss8.com>
To: <iptel@lists.bell-labs.com>
Message-ID: <NDBBIMHCHEHIBCDKLHLKOEEBCPAA.david@ss8.com>
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 IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <200108211124.HAA04923@ietf.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: [IPTEL] RE: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Aug 2001 11:05:05 -0400
Content-Transfer-Encoding: 7bit


Please submit any issues and comments to
this group.


-----Original Message-----
From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On
Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, August 21, 2001 7:25 AM
To: IETF-Announce: ;
Cc: iptel@lists.bell-labs.com
Subject: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: Management Information Base for Telephony Routing over
                          IP (TRIP)
	Author(s)	: J. Jiang, D. Walker, D. Zinman
	Filename	: draft-ietf-iptel-trip-mib-00.txt
	Pages		: 40
	Date		: 20-Aug-01

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage for Telephony Routing over IP (TRIP) [2] devices.
Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4)
[3], the managed objects for TRIP are also modelled after RFC1657 -
Definitions of Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2 [4].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-trip-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trip-mib-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug 23 16:08:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00498
	for <iptel-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:08:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD7C14434D; Thu, 23 Aug 2001 15:12:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from plmler2.mail.eds.com (plmler2.mail.eds.com [199.228.142.72])
	by lists.bell-labs.com (Postfix) with ESMTP id E8F1D44336
	for <iptel@lists.bell-labs.com>; Thu, 23 Aug 2001 15:11:40 -0400 (EDT)
Received: from plmlir3.mail.eds.com (plmlir3-2.mail.eds.com [199.228.143.134])
	by plmler2.mail.eds.com (8.11.1/8.11.1) with ESMTP id f7NK9aa06397
	for <iptel@lists.bell-labs.com>; Thu, 23 Aug 2001 16:09:36 -0400
Received: from plmlir3.mail.eds.com (localhost [127.0.0.1])
	by plmlir3.mail.eds.com (8.11.4/8.11.3) with ESMTP id f7NK9Tj19411
	for <iptel@lists.bell-labs.com>; Thu, 23 Aug 2001 15:09:29 -0500 (CDT)
Received: from usplm001.exch.eds.com ([198.132.135.6])
	by plmlir3.mail.eds.com (8.11.4/8.11.3) with ESMTP id f7NK9Sa19406
	for <iptel@lists.bell-labs.com>; Thu, 23 Aug 2001 15:09:28 -0500 (CDT)
Received: by usplm001.examhub.exch.eds.com with Internet Mail Service (5.5.2653.19)
	id <RJ1BNPMB>; Thu, 23 Aug 2001 15:09:26 -0500
Message-ID: <2BE915A69EF4D2119A0800805FF5E0500BF00F3C@BRSPM201>
From: "Crizza, Roberto" <roberto.crizza@eds.com>
To: "Iptel (E-mail)" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] TRIP Question
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Aug 2001 15:07:28 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00498

Folks

For a good voice quality the response time between source and destination
should be less than 150 ms, Is possible use the keep alive with one clock
and create one threshold for measuring the response time between LS internal
or external ?

Regards

Roberto Crizza
EDS Brazil - CI - Telecomunicações 
Fone.:	55 11 3471-4536 (8-893- )
Fax.:	55 11 3471-4557 (8-893- )
Celular.:	55 11 9757-7505
email.:	roberto.crizza@eds.com
Pager. :	55 11 5188-3838 PIN# 51091 - http://www.pagenet.com.br/




_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 24 11:57:48 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07885
	for <iptel-archive@odin.ietf.org>; Fri, 24 Aug 2001 11:57:48 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7DE3544338; Fri, 24 Aug 2001 11:01:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from squid.squirehome.org (rdu88-253-018.nc.rr.com [24.88.253.18])
	by lists.bell-labs.com (Postfix) with ESMTP id 151C944336
	for <iptel@lists.bell-labs.com>; Thu, 23 Aug 2001 19:42:47 -0400 (EDT)
Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2])
	by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f7O0egt28491;
	Thu, 23 Aug 2001 20:40:42 -0400
Message-ID: <3B85A28A.871963FD@acm.org>
From: Matt Squire <mattsquire@acm.org>
Reply-To: mattsquire@acm.org
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en, pdf
MIME-Version: 1.0
To: "Crizza, Roberto" <roberto.crizza@eds.com>
Cc: "Iptel (E-mail)" <iptel@lists.bell-labs.com>
Subject: Re: [IPTEL] TRIP Question
References: <2BE915A69EF4D2119A0800805FF5E0500BF00F3C@BRSPM201>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Aug 2001 20:40:42 -0400
Content-Transfer-Encoding: 7bit


The 150 ms number is the round trip time for the data/voice channel,
correct?

The keepalive in TRIP is between LSs and has nothing to do with the data
channel.  Maybe I'm just confused about what you're asking.

- Matt

> Folks
> 
> For a good voice quality the response time between source and destination
> should be less than 150 ms, Is possible use the keep alive with one clock
> and create one threshold for measuring the response time between LS internal
> or external ?
> 
> Regards
> 
> Roberto Crizza

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Aug 27 11:12:27 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21236
	for <iptel-archive@odin.ietf.org>; Mon, 27 Aug 2001 11:12:27 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E043444343; Mon, 27 Aug 2001 10:15:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 3DB3344337
	for <iptel@lists.bell-labs.com>; Mon, 27 Aug 2001 05:51:51 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10061;
	Mon, 27 Aug 2001 06:48:46 -0400 (EDT)
Message-Id: <200108271048.GAA10061@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: iptel@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-09.txt
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Aug 2001 06:48:46 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: Telephony Routing over IP (TRIP)
	Author(s)	: J. Rosenberg, H. Salama, M. Squire
	Filename	: draft-ietf-iptel-trip-09.txt
	Pages		: 81
	Date		: 24-Aug-01
	
This document presents the Telephony Routing over IP (TRIP). TRIP is
a policy driven inter-administrative domain protocol for advertising
the reachability of telephony destinations between location servers,
and for advertising attributes of the routes to those destinations.
TRIP's operation is independent of any signaling protocol, hence TRIP
can serve as the telephony routing protocol for any signaling
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-09.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-trip-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trip-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010824105656.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-trip-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-trip-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010824105656.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Aug 28 10:10:19 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10874
	for <iptel-archive@odin.ietf.org>; Tue, 28 Aug 2001 10:10:19 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 91C2C44337; Tue, 28 Aug 2001 09:13:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ahmler2.mail.eds.com (ahmler2.mail.eds.com [192.85.154.72])
	by lists.bell-labs.com (Postfix) with ESMTP id 0003444336
	for <iptel@lists.bell-labs.com>; Tue, 28 Aug 2001 09:12:35 -0400 (EDT)
Received: from ahmlir1.mail.eds.com (ahmlir1-2.mail.eds.com [192.85.154.25])
	by ahmler2.mail.eds.com (8.11.4/8.11.1) with ESMTP id f7SEB0021051;
	Tue, 28 Aug 2001 10:11:00 -0400
Received: from ahmlir1.mail.eds.com (localhost [127.0.0.1])
	by ahmlir1.mail.eds.com (8.11.4/8.11.3) with ESMTP id f7SEArg13343;
	Tue, 28 Aug 2001 10:10:53 -0400 (EDT)
Received: from usahm001.examhub.exch.eds.com (usahm001.examhub.exch.eds.com [207.37.138.140])
	by ahmlir1.mail.eds.com (8.11.4/8.11.3) with ESMTP id f7SEAqm13297;
	Tue, 28 Aug 2001 10:10:52 -0400 (EDT)
Received: by usahm001.examhub.exch.eds.com with Internet Mail Service (5.5.2653.19)
	id <R24G5VJT>; Tue, 28 Aug 2001 10:10:45 -0400
Message-ID: <2BE915A69EF4D2119A0800805FF5E0500C062C0D@BRSPM201>
From: "Crizza, Roberto" <roberto.crizza@eds.com>
To: mattsquire@acm.org
Cc: "Iptel (E-mail)" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP Question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Aug 2001 10:08:05 -0400

Matt

I've talked about this because I've been working with a global VoIP over
MPLS project and the first requirement is that voice delay should be less
than 150 ms, I thought that if we'll control the response time we can have
VoIP with a good quality.

Regards

Roberto Crizza 

-----Original Message-----
From: Matt Squire [mailto:mattsquire@acm.org]
Sent: quinta-feira, 23 de agosto de 2001 21:41
To: Crizza, Roberto
Cc: Iptel (E-mail)
Subject: Re: [IPTEL] TRIP Question



The 150 ms number is the round trip time for the data/voice channel,
correct?

The keepalive in TRIP is between LSs and has nothing to do with the data
channel.  Maybe I'm just confused about what you're asking.

- Matt

> Folks
> 
> For a good voice quality the response time between source and destination
> should be less than 150 ms, Is possible use the keep alive with one clock
> and create one threshold for measuring the response time between LS
internal
> or external ?
> 
> Regards
> 
> Roberto Crizza

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug 29 17:50:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11339
	for <iptel-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:50:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A00DB44338; Wed, 29 Aug 2001 16:53:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from relay02.valueweb.net (relay02.valueweb.net [216.219.253.236])
	by lists.bell-labs.com (Postfix) with ESMTP id D9AF244336
	for <iptel@lists.bell-labs.com>; Wed, 29 Aug 2001 16:22:01 -0400 (EDT)
Received: from thor.valueweb.net ([216.219.254.23]:13327 "EHLO thor.valueweb.net") by relay02.valueweb.net with ESMTP id <S146504AbRH2VUe>; Wed, 29 Aug 2001 17:20:34 -0400
Received: from [62.3.18.126] ([62.3.18.126]:53004 "HELO kibotop") by thor.valueweb.net with SMTP id <S263225AbRH2VUa>; Wed, 29 Aug 2001 17:20:30 -0400
From: "Kiarash Bodouhi" <kibo@solarson.ca>
To: <iptel@lists.bell-labs.com>
Message-ID: <JJEOJFDNKAJPMKFNJCCGGENDCKAA.kibo@solarson.ca>
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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Subject: [IPTEL] TRIP-GW
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Aug 2001 01:53:52 +0430
Content-Transfer-Encoding: 7bit


Hi all,

Any comments on changing the transport protocol from TCP to UDP for
TRIP-GW? It has got major advantages for this specific use.

Regards
Kiarash

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Aug 29 18:48:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12898
	for <iptel-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:48:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2B7B4434A; Wed, 29 Aug 2001 17:51:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 6BBE844336
	for <iptel@lists.bell-labs.com>; Wed, 29 Aug 2001 17:50:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7TMm0ob002060;
	Wed, 29 Aug 2001 18:48:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <RY36MC62>; Wed, 29 Aug 2001 18:48:50 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF020D66E3@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Kiarash Bodouhi'" <kibo@solarson.ca>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] TRIP-GW
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Aug 2001 18:48:50 -0400



 

> -----Original Message-----
> From: Kiarash Bodouhi [mailto:kibo@solarson.ca]
> Sent: Wednesday, August 29, 2001 5:24 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] TRIP-GW
> 
> 
> 
> Hi all,
> 
> Any comments on changing the transport protocol from TCP to UDP for
> TRIP-GW? It has got major advantages for this specific use.

That change makes no sense. It has none of the benefits you assign to it.
The timescales of data changes within TRIP are much larger than any
timescales related to UDP vs. TCP, so your arguments are all moot. Let us
move on to real issues.

We now have an additional proposal for the gateway registration problem:
http://www.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-00.txt

Please take a look, and let us quickly come to an agreement on direction.

-Jonathan R.



---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Aug 30 12:14:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20634
	for <iptel-archive@odin.ietf.org>; Thu, 30 Aug 2001 12:14:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8B07844344; Thu, 30 Aug 2001 11:17:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 4B6AF44336
	for <iptel@lists.bell-labs.com>; Thu, 30 Aug 2001 11:16:29 -0400 (EDT)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GIW00GMH2HHC0@firewall.mcit.com> for
 iptel@lists.bell-labs.com; Thu, 30 Aug 2001 16:15:17 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GIW001012GVYF@dgismtp03.wcomnet.com>;
 Thu, 30 Aug 2001 16:15:17 +0000 (GMT)
Received: from hsinnreich ([166.35.226.44])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GIW00MIM2GC9I@dgismtp03.wcomnet.com>; Thu,
 30 Aug 2001 16:14:51 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [IPTEL] TRIP Question
In-reply-to: <2BE915A69EF4D2119A0800805FF5E0500C062C0D@BRSPM201>
To: "'Crizza, Roberto'" <roberto.crizza@eds.com>, mattsquire@acm.org
Cc: "'Iptel (E-mail)'" <iptel@lists.bell-labs.com>
Message-id: <000e01c1316e$e5ab0ac0$2ce223a6@open.wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Aug 2001 11:14:36 -0500
Content-Transfer-Encoding: 7bit

ITI-T G.109 states clearly that QoS for PSTN-like 3.1 kHz quality is a
trade-off between delay, packet loss, codec type and possible
transcoding. The scale in G. 114 and G.131 includes 150ms as
"acceptable" and 150ms-400ms as "conditionally acceptable". With echo
control.

At any rate, there is no reason to put MPLS over the Internet for VoIP
QoS:

No connection orientation, no state, no central controllers are needed!
:-)

See
http://nwfusion.com/columnists/2001/0820bradner.html
http://www.nanog.org/mtg-0105/casner.html

Henry

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Crizza, Roberto
> Sent: Tuesday, August 28, 2001 9:08 AM
> To: mattsquire@acm.org
> Cc: Iptel (E-mail)
> Subject: RE: [IPTEL] TRIP Question
> 
> 
> Matt
> 
> I've talked about this because I've been working with a
> global VoIP over MPLS project and the first requirement is 
> that voice delay should be less than 150 ms, I thought that 
> if we'll control the response time we can have VoIP with a 
> good quality.
> 
> Regards
> 
> Roberto Crizza
> 
> -----Original Message-----
> From: Matt Squire [mailto:mattsquire@acm.org]
> Sent: quinta-feira, 23 de agosto de 2001 21:41
> To: Crizza, Roberto
> Cc: Iptel (E-mail)
> Subject: Re: [IPTEL] TRIP Question
> 
> 
> 
> The 150 ms number is the round trip time for the data/voice
> channel, correct?
> 
> The keepalive in TRIP is between LSs and has nothing to do
> with the data channel.  Maybe I'm just confused about what 
> you're asking.
> 
> - Matt
> 
> > Folks
> > 
> > For a good voice quality the response time between source and
> > destination should be less than 150 ms, Is possible use the 
> keep alive
> > with one clock and create one threshold for measuring the response
> > time between LS
> internal
> > or external ?
> > 
> > Regards
> > 
> > Roberto Crizza
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-> labs.com/mailman/listinfo/iptel
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 31 13:15:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10953
	for <iptel-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:15:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7623B4433A; Fri, 31 Aug 2001 12:18:05 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id A624844336
	for <iptel@lists.bell-labs.com>; Fri, 31 Aug 2001 10:43:54 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7VFgRe12873;
	Fri, 31 Aug 2001 11:42:27 -0400 (EDT)
Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id ABU04381 (AUTH klingle);
	Fri, 31 Aug 2001 11:42:47 -0400 (EDT)
Message-ID: <3B8FB047.28A8B32F@cisco.com>
From: Kevin Lingle <klingle@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Subject: RE: [Fwd: [Fwd: [IPTEL] FW: I-DACTION:draft-ietf-iptel-trip-mib-0 
 0.txt]]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 31 Aug 2001 11:41:59 -0400
Content-Transfer-Encoding: 7bit

hi,

i have some comments on the trip mib.  i'm not a trip expert, so
consider most comments from a general snmp/mib perspective.

my comments are embedded below. 

this is only a partial review.  i made it up to tripRouteTable.
i'll send more comments early next week.

> TRIP-MIB DEFINITIONS ::= BEGIN
> 
> IMPORTS
>     MODULE-IDENTITY,
>     OBJECT-TYPE,
>     NOTIFICATION-TYPE,
>     Unsigned32,
>     Integer32,
>     Gauge32,
>     Counter32,
>     mib-2
>         FROM SNMPv2-SMI
> 
>     TEXTUAL-CONVENTION,
>     DateAndTime,
>     TruthValue,
>     RowStatus
>         FROM SNMPv2-TC
> 
>     OBJECT-GROUP,
>     MODULE-COMPLIANCE,
>     NOTIFICATION-GROUP
>         FROM SNMPv2-CONF
> 
>     InetAddressType,
>     InetAddress
>         FROM INET-ADDRESS-MIB
> 
>     applIndex
>         FROM NETWORK-SERVICES-MIB;
> 
> tripMIB MODULE-IDENTITY
>    LAST-UPDATED "200108200000Z"
>    ORGANIZATION "IETF IPTel Working Group"
>    CONTACT-INFO
>    "Co-editor  Jianping Jiang
>                SS8 Networks, Inc.
>     postal:    55 Commerce Valley Drive West, Suite #510
>                Thornhill, ON, L3T 7B9 Canada
>     email:     jianping@ss8.com
>     phone:     +1 905 889 5900
> 
>     Co-editor  Dave Walker
>                SS8 Networks, Inc.
>     postal:    495 March Road, Suite #500
>                Ottawa, ON, K2K 3G1 Canada
>     email:     drwalker@ss8.com
>     phone:     +1 613 592 2100
> 
>     Co-editor  David Zinman
>                SS8 Networks, Inc.
>     postal:    495 March Road, Suite #500
>                Ottawa, ON, K2K 3G1 Canada
>     email:     david@ss8.com
>     phone:     +1 613 592 2100
> 
>     IP Telephony (iptel) Working Group
>     ==================================
>     Chair:
>       Jonathan Rosenberg <jdrosen@dynamicsoft.com>
> 
>     Transport Area Directors:
>       Scott Bradner <sob@harvard.edu>
>       Allison Mankin <mankin@east.isi.edu>
> 
>     Transport Area Advisor:
>       Scott Bradner <sob@harvard.edu>

the above wg information is nice, but i think you should
list it outside the mib module (elsewhere in the draft doc)
since it is subject to change.

the list of co-authors is presumed to be more stable, so 
it's good to keep in the mib.

> 
>     Mailing List
>     ============
>     iptel-admin@lists.bell-labs.com
> 
>     General information about the mailing list is at:
>       http://lists.bell-labs.com/mailman/listinfo/iptel/
> 
>     Archives:
>       http://lists.bell-labs.com/pipermail/iptel/"

same basic comment about this maillist section.  although
you should provide one "Email" contact other than the
authors.  the iptel list might be a good common list for
trip mib discussion or create your own trip-mib list.

for sip mib work, we used yahoogroups.com, but now as we
get into last call, the comments have been that ietf
frowns on such list servers and we are using the general
discussion list for sip.   

try and pick a list that will be available longterm and salient 
to trip or specific to the trip-mib.  that way it won't 
need to be changed repeatedly in the mib... a task that will
be harder once this is an rfc.


> 
> DESCRIPTION
>    "The MIB module describing Telephony Routing
>     over IP (TRIP)"

i think you should add some more description here
of what trip is and does.

> REVISION      "200102260000Z"
> DESCRIPTION
>     "The initial revision of this MIB module was
>     published as draft-zinman-trip-mib-00.txt."

remove this reference to a old draft.  it will be of
no use shortly and certainly no down the road in a 
year or two.

just make this revision "The initial version of this MIB..."

> ::= { mib-2 } -- to be assigned by IANA
> 
> --
> -- Textual Conventions
> --
> TripItad ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>        "The values for identifying the IP Telephony
>        Administrative Domain."

add "(ITAD)" to formally introduce the acryonym.

>     SYNTAX Unsigned32 (0..4294967295)
> 
> TripId ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>        "The range of legal values for a TRIP Identifier."

say some more about what a trip identifier is and is used for.

>     SYNTAX Unsigned32 (0..4294967295)
> 
> TripAppProtocol ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "The application protocol used for communication with
>         TRIP LS's. Protocol defined in this document are:

what's an "LS" - expand acryonmym on first use.

>             tripSupProtSIP
>             tripSupProtH323Q931
>             tripSupProtH323RAS
>             tripSupProtH323ANNEXG.
> 
>         Users can add their own application protocol types by defining
>         a TripAppProtocol type in a private specification."
>     SYNTAX OBJECT IDENTIFIER
> 
> TripAddressFamily ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "A type of address for a TRIP route. Address families defined
>         within this document are:

change "document" to "MIB module".

>             tripAddrFamilyDecimal
>             tripAddrFamilyPentadecimal
>             tripAddrFamilyE164.
> 
>        Users can add their own address family types by defining a
>        TripAddressFamily type in a private specification."
>     SYNTAX OBJECT IDENTIFIER
> 
>     tripMIBNotifications OBJECT IDENTIFIER ::= { tripMIB 0 }
>     tripMIBObjects       OBJECT IDENTIFIER ::= { tripMIB 1 }
>     tripMIBConformance   OBJECT IDENTIFIER ::= { tripMIB 2 }
>     tripMIBCompliance    OBJECT IDENTIFIER ::= { tripMIBConformance 1 }
>     tripMIBGroups        OBJECT IDENTIFIER ::= { tripMIBConformance 2 }
> 
> --
> -- Supported protocols
> --
>     tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIBObjects 100 }

i think it would be cleaner to define these (and the addr family) oids
directly off tripMIB rather than picking some arbitrarily high
oid space under tripMIBObjects.

eg,
tripSupportedProtocols OBJECT IDENTIFIER ::= { tripMIB 3 }
tripAddressFamilies    OBJECT IDENTIFIER ::= { tripMIB 4 }

> 
>     tripSupProtSIP
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 }
>     tripSupProtH323Q931
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 }
>     tripSupProtH323RAS
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 }
>     tripSupProtH323ANNEXG
>         OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 }
> 
> --
> -- Address Families
> --
>     tripAddressFamilies    OBJECT IDENTIFIER ::= { tripMIBObjects 101 }
> 
>     tripAddrFamilyDecimal
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 1 }
>     tripAddrFamilyPentadecimal
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 2 }
>     tripAddrFamilyE164
>         OBJECT IDENTIFIER ::= { tripAddressFamilies 3 }
> 
> --
> -- tripCfgTable
> --
>    tripCfgTable OBJECT-TYPE
>        SYNTAX     SEQUENCE OF TripCfgEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>            "This table contains the common configuration objects
>             applicable to all TRIP entities.  Each row represents
>             those objects for a particular TRIP LS present in
>             this system. The instances of TRIP LS's are
>             uniquely identified by applIndex."

the description here indicates that the info in this table is
wrt the trip ls present on this system.  the use of the work
"peer" in later descriptions makes me think the information
might be wrt a peer trip ls elsewhere in the network.
perhaps all trip entities are referred to as Peers and 
you are still actually talking about the local trip entity.
it's a bit confusing, can that be clarified?

>        ::= { tripMIBObjects 1 }
> 
>    tripCfgEntry OBJECT-TYPE
>        SYNTAX     TripCfgEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>            "A row of common configuration."
>        INDEX { applIndex }
>        ::= { tripCfgTable 1 }
> 
>    TripCfgEntry ::=
>        SEQUENCE {
>            tripProtocolVersion               Integer32,
>            tripLocalItad                     TripItad,
>            tripIdentifier                    TripId,
>            tripOperStatus                    INTEGER,
>            tripAdminStatus                   INTEGER,
>            tripLocalAddrIAddrType            InetAddressType,
>            tripLocalAddr                     InetAddress,
>            tripLocalPort                     Integer32,
>            tripMinItadOriginationInterval    Integer32,
>            tripMinRouteAdvertisementInterval Integer32,
>            tripMaxPurgeTime                  Integer32,
>            tripDisableTime                   Integer32,
>            tripSendReceiveMode               INTEGER
>       }
> 
>    tripProtocolVersion    OBJECT-TYPE
>        SYNTAX     Integer32 (1..255)
>        MAX-ACCESS read-only
>        STATUS     current
>        DESCRIPTION
>            "This object will reflect the version of TRIP
>            supported by this system.  It follows the same
>            format as TRIP version information contained
>            in the TRIP messages generated by this TRIP entity
>            as dictated by draft-ietf-iptel-trip-07.txt."

try to avoid referencing I-D documents.  the information will
be stale long before these mib object definitions are obsolete.
if you must for clarity, i understand, but expect to have to
remove/revise it in later revisions of the mib and put it
in a REFERENCE clause rather than the DESCRIPTION.  the
DESCRIPTION here could just say "... as dictated by the
TRIP standard."

>        ::= { tripCfgEntry 1 }
> 
>    tripLocalItad   OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The Local Internet Telephony Administrative domain."
>        ::= { tripCfgEntry 2 }
> 
>    tripIdentifier   OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The object that identifies this TRIP Client."
>        ::= { tripCfgEntry 3 }
> 
>    tripAdminStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The desired TRIP state.
> 
>             up(1)  : Set the application to normal operation.
> 
>             down(2): Set the application to a state where it will not
>                      process TRIP messages."

gee, i wish we could simplify our sip mib admin status down to
this ;)

>        ::= { tripCfgEntry 4 }
> 
>    tripOperStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-write

oper status should be read-only.

>        STATUS      current
>        DESCRIPTION
>            "The current operational state of the TRIP protocol.
> 
>             up(1)  : The application is operating normally, and
>                      is processing (receiving and possibly
>                      issuing) TRIP requests and responses.
> 
>             down(2): The application is currently unable to
>                      process TRIP messages due to a fault or if
>                      TRIP is in an initialization state.
> 
>            If tripAdminStatus is down(2) then tripOperStatus should be
>            down(2). If tripAdminStatus is changed to up(1) then
>            tripOperStatus should change to up(1) if there is no fault
>            that prevents the TRIP protocol from moving to the up(1)
>            state."

consider adding another oper state that the appl can be in if
there is a fault of some sort.

>        ::= { tripCfgEntry 5 }
> 
>    tripLocalAddrIAddrType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripLocalAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripCfgEntry 6 }
> 
>    tripLocalAddr OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The IP address of this entry's TRIP peer connection."

here is one of the confusing spots...
is this an address of a peer trip entity? if so, then the use of 
"Local" in the obj descriptor seems strange.

>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripCfgEntry 7 }
> 
>    tripLocalPort OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The local port that this entry's TRIP peer is using."

again, i'm a bit confused.  the description talks about a trip peer
using this port, but the "Local" reference in the obj has me confused.

also, is this s tcp/udp port or an "interface" on the box?  port
can be an ambiguous term in the world of networking, so please
be more specific.


>        ::= { tripCfgEntry 8 }
> 
>    tripMinItadOriginationInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

any reason not to use the SNMPv2-TC 
TimeInterval ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER (0..2147483647)
?

is the 0 value of TimeInterval a problem?

>        UNITS       "Seconds"

if TimeInterval was used, UNITS would either come out of the mib
or need to reflect "hundreths of a second".

>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Amount of time that must elapse between advertisement
>            of update message that report changes within the
>            Location Server's own ITAD."
>        DEFVAL { 30 }

DEFVAL would go to 3000 if TimeInterval used.

>        ::= { tripCfgEntry 9 }
> 
>    tripMinRouteAdvertisementInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment wrt TimeInterval TC.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Specifies minimal interval between successive
>            advertisement to a particular destination from an LS."
>        DEFVAL { 30 }
>        ::= { tripCfgEntry 10 }
> 
>    tripMaxPurgeTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment wrt TimeInterval TC.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the location server must
>            maintain routes marked as withdrawn in its database."
>        DEFVAL { 10 }
>        ::= { tripCfgEntry 11 }
> 
>    tripDisableTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment wrt TimeInterval TC.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the TRIP module of the
>             location server must be disabled while routes
>             originated by this location server with high
>             sequence numbers can be removed."
>        DEFVAL { 180 }
>        ::= { tripCfgEntry 12 }
> 
>    tripSendReceiveMode OBJECT-TYPE
>        SYNTAX INTEGER {
>                sendReceive(1),
>                sendOnly(2),
>                receiveOnly(3)
>                }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The operational mode of this peer."

the trip entity running on this system??

>        ::= { tripCfgEntry 13 }
> 
> --
> -- tripSupportedCommunityTable
> --
> 
>    tripSupportedCommunityTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripSupportedCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The list of TRIP communities that this LS supports. A TRIP
>            community is a group of destinations that share some common
>            property.

property -> properties.

> 
>            The TRIP Communities attribute is used to group destinations
>            so that the routing decision can be based on the identity of
>            the group."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 5.9."

again be aware of the pitfalls of referencing drafts.  -09 is the
current
draft i think, so this info is essentially stale already.

>        ::= { tripMIBObjects 2 }
> 
>    tripSupportedCommunityEntry OBJECT-TYPE
>        SYNTAX      TripSupportedCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information a community. A TRIP

say "... information about a community."

>            community is a group of destinations that share some
>            common property."

typically, what's that "common property" the destination share?

>        INDEX { applIndex, tripSupportedCommunityId }
>        ::= { tripSupportedCommunityTable 1 }
> 
>    TripSupportedCommunityEntry ::= SEQUENCE {
>        tripSupportedCommunityId         TripItad,
>        tripSupportedCommunityItad       TripItad,
>        tripSupportedCommunityRowStatus  RowStatus
>    }
> 
>    tripSupportedCommunityId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The identifier of the supported Community."
>        ::= { tripSupportedCommunityEntry 1 }
> 
>    tripSupportedCommunityItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The Itad of the community."

i'm not clear on what the differences is between the
tripSupportedCommunityId (index object) and this
tripSupportedCommunityItad??

>        ::= { tripSupportedCommunityEntry 2 }
> 
>    tripSupportedCommunityRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The row status of the entry. This object is required to
>            create or delete rows."

what is the criteria for row creation?  is the
tripSupportedCommunityItad
a required object to create a row - seems a default Itad wouldn't be
likely.  do you createAndGo or do you need to create the row and then
transition it to active w/ an additional set operation?  things like
that help implementors out tremeduously.

>        ::= { tripSupportedCommunityEntry 3 }
> 
> --
> -- TripPeerTable
> --
>    tripPeerTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripPeerEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP peer table. This table contains one entry per
>            TRIP peer, and information about the connection with
>            the peer."

so now this table seems to be info related to trip entities no
in this system, which reinforces my issues of ambiguity in the
earlier tripCfgTable (references to local and peer).

>        ::= { tripMIBObjects 4 }
> 
>    tripPeerEntry OBJECT-TYPE
>        SYNTAX      TripPeerEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information about the connection with
>            a TRIP peer."
>        INDEX { applIndex,
>                tripPeerRemoteAddrInetType,
>                tripPeerRemoteAddr }

why use the peers address objects for indexing instead of
just tripPeerIdentifier?  isn't tripPeerIdentifier unique?

>          ::= {tripPeerTable 1}
> 
>    TripPeerEntry ::= SEQUENCE {
>        tripPeerRemoteAddrInetType            InetAddressType,
>        tripPeerRemoteAddr                    InetAddress,
>        tripPeerIdentifier                    TripId,
>        tripPeerState                         INTEGER,
>        tripPeerAdminStatus                   INTEGER,
>        tripPeerNegotiatedVersion             Integer32,
>        tripPeerSendReceiveMode               INTEGER,
>        tripPeerRemotePort                    Integer32,
>        tripPeerRemoteItad                    TripItad,
>        tripPeerConnectRetryInterval          Integer32,
>        tripPeerMaxRetryInterval              Integer32,
>        tripPeerHoldTime                      Integer32,
>        tripPeerKeepAlive                     Integer32,
>        tripPeerHoldTimeConfigured            Integer32,
>        tripPeerKeepAliveConfigured           Integer32,
>        tripPeerMinItadOriginationInterval    Integer32,
>        tripPeerMinRouteAdvertisementInterval Integer32,
>        tripPeerMaxPurgeTime                  Integer32,
>        tripPeerDisableTime                   Integer32,
>        tripPeerRowStatus                     RowStatus
>    }
> 
>    tripPeerRemoteAddrInetType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripPeerRemoteAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripPeerEntry 1 }
> 
>    tripPeerRemoteAddr OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE(0..125))
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The remote IP address of this entry's TRIP peer. The
>            size value of 125 has been assigned due to the sub
>            identifier of object types length limitation as
>            defined in SMIv2."

i don't understand this last sentence.   is it something about
InetAddress??  was the same not relevant for tripLocalAddr??

>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripPeerEntry 2 }
> 
>    tripPeerIdentifier OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "TRIP identifier of this entry's TRIP peer."

what does it mean to be "this entry's TRIP peer"??
the peer is not a peer of this mib table entry but
rather a peer of the local TRIP LS, right?

>        ::= { tripPeerEntry 3 }
> 
>    tripPeerState OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        idle(1),
>                        connect(2),
>                        active(3),
>                        openSent(4),
>                        openConfirm(5),
>                        established(6)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "TRIP Peer Finite State Machine state.
> 
>            idle(1)       : The initial state. Local LS refuses all
>                            incoming connections. No resources are
>                            allocated to the peer.
> 
>            connect(2)    : Local LS waiting for a transport protocol
>                            connection to be completed to the peer, and
>                            is listening for inbound transport
>                            connections from the peer.
> 
>            active(3)     : LS is listening for an inbound connection
>                            from the peer, but is not in the process of
>                            initiating a connection to the peer.
> 
>            openSent(4)   : LS has sent an OPEN message to its peer and
>                            is waiting for an OPEN message from its
>                            peer.
> 
>            openConfirm(5): LS has sent an OPEN to its peer, received an
>                            OPEN from its peer, and sent a KEEPALIVE in
>                            response to the OPEN. The LS is now waiting
>                            for a KEEPALIVE or NOTIFICATION message in
>                            response to its OPEN.
> 
>            established(6): LS can exchange UPDATE, NOTIFICATION,and
>                            KEEPALIVE messages with its peer."
>        ::= { tripPeerEntry 4 }
> 
>    tripPeerAdminStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        up(1),
>                        down(2)
>                    }
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The desired TRIP connection state."

how might setting this to "up" affect  tripPeerState?
would tripPeerState connect->openSent->openConfirm->established?
if there is any relationship, you may want to describe it.
i may be offbase in presuming there is some relationship.

>        ::= { tripPeerEntry 5 }
> 
>    tripPeerNegotiatedVersion OBJECT-TYPE
>        SYNTAX      Integer32 (1..255)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The negotiated version of TRIP running between this
>            local entity and this peer."
>        ::= { tripPeerEntry 6 }

this is the second object reflecting trip protocol version.
consider creating a TC TripProtocolVersion.

> 
>    tripPeerSendReceiveMode OBJECT-TYPE
>        SYNTAX      INTEGER {
>                sendReceive(1),
>                sendOnly(2),
>                receiveOnly(3)
>                }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The operational mode of this peer."

this is the same syntax as tripSendRecieveMode.
again, a good candidate for making this syntax a TC
TripSendRecvMode.

>        ::= { tripPeerEntry 7 }
> 
>    tripPeerRemotePort OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The remote port for the TCP connection between the
>            TRIP peers."

here you are explicit about this being a tcp port.
does that answer my question regarding tripLocalPort?

>        ::= { tripPeerEntry 8 }
> 
>    tripPeerRemoteItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "The Internet Telephony Administrative domain of
>            this peer."
>        ::= { tripPeerEntry 9 }
> 
>    tripPeerConnectRetryInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval.

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the initial amount of time that will elapse
>            between connection retry. This value should double
>            after each attempt up to the value of
>            tripPeerMaxRetryInterval."

therefore, the value of this object has a dependency on the
value of tripPeerMaxRetryInterval.  this objects value must
always be <= tripPeerMaxRetryInterval.  attempts to set it
higher than the max retry should not be allowed, right?


>        DEFVAL      { 120 }
>        ::= { tripPeerEntry 10 }
> 
>    tripPeerMaxRetryInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the maximum amount of time that will elapse
>            between connection retries."

somehow refer back to the relationship between this object and 
tripPeerConnectRetryInterval.  what if there's an attempt to 
set this object to be less than tripPeerConnectRetryInterval?
it should fail, right?

>        DEFVAL      { 360 }
>        ::= { tripPeerEntry 11 }
> 
>    tripPeerHoldTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time interval in seconds for the hold timer that
>            is established with the peer. The value of this object
>            is the smaller of the values in
>            tripPeerHoldTimeConfigured and the hold time received
>            in the open message."
>        ::= { tripPeerEntry 12 }
> 
>    tripPeerKeepAlive OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Specifies the amount of time that must elapse between
>            keep alive messages."
>        ::= { tripPeerEntry 13 }
> 
>    tripPeerHoldTimeConfigured OBJECT-TYPE
>        SYNTAX      Integer32 (0 | 3..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the maximum time that may elapse between the
>            receipt of successive keepalive or update message."
>        DEFVAL { 240 }
>        ::= { tripPeerEntry 14 }
> 
>    tripPeerKeepAliveConfigured OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies the amount of time that must elapse between
>            keep alive messages."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 15 }
> 
>    tripPeerMinItadOriginationInterval OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Amount of time that must elapse between advertisement
>            of update message that report changes within the Location

message -> messages

>            Server's own ITAD."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 16 }
> 
>    tripPeerMinRouteAdvertisementInterval OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Specifies minimal interval between successive
>            advertisement to a particular destination from an LS."
>        DEFVAL { 30 }
>        ::= { tripPeerEntry 17 }
> 
>    tripPeerMaxPurgeTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the location server must

either say "location server" or "LS" throughout the mib, but don't
keep switching back and forth.  i've noticed this happening.

>            maintain routes marked as withdrawn in its database."
>        DEFVAL { 10 }
>        ::= { tripPeerEntry 18 }
> 
>    tripPeerDisableTime OBJECT-TYPE
>        SYNTAX      Integer32 (1..65535)

same comment as before on possibly using SNMPv2-TC TimeInterval

>        UNITS       "Seconds"
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "Indicate the interval that the TRIP module of the

the peer LS presumably?

>            location server must be disabled while routes
>            originated by this location server with high sequence

is "this" referring to the local ls or the peer ls.

>            numbers can be removed."
>        DEFVAL { 180 }
>        ::= { tripPeerEntry 19 }
> 
>    tripPeerRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-create
>        STATUS      current
>        DESCRIPTION
>            "This object is used to create and delete rows in the
>            tripPeerTable."

again, row creation criteria should be added to aid implementors
and nm appl developers.

>        ::= { tripPeerEntry 20 }
> 
> --
> --     tripPeerRouteTypeTable
> --
>     tripPeerRouteTypeTable OBJECT-TYPE
>       SYNTAX      SEQUENCE OF TripPeerRouteTypeEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The TRIP peer Route Type table. This table contains one
>           entry per supported protocol - address family pair."
>       ::= { tripMIBObjects 5 }
> 
>     tripPeerRouteTypeEntry OBJECT-TYPE
>       SYNTAX      TripPeerRouteTypeEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "Entry containing information about the route type that
>           the TRIP peer supports."
>       INDEX { applIndex,
>               tripPeerRemoteAddrInetType,
>               tripPeerRemoteAddr,

if tripPeerIdentifier is viable, use it instead of address objects.

>               tripPeerRtTypeProtocolId,
>               tripPeerRtTypeAddrFamilyId }

why do these need to be part of the index??
they are oids themselves.  your index into this
table, just to retrieve the value of the RowStatus
object could be very large and cumbersome.

why aren't the protoclid and addrfamily oids the
data retrieved from this table as object values 
rather than index components?

>         ::= { tripPeerRouteTypeTable 1 }
> 
>     TripPeerRouteTypeEntry ::= SEQUENCE {
>         tripPeerRtTypeProtocolId         TripAppProtocol,
>         tripPeerRtTypeAddrFamilyId       TripAddressFamily,
>         tripPeerRtTypeRowStatus          RowStatus
>     }
> 
>     tripPeerRtTypeProtocolId OBJECT-TYPE
>       SYNTAX      TripAppProtocol
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The object identifier of a protocol that this peer is
>           using."
>       ::= { tripPeerRouteTypeEntry 1 }
> 
>     tripPeerRtTypeAddrFamilyId OBJECT-TYPE
>       SYNTAX      TripAddressFamily
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "The object identifier of an address family that this peer
>           belongs to."
>       ::= { tripPeerRouteTypeEntry 2 }
> 
>    tripPeerRtTypeRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object is used to instantiate a row in this table.
>            The normal row status values of createAndGo(4),
>            createAndWait(5) and delete(6) have no application in this
>            table."

good, some beginnings of the row creation criteria that i have been
mentioning.  now why not applicable here?   if i can't
do createAndGo or createAndWait then how do i create a row in this
table?  are these rows instantiated via trip and not by a nms??
i'm confused.

>        ::= { tripPeerRouteTypeEntry 3 }
> 
> --
> -- TripPeerStatsTable
> --
>    tripPeerStatsTable   OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripPeerStatsEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP peer stats table. This table contains one entry
>            per TRIP peer, and statistics related to the connection
>            with the peer."
>        ::= { tripMIBObjects 6 }
> 
>    tripPeerStatsEntry OBJECT-TYPE
>        SYNTAX      TripPeerStatsEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Entry containing information about the connection with
>            a TRIP peer."
>        AUGMENTS { tripPeerEntry }
>          ::= { tripPeerStatsTable 1 }
> 
>    TripPeerStatsEntry ::= SEQUENCE {
>        tripPeerInUpdates                   Counter32,
>        tripPeerOutUpdates                  Counter32,
>        tripPeerInTotalMessages             Counter32,
>        tripPeerOutTotalMessages            Counter32,
>        tripPeerFsmEstablishedTransitions   Counter32,
>        tripPeerFsmEstablishedTime          DateAndTime,
>        tripPeerInUpdateElapsedTime         Gauge32
>    }
> 
>     tripPeerInUpdates OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of TRIP update messages received from this
>            peer since the last restart of this location server."
>        ::= { tripPeerStatsEntry 1 }
> 
>    tripPeerOutUpdates OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of TRIP update messages transmitted to

transmitted -> sent.... consistent w/ other parts of the mib
using send/receive terminology.  i know.... a real nit! ;)

>            this peer since the last restart of this location
>            server."
>        ::= { tripPeerStatsEntry 2 }
> 
>    tripPeerInTotalMessages OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The total number of TRIP messages received to the

to -> from

>            remote peer on this connection since the last restart
>            of this location server."
>        ::= { tripPeerStatsEntry 3 }
> 
>    tripPeerOutTotalMessages OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The total number of outgoing TRIP messages sent since

for consistency sake... say "...sent to the remote peer since...."

>            the last restart of this location server."
>        ::= { tripPeerStatsEntry 4 }
> 
>    tripPeerFsmEstablishedTransitions OBJECT-TYPE
>        SYNTAX      Counter32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of times the TRIP peer has transitioned into
>            the established state since the last restart of this
>            location server."
>        ::= { tripPeerStatsEntry 5 }
> 
>    tripPeerFsmEstablishedTime OBJECT-TYPE
>        SYNTAX      DateAndTime
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates how long in seconds this peer has been in the
>            established state."

description doesn't match up w/ the syntax.  DateAndTime is more
than just seconds.

>        ::= { tripPeerStatsEntry 6 }
> 
>    tripPeerInUpdateElapsedTime OBJECT-TYPE
>        SYNTAX      Gauge32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Elapsed time in seconds since the last TRIP update
>            message was received from the peer."

not sure why Gauge32 is used here.  again, why not TimeInterval.
description would have to not refer to seconds.

i have to stop here.  i will send more comments on the remainder
of the mib early next week.

kevin
>        ::= { tripPeerStatsEntry 7 }
> 
> -- TRIP Received Route Table.  This table contains
> -- all routes from all sources. Each entry consists
> -- of a route and its associated path attributes.
> 
>    tripRouteTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripRouteEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The TRIP route table containing information about
>            reachable routes that are to be added to service by the
>            receiving LS."
>        ::= { tripMIBObjects 7 }
> 
>    tripRouteEntry OBJECT-TYPE
>        SYNTAX      TripRouteEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a route to a called destination."
>        INDEX { applIndex,
>                tripRouteAppProtocol,
>                tripRouteAddressFamily,
>                tripRouteAddress,
>                tripRoutePeer
>                }
>        ::= { tripRouteTable 1 }
> 
>    TripRouteEntry ::= SEQUENCE {
>                tripRouteAppProtocol                 TripAppProtocol,
>                tripRouteAddressFamily               TripAddressFamily,
>                tripRouteAddress                     OCTET STRING,
>                tripRoutePeer                        TripId,
>                tripRouteAddressSequenceNumber       Integer32,
>                tripRouteAddressOriginatorId         TripItad,
>                tripRouteNextHopServerIAddrType      InetAddressType,
>                tripRouteNextHopServer               InetAddress,
>                tripRouteNextHopServerPort           Integer32,
>                tripRouteNextHopServerItad           TripItad,
>                tripRouteMultiExitDisc               Unsigned32,
>                tripRouteLocalPref                   Unsigned32,
>                tripRouteAdvertisementPath           OCTET STRING,
>                tripRouteRoutedPath                  OCTET STRING,
>                tripRouteAtomicAggregate             TruthValue,
>                tripRouteBest                        TruthValue,
>                tripRouteUnknown                     OCTET STRING,
>                tripRouteWithdrawn                   TruthValue,
>                tripRouteConverted                   TruthValue
>            }
> 
>    tripRouteAppProtocol OBJECT-TYPE
>        SYNTAX      TripAppProtocol
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The protocol for which this routing table is
>            maintained."
>        ::= { tripRouteEntry 1 }
> 
>    tripRouteAddressFamily OBJECT-TYPE
>        SYNTAX      TripAddressFamily
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Specifies the type of address for the destination
>            route."
>        ::= { tripRouteEntry 2 }
> 
>    tripRouteAddress OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(1..32))
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This is an address (prefix) of the family type given by
>            Address Family of the destination."
>        ::= { tripRouteEntry 3 }
> 
>    tripRoutePeer OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The identifier of the peer where the route information
>            was learned."
>        ::= { tripRouteEntry 4 }
> 
>    tripRouteAddressSequenceNumber OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the version of the destination route
>            originated by the location server identified by
>            tripRouteAddressOriginatorId intra-domain
>            attribute."
>        ::= { tripRouteEntry 5 }
> 
>    tripRouteAddressOriginatorId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This is an intra-domain attribute indicating the
>            internal location server that originated the route
>            into the ITAD."
>        ::= { tripRouteEntry 6 }
> 
>    tripRouteNextHopServerIAddrType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripRouteNextHopServer."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripRouteEntry 7 }
> 
>    tripRouteNextHopServer OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the next hop that messages of a given
>            protocol destined for tripRouteAddress should
>            be sent to."
>        ::= { tripRouteEntry 8 }
> 
>    tripRouteNextHopServerPort OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The port of the next hop server that this route
>            will use."
>        ::= { tripRouteEntry 9 }
> 
>    tripRouteNextHopServerItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the domain of the next hop."
>        ::= { tripRouteEntry 10 }
> 
>    tripRouteMultiExitDisc OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..4294967295)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "When two ITADs are connected by more than one set of peers,
>            it is used to descriminate between multiple exit points to
>            an adjacent ITAD."
>        ::= { tripRouteEntry 11 }
> 
>    tripRouteLocalPref OBJECT-TYPE
>        SYNTAX      Unsigned32 (0..4294967295)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicated the local LS's degree of preference for an
>            advertised route destination."
>        ::= { tripRouteEntry 12 }
> 
>    tripRouteAdvertisementPath OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(4..252))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Identifies the ITADs through wich routing information
>            carried in an advertisement has passed.
> 
>            This object is probably best represented as sequence of
>            integer. For SMI compatibility, though, it is represented
>            as OCTET STRING. This object is a sequence of ITADs in
>            network byte order."
>        ::= { tripRouteEntry 13 }
> 
>    tripRouteRoutedPath OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(4..252))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Identifies the ITADs through which messages sent using
>            this route would pass. These are as subset of
>            tripRouteAdvertisementPath.
> 
>            This object is probably best represented as sequence of
>            integer. For SMI compatibility, though, it is represented
>            as OCTET STRING.  This object is a sequence of ITADs in
>            network byte order."
>        ::= { tripRouteEntry 14 }
> 
>    tripRouteAtomicAggregate OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates that a route may traverse domains not listed in
>            tripRouteRoutedPath. If an LS selects the less specific
>            route from a set of overlapping routes, then this value
>            returns TRUE."
>        ::= { tripRouteEntry 15 }
> 
>    tripRouteBest OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "An indication of whether this route was chosen as the
>            best TRIP route."
>        ::= { tripRouteEntry 16 }
> 
>    tripRouteUnknown OBJECT-TYPE
>        SYNTAX      OCTET STRING (SIZE(0..255))
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "One or more attributes not understood by this location
>            server."
>        ::= { tripRouteEntry 17 }
> 
>    tripRouteWithdrawn OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates if this route is to be removed from service by
>            the receiving LS."
>        ::= { tripRouteEntry 18 }
> 
>    tripRouteConverted OBJECT-TYPE
>        SYNTAX TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates if this route has been converted to a
>            different application protocol than it had originally."
>        ::= { tripRouteEntry 19 }
> 
> --
> -- TRIP Received Route CommunityTable.
> --
> 
>    tripRouteCommunityTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripRouteCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "A table containing a list of TRIP communities associated
>            with a route."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 5.9."
>        ::= { tripMIBObjects 8 }
> 
>    tripRouteCommunityEntry OBJECT-TYPE
>        SYNTAX      TripRouteCommunityEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about communities associated with a route. An
>            entry with a tripRouteAddress of 00 and a tripRoutePeer of
>            0 refers to the local LS."
>        INDEX { applIndex,
>                tripRouteAppProtocol,
>                tripRouteAddressFamily,
>                tripRouteAddress,
>                tripRoutePeer,
>                tripRouteCommunityId
>              }
>        ::= { tripRouteCommunityTable 1 }
> 
>    TripRouteCommunityEntry ::= SEQUENCE {
>         tripRouteCommunityId    TripItad,
>         tripRouteCommunityItad  TripItad
>         }
> 
>    tripRouteCommunityId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The community identifier."
>        ::= { tripRouteCommunityEntry 1 }
> 
>    tripRouteCommunityItad OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The ITAD associated with this community."
>        ::= { tripRouteCommunityEntry 2 }
> 
> --
> -- tripItadTopologyTable
> --
> 
>    tripItadTopologyTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripItadTopologyEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The sequence of link connections between peers within
>            an ITAD."
>        ::= { tripMIBObjects 9 }
> 
>    tripItadTopologyEntry OBJECT-TYPE
>        SYNTAX      TripItadTopologyEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a peer of the location server identified
>            by tripOriginatorIdentifier."
>        INDEX { applIndex, tripItadTopologyOrigId }
>        ::= { tripItadTopologyTable 1 }
> 
>    TripItadTopologyEntry ::= SEQUENCE {
>                tripItadTopologyOrigId    TripItad,
>                tripItadTopologySeqNum    Integer32
>            }
> 
>    tripItadTopologyOrigId OBJECT-TYPE
>        SYNTAX      TripItad
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Indicates the internal location server that originated
>            the ITAD topology information into the ITAD."
>        ::= { tripItadTopologyEntry 1 }
> 
>    tripItadTopologySeqNum OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "Indicates the version of the ITAD topology
>            originated by the location server identified by
>            tripOriginatorIdentifier."
>        ::= { tripItadTopologyEntry 2 }
> 
> --
> -- tripItadTopologyIdTable
> --
> 
>    tripItadTopologyIdTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF TripItadTopologyIdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The list of other location servers within the ITAD
>            domain that the location server identified by
>            tripOriginatorIdentifier is currently peering."
>        ::= { tripMIBObjects 10 }
> 
>    tripItadTopologyIdEntry OBJECT-TYPE
>        SYNTAX      TripItadTopologyIdEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Information about a peer to the location server
>            identified by tripOriginatorIdentifier."
>        INDEX { applIndex,
>                tripItadTopologyOrigId,
>                tripItadTopologyId }
>        ::= { tripItadTopologyIdTable 1 }
> 
>    TripItadTopologyIdEntry ::= SEQUENCE {
>                tripItadTopologyId            TripId,
>                tripItadTopologyIdRowStatus   RowStatus
>            }
> 
>    tripItadTopologyId OBJECT-TYPE
>        SYNTAX      TripId
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index into this entry. Indicates the other location
>            servers within the ITAD domain that this location server
>            identified by tripOriginatorIdentifier is currently
>            peering."
>        ::= { tripItadTopologyIdEntry 1 }
> 
>    tripItadTopologyIdRowStatus OBJECT-TYPE
>        SYNTAX      RowStatus
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object is used to instantiate a row in this table.
>            The normal row status values of createAndGo(4),
>            createAndWait(5) and delete(6) have no application in this
>            table."
>        ::= { tripItadTopologyIdEntry 2 }
> 
> --
> -- Notification objects
> --
> 
>    tripNotifApplIndex    OBJECT-TYPE
>        SYNTAX     INTEGER (1..2147483647)
>        MAX-ACCESS accessible-for-notify
>        STATUS     current
>        DESCRIPTION
>             "This object contains the applIndex as described
>             in RFC 2788. It is used to bind this notification
>             with a specific instance of TRIP entity."
>        ::= { tripMIBNotifications 1 }
> 
>    tripNotifPeerAddrInetType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The type of Inet Address of the tripNotifPeerAddr."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripMIBNotifications 2 }
> 
>    tripNotifPeerAddr OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE(0..125))
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The remote IP address of this entry's TRIP peer. The
>            size value of 125 has been assigned due to the sub
>            identifier of object types length limitation as
>            defined in SMIv2."
>        REFERENCE
>            "RFC 2851, section 3."
>        ::= { tripMIBNotifications 3 }
> 
>    tripNotifPeerErrCode OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        messageHeader(1),
>                        openMessage(2),
>                        updateMessage(3),
>                        holdTimerExpired(4),
>                        finiteStateMachine(5),
>                        cease(6),
>                        tripNotification(7)
>                    }
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "Notification message of TRIP error. The meaning of this
>            value is applicable to the following functions:
> 
>            1 - message header.
>                All errors detected while processing the TRIP message
>                header.
>            2 - open message.
>                All errors detected while processing the OPEN message.
>            3 - update message.
>                All errors detected while processing the UPDATE message.
>            4 - hold timer expired.
>                A notification generated when the hold timer expires.
>            5 - finite state machine.
>                All errors detected by the TRIP Finite State Machine.
>            6 - cease.
>                Any fatal error condition that the rest of the values
>                do not cover.
>            7 - trip notification message.
>                Any error encountered while sending a notification
>                message."
>       ::= { tripMIBNotifications 4 }
> 
>    tripNotifPeerErrSubcode OBJECT-TYPE
>        SYNTAX      Integer32 (1..7)
>        MAX-ACCESS  accessible-for-notify
>        STATUS      current
>        DESCRIPTION
>            "The sub error code associated with error code. The meaning
>            of this value is dependent on the value of
>            tripNotifPeerErrCode.
> 
>            Message Header (1) Error Subcodes:
>            1 - Bad Message Length.
>            2 - Bad Message Type.
> 
>            OPEN Message (2) Error Subcodes:
>            1 - Unsupported Version Number.
>            2 - Bad Peer ITAD.
>            3 - Bad TRIP Identifier.
>            4 - Unsupported Optional Parameter.
>            5 - Unacceptable Hold Time.
>            6 - Unsupported Capability.
>            7 - Capability Mismatch.
> 
>            UPDATE Message (3) Error Subcodes:
>            1 - Malformed Attribute List.
>            2 - Unrecognized Well-known Attribute.
>            3 - Missing Well-known Mandatory Attribute.
>            4 - Attribute Flags Error.
>            5 - Attribute Length Error.
>            6 - Invalid Attribute."
>       ::= { tripMIBNotifications 5 }
> 
> --
> -- Notifications
> --
>    tripEstablished NOTIFICATION-TYPE
>        STATUS  current
>        DESCRIPTION
>            "The TRIP Established event is generated when the TRIP
>            FSM enters the ESTABLISHED state."
>        ::= { tripMIBNotifications 6 }
> 
>    tripFSM NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "The trip FSM Event is generated when any error is detected
>            by the TRIP Finite State Machine."
>        ::= { tripMIBNotifications 7 }
> 
>    tripOpenMessageError NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "Errors detected while processing the OPEN message."
>        ::= { tripMIBNotifications 8 }
> 
>    tripUpdateMessageError NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "Errors detected while processing the UPDATE message."
>        ::= { tripMIBNotifications 9 }
> 
>    tripHoldTimerExpired NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>        STATUS  current
>        DESCRIPTION
>            "The system does not receive successive messages within the
>            period specified by the negotiated Hold Time."
>        ::= { tripMIBNotifications 10 }
> 
>    tripConnectionCollision NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex }
>        STATUS  current
>        DESCRIPTION
>            "A pair of LSs tried to simultaneously to establish a
>            transport connection to each other."
>        ::= { tripMIBNotifications 11 }
> 
>    tripNotificationErr NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex }
>        STATUS  current
>        DESCRIPTION
>            "Generated if there is an error detected in a TRIP
>            notification message sent with another cause. Note that
>            the TRIP notification refered to in this object is not
>            an SNMP notification, it is a specific message described
>            in the TRIP specification."
>        REFERENCE
>            "draft-ietf-iptel-trip-07.txt, J. Rosenberg et al,
>            section 6.4."
>        ::= { tripMIBNotifications 12 }
> 
>    --
>    -- Compliance Statements
>    --
>    tripCompliance MODULE-COMPLIANCE
>        STATUS     current
>        DESCRIPTION
>             "The compliance statement for TRIP entities."
> 
>        MODULE -- this module
>             MANDATORY-GROUPS { tripConfigGroup,
>                                tripPeerTableConfigGroup,
>                                tripRouteGroup,
>                                tripItadTopologyGroup,
>                                tripPeerTableStatsGroup }
> 
>        GROUP tripNotificationGroup
>        DESCRIPTION
>            "This group is optional. A TRIP entity can choose not to
>            send any notifications. If this group is implemented, the
>            tripNotifObjectGroup must also be implemented."
> 
>        GROUP tripNotifObjectGroup
>        DESCRIPTION
>            "This group is optional. A TRIP entity can choose not to
>            send any notifications. If this group is implemented, the
>            tripNotificationGroup must also be implemented."
> 
>        MODULE NETWORK-SERVICES-MIB
>             MANDATORY-GROUPS { applRFC1565Group }
> 
>        ::= { tripMIBCompliance 1 }
> 
> --
> -- Object and event conformance groups
> --
> 
>    tripConfigGroup OBJECT-GROUP
>        OBJECTS {
>            tripProtocolVersion,
>            tripLocalItad,
>            tripIdentifier,
>            tripOperStatus,
>            tripAdminStatus,
>            tripLocalAddrIAddrType,
>            tripLocalAddr,
>            tripLocalPort,
>            tripMinItadOriginationInterval,
>            tripMinRouteAdvertisementInterval,
>            tripMaxPurgeTime,
>            tripDisableTime,
>            tripSendReceiveMode,
>            tripSupportedCommunityItad,
>            tripSupportedCommunityRowStatus
>        }
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring trip."
>        ::= { tripMIBGroups 1 }
> 
>    tripPeerTableConfigGroup OBJECT-GROUP
>        OBJECTS {
>            tripPeerIdentifier,
>            tripPeerState,
>            tripPeerAdminStatus,
>            tripPeerNegotiatedVersion,
>            tripPeerSendReceiveMode,
>            tripPeerRemotePort,
>            tripPeerRemoteItad,
>            tripPeerConnectRetryInterval,
>            tripPeerMaxRetryInterval,
>            tripPeerHoldTime,
>            tripPeerKeepAlive,
>            tripPeerHoldTimeConfigured,
>            tripPeerKeepAliveConfigured,
>            tripPeerMinItadOriginationInterval,
>            tripPeerMinRouteAdvertisementInterval,
>            tripPeerMaxPurgeTime,
>            tripPeerDisableTime,
>            tripPeerRowStatus
>            }
> 
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring the TRIP peer table."
>        ::= { tripMIBGroups 2 }
> 
>    tripPeerTableStatsGroup OBJECT-GROUP
>        OBJECTS {
>            tripPeerInUpdates,
>            tripPeerOutUpdates,
>            tripPeerInTotalMessages,
>            tripPeerOutTotalMessages,
>            tripPeerFsmEstablishedTransitions,
>            tripPeerFsmEstablishedTime,
>            tripPeerInUpdateElapsedTime
>            }
> 
>        STATUS current
>        DESCRIPTION
>            "The global statistics the TRIP peer table."
>        ::= { tripMIBGroups 3 }
> 
>    tripRouteGroup OBJECT-GROUP
>        OBJECTS {
>            tripRouteAddressSequenceNumber,
>            tripRouteAddressOriginatorId,
>            tripRouteNextHopServerIAddrType,
>            tripRouteNextHopServer,
>            tripRouteNextHopServerPort,
>            tripRouteNextHopServerItad,
>            tripRouteMultiExitDisc,
>            tripRouteLocalPref,
>            tripRouteAdvertisementPath,
>            tripRouteRoutedPath,
>            tripRouteAtomicAggregate,
>            tripRouteBest,
>            tripRouteUnknown,
>            tripRouteWithdrawn,
>            tripRouteConverted,
>            tripRouteCommunityItad,
>            tripPeerRtTypeRowStatus
>            }
> 
>        STATUS current
>        DESCRIPTION
>            "The global objects for configuring route attribute."
>        ::= { tripMIBGroups 4 }
> 
>    tripItadTopologyGroup OBJECT-GROUP
>        OBJECTS {
>            tripItadTopologySeqNum,
>            tripItadTopologyIdRowStatus
>            }
>        STATUS current
>        DESCRIPTION
>            "The objects that define the TRIP ITAD topology."
>        ::= { tripMIBGroups 5 }
> 
>    tripNotificationGroup NOTIFICATION-GROUP
>        NOTIFICATIONS {
>            tripEstablished,
>            tripFSM,
>            tripOpenMessageError,
>            tripUpdateMessageError,
>            tripHoldTimerExpired,
>            tripConnectionCollision,
>            tripNotificationErr
>        }
>        STATUS  current
>        DESCRIPTION
>             "A collection of notifications defined for TRIP."
>        ::= { tripMIBGroups 6 }
> 
>    tripNotifObjectGroup OBJECT-GROUP
>        OBJECTS {
>            tripNotifApplIndex,
>            tripNotifPeerAddrInetType,
>            tripNotifPeerAddr,
>            tripNotifPeerErrCode,
>            tripNotifPeerErrSubcode
>            }
>        STATUS current
>        DESCRIPTION
>            "The collection of objects that specify information for
>            TRIP notifications."
>        ::= { tripMIBGroups 7 }
> 
> END

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 31 16:44:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15692
	for <iptel-archive@odin.ietf.org>; Fri, 31 Aug 2001 16:44:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1B1BA44350; Fri, 31 Aug 2001 15:47:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 355E044336
	for <iptel@lists.bell-labs.com>; Fri, 31 Aug 2001 15:46:48 -0400 (EDT)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA24285;
	Fri, 31 Aug 2001 16:45:49 -0400 (EDT)
Message-ID: <3B8FF77D.E1AC6A5F@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Cc: Weibin Zhao <zwb@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] SLP-based gateway location
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 31 Aug 2001 16:45:49 -0400
Content-Transfer-Encoding: 7bit

In case the announcement didn't make it to this list:
draft-zhao-iptel-gwloc-slp-00.txt is in the archives as an initial
version to start discussion. Comments are most welcome.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Aug 31 21:16:46 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18735
	for <iptel-archive@odin.ietf.org>; Fri, 31 Aug 2001 21:16:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EFE3C44358; Fri, 31 Aug 2001 20:19:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 69D7E44336
	for <IPTEL@lists.bell-labs.com>; Fri, 31 Aug 2001 20:18:00 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id UAA09192
	for <IPTEL@lists.bell-labs.com>; Fri, 31 Aug 2001 20:17:03 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 31 Aug 2001 20:10:49 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RPSX8BFS>; Fri, 31 Aug 2001 20:17:04 -0500
Message-ID: <A56F0B4D52CDD1118F500000F8073C9B05B9247C@crchy272.us.nortel.com>
From: "Woody Denman" <wdenman@nortelnetworks.com>
To: "'IPTEL@lists.bell-labs.com'" <IPTEL@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13283.CAECDDB0"
X-Orig: <wdenman@americasm01.nt.com>
Subject: [IPTEL] unsubscribe IPTEL
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 31 Aug 2001 20:16:56 -0500

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_01C13283.CAECDDB0
Content-Type: text/plain;
	charset="iso-8859-1"

unsubscribe IPTEL

------_=_NextPart_001_01C13283.CAECDDB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>unsubscribe IPTEL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">unsubscribe IPTEL</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13283.CAECDDB0--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel