From rsvp-owner@ISI.EDU Sun Sep 3 06:01:26 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07451
for ; Sun, 3 Sep 2000 06:01:25 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id BAA04238
for rsvp-outgoing; Sun, 3 Sep 2000 01:08:39 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA04228
for ; Sun, 3 Sep 2000 01:08:37 -0700 (PDT)
Received: from unknown (cc584590-a.nagusta1.sc.home.com [24.10.12.57])
by venera.isi.edu (8.9.3/8.9.3) with SMTP id BAA29588;
Sun, 3 Sep 2000 01:09:12 -0700 (PDT)
From: akl@aol.com
Subject: smithy tools
Date: Sun, 3 Sep 2000 00:35:01
Message-Id: <798.616719.886474@>
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
hello just wonted to tell ever body to stay a way from SMITHY
unless you wont to throw a way money i bought a granite 1339
and all tools 5000.00 worth junk you see they had broken it and
then put it in a box the box was not damage in any way what so
ever but the equipment was broken i called them at
1-800-476-4849 they said they have my money and there was nothing
i could do about i asked them a bout the 30 day warranty they
said it was up i told them i only had it 2 weeks and then they
hung up on me ive called them many times but they wont talk to me
when they find out it is me they put me to voice mail and never
call me back but they are wrong i bought a mass mailer program
and i am sending thes letters out ever day 100000 of them ever
day thank you for your time may be this will save some one ther
money
From rsvp-owner@ISI.EDU Mon Sep 4 02:25:04 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29883
for ; Mon, 4 Sep 2000 02:25:03 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id VAA15639
for rsvp-outgoing; Sun, 3 Sep 2000 21:38:32 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA15634
for ; Sun, 3 Sep 2000 21:38:30 -0700 (PDT)
Received: from union.mobiletone.com (IDENT:qmailr@[205.219.91.37])
by gamma.isi.edu (8.9.3/8.9.3) with SMTP id VAA16550
for ; Sun, 3 Sep 2000 21:39:39 -0700 (PDT)
Received: (qmail 739 invoked by uid 514); 4 Sep 2000 03:12:17 -0000
Date: 4 Sep 2000 03:12:17 -0000
Message-ID: <20000904031217.738.qmail@union.mobiletone.com>
From: "Traderfirst Webmaster"
To: "rsvp@isi.edu"
Subject: Electronics Parts B2B Portal (Celebrating TraderFirst Official Launch with Lucky Draw Campaign)
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
English: http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=en
Traditional Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=big5
Simplified Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=gb
Dear Valued Customer,
(New B2B Electronic Asia Portal)
* We are pleased to inform you that TraderFirst.com (www.traderfirst.com) will be officially launched on September 6th, 2000. We dedicate in providing first class services and products to our customers.
* Company Introduction: Traderfirst.com is a leading Internet business-to-business (B2B) exchange and application service provider (ASP) mainly for electronics parts and semiconductor industry in Asia. We are providing a Chinese and English Internet platform for customers to bridge their business worldwide efficiently. TraderFirst.com philosophy is simple: we care the CUSTOMERS, SERVICES, & QUALITY.
* WANNA! HK$20,000.00 CASH Lucky Draw Program: For the first 200 "Gold Members only"
In order to celebrate the official launch, we set up a HK$20,000 cash lucky draw program* for one lucky winner, plus 10 special prizes. Please visit www.traderfirst.com now & get more business opportunities.
* "Gold member" registration site: www.traderfirst.com. Please register today and don't lose the chance to win the HK$ 20,000.00 CASH!
Thank you of your kind attention. If you have any question, please feel free to contact at 852-24050498 or e-mail to customer@traderfirst.com
Yours faithfully,
Marketing Department,
TraderFirst.com Ltd
(www.traderfirst.com)
N.B: * All employees of TraderFirst.com and their affiliates are not allowed to participate. This program is for worldwide customers. It is subject to change. All rights are reserved by TraderFirst.com. If you do not wish to receive any promotional materials from us, please send e-mail to info@traderfirst.com.
From rsvp-owner@ISI.EDU Mon Sep 4 06:03:43 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01675
for ; Mon, 4 Sep 2000 06:03:43 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA23907
for rsvp-outgoing; Mon, 4 Sep 2000 01:13:16 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA23902
for ; Mon, 4 Sep 2000 01:13:14 -0700 (PDT)
Received: from ormail2.orckit.com ([194.90.167.2])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA20842
for ; Mon, 4 Sep 2000 01:14:27 -0700 (PDT)
Received: by ORMAIL2 with Internet Mail Service (5.5.2650.21)
id ; Mon, 4 Sep 2000 11:13:59 +0200
Message-ID:
From: Liav Leshem
To: "'rsvp@isi.edu'"
Subject: RSVP Software Package
Date: Mon, 4 Sep 2000 11:13:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="windows-1255"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi All
I am looking for an RSVP software package for embedded environment
(VxWorks OS).
Would anybody recommend any specific vendor?
Liav Leshem
Fast-Internet Group
Orckit Communications Ltd.
126 Yigal Alon St.
Tel-Aviv 67443, Israel
Tel.: +972 3 608 4802
Fax: +972 3 696 5678
e-mail: LiavL@orckit.com
From rsvp-owner@ISI.EDU Mon Sep 4 07:59:22 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02804
for ; Mon, 4 Sep 2000 07:59:21 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA28472
for rsvp-outgoing; Mon, 4 Sep 2000 03:16:51 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA28455
for ; Mon, 4 Sep 2000 03:16:48 -0700 (PDT)
Received: from neo.it.comsat.com (neo.it.comsat.com [134.133.200.200])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA13793
for ; Mon, 4 Sep 2000 03:18:02 -0700 (PDT)
Received: (from smadmin@localhost)
by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84ACIn23580;
Mon, 4 Sep 2000 06:12:18 -0400 (EDT)
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84ACFo23576
for ; Mon, 4 Sep 2000 06:12:15 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA23907
for rsvp-outgoing; Mon, 4 Sep 2000 01:13:16 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA23902
for ; Mon, 4 Sep 2000 01:13:14 -0700 (PDT)
Received: from ormail2.orckit.com ([194.90.167.2])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA20842
for ; Mon, 4 Sep 2000 01:14:27 -0700 (PDT)
Received: by ORMAIL2 with Internet Mail Service (5.5.2650.21)
id ; Mon, 4 Sep 2000 11:13:59 +0200
Message-ID:
From: Liav Leshem
To: "'rsvp@isi.edu'"
Subject: RSVP Software Package
Date: Mon, 4 Sep 2000 11:13:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="windows-1255"
X-Mail-Filter: omnivore ver 1.0.0
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi All
I am looking for an RSVP software package for embedded environment
(VxWorks OS).
Would anybody recommend any specific vendor?
Liav Leshem
Fast-Internet Group
Orckit Communications Ltd.
126 Yigal Alon St.
Tel-Aviv 67443, Israel
Tel.: +972 3 608 4802
Fax: +972 3 696 5678
e-mail: LiavL@orckit.com
From rsvp-owner@ISI.EDU Mon Sep 4 14:46:15 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05947
for ; Mon, 4 Sep 2000 14:46:15 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA15140
for rsvp-outgoing; Mon, 4 Sep 2000 10:03:18 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA15135
for ; Mon, 4 Sep 2000 10:03:16 -0700 (PDT)
Received: from hotmail.com (f77.law7.hotmail.com [216.33.237.77])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA08530
for ; Mon, 4 Sep 2000 10:04:32 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Mon, 4 Sep 2000 10:04:01 -0700
Received: from 209.58.122.10 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 04 Sep 2000 17:04:01 GMT
X-Originating-IP: [209.58.122.10]
From: "wadia al-zantuti"
To: rsvp@ISI.EDU
Date: Mon, 04 Sep 2000 17:04:01 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID:
X-OriginalArrivalTime: 04 Sep 2000 17:04:01.0873 (UTC) FILETIME=[1FAB4C10:01C01692]
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
hi list,
i need any program easy to use for making analysis
on any rsvp protcol problems working on windows or dos env.
bye
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
From rsvp-owner@ISI.EDU Fri Sep 8 05:14:22 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19244
for ; Fri, 8 Sep 2000 05:14:21 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA12750
for rsvp-outgoing; Fri, 8 Sep 2000 00:11:00 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12745
for ; Fri, 8 Sep 2000 00:10:58 -0700 (PDT)
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA03493
for ; Fri, 8 Sep 2000 00:12:13 -0700 (PDT)
Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway)
id QAA18313 for ; Fri, 8 Sep 2000 16:11:41 +0900 (JST)
(envelope-from kakiuchi@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master)
id QAA22313; Fri, 8 Sep 2000 16:11:41 +0900 (JST)
Received: from nd.net.fujitsu.co.jp (kakiuchi.nd.net.fujitsu.co.jp [10.18.7.136]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id QAA03232; Fri, 8 Sep 2000 16:11:40 +0900 (JST)
Message-ID: <39B8912B.D5C2B1AD@nd.net.fujitsu.co.jp>
Date: Fri, 08 Sep 2000 16:11:39 +0900
From: =?iso-2022-jp?B?GyRCM0BGYhsoQg==?=
Organization: =?iso-2022-jp?B?GyRCSVk7TkRMIUozdCFLGyhCPGh0dHA=?=:
//www.fujitsu.co.jp/>
X-Mailer: Mozilla 4.7 [ja] (Win95; I)
X-Accept-Language: ja
MIME-Version: 1.0
To: rsvp@ISI.EDU
CC: kakiuchi@nd.net.fujitsu.co.jp
Subject: rsvp-request@isi.edu
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
From rsvp-owner@ISI.EDU Fri Sep 8 07:27:12 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20188
for ; Fri, 8 Sep 2000 07:27:11 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id CAA18288
for rsvp-outgoing; Fri, 8 Sep 2000 02:41:30 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA18283
for ; Fri, 8 Sep 2000 02:41:28 -0700 (PDT)
Received: from 21cn.com ([202.104.32.248])
by gamma.isi.edu (8.9.3/8.9.3) with SMTP id CAA00990
for ; Fri, 8 Sep 2000 02:42:43 -0700 (PDT)
Received: from lmx([61.151.18.217]) by 21cn.com(JetMail 2.5.3.0)
with SMTP id jmd39b8c279; Fri, 8 Sep 2000 09:42:14 -0000
From: "Skyperfectv's Good News"
Reply-To: xworld@21cn.com
Message-ID: {59E17B4D-85A6-11D4-9828-444553540000}@lmx
Subject: 伊妹中自有黄金屋,m@il内自有颜如玉.Get mail,get CASH. #3F64
To: sato-21cn.com-0048-9.8-1@ISI.EDU
X-Mailer: Mozilla 4.6 [en] (Win95; I)
Mime-Version: 1.0
Date: Fri, 08 Sep 2000 16:37:32 +0800
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Type: text/plain; charset=unknown-8bit
X-MIME-Autoconverted: from 8bit to base64 by zephyr.isi.edu id CAB18288
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA20188
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Skyperfectv'S Good News
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
\\\|///
\\ - - //
( @ @ )
+-----------------oOOo-(_)-oOOo------------+
| 伊妹中自有黄金屋,m@il中自有颜如玉 |
|Website ==>http://www.skyperfectv.8u8.com |
| E-m@il ==>skyperfectv@sohu.com |
+------------------------Oooo--------------+
oooO ( )
( ) ) /
\ ( (_/
\_)
◆◆◆ If You no interesting GET CASH by receive AD mails,We are so sorry and Please Contact us to Delete Your mail address From The List.◆◆◆
◇◇◇如果打扰了您、请随手删除,并接受我诚挚的歉意!◇◇◇
> Hi,my friends:你好!
> 最近身体好吗?是不是为一直上升的上网费用而发愁?
> 我选用的是一种最简单、最不费神、任何人都行的赚钱方式——收Email广告。
> 如果你对此有兴趣,请听我介绍几个对全世界付费的EMAIL广告公司。
> 其中第一,五个是很可信的,其它几个不知道怎么样,但看起来也不错,建议你都注册一
> 下,反正又不需什么成本。
>
> ━━★PR━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> 1.强烈向你推荐美国的SendMoreInfo,特点是广告量大,广告资金充足,
> 每月20日满10美元即付款。我目前只收到过这家公司的支票,所以对其信誉
> 是不用怀疑的。注册网址是:
>
> http://www.sendmoreinfo.com/id/1252656
>
> 该公司目前每封EMAIL付费5美分,你的下线每收一封EMAIL,你还可得
> 2美分。如果能发展足够的下线,收入就相当可观。
> 请注意,对Sendmoreinfo发来的每一封EMAIL,中间都包含了一个链接
> (蓝色的网址),你必须点击这个链接才给你付费。但这并不麻烦,一分钟
> 点击四、五十封不成问题。根据本人的经验,在点击其中的链接时,看到浏
> 览器中开始显示网页时就可关闭,然后再点击下一封,所以速度很快!你不
> 必看他的广告,你只管收美元!还可以根本不收Email 也能赚钱。登录到你
> 的帐户后,点击“Paid Email”,就会发现列有最近发给你的10封Email 广
> 告信的题目,点击最右边的“Click pay link”就行了,五秒钟就可点完10
> 封邮件。点击后你马上就会喜滋滋地看到你的收入又增加了!岂不美哉!
>
> 注册方法: 首先点击以下链接:
> http://www.sendmoreinfo.com/id/1252656
> 登录后点击右上角的“sign up”,然后点“Next”按钮,接着填写如下的
> 个人信息:(其中带“*”的为必填项目):
> First 你的名字 Last你的姓 (姓名必须用拼音,不能用汉字)
> Addr 1 地址(请用英文或拼音)
> City所在城市 State 选“Not in US or Canada” Zip邮政编码
> Country国家(选China) Email电子邮件地址(必须准确有效)
> Day Phone电话号码
> Password登录密码(请记牢,以后登录查帐时需这个密码)
> Gender / Marital性别和婚姻状况 Birthday出生月/日/年
>
> 下一步要你选择感兴趣的广告类别,共130多种,最多可选10种。填写
> 后,按“Submit Info”就注册完毕。接下来就等着收EMAIL和美元了!
> 不同类别的广告数量有很大的差异,广告量较多的类别有:
> Advertising Affiliate Programs
> Books Business Opportunities
> Computer Supplies Computers
> E-Commerce Finance
> Internet Internet Business
> Internet Marketing Investing
> Multi-Level Marketing Shopping
> Webmasters
> 特别提示:如果你的地址填的是美国的大城市,广告信要多得多(比中国
> 人的多一倍)。所以完全可胡乱用美国的一个地址注册(注意:美国的 ZIP为
> 五位数),到收支票前再改为你的真实地址。
>
> ━━★PR━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> 2.“spedia”是目前网上最用得多的网评最好的一个!spedia每点价值是$0.0079到0.0081,
每小时看广告60个,得60点,每小时收入$0.48。但必须:a、鼠标要动;b、必须是使用浏览器;
c、必须与spedia服务器挂好(这是当然的了)。另外,每点击一下广告得1点,
如注册成功了20个以上的程序且一个月得到20颗星,就可增加总收入30%到50%,每小时可到$0.7了。
星的得法是每天自己上网2小时以上(其实是要自己每天得120点广告点,不算下线)。
现在支持五级下线,分别增加介绍人10%,5%,5%,5%,5%。多发展下线是个好办法。
另外,spedia是目前服务项目最多的赚钱网站,申请后仅是通过注册网站就可以得到好几十美元。
以后主要是广告条赚钱,申请成功后由下面链接进入即可下载广告条,所有的功能可从中找到。
为了能收到钱,地址得用拼音或英文正确填写。
请点击以下链接后注册:
http://www.spedia.net/cgi-bin/tz.cgi?run=show_svc&fl=8&vid=1742817
> ━━★PR━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> 3.今天是来自Skiddily.com好消息,他们要付美元现金支票了。
The first reward checks will be sent out between the 25th of September to the 15th of October.
第一批支票于9月25日至10月15日寄出.
注册地址:http://www.skiddily.com/join.asp?ref=23350
设置IE开始页,每显示一次为0.025美元,限定每天十次,每月三百次,一个月可赚7.5美元,满20美元支付支票,对国际会员(中国)付费。
五层下线的提成分别是:40%,20%,10%,10%,10%。该公司在8月1日运营,会员名额限定100000名后将不再接受国际会员注册,所以大家应该尽快注册。
使用方法:打开IE浏览器工具中的Internet选项,在常规中把主页的地址改为http://www.skiddily.com/?id=xxxxx
(注:xxxxx是注册后分配给你的ID号)
注册地址:http://www.skiddily.com/join.asp?ref=23350
> ━━★PR━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> 4.香港创富公司,中文注册。请点击以下网址注册:
>
> http://www.sharerich.com/schi/asp/joinframe.asp?rid=173094
>
> 该公司目前每封EMAIL付费0.1元港币,你的下线、下线的下线、直到五
> 层以内的所有下线每收一封EMAIL, 你都可得0.05元港币。该公司目前处于
> 初创时期,广告量还较少,但发展下线很容易,随着公司业务的迅速扩展,
> 财源将会滚滚而来!
> 登记手续十分简单. 请进入以下网址
> http://www.sharerich.com/schi/asp/joinframe.asp?rid=173094
>
> 我的会员编号是 :173094
> ━━★PR━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.Themail只要你注册成为会员,它就会为你提供一个免费的电子邮箱,不仅完全免费,还付给你钱。你使用该邮箱收信/发信,每封信0.25美分,你可以发展下线来增加你的收入,
直接下线每收/发一封信,你得到0.0025$,间接下线直到16层,每封信件0.0005$。别小看每封邮件这么少钱,但收/发由你决定,且下线多达十六层,收入是非常可观的。
结算时间:随时申请,在Stats页中选择Cash Out即可,$30起付,全球开通。很多网友都己收到支票,信誉极佳!
注册后你就可以对全世界说:“欢迎给我发垃圾邮件”,因为你使用该信箱收到邮件越多你的收入也就越可观!!
TheMail为您提供安全、便利的电子邮件服务。在您享受免费、可靠的邮件服务的同时,您还有机会挣到美元,一举两得。还等什么,赶快申请吧!!!
http://themail.com/ref.htm?ref=1206891
Themail邮箱还提供了强大的管理工具
Folders:允许您建立不限数量的文件夹,便于组织管理您的邮件。
Mail Filters: 按照您设定的标准自动转寄,移动和删除您收到的邮件。
Address Book: 保存一个您最常用的电子邮件地址簿。
Email Groups: 将经常要发送相同邮件的电子邮件地址设成一个邮件组,简单的实现邮件群发。
Search: 能在您的邮箱中通过关键词搜索您想要的消息。
Personal Calender: 能够提前一个月提醒您自己设定的重要计划。
POP3 Retrieval: 能够将您的POP3邮箱中的邮件定期取回到您的Themail邮箱。
Auto Responder: 收到邮件后,自动发送一封回信。
Signature: 在您发信时,在信尾自动增加一个您自己设计的签名。
State:可以察看自己的收入情况。
Personal Preferences: 可以根据您的要求设计您的信箱的显示和工作方式。
付款说明 :您可以在您的帐户中的钱到$30时要求Themail付款。 当您帐户中的钱到达$30后,您邮箱中的Stats页将出现一个Cash out项,点击即可付款。
Themail支持对国际用户付款。
注册方法:
首先 sign up 进行注册,注册分三步
第一步
Please complete this important form accurately. All fields are required for an a
ccount. (If the information is not correct, you may not receive any payments)
请仔细完成表单填写,如果信息有误,你可能收不到支票
New Email Name: 输入你想要的email帐号名
Your email name may contain the letters A-Z, the numbers 0-9 and the underscore
"_". Your name must begin with a letter.
你的帐号可以包括字母A-Z,数字0-9和下华线"_",但必须以字母开头
First Name: 你的姓(填名比较好)
Last Name: 你的名字(填姓比较好)
Birthday: 出生(月、日、年)
Gender: 性别Male(男) Female(女)
Country: 国家(China中国)
点击进行第二步
Congratulations! XXX@THEMAIL.COM is available. Your selected email name will not
be final until registration is completed.
你的信箱已经生效,但你得完成以后的步骤
Password: 输入密码
Confirm: 确认密码
You will be asked this question if you lose your password. 密码丢失提示问题
Password Question: 密码问题(忘记密码时,提问)
Password Answer: 答案
Time (NST)时区(选择这个 Time (VST) GMT +8:00 - China Taiwan Time)
Address: 地址(要输对,寄钱给你喔!)
Address 2: 地址2(备用)
City: 城市
Region/State: 省
Postal Code: 邮政编码
Occup: 职业
Income: 收入
ationAlternate Email: 其他email地址(你已有的)
第三步:选择你感兴趣的一些类别(从众多标题中打勾选择,有些是付钱的,所以最好多选),快从这里申请吧!
http://themail.com/ref.htm?ref=1206891
最酷读信秘诀:使用网际快车(JetCar)读theMail的信!
TheMail终极解决方案
TheMail是一家免费邮件服务提供商,提供5M的WEB界面邮箱,并且当你的下线读信时付给你报酬(注意是你的下线读信时,而不是你自己读信!).
有两种办法包你赚钱:
1.发展下线法 假设你只介绍2人做为你的下线加入(绝非难事),并且他们每人也只介绍2人加入,依此类推,那么到了16代以后,你的下线人数将达到惊人的数字(2的16
次方,即131,072人),如果每人平均每天收一封信(不难吧),一天你就有收入65.5美元! 怎么样? 如果您有说服别人的能力,还犹豫什么,赶快加入,然后就去发展下线吧!
2.自己收信法 自己注册为自己的下线,多注册几个信箱,多少不限,多多亦善.然后通过订阅垃圾邮件,或者用发信软件给自己发信,但有一点要注意,每个信箱每天读信不能超过3
00封(0.75美元),超过的则不计费.注意事项:读信后一定要点击LOGOUT退出,否则前面读的信将不算钱哦!另外空白信和内容重复的信也不算.所以最省事的办法就是订阅垃圾邮件
那么多信当然不能一封一封地读,推荐使用软件读信,我个人认为最好的是JetCar,JetCar是大名鼎鼎的下载软件,前些天有网友用它来读信,效果不错,我已经测试了两天,
发现了一些问题并找到了解决办法,下面是使用方法:
首先,你的机器上得装有jetcar,现在叫FlashGet然后选"工具"--》"选项"把"对于不支持断点续传的扔然下载"一项的钩去掉(不选),把"最多同时进行的任务数"
改为1(因为TheMail不支持多线程读信,原来设置为5时读信很快但再刷新Inbox时发现只读了20%左右的信,设置成1读信虽然慢一些但能把100封读完),登入t
hemail,选PREFERENCES,将Max messages per page:项的值改为100.这样以后你每页可以显示100封信的主题.点 Inbox等页面出来后,点鼠标右键选取"
用jetcar下载全部联接",这一页所有的链接全都列出来了,注意,这时一定要将不是信的链接去掉(把钩去掉,是信的链接都有...read_message...的字样,
要保留上面的钩!) 点确定!一切OK!这jetcar并没有下载文件,而只是点了一信! 等下载窗里面都变成红叉时就读完了! 然后把这一页的信删了再读下一页.
注意进入themail信箱时,网站要用到你的cookie,所以一次只能点一个信箱里的信,点完一个信箱后,点loginout后再进入另一个信箱!
经我测试,用JetCar,读100封信要4-6分钟,视网络的速度略有差别,但保证1小时能读1000封左右.缺点是操作起来比较烦琐一些,但熟能生巧,多用几次行了:
)每小时轻松获得2.5美元!比看广告条强多了!心动不如行动!!!
jetcar(flashget) http://software.silversand.net:83/internet/ftp/fg086.zip
另外您可以自己注册成为自己的下线,注册10个下线,每天每个信箱读300封信,10个每天就是7.5美圆。如果您觉得每个信箱每天要收到300封信有困难的话,请把您的1
0个下线信箱地址告诉我,我保证您的每个信箱每天可以收到300封不同内容的信,您就可以每天挣7.5美圆了。
From rsvp-owner@ISI.EDU Sat Sep 9 20:38:58 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24168
for ; Sat, 9 Sep 2000 20:38:57 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA03299
for rsvp-outgoing; Sat, 9 Sep 2000 15:57:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id PAA03294
for ; Sat, 9 Sep 2000 15:57:24 -0700 (PDT)
Received: from photon (photon.idirect.com [207.136.80.123])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id PAA06878;
Sat, 9 Sep 2000 15:57:22 -0700 (PDT)
From: westoakwireless@yahoo.com
Received: from bc-van-reg-a53-01-89.look.ca ([216.66.142.89] helo=yahoo.com)
by photon.idirect.com with smtp (Exim 3.12 #9)
id 13XtYm-00063e-00; Sun, 10 Sep 2000 03:57:21 +0500
Reply-To: westoakwireless@yahoo.com
To: westoakwireless@yahoo.com
Subject: FREE Investor's kit - Wireless Company Goes Public
Message-Id:
Date: Sun, 10 Sep 2000 03:57:21 +0500
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
**************************************************
TELESIS NORTH GOES PUBLIC
September 9, 2000
Telesis North, (stock symbol: WO.CDNX), is a wireless connectivity software company providing applications for the exploding wireless communications market.
INVESTMENT HIGHLIGHTS:
-The company has been in business since 1989, with an established customer base and worldwide distribution channels.
-Founded by 2 former engineers from Nortel Networks, world leader in telecom technology and one of the most active stocks on the TSE.
-Strong management team that includes a former Vice President of Infowave Software (IW. TSE), a wireless software stock in the same niche as Telesis North whose market capitalization hit 1.3 billion dollars!
-Strong working relationships with Inmarsat, Microsoft, Telenor, SingTel, Eicon, and Fuji Trading.
-Recently announce distribution agreement and investment from Stratos Global Corporation (SGB. TSE), one of Canada抯 fastest growing companies and a world leader in satellite and wireless communications services.
Telesis North is in the process of going public through a merger with West Oak Resource Corp.
For a FREE company information kit click:
For the latest NEWS on the Company Click Here:
**************************************************************
This bulletin has been sent to you at no charge.
THIS IS NOT A RECOMMENDATION TO BUY OR SELL ANY SECURITY!
To remove yourself from this mailing list click here:
From rsvp-owner@ISI.EDU Mon Sep 11 14:58:48 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08024
for ; Mon, 11 Sep 2000 14:58:44 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id KAA21744
for rsvp-outgoing; Mon, 11 Sep 2000 10:00:44 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA21739
for ; Mon, 11 Sep 2000 10:00:43 -0700 (PDT)
Received: from e-stock2000.com ([202.96.242.107])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25517
for ; Mon, 11 Sep 2000 10:00:43 -0700 (PDT)
Received: from xujingmi [202.109.84.81] by e-stock2000.com with ESMTP
(SMTPD32-5.05) id AD726E000B2; Mon, 11 Sep 2000 18:57:06 +0800
From: "abc"
Subject: Re:
To: user@ISI.EDU
X-Mailer: V3,2,2,0 (W95/NT) (Build: Oct 18 1999)
Mime-Version: 1.0
Date: Mon, 11 Sep 2000 18:55:35 +0800
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <200009111857250.SM00251@xujingmi>
X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id KAA21740
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
X-MIME-Autoconverted: from 8bit to base64 by zephyr.isi.edu id KAB21744
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA08024
http://www.acrosslove.eazier.com
找到您的真爱
From rsvp-owner@ISI.EDU Mon Sep 11 21:11:41 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10504
for ; Mon, 11 Sep 2000 21:11:41 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id OAA01809
for rsvp-outgoing; Mon, 11 Sep 2000 14:52:53 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA01804
for ; Mon, 11 Sep 2000 14:52:52 -0700 (PDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12764;
Mon, 11 Sep 2000 14:52:46 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id VAA00306;
Mon, 11 Sep 2000 21:52:46 GMT
Date: Mon, 11 Sep 2000 21:52:46 GMT
Message-Id: <200009112152.VAA00306@gra.isi.edu>
To: lberger@labn.net
Subject: Questions about draft-ietf-rsvp-refresh-reduct-05
Cc: rsvp@ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Lou,
I have been struggling with understanding section 5 of the Refresh
Reduction Proposed Standard (which is still in the RFC Editor's queue,
unfortunately). Pardon me if I am dense. I have been going over your
words line by line and trying to write down what I think they mean, but
I find one apparent contradiction and some confusion. Hopefully you can
straighten me out. I apologize for bringing this up so late; I just
happened to want to REALLY understand section 5.
In the following, I have extracted just the sentences that concern the
use of the various MESSAGE_ID objects, which is where I have confusion.
Everything else seems pretty much OK, and I don't think I have omitted
anything bearing on my confusion.
Bob
________________________________________________________________
*>
*> 5. Summary Refresh Extension
*>
*> ...
*>
*> The three
*> objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST
*> object, and the MESSAGE_ID MCAST_LIST object.
*>
*> ...
*>
*> The MESSAGE_ID LIST object is used to refresh all Resv state, and
*> Path state of unicast sessions.
*>
*> The other two objects are used to refresh Path
*> state of multicast sessions. ... Both carry
*> Message_Identifier fields and corresponding source IP addresses. The
*> MESSAGE_ID SRC_LIST is sent in messages addressed to the session's
*> multicast IP address. The MESSAGE_ID MCAST_LIST object adds the
*> group address and is sent in messages addressed to the RSVP next hop.
*> The MESSAGE_ID MCAST_LIST is normally used on point-to-point links.
*>
I write these rules as follows. I use "G" for the session destination
address, whether ucast or mcast). Otherwise, I hope the symbology is
obvious.
A1): (id) for Resv and ucast Path state
A2): (id,S) -> G for mcast Path state
A3): (id,S,G) -> hop for mcast Path state, NORMALLY(?) in pt-pt links
What does "normally" mean here??
For consistency with later statements, A1) should probably be:
A1'): (id)->hop for Resv and ucast Path msgs
*> ...
*>
*> 5.2. Srefresh Message Format
*>
*> ...
*>
*> Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
*> SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and
*> MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh
*> message. MESSAGE_ID SRC_LIST can not be combined in Srefresh
*> messages with the other objects. A single Srefresh message MAY
*> refresh both Path and Resv state.
*>
*> Srefresh messages carrying Message_Identifier fields corresponding to
*> Path state are normally sent with a destination IP address equal to
*> the address carried in the corresponding SESSION objects. The
*> destination IP address MAY be set to the RSVP next hop when the next
*> hop is known to be RSVP capable and either (a) the session is unicast
*> or (b) the outgoing interface is a point-to-point link. Srefresh
*> messages carrying Message_Identifier fields corresponding to Resv
*> state MUST be sent with a destination IP address set to the Resv
*> state's previous hop.
B1) Path state "normally" -> G
B2) Path state -> nhop IF direct neighbor and (ucast or pt-pt)
B3) Resv state -> phop
Now, B1) seems to directly contradict A1. A1 says ucast Path state is
sent to nhop, B1) says it is normally sent to G, whatever "normally"
means.
B2 is OK, noting the new condition of direct neighbor to be applied
to A1) and A3), But it calls into question the "normally" in A3).
B3) is consistent with A1')
*>
*> Srefresh messages sent to a multicast session's destination IP
*> address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT
*> include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects.
*> Srefresh messages sent to the RSVP next hop MAY contain either or
*> both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT
*> include any MESSAGE_ID SRC_LIST objects.
The paragraph above appears to be completly redundant with the two
preceding paragraphs, hence can be ignored. Did I miss something?
*>
*> ...
*>
*> 5.3. Srefresh Message Usage
*>
*> ...
*>
*> When generating an Srefresh message, there are two methods for
*> identifying which Path state may be refreshed in a specific message.
*> ...
*> The primary method is to
*> include only those sessions that share the same destination IP
*> address in the same Srefresh message.
*>
NOte that this does not fit the ucast Path msgs in A1), since the
Session dest G will not match the nhop address of the Srefresh message.
Hence MESSAGE_ID LIST objects will not be used except for the following
"optimization".
*> The secondary method for identifying which Path state may be
*> refreshed within a single Srefresh message is an optimization. This
*> method MAY be used when the next hop is known to support RSVP and
*> when either (a) the session is unicast or (b) the outgoing interface
*> is a point-to-point link.
But if A1 does not apply, neither do A2 or A3 for a unicast Path message.
So this section has left me confused.
*> (Redundant sentence omitted)
*> The use of this method MAY be administratively configured. When
*> using this method, the destination address in the IP header of the
*> Srefresh message is usually the next hop's address. When the use of
*> this method is administratively configured, the destination address
*> should be the well known group address 224.0.0.14. When the outgoing
*> interface is a point-to-point link, all Path state associated with
*> sessions advertised out the interface SHOULD be included in the same
*> Srefresh message. When the outgoing interface is not a point-to-
*> point link, all unicast session Path state SHOULD be included in the
*> same Srefresh message.
That appearance of the WK group address was something of a surprise here...
Otherwise, I could not figure out what the last two sentences actually mean.
*>
*> Identifying which Resv state may be refreshed within a single
*> Srefresh message is based simply on the source and destination IP
*> addresses. Any state that was previously advertised in Resv messages
*> with the same IP addresses as an Srefresh message MAY be included.
*>
*>
This is consistent with A1'), so that's OK.
Bob
From rsvp-owner@ISI.EDU Mon Sep 11 22:08:38 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11671
for ; Mon, 11 Sep 2000 22:08:37 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id RAA05811
for rsvp-outgoing; Mon, 11 Sep 2000 17:08:04 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA05806
for ; Mon, 11 Sep 2000 17:08:03 -0700 (PDT)
Received: from griffin.host4u.net (griffin.host4u.net [209.150.128.163])
by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA24030;
Mon, 11 Sep 2000 17:07:20 -0700 (PDT)
Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196])
by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id RAA23836;
Mon, 11 Sep 2000 17:48:02 -0500
Message-Id: <4.3.2.7.2.20000911181017.00bc0740@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 11 Sep 2000 18:50:20 -0400
To: Bob Braden
From: Lou Berger
Subject: Re: Questions about draft-ietf-rsvp-refresh-reduct-05
Cc: lberger@labn.net, rsvp@ISI.EDU
In-Reply-To: <200009112152.VAA00306@gra.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Bob,
See comments in-line. Should I ask what's motivating the "REALLY"
level of interest?
Lou
At 05:52 PM 9/11/00, Bob Braden wrote:
>Lou,
>
>I have been struggling with understanding section 5 of the Refresh
>Reduction Proposed Standard (which is still in the RFC Editor's queue,
>unfortunately). Pardon me if I am dense. I have been going over your
>words line by line and trying to write down what I think they mean, but
>I find one apparent contradiction and some confusion. Hopefully you can
>straighten me out. I apologize for bringing this up so late; I just
>happened to want to REALLY understand section 5.
>
>In the following, I have extracted just the sentences that concern the
>use of the various MESSAGE_ID objects, which is where I have confusion.
>Everything else seems pretty much OK, and I don't think I have omitted
>anything bearing on my confusion.
>
>Bob
>________________________________________________________________
>
>
> *>
> *> 5. Summary Refresh Extension
> *>
> *> ...
> *>
> *> The three
> *> objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST
> *> object, and the MESSAGE_ID MCAST_LIST object.
> *>
> *> ...
> *>
> *> The MESSAGE_ID LIST object is used to refresh all Resv state, and
> *> Path state of unicast sessions.
> *>
> *> The other two objects are used to refresh Path
> *> state of multicast sessions. ... Both carry
> *> Message_Identifier fields and corresponding source IP addresses. The
> *> MESSAGE_ID SRC_LIST is sent in messages addressed to the session's
> *> multicast IP address. The MESSAGE_ID MCAST_LIST object adds the
> *> group address and is sent in messages addressed to the RSVP next hop.
> *> The MESSAGE_ID MCAST_LIST is normally used on point-to-point links.
> *>
>
>I write these rules as follows. I use "G" for the session destination
>address, whether ucast or mcast). Otherwise, I hope the symbology is
>obvious.
>
> A1): (id) for Resv and ucast Path state
>
> A2): (id,S) -> G for mcast Path state
>
> A3): (id,S,G) -> hop for mcast Path state, NORMALLY(?) in
> pt-pt links
>
>What does "normally" mean here??
A3 is usually used on PTP links instead of A2. BTW the inclusion of this
was a compromise. I can't remember the details of the compromise, just
that it was one.
>For consistency with later statements, A1) should probably be:
>A1'): (id)->hop for Resv and ucast Path msgs
>
If memory serves, the omission of "->hop" was intentional and not meant to
be implied. Specifically, the intro section is just identifying the new
objects and defining how they differ. There may have been too much info on
the MCAST and SRC list object in this section as I wasn't trying to
generate any implementation rules/requirements at this point. Note there
are no MAY/MUST/SHOULD directives in this section.
> *> ...
> *>
> *> 5.2. Srefresh Message Format
> *>
> *> ...
> *>
> *> Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
> *> SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and
> *> MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh
> *> message. MESSAGE_ID SRC_LIST can not be combined in Srefresh
> *> messages with the other objects. A single Srefresh message MAY
> *> refresh both Path and Resv state.
> *>
> *> Srefresh messages carrying Message_Identifier fields corresponding to
> *> Path state are normally sent with a destination IP address equal to
> *> the address carried in the corresponding SESSION objects. The
> *> destination IP address MAY be set to the RSVP next hop when the next
> *> hop is known to be RSVP capable and either (a) the session is unicast
> *> or (b) the outgoing interface is a point-to-point link. Srefresh
> *> messages carrying Message_Identifier fields corresponding to Resv
> *> state MUST be sent with a destination IP address set to the Resv
> *> state's previous hop.
>
> B1) Path state "normally" -> G
>
> B2) Path state -> nhop IF direct neighbor and (ucast or pt-pt)
>
> B3) Resv state -> phop
>
>Now, B1) seems to directly contradict A1. A1 says ucast Path state is
>sent to nhop,
I believe this is an inference. I don't see A1 saying anything about where
the object is sent.
>B1) says it is normally sent to G, whatever "normally"
>means.
meaning is sent to G except when the subsequent sentence applies. I guess
I could have said something like "MUST except when ..." but that seems to
me more confusing.
>B2 is OK, noting the new condition of direct neighbor to be applied
>to A1) and A3), But it calls into question the "normally" in A3).
>
>B3) is consistent with A1')
I'm missing something. A1 doesn't say anything about destination and A1')
says hop. Where's the inconsistency?
> *>
> *> Srefresh messages sent to a multicast session's destination IP
> *> address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT
> *> include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects.
> *> Srefresh messages sent to the RSVP next hop MAY contain either or
> *> both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT
> *> include any MESSAGE_ID SRC_LIST objects.
>
>The paragraph above appears to be completly redundant with the two
>preceding paragraphs, hence can be ignored. Did I miss something?
No. I can't tell/remember if I was being overly specific or if the text
was added after a related question.
> *>
> *> ...
> *>
> *> 5.3. Srefresh Message Usage
> *>
> *> ...
> *>
> *> When generating an Srefresh message, there are two methods for
> *> identifying which Path state may be refreshed in a specific message.
> *> ...
> *> The primary method is to
> *> include only those sessions that share the same destination IP
> *> address in the same Srefresh message.
> *>
>
>NOte that this does not fit the ucast Path msgs in A1), since the
>Session dest G will not match the nhop address of the Srefresh message.
This matches B1.
>Hence MESSAGE_ID LIST objects will not be used except for the following
>"optimization".
If you meant MESSAGE_ID MCAST_LIST, I agree.
> *> The secondary method for identifying which Path state may be
> *> refreshed within a single Srefresh message is an optimization. This
> *> method MAY be used when the next hop is known to support RSVP and
> *> when either (a) the session is unicast or (b) the outgoing interface
> *> is a point-to-point link.
>
>But if A1 does not apply, neither do A2 or A3 for a unicast Path message.
>So this section has left me confused.
this matches B2.
> *> (Redundant sentence omitted)
>
> *> The use of this method MAY be administratively configured. When
> *> using this method, the destination address in the IP header of the
> *> Srefresh message is usually the next hop's address. When the use of
> *> this method is administratively configured, the destination address
> *> should be the well known group address 224.0.0.14. When the outgoing
> *> interface is a point-to-point link, all Path state associated with
> *> sessions advertised out the interface SHOULD be included in the same
> *> Srefresh message. When the outgoing interface is not a point-to-
> *> point link, all unicast session Path state SHOULD be included in the
> *> same Srefresh message.
>
>That appearance of the WK group address was something of a surprise here...
If I remember correctly this is something George brought in to reduce total
messages sent (at the expense of having to ignore some message IDs.)
George, can you add anything here?
>Otherwise, I could not figure out what the last two sentences actually mean.
>
> *>
> *> Identifying which Resv state may be refreshed within a single
> *> Srefresh message is based simply on the source and destination IP
> *> addresses. Any state that was previously advertised in Resv messages
> *> with the same IP addresses as an Srefresh message MAY be included.
> *>
> *>
>
>This is consistent with A1'), so that's OK.
>
>Bob
Lou
From rsvp-owner@ISI.EDU Tue Sep 12 04:48:24 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27639
for ; Tue, 12 Sep 2000 04:48:23 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id XAA17943
for rsvp-outgoing; Mon, 11 Sep 2000 23:51:51 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA17938
for ; Mon, 11 Sep 2000 23:51:50 -0700 (PDT)
Received: from ascomax.hasler.ascom.ch (ascomax.hasler.ascom.ch [139.79.129.2])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id XAA14646
for ; Mon, 11 Sep 2000 23:51:50 -0700 (PDT)
Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5])
by ascomax.hasler.ascom.ch (8.10.2/8.10.2) with ESMTP id e8C6plW21544
for ; Tue, 12 Sep 2000 08:51:47 +0200 (MET DST)
Received: from ascom.ch (localhost [127.0.0.1])
by stva195.pbx.ascom.ch (8.9.3/8.9.3) with ESMTP id IAA06210
for ; Tue, 12 Sep 2000 08:51:46 +0200 (MET DST)
Message-ID: <39BDD282.2633DD6A@ascom.ch>
Date: Tue, 12 Sep 2000 08:51:46 +0200
From: Dusan Sarvan
Organization: ASCOM Business Systems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: rsvp@ISI.EDU
Subject: Links for RSVP stack
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Filter-Version: 1.2 (ascomax)
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hi all,
I appreciate if someone can give me an information or advise
about the available RSVP stack you have experience or
information about.
I need to implement RSVP stack on the end user device such as
Phone Gateway.
Web address or/and e-mail are welcomed.
Thanks in advance.
Dusan.
From rsvp-owner@ISI.EDU Wed Sep 13 13:52:25 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14281
for ; Wed, 13 Sep 2000 13:52:23 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA22823
for rsvp-outgoing; Wed, 13 Sep 2000 09:12:16 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA22812
for ; Wed, 13 Sep 2000 09:12:13 -0700 (PDT)
Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA24352;
Wed, 13 Sep 2000 09:12:13 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
id ; Wed, 13 Sep 2000 09:15:22 -0700
Message-ID: <64DC8FA90382D411BA060090277AEE41774E53@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari
To: "'Mark Dewey'" , mpls@uu.net
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Wed, 13 Sep 2000 09:15:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi Mark,
For supporting Diffserv, a new Diffserv object/TLV is introduced for RSVP
and CR-LDP respectively in "MPLS support of Diffserv draft". In case of
RSVP, if the Diffserv object and the CoS object are not present the node
should implement Intserv, however, the presence of each one indicates
non-Intserv (Diffserv) implementation.
Regards,
-Shahram
-----Original Message-----
From: Mark Dewey [mailto:deweymark@hotmail.com]
Sent: Wednesday, August 30, 2000 1:55 PM
To: mpls@uu.net
Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
Subject: CR-LDP traffic parameter TLV and RSVP
Hi,
I apologize for the wide distribution. I am not sure which mailing list
this question belongs to.
I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of an LSP
tunnel can be specified in traffic parameter (e.g CDR) TLV.
How is this value specified in RSVP if it were used to establish a LSP
tunnel with qos characteristics?
If sender TSPEC object is used, should the node implement integrated
services (CL,GS)?
Thanks,
-Mark
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
From rsvp-owner@ISI.EDU Thu Sep 14 13:39:16 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19435
for ; Thu, 14 Sep 2000 13:39:16 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id IAA12637
for rsvp-outgoing; Thu, 14 Sep 2000 08:36:38 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA12632
for ; Thu, 14 Sep 2000 08:36:37 -0700 (PDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00349;
Thu, 14 Sep 2000 08:36:26 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id PAA02298;
Thu, 14 Sep 2000 15:36:26 GMT
Date: Thu, 14 Sep 2000 15:36:26 GMT
Message-Id: <200009141536.PAA02298@gra.isi.edu>
To: rsvp@ISI.EDU
Subject: Working Group Last Call
Cc: braden@ISI.EDU, lixia@cs.ucla.edu, andrew@extremenetworks.com,
mankin@ISI.EDU, sob@harvard.edu
X-Sun-Charset: US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Folks,
The IESG has requested that the following two RAP Internet Drafts receive
a working group last call from the RSVP Working Group. Please read them
and comment if there is a problem. You can direct your comments both to
rsvp@isi.edu and rap@iphighway.com.
Bob Braden & Lixia Zhang
_________________________________________________________________
> Reference:
> ----------
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-signaled-priority-v2-00
> .txt
>
> This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
> error in RFC 2751 and is intended to obsolete RFC 2751.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-newidentity-00.txt
>
> This memo corrects an editorial error in RFC 2752 and is intended
> to obsolete RFC 2752 upon IESG review and approval.
> This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
> error in RFC 2752. The PE type of AUTH_USER has been changed from
> 1 to 2 and AUTH_APP has been changed from 2 to 3.
>
>
>
From rsvp-owner@ISI.EDU Thu Sep 14 22:16:58 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29831
for ; Thu, 14 Sep 2000 22:16:58 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id RAA03368
for rsvp-outgoing; Thu, 14 Sep 2000 17:39:42 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA03363
for ; Thu, 14 Sep 2000 17:39:41 -0700 (PDT)
Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA10592
for ; Thu, 14 Sep 2000 17:39:43 -0700 (PDT)
From: RamMadhusudhan@aol.com
Received: from RamMadhusudhan@aol.com
by imo-d10.mx.aol.com (mail_out_v28.15.) id k.56.9efa68 (4585)
for ; Thu, 14 Sep 2000 20:39:11 -0400 (EDT)
Message-ID: <56.9efa68.26f2c9ae@aol.com>
Date: Thu, 14 Sep 2000 20:39:10 EDT
Subject: RSVP protocol
To: rsvp@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 5.0 for Windows sub 120
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello,
I have a doubt regarding the way RSVP protocol operates.
The way it is stated in RFC 2205 is that I repeat here which is,
RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages
to maintain the state along the reserved path(s). In the absence of refresh
messages, the state automatically times out and is deleted.
My understanding of the above is that for each path refresh message, there is
a refresh resv from the destination node and in the absence of a resv refresh
coming from the destination node, there will be a time out.
Pl. correct if my understanding is incorrect.
Thanks
RamMadhusudhan
From rsvp-owner@ISI.EDU Fri Sep 15 06:44:26 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17184
for ; Fri, 15 Sep 2000 06:44:25 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id BAA19891
for rsvp-outgoing; Fri, 15 Sep 2000 01:57:06 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA19886
for ; Fri, 15 Sep 2000 01:57:05 -0700 (PDT)
Received: from csa.iisc.ernet.in (IDENT:root@csa.iisc.ernet.in [144.16.67.8])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA16971
for ; Fri, 15 Sep 2000 01:56:48 -0700 (PDT)
Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46])
by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA16766;
Fri, 15 Sep 2000 14:25:33 +0530
Received: from localhost (prasanna@localhost)
by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id OAA03643;
Fri, 15 Sep 2000 14:26:25 +0530
X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs
Date: Fri, 15 Sep 2000 14:26:25 +0530 (IST)
From: Gaitonde Anandprasanna
To: RamMadhusudhan@aol.com
cc: rsvp@ISI.EDU
Subject: Re: RSVP protocol
In-Reply-To: <56.9efa68.26f2c9ae@aol.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Well not really,
The refresh messages of PATH and RESV are generated independently, once
the corresponding PATH and RESV state is installed in the devices.
Basically , U will generate refresh messages for both these states
independently and both the PATH and RESV state inside the devices will
aprropriately get refreshed.
When a node recieves a refresh PATH message , it will not
cause the generation of the corresponding RESV refresh message, but they
will be generated based on therir refresh timers.
ENJOY
PRAS
_____________________________
_ |ANANDPRASANNA GAITONDE | _
/ )|COMP. SCIENCE & AUTOMATION |( \
/ / |D-7,IISc HOSTEL | \ \
/ / |INDIAN INSTITUTE OF SCIENCE| \ \
_( (_ |BANGALORE-560012. | _) )_
(((\ \>|_/->___________________<-\_| /)))
(\\\\ \_/ /LAB Ph.(080)3092906 \ \_/ ////)
\ /HOSTEL Ph.- \ /
\ _/ (080)3092452 \_ /
/ /-----------------------------\ \
/ Email Id- \
/ prasanna@csa.iisc.ernet.in \
---------------------------------------------
-----------------------------------------------
--------------------------------------------------------------------------------
*************************************************************************
| | | | __ ___ _____ __ _ _ __ (_) ___ ___ __| | __ _ _ _
| |_| |/ _` \ \ / / _ \ / _` | | '_ \| |/ __/ _ \ / _` |/ _` | | | |
| _ | (_| |\ V / __/ | (_| | | | | | | (_| __/ | (_| | (_| | |_| |
|_| |_|\__,_| \_/ \___| \__,_| |_| |_|_|\___\___| \__,_|\__,_|\__, |
*************************************************************************
On Thu, 14 Sep 2000 RamMadhusudhan@aol.com wrote:
> Hello,
>
> I have a doubt regarding the way RSVP protocol operates.
>
> The way it is stated in RFC 2205 is that I repeat here which is,
>
> RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages
> to maintain the state along the reserved path(s). In the absence of refresh
> messages, the state automatically times out and is deleted.
>
> My understanding of the above is that for each path refresh message, there is
> a refresh resv from the destination node and in the absence of a resv refresh
> coming from the destination node, there will be a time out.
>
> Pl. correct if my understanding is incorrect.
>
> Thanks
> RamMadhusudhan
>
From rsvp-owner@ISI.EDU Fri Sep 15 14:20:33 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23488
for ; Fri, 15 Sep 2000 14:20:32 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id JAA04315
for rsvp-outgoing; Fri, 15 Sep 2000 09:14:50 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA04310
for ; Fri, 15 Sep 2000 09:14:48 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA12353
for ; Fri, 15 Sep 2000 09:14:36 -0700 (PDT)
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 MAA22708;
Fri, 15 Sep 2000 12:14:01 -0400 (EDT)
Received: from whq-msgrtr-01.fore.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 MAA15730;
Fri, 15 Sep 2000 12:14:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
id ; Fri, 15 Sep 2000 12:14:03 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFE495D1@whq-msgusr-02.pit.comms.marconi.com>
From: "Punj, Arun"
To: "'RamMadhusudhan@aol.com'" , rsvp@ISI.EDU
Subject: RE: RSVP protocol
Date: Fri, 15 Sep 2000 12:13:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="ISO-8859-1"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Your understanding is correct. However, your worry is the
refresh traffic, then please refer refresh reduction draft.
TL
> -----Original Message-----
> From: RamMadhusudhan@aol.com [mailto:RamMadhusudhan@aol.com]
> Sent: Thursday, September 14, 2000 8:39 PM
> To: rsvp@ISI.EDU
> Subject: RSVP protocol
>
>
> Hello,
>
> I have a doubt regarding the way RSVP protocol operates.
>
> The way it is stated in RFC 2205 is that I repeat here which is,
>
> RSVP establishes "soft" state; that is, RSVP sends periodic
> refresh messages
> to maintain the state along the reserved path(s). In the
> absence of refresh
> messages, the state automatically times out and is deleted.
>
> My understanding of the above is that for each path refresh
> message, there is
> a refresh resv from the destination node and in the absence
> of a resv refresh
> coming from the destination node, there will be a time out.
>
> Pl. correct if my understanding is incorrect.
>
> Thanks
> RamMadhusudhan
>
From rsvp-owner@ISI.EDU Fri Sep 15 22:09:48 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27834
for ; Fri, 15 Sep 2000 22:09:47 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA23463
for rsvp-outgoing; Fri, 15 Sep 2000 17:38:51 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA23458
for ; Fri, 15 Sep 2000 17:38:49 -0700 (PDT)
Received: from imo-r14.mx.aol.com (imo-r14.mx.aol.com [152.163.225.68])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA01945
for ; Fri, 15 Sep 2000 17:38:51 -0700 (PDT)
From: RamMadhusudhan@aol.com
Received: from RamMadhusudhan@aol.com
by imo-r14.mx.aol.com (mail_out_v28.15.) id e.3a.a65cfe4 (17084);
Fri, 15 Sep 2000 20:37:57 -0400 (EDT)
Message-ID: <3a.a65cfe4.26f41ae5@aol.com>
Date: Fri, 15 Sep 2000 20:37:57 EDT
Subject: Re: RSVP protocol
To: Arun.Punj@marconi.com, rsvp@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 5.0 for Windows sub 120
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Well, I have 2 different answers. My worry is not the refresh reduction but
"Is the refresh on the egress side is done for every path message or for a
timeout which is maintained separately, as Prasanna says.
Can the authors confirm this, since the RFC is not very clear at least for me.
Thanks
RamMadhu
From rsvp-owner@ISI.EDU Fri Sep 15 22:31:57 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28877
for ; Fri, 15 Sep 2000 22:31:56 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id RAA23966
for rsvp-outgoing; Fri, 15 Sep 2000 17:53:21 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id RAA23961
for ; Fri, 15 Sep 2000 17:53:19 -0700 (PDT)
Received: from kid.isi.edu (IDENT:root@kid.isi.edu [128.9.160.80])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id RAA05443
for ; Fri, 15 Sep 2000 17:53:21 -0700 (PDT)
Received: from localhost (berson@localhost)
by kid.isi.edu (8.9.3/8.9.3) with ESMTP id RAA31484;
Fri, 15 Sep 2000 17:53:15 -0700
X-Authentication-Warning: kid.isi.edu: berson owned process doing -bs
Date: Fri, 15 Sep 2000 17:53:14 -0700 (PDT)
From: Steven Berson
To: RamMadhusudhan@aol.com
cc: Arun.Punj@marconi.com, rsvp@ISI.EDU
Subject: Re: RSVP protocol
In-Reply-To: <3a.a65cfe4.26f41ae5@aol.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
On Fri, 15 Sep 2000 RamMadhusudhan@aol.com wrote:
> Well, I have 2 different answers. My worry is not the refresh reduction but
> "Is the refresh on the egress side is done for every path message or for a
> timeout which is maintained separately, as Prasanna says.
>
> Can the authors confirm this, since the RFC is not very clear at least for me.
>
> Thanks
> RamMadhu
Your question (repeated below) is not very well stated, but RFC 2205
is pretty clear on this. State (path or reservation) is refreshed
either when new state arrives or when an interval timer expires. Note
also that state times out if it is not refreshed over several time
intervals.
Steve
From: RamMadhusudhan@aol.com
Date: Thu, 14 Sep 2000 20:39:10 EDT
Subject: RSVP protocol
To: rsvp@ISI.EDU
Hello,
I have a doubt regarding the way RSVP protocol operates.
The way it is stated in RFC 2205 is that I repeat here which is,
RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages
to maintain the state along the reserved path(s). In the absence of refresh
messages, the state automatically times out and is deleted.
My understanding of the above is that for each path refresh message, there is
a refresh resv from the destination node and in the absence of a resv refresh
coming from the destination node, there will be a time out.
Pl. correct if my understanding is incorrect.
Thanks
RamMadhusudhan
From rsvp-owner@ISI.EDU Sat Sep 16 01:26:09 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02941
for ; Sat, 16 Sep 2000 01:26:08 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id UAA00196
for rsvp-outgoing; Fri, 15 Sep 2000 20:47:19 -0700 (PDT)
Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA00190
for ; Fri, 15 Sep 2000 20:47:18 -0700 (PDT)
Received: from 37.com (sdn-ar-003nynyorP291.dialsprint.net [168.191.122.157])
by gull.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id UAA17866
for ; Fri, 15 Sep 2000 20:47:18 -0700 (PDT)
Date: Fri, 15 Sep 2000 23:47:11 -0400
From: "flowergarden@37.com"
Organization: flowergarden@37.com
Reply-To: friendlyservice@bonbon.net
Message-ID:
To: rsvp@ISI.EDU
Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+
Choices! Up to $81.
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
With your first purchase of any size of any new or renewal subscription AT
OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay
us and will even go back 6 months later if you find a better deal and
refund you the difference!); customers living overseas pay only for FPH
(foreign postage & handling) on the free subscription.
FOR MORE INFO OR TO BE REMOVED FROM OUR MAILING LIST:
Just fill out the below form and return to us via email at:
friendlyservice@bonbon.net
Remove requests will be immediately honored and request for more
information will be fulfilled within 24 hours.
For more information, if you do not get a reply within 24 hours, then
please fax us at:
1-602-294-5643
or write us via smail at: or send via smail (first class mail or airmail)
to:
Tempting Tear-Outs
Att. Free-catalogue-by-email Dept
PMB 200
3835 Richmond Ave.
Staten Island NY 10312-3828
USA
When replying, your reply must include only this form*:
(*If you can't figure out how to cut and past this text, just type it out
in the same format):
*------------cut here/begin-------------------------------------------*
No thank you. Please remove me from your mailing list. My email address
is:
Yes, please send me more info. I realize I am not committing myself to
buying
anything at this time and I would just like more info on the offer and a
FREE copy
of your magazine subscription catalogue. Here are my details:
Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:
How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in): Referred by: Tempting
Tear-Outs
091300-ng
Name of USA mags you currently get on the newsstand or in the store:
Name of USA mags you currently get on a subscription basis, through the
mail:
Name of USA mags you would like price quotes on when we call you:
Catalogue version desired (list number of choice below):
*------------cut here/end--------------------------------------------*
CATALOGUE VERSION CHOICES:
1. This version can be read by everyone, no matter what type of
computer you use, or what type of software you use. It is a simple
format, with just our entire catalogue pasted into the body of a
single email message, 316K in size. If you use pine or elm on a unix
system or an advanced software version such as Eudora Pro 3.0 or
later, you will most likely receive it as a single email message.
However, if your software limits incoming email messages to a
certain size, say 32K or so, then your software will split it into
multiple email message parts. Whether you receive it as a single
email message or multiple part email messages, you can easily
paste it into one whole text document with your word processor, in
about 10 minutes or so.
2. For more advanced computer users: attached plain ascii text file
~316K - you must know how to download an attached text file and
then be able to locate it on your hard drive or system home
directory; it can then be opened with any pc or mac word processing
software. If in doubt, don't ask for this version. This isn't for
internet *newbies.* Better to order option 1 and spend a few minutes
pasting them into one whole text document with your word processor,
than to waste hours trying to figure how to deal with this option.
This version is great for doing keyword searches and jumping around
within the catalogue with your word processing software, if your
normal email reading software doesn't allow this.
WHO WE ARE:
Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:
The company making the offer is a magazine subscription agency based in the
USA. They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA! They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time. The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $50.00!
For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free! For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).
Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented. They will even help you with
address changes on your magazines, even if you move from one country to
another country. They have thousands of happy customers in over 59
countries.
Their price guarantee is very simple: they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer. Does that
sound fair? Wouldn't it be great if everything you bought came with
that price guarantee?
Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around. With 1,100+ titles on their list, they
would like to think that they have also the best selection around!
Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves. This is their price
guarantee. The 1 yr. freebie that you get with your first order is
completely free!
Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines. On some titles they
are as little as one-tenth of what the newsstands charge. They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves! Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty! They feel that magazines should not be a luxury
overseas. In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours. They are so cheap in the
USA! Well, this company would like to make it the same way for their
overseas customers. They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves! It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines! But that is what this company specializes in and loves
doing! Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language. Subscription prices quoted for overseas consist of the
subscription price, plus the FPH. You add the two together and that is
your total cost. The exception is the 1 yr. freebie you get with your
first order. On that title, you pay *only* the FPH for the 1 yr. term.
Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.
HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:
Simply email or fax or smail back to us the reply form listed at the top of
this message. We will then forward your form on to the subscription
agency. They will then email their "big and juicy" catalogue to you, in
whichever of the two formats you chose. The catalogue is FREE and makes
for hours of fascinating reading, on its own. It includes the complete list
of freebies, a complete list of all the titles they sell, as well as
detailed descriptions on most of the titles, along with lists of titles by
category of interest and their terms of sale.
They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering. They will call you in whatever country you live
in, taking the time difference into account. As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally. Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.
Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche. Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).
That's our introduction of our client that we represent. We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue! Thank you for your time and interest.
--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to: Tempting Tear-Outs,
PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828, USA.
This email message has been sent to you by: Tempting Tear-Outs, PMB 200,
3835 Richmond Ave., Staten Island NY 10312-3828, USA.
From rsvp-owner@ISI.EDU Sun Sep 17 10:28:13 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09337
for ; Sun, 17 Sep 2000 10:28:12 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id FAA24703
for rsvp-outgoing; Sun, 17 Sep 2000 05:41:47 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA24697
for ; Sun, 17 Sep 2000 05:41:45 -0700 (PDT)
Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.5])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id FAA21348;
Sun, 17 Sep 2000 05:41:48 -0700 (PDT)
From: RamMadhusudhan@aol.com
Received: from RamMadhusudhan@aol.com
by imo-r05.mx.aol.com (mail_out_v28.15.) id k.b1.a9a6c2 (4200);
Sun, 17 Sep 2000 08:41:13 -0400 (EDT)
Message-ID:
Date: Sun, 17 Sep 2000 08:41:12 EDT
Subject: Re: RSVP protocol
To: berson@ISI.EDU
CC: Arun.Punj@marconi.com, rsvp@ISI.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 5.0 for Windows sub 120
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello Berson,
Thanks very much for your reply. I am sorry if my wording is not clear.
Pl. refer to the Section 2.3 of RFC 2205 where it is stated that,
RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and
periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval.
By this I understand since it is explicitly stated above that the state is
deleted if no matching refresh messages arrive before the expiration ...
Further, I wish to say that I am now involved in testing an implementation
which sends path & resv refresh messages and occasionally I see a resv
refresh going on the network for no path message. Now, my doubt is whether
this is correct. According to what you say it is correct.
I am sorry to trouble you but for me still the RFC is not clear. Let me know
if I miss something.
Thanks
Ram
From rsvp-owner@ISI.EDU Mon Sep 18 13:15:42 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15192
for ; Mon, 18 Sep 2000 13:15:42 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA09930
for rsvp-outgoing; Mon, 18 Sep 2000 07:24:01 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA09925
for ; Mon, 18 Sep 2000 07:24:00 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA29931
for ; Mon, 18 Sep 2000 07:23:58 -0700 (PDT)
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 KAA20903
for ; Mon, 18 Sep 2000 10:23:25 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17474
for ; Mon, 18 Sep 2000 10:23:25 -0400 (EDT)
Message-ID: <39C6258F.9233EBE4@marconi.com>
Date: Mon, 18 Sep 2000 10:24:15 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: rsvp@ISI.EDU
Subject: Re: RSVP protocol
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
RamMadhusudhan@aol.com wrote:
>
>
> Further, I wish to say that I am now involved in testing an
> implementation which sends path & resv refresh messages and
> occasionally I see a resv refresh going on the network for no path
> message. Now, my doubt is whether this is correct. According to what
> you say it is correct.
A Resv message is legal at any time, as long as its session exists on
the switch that receives the message. If the Resv message is identical
to a previously-sent Resv message, then it is a refresh. If it is
different, then it may cause state changes in the Phop router, which may
result in it changing the Resv message that it sends out.
-- David
From rsvp-owner@ISI.EDU Mon Sep 18 17:24:50 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20073
for ; Mon, 18 Sep 2000 17:24:50 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA22761
for rsvp-outgoing; Mon, 18 Sep 2000 12:36:08 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA22756
for ; Mon, 18 Sep 2000 12:36:07 -0700 (PDT)
Received: from coltrane.dataconnection.com (smtp.datcon.co.uk [192.91.191.4])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id MAA00357
for ; Mon, 18 Sep 2000 12:36:04 -0700 (PDT)
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
id ; Mon, 18 Sep 2000 20:35:21 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA1FB@monk.datcon.co.uk>
From: Adrian Farrel
To: rsvp@ISI.EDU
Subject: RSVP Hop on PathErr
Date: Mon, 18 Sep 2000 20:35:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi,
I've been polling around a bit privately but had no luck.
Can any of you with long memories recall why PathErr does not contain the
RSVP Hop object? Is it as simple as the fact that sometimes (rarely?) the
node sending the PathErr is not the node identified in the RSVP Hop on the
Path?
All thoughts appreciated.
TIA
Adrian
--
Adrian Farrel mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422
From rsvp-owner@ISI.EDU Mon Sep 18 18:21:56 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20701
for ; Mon, 18 Sep 2000 18:21:55 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id NAA25268
for rsvp-outgoing; Mon, 18 Sep 2000 13:33:08 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA25263
for ; Mon, 18 Sep 2000 13:33:06 -0700 (PDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA04471;
Mon, 18 Sep 2000 13:33:06 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id UAA09130;
Mon, 18 Sep 2000 20:33:06 GMT
Date: Mon, 18 Sep 2000 20:33:06 GMT
Message-Id: <200009182033.UAA09130@gra.isi.edu>
To: rsvp@ISI.EDU, AF@dataconnection.com
Subject: Re: RSVP Hop on PathErr
X-Sun-Charset: US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
*> From rsvp-owner@ISI.EDU Mon Sep 18 12:39:31 2000
*> From: Adrian Farrel
*> To: rsvp@ISI.EDU
*> Subject: RSVP Hop on PathErr
*> Date: Mon, 18 Sep 2000 20:35:08 +0100
*> MIME-Version: 1.0
*> X-Mailer: Internet Mail Service (5.5.2650.21)
*> Sender: owner-rsvp@ISI.EDU
*> Precedence: bulk
*> X-Lines: 19
*>
*> Hi,
*>
*> I've been polling around a bit privately but had no luck.
*>
*> Can any of you with long memories recall why PathErr does not contain the
*> RSVP Hop object? Is it as simple as the fact that sometimes (rarely?) the
*> node sending the PathErr is not the node identified in the RSVP Hop on the
*> Path?
*>
Mainly, I believe, because a Hop object would serve no function in
a PathErr message. It seemed simpler to leave it out than to put it
in and have to explain that it was not useful. (Se, here I am
explaining anyway! ;-) )
The HOP object in a Resv message carries the LIH and next hop address
for merging reservations and putting them on the correct outgoing
interface. PathErr messages are not merged and do not care about
outgoing interfaces.
Bob Braden
*> All thoughts appreciated.
*>
*> TIA
*> Adrian
*> --
*> Adrian Farrel mailto:af@datcon.co.uk
*> Network Convergence Group
*> Data Connection Ltd., Chester, UK
*> http://www.datcon.co.uk/
*> Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422
*>
From rsvp-owner@ISI.EDU Mon Sep 18 18:46:03 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20988
for ; Mon, 18 Sep 2000 18:46:02 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA26528
for rsvp-outgoing; Mon, 18 Sep 2000 13:59:44 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA26523
for ; Mon, 18 Sep 2000 13:59:43 -0700 (PDT)
Received: from coltrane.dataconnection.com (smtp.datcon.co.uk [192.91.191.4])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA23226;
Mon, 18 Sep 2000 13:59:44 -0700 (PDT)
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
id ; Mon, 18 Sep 2000 21:59:04 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA205@monk.datcon.co.uk>
From: Adrian Farrel
To: Bob Braden , rsvp@ISI.EDU
Subject: RE: RSVP Hop on PathErr
Date: Mon, 18 Sep 2000 21:58:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Bob,
Thanks for a speedy response.
I guess that leaves it up to the MPLS WG, who are generally
munching RSVP, anyway to add RSVP_HOP to PathErr if they
believe they have a use for it.
FYI, GMPLS raises the specter of reserving resources on the
forward path and so it may be important to be able to get
back to the correct interface (using LIH) if the Path setup
fails.
Regards,
Adrian
--
Adrian Farrel mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422
>-----Original Message-----
>From: Bob Braden [mailto:braden@ISI.EDU]
>Sent: Monday, September 18, 2000 9:33 PM
>To: rsvp@ISI.EDU; Adrian Farrel
>Subject: Re: RSVP Hop on PathErr
>
>
>
> *> From rsvp-owner@ISI.EDU Mon Sep 18 12:39:31 2000
> *> From: Adrian Farrel
> *> To: rsvp@ISI.EDU
> *> Subject: RSVP Hop on PathErr
> *> Date: Mon, 18 Sep 2000 20:35:08 +0100
> *> MIME-Version: 1.0
> *> X-Mailer: Internet Mail Service (5.5.2650.21)
> *> Sender: owner-rsvp@ISI.EDU
> *> Precedence: bulk
> *> X-Lines: 19
> *>
> *> Hi,
> *>
> *> I've been polling around a bit privately but had no luck.
> *>
> *> Can any of you with long memories recall why PathErr does
> *> not contain the RSVP Hop object? Is it as simple as the
> *> fact that sometimes (rarely?) the node sending the PathErr
> *> is not the node identified in the RSVP Hop on the Path?
>
>Mainly, I believe, because a Hop object would serve no function in
>a PathErr message. It seemed simpler to leave it out than to put it
>in and have to explain that it was not useful. (Se, here I am
>explaining anyway! ;-) )
>
>The HOP object in a Resv message carries the LIH and next hop address
>for merging reservations and putting them on the correct outgoing
>interface. PathErr messages are not merged and do not care about
>outgoing interfaces.
>
>Bob Braden
>
> *> All thoughts appreciated.
> *>
> *> TIA
> *> Adrian
> *> --
> *> Adrian Farrel mailto:af@datcon.co.uk
> *> Network Convergence Group
> *> Data Connection Ltd., Chester, UK
> *> http://www.datcon.co.uk/
> *> Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422
> *>
>
From rsvp-owner@ISI.EDU Mon Sep 18 19:25:23 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21450
for ; Mon, 18 Sep 2000 19:25:22 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id OAA29026
for rsvp-outgoing; Mon, 18 Sep 2000 14:52:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA29021
for ; Mon, 18 Sep 2000 14:52:14 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
by gamma.isi.edu (8.9.3/8.9.3) with SMTP id OAA09404
for ; Mon, 18 Sep 2000 14:52:03 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Sep 18 17:51:28 EDT 2000
Received: from research.bell-labs.com (hamster [135.180.240.129])
by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA21986;
Mon, 18 Sep 2000 17:51:26 -0400 (EDT)
Message-ID: <39C68D67.48690CEA@research.bell-labs.com>
Date: Mon, 18 Sep 2000 17:47:19 -0400
From: Ping Pan
Organization: Bell Labs, Lucent
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Farrel
CC: rsvp@ISI.EDU
Subject: Re: RSVP Hop on PathErr
References: <6DEA508A9A0ED31192E80000F6CC176E2CA205@monk.datcon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Adrian,
Why do you need RSVP_HOP in MPLS? The sender knows exactly where the
error spot is from the EXPLICIT_ROUTE object, which is generated by the
sender itself. Plus, you can always extend the ERROR_SPEC to include any
useful information such as LIH, right?
- Ping
Adrian Farrel wrote:
>
> Bob,
>
> Thanks for a speedy response.
>
> I guess that leaves it up to the MPLS WG, who are generally
> munching RSVP, anyway to add RSVP_HOP to PathErr if they
> believe they have a use for it.
>
> FYI, GMPLS raises the specter of reserving resources on the
> forward path and so it may be important to be able to get
> back to the correct interface (using LIH) if the Path setup
> fails.
>
> Regards,
> Adrian
From rsvp-owner@ISI.EDU Tue Sep 19 06:53:15 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11643
for ; Tue, 19 Sep 2000 06:53:14 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id BAA19882
for rsvp-outgoing; Tue, 19 Sep 2000 01:45:56 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id BAA19877
for ; Tue, 19 Sep 2000 01:45:55 -0700 (PDT)
Received: from coltrane.dataconnection.com (smtp.datcon.co.uk [192.91.191.4])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id BAA28940
for ; Tue, 19 Sep 2000 01:45:58 -0700 (PDT)
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
id ; Tue, 19 Sep 2000 09:45:16 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A3349@monk.datcon.co.uk>
From: Adrian Farrel
To: Ping Pan
Cc: rsvp@ISI.EDU
Subject: RE: RSVP Hop on PathErr
Date: Tue, 19 Sep 2000 09:45:03 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Thanks Ping,
Yes you're right, the information (i.e. LIH) could be carried in other
fields by extending them. However, we already have an object for exactly
this purpose and something of a lack of symmetry by leaving it out of
PathErr.
wrt to ERO, I don't think this tells us the next hop at all. It will tell
us the direction in which to route, but that's all.
Regards,
Adrian
--
Adrian Farrel mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422
>-----Original Message-----
>From: Ping Pan [mailto:pingpan@research.bell-labs.com]
>Sent: Monday, September 18, 2000 10:47 PM
>To: Adrian Farrel
>Cc: rsvp@ISI.EDU
>Subject: Re: RSVP Hop on PathErr
>
>
>Adrian,
>
>Why do you need RSVP_HOP in MPLS? The sender knows exactly where the
>error spot is from the EXPLICIT_ROUTE object, which is generated by the
>sender itself. Plus, you can always extend the ERROR_SPEC to
>include any useful information such as LIH, right?
>
>- Ping
>
>Adrian Farrel wrote:
>>
>> Bob,
>>
>> Thanks for a speedy response.
>>
>> I guess that leaves it up to the MPLS WG, who are generally
>> munching RSVP, anyway to add RSVP_HOP to PathErr if they
>> believe they have a use for it.
>>
>> FYI, GMPLS raises the specter of reserving resources on the
>> forward path and so it may be important to be able to get
>> back to the correct interface (using LIH) if the Path setup
>> fails.
>>
>> Regards,
>> Adrian
>
From rsvp-owner@ISI.EDU Tue Sep 19 08:46:03 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14248
for ; Tue, 19 Sep 2000 08:46:02 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA23767
for rsvp-outgoing; Tue, 19 Sep 2000 03:56:52 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA23762
for ; Tue, 19 Sep 2000 03:56:50 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id DAA22165
for ; Tue, 19 Sep 2000 03:56:53 -0700 (PDT)
Received: from who ([12.78.193.222]) by mtiwmhc21.worldnet.att.net
(InterMail vM.4.01.02.39 201-229-119-122) with SMTP
id <20000919105616.HHYL17935.mtiwmhc21.worldnet.att.net@who>
for ; Tue, 19 Sep 2000 10:56:16 +0000
From: "Gregg C Levine"
To: "Rsvp"
Subject: What form for the RSVP conventions is it on Windows?
Date: Tue, 19 Sep 2000 06:57:00 -0400
Message-ID:
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.4133.2400
Importance: Normal
Disposition-Notification-To: "Gregg C Levine"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello again from Gregg C Levine usually with Jedi knight Computers
What form does the implementation for RSVP on Windows, take? Now let me get
this straight, from a previous discussion, I know that Windows 2000 contains
the entire suite of implementations for Windows based networking. (Current
when that build of Win2000 went to the pressing stage!) But what is found on
Windows 98? I know that there is something there in the form of an
executable called RSVP.exe, but that is it.
----
Gregg C Levine mailto:hansolofalcon@worldnet.att.net
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke." Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi (Perhaps the
most powerful of all of the Jedi Knights))
From rsvp-owner@ISI.EDU Tue Sep 19 15:26:27 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23403
for ; Tue, 19 Sep 2000 15:26:26 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id KAA06291
for rsvp-outgoing; Tue, 19 Sep 2000 10:24:50 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA06286
for ; Tue, 19 Sep 2000 10:24:49 -0700 (PDT)
Received: from ascomax.hasler.ascom.ch (ascomax.hasler.ascom.ch [139.79.129.2])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18757
for ; Tue, 19 Sep 2000 10:24:50 -0700 (PDT)
Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5])
by ascomax.hasler.ascom.ch (8.10.2/8.10.2) with ESMTP id e8JHOkW24014
for ; Tue, 19 Sep 2000 19:24:46 +0200 (MET DST)
Received: from ascom.ch (localhost [127.0.0.1])
by stva195.pbx.ascom.ch (8.9.3/8.9.3) with ESMTP id TAA17043
for ; Tue, 19 Sep 2000 19:24:46 +0200 (MET DST)
Message-ID: <39C7A15D.D56E16BB@ascom.ch>
Date: Tue, 19 Sep 2000 19:24:45 +0200
From: Dusan Sarvan
Organization: ASCOM Business Systems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: rsvp@ISI.EDU
Subject: RSVP PathError and ResvError messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Filter-Version: 1.2 (ascomax)
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hi,
I am considering to use RSVP as a signaling protocol at the end user
side
(telephone Gateway).
I've studied carefully RFC 2205 spec, but there is a point where I am
not
completely clear from the end user prospective. So if some of you
clarify
the following questions, I will be really appreciated.
1. Let's consider the following scenario:
SENDER ---> Router_1 ---> Router_2 ---> Router_N ---> RECEIVER
a) Sender sends PATH message which is processed by the "admission
control" and
"process control" modules on each router downstream along a data path.
If the
PATH message fails some of these controls, PathError message will be
generated
and sent back to the SENDER. So SENDER will examine ERROR_SPEC object
and
will know what has caused the fail of reservation process. This is clear
to me, so there
is no question about this.
b) If RESV message sent from the RECEIVER fails "admission control" or
"process control" on some of the routers, ResvError message will be sent
to the
RECEIVER. In this case the SENDER will never receive the RESV message
and will
never know what has caused the fail, for example no enough bandwidth,
PATH or RESV
messages are lost somewhere between SENDER and RECEIVER due to the
unreliable
delivery mechanism of these messages, or something else.
QUESTION: How to handle this case on the SENDER side? Whether to setup
time out for
the RESV message at the time of sending the PATH message, or to use some
other RSVP
mechanism which I probably have not read correctly in the RFC spec?
Should gateway try to repeat this process once more by sending new
PATH message, or
to start sending data packets with unreserved bandwidth (?????), or to
refuse the call setup
and to play busy tone?
c) This question relates probably more to the Policy and Network
Management then to
the RSVP problem, but probably someone can answer.
SENDER and RECEIVER are connected to the routers which belong to the
different
network domains or ISPs. SENDER is RSVP capable, RECEIVER doesn't
support RSVP.
QUESTION: How SENDER knows RECEIVER's RSVP capabilities? It will
retrieve that
information from the Policy /Network Manager
OR
SENDER will initiate the RSVP signaling without having any knowledge
about RECEIVERS
RSVP capabilities, with setting time out for the RESV message? After
this time out (RESV has
not been received - RECEIVER is not RSVP capable, or PATH/RESV are
lost), SENDER
will start sending traffic with unreserved bandwidth?
Thank you very much for your time, and I appreciate your answers in
advance.
Dusan Sarvan
SW Designer
Ascom Business Systems AG
Switzerland
From rsvp-owner@ISI.EDU Tue Sep 19 15:35:55 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23542
for ; Tue, 19 Sep 2000 15:35:55 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id KAA06893
for rsvp-outgoing; Tue, 19 Sep 2000 10:39:39 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA06888
for ; Tue, 19 Sep 2000 10:39:38 -0700 (PDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01536;
Tue, 19 Sep 2000 10:39:38 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id RAA09591;
Tue, 19 Sep 2000 17:39:38 GMT
Date: Tue, 19 Sep 2000 17:39:38 GMT
Message-Id: <200009191739.RAA09591@gra.isi.edu>
To: rsvp@ISI.EDU, Dusan.Sarvan@ascom.ch
Subject: Re: RSVP PathError and ResvError messages
X-Sun-Charset: US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
*> From rsvp-owner@ISI.EDU Tue Sep 19 10:28:30 2000
*> Date: Tue, 19 Sep 2000 19:24:45 +0200
*> From: Dusan Sarvan
*> Organization: ASCOM Business Systems
*> X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
*> X-Accept-Language: en
*> MIME-Version: 1.0
*> To: rsvp@ISI.EDU
*> Subject: RSVP PathError and ResvError messages
*> Content-Transfer-Encoding: 7bit
*> X-Filter-Version: 1.2 (ascomax)
*> Sender: owner-rsvp@ISI.EDU
*> Precedence: bulk
*> X-Lines: 78
*>
*> Hi,
*>
*> I am considering to use RSVP as a signaling protocol at the end user
*> side
*> (telephone Gateway).
*> I've studied carefully RFC 2205 spec, but there is a point where I am
*> not
*> completely clear from the end user prospective. So if some of you
*> clarify
*> the following questions, I will be really appreciated.
*>
*> 1. Let's consider the following scenario:
*>
*> SENDER ---> Router_1 ---> Router_2 ---> Router_N ---> RECEIVER
*>
*> a) Sender sends PATH message which is processed by the "admission
*> control" and
*> "process control" modules on each router downstream along a data path.
No. RSVP makes reservations from the receiver end. That is why the
upstream message is called Resv! Admission control and process control
(which are collectively called traffic control in RSVP) are not invoked
for Path messages.
*> If the
*> PATH message fails some of these controls, PathError message will be
*> generated
In fact, failure of a Path message should be a very rare event.
*> and sent back to the SENDER. So SENDER will examine ERROR_SPEC object
*> and
*> will know what has caused the fail of reservation process. This is clear
*> to me, so there
*> is no question about this.
*>
But wrong, in fact.
*> b) If RESV message sent from the RECEIVER fails "admission control" or
*> "process control" on some of the routers, ResvError message will be sent
*> to the
*> RECEIVER. In this case the SENDER will never receive the RESV message
*> and will
*> never know what has caused the fail, for example no enough bandwidth,
*> PATH or RESV
*> messages are lost somewhere between SENDER and RECEIVER due to the
*> unreliable
*> delivery mechanism of these messages, or something else.
Why does the sender care what caused it to fail? Isn't it sufficient
to know that the Resv message never arrived? In any case, we expect
there is an application-layer protocol that will carry such information
if it is relevant. In the multicast case, the sender probably does not
want to know about failures of some receiver reservations; it would
not scale.
*>
*> QUESTION: How to handle this case on the SENDER side? Whether to setup
*> time out for
*> the RESV message at the time of sending the PATH message, or to use some
*> other RSVP
*> mechanism which I probably have not read correctly in the RFC spec?
*> Should gateway try to repeat this process once more by sending new
*> PATH message, or
The nodes along the path will continue trying to send Path and Resv
messages until the end systems stop refreshing or explicitly tear down
the state in place.
*> to start sending data packets with unreserved bandwidth (?????), or to
*> refuse the call setup
*> and to play busy tone?
*>
*> c) This question relates probably more to the Policy and Network
*> Management then to
*> the RSVP problem, but probably someone can answer.
*>
*> SENDER and RECEIVER are connected to the routers which belong to the
*> different
*> network domains or ISPs. SENDER is RSVP capable, RECEIVER doesn't
*> support RSVP.
I answered this same question on another list recently. Why doesn't
the receiver support RSVP? I think the question is broken. I wonder
how you would do Web access if one end does not support TCP or HTTP?
Bob Braden
*>
*> QUESTION: How SENDER knows RECEIVER's RSVP capabilities? It will
*> retrieve that
*> information from the Policy /Network Manager
*> OR
*> SENDER will initiate the RSVP signaling without having any knowledge
*> about RECEIVERS
*> RSVP capabilities, with setting time out for the RESV message? After
*> this time out (RESV has
*> not been received - RECEIVER is not RSVP capable, or PATH/RESV are
*> lost), SENDER
*> will start sending traffic with unreserved bandwidth?
*>
*> Thank you very much for your time, and I appreciate your answers in
*> advance.
*>
*> Dusan Sarvan
*> SW Designer
*> Ascom Business Systems AG
*> Switzerland
*>
*>
From rsvp-owner@ISI.EDU Tue Sep 19 16:10:46 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24054
for ; Tue, 19 Sep 2000 16:10:45 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id LAA08054
for rsvp-outgoing; Tue, 19 Sep 2000 11:06:25 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA08048
for ; Tue, 19 Sep 2000 11:06:23 -0700 (PDT)
Received: from ascomax.hasler.ascom.ch (ascomax.hasler.ascom.ch [139.79.129.2])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA00781;
Tue, 19 Sep 2000 11:06:24 -0700 (PDT)
Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5])
by ascomax.hasler.ascom.ch (8.10.2/8.10.2) with ESMTP id e8JI6LW25489;
Tue, 19 Sep 2000 20:06:21 +0200 (MET DST)
Received: from ascom.ch (localhost [127.0.0.1])
by stva195.pbx.ascom.ch (8.9.3/8.9.3) with ESMTP id UAA20644;
Tue, 19 Sep 2000 20:06:20 +0200 (MET DST)
Message-ID: <39C7AB1C.8B6E401@ascom.ch>
Date: Tue, 19 Sep 2000 20:06:20 +0200
From: Dusan Sarvan
Organization: ASCOM Business Systems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Braden
CC: rsvp@ISI.EDU, Dusan.Sarvan@ascom.ch
Subject: Re: RSVP PathError and ResvError messages
References: <200009191739.RAA09591@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Filter-Version: 1.2 (ascomax)
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Bob Braden wrote:
> *> From rsvp-owner@ISI.EDU Tue Sep 19 10:28:30 2000
> *> Date: Tue, 19 Sep 2000 19:24:45 +0200
> *> From: Dusan Sarvan
> *> Organization: ASCOM Business Systems
> *> X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
> *> X-Accept-Language: en
> *> MIME-Version: 1.0
> *> To: rsvp@ISI.EDU
> *> Subject: RSVP PathError and ResvError messages
> *> Content-Transfer-Encoding: 7bit
> *> X-Filter-Version: 1.2 (ascomax)
> *> Sender: owner-rsvp@ISI.EDU
> *> Precedence: bulk
> *> X-Lines: 78
> *>
> *> Hi,
> *>
> *> I am considering to use RSVP as a signaling protocol at the end user
> *> side
> *> (telephone Gateway).
> *> I've studied carefully RFC 2205 spec, but there is a point where I am
> *> not
> *> completely clear from the end user prospective. So if some of you
> *> clarify
> *> the following questions, I will be really appreciated.
> *>
> *> 1. Let's consider the following scenario:
> *>
> *> SENDER ---> Router_1 ---> Router_2 ---> Router_N ---> RECEIVER
> *>
> *> a) Sender sends PATH message which is processed by the "admission
> *> control" and
> *> "process control" modules on each router downstream along a data path.
>
> No. RSVP makes reservations from the receiver end. That is why the
> upstream message is called Resv! Admission control and process control
> (which are collectively called traffic control in RSVP) are not invoked
> for Path messages.
>
> *> If the
> *> PATH message fails some of these controls, PathError message will be
> *> generated
>
> In fact, failure of a Path message should be a very rare event.
>
> *> and sent back to the SENDER. So SENDER will examine ERROR_SPEC object
> *> and
> *> will know what has caused the fail of reservation process. This is clear
> *> to me, so there
> *> is no question about this.
> *>
>
> But wrong, in fact.
>
> *> b) If RESV message sent from the RECEIVER fails "admission control" or
> *> "process control" on some of the routers, ResvError message will be sent
> *> to the
> *> RECEIVER. In this case the SENDER will never receive the RESV message
> *> and will
> *> never know what has caused the fail, for example no enough bandwidth,
> *> PATH or RESV
> *> messages are lost somewhere between SENDER and RECEIVER due to the
> *> unreliable
> *> delivery mechanism of these messages, or something else.
>
> Why does the sender care what caused it to fail? Isn't it sufficient
> to know that the Resv message never arrived? In any case, we expect
> there is an application-layer protocol that will carry such information
> if it is relevant. In the multicast case, the sender probably does not
> want to know about failures of some receiver reservations; it would
> not scale.
>
> *>
> *> QUESTION: How to handle this case on the SENDER side? Whether to setup
> *> time out for
> *> the RESV message at the time of sending the PATH message, or to use some
> *> other RSVP
> *> mechanism which I probably have not read correctly in the RFC spec?
> *> Should gateway try to repeat this process once more by sending new
> *> PATH message, or
>
> The nodes along the path will continue trying to send Path and Resv
> messages until the end systems stop refreshing or explicitly tear down
> the state in place.
>
> *> to start sending data packets with unreserved bandwidth (?????), or to
> *> refuse the call setup
> *> and to play busy tone?
> *>
> *> c) This question relates probably more to the Policy and Network
> *> Management then to
> *> the RSVP problem, but probably someone can answer.
> *>
> *> SENDER and RECEIVER are connected to the routers which belong to the
> *> different
> *> network domains or ISPs. SENDER is RSVP capable, RECEIVER doesn't
> *> support RSVP.
>
> I answered this same question on another list recently. Why doesn't
> the receiver support RSVP? I think the question is broken. I wonder
> how you would do Web access if one end does not support TCP or HTTP?
>
> Bob Braden
>
> *>
> *> QUESTION: How SENDER knows RECEIVER's RSVP capabilities? It will
> *> retrieve that
> *> information from the Policy /Network Manager
> *> OR
> *> SENDER will initiate the RSVP signaling without having any knowledge
> *> about RECEIVERS
> *> RSVP capabilities, with setting time out for the RESV message? After
> *> this time out (RESV has
> *> not been received - RECEIVER is not RSVP capable, or PATH/RESV are
> *> lost), SENDER
> *> will start sending traffic with unreserved bandwidth?
> *>
> *> Thank you very much for your time, and I appreciate your answers in
> *> advance.
> *>
> *> Dusan Sarvan
> *> SW Designer
> *> Ascom Business Systems AG
> *> Switzerland
> *>
> *>
Hi Bob,
Thank you very much for your quick answer.
Could you clarify please the last point you answered.
SENDER - RSVP capable,
RECEIVER (older version of the telephone GW) - doesn't support RSVP.
This is a real situation in today's networks, that we have a telephone
Gateways which support RSVP and gateways which doesn't support RSVP.
Let's say we have a SENDER telephone GW in New York which supports RSVP
and RECEIVER telephone GW in Geneva which doesn't support RSVP.
How to handle this case?
This clarification is very important to me. Thanks a lot in advance.
Best regards,
Dusan Sarvan
From rsvp-owner@ISI.EDU Tue Sep 19 19:02:19 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26177
for ; Tue, 19 Sep 2000 19:02:19 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id NAA14502
for rsvp-outgoing; Tue, 19 Sep 2000 13:56:29 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA14497
for ; Tue, 19 Sep 2000 13:56:28 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA16942
for ; Tue, 19 Sep 2000 13:56:31 -0700 (PDT)
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 QAA21861
for ; Tue, 19 Sep 2000 16:55:58 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24475
for ; Tue, 19 Sep 2000 16:55:58 -0400 (EDT)
Message-ID: <39C7D2DA.434C7C2C@marconi.com>
Date: Tue, 19 Sep 2000 16:55:54 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: rsvp@ISI.EDU
Subject: Re: RSVP PathError and ResvError messages
References: <200009191739.RAA09591@gra.isi.edu> <39C7AB1C.8B6E401@ascom.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Dusan Sarvan wrote:
>
> Thank you very much for your quick answer.
> Could you clarify please the last point you answered.
>
> SENDER - RSVP capable,
> RECEIVER (older version of the telephone GW) - doesn't support RSVP.
>
> This is a real situation in today's networks, that we have a telephone
> Gateways which support RSVP and gateways which doesn't support RSVP.
>
> Let's say we have a SENDER telephone GW in New York which supports
> RSVP and RECEIVER telephone GW in Geneva which doesn't support RSVP.
> How to handle this case?
It seems pretty obvious to me.
In this situation, RSVP will not be able to signal QoS along the entire
path.
You could probably set up a router close to the Geneva GW to signal RSVP
to the New York GW. This will allow QoS to be reserved between the New
York GW and that router. But there will still be no reservations between
that router and the Geneva GW. It will probably require customizations
to the router's code in order to work. (Similar customizations are
being made in routers that use RSVP to signal MPLS tunels.)
Doing so, however, will restrict the kind of reservations that may be
made. Such a router will have to attempt to reserve the specific
resources in the sender's TSpec. Or it will have to have application-
aware knowledge, in order to intelligently choose some other
reservation.
-- David
From rsvp-owner@ISI.EDU Wed Sep 20 11:24:20 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24875
for ; Wed, 20 Sep 2000 11:24:20 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA20885
for rsvp-outgoing; Wed, 20 Sep 2000 06:28:05 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA20880
for ; Wed, 20 Sep 2000 06:28:03 -0700 (PDT)
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA04888
for ; Wed, 20 Sep 2000 06:28:06 -0700 (PDT)
Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131])
by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
with ESMTP id JAA17493;
Wed, 20 Sep 2000 09:26:57 -0400 (EDT)
Received: from cs.columbia.edu (ACA3D6CE.ipt.aol.com [172.163.214.206])
by tot-tj.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e8KDQtI02110;
Wed, 20 Sep 2000 09:26:55 -0400 (EDT)
Message-ID: <39C8BA2D.AA5D76D2@cs.columbia.edu>
Date: Wed, 20 Sep 2000 09:22:53 -0400
From: Ping Pan
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap
CC: rsvp@ISI.EDU, Henning Schulzrinne
Subject: Re: RSVP PathError and ResvError messages
References: <200009191739.RAA09591@gra.isi.edu> <39C7AB1C.8B6E401@ascom.ch> <39C7D2DA.434C7C2C@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Apparently-From: PingPPan@aol.com
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
David Charlap wrote:
>
> Dusan Sarvan wrote:
> >
> > SENDER - RSVP capable,
> > RECEIVER (older version of the telephone GW) - doesn't support RSVP.
> >
> > This is a real situation in today's networks, that we have a telephone
> > Gateways which support RSVP and gateways which doesn't support RSVP.
> >
> > Let's say we have a SENDER telephone GW in New York which supports
> > RSVP and RECEIVER telephone GW in Geneva which doesn't support RSVP.
> > How to handle this case?
>
David,
> In this situation, RSVP will not be able to signal QoS along the entire
> path.
>
This is correct. What Dusan had pointed out was the fact that the
receiver-orientated reservation in RSVP would not work if the receivers
are not "smart". It's also not clear to me why we have to have two-pass
reservation in *this* case. This problem can be easily resolved if the
reservations are made from the sender's direction in a one-pass
reservation manner.
Please take a look at the
http://www.cs.columbia.edu/~pingpan/projects/yessir.html for something
that we have been working on for a while.
> You could probably set up a router close to the Geneva GW to signal RSVP
> to the New York GW. This will allow QoS to be reserved between the New
> York GW and that router. But there will still be no reservations between
> that router and the Geneva GW. It will probably require customizations
> to the router's code in order to work. (Similar customizations are
> being made in routers that use RSVP to signal MPLS tunels.)
>
> Doing so, however, will restrict the kind of reservations that may be
> made. Such a router will have to attempt to reserve the specific
> resources in the sender's TSpec. Or it will have to have application-
> aware knowledge, in order to intelligently choose some other
> reservation.
>
That right. In many cases, sender's Tspec may be good enough for
receivers. Actually, for routers to merge Sender Tspec's and Receiver
flowspecs (all those LUB and GLB operations) can be quite stressful if
you have to deal with shared reservations for multicast (aka,
many-to-many flowspec merging). That's why please take a look at what we
have proposed.
BTW, IMHO, receiver-orientated two-pass reservation (i.e. RSVP) gives
receivers great deal of flexibility, at the cost of having more
messages, processing cycles and states. Also, we have to understand that
RSVP is a good solution to accommodate different receiver requests in a
heterogeneous multicasting environment.
Thanks!
- Ping Pan
From rsvp-owner@ISI.EDU Thu Sep 21 10:51:21 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06750
for ; Thu, 21 Sep 2000 10:51:21 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id GAA12765
for rsvp-outgoing; Thu, 21 Sep 2000 06:11:45 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA12760
for ; Thu, 21 Sep 2000 06:11:44 -0700 (PDT)
Received: from mail.duchy.com.tw ([210.200.14.160])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA12375
for ; Thu, 21 Sep 2000 06:11:46 -0700 (PDT)
Received: from user ([210.200.144.180])
by mail.duchy.com.tw (Lotus Domino Release 5.0.2 (Intl))
with ESMTP id 2000091605201168:1506 ;
Sat, 16 Sep 2000 05:20:11 +0800
From: "肣Мゅ"
Reply-To: leo@tri.com.tw
Subject: 稱禗眤
To: a2000514@pchome.com.tw
X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999)
Mime-Version: 1.0
Date: Sat, 16 Sep 2000 03:17:50 +0800
X-MIMETrack: Itemize by SMTP Server on website/Duchy_Domain(Release 5.0.2 (Intl)|4 November 1999) at 2000/09/16 05:20:12 AM,
Serialize by Router on website/Duchy_Domain(Release 5.0.2 (Intl)|4 November 1999) at 2000/09/21 09:11:48 PM,
Serialize complete at 2000/09/21 09:11:48 PM
Message-ID:
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Type: text/plain; charset=unknown-8bit
X-MIME-Autoconverted: from 8bit to base64 by zephyr.isi.edu id GAB12765
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA06750
籓芖干┇栋床いみ玻籔Μ栋穝硉荡癸琌材渤て基程龟ず甧砯硉程е讽らΜン筳ら砯
PS.玻綪,基龟,扳狝叭Ч俱,叫呼ねみ!!
絬璹潦叫 http://jessy2000.126.com
From rsvp-owner@ISI.EDU Thu Sep 21 18:05:16 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15155
for ; Thu, 21 Sep 2000 18:05:16 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id NAA03505
for rsvp-outgoing; Thu, 21 Sep 2000 13:28:08 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA03500
for ; Thu, 21 Sep 2000 13:28:07 -0700 (PDT)
Received: from hotmail.com (law2-f112.hotmail.com [216.32.181.112])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id NAA09547
for ; Thu, 21 Sep 2000 13:28:12 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Thu, 21 Sep 2000 13:27:41 -0700
Received: from 209.6.34.253 by lw2fd.hotmail.msn.com with HTTP; Thu, 21 Sep 2000 20:27:41 GMT
X-Originating-IP: [209.6.34.253]
From: "Indiana Jones"
To: rsvp@ISI.EDU
Subject: small question
Date: Thu, 21 Sep 2000 16:27:41 EDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID:
X-OriginalArrivalTime: 21 Sep 2000 20:27:41.0827 (UTC) FILETIME=[645A0D30:01C0240A]
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hello,
I am new to RSVP. I was wondering if there is a specific reason why
we may want to keep knowledge of the neighbor even after a PATH
TEAR is sent or when the established session (via the sent PATH msg)
times out. I am not sure RFC 2205 explains this.
Once a PATH TEAR is received, I uderstand that we remove existing state
blocks for that session. I am also assuming that we need to remove the
knowledge of a neighbor unless there are other reasons to keep this
information. Any insights?
Thank you.
-Indiana.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
From rsvp-owner@ISI.EDU Thu Sep 21 18:52:33 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15617
for ; Thu, 21 Sep 2000 18:52:32 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id OAA05076
for rsvp-outgoing; Thu, 21 Sep 2000 14:03:10 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA05071
for ; Thu, 21 Sep 2000 14:03:09 -0700 (PDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01350;
Thu, 21 Sep 2000 14:03:13 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id VAA11143;
Thu, 21 Sep 2000 21:03:13 GMT
Date: Thu, 21 Sep 2000 21:03:13 GMT
Message-Id: <200009212103.VAA11143@gra.isi.edu>
To: rsvp@ISI.EDU, indiana_1_jones@hotmail.com
Subject: Re: small question
X-Sun-Charset: US-ASCII
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
*> From rsvp-owner@ISI.EDU Thu Sep 21 13:35:11 2000
*> X-Originating-IP: [209.6.34.253]
*> From: "Indiana Jones"
*> To: rsvp@ISI.EDU
*> Subject: small question
*> Date: Thu, 21 Sep 2000 16:27:41 EDT
*> Mime-Version: 1.0
*> X-OriginalArrivalTime: 21 Sep 2000 20:27:41.0827 (UTC) FILETIME=[645A0D30:01C0240A]
*> Sender: owner-rsvp@ISI.EDU
*> Precedence: bulk
*> X-Lines: 22
*>
*> Hello,
*>
*> I am new to RSVP. I was wondering if there is a specific reason why
*> we may want to keep knowledge of the neighbor even after a PATH
*> TEAR is sent or when the established session (via the sent PATH msg)
*> times out. I am not sure RFC 2205 explains this.
*>
*> Once a PATH TEAR is received, I uderstand that we remove existing state
*> blocks for that session. I am also assuming that we need to remove the
*> knowledge of a neighbor unless there are other reasons to keep this
*> information. Any insights?
*>
*> Thank you.
*>
*> -Indiana.
AFAIK, the current RSVP spec RFC 2205 says nothing about "knowledge of
a neighbor", except as parts of path and reservation state. The ISI
implementation, at least, does not maintain any explicit neighbor
state. A PathTear will leave no state, including no knowledge of the
neighbor.
However, I suspect that a reasonable implementation of the refresh reduction
extensions DOES require keeping an explicit neighbor table. Is that
what you are asking about?
Bob Braden
*>
*> _________________________________________________________________________
*> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
*>
*> Share information about yourself, create your own public profile at
*> http://profiles.msn.com.
*>
*>
From rsvp-owner@ISI.EDU Fri Sep 22 23:32:42 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04746
for ; Fri, 22 Sep 2000 23:32:41 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id SAA05712
for rsvp-outgoing; Fri, 22 Sep 2000 18:21:56 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05702
for ; Fri, 22 Sep 2000 18:21:54 -0700 (PDT)
Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA09765;
Fri, 22 Sep 2000 18:21:59 -0700 (PDT)
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
id ; Fri, 22 Sep 2000 17:33:35 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2543E6@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
To: "'Shahram Davari'"
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU, mpls@UU.NET
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Fri, 22 Sep 2000 17:33:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C024F5.E8A3A4C0"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C024F5.E8A3A4C0
Content-Type: text/plain
Hello,
I need a clarification in the context that you mentioned below, that is
setting up, through RSVP-TE, LSPs for Diff Serv trunks with both Diff Serv
and CoS object. What is the congruous relationship (if we need one
whatsoever) between the COS value (other than best effort) for the traffic
stream carried out in by the LSP and the diff serv PHBID/PSC objects of the
data flows going into the LSP?
Thanks,
Sergio
> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D
> 1000 Marina Boulevard Suite 300
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com
> --------------------------------------------------------------------
>
>
> -----Original Message-----
> From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> Sent: Wednesday, September 13, 2000 9:15 AM
> To: 'Mark Dewey'; mpls@UU.NET
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: RE: CR-LDP traffic parameter TLV and RSVP
>
> Hi Mark,
>
> For supporting Diffserv, a new Diffserv object/TLV is introduced for RSVP
> and CR-LDP respectively in "MPLS support of Diffserv draft". In case of
> RSVP, if the Diffserv object and the CoS object are not present the node
> should implement Intserv, however, the presence of each one indicates
> non-Intserv (Diffserv) implementation.
>
> Regards,
> -Shahram
>
> -----Original Message-----
> From: Mark Dewey [mailto:deweymark@hotmail.com]
> Sent: Wednesday, August 30, 2000 1:55 PM
> To: mpls@uu.net
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: CR-LDP traffic parameter TLV and RSVP
>
>
> Hi,
>
> I apologize for the wide distribution. I am not sure which mailing list
>
> this question belongs to.
>
> I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of an
> LSP
>
> tunnel can be specified in traffic parameter (e.g CDR) TLV.
>
> How is this value specified in RSVP if it were used to establish a LSP
> tunnel with qos characteristics?
>
>
> If sender TSPEC object is used, should the node implement integrated
> services (CL,GS)?
>
> Thanks,
> -Mark
>
>
>
>
>
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
------_=_NextPart_001_01C024F5.E8A3A4C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
RE: CR-LDP traffic parameter TLV and RSVP
Hello,
I need a clarification in the context =
that you mentioned below, that is setting up, through RSVP-TE, LSPs for =
Diff Serv trunks with both Diff Serv and CoS object. What is the =
congruous relationship (if we need one whatsoever) between the COS =
value (other than best effort) for the traffic stream carried out in by =
the LSP and the diff serv PHBID/PSC objects of the data flows going =
into the LSP?
Thanks,
Sergio
---------------------------------------------------------=
-----------
Sergio =
Catanzariti
Senior Project =
Manager, Technology Integration
France Telecom =
R&D
1000 Marina =
Boulevard Suite 300
Brisbane CA =
94005
Tel. =
650-875-1526
Fax. =
650-875-1505
email:sergio.catanzariti@rd.francetelecom.com =
---------------------------------------------------------=
-----------
-----Original Message-----
From: Shahram Davari =
[SMTP:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, September 13, 2000 9:15 AM
To: 'Mark Dewey'; mpls@UU.NET
Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
Subject: =
RE: CR-LDP traffic parameter TLV and =
RSVP
Hi Mark,
For supporting Diffserv, a new =
Diffserv object/TLV is introduced for RSVP
and CR-LDP respectively in =
"MPLS support of Diffserv draft". In case of
RSVP, if the Diffserv object =
and the CoS object are not present the node
should implement Intserv, =
however, the presence of each one indicates
non-Intserv (Diffserv) =
implementation.
Regards,
-Shahram
-----Original =
Message-----
From: Mark Dewey =
[mailto:deweymark@hotmail.com=
FONT>]
Sent: Wednesday, August 30, =
2000 1:55 PM
To: mpls@uu.net
Cc: rsvp@ISI.EDU; =
int-serv@ISI.EDU
Subject: CR-LDP traffic =
parameter TLV and RSVP
Hi,
I apologize for the =
wide distribution. I am not sure which mailing list
this question belongs =
to.
I understand, in =
CR-LDP, the qos characteristics(e.g bandwidth) of an LSP
tunnel can be specified in =
traffic parameter (e.g CDR) TLV.
How is this value =
specified in RSVP if it were used to establish a LSP
tunnel with qos =
characteristics?
If sender TSPEC object is used, =
should the node implement integrated
services (CL,GS)?
Thanks,
-Mark
___________________________________________________________________=
______
Get Your Private, Free E-mail =
from MSN Hotmail at http://www.hotmail.com.
Share information about =
yourself, create your own public profile at
http://profiles.msn.com.
------_=_NextPart_001_01C024F5.E8A3A4C0--
From rsvp-owner@ISI.EDU Sun Sep 24 22:15:19 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12968
for ; Sun, 24 Sep 2000 22:15:18 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id QAA25355
for rsvp-outgoing; Sun, 24 Sep 2000 16:49:56 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA25350
for ; Sun, 24 Sep 2000 16:49:55 -0700 (PDT)
Received: from klepsch (static24-72-6-183.reverse.accesscomm.ca [24.72.6.183])
by venera.isi.edu (8.9.3/8.9.3) with SMTP id QAA24245
for ; Sun, 24 Sep 2000 16:49:43 -0700 (PDT)
From: klepsch@cableregina.com
Message-Id: <200009242349.QAA24245@venera.isi.edu>
To:
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Sun, 24 Sep 2000 17:39:01
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zephyr.isi.edu id QAB25355
Content-Transfer-Encoding: quoted-printable
ThePresidentsGroup
=
ThePresidentsGroup
Specializing in low cost life insurance for your =
BUSINESS !
If you qualify, you can buy Life Insurance =
at these=20
new Rock Bottom rates:
<=
FONT=20
face=3DArial size=3D2>10 year Renewable Term Life Insurance
<=
FONT=20
face=3DArial size=3D2>Annual=20
Rates
Age |
$ 250,000 |
$ 500,000 |
$ 1,000,000<=
/B> |
$ 2,000,000<=
/B> |
|
|
|
|
|
40 =
TD>
|
253 <=
/TD>
|
445 <=
/TD>
|
820 <=
/TD>
|
1,590 |
45 =
TD>
|
345 <=
/TD>
|
635 <=
/TD>
|
1,210 |
2,370 |
50 =
TD>
|
488 <=
/TD>
|
915 <=
/TD>
|
1,750 |
3,450 |
55 =
TD>
|
743 <=
/TD>
|
1,385 |
2,670 |
5,290 |
60 =
TD>
|
1,130 |
2,185 |
4,300 |
8,550 |
65 =
TD>
|
2,118 |
4,070 |
8,060 |
16,070=
P> |
70 =
TD>
|
3,763 |
7,435 |
14,780=
P> |
29,510 |
=
Rates=20
are based on no tobacco / nicotine use.
Why not=20
let your business pay for your life insurance ?
Ideal=20
for Estate Planning.
I=
n most=20
cases, medical information can be obtained in your home
o=
r office.=20
No money required to find out if you qualify.
F=
or rates=20
just email or fax this letter toll free -
fax (888) 872 5605.
John Klepsch rhu vice president - marketing
business insurance =B7 seg funds =B7 life=20
insurance
Western Canada - 502 - 2339 Lorne St Regina S=
K S4P=20
2N2
Head Office - 3514 Hurontario St Mississauga =
ON L5B=20
1P2
www.presidentsgroup.com=
rates@canada.com
tel (800) 546 3354 • fax (888) 872 5605=
If you have received this email in error, ple=
ase reply with ' REMOVE ' in the subject line.
From rsvp-owner@ISI.EDU Mon Sep 25 19:07:31 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17107
for ; Mon, 25 Sep 2000 19:07:30 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id OAA10370
for rsvp-outgoing; Mon, 25 Sep 2000 14:26:41 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10361
for ; Mon, 25 Sep 2000 14:26:39 -0700 (PDT)
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA11750;
Mon, 25 Sep 2000 14:26:42 -0700 (PDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA14829;
Mon, 25 Sep 2000 17:24:59 -0400 (EDT)
(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200009252124.RAA14829@workhorse.fictitious.org>
To: CATANZARITI Sergio FTR&D/TI
cc: "'Shahram Davari'" , rsvp@ISI.EDU,
int-serv@ISI.EDU, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: CR-LDP traffic parameter TLV and RSVP
In-reply-to: Your message of "Fri, 22 Sep 2000 17:33:30 PDT."
<337055FBC675D311A85D00508B5A9C4F2543E6@u-mail.rd.francetelecom.com>
Date: Mon, 25 Sep 2000 17:24:59 -0400
From: Curtis Villamizar
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
In message <337055FBC675D311A85D00508B5A9C4F2543E6@u-mail.rd.francetelecom.com>
, CATANZARITI Sergio FTR&D/TI writes:
> 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_01C024F5.E8A3A4C0
> Content-Type: text/plain
>
> Hello,
>
> I need a clarification in the context that you mentioned below, that is
> setting up, through RSVP-TE, LSPs for Diff Serv trunks with both Diff Serv
> and CoS object. What is the congruous relationship (if we need one
> whatsoever) between the COS value (other than best effort) for the traffic
> stream carried out in by the LSP and the diff serv PHBID/PSC objects of the
> data flows going into the LSP?
>
> Thanks,
> Sergio
If you are talking about COS in RSVP signaling, then my advice is
pretend it never existed and reread draft-ietf-mpls-diff-ext-07.
Assume that you will be signaling the amount of bandwidth per PSC
(using CL and considering only the sustained rate parameter in the
tspec) and setting aside resources (setting queue weights)
appropriately. If paths change and the mix of PSCs changes so does
the proportional allocation of resource.
If you are talking about EXP and mistakenly calling is COS (which I
doubt anyone will still do :) then just reread
draft-ietf-mpls-diff-ext-07 since it is very clear how EXP is handled.
Curtis
From rsvp-owner@ISI.EDU Mon Sep 25 19:51:15 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17676
for ; Mon, 25 Sep 2000 19:51:14 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id OAA11410
for rsvp-outgoing; Mon, 25 Sep 2000 14:46:35 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA11399
for ; Mon, 25 Sep 2000 14:46:33 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA17430;
Mon, 25 Sep 2000 14:46:31 -0700 (PDT)
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 RAA09459;
Mon, 25 Sep 2000 17:45:29 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA11002;
Mon, 25 Sep 2000 17:45:30 -0400 (EDT)
Message-ID: <39CFC78E.66D46A7F@marconi.com>
Date: Mon, 25 Sep 2000 17:45:50 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: curtis@avici.com
CC: CATANZARITI Sergio FTR&D/TI ,
"'Shahram Davari'" , rsvp@ISI.EDU,
int-serv@ISI.EDU, mpls@UU.NET
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <200009252124.RAA14829@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Curtis Villamizar wrote:
>
> If you are talking about COS in RSVP signaling, then my advice is
> pretend it never existed and reread draft-ietf-mpls-diff-ext-07.
Yes. The CoS CType (of TSpec and FlowSpec) of RSVP-TE accomplishes
something different from what the MPLS-DiffServ draft is trying to
accomplish.
The RSVP CoS objects allow an entire LSP to be signalled for a specific
class. The only class whose behavior is defined is class 0 - best
effort. The meaning of all other classes (if any others are even
allowed in an implementation) are left up in the air - to be defined
either by vendors, by local administrative control, or an independant
signalling mechanism.
It is not possible to signal real QoS along with the class, because RSVP
only allows one TSpec per sender descriptor, and only one FlowSpec per
flow descriptor.
In other words, if you use CoS-type TSpecs and FlowSpecs, you will not
be able to signal QoS. And vice versa.
If you try to use these classes as mappings for DiffServ classes, then
you will be forced to create a separate LSP for each class. This may
cause scalability problems on a real-world network that makes extensive
use of DiffServ and MPLS together.
(And if you want to only use one LSP per DiffServ class, then you don't
have to signal the class at all - you can just signal QoS for a bunch of
LSPs and let the edge routers do all the DiffServ work.)
-- David
From rsvp-owner@ISI.EDU Mon Sep 25 23:25:18 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22206
for ; Mon, 25 Sep 2000 23:25:17 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id SAA21207
for rsvp-outgoing; Mon, 25 Sep 2000 18:34:20 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id SAA21199
for ; Mon, 25 Sep 2000 18:34:17 -0700 (PDT)
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id SAA20206;
Mon, 25 Sep 2000 18:34:17 -0700 (PDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA15868;
Mon, 25 Sep 2000 21:32:02 -0400 (EDT)
(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200009260132.VAA15868@workhorse.fictitious.org>
To: David Charlap
cc: curtis@avici.com,
CATANZARITI Sergio FTR&D/TI ,
"'Shahram Davari'" , rsvp@ISI.EDU,
int-serv@ISI.EDU, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: CR-LDP traffic parameter TLV and RSVP
In-reply-to: Your message of "Mon, 25 Sep 2000 17:45:50 EDT."
<39CFC78E.66D46A7F@marconi.com>
Date: Mon, 25 Sep 2000 21:32:02 -0400
From: Curtis Villamizar
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
In message <39CFC78E.66D46A7F@marconi.com>, David Charlap writes:
>
> (And if you want to only use one LSP per DiffServ class, then you don't
> have to signal the class at all - you can just signal QoS for a bunch of
> LSPs and let the edge routers do all the DiffServ work.)
This is a unique idea. How does the router at the edge do WFQ or
implement the three drop preferences for an AF class? :-)
Curtis
From rsvp-owner@ISI.EDU Tue Sep 26 12:15:37 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11708
for ; Tue, 26 Sep 2000 12:15:36 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA14627
for rsvp-outgoing; Tue, 26 Sep 2000 07:33:50 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA14616
for ; Tue, 26 Sep 2000 07:33:47 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id HAA22239;
Tue, 26 Sep 2000 07:33:53 -0700 (PDT)
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 KAA24246;
Tue, 26 Sep 2000 10:33:17 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03656;
Tue, 26 Sep 2000 10:33:17 -0400 (EDT)
Message-ID: <39D0B3C4.866A3446@marconi.com>
Date: Tue, 26 Sep 2000 10:33:40 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
CC: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <200009260132.VAA15868@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Curtis Villamizar wrote:
> David Charlap writes:
>>
>> (And if you want to only use one LSP per DiffServ class, then you
>> don't have to signal the class at all - you can just signal QoS for a
>> bunch of LSPs and let the edge routers do all the DiffServ work.)
>
> This is a unique idea. How does the router at the edge do WFQ or
> implement the three drop preferences for an AF class? :-)
It doesn't. It picks IntServ parameters that approximate the QoS level
required for each DS class and uses them when signalling the tunnels.
If the LSPs are signalled using the COS-type of TSpec and FlowSpec, then
the switches in the cloud will have to have some sort of agreement about
what the non-zero classes are supposed to mean.
All the edge router does on the data plane is use the DS bits to pick
which tunnel to forward the traffic into. If the tunnels have different
QoS or priority levels, then the different DS classes will end up with
those levels as well.
In this setup, the MPLS cloud is not actually using DS at all - it's
simply mapping the DS classes onto tunnels have their own QoS/COS levels
that are signalled independantly of any DS signalling.
-- David
From rsvp-owner@ISI.EDU Tue Sep 26 16:26:26 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15498
for ; Tue, 26 Sep 2000 16:26:25 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id LAA24373
for rsvp-outgoing; Tue, 26 Sep 2000 11:29:39 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24362
for ; Tue, 26 Sep 2000 11:29:36 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA03921;
Tue, 26 Sep 2000 11:29:05 -0700 (PDT)
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 OAA14921;
Tue, 26 Sep 2000 14:28:32 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04898;
Tue, 26 Sep 2000 14:28:32 -0400 (EDT)
Message-ID: <39D0EAE8.DF88A8DD@marconi.com>
Date: Tue, 26 Sep 2000 14:28:56 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
CC: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <337055FBC675D311A85D00508B5A9C4F2543EA@u-mail.rd.francetelecom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
CATANZARITI Sergio FTR&D/TI wrote:
>
> I would like to be back to my original question. That was how I will
> map, in a semantically compatible way, the COS-type values of
> Tspec/FlowSpec with the DS classes. Okay, assuming that I have clear
> the first case, mapping DS classes in the IntServ service types, (of
> course it is a joke... this presumption of understanding), for the
> second case, how to map COS-type values to DS classes,
You really can't. There is no defined meaning for COS-type values other
than zero (best effort). Any other value may be ignored, rejected, or
handled in a way you don't want.
It's really not a good idea to use non-zero values for the COS-type,
unless you know precisely what your switch's implementation will do with
it.
> I do not think that it is a customization/local configuration choice.
> Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt) says...
>
> Paragraph 5.6
> When processing a path (respectively Resv) message for an E-LSP or
> an L-LSP using the COS service, a Diff-Serv capable LSR must ignore
> the value of the COS field within a COS SENDER_TSPEC (respectively a
> COS FLOWSPEC).
Recognizing the fact that no classes other than zero have any standard
definition.
> So, I guess that, when we (Diff Serv Routers) process RSVP/PATH
> messages with COS-type TSpec/FlowSpec for (L or E type) LSPs carrying
> DS class trunks, the choice on how to implement service treatments is
> not given by COS values but EXP and/or label value. So, I do not worry
> about values mapping at all.
Sounds right to me.
-- David
From rsvp-owner@ISI.EDU Tue Sep 26 16:34:47 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15592
for ; Tue, 26 Sep 2000 16:34:46 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id LAA23993
for rsvp-outgoing; Tue, 26 Sep 2000 11:20:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA23983
for ; Tue, 26 Sep 2000 11:20:12 -0700 (PDT)
Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id LAA00919;
Tue, 26 Sep 2000 11:20:18 -0700 (PDT)
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
id ; Tue, 26 Sep 2000 11:19:01 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2543EA@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
To: "'David Charlap'" , mpls@UU.NET
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Tue, 26 Sep 2000 11:18:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C027E6.3E2CF44E"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C027E6.3E2CF44E
Content-Type: text/plain
I would like to be back to my original question. That was how I will map, in
a semantically compatible way, the COS-type values of Tspec/FlowSpec with
the DS classes. Okay, assuming that I have clear the first case, mapping DS
classes in the IntServ service types, (of course it is a joke... this
presumption of understanding), for the second case, how to map COS-type
values to DS classes, I do not think that it is a customization/local
configuration choice. Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt)
says...
Paragraph 5.6
>>When processing a path (respectively Resv) message for an E-LSP or an
L-LSP using the COS service, a Diff-Serv capable LSR must ignore the value
of the COS field within a COS SENDER_TSPEC (respectively a COS FLOWSPEC).
So, I guess that, when we (Diff Serv Routers) process RSVP/PATH messages
with COS-type TSpec/FlowSpec for (L or E type) LSPs carrying DS class
trunks, the choice on how to implement service treatments is not given by
COS values but EXP and/or label value. So, I do not worry about values
mapping at all.
Sergio
> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D
> 1000 Marina Boulevard Suite 300
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com
> --------------------------------------------------------------------
>
>
> -----Original Message-----
> From: David Charlap [SMTP:david.charlap@marconi.com]
> Sent: Tuesday, September 26, 2000 7:34 AM
> To: mpls@UU.NET
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: Re: CR-LDP traffic parameter TLV and RSVP
>
> Curtis Villamizar wrote:
> > David Charlap writes:
> >>
> >> (And if you want to only use one LSP per DiffServ class, then you
> >> don't have to signal the class at all - you can just signal QoS for a
> >> bunch of LSPs and let the edge routers do all the DiffServ work.)
> >
> > This is a unique idea. How does the router at the edge do WFQ or
> > implement the three drop preferences for an AF class? :-)
>
> It doesn't. It picks IntServ parameters that approximate the QoS level
> required for each DS class and uses them when signalling the tunnels.
> If the LSPs are signalled using the COS-type of TSpec and FlowSpec, then
> the switches in the cloud will have to have some sort of agreement about
> what the non-zero classes are supposed to mean.
>
> All the edge router does on the data plane is use the DS bits to pick
> which tunnel to forward the traffic into. If the tunnels have different
> QoS or priority levels, then the different DS classes will end up with
> those levels as well.
>
> In this setup, the MPLS cloud is not actually using DS at all - it's
> simply mapping the DS classes onto tunnels have their own QoS/COS levels
> that are signalled independantly of any DS signalling.
>
> -- David
------_=_NextPart_001_01C027E6.3E2CF44E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
RE: CR-LDP traffic parameter TLV and RSVP
I would like to be back to my original =
question. That was how I will map, in a semantically compatible way, =
the COS-type values of Tspec/FlowSpec with the DS classes. Okay, =
assuming that I have clear the first case, mapping DS classes in the =
IntServ service types, (of course it is a joke... this presumption of =
understanding), for the second case, how to map COS-type values to DS =
classes, I do not think that it is a customization/local configuration =
choice. Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt) =
says...
Paragraph 5.6
>>When processing a path (respectively Resv) message for an E-LSP =
or an L-LSP using the COS service, a Diff-Serv capable LSR must ignore =
the value of the COS field within a COS SENDER_TSPEC (respectively a =
COS FLOWSPEC).
So, I guess that, when we (Diff Serv =
Routers) process RSVP/PATH messages with COS-type TSpec/FlowSpec for (L =
or E type) LSPs carrying DS class trunks, the choice on how to =
implement service treatments is not given by COS values but EXP and/or =
label value. So, I do not worry about values mapping at all.
Sergio
---------------------------------------------------------=
-----------
Sergio =
Catanzariti
Senior Project =
Manager, Technology Integration
France Telecom =
R&D
1000 Marina =
Boulevard Suite 300
Brisbane CA =
94005
Tel. =
650-875-1526
Fax. =
650-875-1505
email:sergio.catanzariti@rd.francetelecom.com =
---------------------------------------------------------=
-----------
-----Original Message-----
From: David Charlap =
[SMTP:david.charlap@marconi.com]
Sent: Tuesday, September 26, 2000 7:34 AM
To: mpls@UU.NET
Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
Subject: =
Re: CR-LDP traffic parameter TLV and =
RSVP
Curtis Villamizar wrote:
> David Charlap =
writes:
>>
>> (And if you want to =
only use one LSP per DiffServ class, then you
>> don't have to signal =
the class at all - you can just signal QoS for a
>> bunch of LSPs and let =
the edge routers do all the DiffServ work.)
>
> This is a unique =
idea. How does the router at the edge do WFQ or
> implement the three drop =
preferences for an AF class? :-)
It doesn't. It picks =
IntServ parameters that approximate the QoS level
required for each DS class and =
uses them when signalling the tunnels.
If the LSPs are signalled using =
the COS-type of TSpec and FlowSpec, then
the switches in the cloud will =
have to have some sort of agreement about
what the non-zero classes are =
supposed to mean.
All the edge router does on the =
data plane is use the DS bits to pick
which tunnel to forward the =
traffic into. If the tunnels have different
QoS or priority levels, then =
the different DS classes will end up with
those levels as well.
In this setup, the MPLS cloud is =
not actually using DS at all - it's
simply mapping the DS classes =
onto tunnels have their own QoS/COS levels
that are signalled =
independantly of any DS signalling.
-- David
------_=_NextPart_001_01C027E6.3E2CF44E--
From rsvp-owner@ISI.EDU Wed Sep 27 01:46:24 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28267
for ; Wed, 27 Sep 2000 01:46:23 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id VAA19562
for rsvp-outgoing; Tue, 26 Sep 2000 21:00:09 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA19553
for ; Tue, 26 Sep 2000 21:00:07 -0700 (PDT)
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id VAA08045;
Tue, 26 Sep 2000 21:00:09 -0700 (PDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA22407;
Tue, 26 Sep 2000 23:58:44 -0400 (EDT)
(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200009270358.XAA22407@workhorse.fictitious.org>
To: CATANZARITI Sergio FTR&D/TI
cc: "'David Charlap'" , mpls@UU.NET, rsvp@ISI.EDU,
int-serv@ISI.EDU
Reply-To: curtis@avici.com
Subject: Re: CR-LDP traffic parameter TLV and RSVP
In-reply-to: Your message of "Tue, 26 Sep 2000 11:18:54 PDT."
<337055FBC675D311A85D00508B5A9C4F2543EA@u-mail.rd.francetelecom.com>
Date: Tue, 26 Sep 2000 23:58:44 -0400
From: Curtis Villamizar
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
In message <337055FBC675D311A85D00508B5A9C4F2543EA@u-mail.rd.francetelecom.com>
, CATANZARITI Sergio FTR&D/TI writes:
>
> I would like to be back to my original question. That was how I will map, in
> a semantically compatible way, the COS-type values of Tspec/FlowSpec with
> the DS classes. Okay, assuming that I have clear the first case, mapping DS
> classes in the IntServ service types, (of course it is a joke... this
> presumption of understanding), for the second case, how to map COS-type
> values to DS classes, I do not think that it is a customization/local
> configuration choice. Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt)
> says...
> Paragraph 5.6
> >>When processing a path (respectively Resv) message for an E-LSP or an
> L-LSP using the COS service, a Diff-Serv capable LSR must ignore the value
> of the COS field within a COS SENDER_TSPEC (respectively a COS FLOWSPEC).
> So, I guess that, when we (Diff Serv Routers) process RSVP/PATH messages
> with COS-type TSpec/FlowSpec for (L or E type) LSPs carrying DS class
> trunks, the choice on how to implement service treatments is not given by
> COS values but EXP and/or label value. So, I do not worry about values
> mapping at all.
> Sergio
Sergio,
My strong recommendation is don't use COS if you want useful QoS!
draft-ietf-mpls-diff-ext-05.txt:
1.6 Bandwidth Reservation for E-LSPs and L-LSPs
Regardless of which label binding protocol is used, E-LSPs and
L-LSPs may be established without bandwidth reservation or with
bandwidth reservation.
Establishing an E-LSP or L-LSP with bandwidth reservation means that
bandwidth requirements for the LSP are signaled at LSP establishment
time. Such signaled bandwidth requirements may be used by LSRs at
establishment time to perform admission control of the signaled LSP
over the Diff-Serv resources provisioned (e.g. via configuration,
SNMP or COPS) for the relevant PSC(s). Such signaled bandwidth
requirements may also be used by LSRs at establishment time to
perform adjustment to the Diff-Serv resources associated with the
relevant PSC(s) (e.g. adjust PSC scheduling weight).
Note that establishing an E-LSP or L-LSP with bandwidth reservation
does not mean that per-LSP scheduling is necessarily required. Since
E-LSPs and L-LSPs are specified in this document for support of
Differentiated Services, the required forwarding treatment
(scheduling and drop policy) is defined by the appropriate Diff-Serv
PHB. This forwarding treatment MUST be applied by the LSR at the
granularity of the BA and MUST be compliant with the relevant PHB
specification.
When bandwidth requirements are signaled at establishment of an
L-LSP, the signaled bandwidth is obviously associated with the
L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform
admission control may perform admission control over Diff-Serv
resources which are dedicated to the PSC (e.g. over the bandwidth
guaranteed to the PSC through its scheduling weight).
When bandwidth requirements are signaled at establishment of an
E-LSP, the signaled bandwidth is associated collectively to the
whole LSP and therefore to the set of transported PSCs. Thus, LSRs
which use the signaled bandwidth to perform admission control may
perform admission control over global resources which are shared by
the set of PSCs (e.g. over the total bandwidth of the link).
Examples of scenarios where bandwidth reservation is not used and
scenarios where bandwidth reservation is used are provided for
information in APPENDIX B.
[...]
The above is summarized in the following table:
Path Message LSP type
Service DIFFSERV
Object
GS/CL No E-LSP + preconf mapping + bandw reservation
GS/CL Yes/E-LSP E-LSP + signaled mapping + bandw reservation
GS/CL Yes/L-LSP L-LSP + bandw reservation
COS No E-LSP + preconf mapping + no bandw reservation
COS Yes/E-LSP E-LSP + signaled mapping + no band reservation
COS Yes/L-LSP L-LSP + no bandw reservation
Where:
- GS stands for Guaranteed Service
- CL stands for Controlled Load
- COS stands for COS service
Use bandwidth reservation (use service type CL with a tspec giving the
bandwidth reservation amount). Don't use COS service.
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
Consider the case where a network administrator elects to:
- have Diff-Serv resources entirely provisioned off-line (e.g. via
Command Line Interface, via SNMP, via COPS,...)
- use L-LSPs
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from
the bandwidth allocated to the relevant PSC.
In that case, L-LSPs would be established with signaled bandwidth.
The bandwidth signaled at L-LSP establishment would be used by LSRs
to perform admission control at every hop to ensure that the
constraint on availability of bandwidth for the relevant PSC is met.
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
per-PSC Resource Adjustment
Consider the case where a network administrator elects to:
- use L-LSPs
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from
the bandwidth allocated to the relevant PSC.
- have Diff-Serv resources dynamically adjusted
In that case, L-LSPs would be established with signaled bandwidth.
The bandwidth signaled at L-LSP establishment would be used by LSRs
to attempt to adjust the resources allocated to the relevant PSC
(e.g. scheduling weight) and then perform admission control to
ensure that the constraint on availability of bandwidth for the
relevant PSC is met after the adjustment.
I don't know how this could be more clear.
"Don't use COS" is my pesonal advice. The spec supports COS. I just
don't think it provides a useful service.
Curtis
From rsvp-owner@ISI.EDU Thu Sep 28 01:44:39 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06168
for ; Thu, 28 Sep 2000 01:44:38 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id UAA08931
for rsvp-outgoing; Wed, 27 Sep 2000 20:53:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id UAA08926
for ; Wed, 27 Sep 2000 20:53:56 -0700 (PDT)
Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id UAA26599
for ; Wed, 27 Sep 2000 20:54:03 -0700 (PDT)
Received: from who ([12.78.193.246]) by mtiwmhc27.worldnet.att.net
(InterMail vM.4.01.02.39 201-229-119-122) with SMTP
id <20000928035328.YBV14966.mtiwmhc27.worldnet.att.net@who>
for ; Thu, 28 Sep 2000 03:53:28 +0000
From: "Gregg C Levine"
To: "Rsvp"
Subject: Level of support for RSVP on Linux
Date: Wed, 27 Sep 2000 23:53:17 -0400
Message-ID:
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.4133.2400
Disposition-Notification-To: "Gregg C Levine"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello from Gregg C Levine usually with Jedi Knight Computers
What is the current level of support for RSVP on Linux? I mean its capabilties,
and what can be done, besides installing, and running the software found in the
FTP site.
----
Gregg C Levine mailto:hansolofalcon@worldnet.att.net
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke." Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi (Perhaps the most
powerful of all of the Jedi Knights))
(This company also dedicates this E-Mail to Master Yoda (Also perhaps the
most powerful of all of the Jedi Knights))
From rsvp-owner@ISI.EDU Thu Sep 28 14:06:24 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28301
for ; Thu, 28 Sep 2000 14:06:23 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id JAA02020
for rsvp-outgoing; Thu, 28 Sep 2000 09:24:17 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02007
for ; Thu, 28 Sep 2000 09:24:13 -0700 (PDT)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03965;
Thu, 28 Sep 2000 09:24:20 -0700 (PDT)
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA25486;
Thu, 28 Sep 2000 09:22:46 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
id ; Thu, 28 Sep 2000 09:27:11 -0700
Message-ID: <64DC8FA90382D411BA060090277AEE41774E6E@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari
To: "'David Charlap'" , mpls@UU.NET
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Thu, 28 Sep 2000 09:27:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi,
> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, September 26, 2000 2:29 PM
> To: mpls@UU.NET
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: Re: CR-LDP traffic parameter TLV and RSVP
>
>
> CATANZARITI Sergio FTR&D/TI wrote:
> >
> > I would like to be back to my original question. That was how I will
> > map, in a semantically compatible way, the COS-type values of
> > Tspec/FlowSpec with the DS classes. Okay, assuming that I have clear
> > the first case, mapping DS classes in the IntServ service types, (of
> > course it is a joke... this presumption of understanding), for the
> > second case, how to map COS-type values to DS classes,
>
> You really can't. There is no defined meaning for COS-type
> values other
> than zero (best effort). Any other value may be ignored, rejected, or
> handled in a way you don't want.
>
Yes off course you can. You could map any COS-Type to a local (non-standard)
DSCP value.
> It's really not a good idea to use non-zero values for the COS-type,
> unless you know precisely what your switch's implementation
> will do with
> it.
>
> > I do not think that it is a customization/local
> configuration choice.
> > Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt) says...
> >
> > Paragraph 5.6
> > When processing a path (respectively Resv) message for an E-LSP or
> > an L-LSP using the COS service, a Diff-Serv capable LSR must ignore
> > the value of the COS field within a COS SENDER_TSPEC (respectively a
> > COS FLOWSPEC).
>
> Recognizing the fact that no classes other than zero have any standard
> definition.
>
> > So, I guess that, when we (Diff Serv Routers) process RSVP/PATH
> > messages with COS-type TSpec/FlowSpec for (L or E type)
> LSPs carrying
> > DS class trunks, the choice on how to implement service
> treatments is
> > not given by COS values but EXP and/or label value. So, I
> do not worry
> > about values mapping at all.
>
> Sounds right to me.
>
> -- David
>
From rsvp-owner@ISI.EDU Thu Sep 28 14:15:48 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28574
for ; Thu, 28 Sep 2000 14:15:47 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id JAA02213
for rsvp-outgoing; Thu, 28 Sep 2000 09:28:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02204
for ; Thu, 28 Sep 2000 09:28:55 -0700 (PDT)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05057;
Thu, 28 Sep 2000 09:29:02 -0700 (PDT)
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA26542;
Thu, 28 Sep 2000 09:28:29 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
id ; Thu, 28 Sep 2000 09:32:54 -0700
Message-ID: <64DC8FA90382D411BA060090277AEE41774E6F@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari
To: "'David Charlap'" , mpls@UU.NET
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Thu, 28 Sep 2000 09:32:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi,
> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, September 26, 2000 10:34 AM
> To: mpls@UU.NET
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: Re: CR-LDP traffic parameter TLV and RSVP
>
>
> Curtis Villamizar wrote:
> > David Charlap writes:
> >>
> >> (And if you want to only use one LSP per DiffServ class, then you
> >> don't have to signal the class at all - you can just
> signal QoS for a
> >> bunch of LSPs and let the edge routers do all the DiffServ work.)
> >
> > This is a unique idea. How does the router at the edge do WFQ or
> > implement the three drop preferences for an AF class? :-)
>
> It doesn't. It picks IntServ parameters that approximate the
> QoS level
> required for each DS class and uses them when signalling the tunnels.
> If the LSPs are signalled using the COS-type of TSpec and
> FlowSpec, then
> the switches in the cloud will have to have some sort of
> agreement about
> what the non-zero classes are supposed to mean.
>
> All the edge router does on the data plane is use the DS bits to pick
> which tunnel to forward the traffic into. If the tunnels
> have different
> QoS or priority levels, then the different DS classes will end up with
> those levels as well.
It seems that you are mapping Diffserv PHBs to Intserv classes. In other
words
you want an Intserv network to behave like a PHB. This seems odd to me, and
probably
of no real world use.
>
> In this setup, the MPLS cloud is not actually using DS at all - it's
> simply mapping the DS classes onto tunnels have their own
> QoS/COS levels
> that are signalled independantly of any DS signalling.
>
> -- David
>
From rsvp-owner@ISI.EDU Thu Sep 28 14:31:27 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28972
for ; Thu, 28 Sep 2000 14:31:27 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA02887
for rsvp-outgoing; Thu, 28 Sep 2000 09:40:57 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02876
for ; Thu, 28 Sep 2000 09:40:52 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA08900;
Thu, 28 Sep 2000 09:40:58 -0700 (PDT)
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 MAA25542;
Thu, 28 Sep 2000 12:40:21 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24526;
Thu, 28 Sep 2000 12:40:23 -0400 (EDT)
Message-ID: <39D37495.FAF7A0A@marconi.com>
Date: Thu, 28 Sep 2000 12:40:53 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
CC: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <64DC8FA90382D411BA060090277AEE41774E6E@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Shahram Davari wrote:
> David Charlap wrote:
>>
>> You really can't. There is no defined meaning for COS-type
>> values other than zero (best effort). Any other value may be
>> ignored, rejected, or handled in a way you don't want.
>
> Yes off course you can. You could map any COS-Type to a local
> (non-standard) DSCP value.
And ensure that every router along the LSP accepts the non-zero COS-type
and handles it in the intended way.
A human administrator may be able to make that guarantee, but there's no
way switch software can do so on its own.
In other words, any use of these COS-types to map DS classes would have
to be through explicit administrative control. Such mappings can not be
made automatically, because successful implementation requres
meta-knowledge of how the entire cloud will support this non-standard
feature.
(Of course, a new draft may come along to solve this problem, if people
really care. But that changes the problem - after approval of such a
draft, use of the COS-type would no longer be non-standard.)
-- David
From rsvp-owner@ISI.EDU Thu Sep 28 14:38:25 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29180
for ; Thu, 28 Sep 2000 14:38:23 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id JAA03437
for rsvp-outgoing; Thu, 28 Sep 2000 09:51:53 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id JAA03426
for ; Thu, 28 Sep 2000 09:51:49 -0700 (PDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id JAA12524;
Thu, 28 Sep 2000 09:51:23 -0700 (PDT)
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 MAA26449;
Thu, 28 Sep 2000 12:50:45 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26996;
Thu, 28 Sep 2000 12:50:48 -0400 (EDT)
Message-ID: <39D37706.579FCDBD@marconi.com>
Date: Thu, 28 Sep 2000 12:51:18 -0400
From: David Charlap
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
CC: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: Re: CR-LDP traffic parameter TLV and RSVP
References: <64DC8FA90382D411BA060090277AEE41774E6F@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Content-Transfer-Encoding: 7bit
Shahram Davari wrote:
>
> It seems that you are mapping Diffserv PHBs to Intserv classes. In
> other words you want an Intserv network to behave like a PHB. This
> seems odd to me, and probably of no real world use.
I didn't say what I'm doing. And I didn't say what I want.
I merely mentioned another possible way of using DS and MPLS together.
A way that I had already previously stated was not optimal, compared to
the current draft. Somone else then asked a question, which I answered.
-- David
From rsvp-owner@ISI.EDU Thu Sep 28 19:25:41 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04918
for ; Thu, 28 Sep 2000 19:25:41 -0400 (EDT)
Received: by zephyr.isi.edu (8.9.3/8.9.3) id OAA16594
for rsvp-outgoing; Thu, 28 Sep 2000 14:27:09 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id OAA16582
for ; Thu, 28 Sep 2000 14:27:07 -0700 (PDT)
Received: from rwcxch02.clarent.com ([208.205.112.31])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id OAA07633
for ; Thu, 28 Sep 2000 14:27:13 -0700 (PDT)
Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21)
id ; Thu, 28 Sep 2000 14:25:12 -0700
Message-ID: <6374EFC78443D41197DD00508B5C35DD88A7E9@rwcxch02.clarent.com>
From: Supriya Saripalli
To: "Rsvp (E-mail)"
Subject: RSVP and RAS messages...
Date: Thu, 28 Sep 2000 14:25:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
Hi all,
Could anybody of you let me know if theres any significance of RAS messages
in the QoS routing i.e. for example in the Signalling protocol like RSVP..
Since RAS channel is used to convey the registration,admission and status
messages and bandwidth changes in between H323 end points..
So was wondering if it plays a role in the path messages in RSVP protocol
for requesting th e bandwidth....
Thanks in advance,
Supriya
Clarent Corp.
From rsvp-owner@ISI.EDU Thu Sep 28 21:05:28 2000
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06216
for ; Thu, 28 Sep 2000 21:05:27 -0400 (EDT)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.9.3/8.9.3) id QAA21218
for rsvp-outgoing; Thu, 28 Sep 2000 16:07:51 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145])
by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA21207
for ; Thu, 28 Sep 2000 16:07:49 -0700 (PDT)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id QAA07008;
Thu, 28 Sep 2000 16:07:56 -0700 (PDT)
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id QAA08388;
Thu, 28 Sep 2000 16:06:23 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
id ; Thu, 28 Sep 2000 16:10:49 -0700
Message-ID: <64DC8FA90382D411BA060090277AEE41774E78@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari
To: "'David Charlap'" , mpls@UU.NET
Cc: rsvp@ISI.EDU, int-serv@ISI.EDU
Subject: RE: CR-LDP traffic parameter TLV and RSVP
Date: Thu, 28 Sep 2000 16:10:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-rsvp@ISI.EDU
Precedence: bulk
> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Thursday, September 28, 2000 12:41 PM
> To: mpls@UU.NET
> Cc: rsvp@ISI.EDU; int-serv@ISI.EDU
> Subject: Re: CR-LDP traffic parameter TLV and RSVP
>
>
> Shahram Davari wrote:
> > David Charlap wrote:
> >>
> >> You really can't. There is no defined meaning for COS-type
> >> values other than zero (best effort). Any other value may be
> >> ignored, rejected, or handled in a way you don't want.
> >
> > Yes off course you can. You could map any COS-Type to a local
> > (non-standard) DSCP value.
>
> And ensure that every router along the LSP accepts the
> non-zero COS-type
> and handles it in the intended way.
This property is required and can be done by configuration of
each router.
>
> A human administrator may be able to make that guarantee, but
> there's no
> way switch software can do so on its own.
After the configuration is done (which is done only once), then
the switch software could recognize the local PHB from
the DSCP.
>
> In other words, any use of these COS-types to map DS classes
> would have
> to be through explicit administrative control. Such mappings
> can not be
> made automatically, because successful implementation requres
> meta-knowledge of how the entire cloud will support this non-standard
> feature.
I don't think there is any need of making such a mapping automatic.
>
> (Of course, a new draft may come along to solve this problem,
> if people
> really care. But that changes the problem - after approval of such a
> draft, use of the COS-type would no longer be non-standard.)
>
CoS or DSCP both indicate a PHB that a packet must receive
at each node. Now that Diffserv is standardized, there is no point in using
CoS any more, because you could signal any required PHB using DSCP (Diffserv
object)
-Shahram
> -- David
>