From rsvp-owner@ISI.EDU Sat Jul 1 03:04:24 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 DAA17367 for ; Sat, 1 Jul 2000 03:04:24 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA10008 for rsvp-outgoing; Fri, 30 Jun 2000 22:22:34 -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 WAA10002 for ; Fri, 30 Jun 2000 22:22:32 -0700 (PDT) Received: from isiax2.isi.it (isiax2.isi.it [130.192.70.12]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id WAA21556; Fri, 30 Jun 2000 22:22:58 -0700 (PDT) From: Mac.Beach@angelfire.com Received: by isiax2.isi.it; id AA01421; Fri, 30 Jun 2000 07:23:40 +0200 Date: Fri, 30 Jun 2000 07:23:40 +0200 Message-Id: <10006300523.AA01421@isiax2.isi.it> Reply-To: Mac.Beach@angelfire.com To: Mac.Beach@angelfire.com Subject: Update - Own your own E-Commerce Site at No Cost Sender: owner-rsvp@ISI.EDU Precedence: bulk NAME YOUR STORE Your Own SHOPPING MALL - NAME IT AT Absolutely no cost -- Yes, your own e-commerce site Choose the name, design, stores, and even the products you feature! ALL at Absolutely no cost -- FREE! No credit card needed to open your mall, just an address to mall your sale checks & commissions to: HURRY before the name you want for YOUR SHOPPING MALL is taken! Reply NOW WITH YOUR NAME to receive YOUR access code. mailto:MAC.BEACH@angelfire.com ------------------------------------------- Please read below for more information. You can open an e-commerce store of your very own on the Internet and have it making money for you in a matter of minutes. Better still, it costs you absolutely nothing to open it. This is a turnkey operation. You can choose the design of you store from several templates (all functions will be available after the pre-launch phase is completed very shortly), pick a color for your store, name your store, and decide what products your store will carry. Setup is simple: just click on the template options and they will be added to your store. Add Products: you will be able to offer a comprehensive variety of categories as well as a vast selection of brands and items and they all be constantly growing All with the best competitive pricing possible. You can select from individual categories, open several stores, or open one or more superstores with multiple products. What you choose is what will be built for you. With this new breakthrough product, you will never have to maintain inventory or find products to fill your store. It will all be done for you. You an never have to worry about filling or processing order, handling returns or refunds. That will be done for you too! In fact, you won't have to deal with many of the headaches commonly associated with having your own business. Once the store is opened, when people make purchases from your store, you get paid. Tell your friends who are buying CDs to do it online at your store! Tell your family where they can get their next movie video your story Share Your store Address with co-workers or even advertise it. This is your choice.............. You are in control.............. Ready to open your store? Simply reply to this email requesting your Access code. An access code will be provided, along with the link to the site where you will need to follow simple instructions on your computer screen. It takes only a few minutes to become an e-commerce storeowner. REPLY NOW to get an access code. mailto:MAC.BEACH@angelfire.com And begin thinking of the name you want to reserve to be removed from future mailings reply to this email with remove in the subject. >Under Bill s.1618 TITLE III passed by the 105th U.S. Congress >this letter can not be considered spam as long as we include: >Contact information & a Remove Link. mailto:MAC_BEACH.bangkok.com From rsvp-owner@ISI.EDU Sun Jul 2 01:25:36 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 BAA29446 for ; Sun, 2 Jul 2000 01:25:35 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id UAA03712 for rsvp-outgoing; Sat, 1 Jul 2000 20:55:14 -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 UAA03707 for ; Sat, 1 Jul 2000 20:55:12 -0700 (PDT) Received: from nts5.delicacy.com ([203.70.173.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id UAA29246 for ; Sat, 1 Jul 2000 20:55:52 -0700 (PDT) Message-Id: <200007020355.UAA29246@venera.isi.edu> Received: from nts5.delicacy.com.tw (mail.delicacy.com.tw [192.168.2.1]) by nts5.delicacy.com (Post.Office MTA v3.5.3 release 223 ID# 619-63046U200L2S100V35) with SMTP id com; Sun, 2 Jul 2000 11:23:44 +0800 Received: from 202.145.67.25 by nts5.delicacy.com.tw (InterScan E-Mail VirusWall NT); Sun, 02 Jul 2000 11:23:40 +0800 From: "jojolee" Reply-To: goodcd@ms59.url.com.tw Subject: ±ÀÂ˱z¤@­Ó¦n¯¸ To: asiajys@ms15.accnet.com.tw X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sun, 02 Jul 2000 10:58:51 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ±ÀÂˤ@­Ó¸g¨åªºªwÄѺô¯¸ ³o¬O¤@­Ó§Ú¶R¹Lı±o¯uªº¦nªººô¯¸ ³f¯u»ù¹ê µ´¹ï¥i¾a ·Q¬Ý·s³fªººô¤Í´N¥Ñ¦¹¶i§a........ ¡¸¡¸¡¸ http://page.to/jessymax ¡¸¡¸¡¸ From rsvp-owner@ISI.EDU Tue Jul 4 14:18:54 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 OAA29726 for ; Tue, 4 Jul 2000 14:18:53 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id JAA14624 for rsvp-outgoing; Tue, 4 Jul 2000 09:52:09 -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 JAA14619 for ; Tue, 4 Jul 2000 09:52:08 -0700 (PDT) Received: from elm.fernuni-hagen.de (elm.fernuni-hagen.de [132.176.114.24]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA18062 for ; Tue, 4 Jul 2000 09:52:50 -0700 (PDT) Message-Id: <200007041652.JAA18062@venera.isi.edu> Received: from lgks1.fernuni-hagen.de by elm.fernuni-hagen.de via local-channel with ESMTP; Tue, 4 Jul 2000 18:52:42 +0200 Received: from LGKS1/SpoolDir by lgks1.fernuni-hagen.de (Mercury 1.31); 4 Jul 100 18:55:19 MET Received: from SpoolDir by LGKS1 (Mercury 1.31); 4 Jul 100 18:55:14 MET From: Dagmar Sommer To: rsvp@ISI.EDU Date: Tue, 4 Jul 2000 18:55:04 +0200 Subject: Use of reserved resources Reply-to: dagmar.sommer@FernUni-Hagen.de Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-rsvp@ISI.EDU Precedence: bulk If there are reserved resources using RSVP for the data stream of a certain session. Can these reserved resources only be used by the concerning session? Or may be if the source of the session temporarily does not generate data or generates only a low amount of data. Can in this case other traffic make use of the reserved resources? Dagmar From rsvp-owner@ISI.EDU Wed Jul 5 21:51:36 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 VAA21920 for ; Wed, 5 Jul 2000 21:51:35 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id QAA27164 for rsvp-outgoing; Wed, 5 Jul 2000 16:58:49 -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 QAA27159 for ; Wed, 5 Jul 2000 16:58:48 -0700 (PDT) Received: from xf.hb.cninfo.net ([202.103.44.131]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA24200 for ; Wed, 5 Jul 2000 16:59:30 -0700 (PDT) Received: from sihun by xf.hb.cninfo.net (8.8.7/SMI-SVR4) id HAA04591; Thu, 6 Jul 2000 07:27:03 +0900 (CDT) Message-Id: <200007052227.HAA04591@xf.hb.cninfo.net> From: "694" Reply-To: mastercheng@21cn.com Subject: Re:help To: jfka;s@21cn.com;;;; X-Mailer: Microsoft Outlook Express 4.05.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Thu, 06 Jul 2000 02:33:05 +0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id QAA27160 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit ÐÔ.Éú»î ÊÇÒ»±¾°Ù¿ÆÈ«Ê飬Ëûͨ¹ýÏêϸµÄͼÎÄ£¬°ïÄú½Ò¿ªÐÔµÄÉñÃÜÃæÉ´£¬ÈÃÐÔ² »ÔÙÉñÃØ¡£ÏÖ·ÖΪÒÔÏÂÀ¸Ä¿£º ¡ïлéѧУ ¡ï±ÜÔÐרÀ¸ ¡ïÐÔ ½Ì Óý ¡ïÐÔ ÐÄ Àí ¡ïÐÔ Éú Àí ¡ïÐÔÓ뽡¿µ ¡ïÐÔ°®¼¼ÇÉ ¡ïÓÅÉúÓÅÓý ¡ïÒÉÄѽâ´ð ¡ïÁ½ÐÔ»°Ìâ ¡ïÐÔ²¡³£Ê¶ ¡ïΰ¸ç·ç³± Èç¹ûÄúÕý¶Ô´Ë·½ÃæÓÐʲô²»½âµÄµØ·½£¬»¶Ó­·ÃÎÊÕâÀÕâÀïÒ»¶¨»á¸øÄúÒ»¸öÂúÒ âµÄ´ð¸´¡£ δ³ÉÄêÕßÇëɾ³ý´ËÐÅ£¬¶ÔÓÚ±¾È˵Äð·¸Éî¸ÐǸÒâ¡£ µØÖ·£ºhttp://go.163.com/~694 Èç¹û¸ÃÒ³ÎÞ·¨ÏÔʾ£¬Çë¶àˢм¸´Î£¬·ÃÎÊÁ¿Ì« ´óÁË£¬Ã»°ì·¨¡£ From rsvp-owner@ISI.EDU Thu Jul 6 15:43:35 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 PAA24265 for ; Thu, 6 Jul 2000 15:43:34 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA29097 for rsvp-outgoing; Thu, 6 Jul 2000 11:10:15 -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 LAA29091 for ; Thu, 6 Jul 2000 11:10:13 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA10974 for ; Thu, 6 Jul 2000 11:11:05 -0700 (PDT) Received: from pacbell.net ([207.104.18.103]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXA008UFFACRS@mta5.snfc21.pbi.net> for rsvp@ISI.EDU; Thu, 6 Jul 2000 10:59:02 -0700 (PDT) Date: Thu, 06 Jul 2000 10:58:10 -0700 From: Andrew Smith Subject: Re: RFC 2872 on Application Identifiers for RSVP To: rsvp , rap@iphighway.com Message-id: <3964C8B2.6A5E10FD@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: multipart/mixed; boundary="------------0D1C87834E46F8AE0B353A26" X-Accept-Language: en References: <200007060013.RAA22869@boreas.isi.edu> Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. --------------0D1C87834E46F8AE0B353A26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to all who were involved, especially Yoram and Ramesh, on filling in some more detail of policy management for RSVP (still some bits missing though - don't stop thinking about this just yet). Andrew Smith RAP WG co-chair RFC Editor wrote: > > A new Request for Comments is now available in online RFC libraries. > > RFC 2872 > > Title: Application and Sub Application Identity Policy > Element for Use with RSVP > Author(s): Y. Bernet, R. Pabbati > Status: Standards Track > Date: June 2000 > Mailbox: yoramb@microsoft.com, rameshpa@microsoft.com > Pages: 6 > Characters: 10933 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-rap-rsvp-appid-01.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc2872.txt > > RSVP [RFC 2205] signaling messages typically include policy data > objects, which in turn contain policy elements. Policy elements may > describe user and/or application information, which may be used by > RSVP aware network elements to apply appropriate policy decisions to > a traffic flow. This memo details the usage of policy > elements that provide application information. > > This document is a product of the Resource Allocation Protocol Working > Group of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > -------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <000705171119.RFC@RFC-EDITOR.ORG> -- ****************************************************************** Andrew Smith tel: +1 415 345 1627 1001 Chestnut St. fax: +1 415 345 1827 San Francisco, CA 94109, USA email: ah_smith@pacbell.net ****************************************************************** --------------0D1C87834E46F8AE0B353A26 Content-Type: text/x-vcard; charset=us-ascii; name="ah_smith.vcf" Content-Description: Card for Andrew Smith Content-Disposition: attachment; filename="ah_smith.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Smith;Andrew tel;fax:650 325 8450 tel;home:650 325 9132 tel;work:408 579 2821 x-mozilla-html:TRUE adr:;;336 Middlefield Rd.;Palo Alto;CA;94301;USA version:2.1 email;internet:ah_smith@pacbell.net fn:Andrew Smith end:vcard --------------0D1C87834E46F8AE0B353A26-- From rsvp-owner@ISI.EDU Fri Jul 7 15:47:37 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 PAA11366 for ; Fri, 7 Jul 2000 15:47:37 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA05420 for rsvp-outgoing; Fri, 7 Jul 2000 11:07:05 -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 LAA05413 for ; Fri, 7 Jul 2000 11:07:02 -0700 (PDT) Received: from s-mail4.hanmail.net ([211.32.117.64]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04732 for ; Fri, 7 Jul 2000 11:07:53 -0700 (PDT) Received: from www5.mixmail.com ([211.32.117.155]) by s-mail4.hanmail.net (8.9.1/8.9.1) with ESMTP id CAA31525; Sat, 8 Jul 2000 02:56:33 +0900 Received: (from hanadmin@localhost) by www5.mixmail.com (8.9.1/8.9.1) id CAA11713; Sat, 8 Jul 2000 02:56:44 +0900 (KST) From: "David Perez Perez" To: rsvp@ISI.EDU X-Mailer: Daum Web Mailer 1.0 Date: Fri, 07 Jul 2000 04:56:44 -1300 Message-Id: <20000707195644.HM.40000000000L5go@mixmail.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Hello all I am using RSVP and CBQ with Linux, and I have some questions. I have the system: sender <--> router <--> receiver and I have installed: Router: SuSE 6.3, kernel 2.2.13 Sender, receiver: Red Hat 6.0, kernel 2.2.12-14 and the packets: iproute2-current.tar.gz rsvpd.rel4.2a4-1.tar.gz a) Why if I start the rsvp daemon like root it doesn´t do UDP encapsulation, and if I start it like a user it do UDP encapsulation ? (it happens in the 3 machines) root: # rsvpd -D RSVP Version 4.2a4, Compiled.... Log level:7 Debug mask:7 Start time.... IPv4 Multicast Daemon is not running Physical, Virtual... . . T1> user: # rsvpd -D RSVP Version 4.2a4, Compiled.... Log level:7 Debug mask:7 Start time.... IPv4 Multicast Daemon is not running Using UDP encapsulation (<--- ¡¡ HERE !!) Physical, Virtual... . . T1> Does it refer with Multicast ? b) If I compile the rsvp daemons with option -DCBQ in the Makefile of rsvp, I obtain: sender: send PATH messages receiver: receive PATH messages receiver: send RESV message router, sender: when RESV arrive, the rsvp daemon does`t work, and appear the next message in rsvp.log 00:07:12.344 ôÎÿ¿ «: errno 1071644672 00:07:12.344 ôÎÿ¿ «: errno 1072168960 00:07:12.344 ôÎÿ¿ «: errno 1072431104 00:07:12.344 ôÎÿ¿ «: errno 1072562176 00:07:12.344 ôÎÿ¿ «: errno 1072627712 00:07:12.345 ôÎÿ¿ «: errno 1072660480 00:07:12.345 ôÎÿ¿ «: errno 1072676864 00:07:12.345 ôÎÿ¿ «: errno 1072685056 00:07:12.345 ôÎÿ¿ «: errno 1072689152 00:07:12.345 ôÎÿ¿ «: errno 1072691200 00:07:12.345 ôÎÿ¿ «: errno 1072692224 00:07:12.345 ôÎÿ¿ «: errno 1072692736 00:07:12.346 ôÎÿ¿ «: errno 1072692992 00:07:12.346 ôÎÿ¿ «: errno 1072693120 00:07:12.346 ôÎÿ¿ «: errno 1072693184 00:07:12.346 ôÎÿ¿ «: errno 1072693216 00:07:12.346 ôÎÿ¿ «: errno 1072693232 00:07:12.346 ôÎÿ¿ «: errno 1072693240 00:07:12.346 ôÎÿ¿ «: errno 1072693244 00:07:12.347 ôÎÿ¿ «: errno 1072693246 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.347 ôÎÿ¿ «: errno 1072693247 00:07:12.348 ôÎÿ¿ «: errno 1072693247 00:07:12.348 ôÎÿ¿ «: errno 1072693247 00:07:12.348 ôÎÿ¿ «: errno 1072693247 00:07:12.348 ôÎÿ¿ «: errno 1072693247 ôÎÿ¿ «: errno 1072693248 00:07:12.348 Mmm, no policing info? 00:09:08.341 get_stats in the monitor appears also: "rsvpd: rsvp_debug.c: 460:log:The declaration 'severity==0 || severity>=3' Don`t expire" What is happening ? I comment the line 460 in rsvp_debug.c, I start de daemons, write the commands and it works and does the reserve. c) The class 1:7fff has 1Mbit (with CBQ), I do a reserve of any size (< 1Mbit) and the router reserve it. It is OK. After I do a reserve of any size that add with the previous reserve overflow the 1Mbit, the daemon in router and after in the sender don`t work. In the monitor appear: RTNETLINK error: Unknown error 4294967100 get_stats Segmentation fault What does it mean? Thank you very much !! E-mail: dos-manos@mixmail.com Tu correo gratis en MixMail http://www.mixmail.com Inicia tu navegacion en http://www.ya.com From rsvp-owner@ISI.EDU Fri Jul 7 17:15:36 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 RAA13457 for ; Fri, 7 Jul 2000 17:15:36 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id MAA10746 for rsvp-outgoing; Fri, 7 Jul 2000 12:23:20 -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 MAA10741 for ; Fri, 7 Jul 2000 12:23:18 -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 MAA04309; Fri, 7 Jul 2000 12:24:05 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA09959; Fri, 7 Jul 2000 19:24:05 GMT Date: Fri, 7 Jul 2000 19:24:05 GMT Message-Id: <200007071924.TAA09959@gra.isi.edu> To: rsvp@ISI.EDU, dos-manos@mixmail.com X-Sun-Charset: ISO-8859-1 Sender: owner-rsvp@ISI.EDU Precedence: bulk The rsvp mailing list is inappropriate for questions about implementation, testing, or deployment of rsvp. Please send your question to rsvp-test@isi.edu Bob Braden *> From rsvp-owner@ISI.EDU Fri Jul 7 11:14:21 2000 *> From: "David Perez Perez" *> To: rsvp@ISI.EDU *> X-Mailer: Daum Web Mailer 1.0 *> Date: Fri, 07 Jul 2000 04:56:44 -1300 *> MIME-Version: 1.0 *> Content-Transfer-Encoding: 8bit *> Sender: owner-rsvp@ISI.EDU *> Precedence: bulk *> X-Lines: 156 *> *> Hello all *> *> I am using RSVP and CBQ with Linux, and I have some *> questions. *> I have the system: sender <--> router <--> receiver *> and I have installed: *> Router: SuSE 6.3, kernel 2.2.13 *> Sender, receiver: Red Hat 6.0, kernel 2.2.12-14 *> and the packets: iproute2-current.tar.gz *> rsvpd.rel4.2a4-1.tar.gz *> *> a) Why if I start the rsvp daemon like root it doesn´t *> do UDP encapsulation, and if I start it *> like a user it do UDP encapsulation ? (it happens in *> the 3 machines) *> *> root: # rsvpd -D *> *> RSVP Version 4.2a4, Compiled.... *> Log level:7 Debug mask:7 Start time.... *> IPv4 Multicast Daemon is not running *> Physical, Virtual... *> . *> . *> T1> *> *> user: # rsvpd -D *> *> RSVP Version 4.2a4, Compiled.... *> Log level:7 Debug mask:7 Start time.... *> IPv4 Multicast Daemon is not running *> Using UDP encapsulation (<--- *> ¡¡ HERE !!) *> Physical, Virtual... *> . *> . *> T1> *> *> *> *> Does it refer with Multicast ? *> *> *> b) If I compile the rsvp daemons with option -DCBQ in *> the Makefile of rsvp, I obtain: *> *> sender: send PATH messages *> receiver: receive PATH messages *> receiver: send RESV message *> router, sender: when RESV arrive, the rsvp *> daemon does`t work, and appear the next *> message in rsvp.log *> *> *> 00:07:12.344 ôÎÿ¿ «: errno *> 1071644672 *> 00:07:12.344 ôÎÿ¿ «: errno *> 1072168960 *> 00:07:12.344 ôÎÿ¿ «: errno *> 1072431104 *> 00:07:12.344 ôÎÿ¿ «: errno *> 1072562176 *> 00:07:12.344 ôÎÿ¿ «: errno *> 1072627712 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072660480 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072676864 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072685056 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072689152 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072691200 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072692224 *> 00:07:12.345 ôÎÿ¿ «: errno *> 1072692736 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072692992 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693120 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693184 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693216 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693232 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693240 *> 00:07:12.346 ôÎÿ¿ «: errno *> 1072693244 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693246 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.347 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.348 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.348 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.348 ôÎÿ¿ «: errno *> 1072693247 *> 00:07:12.348 ôÎÿ¿ «: errno *> 1072693247 *> ôÎÿ¿ «: errno 1072693248 *> 00:07:12.348 Mmm, no policing info? *> 00:09:08.341 get_stats *> *> *> in the monitor appears also: *> *> "rsvpd: rsvp_debug.c: 460:log:The *> declaration 'severity==0 || severity>=3' *> Don`t expire" *> *> *> What is happening ? *> *> I comment the line 460 in rsvp_debug.c, I start *> de daemons, write the commands and it *> works and does the reserve. *> *> *> c) The class 1:7fff has 1Mbit (with CBQ), I do a *> reserve of any size (< 1Mbit) and the router *> reserve it. It is OK. After I do a reserve of any size *> that add with the previous reserve *> overflow the 1Mbit, the daemon in router and after in *> the sender don`t work. In the monitor *> appear: *> *> RTNETLINK error: Unknown error 4294967100 *> get_stats Segmentation fault *> *> What does it mean? *> *> *> *> Thank you very much !! *> E-mail: dos-manos@mixmail.com *> *> *> *> *> Tu correo gratis en MixMail http://www.mixmail.com *> Inicia tu navegacion en http://www.ya.com *> From rsvp-owner@ISI.EDU Fri Jul 7 18:05:48 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 SAA14362 for ; Fri, 7 Jul 2000 18:05:48 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id MAA13312 for rsvp-outgoing; Fri, 7 Jul 2000 12:59:30 -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 MAA13307 for ; Fri, 7 Jul 2000 12:59:28 -0700 (PDT) Received: from mail.monmouth.com (mail.monmouth.com [209.191.58.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA10363 for ; Fri, 7 Jul 2000 13:00:18 -0700 (PDT) Received: from prominencenet.com ([64.19.145.238]) by mail.monmouth.com (8.9.3/8.9.3) with ESMTP id QAA22604; Fri, 7 Jul 2000 16:00:08 -0400 (EDT) Message-ID: <396628E1.FAC5A802@prominencenet.com> Date: Fri, 07 Jul 2000 16:00:49 -0300 From: alfred Reply-To: ajd1@prominencenet.com Organization: Prominence networks X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14-6.1smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Perez Perez CC: rsvp@ISI.EDU Subject: Re: References: <20000707195644.HM.40000000000L5go@mixmail.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit David Perez Perez wrote: > Hello all > > I am using RSVP and CBQ with Linux, and I have some > questions. > I have the system: sender <--> router <--> receiver > and I have installed: > Router: SuSE 6.3, kernel 2.2.13 > Sender, receiver: Red Hat 6.0, kernel 2.2.12-14 > and the packets: iproute2-current.tar.gz > rsvpd.rel4.2a4-1.tar.gz > > a) Why if I start the rsvp daemon like root it doesn´t > do UDP encapsulation, and if I start it > like a user it do UDP encapsulation ? (it happens in > the 3 machines) ::: ::: The rsvp code tries to use the rsvp protocol first, if that fails, it does udp encapsulation. To use rsvp, the code must be able to use the raw interface. On linux, raw devices may only be opened by root. Hope this addresses your question. Alfred D'Souza From rsvp-owner@ISI.EDU Sat Jul 8 04:58:08 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 EAA04204 for ; Sat, 8 Jul 2000 04:58:07 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id AAA11622 for rsvp-outgoing; Sat, 8 Jul 2000 00:28:43 -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 AAA11617 for ; Sat, 8 Jul 2000 00:28:42 -0700 (PDT) Received: from c004.sfo.cp.net (c004-h000.c004.sfo.cp.net [209.228.14.52]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id AAA06243 for ; Sat, 8 Jul 2000 00:29:34 -0700 (PDT) From: feluda@mycoupons.com Received: (cpmta 12873 invoked from network); 8 Jul 2000 00:29:01 -0700 Date: 8 Jul 2000 00:29:01 -0700 Message-ID: <20000708072901.12872.cpmta@c004.sfo.cp.net> X-Sent: 8 Jul 2000 07:29:01 GMT Received: from [203.199.65.121] by mail.mycoupons.com with HTTP; 08 Jul 2000 00:29:01 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: rsvp@ISI.EDU X-Mailer: Web Mail 3.6.3.1 Subject: Manual Sender: owner-rsvp@ISI.EDU Precedence: bulk HI, I want to know how to use rtap, filter and others in the apitools that come with rsvp pkg for Linux. How do I interprete the commands ? How many m/cs I need to install rsvpd in ? Thanks, dhiman __________________________________________________ Organize all of your coupon and freebie email into one FREE email box. http://www.mycoupons.com From rsvp-owner@ISI.EDU Mon Jul 10 03:24:32 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 DAA29958 for ; Mon, 10 Jul 2000 03:24:32 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id WAA25500 for rsvp-outgoing; Sun, 9 Jul 2000 22:21:55 -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 WAA25495 for ; Sun, 9 Jul 2000 22:21:53 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA25571 for ; Sun, 9 Jul 2000 22:22:44 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id WAA27846; Sun, 9 Jul 2000 22:22:45 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA11884; Sun, 9 Jul 2000 22:22:43 -0700 (MST)] Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id KAA29847; Mon, 10 Jul 2000 10:57:26 +0530 (IST) Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 10:42:25 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCAF@xmail.miel.mot.com> From: Radhakrishna To: diffserv@ietf.org, rsvp@ISI.EDU Subject: draft-rk-diffserv-rsvp-sig-00.txt Date: Mon, 10 Jul 2000 10:42:25 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rsvp@ISI.EDU Precedence: bulk The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for signaling and admission control in DiffServ networks. It also defines the required RSVP objects. The use of RSVP as described in this document simplifies the processing and can be used by end hosts to signal the required PHBs to the network. It is also useful to the network for admission control purposes and does not add any overheads in data path. It also reduces the processing overheads of RSVP messages. Please let me know whether anybody has similar idea and whether we can improve this draft for adding admission control mechanisms to DiffServ networks. Thanks, .....RK The draft is available at - > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > From rsvp-owner@ISI.EDU Mon Jul 10 07:37:01 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 HAA04022 for ; Mon, 10 Jul 2000 07:37:01 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id CAA06824 for rsvp-outgoing; Mon, 10 Jul 2000 02:40:17 -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 CAA06819 for ; Mon, 10 Jul 2000 02:40:15 -0700 (PDT) Received: from c004.sfo.cp.net (c004-h002.c004.sfo.cp.net [209.228.14.54]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id CAA05829 for ; Mon, 10 Jul 2000 02:41:06 -0700 (PDT) From: feluda@mycoupons.com Received: (cpmta 6079 invoked from network); 10 Jul 2000 02:40:38 -0700 Date: 10 Jul 2000 02:40:38 -0700 Message-ID: <20000710094038.6078.cpmta@c004.sfo.cp.net> X-Sent: 10 Jul 2000 09:40:38 GMT Received: from [203.199.65.78] by mail.mycoupons.com with HTTP; 10 Jul 2000 02:40:38 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: rsvp@ISI.EDU X-Mailer: Web Mail 3.6.3.1 Subject: RSVP apis Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi, I want to use rsvpd deamon through programs. So do I need to look into the API codes or some standard convenient APIs are already available ? Thanks, Dhiman __________________________________________________ Organize all of your coupon and freebie email into one FREE email box. http://www.mycoupons.com From rsvp-owner@ISI.EDU Mon Jul 10 16:06:01 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 QAA26698 for ; Mon, 10 Jul 2000 16:06:01 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA06542 for rsvp-outgoing; Mon, 10 Jul 2000 11:28:31 -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 LAA06537 for ; Mon, 10 Jul 2000 11:28:30 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04770 for ; Mon, 10 Jul 2000 11:29:06 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA35618; Mon, 10 Jul 2000 19:28:09 +0100 Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA23074; Mon, 10 Jul 2000 19:28:22 +0100 (BST) Message-ID: <3969FA95.38079050@hursley.ibm.com> Date: Mon, 10 Jul 2000 11:32:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Radhakrishna CC: diffserv@ietf.org, rsvp@ISI.EDU Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt References: <2C202C0F886DD3119B1200A0C9A85FF405DCAF@xmail.miel.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit This is already an area of active work in the ISSLL working group, so can you try on their list? Thanks Brian Carpenter diffserv co-chair Radhakrishna wrote: > > The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for > signaling and admission control in DiffServ networks. It also > defines the required RSVP objects. The use of RSVP as described > in this document simplifies the processing and can be used by > end hosts to signal the required PHBs to the network. It is also > useful to the network for admission control purposes and does not add > any overheads in data path. It also reduces the processing overheads of > RSVP messages. > > Please let me know whether anybody has similar idea and whether we > can improve this draft for adding admission control mechanisms to > DiffServ networks. > > Thanks, > .....RK > > The draft is available at - > > http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt. > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From rsvp-owner@ISI.EDU Tue Jul 11 11:32:58 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 LAA04575 for ; Tue, 11 Jul 2000 11:32:58 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id GAA19559 for rsvp-outgoing; Tue, 11 Jul 2000 06:48:26 -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 GAA19546 for ; Tue, 11 Jul 2000 06:48:23 -0700 (PDT) Received: from smtp.WPI.EDU (root@smtp.WPI.EDU [130.215.24.62]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id GAA27888 for ; Tue, 11 Jul 2000 06:49:14 -0700 (PDT) Received: from falcon.WPI.EDU (falcon.WPI.EDU [130.215.8.131]) by smtp.WPI.EDU (8.11.0.Beta4/8.11.0.Beta4) with ESMTP id e6BDmYS13085 for ; Tue, 11 Jul 2000 09:48:34 -0400 (EDT) Received: from localhost (hao@localhost) by falcon.WPI.EDU (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e6BDnAC12119 for ; Tue, 11 Jul 2000 09:49:10 -0400 (EDT) Date: Tue, 11 Jul 2000 09:49:10 -0400 (EDT) From: Hao Shang To: rsvp@ISI.EDU Subject: About RSVP support in Windows 2000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, Does anyone have experience about the RSVP support in Windows 2000? Does only Windows 2000 server(not Windows 2000 professional) support RSVP? And how to config RSVP in it? Thanks in advance! ------- Hao From rsvp-owner@ISI.EDU Tue Jul 11 12:04:30 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 MAA06248 for ; Tue, 11 Jul 2000 12:04:29 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id HAA21543 for rsvp-outgoing; Tue, 11 Jul 2000 07:18:20 -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 HAA21537 for ; Tue, 11 Jul 2000 07:18:18 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id HAA29653 for ; Tue, 11 Jul 2000 07:19:08 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 07:03:55 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 11 Jul 2000 07:12:22 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message Subject: RE: About RSVP support in Windows 2000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEB40.FC28B9E8" Date: Tue, 11 Jul 2000 07:04:53 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A6101C9EB6@STAY.platinum.corp.microsoft.com> Thread-Topic: About RSVP support in Windows 2000 Thread-Index: Ab/rQC19K8wyk1+/Qfm0C73w8BbjQwAAN5gg From: "Yoram Bernet" To: "Hao Shang" , Cc: X-OriginalArrivalTime: 11 Jul 2000 14:12:22.0176 (UTC) FILETIME=[07DA0200:01BFEB42] Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFEB40.FC28B9E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This should move to rsvp-test. I will respond from there. > -----Original Message----- > From: Hao Shang [mailto:hao@cs.wpi.edu] > Sent: Tuesday, July 11, 2000 6:49 AM > To: rsvp@ISI.EDU > Subject: About RSVP support in Windows 2000 >=20 >=20 > Hello, >=20 > Does anyone have experience about the RSVP support in Windows 2000? >=20 > Does only Windows 2000 server(not Windows 2000 professional)=20 > support RSVP? > And how to config RSVP in it? >=20 > Thanks in advance! >=20 > ------- > Hao=20 >=20 ------_=_NextPart_001_01BFEB40.FC28B9E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: About RSVP support in Windows 2000

