From rsvp-owner@ISI.EDU Wed Mar 1 10:52: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 KAA05791 for ; Wed, 1 Mar 2000 10:52:29 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA10861 for rsvp-outgoing; Wed, 1 Mar 2000 05:35:07 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA10823 for ; Wed, 1 Mar 2000 05:35:03 -0800 (PST) Received: from smtp1-gw.tp1rc.edu.tw (smtp1-gw.tp1rc.edu.tw [163.28.16.23]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA05872; Wed, 1 Mar 2000 05:35:05 -0800 (PST) Received: from ms.cc.ntu.edu.tw (carrot.ee.ntu.edu.tw [140.112.17.108]) by smtp1-gw.tp1rc.edu.tw (8.9.3/8.9.3) with ESMTP id VAA20173; Wed, 1 Mar 2000 21:29:14 +0800 (CST) (envelope-from r7921031@ms.cc.ntu.edu.tw) Message-ID: <38D4D794.BADFB136@ms.cc.ntu.edu.tw> Date: Sun, 19 Mar 2000 21:35:16 +0800 From: Tommy Li X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: zh-TW,en,de-DE MIME-Version: 1.0 To: rsvp@ISI.EDU, rsvp-test@ISI.EDU CC: Stefano Giorcelli , Martin Karsten Subject: Configuration file in KOM RSVP References: <200002232022.VAA05686@KOM.tu-darmstadt.de> <38B5AA4D.6B40083E@cisco.com> Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: We have downloaded KOM RSVP 1.9 and using FreeBSD 3.4. But we don't understand the exact sementics of the config file. There seems no more detailed documentation in the release. Is anyone know how to configure RSVP Daemon? Thanks a lot! p.s I have tried 'virtual nodes on a single machine' --------------------------------------------- Host A: RSVPD ../simple-tests/rsvp.conf1 recvapi ../simple-tests/rsvp.conf1 130.83.138.134 Host A: RSVPD ../simple-tests/rsvp.conf2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But I encountered a problem when I excuted this command. It seems the address has been used in the first RSVPD process. Host A: RSVPD ../simple-tests/rsvp.conf3 sendapi ../simple-tests/rsvp.conf3 130.83.138.134 From rsvp-owner@ISI.EDU Wed Mar 1 11:25:55 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 LAA06871 for ; Wed, 1 Mar 2000 11:25:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA12721 for rsvp-outgoing; Wed, 1 Mar 2000 06:12:07 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12713 for ; Wed, 1 Mar 2000 06:12:05 -0800 (PST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA07477; Wed, 1 Mar 2000 06:12:08 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id PAA20461; Wed, 1 Mar 2000 15:11:36 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.9.3/8.7.5) id PAA08916; Wed, 1 Mar 2000 15:11:34 +0100 Message-Id: <200003011411.PAA08916@KOM.tu-darmstadt.de> Subject: Re: Configuration file in KOM RSVP In-Reply-To: <38D4D794.BADFB136@ms.cc.ntu.edu.tw> from Tommy Li at "Mar 19, 2000 09:35:16 pm" To: Tommy Li Date: Wed, 1 Mar 2000 15:11:34 +0100 (CET) CC: rsvp@ISI.EDU, rsvp-test@ISI.EDU X-Mailer: ELM [version 2.4ME+ PL66 (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 [Charset big5 unsupported, skipping...] [ I am replying to this message on the rsvp list, as well, but I guess it is more appropriate to discuss such details only on rsvp-test. I would like to ask anybody to direct further questions to rsvp-test only. ] Tommy, first, I want to advise you to upgrade to version 2.0. Among many other features, it is also made easier to configure the compilation process through a small script which is executed when running 'make config'. When you want to use the emulation mode, please make sure that you have compiled the daemon with the setting NETWORK=virt in Makefile.auto. Please also make sure that both configuration files specify different ports for communication with the API (should be set that way in the distribution). If that doesn't help, could you please send me the error message you get? (preferrably by private email then we don't bother the list until we solved the problem). Greetings, Martin From rsvp-owner@ISI.EDU Wed Mar 1 12:44:31 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 MAA09068 for ; Wed, 1 Mar 2000 12:44:29 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA18122 for rsvp-outgoing; Wed, 1 Mar 2000 07:36:38 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA18102 for ; Wed, 1 Mar 2000 07:36:35 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA11797 for ; Wed, 1 Mar 2000 07:36:38 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id JAA28990; Wed, 1 Mar 2000 09:36:35 -0600 Message-Id: <4.2.2.20000301102732.00b26da0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 10:36:37 -0500 To: rsvp@ISI.EDU From: Lou Berger Subject: Working group last call - Refresh Overhead Reduction Cc: lberger@labn.net In-Reply-To: <200002091755.RAA06817@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk The WG last call on draft-ietf-rsvp-refresh-reduct-02.txt closed on Friday. Here is a summary of comments received and planned actions. Only summaries of issues are listed. Please see the list archive for full details. [Adrian Farrel ] 1. Comment/Issue: A number of comments related to intent or asking for clarification. (This includes a number of comments related to Epoch.) - Planned action: Will review related sections and revise or add text where appropriate. 2. Comment/Issue: Some inconsistent wording exists related to (a) handling of Send_TTL with Bundle messages and (b) uniqueness of Message_Identifier values. - Planned action: Fix text. 3. Comment/Issue: Suggested adding a NACK reason code for possible future use. - Planned action: None. (Can be added in future if/when need arises.) 4. Comment/Issue: Adrian provided a nice list of typos. - Planned action: Integrate them. (thank you!) [From: Mayumi Tomikawa ] 5. Comment/Issue: There was some confusion on Section 5.5. - Planned action: Will review section and revise as needed. [in private e-mail] 6. Comment/Issue: Sec 5.3 - section could benefit from "... an example with few RSVP sessions going through 2 routers and with a list of the Srefresh messages." - Planned action: Will add example if time permits. [other planned changes] 7. Request assigned values from IANA, put placeholder values in document. 8. Update Srefresh BNF to reduced duplicate name usage. That's it. Please let us know if I missed your comments. The plan is to issue a new version of the draft incorporating these changes before next week's I-D cutoff. We should then be ready for IETF last call. Lou From rsvp-owner@ISI.EDU Thu Mar 2 01:39: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 BAA27485 for ; Thu, 2 Mar 2000 01:39:33 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA25893 for rsvp-outgoing; Wed, 1 Mar 2000 20:10:43 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA25888 for ; Wed, 1 Mar 2000 20:10:42 -0800 (PST) Received: (from braden@localhost) by boreas.isi.edu (8.8.7/8.8.6) id UAA14426 for rsvp; Wed, 1 Mar 2000 20:10:46 -0800 (PST) Date: Wed, 1 Mar 2000 20:10:46 -0800 (PST) From: Bob Braden Message-Id: <200003020410.UAA14426@boreas.isi.edu> To: rsvp@ISI.EDU Subject: Testing email archiving ... please ignore X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk From rsvp-owner@ISI.EDU Fri Mar 3 18:08: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 SAA11629 for ; Fri, 3 Mar 2000 18:08:43 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA19365 for rsvp-outgoing; Fri, 3 Mar 2000 13:11:56 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19360 for ; Fri, 3 Mar 2000 13:11:55 -0800 (PST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA28983 for ; Fri, 3 Mar 2000 13:11:58 -0800 (PST) Received: from cisco.com (ch2-dhcp134-231.cisco.com [161.44.134.231]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA27184 for ; Fri, 3 Mar 2000 16:11:18 -0500 (EST) Message-ID: <38C02A38.4CA409A9@cisco.com> Date: Fri, 03 Mar 2000 16:10:16 -0500 From: JC Ferguson Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: RSVP-external-mailing-list Subject: ordering of parameters in SENDER_TSPEC and FLOWSPEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit RFC 2210 discusses the format of SENDER_TSPEC, FLOWSPEC, and ADSPEC. In section 3.3, the following is stated regarding order: Data fragments must always appear in an ADSPEC in service_number order. In particular, the default general parameters fragment (service_number 1) always comes first. Within a data fragment, the service-specific data must alway come first, followed by any non-default general parameters which may be present, ordered by parameter_number. The size and structure of the service-specific data is fixed by the service definition, and does not require run-time parsing. The remainder of the fragment, which carries non-default general parameters, varies in size and structure depending on which, if any, of these parameters are present. This part of the fragment must be parsed by examining the per-parameter headers. Can one safely assume that this also applies to the FLOWSPEC (seems implicit in this case by the example in section 3.2.2) and the SENDER_TSPEC? The reasoning is, both of these objects employ the same formats (the service frame filled with parameters) as the ADSPEC, and it would only make sense to make this true for all objects following this format (it would certainly help in writing the code!). thanks, jc -- ============================================================== JC Ferguson "Control for smilers can't be bought" Cisco Systems Inc. email:jcferg@cisco.com / voice:978-244-8671 / fax:978-244-8126 From rsvp-owner@ISI.EDU Sat Mar 4 04:17: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 EAA01254 for ; Sat, 4 Mar 2000 04:17:36 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA13766 for rsvp-outgoing; Fri, 3 Mar 2000 23:13:01 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA13760 for ; Fri, 3 Mar 2000 23:13:00 -0800 (PST) Received: from ns.sdcwave.or.jp ([203.178.32.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA16188 for ; Fri, 3 Mar 2000 23:13:02 -0800 (PST) From: Invest22@mail.com Received: from ryan (aui-tx8c-69.rasserver.net [198.211.190.69]) by ns.sdcwave.or.jp (8.8.8/3.6W) with SMTP id PAA20482; Sat, 4 Mar 2000 15:19:04 +0900 Date: Sat, 4 Mar 2000 15:19:04 +0900 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA00838 for sender422@whynot.net; Sun, 5 March 2000 08:39:36 -0700 (EDT) To: plwer@email.com Subject: Make over $100,000 your first year! Reply-To: sample@whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <6595919_33819976> Sender: owner-rsvp@ISI.EDU Precedence: bulk How would you like to: 1. Work from home and be your own boss. 2. Be involved in a business that requires no selling. 3. Distribute a product that everyone needs. 4. Save enormous amounts on your taxes. 5. Protect all your assets from any liens, levies, or judgments. 6. Learn the secrets of what the rich have known for years. 7. Make 80% profit on every sale, with a minimum of $1000. Profit per sale. 8. Most importantly make over $100,000 your first year! If any of your answers are yes I can help. I will show you how I made over $100,000 in four months time and how I go to the Caribbean 2-3 times per year and get paid for it. I will show you a plan of how to retire for life in two years or less. The first step in this journey is to act now by placing your information at our website with your name, phone #, and the best time to call. There is a nominal investment required. If you are SERIOUS about making a change in your financial future. This opportunity is open to residents of the USA and Canada only. CLICK EITHER LINK BELOW, enter your information at our Website and we will contact you with complete details. Click Here ====>>= http://investors44.homepage.com/index.html or Here ====>> http://216.32.170.10/poetry/taxfreeliving/index.html Legal Stuff: This message was sent in compliance with ALL US state laws with a valid from position, subject header, remove link and contact information with the use of privately owned mail servers. To be removed from our list, please enter your address at our website. From rsvp-owner@ISI.EDU Sat Mar 4 07:12:03 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 HAA02393 for ; Sat, 4 Mar 2000 07:12:02 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id CAA20809 for rsvp-outgoing; Sat, 4 Mar 2000 02:11:25 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA20804 for ; Sat, 4 Mar 2000 02:11:24 -0800 (PST) Received: from PromoMail.com (aui-tx8c-69.rasserver.net [198.211.190.69]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA21612 for ; Sat, 4 Mar 2000 02:11:23 -0800 (PST) Date: Sat, 4 Mar 2000 02:11:23 -0800 (PST) From: Cash Machine To: Message-Id: <419.436590.48842234Cashprogram@email.com> Subject: Free Dell Pentium PC Offer 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 The FUTURE of making money on the internet is here. The worlds first, totally automated system. Making money at the speed of light. Make an INSTANT fortune on the internet WITHOUT EVER TALKING TO ANYONE! CALL NOW: 1 800 680-3686 (24 hr. rec) or visit on at either of our locations on the web http://fortune11.homepage.com/index.html http://216.32.170.10/me/fortune11/index.html To Be Removed From Our List Email Remove@china.com From rsvp-owner@ISI.EDU Sun Mar 5 20:19: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 UAA12994 for ; Sun, 5 Mar 2000 20:19:42 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA03469 for rsvp-outgoing; Sun, 5 Mar 2000 15:09:25 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA03458 for ; Sun, 5 Mar 2000 15:09:22 -0800 (PST) Received: from tweety.cuttingedgemedia.com (tweety.cuttingedgemedia.com [208.32.133.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02453 for ; Sun, 5 Mar 2000 15:09:27 -0800 (PST) Date: Sun, 5 Mar 2000 15:09:27 -0800 (PST) From: freepcoffer@mall.com Received: from ryan (aui-tx8c-69.rasserver.net [198.211.190.69]) by tweety.cuttingedgemedia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id G238DA94; Sat, 4 Mar 2000 04:07:38 -0500 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA07770 for sender422@whynot.net; Sun, 5 March 2000 10:45:09 -0700 (EDT) To: plwer@china.com Subject: Free Dell Pentium Pc Offer! Reply-To: sample@whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <6249262_1190172> Sender: owner-rsvp@ISI.EDU Precedence: bulk INTRODUCING THE Y2K FREE PC Promotion --Interested in a FREE DELL PC? --Want to learn how you can earn $300 bonuses by simply posting flyers in your spare time? --Just visit one of our sites today: http://freepcoffer.homepage.com/index.html http://216.32.170.10/sports/freedellpcforu/index.html Toll Free: 1-800-533-8994 *You are receiving this in response to a recent visit to one of our sites. If You Feel This was sent "unauthorized" or to Remove yourself from this mailing list please email unauthorizedmail@mail.com with "REMOVE" in the subject line. Thanks, -Flyer Promotion Team From rsvp-owner@ISI.EDU Mon Mar 6 05:51: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 FAA01836 for ; Mon, 6 Mar 2000 05:51:28 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA24579 for rsvp-outgoing; Mon, 6 Mar 2000 00:01:46 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA24574 for ; Mon, 6 Mar 2000 00:01:45 -0800 (PST) Received: from mercury.abacus.com.tw ([203.74.224.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA22399 for ; Mon, 6 Mar 2000 00:01:49 -0800 (PST) From: Fortune33@wealth.com Received: from ryan ([63.11.185.215]) by mercury.abacus.com.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000030612291716:2774 ; Mon, 6 Mar 2000 12:29:17 +0800 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA05107 for sender422@whynot.net; Tue, 7 March 2000 05:58:51 -0700 (EDT) To: ert44@china.com Subject: [Fortune Network] You Haven't Joined? Reply-To: sample@whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <633049_64193299> X-MIMETrack: Itemize by SMTP Server on Mercury/ABACUS(Release 5.0.2a (Intl)|23 November 1999) at 2000/03/06 12:29:20 PM, Serialize by Router on Mercury/ABACUS(Release 5.0.2a (Intl)|23 November 1999) at 2000/03/06 04:05:44 PM, Serialize complete at 2000/03/06 04:05:44 PM Date: Mon, 6 Mar 2000 12:29:20 +0800 MIME-Version: 1.0 Sender: owner-rsvp@ISI.EDU Precedence: bulk If You Still Haven't Signed Up For The Fastest Growing And Hottest Totally Automated Retirement Plan On The Web... THEN YOU OBVIOUSLY DON"T UNDERSTAND IT. You Need To Listen To Our Toll Free Recorded Overview 1-800-735-0520 Then... To Register And Begin Collecting Your $50 Cash Machine Visit One Of Our Members Sites Below. http://fortunenets.homepage.com/index.html http://ourfortunecity.homestead.com/ New Members Can Expect Anywhere From $300- $5000 In Their First Week! To Be Removed From Our List Email Remove@china.com From rsvp-owner@ISI.EDU Mon Mar 6 14:09:06 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 OAA19433 for ; Mon, 6 Mar 2000 14:09:05 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA21493 for rsvp-outgoing; Mon, 6 Mar 2000 08:51:15 -0800 (PST) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA21488 for ; Mon, 6 Mar 2000 08:51:14 -0800 (PST) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by venera.isi.edu (8.8.7/8.8.6) with ESMTP id IAA07160 for ; Mon, 6 Mar 2000 08:51:01 -0800 (PST) Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 6 Mar 2000 11:45:34 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CEEF@email.quarrytech.com> From: "Abes, Andi" To: JC Ferguson , RSVP-external-mailing-list Subject: RE: ordering of parameters in SENDER_TSPEC and FLOWSPEC Date: Mon, 6 Mar 2000 11:45:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk There's a minor hitch in your well presented arguments: Both RSPEC's and TSPECS will only carry one service at most. In RSPEC, the receiver asks for a specific reservation, which will only provide one certain service to the session. In TSPEC, only the global token bucket parameter is availabe. The sender does not specify any QoS service. As opposed to them, the ADSPEC actually carries information about the node and the path the session traverses, not just about the session. It is thus carrying information about all the QoS services the node can offer. So the short answer, there's no ordering constraints for RSPEC and TSPEC, since they'll only carry one piece on information. Andi. > -----Original Message----- > From: JC Ferguson [mailto:jcferg@cisco.com] > Sent: Friday, March 03, 2000 4:10 PM > To: RSVP-external-mailing-list > Subject: ordering of parameters in SENDER_TSPEC and FLOWSPEC > > > RFC 2210 discusses the format of SENDER_TSPEC, FLOWSPEC, and > ADSPEC. In > section 3.3, the following is stated regarding order: > > Data fragments must always appear in an ADSPEC in service_number > order. In particular, the default general parameters fragment > (service_number 1) always comes first. > > Within a data fragment, the service-specific data must alway come > first, followed by any non-default general parameters which may be > present, ordered by parameter_number. The size and structure of the > service-specific data is fixed by the service definition, and does > not require run-time parsing. The remainder of the fragment, which > carries non-default general parameters, varies in size and > structure > depending on which, if any, of these parameters are present. This > part of the fragment must be parsed by examining the per-parameter > headers. > > Can one safely assume that this also applies to the FLOWSPEC (seems > implicit in this case by the example in section 3.2.2) and the > SENDER_TSPEC? The reasoning is, both of these objects employ the same > formats (the service frame filled with parameters) as the > ADSPEC, and it > would only make sense to make this true for all objects following this > format (it would certainly help in writing the code!). > > thanks, > jc > > > > -- > ============================================================== > JC Ferguson "Control for smilers can't be bought" > Cisco Systems Inc. > email:jcferg@cisco.com / voice:978-244-8671 / fax:978-244-8126 > From rsvp-owner@ISI.EDU Tue Mar 7 06:44:16 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 GAA02754 for ; Tue, 7 Mar 2000 06:44:16 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA20175 for rsvp-outgoing; Tue, 7 Mar 2000 01:30:29 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA20170 for ; Tue, 7 Mar 2000 01:30:28 -0800 (PST) Received: from mercury.abacus.com.tw ([203.74.224.10]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id BAA12926 for ; Tue, 7 Mar 2000 01:30:29 -0800 (PST) From: Fortune33@wealth.com Received: from ryan ([63.11.185.215]) by mercury.abacus.com.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000030612291716:2774 ; Mon, 6 Mar 2000 12:29:17 +0800 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA05107 for sender422@whynot.net; Tue, 7 March 2000 05:58:51 -0700 (EDT) To: ert44@china.com Subject: [Fortune Network] You Haven't Joined? Reply-To: sample@whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <633049_64193299> X-MIMETrack: Itemize by SMTP Server on Mercury/ABACUS(Release 5.0.2a (Intl)|23 November 1999) at 2000/03/06 12:29:20 PM, Serialize by Router on Mercury/ABACUS(Release 5.0.2a (Intl)|23 November 1999) at 2000/03/07 05:34:30 PM, Serialize complete at 2000/03/07 05:34:30 PM Date: Mon, 6 Mar 2000 12:29:20 +0800 MIME-Version: 1.0 Sender: owner-rsvp@ISI.EDU Precedence: bulk If You Still Haven't Signed Up For The Fastest Growing And Hottest Totally Automated Retirement Plan On The Web... THEN YOU OBVIOUSLY DON"T UNDERSTAND IT. You Need To Listen To Our Toll Free Recorded Overview 1-800-735-0520 Then... To Register And Begin Collecting Your $50 Cash Machine Visit One Of Our Members Sites Below. http://fortunenets.homepage.com/index.html http://ourfortunecity.homestead.com/ New Members Can Expect Anywhere From $300- $5000 In Their First Week! To Be Removed From Our List Email Remove@china.com From rsvp-owner@ISI.EDU Wed Mar 8 10:29:28 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 KAA19192 for ; Wed, 8 Mar 2000 10:29:26 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA06092 for rsvp-outgoing; Wed, 8 Mar 2000 05:06:54 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA06087 for ; Wed, 8 Mar 2000 05:06:53 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id FAA21918; Wed, 8 Mar 2000 05:06:59 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id HAA04650; Wed, 8 Mar 2000 07:06:56 -0600 Message-Id: <4.2.2.20000308074907.00b98a30@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 08:06:52 -0500 To: rsvp@ISI.EDU From: Lou Berger Subject: Re: Working group last call - Refresh Overhead Reduction Cc: lberger@labn.net, braden@ISI.EDU, lixia@cs.ucla.edu In-Reply-To: <4.2.2.20000301102732.00b26da0@mail.labn.net> References: <200002091755.RAA06817@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk We've updated the draft per the last call comments. All changes mentioned below were made with the exception of adding the example to section 5.3. The draft has been submitted. For those who don't want to wait for it to come out, it's available at http://www.labn.net/docs/draft-ietf-rsvp-refresh-reduct-03.txt (change bar version is at http://www.labn.net/docs/diff02-03a.txt.) Once the document comes out in the I-D directories, we should be ready for IETF last call. Lou (and fellow co-authors) At 10:36 AM 3/1/00 -0500, Lou Berger wrote: >The WG last call on draft-ietf-rsvp-refresh-reduct-02.txt closed on >Friday. Here is a summary of comments received and planned actions. Only >summaries of issues are listed. Please see the list archive for full details. > >[Adrian Farrel ] > >1. Comment/Issue: > A number of comments related to intent or asking for clarification. > (This includes a number of comments related to Epoch.) > - Planned action: > Will review related sections and revise or add text where > appropriate. > >2. Comment/Issue: > Some inconsistent wording exists related to (a) handling of Send_TTL > with Bundle messages and (b) uniqueness of Message_Identifier values. > > - Planned action: > Fix text. > >3. Comment/Issue: > Suggested adding a NACK reason code for possible future use. > > - Planned action: > None. (Can be added in future if/when need arises.) > >4. Comment/Issue: > Adrian provided a nice list of typos. > > - Planned action: > Integrate them. (thank you!) > > >[From: Mayumi Tomikawa ] >5. Comment/Issue: > There was some confusion on Section 5.5. > - Planned action: > Will review section and revise as needed. > > >[in private e-mail] >6. Comment/Issue: > Sec 5.3 - section could benefit from "... an example with few RSVP > sessions going through 2 routers and with a list of the Srefresh > messages." > - Planned action: > Will add example if time permits. > > >[other planned changes] >7. Request assigned values from IANA, put placeholder values in document. >8. Update Srefresh BNF to reduced duplicate name usage. > >That's it. Please let us know if I missed your comments. The plan is to >issue a new version of the draft incorporating these changes before next >week's I-D cutoff. We should then be ready for IETF last call. > >Lou From rsvp-owner@ISI.EDU Wed Mar 8 17:49:22 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05285 for ; Wed, 8 Mar 2000 17:49:21 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA29456 for rsvp-outgoing; Wed, 8 Mar 2000 13:09:41 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA29450 for ; Wed, 8 Mar 2000 13:09:39 -0800 (PST) Received: from primdns.tmesystems.com.sg ([203.116.235.226]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18323 for ; Wed, 8 Mar 2000 13:09:43 -0800 (PST) From: TaxSecret@Journal.com Received: from ryan (1Cust253.tnt1.austin2.tx.da.uu.net [63.11.185.253]) by primdns.tmesystems.com.sg (8.9.3/8.8.7) with SMTP id FAA22141; Thu, 9 Mar 2000 05:15:09 +0800 Date: Thu, 9 Mar 2000 05:15:09 +0800 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA03993 for sender422@whynot.net; Thu, 9 March 2000 22:42:40 -0700 (EDT) To: weree@street.com Subject: Wealthy Millionaires Sharing Their Secrets Reply-To: sample@whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <3249953_12747588> Sender: owner-rsvp@ISI.EDU Precedence: bulk Wealthy Millionaires Sharing Their Secrets To Help Minimize There Taxes Visit Our Sites And Get On Their Lists To Take Advantage Of This Free Money Make $1000 A Day Or More From Your Home AND LEARN HOW TO LIVE TAX FREE http://208.156.39.20/~millionairemoneys http://investherenow.homepage.com/index.html Visit Us At Either Location On The Web And Register For Free To Receive A Comprehensive, Three-Part Financial Education Program Which Is Teaching Average Americans How To Make Millions From Their Homes And To Live Tax Free. If you have problems accessing our sites due to a "too many users connected error" please hit the "refresh button about 2 or 3 times and you will get in. To Be Removed Email RemoveMe@wealthtopic.com From rsvp-owner@ISI.EDU Fri Mar 10 06:13:52 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 GAA24563 for ; Fri, 10 Mar 2000 06:13:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA05435 for rsvp-outgoing; Fri, 10 Mar 2000 00:46:27 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA05430 for ; Fri, 10 Mar 2000 00:46:25 -0800 (PST) Received: from www.alic042.com.tw ([210.64.191.1]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id AAA22177 for ; Fri, 10 Mar 2000 00:46:27 -0800 (PST) From: maxcd@ms27.hinet.net Received: from shuakio (tp225-33.dialup.seed.net.tw [139.175.225.33]) by www.alic042.com.tw (8.9.3/8.9.3) with SMTP id BAA01681 for ; Sat, 11 Mar 2000 01:14:38 +0800 (CST) Message-Id: <200003101714.BAA01681@www.alic042.com.tw> Date: ¬P´Á¤­, 10 ¤T¤ë 2000 13:06:31 To: Subject: ¤@­Ó±z¤£¥i¤£ª¾ªº¨Æ Sender: owner-rsvp@ISI.EDU Precedence: bulk ---------------------------------------------------- ¥»¼s§i«Y©e°U­¸¯q³Ð·N¦æ¾P¥N¬°µo¥X,¦p±z¤£·Q¦¬¨ì¦¹¼s§i, ½Ð§Y¨è§R°£,¨Ã½Ð±µ¨ü§Ú­Ìªº¹Dºp. ---------------------------------------------------- ±z¦n¡G ¡@¡@­º¥ý¯¬ºÖ±z¡G·s¦~§Ö¼Ö¡A¸U¨Æ¦p·N¡C ¡@¡@¨Ã¯¬ºÖ±z¡G±¡¤H¸`§Ö¼Ö¡C »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://www.geocities.com/maxcd2001/ --------------------------------------------------------- ½Ð¤£­nª½±µ¦^ÂÐ¥»«H¡A·|¦¬¤£¨ì¡C ¡°¦pªG±z¤£·Q¦A±µ¦¬¥»°T®§¡A½Ðª½±µ«ö¤U­±³o­ÓE-mail¦^«H§Y¥i: maxcd@ms49.url.com.tw?subject=no_mail (½Ð¤£­n§ó§ï¥D¦®) ¦A¦¸¯¬ºÖ±z¡G·sªº¤@¦~¨Æ¨Æ¶¶¤ß¡C %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From rsvp-owner@ISI.EDU Fri Mar 10 19:20: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 TAA25088 for ; Fri, 10 Mar 2000 19:20:29 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA14830 for rsvp-outgoing; Fri, 10 Mar 2000 14:20:15 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14825 for ; Fri, 10 Mar 2000 14:20:13 -0800 (PST) Received: from mailman.cs.ucla.edu (Mailman.CS.UCLA.EDU [131.179.128.30]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id OAA12541 for ; Fri, 10 Mar 2000 14:20:20 -0800 (PST) Received: from hermes.cs.ucla.edu (hermes.cs.ucla.edu [131.179.96.172]) by mailman.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id OAA07298; Fri, 10 Mar 2000 14:20:17 -0800 (PST) Received: from localhost (lanw@localhost) by hermes.cs.ucla.edu (8.9.3/UCLACS-3.0) with ESMTP id OAA14144; Fri, 10 Mar 2000 14:19:21 -0800 (PST) X-Authentication-Warning: hermes.cs.ucla.edu: lanw owned process doing -bs Date: Fri, 10 Mar 2000 14:19:21 -0800 (PST) From: Lan Wang X-Sender: lanw@localhost To: rsvp@ISI.EDU cc: Lixia Zhang , Andreas Terzis Subject: draft-wang-rsvp-state-compression-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi Everyone, We've submitted a revised version of our Internet Draft "RSVP Refresh Overhead Reduction by State Compression". It's available at http://irl.cs.ucla.edu/papers/draft-wang-rsvp-state-compression-03.txt. Below is a list of changes from the previous version of this draft . - Paragraphs that describe the MessageID extension are revised to be consistent with draft-ietf-rsvp-refresh-reduct-03.txt where the extension is defined. - Section 9 is added to compare our state compression scheme with other proposals on RSVP refresh overhead reduction. Lan ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Lan Wang Internet Research Lab lanw@cs.ucla.edu UCLA Computer Science Department From rsvp-owner@ISI.EDU Sat Mar 11 05:34:13 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 FAA17557 for ; Sat, 11 Mar 2000 05:34:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA11877 for rsvp-outgoing; Sat, 11 Mar 2000 00:51:41 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA11870 for ; Sat, 11 Mar 2000 00:51:39 -0800 (PST) Received: from mail.clio.it ([195.60.132.33]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id AAA19421 for ; Sat, 11 Mar 2000 00:51:45 -0800 (PST) Received: from [195.60.129.108] (195.60.129.88) by mail.clio.it with ESMTP (Eudora Internet Mail Server 2.2.2); Sat, 11 Mar 2000 09:50:37 +0100 Mime-Version: 1.0 Message-Id: Date: Sat, 11 Mar 2000 09:52:10 +0100 To: rsvp@ISI.EDU From: Franco Tommasi Subject: two drafts released Content-Type: text/plain; charset="us-ascii" Sender: owner-rsvp@ISI.EDU Precedence: bulk Following suggestions received at the last WG meeting, we wrote two drafts (apologies for the delay). They are now available: draft-tommasi-rsvp-bund-00.txt "Limiting Bundling Delays in RSVP" Changes from draft-tommasi-rsvp-enhan-scalab-01.txt: - Polished references to draft-ietf-rsvp-refresh-reduct-03.txt - Information about 'policies' provided - Comments added draft-tommasi-rsvp-list-compr-00.txt "Compression of RSVP protocol's MESSAGE_ID_LIST objects" Changes from draft-tommasi-rsvp-enhan-scalab-01.txt: - Polished references to draft-ietf-rsvp-refresh-reduct-03.txt - Method's overview added - Compression simplified (only BITMAPs allowed) - Consideration about implementation added - Results of a test program added Greetings Franco Tommasi and Simone Molendini From rsvp-owner@ISI.EDU Sun Mar 12 20:21: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 UAA22319 for ; Sun, 12 Mar 2000 20:21:40 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA01889 for rsvp-outgoing; Sun, 12 Mar 2000 15:16:46 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA01884 for ; Sun, 12 Mar 2000 15:16:45 -0800 (PST) Received: from club.netease.com ([202.103.134.4]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06171 for ; Sun, 12 Mar 2000 15:16:49 -0800 (PST) From: vcd003@mailcity.com Received: from 11 (123.c193.ethome.net.tw [202.178.193.123]) by club.netease.com (Postfix) with SMTP id A595A1C99D9; Mon, 13 Mar 2000 06:54:05 +0800 (CST) To: VCD-Club@club.netease.com, ¹q¼v­Ñ¼Ö³¡@club.netease.com Subject: ³o¸Ìªº¤ù¤lÀ³¦³¾¨¦³³á,¶i¨Ó¬Ý¬Ý,¥]§Aº¡·N,¤@­Ó¥Î¤ß¸gÀ窺ºô¯¸^_^ Date: ¬P´Á¤@, 13 ¤T¤ë 2000 07:01:30 +0800 Message-Id: <36598.292719791665200.105333@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit ¹ï¤£°_,¥´ÂZ¤F!!! ³o¬O¤@«Ê¼s§i«H,¦pªG§A¤£·Q­nª¾¹D¤º®e,½Ð§â¦¹«H¥ó§R°£, ¦p¦³¤£«K,·q½Ð¨£½Ì.... ²Î²Î¤@¤ù70¤¸³á,¾÷¤£¥i¥¢,½Ð§â´¤¨}¾÷³á!! ¥»¯¸°£¤F¦³³Ì·s³Ì£t£¸£µªº°|½u¤ù¥~,ÁÙ¦³¤W¦ÊºØªº¤é¼@, ³ßÅwA¤ù¶Ü?¥»¯¸¦³¶W¹L700¦h³¡ªºA¤ù¨Ñ§A¿ï¾Ü, ÁÙ¦³¤W¦ÊºØªº¤é¼@,ÁÙ¦³«Ü¦h¤H³ß·Rªº¦â±¡¥d³q,·R¬Ý´ä¼@¶Ü?§Ú­Ì¤ ]¦³´ä¼@³á!!! ÁÙ¦³¼Æ¤QºØªº¥d³q,ÁÙ¦³³Ì·s³Ì´Îªº­µ¼Ö³á!¯uªº¥i¥H»¡À³¦³¾¨¦³³á , «K©yªº»ù®æ,Àu¨qªº«~½è,¨}¦nªº°â«áªA°È!! ¤£¯à¿ù¹L,»°§Ö¨Ó¤j®a³£³ßÅwªºVCD Club¬Ý¬Ý§a,«OÃҭȦ^²¼»ù. ¤S¬O·sªº¤@¦~ªº¶}©l.§Ú­Ì¤@¦p¥H«eªº¼ö§Õ,¤@­Ó¥Î¤ß¸gÀ窺ºô¯¸!! http://start.at/vcdclub http://w3.to/vcdclub http://98.to/vcdclub From rsvp-owner@ISI.EDU Mon Mar 13 13:32: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 NAA02047 for ; Mon, 13 Mar 2000 13:32:36 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA29061 for rsvp-outgoing; Mon, 13 Mar 2000 03:16:13 -0800 (PST) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29056 for ; Mon, 13 Mar 2000 03:16:11 -0800 (PST) Received: from xg.hb.cninfo.net ([202.103.44.143]) by gamma.isi.edu (8.8.7/8.8.6) with ESMTP id DAA08433 for ; Mon, 13 Mar 2000 03:16:12 -0800 (PST) From: vcd003@mailcity.com Received: from 11 by xg.hb.cninfo.net (8.8.7/SMI-SVR4) id KAA12542; Mon, 13 Mar 2000 10:34:10 +0800 (CST) To: VCD-Club@mailcity.com, ¹q¼v­Ñ¼Ö³¡@mailcity.com Subject: ³o¸Ìªº¤ù¤lÀ³¦³¾¨¦³³á,¶i¨Ó¬Ý¬Ý,¥]§Aº¡·N,¤@­Ó¥Î¤ß¸gÀ窺ºô¯¸^_^ Date: ¬P´Á¤@, 13 ¤T¤ë 2000 11:10:46 +0800 Message-Id: <36598.465817129632300.197684@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit ¹ï¤£°_,¥´ÂZ¤F!!! ³o¬O¤@«Ê¼s§i«H,¦pªG§A¤£·Q­nª¾¹D¤º®e,½Ð§â¦¹«H¥ó§R°£, ¦p¦³¤£«K,·q½Ð¨£½Ì.... ²Î²Î¤@¤ù70¤¸³á,¾÷¤£¥i¥¢,½Ð§â´¤¨}¾÷³á!! ¥»¯¸°£¤F¦³³Ì·s³Ì£t£¸£µªº°|½u¤ù¥~,ÁÙ¦³¤W¦ÊºØªº¤é¼@, ³ßÅwA¤ù¶Ü?¥»¯¸¦³¶W¹L700¦h³¡ªºA¤ù¨Ñ§A¿ï¾Ü, ÁÙ¦³¤W¦ÊºØªº¤é¼@,ÁÙ¦³«Ü¦h¤H³ß·Rªº¦â±¡¥d³q,·R¬Ý´ä¼@¶Ü?§Ú­Ì¤ ]¦³´ä¼@³á!!! ÁÙ¦³¼Æ¤QºØªº¥d³q,ÁÙ¦³³Ì·s³Ì´Îªº­µ¼Ö³á!¯uªº¥i¥H»¡À³¦³¾¨¦³³á , «K©yªº»ù®æ,Àu¨qªº«~½è,¨}¦nªº°â«áªA°È!! ¤£¯à¿ù¹L,»°§Ö¨Ó¤j®a³£³ßÅwªºVCD Club¬Ý¬Ý§a,«OÃҭȦ^²¼»ù. ¤S¬O·sªº¤@¦~ªº¶}©l.§Ú­Ì¤@¦p¥H«eªº¼ö§Õ,¤@­Ó¥Î¤ß¸gÀ窺ºô¯¸!! http://start.at/vcdclub http://w3.to/vcdclub http://98.to/vcdclub From rsvp-owner@ISI.EDU Mon Mar 13 17:29:46 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 RAA02748 for ; Mon, 13 Mar 2000 17:29:45 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA25005 for rsvp-outgoing; Mon, 13 Mar 2000 11:56:36 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA25000 for ; Mon, 13 Mar 2000 11:56:34 -0800 (PST) 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 LAA15258; Mon, 13 Mar 2000 11:56:36 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA04675; Mon, 13 Mar 2000 19:56:35 GMT Date: Mon, 13 Mar 2000 19:56:35 GMT Message-Id: <200003131956.TAA04675@gra.isi.edu> To: sob@harvard.edu Subject: draft-ietf-rsvp-refresh-reduct-02.txt Cc: rsvp@ISI.EDU, lixia@cs.ucla.edu, lberger@labn.net, braden@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Scott, The Working Group Last Call having successfully concluded, the RSVP Working Group would like to submit the "Refresh Overhead Reduction Extension" draft to the IESG to become a Proposed Standard. Bob Braden Lixia Zhang From rsvp-owner@ISI.EDU Tue Mar 14 06:32:22 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24948 for ; Tue, 14 Mar 2000 06:32:21 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA23276 for rsvp-outgoing; Tue, 14 Mar 2000 01:09:34 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA23271 for ; Tue, 14 Mar 2000 01:09:32 -0800 (PST) Received: from tid.es (tidos.tid.es [193.145.240.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA10911 for ; Tue, 14 Mar 2000 01:09:27 -0800 (PST) Received: from tid.es (tag [1.0.9.164]) by tid.es (8.9.3/8.9.1) with ESMTP id KAA16669 for ; Tue, 14 Mar 2000 10:05:08 +0100 (MET) Posted-Date: Tue, 14 Mar 2000 10:05:08 +0100 (MET) Message-ID: <38CE01D7.7BE0873A@tid.es> Date: Tue, 14 Mar 2000 10:09:44 +0100 From: Teresa Ariste Organization: Telefónica I+D X-Mailer: Mozilla 4.06 [es] (Win95; I) MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: unsuscribe References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB77A14169DDA902DCF054517" Sender: owner-rsvp@ISI.EDU Precedence: bulk Iste es un mensaje firmado criptograficamente en formato MIME. --------------msB77A14169DDA902DCF054517 Content-Type: multipart/mixed; boundary="------------89D001A4BC4E8B08E40A04C4" Este es un mensaje multipartes en formato MIME. --------------89D001A4BC4E8B08E40A04C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsuscribe -- +--------------------------------------------------------+ | #### Teresa Ariste Gonzalez | | #### VideoTelephony Services Division | | #### Telefonica I+D C./ Emilio Vargas, 6 | | ==== E-28043 Madrid, Spain | | ==== mailto:tariste@tid.es Tlf +34-1-337 45 87 | | ==== FAX +34-1-337 45 02 | +--------------------------------------------------------+ --------------89D001A4BC4E8B08E40A04C4 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Tarjeta de Teresa Ariste Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Teresa Ariste n: Ariste;Teresa org: Telefonica I+D adr;dom: VideoTelephony Services;;Recinto 357-O;;;; email;internet: tariste@tid.es title:
tel;work: +34913374587 tel;fax: +34913374502 x-mozilla-cpt: ;-2816 x-mozilla-html: FALSE version: 2.1 end: vcard --------------89D001A4BC4E8B08E40A04C4-- --------------msB77A14169DDA902DCF054517 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma criptográfica S/MIME Content-Transfer-Encoding: base64 MIIDsgYJKoZIhvcNAQcCoIIDozCCA58CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC AkQwggJAMIIBqaADAgECAgIEFzANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJFUzEMMAoG A1UEChMDVElEMREwDwYDVQQLEwhQZXJzb25hbDEcMBoGA1UEAxMTQ0VSVElGSUNBRE8gSU5U RVJOTzAeFw0wMDAzMDIwNzE2MDdaFw0wMTAzMDIwNzE2MDdaMIGKMQswCQYDVQQGEwJFUzEM MAoGA1UEChMDVElEMREwDwYDVQQLEwhQRVJTT05BTDEXMBUGCgmSJomT8ixkAQETB1RBUklT VEUxIjAgBgNVBAMTGU0uIFRFUkVTQSBBUklTVEUgR09OWkFMRVoxHTAbBgkqhkiG9w0BCQEW DnRhcmlzdGVAdGlkLmVzMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANqC9j/YKNjxVYtA5Lmf MmdTc73hz047w2iUJQBMtRyu1/foJgl3kVcenca70wTW+xEAy84rQQm/WgGU6e0P/aECAwEA AaM2MDQwEQYJYIZIAYb4QgEBBAQDAgCwMB8GA1UdIwQYMBaAFCm2UVr/fsja/0H3L4IKyTaL Uww1MA0GCSqGSIb3DQEBBAUAA4GBANG7lNLqQR/MZihfTCWSLm0XxRtqwEq9IJdNGZ5TQMUx xXR9fe3lWZxh4YA2HtttVDsJEv8s6Vxwc1tEkxB2NKn5YKsvWGOHUeKCJ47jJ94FKG+qeckV E8x3bvj2Erm+TXJrqOj8Nz7qj9ASALxMPpmzoE0K/SI/8jxbdOXs7o5OMYIBNjCCATICAQEw UjBMMQswCQYDVQQGEwJFUzEMMAoGA1UEChMDVElEMREwDwYDVQQLEwhQZXJzb25hbDEcMBoG A1UEAxMTQ0VSVElGSUNBRE8gSU5URVJOTwICBBcwCQYFKw4DAhoFAKB9MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDMxNDA5MDk0NVowHgYJKoZIhvcN AQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUIGp7lcRUpjmp3HVQ7YYl M59kViYwDQYJKoZIhvcNAQEBBQAEQAkpN0ojARx5zGCq6fZuPMyb1IXXQuCYySo0FNvcHE2P JgCnbScGviNekWSA0GCciejabN8ifTsQ32FxUpExb6c= --------------msB77A14169DDA902DCF054517-- From rsvp-owner@ISI.EDU Wed Mar 15 08:50:51 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 IAA27854 for ; Wed, 15 Mar 2000 08:50:51 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA21482 for rsvp-outgoing; Wed, 15 Mar 2000 03:25:36 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA21477 for ; Wed, 15 Mar 2000 03:25:34 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA29543 for ; Wed, 15 Mar 2000 03:25:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29796; Wed, 15 Mar 2000 06:25:41 -0500 (EST) Message-Id: <200003151125.GAA29796@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-refresh-reduct-03.txt Date: Wed, 15 Mar 2000 06:25:41 -0500 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 Refresh Overhead Reduction Extensions Author(s) : L. Berger, D. Gan et.al Filename : draft-ietf-rsvp-refresh-reduct-03.txt Pages : 34 Date : 14-Mar-00 This document describes a number of mechanisms that can be used 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-03.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-refresh-reduct-03.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-refresh-reduct-03.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: <20000314133224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-refresh-reduct-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-refresh-reduct-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314133224.I-D@ietf.org> --OtherAccess-- --NextPart-- From rsvp-owner@ISI.EDU Wed Mar 15 13:44: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 NAA29788 for ; Wed, 15 Mar 2000 13:44:31 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA00817 for rsvp-outgoing; Wed, 15 Mar 2000 08:11:47 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00812 for ; Wed, 15 Mar 2000 08:11:46 -0800 (PST) Received: from tpts5.seed.net.tw (tpts5.seed.net.tw [139.175.55.241]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA25608 for ; Wed, 15 Mar 2000 08:11:49 -0800 (PST) Received: from sj2-23.dialup.seed.net.tw ([211.74.2.23] helo=tp218-15.dialup.seed.net.tw) by tpts5.seed.net.tw with smtp (SEEDNet Mail Server v2.313f) id 12VGOP-0006yF-00 for rsvp@isi.edu; Thu, 16 Mar 2000 00:11:29 +0800 Received: by tp218-15.dialup.seed.net.tw with Microsoft Mail id <01BF8EDB.C5317CC0@tp218-15.dialup.seed.net.tw>; Thu, 16 Mar 2000 00:08:34 +0800 Message-ID: <01BF8EDB.C5317CC0@tp218-15.dialup.seed.net.tw> From: DAVID To: "'rsvp@isi.edu'" Subject: =?Big5?Q?=C2=E0=B1H_=3A_important?= Date: Wed, 15 Mar 2000 23:52:06 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BF8EDB.C5317CC0" Sender: owner-rsvp@ISI.EDU Precedence: bulk ------ =_NextPart_000_01BF8EDB.C5317CC0 Content-Type: text/plain; charset="Big5" Content-Transfer-Encoding: base64 DQoNCi0tLS0treypbLZspfMtLS0tLQ0KsUil86rMOglaWURFQyBbU01UUDoxMjIxOUB6eWRlYy5j b20udHddDQq2x7Blrsm2oToJMjAwMKZ+M6TrMTWk6UFNIDExOjI1DQqmrKXzqsw6CXpvZTsgUkVH SU5BOyBQYXJpcyBMaW47IDAzMDIwMDY7IDAzMDIwMDU7IDAzMDIwMDQ7IDAzMDIwMDM7IDAzMDIw MDENCqVEpq46CUZ3OiBpbXBvcnRhbnQNCg0KID4NCj4gPiCxYbXbt1Kk36RApMGxTqZwxEClSMB2 oUmmcKpHs2+sT6RAq8qxYbXbr6y61qq6q0ihQafaxEC3TrFOr6y61sBItdsNCj4gPkUtTUFJTA0K PiA+p2m2RKfaqrqqQqTNoUHEQLF6sLexZKFCpa2mdw0KPiA+ILNvq8qrSKxPtbmnQbBlpFembrlC qrqhQbNvutinQKprtW+3vanzrV6u5sT1oUGlpqR3uGfCtqZhsnkgwuCkRqRRDQo+ID6muKFBsnsN Cj4gPqZipm65QqW/sWG1uadBoUGmcKpHt9O/7KFBp0GxTqZipXyk0aSnpLql5qRXpm65QqFBs2+k o6xPtn2qsa+6oUGnQaRAqXel5qRXDQo+pm4NCj4gPrlCoUGko61usUi/+qFBpl2ssKlSuUKsT7VM u/mquqFBpKOtbrFOq0imqanjoUGnQaRAqXemYjk2pHCuyaSnpLqxTqa5q0iy5g0KPqTioUMNCj4g PrXhq9+7q6q6pvOkzC66+6VPp8amrKjss2+8y6q6q0ihQaVMqFOoz7jTq0ipUMLgoUGlTKWipWik RqVMqrqpZKRsNTCk0aFBIA0KPqvhDQo+qNMNCj4gPqVMt9O/7KRGoUGmYqVMqWSkbMF7prqkp6tl oUGlTLFvqOykRjc3NzWtXsLpoUMNCj4gPr3Qp0GxTqa5q0i9xrtzMjCryqjDsUilWKFBrN2s3TSk 0aSnpLqxTrVvpc2ksLvyoUizb6vKq0il0atuq0RERbHQsM+qurHQDQo+ID6lRK/BurgupneqRqWn sF+v86FBqMOl0br7paevUbVvpVihQaZdrLCzb6tIqrq9xrtzpfOtbqZipUCsyalQwuChQadBpECp d61usU4NCj4gPqVMvca7czIwpMCow7FItbmmbqpCpM2hQbRYpNGr4aFBsU6ms6RAqKOoz6dBxeWp X6q6qMal87Vvpc2hQadZqM+nQaSjsGerSKFBDQo+s28NCj4gPqRdrE+kZK91uFW9VKq6oUMNCj4g PiCqYLdOpFWtsaq6qMa56qFHDQo+ID4xOTg3pn6xZLS1qVqkQi682rS1sbWo7LNvvMuquqtIoUGl TMX9r7Wu0b3Gu3MyMKX3qMOxSKVYoUG0WKTRq+GhQaVMsW+o7CANCj6kRg0KPqRADQo+ID61pzIw MDAwMDCtXsLpqrqxbajpoUMNCj4gPq1esOqquqz5qPes26Z+q0Oquq7JrdShQaasqOyrSCCr4aVM p9GkRjk2pHCuyaS6sUilWKFBpUykQKZBpaK3fqFBq+Go06VMDQo+ID6n5KjspEa406tIoUGl36dZ vca7c6jDsUilWDIwoUGkVKTRpKer4aFBpUzA8rFvpEbE0qS6pECt07Cqr8XCvqbsoUGqvabcs8yr 4Q0KPqVMDQo+ID6mqKywrV6w6rLEpEC4uaRIqquhQw0KPiA+ILPSrdu6uK7juri8d6asqOymuatI q+Gko6SprNurSKFBsU6rSKXhsfOhQaVMprqkRqFDDQo+ID4gMTk4N6Z+pVunUbrWpaeoyKRApuyw /KRIpqyo7LNvvMuquqtIoUGmb8H2qE2k37FOprmrSK2rpbSkQKvKsUilWKFBpv0NCj4gPqZvq+EN Cj4gPqjTqFOms7fTsLWhQaZvuEmo7KZVpqGmVbzLqrqzwrfQoUGlXaxBquGr3KZov/qt17J6qFSo rqFBpm+r4ajTrau3c6W0pkyow7FIDQo+pVgNCj4gPqRGuNOrSKFBpm/A8rFvpEakQL34ufG3c6q6 pHDD4qiuoUENCj4gPiC90LBPpu2ko61usUi/+qFJpKOtbqSjsnqzb6vKq0ihSQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdldCBZb3Vy IFByaXZhdGUsIEZyZWUgRW1haWwgYXQgaHR0cDovL3d3dy5ob3RtYWlsLmNvbQ0KDQoNCg== ------ =_NextPart_000_01BF8EDB.C5317CC0 Content-Type: text/html; name="ATT00001.html" Content-Transfer-Encoding: quoted-printable
>
> > = =B1a=B5=DB=B7R=A4=DF=A4@=A4=C1=B1N=A6p=C4@=A5H=C0v=A1I=A6p=AAG=B3o=ACO=A4= @=AB=CA=B1a=B5=DB=AF=AC=BA=D6=AA=BA=ABH=A1A=A7=DA=C4@=B7N=B1N=AF=AC=BA=D6= =C0H=B5=DB
>=20 >E-MAIL
> = >=A7i=B6D=A7=DA=AA=BA=AAB=A4=CD=A1A=C4@=B1z=B0=B7=B1d=A1B=A5=AD=A6w> > = =B3o=AB=CA=ABH=ACO=B5=B9=A7A=B0e=A4W=A6n=B9B=AA=BA=A1A=B3o=BA=D8=A7@=AAk=B5= o=B7=BD=A9=F3=AD^=AE=E6=C4=F5=A1A=A5=A6=A4w=B8g=C2=B6=A6a=B2y=20 =C2=E0=A4F=A4Q
> >=A6=B8=A1A=B2{
>=20 >=A6b=A6n=B9B=A5=BF=B1a=B5=B9=A7A=A1A=A6p=AAG=B7=D3=BF=EC=A1A=A7A=B1N=A6= b=A5|=A4=D1=A4=A7=A4=BA=A5=E6=A4W=A6n=B9B=A1A=B3o=A4=A3=ACO=B6}=AA=B1=AF=BA= =A1A=A7A=A4@=A9w=A5=E6=A4W
>=A6n
>=20 >=B9B=A1A=A4=A3=ADn=B1H=BF=FA=A1A=A6]=AC=B0=A9R=B9B=ACO=B5L=BB=F9=AA=BA= =A1A=A4=A3=ADn=B1N=ABH=A6=A9=A9=E3=A1A=A7A=A4@=A9w=A6b96=A4p=AE=C9=A4=A7=A4= =BA=B1N=A6=B9=ABH=B2=E6
>=A4=E2=A1C
>=20 >=B5=E1=AB=DF=BB=AB=AA=BA=A6=F3=A4=CC.=BA=FB=A5O=A7=C6=A6=AC=A8=EC=B3o= =BC=CB=AA=BA=ABH=A1A=A5L=A8S=A8=CF=B8=D3=ABH=A9P=C2=E0=A1A=A5L=A5=A2=A5h=A4= F=A5L=AA=BA=A9d=A4l50=A4=D1=A1A
>=AB=E1
>=A8=D3
>=20 >=A5L=B7=D3=BF=EC=A4F=A1A=A6b=A5L=A9d=A4l=C1{=A6=BA=A4=A7=ABe=A1A=A5L=B1= o=A8=EC=A4F7775=AD^=C2=E9=A1C
>=20 >=BD=D0=A7A=B1N=A6=B9=ABH=BD=C6=BBs20=AB=CA=A8=C3=B1H=A5X=A1A=AC=DD=AC= =DD4=A4=D1=A4=A7=A4=BA=B1N=B5o=A5=CD=A4=B0=BB=F2=A1H=B3o=AB=CA=ABH=A5=D1=AB= n=ABDDE=B1=D0=B0=CF=AA=BA=B1=D0
>=20 >=A5D=AF=C1=BA=B8.=A6w=AAF=A5=A7=B0_=AF=F3=A1A=A8=C3=A5=D1=BA=FB=A5=A7= =AFQ=B5o=A5X=A1A=A6]=AC=B0=B3o=ABH=AA=BA=BD=C6=BBs=A5=F3=ADn=A6b=A5@=AC=C9= =A9P=C2=E0=A1A=A7A=A4@=A9w=ADn=B1N
>=20 >=A5L=BD=C6=BBs20=A4=C0=A8=C3=B1H=B5=B9=A6n=AAB=A4=CD=A1A=B4X=A4=D1=AB= =E1=A1A=B1N=A6=B3=A4@=A8=A3=A8=CF=A7A=C5=E5=A9_=AA=BA=A8=C6=A5=F3=B5o=A5=CD= =A1A=A7Y=A8=CF=A7A=A4=A3=B0g=ABH=A1A
>=B3o
> = >=A4]=ACO=A4d=AFu=B8U=BDT=AA=BA=A1C
>=20 > =AA`=B7N=A4U=AD=B1=AA=BA=A8=C6=B9=EA=A1G
> = >1987=A6~=B1d=B4=B5=A9Z=A4B.=BC=DA=B4=B5=B1=B5=A8=EC=B3o=BC=CB=AA=BA=AB= H=A1A=A5L=C5=FD=AF=B5=AE=D1=BD=C6=BBs20=A5=F7=A8=C3=B1H=A5X=A1A=B4X=A4=D1= =AB=E1=A1A=A5L=B1o=A8=EC=20
>=A4F
>=A4@
> = >=B5=A72000000=AD^=C2=E9=AA=BA=B1m=A8=E9=A1C
> = >=AD^=B0=EA=AA=BA=AC=F9=A8=F7=AC=DB=A6~=ABC=AA=BA=AE=C9=AD=D4=A1A=A6=AC= =A8=EC=ABH=20 =AB=E1=A5L=A7=D1=A4F96=A4p=AE=C9=A4=BA=B1H=A5X=A1A=A5L=A4@=A6A=A5=A2=B7~=A1= A=AB=E1=A8=D3=A5L
>=20 >=A7=E4=A8=EC=A4F=B8=D3=ABH=A1A=A5=DF=A7Y=BD=C6=BBs=A8=C3=B1H=A5X20=A1= A=A4T=A4=D1=A4=A7=AB=E1=A1A=A5L=C0=F2=B1o=A4F=C4=D2=A4=BA=A4@=AD=D3=B0=AA= =AF=C5=C2=BE=A6=EC=A1A=AA=BD=A6=DC=B3=CC=AB=E1
>=A5L
>=20 >=A6=A8=AC=B0=AD^=B0=EA=B2=C4=A4@=B8=B9=A4H=AA=AB=A1C
> > = =B3=D2=AD=DB=BA=B8=AE=E3=BA=B8=BCw=A6=AC=A8=EC=A6=B9=ABH=AB=E1=A4=A3=A4=A9= =AC=DB=ABH=A1A=B1N=ABH=A5=E1=B1=F3=A1A=A5L=A6=BA=A4F=A1C
> >=20 1987=A6~=A5[=A7Q=BA=D6=A5=A7=A8=C8=A4@=A6=EC=B0=FC=A4H=A6=AC=A8=EC=B3o=BC= =CB=AA=BA=ABH=A1A=A6o=C1=F6=A8M=A4=DF=B1N=A6=B9=ABH=AD=AB=A5=B4=A4@=AB=CA= =B1H=A5X=A1A=A6=FD
> >=A6o=AB=E1
>=20 >=A8=D3=A8S=A6=B3=B7=D3=B0=B5=A1A=A6o=B8I=A8=EC=A6U=A6=A1=A6U=BC=CB=AA= =BA=B3=C2=B7=D0=A1A=A5]=ACA=AA=E1=AB=DC=A6h=BF=FA=AD=D7=B2z=A8T=A8=AE=A1A= =A6o=AB=E1=A8=D3=AD=AB=B7s=A5=B4=A6L=A8=C3=B1H
>=A5X
>=20 >=A4F=B8=D3=ABH=A1A=A6o=C0=F2=B1o=A4F=A4@=BD=F8=B9=F1=B7s=AA=BA=A4p=C3= =E2=A8=AE=A1A
> >=20 =BD=D0=B0O=A6=ED=A4=A3=ADn=B1H=BF=FA=A1I=A4=A3=ADn=A4=A3=B2z=B3o=AB=CA=AB= H=A1I

______________________________________________________
Ge= t=20 Your Private, Free Email at http://www.hotmail.com

<= /BODY> ------ =_NextPart_000_01BF8EDB.C5317CC0-- From rsvp-owner@ISI.EDU Wed Mar 15 15:01:13 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 PAA02004 for ; Wed, 15 Mar 2000 15:01:10 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA05374 for rsvp-outgoing; Wed, 15 Mar 2000 10:08:18 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA05369 for ; Wed, 15 Mar 2000 10:08:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA10961 for ; Wed, 15 Mar 2000 10:08:24 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14712; Wed, 15 Mar 2000 13:08:21 -0500 (EST) Message-Id: <200003151808.NAA14712@ietf.org> To: IETF-Announce: ; Cc: rsvp@ISI.EDU From: The IESG SUBJECT: Last Call: RSVP Refresh Overhead Reduction Extensions to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 15 Mar 2000 13:08:21 -0500 Sender: owner-rsvp@ISI.EDU Precedence: bulk The IESG has received a request from the Resource Reservation Setup Protocol Working Group to consider RSVP Refresh Overhead Reduction Extensions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 5, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-03.txt From rsvp-owner@ISI.EDU Wed Mar 15 16:36:02 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 QAA11069 for ; Wed, 15 Mar 2000 16:36:01 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA08344 for rsvp-outgoing; Wed, 15 Mar 2000 11:29:31 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA08337 for ; Wed, 15 Mar 2000 11:29:30 -0800 (PST) Received: from www.charteralliance.com ([206.114.168.110]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA23650 for ; Wed, 15 Mar 2000 11:29:38 -0800 (PST) From: info@CharterAlliance.com Received: from avation - 206.114.168.98 by www.charteralliance.com with Microsoft SMTPSVC(5.5.1774.114.11); Wed, 15 Mar 2000 14:30:04 +0000 To: info@CharterAlliance.com Subject: Breakthrough Aviation Scheduling ! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <005b90430140f30CHARTERALLIANCE@www.charteralliance.com> Date: 15 Mar 2000 14:30:04 +0000 Sender: owner-rsvp@ISI.EDU Precedence: bulk FREE SIX-MONTH MEMBERSHIP OF INTERNET BASED PRIMARY SCHEDULING & DISPATCHING SOLUTION GIVES YOU FREEDOM FROM THE LIMITATIONS OF YOUR EXISTING SCHEDULE! Welcome to the future of aviation scheduling & dispatching! No longer will you have to install a cumbersome, and costly, network system to take advantage of advances in scheduling technology. From now on, aviation software packages are a thing of the past. In fact, with our solution, there is nothing to buy! All that’s needed is a personal computer with an Internet connection. Everything's FREE! * No Large Purchase of Hardware or Software! * Free Your System From the Technology Trap! * Works For: 135, 91, Cargo, Flight Schools, etc., etc.! * Decrease Dispatcher's Hours & Increase Aircraft Utilization! * Easy Multi-User/Multi-Tasking Ability From Anywhere! * 135! Post Deadheads Onto the Internet Automatically! Our service works better than many software packages costing thousands of dollars! Being Internet based, it also boasts features that no mere client-server system can match. All you have to do is go to: http://charteralliance.com/register.asp to register. Immediately you can begin benefiting from this FREE solution! CharterAlliance.com has a global vision for how information will be shared among the Charter Aviation Industry in the Twenty-First Century. No longer will technological advances be only available to the operators who can afford them. Now is your chance to climb aboard the cusp of something that is sweeping the industry. Don’t delay! This is the key. Use it! There are no strings attached! It's FREE! Use it! Kiloh R. Smith Director of Marketing CharterAlliance.com kiloh@CharterAlliance.com (607) 257-7631 ******************************************* To be removed from this list, reply to this email with "remove" in the subject line. We will be announcing other FREE aviation services in upcoming emails. Remain on this list for these exciting notices. From rsvp-owner@ISI.EDU Thu Mar 16 02:41: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 CAA05483 for ; Thu, 16 Mar 2000 02:41:59 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id VAA28951 for rsvp-outgoing; Wed, 15 Mar 2000 21:31:31 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA28944 for ; Wed, 15 Mar 2000 21:31:29 -0800 (PST) Received: from taumsauk.cs.wustl.edu (cs.wustl.edu [128.252.165.15]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA09324; Wed, 15 Mar 2000 21:31:38 -0800 (PST) Received: from cs.wustl.edu (merengue.cs.wustl.edu [128.252.165.145]) by taumsauk.cs.wustl.edu (8.9.1/8.9.1) with ESMTP id XAA21053; Wed, 15 Mar 2000 23:31:37 -0600 (CST) Message-ID: <38D071B7.C36A4A2C@cs.wustl.edu> Date: Wed, 15 Mar 2000 23:31:35 -0600 From: Vishal Kachroo X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU, rsvp-test@ISI.EDU Subject: RAPI Daemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I am using the RAPI implementation from ISI. I am running into two problems. I would really appreciate if anyone can address these : 1. When I run the rsvpd daemon in -D (debug) mode, it crashes when the client executes rapi_session (). The client, however, gets a valid session ID. The daemon does not crash if its not run in a -D mode. 2. How do I initialize the Simplified TSpec as opposed to the IntServ version of TSpec. Thanks, Vishal. From rsvp-owner@ISI.EDU Fri Mar 17 10:40: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 KAA15555 for ; Fri, 17 Mar 2000 10:40:17 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA04752 for rsvp-outgoing; Fri, 17 Mar 2000 05:23:44 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04744 for ; Fri, 17 Mar 2000 05:23:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18549 for ; Fri, 17 Mar 2000 05:23:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22548; Fri, 17 Mar 2000 08:23:50 -0500 (EST) Message-Id: <200003171323.IAA22548@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-state-compression-03.txt Date: Fri, 17 Mar 2000 08:23:50 -0500 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 Refresh Overhead Reduction by State Compression Author(s) : L. Wang, L. Zhang, A. Terzis Filename : draft-ietf-rsvp-state-compression-03.txt Pages : 30 Date : 16-Mar-00 As a soft-state protocol, RSVP specifies that each RSVP node sends peri- odic RSVP messages for each existing RSVP session. The overhead due to such periodic state refreshes goes up linearly with the number of active RSVP sessions. One can reduce the overhead by using a longer refresh period, which unfortunately leads to longer delays in re-synchronizing RSVP state in face of packet losses. To overcome the dilemma, this specification describes the use of a 'state-compression' approach to soft-state protocol refreshes. In the absence of state changes this compression mechanism has a constant message overhead while retaining the soft-state nature of RSVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rsvp-state-compression-03.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-state-compression-03.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-state-compression-03.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: <20000316144815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-state-compression-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-state-compression-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144815.I-D@ietf.org> --OtherAccess-- --NextPart-- From rsvp-owner@ISI.EDU Fri Mar 17 10:44:09 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 KAA17121 for ; Fri, 17 Mar 2000 10:44:08 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA04736 for rsvp-outgoing; Fri, 17 Mar 2000 05:23:38 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA04731 for ; Fri, 17 Mar 2000 05:23:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18540 for ; Fri, 17 Mar 2000 05:23:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22491; Fri, 17 Mar 2000 08:23:43 -0500 (EST) Message-Id: <200003171323.IAA22491@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-00.txt Date: Fri, 17 Mar 2000 08:23:42 -0500 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 Receiver Proxy Author(s) : S. Gai, D. Dutt, Y. Bernet, N. Elfassy Filename : draft-ietf-rsvp-proxy-00.txt Pages : 10 Date : 16-Mar-00 RSVP has been extended in several directions [Policy], [Identity], [DCLASS], [AggrRSVP], [DiffModel],[COPS-RSVP], These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable both inside and outside the IntServ model. With the addition of the 'Null Service Type' [NullServ], RSVP is being adopted also by mission critical applications that require some form of prioritized service, but cannot readily specify their resource requirements. These applications do not need to set-up a reservation end-to-end, but only to signal to the network their policy information [Policy], [Identity] and obtain in response an applicable DSCP [DCLASS]. RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself), mainly designed to operate in conjunction with the Null Service Type. If COPS is used for policy control, an extension to the COPS for RSVP protocol [COPS-RSVP-EXT] is also required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-proxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144801.I-D@ietf.org> --OtherAccess-- --NextPart-- From rsvp-owner@ISI.EDU Fri Mar 17 15:30:09 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 PAA16692 for ; Fri, 17 Mar 2000 15:30:08 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA13622 for rsvp-outgoing; Fri, 17 Mar 2000 09:39:35 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA13617 for ; Fri, 17 Mar 2000 09:39:34 -0800 (PST) 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 JAA14658; Fri, 17 Mar 2000 09:39:42 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA07607; Fri, 17 Mar 2000 17:39:42 GMT Date: Fri, 17 Mar 2000 17:39:42 GMT Message-Id: <200003171739.RAA07607@gra.isi.edu> To: rsvp@ISI.EDU Subject: Last Call(s) Cc: braden@ISI.EDU, lixia@cs.ucla.edu, andrew@extremenetworks.com X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Friends, At the Washington DC IETF, the RSVP WG agreed that the draft by Silvano Gai et al, draft-sgai-rsvp-proxy-00.txt on "RSVP Receiver Proxy", would be Last Called by both the RSVP and RAP WGs to become an Informational RFC. This draft has now been republished as draft-ietf-rsvp-proxy-00.txt (see announcement below). We are accordingly now issuing a working group last call, to be closed on April 1, 2000. I expect that the RAP WG will also issue a Last Call. In addition, we decided that the State Compression draft draft-ietf-rsvp-state-compression-03.txt should be published as an Experimental RFC. It is not clear to me that a WG last call is really needed in this case, but we might as well do it anyway. Again, the close will be April 1, 2000. Bob Braden & Lixia Zhang ----- Begin Included Message ----- draft 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 Receiver Proxy Author(s) : S. Gai, D. Dutt, Y. Bernet, N. Elfassy Filename : draft-ietf-rsvp-proxy-00.txt Pages : 10 Date : 16-Mar-00 RSVP has been extended in several directions [Policy], [Identity], [DCLASS], [AggrRSVP], [DiffModel],[COPS-RSVP], These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable both inside and outside the IntServ model. With the addition of the 'Null Service Type' [NullServ], RSVP is being adopted also by mission critical applications that require some form of prioritized service, but cannot readily specify their resource requirements. These applications do not need to set-up a reservation end-to-end, but only to signal to the network their policy information [Policy], [Identity] and obtain in response an applicable DSCP [DCLASS]. RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself), mainly designed to operate in conjunction with the Null Service Type. If COPS is used for policy control, an extension to the COPS for RSVP protocol [COPS-RSVP-EXT] is also required. 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 Refresh Overhead Reduction by State Compression Author(s) : L. Wang, L. Zhang, A. Terzis Filename : draft-ietf-rsvp-state-compression-03.txt Pages : 30 Date : 16-Mar-00 As a soft-state protocol, RSVP specifies that each RSVP node sends peri- odic RSVP messages for each existing RSVP session. The overhead due to such periodic state refreshes goes up linearly with the number of active RSVP sessions. One can reduce the overhead by using a longer refresh period, which unfortunately leads to longer delays in re-synchronizing RSVP state in face of packet losses. To overcome the dilemma, this specification describes the use of a 'state-compression' approach to soft-state protocol refreshes. In the absence of state changes this compression mechanism has a constant message overhead while retaining the soft-state nature of RSVP. From rsvp-owner@ISI.EDU Mon Mar 20 09:49: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 JAA03765 for ; Mon, 20 Mar 2000 09:49:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA20230 for rsvp-outgoing; Mon, 20 Mar 2000 04:32:35 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA20225 for ; Mon, 20 Mar 2000 04:32:34 -0800 (PST) Received: from miles.datcon.co.uk (smtp2.datcon.co.uk [192.91.191.8]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA20408 for ; Mon, 20 Mar 2000 04:32:44 -0800 (PST) Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 12:32:07 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404C1@monk.datcon.co.uk> From: Adrian Farrel To: rsvp@ISI.EDU, mpls@uu.net Subject: Sender TSpec on PathTear Date: Mon, 20 Mar 2000 12:32:03 -0000 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 All, RFC 2205 states that Sender TSpec is mandatory on a PathTear if a Sender Descriptor is included. ::= [ ] [ ] ::= (see earlier definition) Where the earlier definition of sender Descriptor is found in the definition of Path Message and is... ::= [ ] draft-ietf-mpls-rsvp-lsp-tunnel-05 does not make any change to this requirement, but does add [RECORD_ROUTE] as an optional field in Sender Descriptor. It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do not add anything to PathTear. Can anyone comment on whether or not it would be better to define PathTear as ::= [ ] [] Of course the effect of this can be mitigated by applying the usual rules of conservative on send, liberal on receive. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From rsvp-owner@ISI.EDU Mon Mar 20 13:28:47 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 NAA01161 for ; Mon, 20 Mar 2000 13:28:46 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA27551 for rsvp-outgoing; Mon, 20 Mar 2000 08:13:28 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA27545 for ; Mon, 20 Mar 2000 08:13:26 -0800 (PST) Received: from mlsrv1.avici.com ([208.246.215.9]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04117 for ; Mon, 20 Mar 2000 08:13:36 -0800 (PST) Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id LAA29791; Mon, 20 Mar 2000 11:12:58 -0500 (EST) Received: by localhost with Microsoft MAPI; Mon, 20 Mar 2000 11:12:59 -0500 Message-ID: <01BF925D.3FE04760.mjork@avici.com> From: Markus Jork To: "'Adrian Farrel'" , "rsvp@ISI.EDU" , "mpls@UU.NET" Subject: RE: Sender TSpec on PathTear Date: Mon, 20 Mar 2000 11:12:58 -0500 Organization: Avici X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adrian, On Monday, March 20, 2000 7:32 AM, Adrian Farrel wrote: > All, > > RFC 2205 states that Sender TSpec is mandatory on a PathTear > if a Sender Descriptor is included. > > ::= [ ] > > [ ] > > ::= (see earlier definition) > > Where the earlier definition of sender Descriptor is found in > the definition of Path Message and is... > > ::= > [ ] > > > draft-ietf-mpls-rsvp-lsp-tunnel-05 does not make any change to > this requirement, but does add [RECORD_ROUTE] as an optional > field in Sender Descriptor. > > It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do > not add anything to PathTear. Note that you cannot have a RECORD_ROUTE object in a PathTear message. draft-ietf-mpls-rsvp-lsp-tunnel-05 does say that RECORD_ROUTE is an optional part of a Sender Descriptor. But it also states that a RECORD_ROUTE object may only be present in Path or Resv messages (at the beginning of section 3 in the draft). > Can anyone comment on whether or not it would be better to > define PathTear as > > ::= [ ] > > [] > I also don't see a use for the tspec object (or adspec) in a PathTear message. But it won't do any harm, either. If RFC 2205 ever gets updated, this is something to keep in mind. But for now we are just stuck with it, I guess. And while we are on the topic of message formats: there seems to be a minor inconsistency between RFC 2205 and draft-ietf-mpls-rsvp-lsp-tunnel-05. My interpretation of RFC 2205 is that duplicate objects (e.g. two SESSION objects) in a single message are to be treated as an error which in turn means such messages should/could be discarded. This is not spelled out directly but it's my reading of the spec. On the other hand, the new objects introduced for MPLS have some explicit language that says: this object should appear only once, but if not just look at the first occurence and ignore the others. Not a big deal but it makes you wonder why to introduce these subtleties that a parser needs to deal with. Markus From rsvp-owner@ISI.EDU Mon Mar 20 14:43:38 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 OAA01823 for ; Mon, 20 Mar 2000 14:43:35 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA28089 for rsvp-outgoing; Mon, 20 Mar 2000 08:27:54 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA28084 for ; Mon, 20 Mar 2000 08:27:53 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA06923 for ; Mon, 20 Mar 2000 08:28:03 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Mar 20 11:27:26 EST 2000 Received: from dnrc.bell-labs.com (pingpanpc [135.180.130.92]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA27437; Mon, 20 Mar 2000 11:27:24 -0500 (EST) Message-ID: <38D650FE.F4F2EE74@dnrc.bell-labs.com> Date: Mon, 20 Mar 2000 11:25:34 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Jork CC: "'Adrian Farrel'" , "rsvp@ISI.EDU" , "mpls@UU.NET" Subject: Re: Sender TSpec on PathTear References: <01BF925D.3FE04760.mjork@avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Markus Jork wrote: > > > It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do > > not add anything to PathTear. > > ... > > Can anyone comment on whether or not it would be better to > > define PathTear as > > > > ::= [ ] > > > > [] > > > > I also don't see a use for the tspec object (or adspec) in a PathTear > message. But it won't do any harm, either. If RFC 2205 ever gets > updated, this is something to keep in mind. But for now we are just > stuck with it, I guess. > I don't think that tspec is harmful. Actually, tspec may be useful in case of merged reservations (SE and WF). In some implementation, if the routers only keep the final merged bandwidth allocation, then they'd better rely on the tspec in PATHTEAR to update their resources after teardown. - Ping From rsvp-owner@ISI.EDU Mon Mar 20 22:07:15 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17171 for ; Mon, 20 Mar 2000 22:07:14 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA18530 for rsvp-outgoing; Mon, 20 Mar 2000 16:52:04 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA18525 for ; Mon, 20 Mar 2000 16:52:03 -0800 (PST) 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 QAA03252; Mon, 20 Mar 2000 16:52:08 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA09079; Tue, 21 Mar 2000 00:52:07 GMT Date: Tue, 21 Mar 2000 00:52:07 GMT Message-Id: <200003210052.AAA09079@gra.isi.edu> To: rsvp@ISI.EDU, mpls@uu.net, AF@datcon.co.uk Subject: Re: Sender TSpec on PathTear X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> From rsvp-owner@ISI.EDU Mon Mar 20 04:45:27 2000 *> From: Adrian Farrel *> To: rsvp@ISI.EDU, mpls@uu.net *> Subject: Sender TSpec on PathTear *> Date: Mon, 20 Mar 2000 12:32:03 -0000 *> MIME-Version: 1.0 *> X-Mailer: Internet Mail Service (5.5.2650.21) *> Sender: owner-rsvp@ISI.EDU *> Precedence: bulk *> X-Lines: 44 *> *> All, *> *> RFC 2205 states that Sender TSpec is mandatory on a PathTear *> if a Sender Descriptor is included. *> *> ::= [ ] *> *> [ ] *> *> ::= (see earlier definition) *> And the very next sentence says, "A PathTear message may include a SENDER_TSPEC or ADSPEC object in its sender descriptor, but these must be ignored". There are several places where the text modulates the BNF, and this is one of them. This presentation was chosen for simplicity and (we thought) clarity, but apparently it failed for you. Bob Braden From rsvp-owner@ISI.EDU Tue Mar 21 00:02: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 AAA01168 for ; Tue, 21 Mar 2000 00:02:33 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA24011 for rsvp-outgoing; Mon, 20 Mar 2000 19:09:26 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA24006 for ; Mon, 20 Mar 2000 19:09:24 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA19866 for ; Mon, 20 Mar 2000 19:09:35 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA04394 for ; Mon, 20 Mar 2000 22:08:58 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA18682 for ; Mon, 20 Mar 2000 22:08:59 -0500 (EST) Message-ID: <38D6E7CB.AD87C68C@fore.com> Date: Mon, 20 Mar 2000 22:08:59 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: Conflict in draft-ietf-rsvp-refresh-reduct-03.txt References: <200003210052.AAA09079@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit While readining through draft-ietf-rsvp-refresh-reduct-03.txt, I discovered a problem. Both the MESSAGE_ID_ACK and MESSAGE_ID_LIST classes have the same value (24). They also share some of the same C-Types. If this is intentional, how are you supposed to know what the object is? I hope the meaning of the object isn't meant to be a function of the router's current state or something. The way the draft is currently written, it becomes very difficult to determine what the object really is, in the context of a stateless device, like a packet sniffer. -- David From rsvp-owner@ISI.EDU Tue Mar 21 11:10: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 LAA09127 for ; Tue, 21 Mar 2000 11:10:23 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA03605 for rsvp-outgoing; Mon, 20 Mar 2000 23:56:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA03600 for ; Mon, 20 Mar 2000 23:56:05 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA10776 for ; Mon, 20 Mar 2000 23:56:12 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 21 Mar 2000 13:34:33 +0530 Received: from steve.future.futsoft.com ([172.16.1.8]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA20406 for ; Tue, 21 Mar 2000 13:12:50 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 13:19:15 +0530 Message-Id: <01BF9338.0E789B60.junqy@future.futsoft.com> From: Steve To: "'rsvp@isi.edu'" Subject: about the effective ADSPEC Date: Tue, 21 Mar 2000 13:19:14 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi, When I read RFC2205, I notice that there is a new idea about "effective ADSPEC". In "3.11.2 RSVP/Traffic Control Interface", [Page 70] says " o Make a Reservation Call: TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec, TC_Adspec, Police_Flags ) -> RHandle [, Fwd_Flowspec] ......The TC_Adspec parameter defines the effective Adspec. ..... " I try to consult RFC2205, RFC2209, RFC2210, RFC2211, RFC2212, RFC2215, but I fail to get any other place to talk about "effective Adspec". Do anyone know how to calculate the "effective Adspec" or "TC_Adspec"? Thanks in Advance! Thanks and Regards Steve From rsvp-owner@ISI.EDU Tue Mar 21 12:32: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 MAA08544 for ; Tue, 21 Mar 2000 12:32:35 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA12073 for rsvp-outgoing; Tue, 21 Mar 2000 04:46:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA12068 for ; Tue, 21 Mar 2000 04:46:08 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA00871 for ; Tue, 21 Mar 2000 04:46:19 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id GAA09811; Tue, 21 Mar 2000 06:45:54 -0600 Message-Id: <4.2.2.20000321074030.00bae7c0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 07:46:35 -0500 To: David Charlap From: Lou Berger Subject: Re: Conflict in draft-ietf-rsvp-refresh-reduct-03.txt Cc: rsvp@ISI.EDU In-Reply-To: <38D6E7CB.AD87C68C@fore.com> References: <200003210052.AAA09079@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi David, You are correct. That should have been 25. (Had it that way in my request to IANA, see below.) Please remember that values *may* change until assigned by IANA. Here's what I requested: >The messages and objects assigned in the draft are: > > Name Suggested value > ======================================== >Messages: > Bundle 12 > ACK 13 > Srefresh 15 >New objects classes: > MESSAGE_ID 23 > MESSAGE_ID_ACK 24 > MESSAGE_ID_LIST 25 I've not heard back on the assignments. Lou At 10:08 PM 3/20/00 -0500, David Charlap wrote: >While readining through draft-ietf-rsvp-refresh-reduct-03.txt, I >discovered a problem. > >Both the MESSAGE_ID_ACK and MESSAGE_ID_LIST classes have the same value >(24). They also share some of the same C-Types. > >If this is intentional, how are you supposed to know what the object >is? I hope the meaning of the object isn't meant to be a function of >the router's current state or something. The way the draft is currently >written, it becomes very difficult to determine what the object really >is, in the context of a stateless device, like a packet sniffer. > >-- David From rsvp-owner@ISI.EDU Tue Mar 21 18:39: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 SAA26676 for ; Tue, 21 Mar 2000 18:39:30 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA01936 for rsvp-outgoing; Tue, 21 Mar 2000 14:00:38 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01931 for ; Tue, 21 Mar 2000 14:00:36 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA09152 for ; Tue, 21 Mar 2000 14:00:46 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA28617; Tue, 21 Mar 2000 17:00:12 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA29259; Tue, 21 Mar 2000 17:00:14 -0500 (EST) Message-ID: <38D7F0F0.26E46FA4@fore.com> Date: Tue, 21 Mar 2000 17:00:16 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@uu.net Subject: Semantics of shared reservations (with RSVP) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I've got a question about how shared (SE) style reservations get propagated in the RSVP/MPLS world. In a simple multipoint-to-point scenario with shared resources: H1 ---- R1 \ R3 ---- R4 --- H3 / H2 ---- R2 H3 should will send out a Resv mesage to R4. The flow descriptor of this Resv will look like: FLOWSPEC FILTERSPEC (for H1) FILTERSHEC (for H2) R3, when sending out its Resv messages, will break up this flow descriptor, and will send out FLOWSPEC FILTERSPEC (for H1) to R1, and FLOWSPEC FILTERSPEC (for H2) to R2. Right? OK. The problem shows up when H1 and H2 are two different tunnel endpoints on the same physical box. This can happen in the MPLS world if an ingress router is signalling multiple redundant (failover) paths to a single destination. For instance: R2 ---- R3 / \ H1 ---- R1 R6 ---- R7 ---- H2 \ / R4 ---- R5 H1 sends out two Path messages (with different explicit route objects) to H2. H2 sends out a Resv message indicating that the two "senders" (indicated by different tunnel IDs) are to use shared resources. The flow descriptor looks something like: FLOWSPEC FILTERSPEC (for tunnel 1) FILTERSPEC (for tunnel 2) R6, when receiving this, breaks the flow descriptor up for the two paths, sending out FLOWSPEC FILTERSPEC (for tunnel 1) to R3, and FLOWSPEC FILTERSPEC (for tunnel 2) to R5. This works great until those two Resv messages both arrive at R1. How does R1 know that these two tunnels are supposed to be sharing resources. Normally, a router would know this from the multiple filterspecs in a single flow-descriptor, but R1 doesn't see this. It receives two separate Resv messages from two different next-hop nodes. I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 could (probably would) reject those Resv messages, wouldn't they? After all, those two routers each only processed one of the two Path messages - they don't know about the other one. For that matter, how does H1 tell H2 that these two paths are supposed to be sharing resources? Must it be configured across the network? So, am I missing something here? Is this an as-yet-unsolved problem with RSVP and MPLS? -- David From rsvp-owner@ISI.EDU Tue Mar 21 19:07: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 TAA06461 for ; Tue, 21 Mar 2000 19:07:00 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA03147 for rsvp-outgoing; Tue, 21 Mar 2000 14:34:54 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03142 for ; Tue, 21 Mar 2000 14:34:48 -0800 (PST) Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14688 for ; Tue, 21 Mar 2000 14:34:59 -0800 (PST) Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HM230LPZ; Tue, 21 Mar 2000 17:32:16 -0500 Message-ID: <38D7F9E9.EB386B21@globespan.net> Date: Tue, 21 Mar 2000 17:38:33 -0500 From: Jayesh V Shah Organization: GlobeSpan, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, > I've got a question about how shared (SE) style reservations get > propagated in the RSVP/MPLS world. > > In a simple multipoint-to-point scenario with shared resources: > > H1 ---- R1 > \ > R3 ---- R4 --- H3 > / > H2 ---- R2 > > H3 should will send out a Resv mesage to R4. The flow descriptor of > this Resv will look like: > > FLOWSPEC > FILTERSPEC (for H1) > FILTERSHEC (for H2) > > R3, when sending out its Resv messages, will break up this flow > descriptor, and will send out > > FLOWSPEC > FILTERSPEC (for H1) > > to R1, and > > FLOWSPEC > FILTERSPEC (for H2) > > to R2. > > Right? > > OK. The problem shows up when H1 and H2 are two different tunnel > endpoints on the same physical box. This can happen in the MPLS world > if an ingress router is signalling multiple redundant (failover) paths > to a single destination. For instance: > > R2 ---- R3 > / \ > H1 ---- R1 R6 ---- R7 ---- H2 > \ / > R4 ---- R5 > > H1 sends out two Path messages (with different explicit route objects) > to H2. > > H2 sends out a Resv message indicating that the two "senders" (indicated > by different tunnel IDs) are to use shared resources. The flow > descriptor looks something like: > > FLOWSPEC > FILTERSPEC (for tunnel 1) > FILTERSPEC (for tunnel 2) The senders will be distinguished by different Sender Address and/or LSP Id in the Sender Template, and not the tunnel Id, which by virtue of being a part of session, has to be same for both the flows, to allow the shared explicit reservation, we are talking about here. > R6, when receiving this, breaks the flow descriptor up for the two > paths, sending out > > FLOWSPEC > FILTERSPEC (for tunnel 1) > > to R3, and > > FLOWSPEC > FILTERSPEC (for tunnel 2) > > to R5. > > This works great until those two Resv messages both arrive at R1. > > How does R1 know that these two tunnels are supposed to be sharing > resources. Normally, a router would know this from the multiple > filterspecs in a single flow-descriptor, but R1 doesn't see this. It > receives two separate Resv messages from two different next-hop nodes. R1 knows that it needs to share resources among the two flows, because they belong to the same session (the session object is the same). > > I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 > could (probably would) reject those Resv messages, wouldn't they? After > all, those two routers each only processed one of the two Path messages > - they don't know about the other one. > > For that matter, how does H1 tell H2 that these two paths are supposed > to be sharing resources? Must it be configured across the network? > > So, am I missing something here? Is this an as-yet-unsolved problem > with RSVP and MPLS? > > -- David I hope it is clear. Regards, Jayesh -- __________________________________________ Jayesh V. Shah GlobeSpan, Inc. Tel: (732) 283-2770 x321 Fax: (732) 283-2848 E-mail: jshah@globespan.net Web: http://www.ficon-tech.com/home.htm From rsvp-owner@ISI.EDU Tue Mar 21 19:38: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 TAA18693 for ; Tue, 21 Mar 2000 19:38:38 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA03988 for rsvp-outgoing; Tue, 21 Mar 2000 14:50:24 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03983 for ; Tue, 21 Mar 2000 14:50:23 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16903 for ; Tue, 21 Mar 2000 14:50:33 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA03339; Tue, 21 Mar 2000 17:49:55 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA08639; Tue, 21 Mar 2000 17:49:57 -0500 (EST) Message-ID: <38D7FC97.3572C0B6@fore.com> Date: Tue, 21 Mar 2000 17:49:59 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Jayesh V Shah CC: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Jayesh V Shah wrote: >> >> I've got a question about how shared (SE) style reservations get >> propagated in the RSVP/MPLS world. >> >> In a simple multipoint-to-point scenario with shared resources: >> >> H1 ---- R1 >> \ >> R3 ---- R4 --- H3 >> / >> H2 ---- R2 >> >> H3 should will send out a Resv mesage to R4. The flow descriptor of >> this Resv will look like: >> >> FLOWSPEC >> FILTERSPEC (for H1) >> FILTERSHEC (for H2) >> >> R3, when sending out its Resv messages, will break up this flow >> descriptor, and will send out >> >> FLOWSPEC >> FILTERSPEC (for H1) >> >> to R1, and >> >> FLOWSPEC >> FILTERSPEC (for H2) >> >> to R2. >> >> Right? >> >> OK. The problem shows up when H1 and H2 are two different tunnel >> endpoints on the same physical box. This can happen in the MPLS >> world if an ingress router is signalling multiple redundant >> (failover) paths to a single destination. For instance: >> >> R2 ---- R3 >> / \ >> H1 ---- R1 R6 ---- R7 ---- H2 >> \ / >> R4 ---- R5 >> >> H1 sends out two Path messages (with different explicit route >> objects) to H2. >> >> H2 sends out a Resv message indicating that the two "senders" >> (indicated by different tunnel IDs) are to use shared resources. The >> flow descriptor looks something like: >> >> FLOWSPEC >> FILTERSPEC (for tunnel 1) >> FILTERSPEC (for tunnel 2) > > The senders will be distinguished by different Sender Address and/or > LSP Id in the Sender Template, and not the tunnel Id, which by virtue > of being a part of session, has to be same for both the flows, to > allow the shared explicit reservation, we are talking about here. Yes. But if H2 is going to issue a shared reservation for the two, it must specify filterspecs for both senders in the same Resv object. If it doesn't then it is signalling two separate resource-sharing groups. >> R6, when receiving this, breaks the flow descriptor up for the two >> paths, sending out >> >> FLOWSPEC >> FILTERSPEC (for tunnel 1) >> >> to R3, and >> >> FLOWSPEC >> FILTERSPEC (for tunnel 2) >> >> to R5. >> >> This works great until those two Resv messages both arrive at R1. >> >> How does R1 know that these two tunnels are supposed to be sharing >> resources. Normally, a router would know this from the multiple >> filterspecs in a single flow-descriptor, but R1 doesn't see this. It >> receives two separate Resv messages from two different next-hop >> nodes. > > R1 knows that it needs to share resources among the two flows, because > they belong to the same session (the session object is the same). No. This is SE style, not WF. In WF style, all senders in a single session share the same resources. In SE, the senders that share resources must be explicitly specified. If a switch assumes sharing when this specification is not present, it is in error. The recipient (H2) knows this and will explicitly state the sharing in its flow-descriptor list (one flow descriptor containing two flowspecs and two labels.) The problem is that this information is lost after the flow descriptors are broken up at R6. >> I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 >> could (probably would) reject those Resv messages, wouldn't they? >> After all, those two routers each only processed one of the two Path >> messages - they don't know about the other one. >> >> For that matter, how does H1 tell H2 that these two paths are >> supposed to be sharing resources? Must it be configured across the >> network? >> >> So, am I missing something here? Is this an as-yet-unsolved problem >> with RSVP and MPLS? > > I hope it is clear. > > Regards, > Jayesh From rsvp-owner@ISI.EDU Tue Mar 21 20:41: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 UAA11397 for ; Tue, 21 Mar 2000 20:41:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA08432 for rsvp-outgoing; Tue, 21 Mar 2000 15:52:55 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08427 for ; Tue, 21 Mar 2000 15:52:53 -0800 (PST) Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA26126 for ; Tue, 21 Mar 2000 15:53:04 -0800 (PST) Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HM230L67; Tue, 21 Mar 2000 18:50:23 -0500 Message-ID: <38D80C39.AC653864@globespan.net> Date: Tue, 21 Mar 2000 18:56:41 -0500 From: Jayesh V Shah Organization: GlobeSpan, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> <38D7FC97.3572C0B6@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > >> I've got a question about how shared (SE) style reservations get > >> propagated in the RSVP/MPLS world. > >> > >> In a simple multipoint-to-point scenario with shared resources: > >> > >> H1 ---- R1 > >> \ > >> R3 ---- R4 --- H3 > >> / > >> H2 ---- R2 > >> > >> H3 should will send out a Resv mesage to R4. The flow descriptor of > >> this Resv will look like: > >> > >> FLOWSPEC > >> FILTERSPEC (for H1) > >> FILTERSHEC (for H2) > >> > >> R3, when sending out its Resv messages, will break up this flow > >> descriptor, and will send out > >> > >> FLOWSPEC > >> FILTERSPEC (for H1) > >> > >> to R1, and > >> > >> FLOWSPEC > >> FILTERSPEC (for H2) > >> > >> to R2. > >> > >> Right? > >> > >> OK. The problem shows up when H1 and H2 are two different tunnel > >> endpoints on the same physical box. This can happen in the MPLS > >> world if an ingress router is signalling multiple redundant > >> (failover) paths to a single destination. For instance: > >> > >> R2 ---- R3 > >> / \ > >> H1 ---- R1 R6 ---- R7 ---- H2 > >> \ / > >> R4 ---- R5 > >> > >> H1 sends out two Path messages (with different explicit route > >> objects) to H2. > >> > >> H2 sends out a Resv message indicating that the two "senders" > >> (indicated by different tunnel IDs) are to use shared resources. The > >> flow descriptor looks something like: > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 1) > >> FILTERSPEC (for tunnel 2) > > > > The senders will be distinguished by different Sender Address and/or > > LSP Id in the Sender Template, and not the tunnel Id, which by virtue > > of being a part of session, has to be same for both the flows, to > > allow the shared explicit reservation, we are talking about here. > > Yes. But if H2 is going to issue a shared reservation for the two, it > must specify filterspecs for both senders in the same Resv object. If > it doesn't then it is signalling two separate resource-sharing groups. What do we mean by multiple resource sharing groups within the same session ? > > >> R6, when receiving this, breaks the flow descriptor up for the two > >> paths, sending out > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 1) > >> > >> to R3, and > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 2) > >> > >> to R5. > >> > >> This works great until those two Resv messages both arrive at R1. > >> > >> How does R1 know that these two tunnels are supposed to be sharing > >> resources. Normally, a router would know this from the multiple > >> filterspecs in a single flow-descriptor, but R1 doesn't see this. It > >> receives two separate Resv messages from two different next-hop > >> nodes. > > > > R1 knows that it needs to share resources among the two flows, because > > they belong to the same session (the session object is the same). > > No. This is SE style, not WF. > > In WF style, all senders in a single session share the same resources. > > In SE, the senders that share resources must be explicitly specified. > If a switch assumes sharing when this specification is not present, it > is in error. R1 would get two different Resv, both with SE style with individual filter specs. R1 would make reservations accordingly, as the outgoing interfaces for the two flows are different. However, when forwarding the Resv to H1, the Resv Merge would result in a single SE style Resv, with two filter specs, one corresponding to each sender. As a matter of fact, R1 can as well forward two different Resv., one for each filter spec, without changing the interpretation for H1, because the style is SE. The senders should be explicitly specified for the switch to share reservation in the case of SE, but they need not belong to the same Resv message. > > The recipient (H2) knows this and will explicitly state the sharing in > its flow-descriptor list (one flow descriptor containing two flowspecs > and two labels.) The problem is that this information is lost after the > flow descriptors are broken up at R6. > > >> I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 > >> could (probably would) reject those Resv messages, wouldn't they? > >> After all, those two routers each only processed one of the two Path > >> messages - they don't know about the other one. > >> > >> For that matter, how does H1 tell H2 that these two paths are > >> supposed to be sharing resources? Must it be configured across the > >> network? > >> > >> So, am I missing something here? Is this an as-yet-unsolved problem > >> with RSVP and MPLS? > > > > I hope it is clear. > > > > Regards, > > Jayesh Regards, Jayesh -- __________________________________________ Jayesh V. Shah GlobeSpan, Inc. Tel: (732) 283-2770 x321 Fax: (732) 283-2848 E-mail: jshah@globespan.net Web: http://www.ficon-tech.com/home.htm From rsvp-owner@ISI.EDU Tue Mar 21 20:50: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 UAA14796 for ; Tue, 21 Mar 2000 20:50:53 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA08973 for rsvp-outgoing; Tue, 21 Mar 2000 16:07:38 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA08968 for ; Tue, 21 Mar 2000 16:07:37 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA28491 for ; Tue, 21 Mar 2000 16:07:48 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA09491; Tue, 21 Mar 2000 19:07:15 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA18906; Tue, 21 Mar 2000 19:07:17 -0500 (EST) Message-ID: <38D80EB7.12AFE0B4@fore.com> Date: Tue, 21 Mar 2000 19:07:19 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Jayesh V Shah CC: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> <38D7FC97.3572C0B6@fore.com> <38D80C39.AC653864@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Jayesh V Shah wrote: >>>> >>>> I've got a question about how shared (SE) style reservations get >>>> propagated in the RSVP/MPLS world. >>>> >>>> In a simple multipoint-to-point scenario with shared resources: >>>> >>>> H1 ---- R1 >>>> \ >>>> R3 ---- R4 --- H3 >>>> / >>>> H2 ---- R2 >>>> >>>> H3 should will send out a Resv mesage to R4. The flow descriptor >>>> of this Resv will look like: >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H1) >>>> FILTERSHEC (for H2) >>>> >>>> R3, when sending out its Resv messages, will break up this flow >>>> descriptor, and will send out >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H1) >>>> >>>> to R1, and >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H2) >>>> >>>> to R2. >>>> >>>> Right? >>>> >>>> OK. The problem shows up when H1 and H2 are two different tunnel >>>> endpoints on the same physical box. This can happen in the MPLS >>>> world if an ingress router is signalling multiple redundant >>>> (failover) paths to a single destination. For instance: >>>> >>>> R2 ---- R3 >>>> / \ >>>> H1 ---- R1 R6 ---- R7 ---- H2 >>>> \ / >>>> R4 ---- R5 >>>> >>>> H1 sends out two Path messages (with different explicit route >>>> objects) to H2. >>>> >>>> H2 sends out a Resv message indicating that the two "senders" >>>> (indicated by different tunnel IDs) are to use shared resources. >>>> The flow descriptor looks something like: >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 1) >>>> FILTERSPEC (for tunnel 2) >>> >>> The senders will be distinguished by different Sender Address and/or >>> LSP Id in the Sender Template, and not the tunnel Id, which by >>> virtue of being a part of session, has to be same for both the >>> flows, to allow the shared explicit reservation, we are talking >>> about here. >> >> Yes. But if H2 is going to issue a shared reservation for the two, >> it must specify filterspecs for both senders in the same Resv object. >> If it doesn't then it is signalling two separate resource-sharing >> groups. > > What do we mean by multiple resource sharing groups within the same > session ? Two flows (as defined by session-filterspec pairs) that share resources together. Either the two flows share resources, or they do not. If they share resources, the flows are described by a single flow descriptor. If they do not, they are described by two separate flow descriptors. >>>> R6, when receiving this, breaks the flow descriptor up for the two >>>> paths, sending out >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 1) >>>> >>>> to R3, and >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 2) >>>> >>>> to R5. >>>> >>>> This works great until those two Resv messages both arrive at R1. >>>> >>>> How does R1 know that these two tunnels are supposed to be sharing >>>> resources. Normally, a router would know this from the multiple >>>> filterspecs in a single flow-descriptor, but R1 doesn't see this. >>>> It receives two separate Resv messages from two different next-hop >>>> nodes. >>> >>> R1 knows that it needs to share resources among the two flows, >>> because they belong to the same session (the session object is the >>> same). >> >> No. This is SE style, not WF. >> >> In WF style, all senders in a single session share the same >> resources. >> >> In SE, the senders that share resources must be explicitly specified. >> If a switch assumes sharing when this specification is not present, >> it is in error. > > R1 would get two different Resv, both with SE style with individual > filter specs. R1 would make reservations accordingly, as the outgoing > interfaces for the two flows are different. However, when forwarding > the Resv to H1, the Resv Merge would result in a single SE style Resv, > with two filter specs, one corresponding to each sender. But these two filterspecs should be in one flow descriptor. If they are placed in separate flow descriptors, then resources are no longer shared along the common link from H1 to R1. Regardless, I got my answer from Andi's post. The answer is that the flow descriptors are not broken up in the first place, so R1 doesn't lose the resource-sharing information. > As a matter of fact, R1 can as well forward two different Resv., one > for each filter spec, without changing the interpretation for H1, > because the style is SE. Only if the two filterspecs are in separate flow descriptors. If they are sharing resources, then you can not reserve them in two separate Resv messages - to do so would create two distinct reservations. > The senders should be explicitly specified for the switch to share > reservation in the case of SE, but they need not belong to the same > Resv message. No. If two filterspecs are specified in two separate Resv messages, then they can not share resources unless the style is WF. >> The recipient (H2) knows this and will explicitly state the sharing >> in its flow-descriptor list (one flow descriptor containing two >> flowspecs and two labels.) The problem is that this information is >> lost after the flow descriptors are broken up at R6. This was my incorrect assumption. R6 doesn't break up the flow descriptor. Both Resv messages contain the flow descriptor that specifies both senders. R1 receieves two Resv messages, each of which describes both senders. And that maintains the resource sharing. -- David From rsvp-owner@ISI.EDU Tue Mar 21 23:31: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 XAA16775 for ; Tue, 21 Mar 2000 23:31:29 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA11762 for rsvp-outgoing; Tue, 21 Mar 2000 17:20:13 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA11757 for ; Tue, 21 Mar 2000 17:20:11 -0800 (PST) Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA21602 for ; Tue, 21 Mar 2000 17:20:22 -0800 (PST) Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HM230M1D; Tue, 21 Mar 2000 20:17:42 -0500 Message-ID: <38D820AF.8F848703@globespan.net> Date: Tue, 21 Mar 2000 20:23:59 -0500 From: Jayesh V Shah Organization: GlobeSpan, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> <38D7FC97.3572C0B6@fore.com> <38D80C39.AC653864@globespan.net> <38D80EB7.12AFE0B4@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > > What do we mean by multiple resource sharing groups within the same > > session ? > > Two flows (as defined by session-filterspec pairs) that share resources > together. > > Either the two flows share resources, or they do not. > > If they share resources, the flows are described by a single flow > descriptor. If they do not, they are described by two separate flow > descriptors. But SE style doesn't allow multiple flow descriptors. You can only have a single FlowSpec, followed by a list of filter specs. Look at the BNF notation for SE style Resv message If you follow the steps for RESV REFRESH sequence in RFC 2209 (Message Processing), specifically step # 5, regardless of the fact whether you receive all the filter specs in a single or multiple Resvs, it will result in a single resv refresh to the PHOP, with a merged FlowSpec and a list of FilterSpecs, which is the union of all the Filter Specs, across all the Resvs you have received for this session, sharing the same PHOP. > > As a matter of fact, R1 can as well forward two different Resv., one > > for each filter spec, without changing the interpretation for H1, > > because the style is SE. > > Only if the two filterspecs are in separate flow descriptors. If they > are sharing resources, then you can not reserve them in two separate > Resv messages - to do so would create two distinct reservations. I don't agree with you here. Going by the message processing rule, I don't think it would result in two distinct reservations. Assuming the case that you receive two different SE style reservations, for the same session, encompassing different filter specs, coming from the same NHOP, it would result in just a single RSB, with a single FlowSpec, and a list of FilterSpecs equal to the union of those in the two Resvs. Look at Page 11 of RFC2209. My question still remains, is it possible to have multiple resource sharing groups within the same session for SE style reservations ? > Regardless, I got my answer from Andi's post. The answer is that the > flow descriptors are not broken up in the first place, so R1 doesn't > lose the resource-sharing information. > >> The recipient (H2) knows this and will explicitly state the sharing > >> in its flow-descriptor list (one flow descriptor containing two > >> flowspecs and two labels.) The problem is that this information is > >> lost after the flow descriptors are broken up at R6. > > This was my incorrect assumption. R6 doesn't break up the flow > descriptor. Both Resv messages contain the flow descriptor that > specifies both senders. R1 receieves two Resv messages, each of which > describes both senders. And that maintains the resource sharing. No. The flow descriptor list is broken. Refer to examples given at the beginning of RFC 2205. However, Andi's post makes it clear that even if they are not, there is no harm, because extra filter specs will get ignored at the PHOP. And even if R6 does not split the filter Spec list, the Resv coming out of R3 will contain just a single filter spec, according to step 3 in Andi's post. Regards, Jayesh -- __________________________________________ Jayesh V. Shah GlobeSpan, Inc. Tel: (732) 283-2770 x321 Fax: (732) 283-2848 E-mail: jshah@globespan.net Web: http://www.ficon-tech.com/home.htm From rsvp-owner@ISI.EDU Wed Mar 22 06:25:46 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 GAA04708 for ; Wed, 22 Mar 2000 06:25:46 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA27551 for rsvp-outgoing; Wed, 22 Mar 2000 01:14:51 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA27545 for ; Wed, 22 Mar 2000 01:14:49 -0800 (PST) Received: from mail.fsptt.ln.cn ([202.96.86.8]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA08832 for ; Wed, 22 Mar 2000 01:14:58 -0800 (PST) Received: from x1s4x9 ([202.110.11.227]) by mail.fsptt.ln.cn (8.9.3/8.9.3) with ESMTP id RAA08127; Wed, 22 Mar 2000 17:04:29 +0800 (CST) Message-Id: <200003220904.RAA08127@mail.fsptt.ln.cn> From: rrr@abacus.bates.edu Reply-To: zixiaox@163.net Subject: УÓѼ To: zixiaox@163.net X-Mailer: V3,1,6,1 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 22 Mar 2000 17:01:53 +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 BAA27546 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Öйú´óרԺУУÓѼÍøÕ¾¿ªÍ¨ ¡¡¡¡¡°Öйú´óרԺУУÓѼ¡±ÍøÕ¾£¨ÍøÖ·£ºhttp://www.daxinghua.com /xiaoyou£© ÏÖÒÑÕýʽ¿ªÍ¨¡£ÕâÊÇÄ¿Ç°È«¹ú¹æÄ£×î´óÊÕÁÐѧУ×îÈ«µÄУÓÑÍøÕ¾¡£¸ÃÍøվʵÐп ª·Å ʽÃâ·ÑµÇ¼ʹÓᣠ¡¡¡¡¡°Ð£ÓѼ¡±ÍøÕ¾º­¸ÇÁËÈ«¹úÆÕͨ¸ßУ¡¢¾üÊÂԺУÒÔ¼°¸Û°Ą̈µØÇøËùÓдó×¨Ô ºÐ££¬ ¹²¼ÆǧÓàËù¡£¸ÃÍøÕ¾¾ßÓÐÒÔϹ¦Äܼ°Ìص㣺һÊÇ´óѧ±ÏÒµÉúÃÇÇé¸Ð½»Á÷¡¢¼¯»á¡ ¢Ð£ ÇìµÄÀíÏëͨѶ²¾£»¶þÊǸ߿¼¿¼ÉúÃDZ¨¿¼´óѧµÄºÜºÃ²Î¿¼×ÊÁÏ£¬Ò²ÊÇѧ×ÓÃÇÁ˽âÄ ¸Ð£ ±ä»¯µÄºÃÁª½Óµã£»ÈýÊǽøÈë¸÷УУÓÑ»áÖ÷ÍøÕ¾µÄÃÅ»§¡£ ¡¡¡¡Ä㻹¿ÉÒÔͨ¹ýËüÖ±½ÓÖÆ×÷¹óУУÓÑÍøÕ¾¡£Èç¡°±±¾©´óѧУÓѼ¡±£¬Ö»Òª¼ÓÉ ÏÁ´ ½Ó¡¡http://www.daxinghua.com/xiaoyou/search.asp?university=±±¾©´óѧ¡¡ £¬ ²»ÓÃÁí×â¿Õ¼ä£¬²»ÓÃÉè¼Æ£¬²»ÓÃά»¤£¬¾ÍÕâô¼òµ¥¡£ ¡¡¡¡´ËÍ⣬¡°Ð£ÓѼ¡±ÍøÕ¾»¹ÎªÐ£ÓÑÃÇÃâ·ÑÌṩÁ˸öÈËÕÕƬ¼°¸öÈËÖ÷Ò³Á´½Ó£¬Ö ÷Òª ÊÇΪУÓÑÃÇ»ØÒä·½±ã¡¢½øÒ»²½Á˽âУÓѶ¯Ì¬¡£Èç¹ûÄúûÓÐÌõ¼þ¹Ò½Ó¸öÈËÕÕƬ¡¢¸ öÈË Ö÷Ò³£¬¿É²Î¿´¡°×îÐÂ˵Ã÷¡±¡£¡°Ð£ÓѼ¡±ÍøÕ¾»¹¿ÉΪÄúÌṩ¾­¼Ãʵ»ÝµÄ¹Ò½Ó·½° ¸¡£ ¡¡¡¡¡°Ð£ÓѼ¡±ÍøÕ¾Ö÷Ò³ÉÏÏÖÁгö20ËùѧУ£¬ÊÇΪÁË·½±ãÄÇЩµÇ½Á¿´óµÄѧУР£ÓÑ ²éѯ·½±ã¶øÉè¼ÆµÄ¡£´Ó2001ÄêÆð£¬ÍøÕ¾½«°´¸÷ѧУУÓÑʵ¼ÊµÇ¼ÊýÁ¿½øÐÐÅÅÃû¡ £Õâ ½«´ÓÒ»¶¨³Ì¶ÈÉÏ·´Ó³³ö¸÷ԺУ±ÏÒµÉúµÄÉÏÍøÇé¿ö¡£ ¡¡¡¡»¶Ó­´ó¼Ò¼°Ê±µÇ¼¡°Ð£ÓѼ¡±ÍøÕ¾£¬²¢½«Ëü¼ÓÈëÄãµÄÊղؼÐÀï¡£ ¡¡¡¡ From rsvp-owner@ISI.EDU Wed Mar 22 17:55:49 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 RAA09847 for ; Wed, 22 Mar 2000 17:55:49 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA22702 for rsvp-outgoing; Wed, 22 Mar 2000 13:14:24 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22697 for ; Wed, 22 Mar 2000 13:14:23 -0800 (PST) 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 NAA22174; Wed, 22 Mar 2000 13:14:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA09916; Wed, 22 Mar 2000 21:14:31 GMT Date: Wed, 22 Mar 2000 21:14:31 GMT Message-Id: <200003222114.VAA09916@gra.isi.edu> To: rsvp@ISI.EDU, mpls@uu.net, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> *> R2 ---- R3 *> / \ *> H1 ---- R1 R6 ---- R7 ---- H2 *> \ / *> R4 ---- R5 *> *> H1 sends out two Path messages (with different explicit route objects) *> to H2. *> This seems a little strange. How/why would an end host H1 know about the failover path in the middle of the network?? It seems to me more likely that R1 knows about this magic for Path messages, and can also do magic for Resv messages. Note that Explicit Route objects were pasted onto RSVP by someone other than the RSVP WG, and I don't know that anyone has thoroughly investigated the consequences. Bob Braden From rsvp-owner@ISI.EDU Wed Mar 22 18:43:14 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 SAA27069 for ; Wed, 22 Mar 2000 18:43:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA25142 for rsvp-outgoing; Wed, 22 Mar 2000 14:13:42 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25137 for ; Wed, 22 Mar 2000 14:13:40 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA00929 for ; Wed, 22 Mar 2000 14:13:51 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA12586; Wed, 22 Mar 2000 17:13:13 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA27614; Wed, 22 Mar 2000 17:13:15 -0500 (EST) Message-ID: <38D94582.6A9CC68D@fore.com> Date: Wed, 22 Mar 2000 17:13:22 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@uu.net Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222114.VAA09916@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: >> >> R2 ---- R3 >> / \ >> H1 ---- R1 R6 ---- R7 ---- H2 >> \ / >> R4 ---- R5 >> >> H1 sends out two Path messages (with different explicit route >> objects) to H2. > > This seems a little strange. How/why would an end host H1 know about > the failover path in the middle of the network?? It seems to me more > likely that R1 knows about this magic for Path messages, and can also > do magic for Resv messages. Sorry for the confusion here (I've been saying that a lot recently - I must start using terminology that everybody else understands). I chose to call the ends "H" because they perform the role that hosts do in a straight-RSVP environment - initiating and terminating RSVP messages. In the scenario I was thinking of, H1 and H2 are actually MPLS edge routers (LERs). They know about the full topology (and therefore know about the failover path). They are differentiated from the "R" routers in that they initiate the RSVP signalling when establishing LSPs between each other. > Note that Explicit Route objects were pasted onto RSVP by someone > other than the RSVP WG, and I don't know that anyone has thoroughly > investigated the consequences. Understood. This is the reason I posted my question to both the RSVP and MPLS lists. I figure that what one group doesn't know, the other may be able to answer. After reading replies messages by others, it appears that my understanding of how SE works was flawed, and the perceived problem does not actually exist. The one problem remaining, which doesn't appear to be covered by RSVP-TE or MPLS is how the ingress node (host or router) can tell the egress node that two paths are meant to share resources. I suppose this is a more generic RSVP issue as well. If it is desired that the sender choose the reservation style, this choice can not be signalled through any standard object in the Path message. It must be signalled out-of-band, or through a non-standard extension - in either case, something beyond the RSVP spec must be supported by both ends for this. It seems to me that it would be a good idea to have a mechanism for the sender to request a style of the recipient. (Of course, the recipient would still be free to ignore this request - to do otherwise would break existing implementations.) Perhaps via a new service type in the ADSPEC or something similar. -- David From rsvp-owner@ISI.EDU Wed Mar 22 18:57: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 SAA01573 for ; Wed, 22 Mar 2000 18:57:44 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA25883 for rsvp-outgoing; Wed, 22 Mar 2000 14:32:00 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25878 for ; Wed, 22 Mar 2000 14:31:59 -0800 (PST) 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 OAA03869; Wed, 22 Mar 2000 14:32:09 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA09985; Wed, 22 Mar 2000 22:32:08 GMT Date: Wed, 22 Mar 2000 22:32:08 GMT Message-Id: <200003222232.WAA09985@gra.isi.edu> To: rsvp@ISI.EDU, mpls@uu.net, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> *> The one problem remaining, which doesn't appear to be covered by RSVP-TE *> or MPLS is how the ingress node (host or router) can tell the egress *> node that two paths are meant to share resources. *> *> I suppose this is a more generic RSVP issue as well. If it is desired *> that the sender choose the reservation style, this choice can not be *> signalled through any standard object in the Path message. It must be *> signalled out-of-band, or through a non-standard extension - in either *> case, something beyond the RSVP spec must be supported by both ends for *> this. If I understand your problem, it is not really the reservation style you want to signal -- both ends KNOW that SE is to be used -- but some resource-sharing identifier tag. Is this correct? Bob From rsvp-owner@ISI.EDU Wed Mar 22 18:58:57 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 SAA01950 for ; Wed, 22 Mar 2000 18:58:57 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA25556 for rsvp-outgoing; Wed, 22 Mar 2000 14:24:14 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA25550 for ; Wed, 22 Mar 2000 14:24:12 -0800 (PST) Received: from mailrelay.laurelnetworks.com (laurelnetworks.com [206.67.234.84]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02070 for ; Wed, 22 Mar 2000 14:24:23 -0800 (PST) Received: from ganeshpc (ganesh-pc.laurelnetworks.com [192.168.0.30]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id RAA21592; Wed, 22 Mar 2000 17:24:20 -0500 From: "Ganesh Murugesan" To: "David Charlap" , , Subject: RE: Semantics of shared reservations (with RSVP) Date: Wed, 22 Mar 2000 17:26:43 -0800 Message-ID: <002401bf9466$d8c49480$8ac6fea9@laurelnetworks.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 In-reply-to: <38D94582.6A9CC68D@fore.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > > The one problem remaining, which doesn't appear to be covered by RSVP-TE > or MPLS is how the ingress node (host or router) can tell the egress > node that two paths are meant to share resources. > > I suppose this is a more generic RSVP issue as well. If it is desired > that the sender choose the reservation style, this choice can not be > signalled through any standard object in the Path message. It must be > signalled out-of-band, or through a non-standard extension - in either > case, something beyond the RSVP spec must be supported by both ends for > this. > > It seems to me that it would be a good idea to have a mechanism for the > sender to request a style of the recipient. (Of course, the recipient > would still be free to ignore this request - to do otherwise would break > existing implementations.) Perhaps via a new service type in the ADSPEC > or something similar. > > -- David > I am not sure if this is what you are asking for. The RSVP Extension for LSP tunnels draft has this section about the Session Attributes Object: 0x04 = Ingress node may reroute This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. The above sentence seems to indicate that the Ingress can indeed signal to the egress as to whether it should choose SE style or not. thanks ganesh From rsvp-owner@ISI.EDU Wed Mar 22 19:34: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 TAA15263 for ; Wed, 22 Mar 2000 19:34:41 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA27198 for rsvp-outgoing; Wed, 22 Mar 2000 15:03:32 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA27193 for ; Wed, 22 Mar 2000 15:03:30 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08256 for ; Wed, 22 Mar 2000 15:03:42 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA17042; Wed, 22 Mar 2000 18:03:09 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA06418; Wed, 22 Mar 2000 18:03:11 -0500 (EST) Message-ID: <38D95135.30A0046D@fore.com> Date: Wed, 22 Mar 2000 18:03:17 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@uu.net Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222232.WAA09985@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: >> >> The one problem remaining, which doesn't appear to be covered by >> RSVP-TE or MPLS is how the ingress node (host or router) can tell the >> egress node that two paths are meant to share resources. >> >> I suppose this is a more generic RSVP issue as well. If it is >> desired that the sender choose the reservation style, this choice can >> not be signalled through any standard object in the Path message. It >> must be signalled out-of-band, or through a non-standard extension - >> in either case, something beyond the RSVP spec must be supported by >> both ends for this. > > If I understand your problem, it is not really the reservation style > you want to signal -- both ends KNOW that SE is to be used -- but some > resource-sharing identifier tag. Is this correct? OK. Let me see if I can explain my assumptions and my question more clearly. Based on what others here have written, I understand that all paths in a single session that are reseved with SE style must share resources, right? This means that if a tunnel-ingress node sets up two different paths in the same session (differing only by their ERO), the decision on whether these two tunnels will share resources will be made by the egress node when it chooses a style for the reservation - SE for sharing, FF for no sharing. Sharing makes sense if the two paths are to be used for a primary/backup fail-over scenario. Where one carries all data until it fails, then the ingress node immediately starts sending data over the backup path. This way, it doesn't have to wait for a new path to be signalled. (Note that this is not the make-before-break scenario of the MPLS-RSVP draft. That scenario doesn't set up the backup tunnel until it is time move traffic to it.) In other situations, not sharing makes sense. For instance, if the two paths are to be used for a load-balancing scenario. Where the ingress node sends packets over both tunnels. (Hopefully, with enough intelligence so that TCP doesn't end up breaking.) In this scenario, FF would be the preferred style. (Of course, this effect could also be created by using two sessions and either style.) In short, I can see reasons why it would make sense for two tunnels in the same session from a single sender node to use FF or SE style. But the ingress node has no standard way of indicating in its Path message that it wants to use one style or another. The decision depends on something else (probably administrative configuration of the egress nodes.) I hope this is clearer. -- David From rsvp-owner@ISI.EDU Wed Mar 22 19:50: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 TAA21499 for ; Wed, 22 Mar 2000 19:50:18 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA28338 for rsvp-outgoing; Wed, 22 Mar 2000 15:26:09 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28333 for ; Wed, 22 Mar 2000 15:26:08 -0800 (PST) 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 PAA11791; Wed, 22 Mar 2000 15:26:18 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA10069; Wed, 22 Mar 2000 23:26:17 GMT Date: Wed, 22 Mar 2000 23:26:17 GMT Message-Id: <200003222326.XAA10069@gra.isi.edu> To: rsvp@ISI.EDU, mpls@uu.net, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk David, Thanks for taking the trouble to explain to me. But I must admit I am still unconvinced. There are two "scenarios" at issue: failover vs. load balancing, which have completely different semantics. I would expect that all the nodes (at least the ingress and egress) must be solidly configured for one or the other of these "scenarios", and the scenario will imply the correct reservation style. But then, I am just an academic, what do I know? As far the original issue is concerned, I had trouble following the discussion, but here is what seems like a simple way to think about it. In sending out two paths, H1 is serving as two logical senders, distinguished by ERO. I don't know if this is the way it DOES work, but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1, ERO2)), which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q, (ERO2)) along the two paths. These get merged again by R1 into Resv(SE, Q, (ERO1, ERO2)). This creates one shared reservation at H1, as desired. Bob Braden From rsvp-owner@ISI.EDU Wed Mar 22 20:43: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 UAA10555 for ; Wed, 22 Mar 2000 20:43:35 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA29173 for rsvp-outgoing; Wed, 22 Mar 2000 15:46:13 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA29168 for ; Wed, 22 Mar 2000 15:46:11 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14319 for ; Wed, 22 Mar 2000 15:46:22 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA20225; Wed, 22 Mar 2000 18:45:44 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA11867; Wed, 22 Mar 2000 18:45:47 -0500 (EST) Message-ID: <38D95B31.F3D3F2C0@fore.com> Date: Wed, 22 Mar 2000 18:45:53 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@uu.net Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222326.XAA10069@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > > Thanks for taking the trouble to explain to me. But I must admit I am > still unconvinced. There are two "scenarios" at issue: failover vs. > load balancing, which have completely different semantics. I would > expect that all the nodes (at least the ingress and egress) must be > solidly configured for one or the other of these "scenarios", and > the scenario will imply the correct reservation style. Perhps, but it seems to me that only the ingress node (which classifies the packets into one tunnel or the other) really needs to know anything special, if the correct reservation style is chosen at the other end. > As far the original issue is concerned, I had trouble following the > discussion, but here is what seems like a simple way to think about > it. In sending out two paths, H1 is serving as two logical senders, > distinguished by ERO. I don't know if this is the way it DOES work, > but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1, > ERO2)), which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q, > (ERO2)) along the two paths. These get merged again by R1 into > Resv(SE, Q, (ERO1, ERO2)). This creates one shared reservation at H1, > as desired. Correct. My original question was based on a gross misunderstanding of SE. I was under the impression that a single session under SE could have multiple flow descriptors - that is, multiple groups of senders that share resources within the group but not with other groups. Based on other posts here, which encouraged me to look more closely at the RFCs, I now believe that I was wrong in that assumption. So the original problem (of how R1 can properly re-merge the two single-sender reservations back into a single shared reservation) no longer exists. I can go into the details of my original misunderstanding if you're interested, but I'll take that off the list, since it really isn't relevant. -- David From rsvp-owner@ISI.EDU Wed Mar 22 22:29:16 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 WAA21390 for ; Wed, 22 Mar 2000 22:29:15 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA02163 for rsvp-outgoing; Wed, 22 Mar 2000 16:55:46 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA02158 for ; Wed, 22 Mar 2000 16:55:44 -0800 (PST) Received: from mlsrv1.avici.com ([208.246.215.9]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA24601 for ; Wed, 22 Mar 2000 16:55:55 -0800 (PST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id TAA00146; Wed, 22 Mar 2000 19:55:17 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id TAA43297; Wed, 22 Mar 2000 19:55:33 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003230055.TAA43297@curtis-lt.avici.com> To: David Charlap cc: rsvp@ISI.EDU, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Semantics of shared reservations (with RSVP) In-reply-to: Your message of "Wed, 22 Mar 2000 18:03:17 EST." <38D95135.30A0046D@fore.com> Date: Wed, 22 Mar 2000 19:55:33 -0500 From: Curtis Villamizar Sender: owner-rsvp@ISI.EDU Precedence: bulk In message <38D95135.30A0046D@fore.com>, David Charlap writes: > Bob Braden wrote: > >> > >> The one problem remaining, which doesn't appear to be covered by > >> RSVP-TE or MPLS is how the ingress node (host or router) can tell the > >> egress node that two paths are meant to share resources. > >> > >> I suppose this is a more generic RSVP issue as well. If it is > >> desired that the sender choose the reservation style, this choice can > >> not be signalled through any standard object in the Path message. It > >> must be signalled out-of-band, or through a non-standard extension - > >> in either case, something beyond the RSVP spec must be supported by > >> both ends for this. > > > > If I understand your problem, it is not really the reservation style > > you want to signal -- both ends KNOW that SE is to be used -- but some > > resource-sharing identifier tag. Is this correct? > > OK. Let me see if I can explain my assumptions and my question more > clearly. > > Based on what others here have written, I understand that all paths in a > single session that are reseved with SE style must share resources, > right? > > This means that if a tunnel-ingress node sets up two different paths in > the same session (differing only by their ERO), the decision on whether > these two tunnels will share resources will be made by the egress node > when it chooses a style for the reservation - SE for sharing, FF for no > sharing. > > Sharing makes sense if the two paths are to be used for a primary/backup > fail-over scenario. Where one carries all data until it fails, then the > ingress node immediately starts sending data over the backup path. This > way, it doesn't have to wait for a new path to be signalled. (Note that > this is not the make-before-break scenario of the MPLS-RSVP draft. That > scenario doesn't set up the backup tunnel until it is time move traffic > to it.) > > In other situations, not sharing makes sense. For instance, if the two > paths are to be used for a load-balancing scenario. Where the ingress > node sends packets over both tunnels. (Hopefully, with enough > intelligence so that TCP doesn't end up breaking.) In this scenario, FF > would be the preferred style. (Of course, this effect could also be > created by using two sessions and either style.) > > In short, I can see reasons why it would make sense for two tunnels in > the same session from a single sender node to use FF or SE style. But > the ingress node has no standard way of indicating in its Path message > that it wants to use one style or another. The decision depends on > something else (probably administrative configuration of the egress > nodes.) > > I hope this is clearer. > > -- David > David, Bob, Hope this helps: Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-05.txt February 2000 ... 2.4.3. Shared Explicit (SE) Style The Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on a link for all the senders listed. Because each sender is explicitly listed in the Resv message, different labels may be assigned to different senders, thereby creating separate LSPs. SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender. Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects. In either of these cases a common label may be assigned. Path messages from different senders can each carry their own ERO, and the paths taken by the senders can converge and diverge at any point in the network topology. When Path messages have differing EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object must be established. The next section explains how to use this to reroute tunnels. It explains when reservation amounts can be shared when doing make-before-break rerouting. A further restriction is found in another draft. Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-05.txt February 2000 3.6 E-LSP Merging In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. E-LSPs are compatible with LSP Merging under the following condition: E-LSPs can only be merged into one LSP if they support the exact same set of BAs. ... 4.6 L-LSP Merging In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. The proposed support of Diff-Serv in MPLS is compatible with LSP Merging under the following condition: L-LSPs can only be merged into one L-LSP if they support the same PSC. This seems clear enough once you find it. Curtis From rsvp-owner@ISI.EDU Thu Mar 23 12:34: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 MAA01650 for ; Thu, 23 Mar 2000 12:34:07 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA29504 for rsvp-outgoing; Thu, 23 Mar 2000 07:10:38 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29498 for ; Thu, 23 Mar 2000 07:10:37 -0800 (PST) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA27368; Thu, 23 Mar 2000 07:10:48 -0800 (PST) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA16627; Thu, 23 Mar 2000 10:10:16 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 10:10:16 -0500 Message-ID: From: Dimitry Haskin To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com Subject: RE: Semantics of shared reservations (with RSVP) Date: Thu, 23 Mar 2000 10:10:15 -0500 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 > David, > > Thanks for taking the trouble to explain to me. But I must admit I am > still unconvinced. There are two "scenarios" at issue: failover vs. > load balancing, which have completely different semantics. I would > expect that all the nodes (at least the ingress and egress) must be > solidly configured for one or the other of these "scenarios", and > the scenario will imply the correct reservation style. > A small but important correction: it is not necessary "one or the other" -- a load balancing reservation may be protected by a failover path. Dimitry From rsvp-owner@ISI.EDU Thu Mar 23 13:39:15 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26029 for ; Thu, 23 Mar 2000 13:39:13 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA02509 for rsvp-outgoing; Thu, 23 Mar 2000 08:35:55 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA02504 for ; Thu, 23 Mar 2000 08:35:53 -0800 (PST) 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 IAA05971; Thu, 23 Mar 2000 08:35:57 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA10407; Thu, 23 Mar 2000 16:35:57 GMT Date: Thu, 23 Mar 2000 16:35:57 GMT Message-Id: <200003231635.QAA10407@gra.isi.edu> To: braden@ISI.EDU, rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com, dhaskin@nexabit.com Subject: RE: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> From dhaskin@nexabit.com Thu Mar 23 07:10:49 2000 *> From: Dimitry Haskin *> To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com *> Subject: RE: Semantics of shared reservations (with RSVP) *> Date: Thu, 23 Mar 2000 10:10:15 -0500 *> MIME-Version: 1.0 *> X-Mailer: Internet Mail Service (5.5.2650.21) *> X-Lines: 13 *> *> > David, *> > *> > Thanks for taking the trouble to explain to me. But I must admit I am *> > still unconvinced. There are two "scenarios" at issue: failover vs. *> > load balancing, which have completely different semantics. I would *> > expect that all the nodes (at least the ingress and egress) must be *> > solidly configured for one or the other of these "scenarios", and *> > the scenario will imply the correct reservation style. *> > *> A small but important correction: it is not necessary "one or the other" -- *> a load balancing reservation may be protected by a failover path. *> *> Dimitry *> I which case you use reservation style (SE+FF)/2, I suppose. Your comments seems orthogonal to my point. Bob From rsvp-owner@ISI.EDU Thu Mar 23 14:05: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 OAA06752 for ; Thu, 23 Mar 2000 14:05:43 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA03655 for rsvp-outgoing; Thu, 23 Mar 2000 09:05:15 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03650 for ; Thu, 23 Mar 2000 09:05:14 -0800 (PST) Received: from tid.es (tidos.tid.es [193.145.240.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA10953 for ; Thu, 23 Mar 2000 09:05:17 -0800 (PST) Received: from tid.es (lnieto [1.0.18.173]) by tid.es (8.9.3/8.9.1) with ESMTP id SAA17795 for ; Thu, 23 Mar 2000 18:01:02 +0100 (MET) Posted-Date: Thu, 23 Mar 2000 18:01:02 +0100 (MET) Message-ID: <38DA5014.994A7B3A@tid.es> Date: Thu, 23 Mar 2000 18:10:44 +0100 From: Ana Maria Lopez Nieto X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: unsuscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit unsuscribe From rsvp-owner@ISI.EDU Thu Mar 23 14:17: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 OAA11022 for ; Thu, 23 Mar 2000 14:17:31 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA03864 for rsvp-outgoing; Thu, 23 Mar 2000 09:10:57 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA03859 for ; Thu, 23 Mar 2000 09:10:55 -0800 (PST) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11576; Thu, 23 Mar 2000 09:11:06 -0800 (PST) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id MAA17750; Thu, 23 Mar 2000 12:10:35 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:10:35 -0500 Message-ID: From: Dimitry Haskin To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com, Dimitry Haskin Subject: RE: Semantics of shared reservations (with RSVP) Date: Thu, 23 Mar 2000 12:10:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk Bob, I just tried to point out that configuring the nodes for one or the other scenarios may not be a solution and when RSVP is used for MPLS some kind of additional RSVP signaling may be needed to insure that the working and failover paths are set correctly. However I might have diverted from the subject of the thread. Dimitry > *> > > *> > Thanks for taking the trouble to explain to me. But I > must admit I am > *> > still unconvinced. There are two "scenarios" at > issue: failover vs. > *> > load balancing, which have completely different > semantics. I would > *> > expect that all the nodes (at least the ingress and > egress) must be > *> > solidly configured for one or the other of these > "scenarios", and > *> > the scenario will imply the correct reservation style. > *> > > *> A small but important correction: it is not necessary > "one or the other" -- > *> a load balancing reservation may be protected by a failover path. > *> > *> Dimitry > *> > I which case you use reservation style (SE+FF)/2, I suppose. > > Your comments seems orthogonal to my point. > > Bob > From rsvp-owner@ISI.EDU Fri Mar 24 15:29:03 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 PAA14096 for ; Fri, 24 Mar 2000 15:29:02 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA25907 for rsvp-outgoing; Fri, 24 Mar 2000 10:25:29 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA25902 for ; Fri, 24 Mar 2000 10:25:25 -0800 (PST) Received: from smtp3.libero.it ([193.70.192.53]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA24986 for ; Fri, 24 Mar 2000 10:25:32 -0800 (PST) Received: from k2k8y5 (151.28.128.191) by smtp3.libero.it; 24 Mar 2000 19:24:56 +0100 Message-ID: <002201bf95bd$4503d5a0$bf801c97@k2k8y5> From: "Giuseppe Caldarazzo" To: Date: Fri, 24 Mar 2000 19:17:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01BF95C5.8C7D96C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01BF95C5.8C7D96C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_0017_01BF95C5.8C7D96C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_0017_01BF95C5.8C7D96C0-- From rsvp-owner@ISI.EDU Fri Mar 24 15:53:13 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 PAA23293 for ; Fri, 24 Mar 2000 15:53:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA27571 for rsvp-outgoing; Fri, 24 Mar 2000 11:12:32 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA27566 for ; Fri, 24 Mar 2000 11:12:30 -0800 (PST) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA02366 for ; Fri, 24 Mar 2000 11:12:42 -0800 (PST) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA22169 for ; Fri, 24 Mar 2000 11:12:43 -0800 (PST) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA08223 for ; Fri, 24 Mar 2000 11:12:41 -0800 (PST) Date: Fri, 24 Mar 2000 11:12:40 -0800 (PST) From: demir To: rsvp@ISI.EDU Subject: A question on RSVP deployment In-Reply-To: <002201bf95bd$4503d5a0$bf801c97@k2k8y5> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi, Is there any information on the number of domains that deployed RSVP coupled with other components of IntServ Architecture and using it? (or deployments are not in domain level?) Alper K. Demir, PhD student Computer Science Dept. University of Southern California From rsvp-owner@ISI.EDU Sun Mar 26 00:52:28 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 AAA15683 for ; Sun, 26 Mar 2000 00:52:27 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA29881 for rsvp-outgoing; Sat, 25 Mar 2000 19:37:01 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA29876 for ; Sat, 25 Mar 2000 19:36:59 -0800 (PST) Received: from ms.accnet.com.tw (ms.accnet.com.tw [202.145.242.1]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id TAA25425 for ; Sat, 25 Mar 2000 19:37:05 -0800 (PST) Received: from acer (unverified [203.149.131.162]) by ms.accnet.com.tw (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 26 Mar 2000 11:35:21 +0800 Message-ID: From: "2-JOB" Reply-To: webmaster@ms0.copy.com.tw Subject: Áܽбz¤@°_¨Ó¥[¤J To: andy@ms33.hinet.net X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sun, 26 Mar 2000 22:30:53 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk §ä¤u§@»âÁ~¤ô¡A«Ü¦nªº¿ï¾Ü¡I­Y·Q­n¹ï¦Û¤vªº¯à¤O§@¤@­Ó·¥«×ªº¬D¾Ô¡A³Ð·~¤]¬O¤@­Ó«Ü¦nªº¨M©w¡I ¥j¤§¦W°V¡G³Ð·~ºûÁ}¡C¤°»ò¼Ëªº¨Æ·~³Ì·s¡B³t¡B¹ê¡B²©O¡H ¹ï¤F¡Iºô¸ô....³Ì¯à²Å¦X®É¤Uªº¼é¬y¡C ¨º­n¦p¦ó³Ð³yºô¸ô¤½¥qªº»ù­È©O¡H¤H¼é¡H«~µP¡H¦æ¾P¡H°t°e¡H¸ê°T¬¡¤Æ..... ¨«¶i¤@®a¤½¥q¡AÆ[¹î©Î±µÄ²¥Lªº­û¤u¡A·P¨ü¿ì¤½«Ç®ðª^¡A¤K¦¨¥i¥H²q´ú¥X³o­Ó³æ¦ì¥DºÞªººÞ²z­·®æ©Î¿ì¤½¤å¤Æ¡C ¿ì¤½«Çªº¤å¤Æ¦p¦ó§Î¦¨¡H§Ú­Ì±`·|»¡¡u¦ÛµM§Î¦¨¡v¡A¨ä¹ê¨Ã¤£§¹¥þ¥¿½T¡A¥u­nºÞ²zªÌ¦³¤ß¡A¨ä¹êÀô¹Ò¤Î¤å¤Æ¬O¥i¥H¶ì³y¤Î°ö¾iªº¡C ¦pªG±z¦³¤ß¡A·Q¤F¸Ñ¿ì¤½«Ç¤å¤Æªº§ï³y¤èªk¡A½Ð¨Ó³Ì±M·~ªºÂ¾³õ¤H¤Oºôhttp://www.2-job.com§¤§¤¡C ºô¸ô¼ö¼é¿³°_¡A³nÅé¼t°Ó¯É¯É´Âºô¸ôÂ૬¡A°£¤F¶}µo»Pºô¸ôµ²¦Xªº³nÅé²£«~¥~¡A ¨Ã¥þ¤O¶i­x¹q¤l°Ó°ÈÉ]³õ¡A±a°Ê¹ï¬ÛÃöªººô¸ô³nÅé¬ãµo§Þ³N¤H¤~¡Bºô¸ô¦æ¾P¤H¤~ªº»Ý¨D¤j¼W¡A ¤£¤Ö¨­­tºô¸ô³nÅé§Þ³N±M¤~ªº¤H­ûªñ¨Óª±°_¡u¤j­·§j¡v¡C ±z¬O¤H¤~¶Ü¡H±z¬O°ª¤â¶Ü¡H»°§Ö¨Ó¬Ý¬Ý¡A³o­Ó¸ê°T¾³õ¤j­·¬O«ç»ò§jªº¡I http://www.2-job.com ====================== From rsvp-owner@ISI.EDU Tue Mar 28 02:17:49 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 CAA17230 for ; Tue, 28 Mar 2000 02:17:48 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA05821 for rsvp-outgoing; Mon, 27 Mar 2000 20:39:19 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA05816 for ; Mon, 27 Mar 2000 20:39:18 -0800 (PST) Received: from sims.sol.com.br (mail.sol.com.br [200.230.143.253]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA06009 for ; Mon, 27 Mar 2000 20:39:30 -0800 (PST) From: xa3cX9UFo@mcs.surrey.ac.uk Received: from 6H1YMQH2m (ppp-259.tnt-1.hou.smartworld.net) by sims.sol.com.br (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with SMTP id <0FS400FXW7BUIQ@sims.sol.com.br> for rsvp@isi.edu; Tue, 28 Mar 2000 01:34:43 -0300 (EST) Date: Mon, 27 Mar 2000 10:38:21 +0000 (PM) Subject: EDGAR FILING To: miguel@IDIAP.CH, ddavis@cacr.caltech.edu, kdroege@ou.edu, stephanh@wins.uva.nl, kknisely@access.digex.net, D.Wilson@mmu.ac.uk, www.mail@ciesin.org, rsvp@ISI.EDU, crs@noaa8.lax.noaa.gov, ennis_S_Schain@travelers.com, swift@pilotonline.com, mcade@attmail.com, robbert@IDIAP.CH, dpa@ntserver.physics.udel.edu, rmeader1@maine.rr.com, rsaref-administrator@rsa.com, betsy@wid.org, bryon@softdisk.com, theodric@mit.edu, Kovach@pendragonbbs.com, sabio@sabio.library.Arizona.EDU, catalog.request@moobasi.vnet.net, Ancestor@net1.comm.com, grl@grl.com, corkykn@imt.net Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Optimum Source International, Ltd. Announces Report For Fiscal Year Ended December 31, 1999 LAS VEGAS, Mar 15, 2000 /PRNewswire via COMTEX/ -- Optimum Source International Ltd. (OTC Bulletin Board: OSIN), today announced results for the year ending December 31, 1999. For the year ending December 31, 1999, OSIN reported an increase in net sales of $182,626 compared to revenues of $45,905 in the prior year. Net income for 1999 was $126,226, or $0.03 per share, based on 2,887,004 weighted average shares outstanding compared to a net loss of $ (0.05) per share based on 1,654,051 weighted average shares outstanding for 1998. For a complete report please visit the following Edgar Archive address: http://www.sec.gov/Archives/edgar/data/1056256/0000939802-00-000005.txt James O'Brien, Chief Executive Officer, commented, "OSI has completed its recent relocation to Las Vegas, Nevada, and its new warehouse facility. OSI is now finalizing a 5 million 506 offering to assist in the acquisition of inventories to promote additional working capital." About OSIN The Company's primary mission is Barter/Counter-trade and its proprietary interactive services both Domestic and International and encompassing the liquidation and auction industries globally. Optimum Source International Ltd. (OSI), is poised with products and services for individuals, entrepreneurs, and companies of all sizes that are desirous of learning or enhancing their bartering, trading and counter-trading skills. Products are developed to fully integrate with each other or may be used as stand-alone products. All products and services are currently offered on the Internet, and through selected channels of distribution. Certain statements contained herein are "forward-looking" statements (as such term is defined in the Private Securities Litigation Reform Act of 1995). Because such statements include risks and uncertainties, actual results may differ materially from those expressed or implied by such forward-looking statements. Factors that could cause or contribute to such differences include continued acceptance of the Company's products in the marketplace, the timing of significant orders, delays in the Company's ability to develop or ship new products, market acceptance of new products, competitive factors, general economic conditions, currency fluctuations, and other risks detailed in the Company's registration statements and periodic reports filed with the Securities and Exchange Commission. By making these forward-looking statements, the Company undertakes no obligation to update these statements for revisions or changes after the date of this release. SOURCE Optimum Source International, Ltd. to be removed from this list mailto:sms@berlinoffice.com?subject=remove From rsvp-owner@ISI.EDU Tue Mar 28 13:43: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 NAA24829 for ; Tue, 28 Mar 2000 13:43:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA29601 for rsvp-outgoing; Tue, 28 Mar 2000 08:38:01 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA29596 for ; Tue, 28 Mar 2000 08:38:00 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA13085 for ; Tue, 28 Mar 2000 08:38:12 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA11676 for ; Tue, 28 Mar 2000 18:38:06 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Tue, 28 Mar 2000 18:37:17 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 28 Mar 2000 16:37:17 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Mar 2000 18:37:59 +0200 Message-ID: From: "Simon Oosthoek (EMN)" To: "'rsvp@isi.edu'" Subject: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) Date: Tue, 28 Mar 2000 17:55:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 28 Mar 2000 16:37:17.0375 (UTC) FILETIME=[E13854F0:01BF98D3] Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi There, I've just started working with RSVP (or rather, attempted to get started). We are going to use RSVP in our lab for QoS on Wireless IP networks and possibly to interact with DiffServ based QoS. So far I've had little success compiling the available RSVP sources on recent versions of linux (we use Mandrake 6.x or 7.x at the moment) As a desperate measure, I tried an old Red Hat 5.2 distro and suddenly I could compile rsvpd on Linux. Starting from there (a certainty that it did compile on Linux) I tried again to compile rsvp (rel4.2a3 btw, I think it's Phil Wang's version) on Mandrake 6.1. With some help of a colleague, I was able to find the problem in the source (or at least one of the problems) and now I can compile rsvpd there as well. Now I'm wondering why nobody else had trouble with this before, or is everyone using ancient versions of Linux? Also, the problem in the code was really silly and not too difficult to fix (I mean, I could do it and I have no experience programming in C). It involved changing the include of huge_val.h to math.h and renaming all occurances of log() to printlog(). Oh and some other things involving a certain "system.h" which should not be included, because it redefines existing system calls or something. I'm not there yet, the apitools don't compile yet (and anything after that, I don't know) I would love to exchange information/ideas and code with others who are working with RSVP on Linux or other platforms with these problems... Cheers Simon -- Phone: +31 53 450 5542 (fax: ~5550) E-mail: Simon.Oosthoek@emn.ericsson.se From proms@saturn.kt.agh.edu.pl Tue Mar 28 14:38:43 2000 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25436 for ; Tue, 28 Mar 2000 14:38:40 -0500 (EST) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id VAA24543 for ; Tue, 28 Mar 2000 21:38:38 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA20645; Tue, 28 Mar 2000 21:37:48 +0100 Date: Tue, 28 Mar 2000 21:37:48 +0100 From: proms@saturn.kt.agh.edu.pl (Piotr Pacyna) Message-Id: <10003282037.AA20645@saturn.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: rsvp-archive@ietf.org Subject: PROMS2000 Call for Papers Dear Sir, Dear Madam, Please find enclosed the Protocols for Multimedia Systems conference CfP. Please read it and send to your collegues. Thank you for your attention. We do apologise if you receive multiple copies of this. With best regards, Piotr Pacyna ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (Please apologize, if you receive multiple copies of this CfP) Announcement and Call for Papers PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks * multimedia traffic engineering; * applications and platforms for service management and provisioning; * definition, provisioning, and supervision of QoS parameters for networked applications and services; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due June 26, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From rsvp-owner@ISI.EDU Thu Mar 30 04:23:49 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 EAA14582 for ; Thu, 30 Mar 2000 04:23:49 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA18787 for rsvp-outgoing; Wed, 29 Mar 2000 23:00:51 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id XAA18782 for ; Wed, 29 Mar 2000 23:00:49 -0800 (PST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA10483 for ; Wed, 29 Mar 2000 23:01:04 -0800 (PST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 22:58:48 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC711@SOL> From: Andrew Smith To: "'rsvp@isi.edu'" , "'rap@iphighway.com'" Subject: Comments on draft-ietf-rsvp-proxy-00.txt Date: Wed, 29 Mar 2000 22:58:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rsvp@ISI.EDU Precedence: bulk Some comments re the WG last call on the above draft - apologies for being so close to the deadline but it's been a busy week. 1. This work is not yet ready for RFC publication as WG output. 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. 3. Subflows? what is this all about? 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. 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. 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. 8. Section 5: should not be making any changes to RSVP recommendations here. 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. Andrew Smith From rsvp-owner@ISI.EDU Thu Mar 30 09:14: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 JAA16635 for ; Thu, 30 Mar 2000 09:14:52 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA27533 for rsvp-outgoing; Thu, 30 Mar 2000 03:51:27 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA27528 for ; Thu, 30 Mar 2000 03:51:26 -0800 (PST) Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA06143 for ; Thu, 30 Mar 2000 03:51:39 -0800 (PST) Received: from nitsan-8000 (oz-syd-dial1-29.cisco.com [144.254.157.30]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id NAA05338; Thu, 30 Mar 2000 13:52:43 +0200 (IST) Reply-To: From: "Nitsan Elfassy" To: "'Andrew Smith'" , "'rsvp@isi.edu'" , Subject: RE: Comments on draft-ietf-rsvp-proxy-00.txt Date: Thu, 30 Mar 2000 13:49:24 +0200 Message-ID: <001201bf9a3e$82439420$3b9dfe90@nitsan-8000.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 Importance: Normal In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC711@SOL> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Andrew, See inline: (I have answered those parts which I know all co-authors are in full consensus.) > > Some comments re the WG last call on the above draft - > apologies for being > so close to the deadline but it's been a busy week. > > 1. This work is not yet ready for RFC publication as WG output. > > 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. We all agree with you, I guess. Usage of Proxy action to NULL service was (or meant to) brought as an example. > > 3. Subflows? what is this all about? I would remove that issue, unless my co-authors disagree (??). > > 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. The wording may not be clear enough about it but we certainly refer to Resv State installation, which requires that the router should behave accordingly (i.e. send refresh messages, keep the state information). Let me add some history. When Silvano presented draft-ietf-rsvp-proxy-00.txt to the RSVP WG in Washington, three questions were asked: 1. Does Proxy breaks or adds a new behavior to RSVP ? 2. If Proxy then why only Resv ? What about Proxying Path messages ? 3. Does anyone fines RSVP Proxy useful ? The answers that were given: 1. Bob B. and Lixia X. both concluded that Proxy RSVP does not require any addition to the RSVP protocol RFC. However, they did agree that there is a need for an informational document that will shed a light on RSVP Proxy possible usage. 2. On that same meeting we all agreed that the Proxy model should apply not only to Resv but also to Path message. Maybe it should have been better reflected. Anyway, it is not only about answering a Path message. 3. Benny R. from Lucent and Diana from MCI backed up the Cisco co-authors proposed usage and pointed out Resv Proxy as very useful. Both emphasized it should be used for ALL RSVP services. > > 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). Yes it is a policy/configuration issue, but since this document meant to shed a light on the possible usage, a clarification would remove any doubt. > > 6. Section 3.1: There is no need to specify all those details of RSVP > message syntax and rules: the behavior of what goes in a > RESV message is > already defined by RFC2205. > Agreed. > 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. > > 8. Section 5: should not be making any changes to RSVP > recommendations here. > > 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. > thanks, Nitsan > > Andrew Smith > > > > > > From rsvp-owner@ISI.EDU Thu Mar 30 15:05:06 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 PAA21090 for ; Thu, 30 Mar 2000 15:05:03 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA11008 for rsvp-outgoing; Thu, 30 Mar 2000 10:11:45 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA11003 for ; Thu, 30 Mar 2000 10:11:44 -0800 (PST) Received: from hal.cs.wmich.edu (hal.cs.wmich.edu [141.218.40.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA22138 for ; Thu, 30 Mar 2000 10:11:58 -0800 (PST) Received: from csx01 (csx01.cs.wmich.edu [141.218.40.155]) by hal.cs.wmich.edu (8.9.3/8.9.3) with ESMTP id NAA28994 for ; Thu, 30 Mar 2000 13:11:54 -0500 (EST) Date: Thu, 30 Mar 2000 13:11:53 -0500 (EST) From: SARIPALLI SUPRIYA X-Sender: ssaripal@csx01 To: rsvp@ISI.EDU Subject: Re: Masters Project Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi all... I am a student of Western Michigan university doing my Masters in computer science..I am right now working on my Masters project and the topic I choice is Voice over IP..I am dealing into the QoS of Voice packets..During the course of my research RSVP interested me a lot.. Just have a couple of questions regarding the protocol.. Could you let me know if could do any kind of software implementation in the infrastructure I have got in my university..I read a lot about RSVP,RAPI, RSRR, Reservation styles, Soft states etc... If you could give me an idea in any of the above areas where I could implement something, I would greatly appreciate that... --Supriya ****************************************************************************** Supriya Saripalli T.A CS Department Phone # 616-387-5521 ******************************************************************************* From rsvp-owner@ISI.EDU Fri Mar 31 09:11:02 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 JAA13782 for ; Fri, 31 Mar 2000 09:11:01 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA13662 for rsvp-outgoing; Fri, 31 Mar 2000 03:11:50 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA13657 for ; Fri, 31 Mar 2000 03:11:48 -0800 (PST) Received: from ish7.ericsson.com.au ([203.61.155.111]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA02563 for ; Fri, 31 Mar 2000 03:12:02 -0800 (PST) Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id VAA06872 for ; Fri, 31 Mar 2000 21:10:27 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA19165 for ; Fri, 31 Mar 2000 21:11:11 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0) id ; Fri, 31 Mar 2000 21:10:40 +1000 Message-ID: <2B6FBFA9C95FD211AE480008C71E077602A42C4C@eaumcnt015.epa.ericsson.se> From: "Brian Williams (EPA)" To: rsvp@ISI.EDU Subject: Comments on draft-ietf-rsvp-proxy-00.txt Date: Fri, 31 Mar 2000 21:10:38 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9B01.BF384CD6" Sender: owner-rsvp@ISI.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9B01.BF384CD6 Content-Type: text/plain; charset="iso-8859-1" The RSVP receiver proxy draft appears to cover the null service case quite reasonably. However, I would also like to see the receiver proxy cover another case also. On page 4 of the draft, there are two diagrams shown: case A for normal RSVP processing, and case B for RSVP receiver proxy. My question is what happens for the situation where the host H1 initiates an RSVP session but the host H2 does not support RSVP. If the RSVP was proxied at R1, the RSVP session could be mapped to DS which would provide some QoS for the data stream to the host H2. However, you do not know at that stage whether host H2 supports RSVP or not. Here, the decision to proxy at R1 cannot be a simple policy decision that can be made when the PATH is received at R1 as it depends on whether host H2 is RSVP capable or not. If H2 is RSVP capable, then you may not install/retain the RSVP proxy at R1. However, if host H2 is not RSVP capable (does not respond to PATH message), then it would be beneficial to install the proxy at R1 as shown in this draft. I believe it would be beneficial to consider this case also in the draft, since it is another situation that would lead to case B. /brian ------_=_NextPart_001_01BF9B01.BF384CD6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-rsvp-proxy-00.txt

The RSVP receiver proxy draft appears to cover the = null service case quite reasonably.

However, I would also like to see the receiver proxy = cover another case also. On page 4 of the draft, there are two diagrams = shown: case A for normal RSVP processing, and case B for RSVP receiver = proxy.

My question is what happens for the situation where = the host H1 initiates an RSVP session but the host H2 does not support = RSVP. If the RSVP was proxied at R1, the RSVP session could be mapped = to DS which would provide some QoS for the data stream to the host H2. = However, you do not know at that stage whether host H2 supports RSVP or = not.

Here, the decision to proxy at R1 cannot be a simple = policy decision that can be made when the PATH is received at R1 as it = depends on whether host H2 is RSVP capable or not. If H2 is RSVP = capable, then you may not install/retain the RSVP proxy at R1. However, = if host H2 is not RSVP capable (does not respond to PATH message), then = it would be beneficial to install the proxy at R1 as shown in this = draft.

I believe it would be beneficial to consider this = case also in the draft, since it is another situation that would lead = to case B.

/brian

------_=_NextPart_001_01BF9B01.BF384CD6-- From rsvp-owner@ISI.EDU Fri Mar 31 10:50:46 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 KAA14896 for ; Fri, 31 Mar 2000 10:50:45 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA18267 for rsvp-outgoing; Fri, 31 Mar 2000 05:51:15 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA18262 for ; Fri, 31 Mar 2000 05:51:14 -0800 (PST) Received: from ctsincsisxic.cts-corp.com ([202.54.64.136]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id FAA08926 for ; Fri, 31 Mar 2000 05:51:21 -0800 (PST) Received: from 162.44.9.80 by ctsincsisxic.cts-corp.com (InterScan E-Mail VirusWall NT); Fri, 31 Mar 2000 19:22:44 +0530 Received: from ctsincsisxic.cts-corp.com (CTSINCSISXIC [162.44.9.80]) by ctsincsisxic.cts-corp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id H8Z9FRRY; Fri, 31 Mar 2000 19:22:44 +0530 Received: from 206.136.109.204 by ctsincsisxic.cts-corp.com (InterScan E-Mail VirusWall NT); Fri, 31 Mar 2000 19:22:43 +0530 Received: from ex0501-5a4 ([206.136.109.46]) by rnd.cts-corp.com (8.9.3/8.8.7) with SMTP id TAA00834 for ; Fri, 31 Mar 2000 19:26:55 +0530 Received: by localhost with Microsoft MAPI; Fri, 31 Mar 2000 19:20:15 +0530 Message-ID: <01BF9B46.24886DC0.psumit@rnd.cts-corp.com> From: sumit pandey Reply-To: "psumit@rnd.cts-corp.com" To: "'rsvp@ISI.EDU'" Subject: query regarding rsvp Date: Fri, 31 Mar 2000 19:20:13 +0530 Organization: cts X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit i'm at present making a study on rsvp. i wanted to know whether rsvp is just a signalling protocol or does it actually reserve bandwidth. if so then how does the bandwidth reservation actually work does it mean reserving the ports or providing higher priority to the packets From rsvp-owner@ISI.EDU Fri Mar 31 13:08:06 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 NAA16970 for ; Fri, 31 Mar 2000 13:08:06 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA22274 for rsvp-outgoing; Fri, 31 Mar 2000 07:59:18 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA22267 for ; Fri, 31 Mar 2000 07:59:15 -0800 (PST) Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16094 for ; Fri, 31 Mar 2000 07:59:30 -0800 (PST) Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 31 Mar 2000 11:09:06 -0500 Message-ID: <38E4CB2D.8E288E37@globespan.net> Date: Fri, 31 Mar 2000 10:58:37 -0500 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "psumit@rnd.cts-corp.com" CC: "'rsvp@ISI.EDU'" Subject: Re: query regarding rsvp References: <01BF9B46.24886DC0.psumit@rnd.cts-corp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Sumit, RSVP only provides mechanisms for signaling the resources required for a flow (and how to identify a flow). Typically, there would be another entity on the device reserving resources for these flows and when RSVP module receives request for a flow, it would notify this entity to reserve resources. Hope it helps. For more details on using RSVP to support Int-Serv QoS model, refer to RFC 2210. It has also been enhanced to support Diff-Serv model with MPLS (refer to draft-ietf-mpls-diff-ext-03.txt and draft-ietf-mpls-rsvp-lsp-tunnel-05.txt). Rohit sumit pandey wrote: > > i'm at present making a study on rsvp. > i wanted to know whether rsvp is just a signalling protocol or does it actually reserve bandwidth. > if so then how does the bandwidth reservation actually work > does it mean reserving the ports or providing higher priority to the packets -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From rsvp-owner@ISI.EDU Fri Mar 31 16:10: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 QAA18301 for ; Fri, 31 Mar 2000 16:10:33 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA29707 for rsvp-outgoing; Fri, 31 Mar 2000 11:19:46 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29701 for ; Fri, 31 Mar 2000 11:19:44 -0800 (PST) Received: from kid.isi.edu (root@kid.isi.edu [128.9.160.80]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA17414 for ; Fri, 31 Mar 2000 11:19:59 -0800 (PST) From: Steven Berson Received: from localhost (berson@localhost) by kid.isi.edu (8.9.3/8.9.3) with ESMTP id LAA07727; Fri, 31 Mar 2000 11:19:36 -0800 X-Authentication-Warning: kid.isi.edu: berson owned process doing -bs Date: Fri, 31 Mar 2000 11:19:36 -0800 (PST) To: sumit pandey cc: "'rsvp@ISI.EDU'" Subject: Re: query regarding rsvp In-Reply-To: <01BF9B46.24886DC0.psumit@rnd.cts-corp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk On Fri, 31 Mar 2000, sumit pandey wrote: > i'm at present making a study on rsvp. i wanted to know whether > rsvp is just a signalling protocol or does it actually reserve > bandwidth. if so then how does the bandwidth reservation actually > work does it mean reserving the ports or providing higher priority > to the packets RSVP is just a signalling protocol, and will work with various traffic control schemes (such as priority or bandwidth allocation). Steve From rsvp-owner@ISI.EDU Fri Mar 31 18:01:42 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 SAA19111 for ; Fri, 31 Mar 2000 18:01:41 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA03916 for rsvp-outgoing; Fri, 31 Mar 2000 13:13:03 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id NAA03911 for ; Fri, 31 Mar 2000 13:13:02 -0800 (PST) Received: from mainframe.dgrc.crc.ca (mainframe.dgrc.crc.ca [142.92.38.206]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14484 for ; Fri, 31 Mar 2000 13:13:16 -0800 (PST) Received: from crc.ca (curly [142.92.38.251]) by mainframe.dgrc.crc.ca (8.9.3/8.9.3) with ESMTP id QAA02386 for ; Fri, 31 Mar 2000 16:12:44 -0500 (EST) Message-ID: <38E514CD.74A41BDF@crc.ca> Date: Fri, 31 Mar 2000 16:12:45 -0500 From: Guilhem Tardy Organization: CRC X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: RSVP in a mobile environment (e.g. MANET): how to improve latencies? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I have been working on wireless networks for a while (more specifically Mobile-IP and MANET) and Qos management in those environments. As an exercice, I started to look at possible ways to improve latencies of re-reservation with RSVP when a host roams (i.e. when the topology changes), under the assumption that the physical and link layers would notify the RSVP process *beforehand*. This is feasible as the MAC constantly compares signals from various neighboring nodes and decides at a given threshold to effectively switch to a new correspondent, right? It might be a bit premature, but I would very much like to discuss with anyone of you the scheme found below. I introduced two new objects for the Path message, which shall be of the form ClassNum = 11bbbbbb. A slightly expanded version (with a short introduction and a couple of figures) can be found at http://gt89.dgrc.crc.ca/QoS/t.html I am only aware of another study called "MRSVP" by A. K. Talukdar, B. R. Badrinath and A. Acharya, which takes the point of view of reserving in advance at multiple potential neighbours, where I would prefer to act a little bit later, only when a node is sure to roam (hence a single new reservation). This is particularly important when bandwidth is very limited, roaming is unpredictable (e.g. many neighbours, all moving) and frequent. A typical case is a mobile ad-hoc network (MANET) or other nomad networks (e.g. Bluetooth). There might have been some other studies since then, and I would like to hear about it, too. Please send your replies directly to me, as well. Best regards, Guilhem Tardy. phone: (613) 993-8232 Network Systems and Technologies fax: (613) 998-9648 Communications Research Center email: Guilhem.Tardy@crc.ca 3701 Carling Ave. #28/2B web: http://www.crc.ca/ Ottawa (Ontario) K2H 8S2 Terminology: path state {SENDER_TEMPLATE, PHOP, SESSION, IFin, IFout} as defined by the Path messages, {NHOP} as defined by the Resv messages #{1..n} first common node between the current and forthcoming route [] forthcoming anchor #s{1..n} first common node towards the source between the current and forthcoming route #d{1..n} first common node towards the destination between the current and forthcoming route Note: * {1..n} is an optional index respective to several routes for multicast * parentheses as in "dest->#(->src)" mean that a packet would be merged at # and not forwarded * curly braces as in "{->[],->src}" mean that a packet could be forwarded to either of both The specific rules are as follows: [host mobility] [reservation, host=dest] a. Path(w/ obj) dest->[] pck.{srcaddr=src, destaddr=[]}, SESSION=dest 'obj' specifies the reservation made to this flow (i.e. style and corresponding descriptors) b. Resv []->#{->dest(->src),(->src)} pck.{srcaddr=dest, destaddr=phop} [] substitutes to dest for making the necessary reservations c. ( ResvTear dest->#(->src) ) optionally, dest tears down its current reservations before roaming (note: # should discard this message, because it doesn't match the new state, in particular for the outgoing interface) d. roaming e. Resv dest->[](->src) pck.{srcaddr=dest, destaddr=phop} If 'obj' indicates the need of confirmation, by the means of the current dest address specified in a RESV_CONFIRM (b.), this will trigger one or many Confirmation messages processed by dest (e.g. for tearing down corresponding reservations and deciding eventually on roaming), while possible ResvErr messages will be forwarded to []. [path, host=src] a. Path(w/ obj) src->[] pck.{srcaddr=src, destaddr=[]}, SESSION=[] 'obj' specifies the dest address of a session b. Path []->#(->dest) pck.{srcaddr=src, destaddr=dest}, SESSION=dest [] substitutes to src for sending the Path message c. Resv (dest->)#{->[],->src} pck.{srcaddr=dest, destaddr=phop} # immediately sends Resv refreshes upon reception of a Path with a new PHOP address d. ( PathTear src->#(->dest) ) optionally, dest tears down its current paths before roaming (note: # should discard this message, because it doesn't match the new state, in particular for the incoming interface) e. roaming f. Path src->[](->dest) pck.{srcaddr=src, destaddr=dest}, SESSION=dest [router mobility] [reservation & path] a. Path host->phop->#s->#d(->dest) pck.{srcaddr=src, destaddr=dest}, SESSION=dest phop looks for another route towards dest (the message sent to phop, despite routing default, cannot be forwarded out the same interface) b. Resv (dest->)#d->#s{->host(->src),(->src)} pck.{srcaddr=dest, destaddr=phop} #d immediately sends Resv refreshes upon reception of a Path with a new PHOP address c. ( ResvTear host->#s(->src) ) optionally, dest tears down its current reservations before roaming (note: #s should discard this message, because it doesn't match the new state, in particular for the outgoing interface) d. roaming From rsvp-owner@ISI.EDU Fri Mar 31 22:37:13 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 WAA23104 for ; Fri, 31 Mar 2000 22:37:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA13549 for rsvp-outgoing; Fri, 31 Mar 2000 17:43:39 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA13544 for ; Fri, 31 Mar 2000 17:43:38 -0800 (PST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA27629 for ; Fri, 31 Mar 2000 17:43:53 -0800 (PST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id UAA17757 for ; Fri, 31 Mar 2000 20:43:19 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id UAA25296 for ; Fri, 31 Mar 2000 20:43:23 -0500 (EST) Message-ID: <38E5542B.86951944@fore.com> Date: Fri, 31 Mar 2000 20:43:07 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: Question about integrity Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit What is the proper procedure for an RSVP router if an incoming message has an INTEGRITY object, but the router does not have INTEGRITY support implemented? I think it should go ahead and process the message anyway (akin to someone giving you a key to a room, and you find out that the room does not have a lock on the door.) Others here, however, have suggested that the message should be ignored. Possibly sending back an error message. The idea here being that the sender of the message is asking for a level of security that can not be provided. -- David