This should move to rsvp-test. I will respond from = there.

> -----Original Message-----
> From: Hao Shang [mailto:hao@cs.wpi.edu]
> Sent: Tuesday, July 11, 2000 6:49 AM
> To: rsvp@ISI.EDU
> Subject: About RSVP support in Windows = 2000
>
>
> Hello,
>
> Does anyone have experience about the RSVP = support in Windows 2000?
>
> Does only Windows 2000 server(not Windows 2000 = professional)
> support RSVP?
> And how to config RSVP in it?
>
> Thanks in advance!
>
> -------
> Hao
>

------_=_NextPart_001_01BFEB40.FC28B9E8-- From rsvp-owner@ISI.EDU Wed Jul 12 16:22:45 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 QAA12620 for ; Wed, 12 Jul 2000 16:22:44 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA22049 for rsvp-outgoing; Wed, 12 Jul 2000 11:40:35 -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 LAA22042 for ; Wed, 12 Jul 2000 11:40:34 -0700 (PDT) Received: from s-mail4.hanmail.net ([211.32.117.64]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07205; Wed, 12 Jul 2000 11:41:22 -0700 (PDT) Received: from www5.mixmail.com ([211.32.117.155]) by s-mail4.hanmail.net (8.9.1/8.9.1) with ESMTP id DAA11600; Thu, 13 Jul 2000 03:31:48 +0900 Received: (from hanadmin@localhost) by www5.mixmail.com (8.9.1/8.9.1) id DAA18526; Thu, 13 Jul 2000 03:22:49 +0900 (KST) From: "David Perez Perez" To: rsvp-test@ISI.EDU Cc: braden@ISI.EDU, rsvp@ISI.EDU X-Mailer: Daum Web Mailer 1.0 Date: Wed, 12 Jul 2000 05:22:49 -1300 Message-Id: <20000712202249.HM.40000000000LTau@mixmail.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Hi I am using RSVP,CBQ in LINUX I run cbqinit.eth0, and class 7ffe has 5 Mbit, parent class is isolated. The PATH arrive to receiver. My question is: Why in the router appear: "Adspec( 1 hop 655kBW 48us 1500B, ...." ? When the receiver sends RESV, appear: "RESV: error Traffic Control failure". Why appear this ? Tu correo gratis en MixMail http://www.mixmail.com Inicia tu navegacion en http://www.ya.com From rsvp-owner@ISI.EDU Thu Jul 13 15:13: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 PAA06012 for ; Thu, 13 Jul 2000 15:13:03 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id KAA13744 for rsvp-outgoing; Thu, 13 Jul 2000 10:26:49 -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 KAA13739 for ; Thu, 13 Jul 2000 10:26:48 -0700 (PDT) Received: from ormail2.orckit.com ([194.90.167.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA16428 for ; Thu, 13 Jul 2000 10:27:35 -0700 (PDT) Received: by ORMAIL2 with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jul 2000 20:27:07 +0200 Message-ID: From: Gal Mor To: "'rsvp@ISI.EDU'" Subject: an RSVP question Date: Thu, 13 Jul 2000 20:27:06 +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, As you all know, RSVP is a unidirectional protocol, resources will be reserved to the sender that sent the RSVP PATH request. if, for example, user started an application that needs a resources in both direction (upstream and downstream). if the application will send an RSVP PATH message, resources will be reserved only in downstream direction (from the destination to the user's application). how can we trigger a request in the opposite direction, should the application ask the destination to send an RSVP PATH message, or there is a simpler way ? thanks in advance Gal. From rsvp-owner@ISI.EDU Thu Jul 13 18:19:36 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 SAA26608 for ; Thu, 13 Jul 2000 18:19:36 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id NAA29126 for rsvp-outgoing; Thu, 13 Jul 2000 13:44:43 -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 NAA29121 for ; Thu, 13 Jul 2000 13:44:42 -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 NAA19466; Thu, 13 Jul 2000 13:45:35 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA13257; Thu, 13 Jul 2000 20:45:34 GMT Date: Thu, 13 Jul 2000 20:45:34 GMT Message-Id: <200007132045.UAA13257@gra.isi.edu> To: rsvp@ISI.EDU Subject: Is this still RSVP? Cc: braden@ISI.EDU, mankin@ISI.EDU, sob@harvard.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk I would like to call the Working Group's attention to: http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf and pose the questions: is this still RSVP, modified to be bi-directional? Is this compatible with the other RSVP extensions, including Refresh Reduction? Does anyone care? This work has been developed by a commercial consortium outside the IETF process (as I understand it). They have asked IANA for ten new object types to support this spec, and of course IANA will assign them. Bob Braden From rsvp-owner@ISI.EDU Thu Jul 13 20:05:00 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 UAA27203 for ; Thu, 13 Jul 2000 20:04:59 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id PAA05593 for rsvp-outgoing; Thu, 13 Jul 2000 15:36:34 -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 PAA05585 for ; Thu, 13 Jul 2000 15:36:32 -0700 (PDT) Received: from server4.ecc ([202.96.122.111]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id PAA08451 for ; Thu, 13 Jul 2000 15:37:13 -0700 (PDT) Message-Id: <200007132237.PAA08451@venera.isi.edu> Received: from YETI ([202.104.175.91]) by server4.ecc with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3LPTCJH0; Fri, 14 Jul 2000 03:37:12 +0800 From: "xiaoqiang" Reply-To: no@ISI.EDU Subject: ´´ÊÀÍøÖسö½­ºþ£¬¿´Á˾ÍÖªµÀºÃ To: users@21cn.net X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Thu, 13 Jul 2000 18:42:56 +0800 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Untitled Document =

=B4=B4=CA=C0=CD=F8=D6=D5=D3=DA=D6=D8=B3=F6=BD=AD=BA=FE=C1=CB=A3= =A1=A3=A1=A3=A1

=CE=AA=C1=CB=CF=EC=D3=A6=CC=D8=C7=F8=BD=FC=C8=D5=A1=B0=D0=A1=C7=BF= =A1=B1=B5=C4=D7=DF=BA=EC=A3=AC=B1=BE=D5=BE=D4=DD=B8=FC=C3=FB=D4=BB=A1=B0=D0= =A1=C7=BF=2Ecom=A1=B1=A1=A3


1=A1=A2=C3=BF=CC=EC=B8=FC=D0=C2=B5=C4=B8=DF=C7=E5=CE=FA=C3=C0=C0= =F6=D0=B4=D5=E6=A3=AC=D3=C0=B2=BB=C9=BE=B3=FD=A3=AC=B0=FC=C4=E3=BF=B4=B8=F6= =B1=A5=A1=A3

2=A1=A2=D0=D4=B8=D0=D0=C2=CE=C5=D7=E9

=A1=A1=A1=A1=D4=DA=D5=E2=C0=EF=C4=E3=BF=C9=D2=D4=B7=D6=CF=ED=B5=BD= =C8=AB=C7=F2=CD=F8=D3=D1=B5=C4=D0=D4=B8=D0=D0=C5=CF=A2=A3=AC=B0=FC=C0=A8=CD= =BC=C6=AC=C0=B2=A3=AC=CE=C4=D5=C2=C0=B2=A3=AC=C4=E3=D2=B2=BF=C9=D2=D4=B0=D1= =C4=E3=CB=F9=D5=E4=B2=D8=B5=C4=B6=AB=CE=F7=C4=C3=B3=F6=C0=B4=C8=C3=B4=F3=BC= =D2=B9=B2=CF=ED=A3=AC=CA=C7=B9=B2=CF=ED=BA=CD=D7=D4=D3=C9=B5=C4=CC=EC=CC=C3= =A1=A3

3=A1=A2=C1=ED=C0=E0=C1=C4=CC=EC=CA=D2=BA=CD=D3=EF=D2=F4=C1=C4=CC= =EC=CA=D2

=A1=A1=A1=A1=D5=E2=C0=EF=D3=D0=B1=BE=D5=BE=B3=A4=D7=D4=D6=C6=B5=C4= =C1=ED=C0=E0=C1=C4=CC=EC=CA=D2=A3=AC=BF=C9=D2=D4=D4=DA=C9=CF=C3=E6=B7=A2=CB= =CD=CE=C4=BC=FE=BA=CD=A3=AC=C9=F9=D2=F4=A3=AC=BB=B9=D3=D0=BF=C9=D2=D4=D3=C3= MIC=D6=B1=BD=D3=BD=BB=CC=B8=B5=C4=D3=EF=D2=F4=C1=C4=CC=EC=CA=D2=A3=AC=B8=CF= =BF=EC=C0=B4=CB=AC=D2=BB=CF=C2=B0=C9=A1=A3

4=A1=A2=CA=B5=D3=C3=D0=A1=B7=FE=CE=F1

=A1=A1=A1=A1=D1=D3=D0=F8=B1=BE=D5=BE=D2=D4=CD=F9=B5=C4=D7=F7=B7=E7= =A3=AC=D0=C2=D5=BE=D2=C0=BE=C9=B8=F8=CD=F8=D3=D1=CC=E1=B9=A9=B8=F7=C0=E0=D0= =A1=B7=FE=CE=F1=A3=AC=B0=FC=C0=A8=CB=D1=CB=F7=D2=FD=C7=E6=A1=A2=C8=ED=BC=FE= =CB=D1=CB=F7=A1=A2MP3=CB=D1=CB=F7=A1=A2=CD=F8=D5=BE=B7=AD=D2=EB=A3=AC=CD=F8= =C9=CF=D1=B0=BA=F4=A1=A2=CD=F8=C9=CF=B2=E9=CC=A8=B5=C8=B5=C8=A3=AC=C1=ED=CD= =E2=CC=D8=B1=F0=CD=C6=B3=F6=CA=D6=BB=FA=B6=CC=D1=B6=B7=A2=CB=CD=B7=FE=CE=F1= =A3=AC=CB=D9=B6=C8=C6=E6=BF=EC=A3=AC=BE=F8=B6=D4=C4=DC=D3=C3=A1=A3

5=A1=A2=D0=A1=C7=BF=D5=E4=B2=D8

=A1=A1=A1=A1=B0=FC=C0=A8=B1=BE=D5=BE=B3=A4=B9=FD=C8=A5=BA=CD=CF=D6= =D4=DA=CB=F9=BF=B4=B5=BD=CB=D1=BC=AF=B5=BD=B5=C4=D2=BB=D0=A9=BA=C3=B6=AB=CE= =F7=A1=A2=D0=C2=C6=E6=B5=C4=B6=AB=CE=F7=B6=BC=BB=E1=B8=F8=C4=E3=D2=BB=D2=BB= =B7=EE=C9=CF=A3=AC=C1=ED=CD=E2=BB=B9=CC=D8=C9=E8=D3=CA=BC=FE=C1=D0=B1=ED=A3= =AC=BC=D3=C8=EB=D5=DF=BF=C9=D2=D4=B2=BB=B6=A8=C6=DA=B5=D8=CA=D5=B5=BD=D5=BE= =B3=A4=B5=C4=CC=D8=C9=AB=D5=E4=B2=D8=A3=AC=CD=F2=CE=F0=B4=ED=B9=FD=A1=A3

=CF=C8=B8=F8=C4=E3=B8=F6=B6=AB=CE=F7=D0=C0=C9=CD=D2=BB=CF=C2=A3=AC= =BA=C3=BA=C3=D0=A6=B5=C4=C5=B6=A3=AC=BE=CD=CA=C7=B4=F3=C1=CB=B5=E3=A1=A3

http://elanchen=2Ehome=2Echinaren=2Ecom/xhmtq012=2Empg

=BB=B9=D3=D0=B8=FC=B6=E0=C4=D8=A3=AC=B8=CF=BF=EC=C8=A5=BF=B4=BF=B4= =B0=C9=A1=A3

 

 

------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From rsvp-owner@ISI.EDU Fri Jul 14 02:59:00 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 CAA13504 for ; Fri, 14 Jul 2000 02:58:59 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id WAA25036 for rsvp-outgoing; Thu, 13 Jul 2000 22:09:08 -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 WAA25031 for ; Thu, 13 Jul 2000 22:09:07 -0700 (PDT) Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA27584 for ; Thu, 13 Jul 2000 22:09:55 -0700 (PDT) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.9.3+Sun/UCLACS-5.0) id WAA01963; Thu, 13 Jul 2000 22:09:46 -0700 (PDT) From: Lixia Zhang Message-Id: <200007140509.WAA01963@aurora.cs.ucla.edu> Subject: Re: an RSVP question In-Reply-To: from Gal Mor at "Jul 13, 2000 08:27:06 pm" To: Gal Mor Date: Thu, 13 Jul 2000 22:09:46 -0700 (PDT) CC: "'rsvp@ISI.EDU'" X-Mailer: ELM [version 2.4ME+ PL60 (25)] 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 > As you all know, RSVP is a unidirectional protocol, resources will be > reserved to the sender that sent the RSVP PATH request. > > if, for example, user started an application that needs a resources in both > direction (upstream and downstream). if the application will send an RSVP > PATH message, resources will be reserved only in downstream direction (from > the destination to the user's application). > > how can we trigger a request in the opposite direction, should the > application ask the destination to send an RSVP PATH message, or there is a > simpler way ? > > thanks in advance > Gal. RSVP's simplex reservation works in all cases including networks with asymmentric paths (I agree that the operation is not the least cost, or the most optimal). Allowing a control message from one direction to make reservations for both directions works only if all paths are symmentric. Lixia From rsvp-owner@ISI.EDU Fri Jul 14 09:01:58 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 JAA18132 for ; Fri, 14 Jul 2000 09:01:57 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA09995 for rsvp-outgoing; Fri, 14 Jul 2000 04:21:36 -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 EAA09988 for ; Fri, 14 Jul 2000 04:21:34 -0700 (PDT) Received: from cad.zju.edu.cn ([210.32.131.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA14198 for ; Fri, 14 Jul 2000 04:22:19 -0700 (PDT) Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 420 for ; Fri, 14 Jul 2000 19:21:54 +0800 Message-ID: <396EE9CE.B171D873@cad.zju.edu.cn> Date: Fri, 14 Jul 2000 19:22:06 +0900 From: jing shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "'rsvp@ISI.EDU'" Subject: Re: an RSVP question References: <200007140509.WAA01963@aurora.cs.ucla.edu> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Lixia Zhang wrote: > > As you all know, RSVP is a unidirectional protocol, resources will be > > reserved to the sender that sent the RSVP PATH request. > > > > if, for example, user started an application that needs a resources in both > > direction (upstream and downstream). if the application will send an RSVP > > PATH message, resources will be reserved only in downstream direction (from > > the destination to the user's application). > > > > how can we trigger a request in the opposite direction, should the > > application ask the destination to send an RSVP PATH message, or there is a > > simpler way ? > > > > thanks in advance > > Gal. > I think it perhaps you can realized that in your system by invoking a trigger message after one-way RSVP. Jing Shen From rsvp-owner@ISI.EDU Fri Jul 14 09:12:39 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 JAA20558 for ; Fri, 14 Jul 2000 09:12:39 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA11242 for rsvp-outgoing; Fri, 14 Jul 2000 04:43:18 -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 EAA11237 for ; Fri, 14 Jul 2000 04:43:16 -0700 (PDT) Received: from xaloc.upc.es (root@xaloc.upc.es [147.83.105.131]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15337 for ; Fri, 14 Jul 2000 04:44:05 -0700 (PDT) Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id NAA09390 for ; Fri, 14 Jul 2000 13:42:12 +0200 (METDST) Message-ID: <396F076E.8372C353@estos.upc.es> Date: Fri, 14 Jul 2000 13:28:30 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: RSVP WG Subject: BW reserve with RSVP Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi,

I have established an MPLS TE Tunnel between 2
Cisco 7200 routers with RSVP as the signaling protocol.
I've made a RSVP reserve if 100 Kbit/s. I have one question:
if you don't use your BW reserved, or you just use, for
instace 25%, what happens with the unused reserved BW. It
can be used by other traffic flows? It can be used by best-effort
traffic who travels in the same links that the RSVP flows?

Thanks

Diego Otero From rsvp-owner@ISI.EDU Fri Jul 14 12:40:33 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 MAA26104 for ; Fri, 14 Jul 2000 12:40:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id HAA19616 for rsvp-outgoing; Fri, 14 Jul 2000 07:08:49 -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 HAA19611 for ; Fri, 14 Jul 2000 07:08:45 -0700 (PDT) Received: from brmnj-fw ([63.89.157.2]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id HAA22162 for ; Fri, 14 Jul 2000 07:09:33 -0700 (PDT) Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id <3VY46HTC>; Fri, 14 Jul 2000 10:02:21 -0400 Received: from brmnj-fw (63.89.157.129 [63.89.157.129]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3VY46HTA; Fri, 14 Jul 2000 10:02:12 -0400 From: "Shai Herzog (IPHighway MA)" To: internet-drafts@ietf.org Cc: rap , rsvp@ISI.EDU Message-Id: <4.3.2.7.2.20000713143557.00b518b0@bmailnj.iphighway.com> X-Sender: herzog@bmailnj.iphighway.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 10:07:28 -0400 Subject: Please post attached draft Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_40535086==_" Sender: owner-rsvp@ISI.EDU Precedence: bulk --=====================_40535086==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please post the attached ID on the Internet Drafts Servers for distribution to and discussion in the RAP working group of IETF. These are updated drafts and should be titled: DATE: July 2000 EXPIRES: January 2000 WORKING GROUP: RAP CHAIR: Andrew Smith, Mark Stevens Drafts: -------------------------------------------------------------------- TITLE: draft-ietf-rap-signaled-priority-v2-00.txt AUTHORS: Shai Herzog Comment: This draft is a replacement of RFC 2751. The change was needed because of a mix up in the Policy Element number registration with IANA: the RFC used PE number 3, while this one uses the correct PE number 1 instead. --=====================_40535086==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-rap-signaled-priority-v2-00.txt" Internet Draft S. Herzog Expiration: January 2001 IPHighway File: draft-ietf-rap-signaled-priority-v2-00.txt July 2000 Replaces: RFC 2751 Signaled Preemption Priority Policy Element Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751. Herzog Standards Track [Page 1] Internet Draft Signaled Preemption Priority Policy Element July 2000 Table of Contents 1 Introduction .....................................................2 2 Scope and Applicability ..........................................3 3 Stateless Policy .................................................3 4 Policy Element Format ............................................4 5 Priority Merging Issues ..........................................5 5.1 Priority Merging Strategies ...................................6 5.1.1 Take priority of highest QoS .................................6 5.1.2 Take highest priority ........................................7 5.1.3 Force error on heterogeneous merge ...........................7 5.2 Modifying Priority Elements ...................................7 6 Error Processing .................................................8 7 IANA Considerations ..............................................8 8 Security Considerations ..........................................8 9 References .......................................................9 10 Author Information .............................................9 Appendix A: Example ...............................................10 A.1 Computing Merged Priority ....................................10 A.2 Translation (Compression) of Priority Elements ...............11 Full Copyright Statement ..........................................12 1 Introduction Traditional Capacity based Admission Control (CAC) indiscriminately admits new flows until capacity is exhausted (First Come First Admitted). Policy based Admission Control (PAC) on the other hand attempts to minimize the significance of order of arrival and use policy based admission criteria instead. One of the more popular policy criteria is the rank of importance of a flow relative to the others competing for admission into a network node. Preemption Priority takes effect only when a set of flows attempting admission through a node represents overbooking of resources such that based on CAC some would have to be rejected. Preemption priority criteria help the node select the most important flows (highest priority) for admission, while rejecting the low priority ones. Network nodes which support preemption should consider priorities to preempt some previously admitted low-priority flows in order to make room for a newer, high-priority flow. This document describes the format and applicability of the preemption priority represented as a policy element in [RSVP-EXT]. Herzog Expires January 2001 [Page 2] Internet Draft Signaled Preemption Priority Policy Element July 2000 2 Scope and Applicability The Framework document for policy-based admission control [RAP] describes the various components that participate in policy decision making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI elements is to be simple, stateless, and light-weight such that they could be implemented internally within a node's LDP (Local Decision Point). Certain base assumptions are made in the usage model for PREEMPTION_PRI elements: - They are created by PDPs In a model where PDPs control PEPs at the periphery of the policy domain (e.g., in border routers), PDPs reduce sets of relevant policy rules into a single priority criterion. This priority as expressed in the PREEMPTION_PRI element can then be communicated to downstream PEPs of the same policy domain, which have LDPs but no controlling PDP. - They can be processed by LDPs PREEMPTION_PRI elements are processed by LDPs of nodes that do not have a controlling PDP. LDPs may interpret these objects, forward them as is, or perform local merging to forward an equivalent merged PREEMPTION_PRI policy element. LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects. (Clearly, a PDP, being a superset of LDP, may act as an LDP as well). - They are enforced by PEPs PREEMPTION_PRI elements interact with a node's traffic control module (and capacity admission control) to enforce priorities, and preempt previously admitted flows when the need arises. 3 Stateless Policy Signaled Preemption Priority is stateless (does not require past history or external information to be interpreted). Therefore, when carried in COPS messages for the outsourcing of policy decisions, these objects are included as COPS Stateless Policy Data Decision objects (see [COSP, COPS-RSVP]). Herzog Expires January 2001 [Page 3] Internet Draft Signaled Preemption Priority Policy Element July 2000 4 Policy Element Format The format of Policy Data objects is defined in [RSVP-EXT]. A single Policy Data object may contain one or more policy elements, each representing a different (and perhaps orthogonal) policy. The format of preemption priority policy element is as follows: +-------------+-------------+-------------+-------------+ | Length (12) | P-Type = PREEMPTION_PRI | +------+------+-------------+-------------+-------------+ | Flags | M. Strategy | Error Code | Reserved(0) | +------+------+-------------+-------------+-------------+ | Preemption Priority | Defending Priority | +------+------+-------------+-------------+-------------+ Length: 16 bits Always 12. The overall length of the policy element, in bytes. P-Type: 16 bits PREEMPTION_PRI = 1 This value is registered with IANA, see Section 7. Flags: 8 bits Reserved (always 0). Merge Strategy: 8 bit 1 Take priority of highest QoS: recommended 2 Take highest priority: aggressive 3 Force Error on heterogeneous merge Reserved: 8 bits Error code: 8 bits 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 1 PREEMPTION This previously admitted flow was preempted 2 HETEROGENEOUS This element encountered heterogeneous merge Reserved: 8 bits Always 0. Preemption Priority: 16 bit (unsigned) The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher Priority. Herzog Expires January 2001 [Page 4] Internet Draft Signaled Preemption Priority Policy Element July 2000 Defending Priority: 16 bits (unsigned) Once a flow was admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority must always be less than or equal to the defending priority. A wide gap between preemption and defending priority provides added stability: moderate preemption priority makes it harder for a flow to preempt others, but once it succeeded, the higher defending priority makes it easier for the flow to avoid preemption itself. This provides a mechanism for balancing between order dependency and priority. 5 Priority Merging Issues Consider the case where two RSVP reservations merge: F1: QoS=High, Priority=Low F2: QoS=Low, Priority=High F1+F2= F3: QoS=High, Priority=??? The merged reservation F3 should have QoS=Hi, but what Priority should it assume? Several negative side-effects have been identified that may affect such a merger: Free-Riders: If F3 assumes Priority=High, then F1 got a free ride, assuming high priority that was only intended to the low QoS F2. If one associates costs as a function of QoS and priority, F1 receives an "expensive" priority without having to "pay" for it. Denial of Service: If F3 assumes Priority=Low, the merged flow could be preempted or fail even though F2 presented high priority. Denial of service is virtually the inverse of the free-rider problem. When flows compete for resources, if one flow receives undeserving high priority it may be able to preempt another deserving flow (hence one free-rider turns out to be another's denial of service). Herzog Expires January 2001 [Page 5] Internet Draft Signaled Preemption Priority Policy Element July 2000 Instability: The combination of preemption priority, killer reservation and blockade state [RSVP] may increase the instability of admitted flows where a reservation may be preempted, reinstated, and preempted again periodically. 5.1 Priority Merging Strategies In merging situations LDPs may receive multiple preemption elements and must compute the priority of the merged flow according to the following rules: a. Preemption priority and defending priority are merged and computed separately, irrespective of each other. b. Participating priority elements are selected. All priority elements are examined according to their merging strategy to decide whether they should participate in the merged result (as specified bellow). c. The highest priority of all participating priority elements is computed. The remainder of this section describes the different merging strategies the can be specified in the PREEMPTION_PRI element. 5.1.1 Take priority of highest QoS The PREEMPTION_PRI element would participate in the merged reservation only if it belongs to a flow that contributed to the merged QoS level (i.e., that its QoS requirement does not constitute a subset another reservation.) A simple way to determine whether a flow contributed to the merged QoS result is to compute the merged QoS with and without it and to compare the results (although this is clearly not the most efficient method). The reasoning for this approach is that the highest QoS flow is the one dominating the merged reservation and as such its priority should dominate it as well. This approach is the most amiable to the prevention of priority distortions such as free-riders and denial of service. This is a recommended merging strategy. Herzog Expires January 2001 [Page 6] Internet Draft Signaled Preemption Priority Policy Element July 2000 5.1.2 Take highest priority All PREEMPTION_PRI elements participate in the merged reservation. This strategy disassociates priority and QoS level, and therefore is highly subject to free-riders and its inverse image, denial of service. This is not a recommended method, but may be simpler to implement. 5.1.3 Force error on heterogeneous merge A PREEMPTION_PRI element may participate in a merged reservation only if all other flows in the merged reservation have the same QoS level (homogeneous flows). The reasoning for this approach assumes that the heterogeneous case is relatively rare and too complicated to deal with, thus it better be prohibited. This strategy lends itself to denial of service, when a single receiver specifying a non-compatible QoS level may cause denial of service for all other receivers of the merged reservation. Note: The determination of heterogeneous flows applies to QoS level only (FLOWSPEC values), and is a matter for local (LDP) definition. Other types of heterogeneous reservations (e.g. conflicting reservation styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI element. This is a recommended merging strategy when reservation homogeneity is coordinated and enforced for the entire multicast tree. It is more restrictive than Section 5.1.1, but is easier to implement. 5.2 Modifying Priority Elements When POLICY_DATA objects are protected by integrity, LDPs should not attempt to modify them. They must be forwarded as-is or else their security envelope would be invalidated. In other cases, LDPs may modify and merge incoming PREEMPTION_PRI elements to reduce their size and number according to the following rule: Merging is performed for each merging strategy separately. There is no known algorithm to merge PREEMPTION_PRI element of different merging strategies without loosing valuable information that may affect OTHER nodes. Herzog Expires January 2001 [Page 7] Internet Draft Signaled Preemption Priority Policy Element July 2000 - For each merging strategy, the highest QoS of all participating PREEMPTION_PRI elements is taken and is placed in an outgoing PREEMPTION_PRI element of this merging strategy. - This approach effectively compresses the number of forwarded PREEMPTION_PRI elements to at most to the number of different merging strategies, regardless of the number of receivers (See the example in Appendix A.2). 6 Error Processing A PREEMPTION_PRI error object is sent back toward the appropriate receivers when an error involving PREEMPTION_PRI elements occur. PREEMPTION When a previously admitted flow is preempted, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted PREEMPTION_PRI object. This PDP, having information on both the preempting and the preempted priorities may construct a higher priority PREEMPTION_PRI element in an effort to re-instate the preempted flow. Heterogeneity When a flow F1 with Heterogeneous Error merging strategy set in its PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI element is sent back toward receivers with the Heterogeneity error code set. 7 IANA Considerations Following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RSVP-EXT]. P-Type PREEMPTION_PRI is assigned the value 3. 8 Security Considerations The integrity of PREEMPTION_PRI is guaranteed, as any other policy element, by the encapsulation into a Policy Data object [RSVP-EXT]. Further security mechanisms are not warranted, especially considering that preemption priority aims to provide simple and quick guidance to routers within a trusted zone or at least a single zone (no zone boundaries are crossed). Herzog Expires January 2001 [Page 8] Internet Draft Signaled Preemption Priority Policy Element July 2000 9 References [RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission Control", RFC 2753, January 2000. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 10 Author Information Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone: (508) 620-1141 EMail: herzog@iphighway.com Herzog Expires January 2001 [Page 9] Internet Draft Signaled Preemption Priority Policy Element July 2000 Appendix A: Example The following examples describe the computation of merged priority elements as well as the translation (compression) of PREEMPTION_PRI elements. A.1 Computing Merged Priority r1 / QoS=Hi (Pr=3, St=Highest QoS) / s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP) \ \ \ \ QoS=Low (Pr=7, St=Highest QoS) r4 r3 QoS=Low (Pr=9, St=Error) Example 1: Merging preemption priority elements Example one describes a multicast scenario with one sender and four receivers each with each own PREEMPTION_PRI element definition. r1, r2 and r3 merge in B. The resulting priority is 4. Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not contributing to the merged QoS) and the priority is the highest of the PREEMPTION_PRI from r1 and r2. r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 doesn't participate because its own QoS=Low is incompatible with the other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to r4 telling it that its PREEMPTION_PRI element encountered heterogeneity. Herzog Expires January 2001 [Page 10] Internet Draft Signaled Preemption Priority Policy Element July 2000 A.2 Translation (Compression) of Priority Elements Given this set of participating PREEMPTION_PRI elements, the following compression can take place at the merging node: From: (Pr=3, St=Highest QoS) (Pr=7, St=Highest QoS) (Pr=4, St=Highest PP) (Pr=9, St=Highest PP) (Pr=6, St=Highest PP) To: (Pr=7, St=Highest QoS) (Pr=9, St=Highest PP) Herzog Expires January 2001 [Page 11] Internet Draft Signaled Preemption Priority Policy Element July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Herzog Expires January 2001 [Page 12] --=====================_40535086==_ Content-Type: text/plain; charset="us-ascii"; format=flowed __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Fax : (914) 654-0209 Framingham, MA 01701 Main: (508) 620-1141 --=====================_40535086==_-- From rsvp-owner@ISI.EDU Fri Jul 14 13:18:19 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 NAA06583 for ; Fri, 14 Jul 2000 13:18:18 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA24538 for rsvp-outgoing; Fri, 14 Jul 2000 08:30: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 IAA24533 for ; Fri, 14 Jul 2000 08:30:54 -0700 (PDT) Received: from mail.corp124.com (adsl-63-206-97-82.dsl.snfc21.pacbell.net [63.206.97.82]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA27884 for ; Fri, 14 Jul 2000 08:31:44 -0700 (PDT) Received: from Lixia.cs.ucla.edu ([192.168.1.11]) by mail.corp124.com (8.9.3/8.8.7) with ESMTP id IAA12396; Fri, 14 Jul 2000 08:30:25 -0700 Message-Id: <4.3.2.7.2.20000714082322.02a67ec0@131.179.96.157> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 08:28:35 -0700 To: Juan Diego Otero , RSVP WG From: Lixia Zhang Subject: Re: BW reserve with RSVP In-Reply-To: <396F076E.8372C353@estos.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk At 05:28 AM 7/14/00, Juan Diego Otero wrote: >Hi, > >I have established an MPLS TE Tunnel between 2 >Cisco 7200 routers with RSVP as the signaling protocol. >I've made a RSVP reserve if 100 Kbit/s. I have one question: >if you don't use your BW reserved, or you just use, for >instace 25%, what happens with the unused reserved BW. It >can be used by other traffic flows? It can be used by best-effort >traffic who travels in the same links that the RSVP flows? > >Thanks > >Diego Otero Keep in mind that RSVP is only a messenger that carries your reservation requests around. RSVP does not make admission policies itself. It is up to the admission control module at the node to decide what to do with reserved but unused bandwidth. Lixia From rsvp-owner@ISI.EDU Fri Jul 14 16:25:59 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 QAA07319 for ; Fri, 14 Jul 2000 16:25:58 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA07350 for rsvp-outgoing; Fri, 14 Jul 2000 11:40:41 -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 LAA07345 for ; Fri, 14 Jul 2000 11:40:39 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA09578 for ; Fri, 14 Jul 2000 11:40:21 -0700 (PDT) Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 14:38:24 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id <3PCQ0QPN>; Fri, 14 Jul 2000 14:38:27 -0400 Message-ID: From: "Ralph Santitoro" To: internet-drafts@ietf.org Cc: rap@iphighway.com, rsvp@ISI.EDU Subject: Please post attached draft Date: Fri, 14 Jul 2000 14:38:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEDC2.B1E4195C" 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_000_01BFEDC2.B1E4195C Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDC2.B1E4195C" ------_=_NextPart_001_01BFEDC2.B1E4195C Content-Type: text/plain; charset="iso-8859-1" Please post the attached ID on the Internet Drafts Servers for distribution to and discussion in the RAP working group of the IETF. DATE: July 2000 EXPIRES: January 2001 WORKING GROUP: RAP CHAIR: Andrew Smith, Mark Stevens Drafts: -------------------------------------------------------------------- TITLE: draft-ietf-rap-policy-errorcodes-00.txt AUTHORS: Ralph Santitoro and Ramesh Pabbati Comment: This is a new draft. ------_=_NextPart_001_01BFEDC2.B1E4195C Content-Type: text/html; charset="iso-8859-1" Please post attached draft

Please post the attached ID on the Internet Drafts Servers for
distribution to and discussion in the RAP working group of the IETF.

DATE: July 2000

EXPIRES: January 2001

WORKING GROUP: RAP

CHAIR: Andrew Smith, Mark Stevens

Drafts:
--------------------------------------------------------------------

TITLE: draft-ietf-rap-policy-errorcodes-00.txt

AUTHORS: Ralph Santitoro and Ramesh Pabbati

Comment:

This is a new draft.

  ------_=_NextPart_001_01BFEDC2.B1E4195C-- ------_=_NextPart_000_01BFEDC2.B1E4195C Content-Type: text/plain; name="draft-ietf-rap-policy-errorcodes-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rap-policy-errorcodes-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group R. = Santitoro=20 Internet Draft Nortel = Networks=20 Category: Informational =20 Expiration Date: January 2001 R. = Pabbati=20 = Microsoft=20 =20 = July 2000=20 =20 Implementation Experience with =20 Policy Error Object in Identity Policy Element=20 =20 draft-ietf-rap-policy-errorcodes-00.txt=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with = all=20 provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering = Task Force=20 (IETF), its areas, and its working groups. Note that other groups = may also=20 distribute working documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and=20 may be updated, replaced, or obsoleted by other documents at any = time. It=20 is inappropriate to use Internet-Drafts as reference material or to = cite=20 them other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2000). All Rights Reserved.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in [RFC 2119].=20 =20 1. Abstract=20 =20 This document defines two new ErrorValues for the Policy Error = Object, which=20 is part of the Policy Data object [RFC2752]. These new ErrorValues = are being=20 defined because the ErrorValues defined in RFC 2752 are not = extensive enough=20 for a Policy server(PDP) to control application data flows. Hence = this draft=20 is defining two new ErrorValues to provide the host with additional = information on the error that caused the RSVP reservation failure. = =20 =20 =20 Santitoro and Pabbati Expires: January 2001 = 1=20 draft-ietf-rap-policy-errorcodes-00.txt July = 2000=20 =20 =20 =20 One ErrorValue allows the host to request a new reservation with = different=20 QoS requirements from the initial reservation. Consequently, the = network=20 may be able to provide this new QoS level and hence the host can = achieve=20 some QoS instead of only achieving a best effort service. The = other=20 ErrorValue is used to convey to a host that the reservation has = failed and=20 host must not send the particular type of traffic. This is = important for=20 applications that the network cannot easily classify and therefore = may have=20 difficulty blocking from the network. =20 =20 The ErrorValues are sent back to the host in the Policy Data Object = inside=20 an RSVP PathErr or ResvErr message as defined in [RFC 2752]. This = works for=20 both sender-based or receiver-based admission control. =20 =20 2. Introduction=20 =20 The POLICY_DATA object can be used to convey two types of policy = failure=20 information back to hosts initiating an RSVP reservation. =20 =20 The first type of failure informs the host that it must choose = between=20 sending its traffic with no QoS (best effort service) or attempt = another=20 reservation requesting a different QoS level from the network. = Some=20 applications, e.g., IP telephony used in a business environment, = may be=20 configured to use alternate paths to send traffic, e.g., route call = to PSTN,=20 because a best effort service does not provide an acceptable level = of=20 quality for the user. =20 =20 The second type of failure informs the requesting host and/or = application=20 that it should not send any traffic for the flow signaled in the = RSVP=20 messages. This is useful when the network cannot provide a useful = level of QoS that the application needs and it is better for the host to not = send the traffic rather than the traffic experiencing unpredictable and = hence=20 undesirable QoS. This is also useful to limit the amount of = traffic send to expensive connections.=20 =20 Note that this approach works for both sender-based and = receiver-based=20 admission control models. The POLICY_DATA object containing this = ErrorValue=20 may be part of either a PathErr or ResvErr message depending upon = whether=20 the Path message or Resv message is used for admission control.=20 =20 3. New ErrorValues for Policy Error Object=20 =20 The Policy Error Object (P-Type=3D1 or 2, A-Type=3D4, SubType=3D0) = contains the=20 ErrorValue field. The following two new ErrorValues are defined = below.=20 =20 ErrorValue Description =20 =20 =20 Santitoro and Pabbati Expires January 2001 = 2=20 draft-ietf-rap-policy-errorcodes-00.txt July = 2000=20 =20 =20 =20 6 INSUFFICIENT_BANDWIDTH Reservation failed due to insufficient=20 bandwidth to satisfy the host's=20 reservation request. Host may still = send=20 traffic but the network provides no QoS. = =20 7 DO_NOT_SEND Reservation failed and host is informed = to=20 not send any traffic=20 =20 3.1 INSUFFICIENT_BANDWIDTH (ErrorValue=3D6)=20 =20 This ErrorValue is used to quickly fail an RSVP reservation due to=20 insufficient bandwidth. For certain types of applications, such as = IP=20 telephony, it is critical to minimize connection setup time. = Therefore, it=20 is best to fail an RSVP reservation as soon as it is known that = insufficient=20 bandwidth is available for the call. =20 =20 For an IP telephony application, the PDP could include this = ErrorValue in=20 a PathErr message back to the initiating IP Phone. This allows the = reservation to be failed by a PDP (Policy Decision Point) or LDP = (Local=20 Decision Point) in the first RSVP-aware PEP (Policy Enforcement = Point) in the network where there is insufficient bandwidth to satisfy the IP = Phone's reservation request. Once this reservation has failed, additional=20 information can be conveyed to the host in the OctetString field in = the=20 Policy Error Object. The host may use this additional information = for the=20 new reservation request. Because this ErrorValue can be sent via a = PathErr message in response to a Path message, the reservation can be = quickly=20 failed. This type of quick failure is important for applications = such as=20 IP telephony that have stringent connection setup times. Note = that this scenario uses a sender-based admission control model.=20 =20 When a reservation is failed using this ErrorValue, the host may = send the=20 traffic with no QoS if this is acceptable to the application. This = can also=20 be achieved by the PDP sending a DCLASS object with DSCP '000000' = (best=20 effort service) back to the originating host to use to mark = subsequent=20 traffic associated with the reservation. This has the same result = of=20 getting no QoS treatment from the network. However, in the latter = case, the application will not know that it is getting no QoS and may not = function=20 properly.=20 =20 Finally, the network may send a non-best effort DCLASS object back = to the=20 host so its traffic can achieve some QoS from the network albeit = not the QoS=20 it requested in the initial reservation. The determination of the=20 alternative DCLASS object would be made by the PDP and the host may = elect to accept this new DCLASS object.=20 =20 Example 1:=20 =20 =20 Santitoro and Pabbati Expires January 2001 = 3=20 draft-ietf-rap-policy-errorcodes-00.txt July = 2000=20 =20 =20 A host attempts a reservation request for 384kbps but the network = can only=20 provide 128kbps during the time of the reservation. The network = fails the=20 reservation due to insufficient bandwidth (ErrorValue=3D6) and can = indicate=20 in the OctetString "128kbps available" (128kbps of bandwidth was = available=20 at the time the reservation had failed). The host may then = initiate a new=20 reservation requesting 128kbps if this is acceptable to the host's=20 application.=20 =20 Example 2:=20 =20 A host attempts a reservation request for 384kbps with a given QoS = level but=20 the network has no bandwidth available at for the requested QoS = level. The=20 network fails the reservation due to insufficient bandwidth = (ErrorValue=3D6). =20 The host can then use this information to make one of many = decision, e.g.,=20 attempt to initiate new reservation with different QoS level or = lower=20 bandwidth, send as best effort, etc.=20 =20 3.2 FLOW_DENIED (ErrorValue=3D7)=20 =20 This ErrorValue informs the host to not send traffic. This is used = when the=20 PDP (or LDP) does not want the host to send any traffic even as = best effort. =20 =20 Network administrators are limiting deploying of multimedia = applications on=20 enterprise networks because they are concerned about sending = multimedia=20 traffic over their expensive wide area network connections. = Network=20 administrators would like to either prevent high bandwidth = applications from=20 sending any data over these expensive connections or at least limit = the=20 number of simultaneous sessions that can be active. The simple = choice is=20 not to deploy these types of applications. =20 =20 This ErrorValue provides the network administrators with the = control they=20 need over these expensive network resources. Furthermore, when a = PDP=20 returns this ErrorValue, it could also push a filter to the PEP to = drop all=20 packets for this session.=20 =20 4. Security Considerations=20 =20 Authentication mechanisms defined in [RFC 2752] apply to this = document.=20 =20 5. References=20 =20 [RFC 2753] Yavatkar R., et al. "A Framework for Policy-based = Admission=20 Control", RFC 2753, January 2000.=20 =20 [RFC 2750] Herzog S., "RSVP Extensions for Policy Control", RFC = 2750,=20 January 2000.=20 =20 Santitoro and Pabbati Expires January 2001 = 4=20 draft-ietf-rap-policy-errorcodes-00.txt July = 2000=20 =20 =20 =20 [RFC 2752] Yadav S., et al. "Identity Representation for RSVP", = RFC=20 2752, January 2000.=20 =20 6. Acknowledgments=20 =20 The authors would like to thank Yoram Bernet, Kwok-Ho Chan, Ron = Pashby, =20 Eric Edwards and Nabil Seddigh for their input into the creation of = this document.=20 =20 7. Author's Addresses=20 =20 Ralph Santitoro=20 Nortel Networks=20 4100 Guardian Street=20 Simi Valley, CA 93063=20 Phone: 805-527-3024=20 Email: rsantito@nortelnetworks.com=20 =20 Ramesh Pabbati=20 Microsoft=20 1 Microsoft Way=20 Redmond, WA 98054=20 Phone: 425-936-9438=20 Email: rameshpa@microsoft.com=20 =20 =20 =20 Santitoro and Pabbati Expires January 2001 = 5=20 ------_=_NextPart_000_01BFEDC2.B1E4195C-- From rsvp-owner@ISI.EDU Fri Jul 14 16:34:56 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 QAA10648 for ; Fri, 14 Jul 2000 16:34:55 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA07657 for rsvp-outgoing; Fri, 14 Jul 2000 11:46:28 -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 LAA07651 for ; Fri, 14 Jul 2000 11:46:25 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA10038 for ; Fri, 14 Jul 2000 11:47:00 -0700 (PDT) Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 14:43:22 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id <3PCQ0QT3>; Fri, 14 Jul 2000 14:43:24 -0400 Message-ID: From: "Ralph Santitoro" To: internet-drafts@ietf.org Cc: rap@iphighway.com, rsvp@ISI.EDU Subject: Please post attached draft Date: Fri, 14 Jul 2000 14:43:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEDC3.63834A5C" 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_000_01BFEDC3.63834A5C Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDC3.63834A5C" ------_=_NextPart_001_01BFEDC3.63834A5C Content-Type: text/plain; charset="iso-8859-1" Please post the attached ID on the Internet Drafts Servers for distribution to and discussion in the RAP working group of the IETF. DATE: July 2000 EXPIRES: January 2001 WORKING GROUP: RAP CHAIR: Andrew Smith, Mark Stevens Drafts: -------------------------------------------------------------------- TITLE: draft-ietf-rap-policy-appids-00.txt AUTHORS: Ralph Santitoro and Ramesh Pabbati Comment: This is a new draft. ------_=_NextPart_001_01BFEDC3.63834A5C Content-Type: text/html; charset="iso-8859-1" Please post attached draft

Please post the attached ID on the Internet Drafts Servers for
distribution to and discussion in the RAP working group of the IETF.

DATE: July 2000

EXPIRES: January 2001

WORKING GROUP: RAP

CHAIR: Andrew Smith, Mark Stevens

Drafts:
--------------------------------------------------------------------

TITLE: draft-ietf-rap-policy-appids-00.txt

AUTHORS: Ralph Santitoro and Ramesh Pabbati

Comment:

This is a new draft.

  ------_=_NextPart_001_01BFEDC3.63834A5C-- ------_=_NextPart_000_01BFEDC3.63834A5C Content-Type: text/plain; name="draft-ietf-rap-policy-appids-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rap-policy-appids-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group R. = Santitoro=20 Internet Draft Nortel = Networks=20 Category: Informational = Expiration Date: January 2001 R. = Pabbati=20 = Microsoft=20 = = July 2000=20 = Implementation Experience with APPID in Identity Policy Element=20 =20 draft-ietf-rap-policy-appids-00.txt=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with = all=20 provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering = Task Force=20 (IETF), its areas, and its working groups. Note that other groups = may also=20 distribute working documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and=20 may be updated, replaced, or obsoleted by other documents at any = time. It=20 is inappropriate to use Internet-Drafts as reference material or to = cite=20 them other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2000). All Rights Reserved.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in [RFC 2119].=20 =20 1. Abstract=20 =20 The identity policy element (PE) is part of the Policy Data Object=20 [RFC 2750] which may be included in RSVP [RFC 2205] signaling = messages.=20 Policy elements with a P-type of AUTH_APP are used to identify = applications=20 and their attributes as defined in [RFC 2752]. =20 =20 =20 Santitoro and Pabbati Expires: January 2001 = 1=20 draft-ietf-rap-policy-appids-00.txt July = 2000=20 =20 =20 The usage and format of the PE for application identification is = defined in=20 [RFC 2753]. RSVP-aware network elements may use this application=20 identification information to apply appropriate policy decisions = for a given=20 traffic flow. =20 =20 This document proposes a standardized set of sub-application (SAPP) = descriptors to facilitate network element and host = interoperability. Since=20 applications, in general, are implementation-specific, a = standardized set=20 of APPs will not be covered in the document. However, hypothetical = APP=20 names will be used in the different examples for completeness.=20 =20 This document will provide SAPP descriptors only for real-time = application,=20 namely, audio, video and telephony (voice and fax) applications. = APP and=20 SAPP descriptors may be standardized for other non-real-time = applications. =20 However, this is beyond the scope of this memo.=20 =20 2. Introduction=20 =20 Many types of real-time applications, such as IP telephony, video = and=20 streaming audio, are difficult to classify. This is because they = do not use=20 well known, standardized port numbers or do not have standardized = protocol=20 IDs. Furthermore, devices can send multiple types of traffic, each = requiring different treatment by the network so classifying only on = the=20 source IP address is insufficient. SAPP can be used to distinguish = between=20 these different traffic types by providing standardized names to = define the=20 sub-application type. =20 =20 Finally, SAPP may be use in conjunction with other RSVP objects, = e.g.,=20 Flowspec and Filterspec, to allow a policy server (PDP) to make = more=20 informed policy decisions on the traffic to be sent to the network. = =20 3. Standardized Set of Sub-Application IDs=20 =20 RFC 2872 provides some examples for Sub-application (SAPP) = identification. =20 These attributes are provided in the Policy Locator attribute field = in the=20 Policy Element. To facilitate interoperability, a standardized set = of SAPP=20 descriptors are provided in the next sections. Many of the SAPP = descriptors=20 used are defined in [RTP Profile].=20 =20 The sub-application (SAPP) identifiers described in the next = sub-sections=20 consist of audio, voice, fax and video. Each of these has = additional SAPPs=20 which provide additional descriptors used to identify the = application.=20 =20 3.1 Audio=20 Audio SAPPs must include one codec and may include one or more = additional=20 SAPPs. The focus of these audio SAPPs is for use in real-time, = streaming=20 =20 =20 Santitoro and Pabbati Expires January 2001 = 2=20 draft-ietf-rap-policy-appids-00.txt July = 2000=20 =20 =20 audio applications such as Internet radio or music broadcasts. = However, the=20 audio SAPPs may also be used for the identification of other audio=20 applications as well.=20 =20 SAPP=3DAudio=20 =20 SAPP=3DMP1-32=20 SAPP=3DMP1-44.1=20 SAPP=3DMP1-48=20 SAPP=3DMP2-16=20 SAPP=3DMP2-22.05=20 SAPP=3DMP2-24=20 SAPP=3DMP2-32=20 SAPP=3DMP2-44.1=20 SAPP=3DMP2-48=20 SAPP=3DMP3-32=20 SAPP=3DMP3-44.1=20 SAPP=3DMP3-48=20 =20 This example specifies an MP1 (MPEG-1) audio file playing on a CD = Audio=20 Player device.=20 =20 Example: APP=3DCD Audio Player SAPP=3DAudio, SAPP=3DMP1-44.1=20 =20 3.2 Voice=20 =20 Voice SAPPs must include at least one codec and may include one or = more=20 additional SAPPs. When a VAD (Voice Activity Detection) SAPP, = which=20 includes silence suppression, is included, it indicates that VAD is = supported. If the VAD SAPP is not included then it indicates that = VAD is=20 not supported.=20 =20 While a voice application may be considered an audio application, = this=20 document has separated them because there are unique differences = between=20 the two. Voice applications are interactive and as such are more = latency=20 sensitive than audio applications. A network administrator will = apply=20 different policies that will take this into account and hence this=20 difference is of interest in the policy decisions made by the PDPs = (Policy=20 Decision Points) and PEP (Policy Enforcement Point) network = elements=20 enforcing the traffic. =20 =20 SAPP=3DVoice=20 =20 SAPP=3DG.711=20 SAPP=3DG.729=20 SAPP=3DG.728=20 SAPP=3DG.722=20 =20 Santitoro and Pabbati Expires January 2001 = 3=20 draft-ietf-rap-policy-appids-00.txt July = 2000=20 =20 =20 SAPP=3DG.723.1=20 SAPP=3DG.726-40=20 SAPP=3DG.726-32=20 SAPP=3DG.726-24=20 SAPP=3DG.726-16=20 SAPP=3DGSM6.10=20 SAPP=3DGSM6.90=20 SAPP=3DGSM-HR=20 SAPP=3DGSM-EFR=20 =20 SAPP=3DVAD =20 =20 In this example, the IP Phone indicates that it will use the G.729 = codec=20 with VAD (Voice Activity Detection) enabled (and hence, silence = suppression=20 enabled) for a voice call.=20 =20 Example: APP=3DIP Phone, SAPP=3DVoice, SAPP=3DG.729, SAPP=3DVAD=20 3.3 Fax=20 =20 There are two predominant ITU-T IP-based Fax standards, namely, = T.38 and=20 T.37. The SAPPs for fax must include the standard it is using = (T.38 or=20 T.37) and at least one modulation scheme.=20 =20 SAPP=3DFax=20 =20 SAPP=3DT.38=20 SAPP=3DT.37=20 =20 SAPP=3DV.90=20 SAPP=3DV.34=20 SAPP=3DV.17=20 SAPP=3DV.29=20 SAPP=3DV.27=20 =20 In this example, an IP Telephony (IPT) Gateway indicates that it = will=20 initiate a T.38 real-time fax call using the V.17 (14.4kbps) = modulation=20 scheme.=20 =20 Example: APP=3DIPT Gateway, SAPP=3DFax, SAPP=3DT.38, SAPP=3DV.17=20 3.4 Video=20 =20 Video SAPPs consist of the codec including the video window size = specified=20 in the standard CIF format. This provides the PDP with more = information on=20 the type of video (window size) to be sent over the network. A = network=20 =20 Santitoro and Pabbati Expires January 2001 = 4=20 draft-ietf-rap-policy-appids-00.txt July = 2000=20 =20 =20 administrator, for example, may only allow an application to send = H.263-QCIF=20 video over expensive wide area connections but allow H.263-CIF = video over=20 high bandwidth campus LAN connections.=20 =20 SAPP=3DVideo=20 =20 SAPP=3DH.261-CIF=20 SAPP=3DH.261-QCIF=20 SAPP=3DH.263-CIF=20 SAPP=3DH.263-QCIF=20 SAPP=3DH.263-SQCIF=20 SAPP=3DH.263-4CIF=20 SAPP=3DH.263-16QCIF=20 =20 This example represents a 180x144 pixel Quarter Common Intermediate = Format=20 (CIF) frame of H.261-encoded video playing on a Media Player.=20 =20 Example: APP=3DMedia Player, SAPP=3DVideo, SAPP=3DH.261-QCIF=20 =20 4. Security Considerations=20 =20 The identity policy element does not guarantee any association with = the=20 application initiating it. However, the identity policy element = can be part=20 of same RSVP message that contains the POLICY_DATA object [RFC = 2750] which=20 can be used to authenticate users and applications. =20 =20 5. References=20 =20 [RFC 2750] Herzog S., "RSVP Extensions for Policy Control", RFC = 2750,=20 January 2000.=20 =20 [RFC 2752] Yadav S., et al. "Identity Representation for RSVP", = RFC=20 2752, January 2000.=20 =20 [RFC 2753] Yavatkar R., et al. "A Framework for Policy-based = Admission=20 Control", RFC 2753, January 2000.=20 [RFC 2872] Bernet, Y. and Pabbati, R., "Application and Sub = Application=20 Identity Policy Element for Use with RSVP", RFC 2872, = June=20 2000. =20 [RTP Profile] Schulzrinne and Casner "RTP Profile for Audio and = Video=20 Conferences with Minimal Control",=20 draft-ietf-avt-profile-new-08.txt, January 2000.=20 =20 Santitoro and Pabbati Expires January 2001 = 5=20 draft-ietf-rap-policy-appids-00.txt July = 2000=20 =20 =20 6. Acknowledgments=20 =20 The authors would like to thank Yoram Bernet, Kwok-Ho Chan, Ron = Pashby and=20 Eric Edwards for their input into the creation of this document.=20 =20 7. Author's Addresses=20 =20 Ralph Santitoro=20 Nortel Networks=20 4100 Guardian Street=20 Simi Valley, CA 93063=20 Phone: 805-527-3024=20 Email: rsantito@nortelnetworks.com=20 =20 Ramesh Pabbati=20 Microsoft=20 1 Microsoft Way=20 Redmond, WA 98054=20 Phone: 425-936-9438=20 Email: rameshpa@microsoft.com=20 =20 =20 =20 Santitoro and Pabbati Expires January 2001 = 6=20 ------_=_NextPart_000_01BFEDC3.63834A5C-- From rsvp-owner@ISI.EDU Tue Jul 18 02:26:18 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 CAA11324 for ; Tue, 18 Jul 2000 02:26:17 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id VAA26993 for rsvp-outgoing; Mon, 17 Jul 2000 21:20:32 -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 VAA26988 for ; Mon, 17 Jul 2000 21:20:31 -0700 (PDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id VAA23410 for ; Mon, 17 Jul 2000 21:21:21 -0700 (PDT) Received: from atticus.cisco.com ([144.254.219.19]) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA16579; Mon, 17 Jul 2000 21:20:56 -0700 (PDT) Received: (from ddutt@localhost) by atticus.cisco.com (8.9.3/8.8.7) id VAA18145; Mon, 17 Jul 2000 21:20:40 -0700 X-Authentication-Warning: atticus.cisco.com: ddutt set sender to ddutt@cisco.com using -f X-Mailer: 21.1 (patch 10) "Capitol Reef" XEmacs Lucid (via feedmail 8 Q); VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid From: "Dinesh G Dutt" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14707.53267.862925.467510@atticus.cisco.com> Date: Mon, 17 Jul 2000 20:33:39 -0700 (PDT) To: Andrew Smith Cc: "'rsvp@isi.edu'" , "'rap@iphighway.com'" Subject: Re: Comments on draft-ietf-rsvp-proxy-00.txt In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC711@SOL> References: <808F64DDB492D3119D3C00508B5D8D733EC711@SOL> Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I regret the delay in responding to these comments. I have addressed all the points raised by Andrew below. A new version of the draft has been submitted last week. More comments inline. Andrew Smith writes: > 2. Scope: there is no reason to tie RSVP proxy to NULL service; no reason to > tie it to DiffServ/DSCPs: instead, should use generic examples of wanting to > replace or add RSVP objects. No reason to include discussion of SBM here. No > reason to tie the mechanism to outsourced policy management: this should be > described as a general mechanism for RSVP. Fixed. The wording has been modified to address this. > > 3. Subflows? what is this all about? This has been removed. > > 4. The draft talks about "generation of the Resv message": are we talking > about individual messages or installation of state here? I always thought > that RSVP messages were just a mechanism to install/refresh/delete state in > intermediate and terminal nodes. I think this draft uses the wrong model for > what is being done here. Clarified in detail what we're talking about. > > 5. Section 3: the discussion of where along the path to locate the proxy > function does not give much help. I think this discussion is outside the > scope (yes, it is a policy or configuration issue). > > 6. Section 3.1: There is no need to specify all those details of RSVP > message syntax and rules: the behaviour of what goes in a RESV message is > already defined by RFC2205. This section (3.1) has been removed. > > 7. Section 3.2: what is special about SBMs? yes, you have to have the proxy > at the right point along the path: same issue exists with pure RSVP. Fixed. > > 8. Section 5: should not be making any changes to RSVP recommendations here. Agreed. Fixed to reflect issues raised by RFC2205. > > 9. Section 6: IPR - still waiting to see these claims: I do not think it is > appropriate to forward this as an RFC with this still pending. We have submitted a statement to IETF that Steve Coya indicated would be posted on IETF's web page. Dinesh -- Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? - T. S. Eliot From rsvp-owner@ISI.EDU Thu Jul 20 08:29:21 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 IAA05240 for ; Thu, 20 Jul 2000 08:29:20 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA04634 for rsvp-outgoing; Thu, 20 Jul 2000 03:46:10 -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 DAA04629 for ; Thu, 20 Jul 2000 03:46:09 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA29518 for ; Thu, 20 Jul 2000 03:46:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12124; Thu, 20 Jul 2000 06:47:04 -0400 (EDT) Message-Id: <200007201047.GAA12124@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rsvp@ISI.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-proxy-01.txt Date: Thu, 20 Jul 2000 06:47:04 -0400 Sender: owner-rsvp@ISI.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Proxy Author(s) : S. Gai, D. Dutt, N. Elfassy, Y. Bernet Filename : draft-ietf-rsvp-proxy-01.txt Pages : 8 Date : 19-Jul-00 RSVP has been extended in several directions [POLICY], [RSVP-APPID], [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable both inside and outside the Integrated Services [INTSERV] model. With the addition of the 'Null Service Type' [NULLSERV], RSVP is also being adopted by mission critical applications that require some form of prioritized service, but cannot quantify their resource requirements. In cases where RSVP cannot travel end-to-end, these applications may still benefit from reservations that are not truly end-to-end, but that are 'proxied' by a network node on the data path between the sender and the receiver(s). RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself) in which an intermediate network node originates the Resv message on behalf of the receiver(s) identified by the Path message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-proxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-proxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-proxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-proxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141601.I-D@ietf.org> --OtherAccess-- --NextPart-- From rsvp-owner@ISI.EDU Fri Jul 21 07:18:37 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 HAA21470 for ; Fri, 21 Jul 2000 07:18:36 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id CAA03104 for rsvp-outgoing; Fri, 21 Jul 2000 02:23:40 -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 CAA03099 for ; Fri, 21 Jul 2000 02:23:39 -0700 (PDT) Received: from web2002.mail.yahoo.com (web2002.mail.yahoo.com [128.11.68.202]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id CAA21807 for ; Fri, 21 Jul 2000 02:24:28 -0700 (PDT) Received: (qmail 20917 invoked by uid 60001); 21 Jul 2000 09:24:37 -0000 Message-ID: <20000721092437.20916.qmail@web2002.mail.yahoo.com> Received: from [161.142.112.8] by web2002.mail.yahoo.com; Fri, 21 Jul 2000 02:24:37 PDT Date: Fri, 21 Jul 2000 02:24:37 -0700 (PDT) From: Junaid Zubairi Subject: CFP Special Session on Interworking of Diffserv, RSVP and MPLS To: rsvp@ISI.EDU Cc: zubairi@cs.fredonia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rsvp@ISI.EDU Precedence: bulk CALL FOR PAPERS Special Session on Interworking of Diffserv, RSVP and MPLS for achieving QoS in the Internet Twelfth IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS 2000) Las Vegas, Nevada, USA November 6-9, 2000 http://www.iasted.com/conferences/2000/lasvegas/pdcscfp.htm (Submission Deadline: August 14, 2000) Scope: The traffic on the Internet is increasingly changing from best-effort to time-sensitive however the Internet is not ready yet for supporting this changing traffic. IETF (Internet Engineering Task Force) is developing new protocols and techniques for supporting QoS (Quality of Service) in private networks as well as the global Internet. Among the new protocols, RSVP provides quantitative guarantees to each flow whereas Diffserv provides qualitative assurances by using PHB (per hop behavior) for packets marked with DSCP (DS codepoints). MPLS has been developed to accelerate routing of traffic aggregates destined towards a common point by using LSP (Label Switched Paths) so that the intermediate routers do not have to make a routing decision. MPLS also leverages the cost of ATM switches by mapping LSP's to VPI/VCI for IP over ATM. A special session on Interworking of these protocols will be organized at the PDCS 2000 conference. This session will serve as a forum to present the latest research and simulation results of works by international researchers, developers, and users. Topics of interest include, but are not limited to: * Integrated operation of Intserv and Diffserv for edge-to-edge QoS flows * Aggregation of flows for scaling of RSVP * VoIP performance over Diffserv networks * Traffic Engineering Architecture for the Internet * Jitter characteristics in a Diffserv domain * Scheduling at nodes in a Diffserv domain * Mapping ATM CoS to Diffserv * Voice over MPLS * Performance of RSVP-MPLS architecture * FR/MPLS Network and service interworking * Inter-provider MPLS signaling and LSP routing * COPS Policy Server/Bandwidth Broker implementation issues Paper Submission Submission should include authors names, affiliations, addresses and email addresses, on the cover page. Submission implies the willingness of at least one of the authors to register and present the paper. Please submit full paper, not exceeding 10 pages in length (single-space) in PS or PDF format for consideration, to session organizer at zubairi@cs.fredonia.edu by August 14, 2000 via email. Include up to 5 keywords and an abstract of no more than 250 words. On a separate sheet, include paper's title, author(s) names and affiliation, postal address, email, fax, and phone numbers. Indicate address for correspondence. Proceedings All papers selected for this session by peer-review process will be published in the PDCS'2000 conference proceedings through IASTED Press, USA. Session Organizer: Dr. Junaid Ahmed Zubairi Department of Mathematics and Computer Science College at Fredonia, State University of New York, Fredonia, NY 14063, USA Tel: +1-716-673-4694 (During summer 2000,Tel: 00-603-2056-4552) Fax: +1-508-256-8324 Email: zubairi@cs.fredonia.edu WWW: http://www.cs.fredonia.edu/~zubairi Important Dates: Draft Papers due on: August 14, 2000 Notification of Acceptance: August 22, 2000 Final Manuscripts and Preregistration due on: September 15, 2000 If you have questions concerning session paper submission or session content, please contact the special session organizer at the address above. If you have questions concerning conference paper submissions or program, please contact Conference Program Co-Chairs: Dr. M. Guizani, University of West Florida, USA, mguizani@cs.uwf.edu or X. Shen, University of Missouri-Kansas City, USA, xshen@cstp.umkc.edu. For further information, see conference web site at http://www.iasted.com/conferences/2000/lasvegas/pdcs.htm. For more information about IASTED or PDCS 2000, please contact: IASTED Secretariat PDCS 2000, #80, 4500 16th Avenue NW, Calgary, Alberta, Canada, T3B 0M6 , Tel: 403-288-1195, Fax: 403-247-6851, Email: calgary@iasted.com, Web: www.iasted.com. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From rsvp-owner@ISI.EDU Fri Jul 21 12:37:29 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 MAA26633 for ; Fri, 21 Jul 2000 12:37:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id HAA16969 for rsvp-outgoing; Fri, 21 Jul 2000 07:40:27 -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 HAA16964 for ; Fri, 21 Jul 2000 07:40:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04610 for ; Fri, 21 Jul 2000 07:41:13 -0700 (PDT) Received: from NSYRACUS ([10.27.5.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16021; Fri, 21 Jul 2000 10:41:08 -0400 (EDT) Date: Fri, 21 Jul 2000 10:44:39 -0400 (Eastern Daylight Time) From: Natalia Syracuse To: Ralph Santitoro cc: internet-drafts@ietf.org, rap@iphighway.com, rsvp@ISI.EDU Subject: Re: Please post attached draft In-Reply-To: Message-ID: X-X-Sender: nsyracus@odin.ietf.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Your drafts will be announced on Monday - Jul, 24th as an individual submission with a filenames are draft-santitoro-rap-policy-errorcodes-00.txt AND draft-santitoro-rap-policy-appids-00.txt Natalia Syracuse On Fri, 14 Jul 2000, Ralph Santitoro wrote: > Please post the attached ID on the Internet Drafts Servers for > distribution to and discussion in the RAP working group of the IETF. > > DATE: July 2000 > > EXPIRES: January 2001 > > WORKING GROUP: RAP > > CHAIR: Andrew Smith, Mark Stevens > > Drafts: > -------------------------------------------------------------------- > > TITLE: draft-ietf-rap-policy-errorcodes-00.txt > > AUTHORS: Ralph Santitoro and Ramesh Pabbati > > Comment: > > This is a new draft. > > > From rsvp-owner@ISI.EDU Fri Jul 21 13:14:50 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 NAA13852 for ; Fri, 21 Jul 2000 13:14:49 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA19126 for rsvp-outgoing; Fri, 21 Jul 2000 08:28:29 -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 IAA19120 for ; Fri, 21 Jul 2000 08:28:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07696; Fri, 21 Jul 2000 08:29:14 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27960; Fri, 21 Jul 2000 11:29:21 -0400 (EDT) Message-Id: <200007211529.LAA27960@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rsvp@ISI.EDU From: The IESG Subject: Protocol Action: RSVP Refresh Overhead Reduction Extensions to Proposed Standard Date: Fri, 21 Jul 2000 11:29:21 -0400 Sender: owner-rsvp@ISI.EDU Precedence: bulk The IESG has approved the Internet-Draft 'RSVP Refresh Overhead Reduction Extensions' as a Proposed Standard. This document is the product of the Resource Reservation Setup Protocol Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document describes a number of mechanisms that can be used in RSVP to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost and, when desired, refreshing state without the transmission of whole refresh messages. The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues. Working Group Summary This document received a careful review by the RSVP working group. The issues with the document have been resolved in this version. Protocol Quality This document was reviewed for the IESG by Scott Bradner Note to RFC Editor: Please remove the "Changes from previous version:" section. From rsvp-owner@ISI.EDU Sun Jul 23 12:26:44 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 MAA07721 for ; Sun, 23 Jul 2000 12:26:44 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id HAA03247 for rsvp-outgoing; Sun, 23 Jul 2000 07:44:30 -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 HAA03242 for ; Sun, 23 Jul 2000 07:44:29 -0700 (PDT) Received: from smtp1.ihug.co.nz (tk1.ihug.co.nz [203.29.160.13]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA04166 for ; Sun, 23 Jul 2000 07:45:14 -0700 (PDT) From: Steve_Chen@hotmail.com Received: from jackwang (p182-tnt1.ham.ihug.co.nz [203.109.160.182]) by smtp1.ihug.co.nz (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA08625; Sun, 23 Jul 2000 19:20:13 +1200 Date: Sun, 23 Jul 2000 19:20:13 +1200 Message-Id: <200007230720.TAA08625@smtp1.ihug.co.nz> To: welcom@welcom.com.tw Subject: ¥xÆW»¶©f±¡¦âºô MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit ¬f«C­ô¤S­«·s¶}¹õ¤F,¦¹¥u´«¤F·s¥D¾÷À³¸Ó¥i¥Hºû«ù¤@¬q«Üªøªº®É¶¡Åo!! ¬f«C­ô²{¦b°£¤Fhttp://www.xheaven.com ¤S¦³¤@­Ó·sªººô§}http://www.twgirl-sex.com ¥xÆW»¶©f±¡¦âºô,¾Ö¦³¶W¤H®ðªº±¡¦â¶K¹Ï°Ï,¤@©]±¡¤Î´©¥æ¸ê°T¥æ¬y°Ï Åwªï¤j®a¨Ó°ÑÆ[!! ¥»¯¸¥t¦³¥þ¥@¬ÉµL½XVCD±M°eªA°È,¤£½×±z¦í¤¤°ê,¥xÆW,¥[®³¤j,¬ü°ê,¯Ã¿D©Î¥ô¦ó¦a¤è §Ú­Ì³£·|±N±zªº­q³f±M°e¨ì©²,¥ý¨É¨ü¬Ý¤ùªº¼ö½ì«á¥I´Ú!! «OÃÒ¥þ³£¬OµL½X¤ù,§ó¦³ºô¸ô¤W³Ì¦hªº°½¿s¤ù¨Ñ±z¿ï¾Ü, ¨C¤ù¬Ò¦³¬Ý«áªº·P·Q»¡©ú,Åý±z§ó®e©ö¿ï³f!! §Ú­Ì¬Oºô¸ô¤W¸gÀç³Ì¤[¡A¦r¸¹³Ì¦Ñ¡A­·µû³Ì¨Î¡A «H¥Î³Ì¦nªº¦¨¤HVCD±M½æ©±,­Y¦³Ãa¤ù«OÃÒ°h´Ú©Î´«¤ù!! ÁÙµ¥¤°»ò§Ö¨Ó¿ï¤ù§a ¥@¬ÉµL½X±M°eVCD http://www.xheaven.com/vcd From rsvp-owner@ISI.EDU Mon Jul 24 09:52:53 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 JAA29166 for ; Mon, 24 Jul 2000 09:52:51 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id DAA05560 for rsvp-outgoing; Mon, 24 Jul 2000 03:57:09 -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 DAA05555 for ; Mon, 24 Jul 2000 03:57:07 -0700 (PDT) Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA16092 for ; Mon, 24 Jul 2000 03:57:53 -0700 (PDT) From: conf@colmar.uha.fr Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA16333; Mon, 24 Jul 2000 12:21:46 +0200 Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07829; Mon, 24 Jul 2000 12:48:52 +0100 (WET DST) Message-Id: <3.0.1.32.20000724135449.009392b0@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 24 Jul 2000 13:54:49 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for papers of ICN'01 & Final program of ECUMN'00 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following : - call for papers of ICN'01 (see 0000,0000,fefehttp://iutsun1.colmar.uha.fr/= ICN01.html ) AND=20 - final program of ECUMN'00 (see= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ECUMN2000.html ) to interested colleagues. Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ---

CALL FOR PAPERS=20 IEEE International Conference on Networking=20 ICN'01=20 July 11-13, 2001 - CREF, Colmar, France=20
GENERAL INFORMATION=20 The 2001 International Conference on Networking (ICN'01) is sponsored by= IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized= by academic, research and industrial societies will be held at the= Technical Institute, Colmar, part of the University of Haute Alsace,= France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of= Colmar is ideally situated in the eastern part of France, near the German= and Swiss borders. The city of Colmar has been working on its own= Metropolitan Area Network (MAN) project, called OASICE, including LAN= interconnection, PBX interconnection and interactive video. An exhibition= illustrating these topics will be organized for industrial companies and= development research institutes.=20 In order to encourage closer interaction between academic and industrial ATM= research communities, we solicit both academic research papers and= industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 =20 Communications switching and routing =20 Communications modeling =20 Communications security =20 Computer communications =20 Multimedia and multicast communications =20 Internet environment =20 Network Management and control =20 Quality of Service (IntServ, DiffServ, =85) =20 Wireless Communications (Satellite, WLL, 3G) =20 Voice over IP =20 Java, Tina, Corba architectures Network signaling =20 ATM networks =20 ATM/IP integration =20 Integrated services =20 Traffic engineering =20 Telecommunication networks architectures =20 Performance evaluation, simulation =20 Mobile agents, active and intelligent networks =20 Applications and case studies =20 Protocol design and evaluation =20 MPLS=20 These topics can be discussed in term of concepts, state of the art,= standards, implementations, running experiments and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four papers or E-mail preferably in Word 6 format, or alternately a= postscript version of a 2000-word extended abstract summarizing an original= work. All the manuscripts must be written in English. The top of the first= page of each paper should include the title of the paper, authors' name,= position, address, telephone and fax numbers, e-mail of the author= responsible for correspondence and a list of four keywords. The deadline= for submission of all extended abstracts is December 10, 2000 with= notification of acceptance by February 20, 2001. Submission of camera-ready= paper is by March 30, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts= for inclusion in the proceedings with ISBN.=20 All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 Check our Web page at= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ICN01.html for the latest information concerning the= conference.=20 Best papers will be forwarded for consideration in a special issue of a= journal.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by December 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort-Montbeliard=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) =96 Mitsubishi=20 J. Crowcroft (UK) =96 University College London=20 S. Fdida (France) =96 LIP6=20 B. Gavish (USA) - Vanderbilt University=20 H. Guyennet (France) - University of Franche-Comte=20 J. Halpern (USA) =96 Newbridge=20 Z. Hulicki (Poland) =96 University of Cracow=20 R. Israel (France) - IEEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy=20 A. Jamalipour (Australia) - University of Sydney=20 S. Kota (USA) - Lockeed Martin=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) =96 Ericsson=20 G.S. Kuo (Taiwan) =96 National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) =96 Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 H.. Mouftah (Canada) - Queen's University=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) =96 Clemessy=20 M. Trehel (France) =96 University of Franche-Comte=20 V.A. Villagra (Spain) =96 University of Madrid=20 E. Vazquez Gallo (Spain) =96 University of Madrid=20 O. Yang (Canada) - University of Ottawa=20 IMPORTANT DATES=20 Extended Abstract due: December 10, 2000=20 Notification of acceptance: February 20, 2001=20 Deadline for full-length camera-ready manuscript: March 30, 2001=20 ---------------------------------------------------------------------------
1st IEEE European Conference on Universal Multiservice= Networks ECUMN'2000 October 2-4, 2000 - CREF, Colmar, France FINAL PROGRAM
=20 08:30 - 18:30 Conference Registration Monday October 2, 2000 09:00 - 09:20 Opening Address=20 09:20 - 10:30 Tutorial Session 1 Internet Services over Mobile and Wireless Networks: Architectures and= Protocols G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,= USA 10:30 - 11:00 Coffee Break 11:00 - 12:15 Network Architecture and Convergence Chair: S. Ritzenthaler, Newbridge, France MPLS and Next Generation Access Network A. Kankkunen, Integral Access Inc, USA Deutsche Telekom's View on Network Convergence L. Falkenhagen Deutsche Telekom AG, Germany A Functional Architecture for End-to-end Quality-of-Service in a= Multi-domain Network E. Pagani, G.P. Rossi, University of Milano, Italy 12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence 13:00 - 14:30 Lunch 14:30 - 16:15 Traffic=20 Chair: M. Villen, Telefonica I+D, Spain The Relevance of the Bufferless Analysis for Traffic Management in= Telecommunication Networks G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,= University of Karlskrona/Ronneby, Sweden Mapping of Loss and Delay Between IntServ and DiffServ T. Chahed, G. H=E9buterne, C. Fayet, National Institute of= Telecommunications, France Resource Demand of Aggregated Resource Reservations J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland Characterization of the MPEG-2 Video Traffic Generated by DVD Applications A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,= University of Mining and Metallurgy, Poland 14:30 - 16:15 Interworking between narrow band and broadband networks Chair: S. Chakraborty, Technical University of Helsinki, Finland Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and= Services Support L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.= Papadopoulos, University of Patras, Greece Extending the Internet with the Intelligent Network Capabilities B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,= France A Suitable Service Discipline for ATM-Ethernet Interconnection J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain Interoperability of ATM-Ethernet Interworking System: Design and Congestion= Control R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,= Tinisia ; K. Torki, INPG, France 16:15 - 16:45 Coffee Break 16:45 - 18:30 Routing Chair: P. Chemouil, France Telecom R&D, France Adaptive Routing and Load Balancing of Ephemeral Connections M. Heusse, ENST de Bretagne, France A new Multi-Services Rerouting Algorithm A. Gueroui, University of Versailles, France ; L. Mokdad University of= Dauphine, France ; J. Ben-Othman University of Paris 6, France Extending Mobile IP-v6 with Multicast to Support Mobile Networks in IPv6 T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola= Labs, France 16:45 - 18:30 Interworking between IP and ATM Chair: M. Potts, Martel, Switzerland Topology Optimization of IP over ATM L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland Resource Reservation with Boomerang via Open Interfaces M. Maliosz, Budapest University of Technology and Economics, Hungary Efficient Translation of Network Performance Parameters for Transport of IP= Packets over Cell-Switched Subnetworks J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,= Germany Design of Adaptive Access Network and Control Protocol H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform= Laboratories, Japan 19:15 Reception - Town Hall Tuesday October 3, 2000 09:00 - 10:45 End to end traffic Control (1) Chair: U. Krieger, Deutsche Telecom, Germany Guaranteed QoS for TCP flows in ATM-based DiffServ Networks T. M=FCller, Dresden University of Technology, Germany Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,= National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,= Taiwan An Efficient Weight Assignment Process for GPS Servers G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des= T=E9l=E9communications, France Some Aspects of RTP - TCP Coexistence in Universal Multiservice Networks R. Chodorek, University of Mining and Metallurgy, Poland 09:00 - 10:45 Mobile Networks and Mobile Services Chair: G. Omidyar, Computer Sciences Corp, USA Voice Enabled Request and Response for Mobile Devices Supporting WAP= Protocol: the Constraints A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian= Institute of Technology, India IP based enhanced Data Casting Services over Radio Broadcast Networks W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,= Germany Location-Dependant and Value Added Services (VAS) for Mobile Communications P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20 The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony= Operators in the Liberalization of Telecommunications D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National= Technical University of Athens, Greece 10:45 - 11:15 Coffee Break 11:15 - 13:00 Multicast Chair: G. Girardi, CSELT, Italy A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain= Multicast Routing Environment M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco A New Routing Algorithm for Delay-Constrained Dynamic Multicast T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.= Tanaka, Waseda University, Japan Remote Time-Alignment of Interactive Services through Efficient Multicast= Algorithms A. Borella, G. Cancellieri, University of Ancona, Italy Key Establishment for IGMP Authentication in IP Multicast T. Hardjono, B. Cain, Nortel Networks, USA 11:15 - 13:00 IP Test-beds Chair: H. Tobiet, NMG, France Real-Time Multimedia Services over Internet A. Benslimane, Technical University of Belfort-Montb=E9liard, France Telephony over IP: Theoretical Modelling and Lab Experiments P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy User-domain Multiservice Architecture for Wired and Wireless IP Networks L. Cheng, I. Marsic, The State University of New Jersey, USA A Testbed Environment for the Performance Evaluation of Modular Network= Architectures D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy 13:00 - 14:30 Lunch 14:30 - 16:15 Modeling Chair: G. H=E9buterne, INT, France Estimation of the Renewal Function by Empiral Data - A Bayesian Approach N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova= Deutsche Telekom, Germany Modeling Access Networks for Quality of Service F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and= Technology, USA ; D.R. Vaman, Megaxess, USA Managing Wireless Internet Information of Electronic Advertising E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,= Tohoku University, Japan Performance Evaluation of a full Memory Multidestination Protocol for= Satellite Based Reliable Multicast with and without Local Recovery H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological= University, Singapore 14:30 - 16:15 Tariffs and Bandwidth Allocation Chair: P. Lorenz, University of Haute Alsace, France INEDAC Project: A Tool to Calculate Interconnection Tariff based on a= Bottom-up Method J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;= R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany Auction Method and its Performance in a Dynamic Bandwidth Allocation Service E. Takahashi, Y. Tanaka, Waseda Universiy, Japan Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video= Streams to Variable Channel Bandwidth H.F. Raynaud, M. Luong, University of Paris Nord, France Robust Topology for Enterprise Networks against Diverse Tariff Structures T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT= Service Integration Laboratories, Japan 16:15 - 16:45 Coffee Break 16:45 - 18:30 End to end Traffic Control (2) Chair: G. H=E9buterne, INT, France An Architecture of QoS Services for a Core Internet Network over DTM C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.= Moreno, University Carlos III of Madrid, Spain Congestion Avoidance for Unicast and Multicast Traffic A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France MPOA and QoS Support in LIS Internetworking Environments I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK A Method for Increasing Throughput based on Packet Striping F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France 16:45 - 18:30 Advanced Networking Chair: G.V. Morson, Cambridge Network, England A New Network Service Environment using Active Network K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan Adaptive Applications over Active Networks: Case Study on Layered Multicast L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium Integrated Performance Monitoring of Client/Server Software C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany Who needs Addresses ? V. Guruprasad, IBM, USA 20:00 Gala Dinner - Restaurant Meistermann Wednesday October 4, 2000 09:00 - 10:00 Tutorial Session 2 Chair: P. Rolin, France Telecom R&D, France Active Networks and its Management M. Brunner, NEC Europe Ltd, Germany 10:00- 10:30 Coffee Break 10:30 - 11:45 New Architectures for New Services Chair: A. Gravey, ENST-Bretagne, France A Novel Architecture for Efficient Protocol Processing in High Speed= Communication Environments G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,= Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,= Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),= Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,= J.A. Sanchez, Lucent Technologies, The Netherlands Using T=E9l=E9domotis Interface for a new Multiservice Network applied to= Monitoring the Elderly T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,= University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,= France Video and Interactive Internet access in a DVB Network R. Jaeger, BetaResearch, Germany 11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services 13:00 - 14:30 Lunch 14:30 Visit of Vialis From rsvp-owner@ISI.EDU Mon Jul 24 16:07:19 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 QAA19785 for ; Mon, 24 Jul 2000 16:07:18 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id KAA16388 for rsvp-outgoing; Mon, 24 Jul 2000 10:56:54 -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 KAA16383 for ; Mon, 24 Jul 2000 10:56:53 -0700 (PDT) Received: from csa.iisc.ernet.in (IDENT:root@csa.iisc.ernet.in [144.16.67.8]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA08940 for ; Mon, 24 Jul 2000 10:57:36 -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 XAA22095 for ; Mon, 24 Jul 2000 23:27:53 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id XAA10317 for ; Mon, 24 Jul 2000 23:27:28 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Mon, 24 Jul 2000 23:27:28 +0530 (IST) From: Gaitonde Anandprasanna To: rsvp@ISI.EDU Subject: Implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk I am currently doing Project in RSVP. This protocol has been implemented in C++. Are there any implementation in C. If yes please give references. _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Tue, 25 Jul 2000 05:12:53 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id AAA01272 for rsvp-outgoing; Tue, 25 Jul 2000 00:31:44 -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 AAA01267 for ; Tue, 25 Jul 2000 00:31:43 -0700 (PDT) Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA09727 for ; Tue, 25 Jul 2000 00:32:30 -0700 (PDT) Received: from gilad8000 (telaviv3-dhcp148.cisco.com [144.254.93.86]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id KAA15456 for ; Tue, 25 Jul 2000 10:32:55 +0300 (IDT) Reply-To: From: "Gilad Zlotkin" To: Subject: unsubscrib gzlotkin@cisco.com Date: Tue, 25 Jul 2000 10:30:46 +0200 Message-ID: <001101bff612$a1f97e30$565dfe90@gilad8000.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit unsubscrib gzlotkin@cisco.com -- Dr. Gilad Zlotkin (mailto:gilad@cisco.com) Director Engineering Enterprise Management Business Unit - Israel Cisco Systems (http://www.cisco.com). -- Tel: 972-9-9700000, Direct Line: 972-9-9700097, Direct Fax: 972-9-9700400 Herziliya Business Park, 4 Maskit St., P.O.Box 12497, Herziliya Pituach 46766, ISRAEL -- From rsvp-owner@ISI.EDU Wed Jul 26 09:44:25 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 JAA13272 for ; Wed, 26 Jul 2000 09:44:25 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id EAA06244 for rsvp-outgoing; Wed, 26 Jul 2000 04:44:35 -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 EAA06239 for ; Wed, 26 Jul 2000 04:44:34 -0700 (PDT) Received: from exchange01.iirltd.co.uk ([193.133.64.178]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA02669; Wed, 26 Jul 2000 04:45:17 -0700 (PDT) Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 12:44:18 +0100 Message-ID: From: Richard Cooper To: Richard Cooper Subject: MPLS Date: Wed, 26 Jul 2000 12:44: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 Hello, You may remember that I sent you an email a few weeks ago regarding the MPLS conference I was working on. Well, I have now finished and printed the prorgamme and I would like to thank all of you who helped with my research or have agreed to speak. The conference will run the 25th-28th of September in London for full details please see the website www.iir-conferences.com/mpls Many Thanks Sarah Jones Senior Conference Producer, Transmission Events IIR Telecoms & Technology 0044 20 7915 5146 0044 20 7915 5001 From rsvp-owner@ISI.EDU Wed Jul 26 20:12:34 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 UAA00760 for ; Wed, 26 Jul 2000 20:12:34 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id PAA22788 for rsvp-outgoing; Wed, 26 Jul 2000 15:29:42 -0700 (PDT) Received: from earthlink.net (ip157.sacramento14.ca.pub-ip.psi.net [38.28.187.157]) by zephyr.isi.edu (8.9.3/8.9.3) with SMTP id PAA22777 for ; Wed, 26 Jul 2000 15:29:38 -0700 (PDT) Message-Id: <200007262229.PAA22777@zephyr.isi.edu> From: "Home Workers" To: Subject: Download FREE Software & Promote Your Business! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 26 Jul 2000 15:16:19 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA22778 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit InterNETACTIVE has sold for $39.95 and more... InterNETACTIVE allows you to post your ad on Classified Sites and Internet Malls for free! InterNETACTIVE reveals what REALLY works to get you top ranking among the most popular search engines. InterNETACTIVE is yours FREE with no strings attached! There is nothing to buy, no special unlock codes and no fine print. This is a one time offer so don't pass it up. Request your free copy of this valuable Windows based software today by emailing us at directpower2k@earthlink.net with "Free Download" in the subject heading. Save valuable time by not having to search for classified sites and malls. InterNETACTIVE makes it a snap to advertise on-line! Direct Marketing Pros From rsvp-owner@ISI.EDU Wed Jul 26 20:12:41 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 UAA00771 for ; Wed, 26 Jul 2000 20:12:39 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id PAA22885 for rsvp-outgoing; Wed, 26 Jul 2000 15:30:07 -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 PAA22880 for ; Wed, 26 Jul 2000 15:30:06 -0700 (PDT) Received: from earthlink.net (ip157.sacramento14.ca.pub-ip.psi.net [38.28.187.157]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA01208 for ; Wed, 26 Jul 2000 15:31:05 -0700 (PDT) Message-Id: <200007262231.PAA01208@tnt.isi.edu> From: "Home Workers" To: Subject: Download FREE Software & Promote Your Business! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 26 Jul 2000 15:16:44 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id PAA22881 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit InterNETACTIVE has sold for $39.95 and more... InterNETACTIVE allows you to post your ad on Classified Sites and Internet Malls for free! InterNETACTIVE reveals what REALLY works to get you top ranking among the most popular search engines. InterNETACTIVE is yours FREE with no strings attached! There is nothing to buy, no special unlock codes and no fine print. This is a one time offer so don't pass it up. Request your free copy of this valuable Windows based software today by emailing us at directpower2k@earthlink.net with "Free Download" in the subject heading. Save valuable time by not having to search for classified sites and malls. InterNETACTIVE makes it a snap to advertise on-line! Direct Marketing Pros From rsvp-owner@ISI.EDU Thu Jul 27 11:49:40 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 LAA22768 for ; Thu, 27 Jul 2000 11:49:39 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id FAA22070 for rsvp-outgoing; Thu, 27 Jul 2000 05:56:26 -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 FAA22065 for ; Thu, 27 Jul 2000 05:56:25 -0700 (PDT) Received: from job8.com (IDENT:carsonwong@[210.176.226.249]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA08946 for ; Thu, 27 Jul 2000 05:57:10 -0700 (PDT) From: carsonwong@job8.com Received: (from carsonwong@localhost) by job8.com (8.9.3/8.9.3) id VAA04833 for rsvp@isi.edu; Thu, 27 Jul 2000 21:06:39 +0800 Date: Thu, 27 Jul 2000 21:06:39 +0800 Message-Id: <200007271306.VAA04833@job8.com> To: rsvp@ISI.EDU Subject: Network finance for webmasters Sender: owner-rsvp@ISI.EDU Precedence: bulk Webmasters, you can earn money here: http://www.gccx.com/public/index.php3?referrer=carsonwong And, get commission from your referrals! It really works! I've got my cheque! ^_^ ------------------------------------------------------------------ This message is sent once only and you need not unsubscribe. Sorry for disturbing you if you are not interested! From rsvp-owner@ISI.EDU Thu Jul 27 16:12:33 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 QAA21393 for ; Thu, 27 Jul 2000 16:12:24 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id KAA16998 for rsvp-outgoing; Thu, 27 Jul 2000 10:32:32 -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 KAA16993 for ; Thu, 27 Jul 2000 10:32:30 -0700 (PDT) Received: from mecnts1.macrotec.com.tw (macrotec.com.tw [203.70.112.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25696 for ; Thu, 27 Jul 2000 10:33:17 -0700 (PDT) Message-Id: <200007271733.KAA25696@venera.isi.edu> Received: from TANG ([210.200.144.218]) by mecnts1.macrotec.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id PBANLF46; Fri, 28 Jul 2000 01:42:13 +0800 From: "CORSA" Reply-To: light777@kimo.com.tw Subject: ±ÀÂË To: light777@ISI.EDU X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Thu, 27 Jul 2000 21:54:00 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ±z»Ý­n¦UºØ³nÅé¶Ü !!!!!! http://tip.nu/abc123 «OÃÒ±z¤£µê¦¹¦æ !!! From rsvp-owner@ISI.EDU Thu Jul 27 16:47:37 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 QAA00828 for ; Thu, 27 Jul 2000 16:47:33 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA23857 for rsvp-outgoing; Thu, 27 Jul 2000 11:49: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 LAA23851 for ; Thu, 27 Jul 2000 11:49:03 -0700 (PDT) Received: from csa.iisc.ernet.in (IDENT:root@csa.iisc.ernet.in [144.16.67.8]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA00884 for ; Thu, 27 Jul 2000 11:49:47 -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 AAA23782 for ; Fri, 28 Jul 2000 00:20:13 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id AAA14252; Fri, 28 Jul 2000 00:19:51 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Fri, 28 Jul 2000 00:19:51 +0530 (IST) From: Gaitonde Anandprasanna To: rsvp@ISI.EDU Subject: RSVP Implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk There is one application called vat which uses RSVP but the one i downloded from the site uses SCRAPI Interface whereas the RSVP protocol code for the linux distribution provides just RAPI Interface That is: for the vat tool when u do it says scrapi.h file not found. and the in the source code of RSVP there is no such file.The source code which i have is the Linux distribution of RSVP on the www.isi.edu/rsvp site and the s/w vat using rsvp is also taken from this site. what do i need to do to run the application on RSVP. I have the rsvp deamon running on the machine which is Linux. Please tell me where i can find proper documentation for installing the software. Or please tell me the necessary changes or modifications. Thanks a lot. Prasanna _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Fri, 28 Jul 2000 09:23:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id EAA09439 for rsvp-outgoing; Fri, 28 Jul 2000 04:48:03 -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 EAA09432 for ; Fri, 28 Jul 2000 04:48:01 -0700 (PDT) Received: from mecnts1.macrotec.com.tw (macrotec.com.tw [203.70.112.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA17644 for ; Fri, 28 Jul 2000 04:48:48 -0700 (PDT) Message-Id: <200007281148.EAA17644@venera.isi.edu> Received: from TANG ([210.200.146.22]) by mecnts1.macrotec.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id PBANLJDQ; Fri, 28 Jul 2000 19:57:44 +0800 From: "orange" Reply-To: sunny22@ms3.seeder.net Subject: ±ÀÂË To: sunny22@ISI.EDU X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Fri, 28 Jul 2000 17:23:31 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk »OÆW¸É©«¶°´²¤¤¤ß¡A¥X²£»P¦¬¶°·s¤ùªº³t«×µ´¹ï¬O²Ä¤@¡A¤j²³¤Æªº»ù®æ¡A³Ì¥R¹êªº¤º®e¡I¥X³f³t«×³Ì§Ö¡I·í¤é¦¬¥ó¡A¹j¤é¥X³f¡I PS.¦Û²£¦Û¾P,»ù®æ¹ê¦b,°â«áªA°È§¹¾ã,½Ðºô¤Í©ñ¤ß!! ½u¤W­qÁÊ½Ð¦Ü http://top.ms/jessy2000 From rsvp-owner@ISI.EDU Sat Jul 29 01:36: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 BAA22137 for ; Sat, 29 Jul 2000 01:36:42 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id UAA02047 for rsvp-outgoing; Fri, 28 Jul 2000 20:51:31 -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 UAA02042 for ; Fri, 28 Jul 2000 20:51:30 -0700 (PDT) Received: from ns1.lnprice.gov.cn ([202.96.65.178]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id UAA15130 for ; Fri, 28 Jul 2000 20:52:11 -0700 (PDT) Received: from bta ([202.106.227.205]) by ns1.lnprice.gov.cn (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 48256928.005E0DAA; Mon, 27 Jul 1970 01:05:58 +0800 From: "isdn" Reply-To: chinaisdn@263.net Message-ID: {EF4BDF10-6332-11D4-B8A5-0050BAA35392}@bta Subject: Ò»Ìõµç»°Ïߣ¬30̨µçÄÔÉÏÍø£¡ To: aaa@ISI.EDU X-Mailer: V3,1,6,1 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 26 Jul 2000 20:31:29 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ´Ë¼þÈô¸øÄú´øÀ´Âé·³,Ôڴ˱íʾÓÉÖÔµØǸÒâ ʹÓÃÒ»Ìõµç»°Ïߣ¬¿ÉÒÔÈÃ30̨µçÄÔͬʱ³ÛƸÔÚÍøÂçÉÏ£¿ Êǵģ¡×¨ÒµµÄÍøÂçÉ豸¡¢³äÅæµÄ´ø¿í¡¢Ç¿´óµÄѹËõ·Ö×é¼¼Êõ£¬¿ÉÒÔ×öµÃµ½£¡ ÎÒÃǹ«Ë¾×¨Òµ´ÓÊ¿í´øÍøÂçµÄ½ÓÈë·þÎñ£¬ÔÚÍøÂç½ÓÈëÉÏÓÐ×Ô¼º¶Àµ½µÄ¼û½â£¬Ä¿Ç°Ö÷Òª¿ªÕ¹ISDN½ÓÈ룬¹«Ë¾²¢²»´ó£¬µ«Ô±¹¤¶¼ºÜרҵºÍ¾´Òµ£¬½áºÏISDNºÍÏÖÔÚÓû§µÄÒªÇó£¬ÎÒÃDzÉÓ÷½±ã¡¢Áé»î¡¢¼á¹ÌµÄ·½°¸½«¹«Ë¾£¬Íø°ÉµÄÏÖÓÐÄÚ²¿ÍøÁªÈëInternet¡£ ISDNËٶȵ¥Í¨µÀ1BΪ64K£¬ÔÚ½ÓÈ뷽ʽÖÐËý²»Ëã×î¿ìµÄ£¬µ«ÊÇËýµÄÐԼ۱Ⱥܸߣ¬Ä¿Ç°¹úÄڴ󲿷ֳÇÊпÉÒÔ¿ªÍ¨£¬ÉêÇë·½±ã£¬ÖÕ¶ËÉ豸ºÍʹÓ÷ÑÓÃÒ²²»¹ó£¬ÔÚÄ¿Ç°ÆÕͨµÄä¯ÀÀºÍÏÂÔØ£¬Êµ¼ùÖ¤Ã÷ËüÊǹ»Óõģ¬´ø¿íµÄÔö¼ÓÐèÒªÒ»²½Ò»²½µÄÀ´£¬µÈµ½¹ãµç»òµçÐŵĿí´øÍø½¨ÉèºÃ£¬¼Û¸ñÒ²ÏÂÀ´ÁË£¬ICPÍƳö×ã¹»¶à¿í´ø½ÚÄ¿£¬ÔÙ»»³ÉCable Modem »òADSL²»³Ù¡£ ÎÒÃÇ¿ÉÒÔΪÄúÌṩISDNÏà¹ØµÄÉ豸ºÍ½â¾ö·½°¸£¬ÓйúÄÚÁ÷ÐеÄTA£¬PC¿¨£¬Â·ÓÉÆ÷£¬»ú·¿¼Ç·ÑϵͳµÈ£¬ÔÚ¹«Ë¾ºÍÍø°ÉʹÓÃISDN½ÓÈëÉÏÓÐ×Ô¼º¶Àµ½µÄ½â¾ö·½°¸£¬Ï£ÍûÄÜΪÄú½â¾ö¼¯ÖÐÉÏÍøºÍ½ÚÊ¡·ÑÓ÷½ÃæÌṩÖܵ½¡¢ÎñʵµÄ·þÎñ¡£ ÏÂÃæÊÇʹÓÃISDN·ÓÉÆ÷ÁªÈëInternet·½°¸µÄһЩÌص㣺 1¡¢½¨Á¢»ùÓÚISDNÏß·µÄ¹²Ïí·þÎñÆ÷¡¢×¨Ó÷ÓÉÆ÷¡¢ÍøÂç½á¹¹²ß»®¡¢°ïÖúÉêÇëISDNÏß·¡£ 2¡¢ÏÖÓоÖÓòÍø¸ÄÔì³É£¬Í¨¹ýÒ»ÌõISDNÏß·£¬Ò»¸öÉÏÍøÕ˺ŷÃÎÊInternet£¬°üÀ¨£º ¹²Ïí·þÎñÆ÷£¬Â·ÓÉÆ÷£¬½Úµã ÄÚ¼ÆËã»úÅäÖã¬Ëٶȹ²Ïí¿ÉÒÔÂú×ãÓû§ÆÕͨä¯ÀÀºÍÏÂÔصÄÐèÒª¡£ 3¡¢¹²Ïí·ÃÎʵÄÓÃ;£¬Ê×ÏÈÊǹ«Ë¾»òÍø°É¿ÉÒÔ´ó´ó½ÚÊ¡Ïß·Ͷ×ʺÍÍøÂçʹÓ÷ѣ¬¿´¿´¹úÄڵĸ÷´ó¹«Ë¾£¬´óÐÍÍø°É ÎÞÒ»²»ÊDzÉÓù²Ïí·½Ê½½ÓÈ뻥ÁªÍøÖУ¬Æä¹ÜÀí·½±ã£¬Ã¿Ô·ÑÓÿɽÚÊ¡Ðí¶à¡£ 4¡¢ÔÚ¹²ÏíµÄ»ù´¡ÉÏ¿ÉÒÔʵÏÖ¸ü¶àµÄÓ¦Ó㬱ÈÈç¿ÉÒԴÄÚ²¿Óʾ֣¬¹«Ë¾ÄÚ²¿ÍùÀ´µç×ÓÓʼþÖ±½Ó¿ÉÒÔͨ¹ýÄÚ²¿Íø ·¢ËÍ£¬ÍâÀ´Óʼþ¿ÉÒÔͨ¹ýÄÚ²¿Óʼþ·þÎñÆ÷¶¨Ê±ÊÕÈ¡£¬ ×Ô¶¯·Ö·¢µ½Ã¿¸öÔ±¹¤ÐÅÏä. 1)ÔÚ¹«Ë¾ÄÚ²¿Óʾִ«Ë͵ç×ÓÓʼþ±£ÃÜÐÔÌرðºÃ¡£ ±ÈÈçÃô¸ÐµÄ¿Í»§×ÊÁÏ£¬ÒªÇóÒµÎñÈËÔ±Ö±½Ó·¢Ë͵½Ïà¹ØÈËÔ±ÓÊÏäÄÚ£¬²»¾­¹ýÍⲿÍø£¬´ó´ó¼õÉÙÃô¸ÐÊý¾Ý¶ªÊ§ ΣÏÕ£¬¸ü¿ÉÒÔÃ÷È·µÄ¼Ç¼Ï·¢ËÍÈ˺ͽÓÊÜÈË£¬°üº¬Ö÷Ì⣬±ãÓÚ¹ÜÀíºÍÊղء£ 2)×Ô¶¯·Ö·¢ÏµÍ³¿ÉÒÔΪ¹«Ë¾½¨Á¢Í³Ò»µç×ÓÓʼþµØÖ·£¬ÎÞÐèÉêÇëÃâ·ÑÐÅÏ䣬Ìá¸ß¹«Ë¾ÕûÌåÐÎÏó£¬Ò²Îª¹ÜÀíÔ±¹¤ ÐżþÌṩÁ˼¼ÊõÊֶΠ5¡¢½¨Á¢Í³Ò»·ÃÎʳö¿Ú£¬Â·ÓÉÆ÷¿ÉÒÔ¼ÓÔØ·À»ðǽ£¬¼È±£Ö¤¹«Ë¾ÍøÂ簲ȫ£¬ÓÖ¿É¿ØÖÆÄÚ²¿·ÃÎÊÕ¾µã£¬·²ÊDz»¾­Ðí¿É µÄÕ¾µã¶¼ÎÞ·¨·ÃÎÊ£¬¶Å¾øÉÏ°àʱ¼äµÄÈËÁ¦¿ÕºÄ£¬Ìá¸ß¹¤×÷ЧÂÊ¡£ 6¡¢¿ÉÒÔ¿ªÍ¨Ô¶³Ì·ÃÎÊ£¬Ô±¹¤Ï°àºó£¬¿ÉÒÔͨ¹ýÊÚȨÕ˺ŵǼ£¬·ÃÎÊÄÚ²¿ÍøÂ磬ʵÏÖÔ¶³Ì°ì¹«¡£ 7¡¢ÊµÏÖ·Ö¹«Ë¾£¬°ìÊ´¦Ô¶³ÌÊý¾Ýʵʱ¹²Ïí£¬½«Á½µØµÄÍøÂçÓÃISDNÕâÖÖ¼Û¸ñ±ãÒË¡¢ËٶȻ¹¿ÉÒԵķ½Ê½Á¬½áÆðÀ´£¬ ´ó´ó¼õÉÙÈ˹¤´«µÝÊý¾Ý×ÊÔ´ÀË·Ñ¡£ Èç¹ûÄú¶ÔÏëÁ˽â¸ü¶àµÄϸ½Ú£¬Çëͨ¹ýÒÔϵķ½·¨ÁªÏµ£¬ÎÒÃǽ«Ñ¸ËÙÏìÓ¦Äú¡£ ÎÒÃdz«µ¼£ºÊ¹ÓÿƼ¼£¬ÏíÊܿƼ¼¡£ ×£¹¤×÷˳Àû ±±¾©¾©Ì©·á¿ÆóÓÐÏÞ¹«Ë¾ Tel:010-86470003,86470004,64172047(ISDN) Fax:010-64150328 Http://www.ip2phone.com.cn sales@ip2phone.com.cn