From rsvp-owner@ISI.EDU Sat Apr 1 01:08:50 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25729 for ; Sat, 1 Apr 2000 01:08:50 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA18192 for rsvp-outgoing; Fri, 31 Mar 2000 20:09:52 -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 UAA18187 for ; Fri, 31 Mar 2000 20:09:51 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA20028 for ; Fri, 31 Mar 2000 20:10:06 -0800 (PST) Received: from akyol.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA23371; Fri, 31 Mar 2000 20:10:02 -0800 (PST) Message-Id: <4.3.1.2.20000331200445.00beeef0@localhost> X-Sender: akyol@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 31 Mar 2000 20:10:00 -0800 To: "Simon Oosthoek (EMN)" , "'rsvp@isi.edu'" From: Bora Akyol Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk In a wireless environment, what kind of QoS are you planning on utilizing. Reserved bandwidth, or BER, or CIR type. Do you think that RSVP is a good match for a wireless environment when the channel varies rapidly? Do you think that RSVP will provide the necessary API so that you can use time-varying error-correcting codes based on BER? How are you planning on differentiation congestion loss from link layer corruption? I guess what I am trying to say is that I don't think RSVP meets the requirements for dynamic wireless channels, you may be much better of proxying RSVP requests via an agent architecture that sits at the two end of the wireless connection. Also you may want to bring this up in the PILC group. Bora At 05:55 PM 3/28/00 +0200, Simon Oosthoek (EMN) wrote: >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 rsvp-owner@ISI.EDU Sat Apr 1 17:43:17 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 RAA12139 for ; Sat, 1 Apr 2000 17:43:16 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA16830 for rsvp-outgoing; Sat, 1 Apr 2000 12:52: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 MAA16825 for ; Sat, 1 Apr 2000 12:52:34 -0800 (PST) Received: from medusa.mminternet.com (root@medusa.mminternet.com [207.175.72.15]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA05206 for ; Sat, 1 Apr 2000 12:52:49 -0800 (PST) Received: from aterzis (adsl-gte-la-216-86-192-44.mminternet.com [216.86.192.44]) by medusa.mminternet.com (8.9.3/8.9.3) with SMTP id MAA08017; Sat, 1 Apr 2000 12:51:53 -0800 From: "Andreas Terzis" To: "Guilhem Tardy" , Subject: RE: RSVP in a mobile environment (e.g. MANET): how to improve latencies? Date: Sat, 1 Apr 2000 12:53:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38E514CD.74A41BDF@crc.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by zephyr.isi.edu id MAA16826 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Guilhem, We had a paper in INFOCOM'99, which proposed using RSVP tunnels to either statically or dynamically allocate resources between base stations for mobile hosts moving between neighboring cells. The pointer to the paper is: http://www.cs.ucla.edu/~terzis/pubs/infocom99.ps.gz cheers, -andreas > -----Original Message----- > From: owner-rsvp@isi.edu [mailto:owner-rsvp@isi.edu]On Behalf Of Guilhem > Tardy > Sent: Friday, March 31, 2000 1:13 PM > To: rsvp@isi.edu > Subject: RSVP in a mobile environment (e.g. MANET): how to improve > latencies? > > > 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 Mon Apr 3 06:36: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 GAA15819 for ; Mon, 3 Apr 2000 06:36:00 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA15683 for rsvp-outgoing; Mon, 3 Apr 2000 01:14:34 -0700 (PDT) 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 BAA15677 for ; Mon, 3 Apr 2000 01:14:32 -0700 (PDT) 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 BAA28883 for ; Mon, 3 Apr 2000 01:14:44 -0700 (PDT) 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 KAA23605 for ; Mon, 3 Apr 2000 10:14:42 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 3 Apr 2000 10:13:48 +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) ; Mon, 03 Apr 2000 08:13:47 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Mon, 3 Apr 2000 10:14:34 +0200 Message-ID: From: "Simon Oosthoek (EMN)" To: "'Bora Akyol'" , "'rsvp@isi.edu'" Cc: "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" Subject: RE: RSVP on wireless IP Date: Mon, 3 Apr 2000 10:09:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 Apr 2000 08:13:48.0125 (UTC) FILETIME=[899518D0:01BF9D44] Sender: owner-rsvp@ISI.EDU Precedence: bulk > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: 01 April 2000 06:10 > To: Simon Oosthoek (EMN); 'rsvp@isi.edu' > Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) > > > In a wireless environment, what kind of QoS are you planning > on utilizing. > Reserved bandwidth, or BER, or CIR type. I haven't looked at the details for QoS over wireless IP yet, so I can't answer this. > Do you think that RSVP is a good match for a wireless > environment when the > channel varies rapidly? It rather depends on the technology used for the wireless access method. I do believe the MAC layer should provide some handles for QoS aware operation. > Do you think that RSVP will provide the necessary API so that > you can use > time-varying error-correcting codes based on BER? Is that something that should be taken care of in RSVP? > How are you planning on differentiation congestion loss from > link layer > corruption? Good question ;-) I think MAC layer awareness of QoS should be able to help here. Or just knowing about MAC layer packetloss... > I guess what I am trying to say is that I don't think RSVP meets the > requirements for dynamic wireless channels, you may be much better of > proxying RSVP requests via an agent architecture > that sits at the two end of the wireless connection. But that would mean that you have at least one hop without QoS support in the RSVP connection. That could break the entire QoS for that flow. The least you can do is try to support QoS awareness in the wireless link, if it then fails for any reason, then you call it static ;-) > Also you may want to bring this up in the PILC group. I think I know too little of this to make a useful contribution yet, but I'll keep it in mind. Thanks for your comments, I'm looking forward to more discussions on this subject, especially when I know more.... Cheers Simon From rsvp-owner@ISI.EDU Mon Apr 3 13:33: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 NAA20418 for ; Mon, 3 Apr 2000 13:33:09 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA28592 for rsvp-outgoing; Mon, 3 Apr 2000 08:16:37 -0700 (PDT) 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 IAA28587 for ; Mon, 3 Apr 2000 08:16:36 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA02206 for ; Mon, 3 Apr 2000 08:16:52 -0700 (PDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Apr 2000 08:07:49 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2FLCMLFB>; Mon, 3 Apr 2000 08:07:49 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F4195@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: "Simon Oosthoek (EMN)" , "'Bora Akyol'" , "'rsvp@isi.edu'" , issll@lmcs.mit.edu Cc: "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" Subject: RE: RSVP on wireless IP Date: Mon, 3 Apr 2000 08:07:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk I tend to view > -----Original Message----- > From: Simon Oosthoek (EMN) [mailto:Simon.Oosthoek@emn.ericsson.se] > Sent: Monday, April 03, 2000 1:10 AM > To: 'Bora Akyol'; 'rsvp@isi.edu' > Cc: Geert Heijenk (EMN); Georgios Karagiannis (EMN) > Subject: RE: RSVP on wireless IP > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: 01 April 2000 06:10 > > To: Simon Oosthoek (EMN); 'rsvp@isi.edu' > > Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) > > > > > > In a wireless environment, what kind of QoS are you planning > > on utilizing. > > Reserved bandwidth, or BER, or CIR type. > > I haven't looked at the details for QoS over wireless IP yet, > so I can't answer this. > > > Do you think that RSVP is a good match for a wireless > > environment when the > > channel varies rapidly? > > It rather depends on the technology used for the wireless > access method. I do believe the MAC layer should provide some > handles for QoS aware operation. > > > Do you think that RSVP will provide the necessary API so that > > you can use > > time-varying error-correcting codes based on BER? > > Is that something that should be taken care of in RSVP? > > > How are you planning on differentiation congestion loss from > > link layer > > corruption? > > Good question ;-) I think MAC layer awareness of QoS should > be able to help here. Or just knowing about MAC layer packetloss... > > > I guess what I am trying to say is that I don't think RSVP > meets the > > requirements for dynamic wireless channels, you may be much > better of > > proxying RSVP requests via an agent architecture > > that sits at the two end of the wireless connection. > > But that would mean that you have at least one hop without > QoS support in the RSVP connection. That could break the > entire QoS for that flow. The least you can do is try to > support QoS awareness in the wireless link, if it then fails > for any reason, then you call it static ;-) > > > Also you may want to bring this up in the PILC group. > > I think I know too little of this to make a useful > contribution yet, but I'll keep it in mind. > > Thanks for your comments, I'm looking forward to more > discussions on this subject, especially when I know more.... > > Cheers > > Simon > From rsvp-owner@ISI.EDU Mon Apr 3 13:41: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 NAA20499 for ; Mon, 3 Apr 2000 13:41:49 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA28928 for rsvp-outgoing; Mon, 3 Apr 2000 08:26:30 -0700 (PDT) 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 IAA28923 for ; Mon, 3 Apr 2000 08:26:29 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id IAA02520 for ; Mon, 3 Apr 2000 08:26:45 -0700 (PDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Apr 2000 08:15:15 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2FLCMLMD>; Mon, 3 Apr 2000 08:15:15 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F419A@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: "Simon Oosthoek (EMN)" , "'Bora Akyol'" , "'rsvp@isi.edu'" , issll@lmcs.mit.edu Cc: "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" Subject: RE: RSVP on wireless IP Date: Mon, 3 Apr 2000 08:15:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk I tend to view wireless as just another link layer over which QoS is necessary. RSVP is a signaling protocol that is used to request QoS on an end-to-end basis. It is intentionally, sufficiently abstract to support concatenated subnetworks of varying media. The ISSLL working group has defined mappings from RSVP (when it carries Intserv parameters) to various 'link layers' including 802, atm, slow wan, and most recently, diffserv. The current model as I see it, is that an RSVP request is generated by an end system, including a layer-3 abstraction of the QoS it needs. This request propagates along the traffic path, from sender to receiver (and the response in return). At various points, admission control 'agents' are responsible for reviewing the request and comparing it against the resources aailable in the part of the network for which they are responsible. This requires these agents to be able to map the abstract intserv parameters into the parameters appropriate for their specific media, and possibly to generate some link layer specific signaling. RSVP serves to unify the disparate QoS mechanisms of the different media. I think that wireless should be part of the same general model. I expect that the wireless 'base station' (or alternate admission conrtrol agent) would participate in the end-to-end RSVP signaling and would be able to map RSVP requests to its local QoS mechanisms. The SBM, defined by the ISSLL WG might be a good model for such participation. Regards, Yoram > -----Original Message----- > From: Simon Oosthoek (EMN) [mailto:Simon.Oosthoek@emn.ericsson.se] > Sent: Monday, April 03, 2000 1:10 AM > To: 'Bora Akyol'; 'rsvp@isi.edu' > Cc: Geert Heijenk (EMN); Georgios Karagiannis (EMN) > Subject: RE: RSVP on wireless IP > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: 01 April 2000 06:10 > > To: Simon Oosthoek (EMN); 'rsvp@isi.edu' > > Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) > > > > > > In a wireless environment, what kind of QoS are you planning > > on utilizing. > > Reserved bandwidth, or BER, or CIR type. > > I haven't looked at the details for QoS over wireless IP yet, > so I can't answer this. > > > Do you think that RSVP is a good match for a wireless > > environment when the > > channel varies rapidly? > > It rather depends on the technology used for the wireless > access method. I do believe the MAC layer should provide some > handles for QoS aware operation. > > > Do you think that RSVP will provide the necessary API so that > > you can use > > time-varying error-correcting codes based on BER? > > Is that something that should be taken care of in RSVP? > > > How are you planning on differentiation congestion loss from > > link layer > > corruption? > > Good question ;-) I think MAC layer awareness of QoS should > be able to help here. Or just knowing about MAC layer packetloss... > > > I guess what I am trying to say is that I don't think RSVP > meets the > > requirements for dynamic wireless channels, you may be much > better of > > proxying RSVP requests via an agent architecture > > that sits at the two end of the wireless connection. > > But that would mean that you have at least one hop without > QoS support in the RSVP connection. That could break the > entire QoS for that flow. The least you can do is try to > support QoS awareness in the wireless link, if it then fails > for any reason, then you call it static ;-) > > > Also you may want to bring this up in the PILC group. > > I think I know too little of this to make a useful > contribution yet, but I'll keep it in mind. > > Thanks for your comments, I'm looking forward to more > discussions on this subject, especially when I know more.... > > Cheers > > Simon > From rsvp-owner@ISI.EDU Mon Apr 3 14:04: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 OAA20823 for ; Mon, 3 Apr 2000 14:04:46 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA29671 for rsvp-outgoing; Mon, 3 Apr 2000 08:43:43 -0700 (PDT) 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 IAA29666 for ; Mon, 3 Apr 2000 08:43:41 -0700 (PDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA04437 for ; Mon, 3 Apr 2000 08:43:39 -0700 (PDT) Received: from vega.upv.es (vega.cc.upv.es [158.42.4.1]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id RAA01532; Mon, 3 Apr 2000 17:43:02 +0200 Received: from dcom.upv.es (nt2.dcom.upv.es [158.42.32.45]) by vega.upv.es (8.8.4/8.8.5) with ESMTP id RAA05085; Mon, 3 Apr 2000 17:42:53 +0200 (METDST) Message-ID: <38E8BEB6.6818E54@dcom.upv.es> Date: Mon, 03 Apr 2000 17:54:31 +0200 From: ana X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Guilhem Tardy CC: rsvp@ISI.EDU Subject: Re: RSVP in a mobile environment (e.g. MANET): how to improve latencies? References: <38E514CD.74A41BDF@crc.ca> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Hi Guilhem, we had also a paper in the First Workshop on IP Quality of Service for Wireless and Mobile Networks (IQWiM´99). We propose to use Mobile IP and Resource Reservations in Advance (using RSVP) for guaranteeing QoS in mobile environments. You can find a reference to this paper at: http://www.darmstadt.gmd.de/mobile/publications/abstracts/PajaresBerierWolfSteinmetz1999a.html Best wishes, -ana Guilhem Tardy wrote: > 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 Mon Apr 3 14:17: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 OAA21015 for ; Mon, 3 Apr 2000 14:17:44 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA00514 for rsvp-outgoing; Mon, 3 Apr 2000 09:00:47 -0700 (PDT) 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 JAA00509 for ; Mon, 3 Apr 2000 09:00:46 -0700 (PDT) Received: from bmailnj.iphighway.com ([63.89.157.130]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06041 for ; Mon, 3 Apr 2000 09:01:01 -0700 (PDT) Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id <2DK7NBP3>; Mon, 3 Apr 2000 11:57:16 -0400 Message-ID: <6399122981E1D211AB490090271E0AA34C538A@BMAILNJ> From: Andrew Rawson - NJ To: Andrew Rawson - NJ Subject: Quality of Service & Policy-based Networking White Papers from IPHighway Date: Mon, 3 Apr 2000 11:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9D85.45088C24" 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_01BF9D85.45088C24 Content-Type: text/plain; charset="iso-8859-1" As voice, video, and data continue to converge, policy-based networking allows administrators to easily manage network traffic - dynamically prioritizing the delivery of time-critical and bandwidth-intensive traffic. IPHighway has just released a new series of white papers that highlight the promise of policy-based network management, and how it can improve Quality of Service (QoS) to better support next-generation, business-critical applications. The series includes 4 targeted documents, they offer a comprehensive overview of policy-based networking and its possibilities: * #1 - Introduction to Policy Based Networking & QoS (509KB) * #2 - Policy Standards & IETF Terminology (484KB) * #3 - Policy-based Networking Products, Design & Architecture (535KB) * #4 - IPHighway Target Markets & Case Studies (1,159KB) To receive any or all of these papers, simply respond to this message and indicate which one(s) you would like to receive. You may also visit our web site at http://www.iphighway.com/whitepapers.html and request them online. All requests will be fulfilled via email. Thanks, Andrew _____ If you do not want to receive any further email messages from IPHighway, simply reply with the subject REMOVE in the header. _____ Andrew Rawson Vice President Marketing & Business Development IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone 201-934-4265 Fax 201-934-4439 Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As voice, video, and data continue to converge, = policy-based=20 networking allows administrators to easily manage network traffic - = dynamically=20 prioritizing the delivery of time-critical and bandwidth-intensive=20 traffic.

IPHighway has just released a new series of white = papers that=20 highlight the promise of policy-based network management, and how it = can improve=20 Quality of Service (QoS) to better support next-generation, = business-critical=20 applications.

The series includes 4 targeted documents, they = offer a=20 comprehensive overview of policy-based networking and its=20 possibilities:
  • #1 - Introduction to Policy Based Networking & = = QoS           &nb= sp;        =20 (509KB)
  • #2 - Policy Standards & IETF=20 = Terminology          &= nbsp;           &= nbsp;           &= nbsp;     =20 (484KB)
  • #3 - Policy-based Networking Products, Design = &=20 Architecture     (535KB)
  • #4 - IPHighway Target Markets & Case=20 = Studies           = ;            = ;      =20 (1,159KB)
To receive any or all of these papers, simply = respond to this=20 message and indicate which one(s) you would like to receive. =
You may also visit our web site at http://www.iphighway.= com/whitepapers.html and=20 request them online.
All requests will be fulfilled via = email.
 
Thanks,
Andrew
 
If you do not want to receive any further email = messages from=20 IPHighway, simply reply with the subject REMOVE in the = header.
 
Andrew Rawson
Vice President
Marketing & Business Development
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone 201-934-4265 Fax 201-934-4439
Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24-- From rsvp-owner@ISI.EDU Mon Apr 3 15:02:12 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 PAA22234 for ; Mon, 3 Apr 2000 15:02:11 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA03142 for rsvp-outgoing; Mon, 3 Apr 2000 10:06:30 -0700 (PDT) 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 KAA03137 for ; Mon, 3 Apr 2000 10:06:29 -0700 (PDT) Received: from pup.isi.edu (pup.isi.edu [128.9.160.228]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA27071; Mon, 3 Apr 2000 10:06:43 -0700 (PDT) Message-Id: <200004031706.KAA27071@boreas.isi.edu> To: David Charlap cc: rsvp@ISI.EDU Reply-To: lindell@ISI.EDU Subject: Re: Question about integrity In-Reply-To: Message from David Charlap of "Fri, 31 Mar 2000 20:43:07 EST." <38E5542B.86951944@fore.com> Date: Mon, 03 Apr 2000 10:06:43 -0700 From: Bob Lindell Sender: owner-rsvp@ISI.EDU Precedence: bulk > 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. I also think it should go ahead and process the message. If the sender was really concerned about security, it would make sure the next hop supported integrity. There are 2 basic cases I can think of at the moment. 1) A sender would require that the replay protection handshake complete successfully. By definition the next hop supports integrity. 2) A sender does not handshake over a point to point link that is assumed to be secure from replay attacks. It is likely in this case that the sender has apriori knowledge that the peer supports integrity as part of a peering agreement. Bob Lindell From rsvp-owner@ISI.EDU Mon Apr 3 16:59: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 QAA24686 for ; Mon, 3 Apr 2000 16:59:18 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA08799 for rsvp-outgoing; Mon, 3 Apr 2000 12:15:30 -0700 (PDT) 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 MAA08794 for ; Mon, 3 Apr 2000 12:15:23 -0700 (PDT) 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 MAA29072 for ; Mon, 3 Apr 2000 12:15:24 -0700 (PDT) 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 VAA17044 for ; Mon, 3 Apr 2000 21:15:13 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 3 Apr 2000 21:14:11 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 03 Apr 2000 19:14:11 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <2GWTHR76>; Mon, 3 Apr 2000 21:15:00 +0200 Message-ID: From: "Georgios Karagiannis (EMN)" To: "'Yoram Bernet'" Cc: "Simon Oosthoek (EMN)" , "'Bora Akyol'" , "'rsvp@isi.edu'" , issll@lmcs.mit.edu, "Geert Heijenk (EMN)" Subject: RE: RSVP on wireless IP Date: Mon, 3 Apr 2000 18:10:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 03 Apr 2000 19:14:11.0390 (UTC) FILETIME=[CAE385E0:01BF9DA0] Sender: owner-rsvp@ISI.EDU Precedence: bulk Dear all In principle, I agree with Yoram's opinion regarding the fact that RSVP serves to unify the disparate QoS mechanisms of the different media, including wireless subnetworks. However, we have not seen any activity of the ISSLL group in the area of QoS mappings from RSVP to wireless subnetworks. Perhaps it will be a good idea to enlarge the charter goals of the ISSLL group in order to include issues that are relevant to RSVP and wireless networks, e.g., cellular networks. Best Regards, Georgios From rsvp-owner@ISI.EDU Tue Apr 4 15:09: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 PAA12869 for ; Tue, 4 Apr 2000 15:09:50 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA24322 for rsvp-outgoing; Tue, 4 Apr 2000 10:04:26 -0700 (PDT) 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 KAA24317 for ; Tue, 4 Apr 2000 10:04:25 -0700 (PDT) Received: from bmailnj.iphighway.com ([63.89.157.130]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21958 for ; Tue, 4 Apr 2000 10:04:41 -0700 (PDT) Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id <2DK7NBP3>; Mon, 3 Apr 2000 11:57:16 -0400 Message-ID: <6399122981E1D211AB490090271E0AA34C538A@BMAILNJ> From: Andrew Rawson - NJ To: Andrew Rawson - NJ Subject: Quality of Service & Policy-based Networking White Papers from IPHighway Date: Mon, 3 Apr 2000 11:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9D85.45088C24" 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_01BF9D85.45088C24 Content-Type: text/plain; charset="iso-8859-1" As voice, video, and data continue to converge, policy-based networking allows administrators to easily manage network traffic - dynamically prioritizing the delivery of time-critical and bandwidth-intensive traffic. IPHighway has just released a new series of white papers that highlight the promise of policy-based network management, and how it can improve Quality of Service (QoS) to better support next-generation, business-critical applications. The series includes 4 targeted documents, they offer a comprehensive overview of policy-based networking and its possibilities: * #1 - Introduction to Policy Based Networking & QoS (509KB) * #2 - Policy Standards & IETF Terminology (484KB) * #3 - Policy-based Networking Products, Design & Architecture (535KB) * #4 - IPHighway Target Markets & Case Studies (1,159KB) To receive any or all of these papers, simply respond to this message and indicate which one(s) you would like to receive. You may also visit our web site at http://www.iphighway.com/whitepapers.html and request them online. All requests will be fulfilled via email. Thanks, Andrew _____ If you do not want to receive any further email messages from IPHighway, simply reply with the subject REMOVE in the header. _____ Andrew Rawson Vice President Marketing & Business Development IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone 201-934-4265 Fax 201-934-4439 Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As voice, video, and data continue to converge, = policy-based=20 networking allows administrators to easily manage network traffic - = dynamically=20 prioritizing the delivery of time-critical and bandwidth-intensive=20 traffic.

IPHighway has just released a new series of white = papers that=20 highlight the promise of policy-based network management, and how it = can improve=20 Quality of Service (QoS) to better support next-generation, = business-critical=20 applications.

The series includes 4 targeted documents, they = offer a=20 comprehensive overview of policy-based networking and its=20 possibilities:
  • #1 - Introduction to Policy Based Networking & = = QoS           &nb= sp;        =20 (509KB)
  • #2 - Policy Standards & IETF=20 = Terminology          &= nbsp;           &= nbsp;           &= nbsp;     =20 (484KB)
  • #3 - Policy-based Networking Products, Design = &=20 Architecture     (535KB)
  • #4 - IPHighway Target Markets & Case=20 = Studies           = ;            = ;      =20 (1,159KB)
To receive any or all of these papers, simply = respond to this=20 message and indicate which one(s) you would like to receive. =
You may also visit our web site at http://www.iphighway.= com/whitepapers.html and=20 request them online.
All requests will be fulfilled via = email.
 
Thanks,
Andrew
 
If you do not want to receive any further email = messages from=20 IPHighway, simply reply with the subject REMOVE in the = header.
 
Andrew Rawson
Vice President
Marketing & Business Development
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone 201-934-4265 Fax 201-934-4439
Andrew@IPHighway.com ------_=_NextPart_001_01BF9D85.45088C24-- From rsvp-owner@ISI.EDU Tue Apr 4 16:17: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 QAA14936 for ; Tue, 4 Apr 2000 16:17:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA26880 for rsvp-outgoing; Tue, 4 Apr 2000 11:11:17 -0700 (PDT) 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 LAA26875 for ; Tue, 4 Apr 2000 11:11:14 -0700 (PDT) Received: from imo24.mx.aol.com (imo24.mx.aol.com [152.163.225.68]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28919 for ; Tue, 4 Apr 2000 11:11:30 -0700 (PDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo24.mx.aol.com (mail_out_v25.3.) id l.c0.264e119 (4329); Tue, 4 Apr 2000 14:10:08 -0400 (EDT) Message-ID: Date: Tue, 4 Apr 2000 14:10:08 EDT Subject: QOS, RSVP, Differential Services, Integrated Services and IPv6 To: diffserv@ietf.org (DIFFSERV WG), rsvp@ISI.EDU ('rsvp@isi.edu'), issll@lmcs.mit.edu CC: martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I have been thinking about guaranteeing latencies in packet delivery. If a WAN network provides transport for very large packets, and if a reservation is made for video traffic that requires a very low latency at high priority, would it not make sense for intermediate routers to fragment very large packets so that if a priority low latency packet arrived at an intermediate router while that router is transmitting a lower priority packet, the wait before the high priority low latency packet actually begins to transmit would be low because as soon as the reservation had been made, the router limited the transmit MTU size on the relevant interfaces to decrease possible delays through an intermediate router? Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com From rsvp-owner@ISI.EDU Tue Apr 4 16:26: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 QAA14935 for ; Tue, 4 Apr 2000 16:17:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA27472 for rsvp-outgoing; Tue, 4 Apr 2000 11:24:42 -0700 (PDT) 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 LAA27467 for ; Tue, 4 Apr 2000 11:24:41 -0700 (PDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01179 for ; Tue, 4 Apr 2000 11:24:57 -0700 (PDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA15232; Tue, 4 Apr 2000 11:23:53 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2JHG36BM>; Tue, 4 Apr 2000 11:23:54 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40488@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Telford001@aol.com'" , diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu Cc: martillo@telfordtools.com Subject: RE: [Diffserv] QOS, RSVP, Differential Services, Integrated Servi ces and IPv6 Date: Tue, 4 Apr 2000 11:21:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk It all depends on the link speed. I don't think that this kind of delay in the core is a problem, because the core links are of high speed. For example the delay for a video/audio packet to wait behind an MTU=1500 byte packet in a OC-192 link (~10 Gbit/sec) is close to 1 micro-second. On the other hand if the link speed is in the order of 1 Mbit/sec, then the delay would be almost 10 msec which is significant. But I don't expect a WAN core router to have 1 Mbit/sec link. -Shahram >-----Original Message----- >From: Telford001@aol.com [mailto:Telford001@aol.com] >Sent: Tuesday, April 04, 2000 2:10 PM >To: diffserv@ietf.org; rsvp@isi.edu; issll@lmcs.mit.edu >Cc: martillo@telfordtools.com >Subject: [Diffserv] QOS, RSVP, Differential Services, Integrated >Services and IPv6 > > >I have been thinking about guaranteeing latencies in packet delivery. >If a WAN network provides transport for very large packets, and if a >reservation is made for video traffic that requires a very low latency >at high priority, would it not make sense for intermediate routers to >fragment very large packets so that if a priority low latency packet >arrived at an intermediate router while that router is transmitting >a lower priority packet, the wait before the high priority low latency >packet actually begins to transmit would be low because as soon >as the reservation had been made, the router limited the transmit >MTU size on the relevant interfaces to decrease possible delays >through an intermediate router? > >Joachim Martillo >President >Telford Tools, Inc. >17 Pleasant Hill Ave. >Boston, MA 02126-2813 >V 617-298-4107, 298-1617 >F 617-298-1745 >E martillo@telfordtools.com >U http://www.telfordtools.com > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > From rsvp-owner@ISI.EDU Tue Apr 4 16:39:21 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15639 for ; Tue, 4 Apr 2000 16:39:20 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA28743 for rsvp-outgoing; Tue, 4 Apr 2000 11:52:06 -0700 (PDT) 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 LAA28738 for ; Tue, 4 Apr 2000 11:52:02 -0700 (PDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05924 for ; Tue, 4 Apr 2000 11:52:17 -0700 (PDT) Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id UAA00256; Tue, 4 Apr 2000 20:52:09 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id UAA00650; Tue, 4 Apr 2000 20:52:08 +0200 (MET DST) Date: Tue, 4 Apr 2000 20:52:08 +0200 (MET DST) Message-Id: <200004041852.UAA00650@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Telford001@aol.com Cc: diffserv@ietf.org (DIFFSERV WG), rsvp@ISI.EDU ('rsvp@isi.edu'), issll@lmcs.mit.edu, martillo@telfordtools.com Subject: Re: QOS, RSVP, Differential Services, Integrated Services and IPv6 In-Reply-To: References: Sender: owner-rsvp@ISI.EDU Precedence: bulk Telford001@aol.com writes: > [...] would it not make sense for intermediate routers to > fragment very large packets so that if a priority low latency packet > arrived at an intermediate router while that router is transmitting > a lower priority packet, [...] Yes, kind of. RFC 2686-2689, products of the ISSLL WG. Good night. Gruesse, Carsten From rsvp-owner@ISI.EDU Tue Apr 4 18:03:24 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18135 for ; Tue, 4 Apr 2000 18:03:23 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA02048 for rsvp-outgoing; Tue, 4 Apr 2000 13:04:58 -0700 (PDT) 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 NAA02043 for ; Tue, 4 Apr 2000 13:04:56 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA13479 for ; Tue, 4 Apr 2000 13:05:11 -0700 (PDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA26528; Tue, 4 Apr 2000 16:04:54 -0400 (EDT) Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id QAA28812; Tue, 4 Apr 2000 16:04:26 -0400 (EDT) Received: from luna.mitre.org (luna.mitre.org [128.29.31.17]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id QAA27900; Tue, 4 Apr 2000 16:04:51 -0400 (EDT) Received: from mitre.org (m14961-pc.mitre.org [128.29.105.115]) by luna.mitre.org (8.7.2/8.7.2) with ESMTP id QAA13188; Tue, 4 Apr 2000 16:04:43 -0400 (EDT) Message-ID: <38EA4A6A.6EB3D87B@mitre.org> Date: Tue, 04 Apr 2000 16:02:50 -0400 From: Duncan Thomson Reply-To: duncant@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Simon Oosthoek (EMN)" CC: "'Bora Akyol'" , "'rsvp@isi.edu'" , "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" , "Schult,Nancy L." Subject: Re: RSVP on wireless IP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit The questions raised in this message are ones that we have been tackling here at MITRE in an ongoing research project. I'm a bit hesitant to jump into the fray here, because we haven't published anything on our work yet. But we're currently preparing some papers for submission, and we're far enough along that I thing we have some valuable experience we can contribute to the discussion. So here goes... One question being discussed was suitability of RSVP for wireless environment > > From: Bora Akyol [mailto:akyol@pluris.com] > > > > Do you think that RSVP is a good match for a wireless > > environment when the channel varies rapidly? I would extend this question as follows: "Is a resource reservation-based approach to QoS applicable to a dynamic environment?" In other words, if resources (in particular link bandwidths) are constantly changing, how can you make a reasonable admission control decision that will remain valid for the duration of a flow? We think the answer to this question is to build on the concept of reservation ranges proposed by Songwu Lu and Vadavur Bharghavan in a SICCOMM '96 paper. Reservation requests specify a range of bandwidths that the application can operate in, and the network provides a reservation somewhere in this range, which can be adjusted as network conditions vary. Our approach uses the concept of reservation ranges as follows. First, the application signals to the network the range of bandwidth that it is capable of operating in. The network then reserves resources somewhere in this range, and signals to the application the end-to-end allocation. The application then adapts its behaviour to conform to this allocation, which may change during the course of the connection. Obviously, this is not exactly RSVP. However, RSVP could be extended to implement the concept, and here at MITRE we have done exactly that. We now have a working implementation we call "Dynamic RSVP" (dRSVP), with an extended API we call "Dynamic SCRAPI" (dSCRAPI), together with adaptive versions of streaming video and audio applications (modified versions of vic and vat). We can demonstrate adaptive QoS in an environment where link characteristics change during the course of a connection. Note that I'm not proposing that the RSVP standard needs to be extended or modified at this point in time. I'm saying that RSVP as it currently stands does not include the concept of reservation ranges, that this concept is valuable in dealing with network dynamics, and that RSVP could be extended to include this concept. Whether, and and what point in time, we would want to think of tinkering with the RSVP standard to handle this is a separate question that I think would be premature to discuss at this point. Another issue being discussed was the necessary interaction between RSVP and lower layers: "Simon Oosthoek (EMN)" wrote: > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > > > How are you planning on differentiation congestion loss from > > link layer corruption? > > Good question ;-) I think MAC layer awareness of QoS should be able to > help here. Or just knowing about MAC layer packetloss... Distinguishing congestion loss from link layer corruption is difficult. We struggled with this one, and came to the conclusion that it is important to have explicit signaling between the MAC and RSVP so that RSVP knows what the current link bandwidth is. Note that ISI's RSVP daemon reads link bandwidths from a configuration file on startup - it has no way of knowing when link conditions change. I suspect that other implementations are similar. This is a big problem in a dynamic environment. So I agree fully with Simon that MAC layer awareness of QoS requirements is important, together with appropriate communication between the MAC layer and RSVP. You might want to take a look at the work that was done in the DARPA GloMo project to define router/radio APIs. In addition, I think it's important to deal with errors within the link layer, so that the network layer sees only a varying effective link bandwidth. This relates to another point that Simon and Bora were discussing: Bora: > > Do you think that RSVP will provide the necessary API so that > > you can use time-varying error-correcting codes based on BER? > Simon: > Is that something that should be taken care of in RSVP? I think the answer that the MAC layer should include mechanisms (perhaps things like adaptive error-correcting codes, but other adaptive mechanisms are possible) so that the network layer QoS mechanism can have a simplified model in which error conditions stay "good," while effective throughput (and possibly other characteristics such as delay) are signalled from the MAC layer via an appropriate API. This is the approach we have taken in our dRSVP implementation. Duncan Thomson From rsvp-owner@ISI.EDU Tue Apr 4 23:15: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 XAA23683 for ; Tue, 4 Apr 2000 23:15:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id SAA18227 for rsvp-outgoing; Tue, 4 Apr 2000 18:09:59 -0700 (PDT) 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 SAA18222 for ; Tue, 4 Apr 2000 18:09:57 -0700 (PDT) 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 SAA18435 for ; Tue, 4 Apr 2000 18:10:14 -0700 (PDT) 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 VAA29492 for ; Tue, 4 Apr 2000 21:09:40 -0400 (EDT) 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 VAA11977 for ; Tue, 4 Apr 2000 21:09:43 -0400 (EDT) Message-ID: <38EA9258.B89E8974@fore.com> Date: Tue, 04 Apr 2000 21:09:44 -0400 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: Another question: unnecessary objects Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit How should unnecessary objects be handled? For instance, if a STYLE object is included in a Path message. Or if a SCOPE object is included in a non-WF style Resv message. I can think of two possibilities, either of which might be appropriate: - Treat it as an unknown object class. For most objects, this will mean rejecting the message, since most objects have class numbers of the form 0bbbbbbb. - Ignore the object - process the message as if it didn't exist. -- David From rsvp-owner@ISI.EDU Wed Apr 5 05:58:21 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07786 for ; Wed, 5 Apr 2000 05:58:20 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA29056 for rsvp-outgoing; Tue, 4 Apr 2000 23:32:48 -0700 (PDT) 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 XAA29050 for ; Tue, 4 Apr 2000 23:32:46 -0700 (PDT) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA02079 for ; Tue, 4 Apr 2000 23:33:01 -0700 (PDT) Received: from spri.levels.unisa.edu.au (maria@kruschev [172.17.0.97]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id QAA18356; Wed, 5 Apr 2000 16:02:27 +0930 (CST) Message-ID: <38EADFC6.1FE2B862@spri.levels.unisa.edu.au> Date: Wed, 05 Apr 2000 16:10:06 +0930 From: Maria Elena Villapol X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) MIME-Version: 1.0 To: duncant@mitre.org CC: "Simon Oosthoek (EMN)" , "'Bora Akyol'" , "'rsvp@isi.edu'" , "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" , "Schult,Nancy L." Subject: Re: RSVP on wireless IP References: <38EA4A6A.6EB3D87B@mitre.org> Content-Type: multipart/alternative; boundary="------------9E54C311A9536E568EBEC9E8" Sender: owner-rsvp@ISI.EDU Precedence: bulk --------------9E54C311A9536E568EBEC9E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > I would extend this question as follows: "Is a resource reservation-based > approach to QoS applicable to a dynamic environment?" In other words, if > resources (in particular link bandwidths) are constantly changing, how can you > make a reasonable admission control decision that will remain valid for the > duration of a flow? > I agree > Another issue being discussed was the necessary interaction between RSVP and > lower layers: > > "Simon Oosthoek (EMN)" wrote: > > > > > -----Original Message----- > > > From: Bora Akyol [mailto:akyol@pluris.com] > > > > > > How are you planning on differentiation congestion loss from > > > link layer corruption? > > > > Good question ;-) I think MAC layer awareness of QoS should be able to > > help here. Or just knowing about MAC layer packetloss... > > Distinguishing congestion loss from link layer corruption is difficult. We > struggled with this one, and came to the conclusion that it is important to have > explicit signaling between the MAC and RSVP so that RSVP knows what the current > link bandwidth is. Note that ISI's RSVP daemon reads link bandwidths from a > configuration file on startup - it has no way of knowing when link conditions > change. I suspect that other implementations are similar. This is a big > problem in a dynamic environment. > > So I agree fully with Simon that MAC layer awareness of QoS requirements is > important, together with appropriate communication between the MAC layer and > RSVP. You might want to take a look at the work that was done in the DARPA > GloMo project to define router/radio APIs. > > In addition, I think it's important to deal with errors within the link layer, > so that the network layer sees only a varying effective link bandwidth. This > relates to another point that Simon and Bora were discussing: > I got confused. Why should RSVP distinguish between congestion loss and link layer disruption?. RSVP is just a signaling protocol. I think that it is responsibility of other components of the IntServ architecture such as traffic control (eg packet scheduler and admission control). I don't know if when you say RSVP you refer to RSVP and traffic control components ?. Maria -- Maria Elena Villapol PhD Student Institute for Telecommunications Research University of South Australia email: maria@spri.levels.unisa.edu.au VILME001@Students.UniSA.Edu.Au Web Page: http://www.itr.unisa.edu.au/~maria/index.htm --------------9E54C311A9536E568EBEC9E8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 

I would extend this question as follows: "Is a resource reservation-based
approach to QoS applicable to a dynamic environment?"  In other words, if
resources (in particular link bandwidths) are constantly changing, how can you
make a reasonable admission control decision that will remain valid for the
duration of a flow?
 

I agree
Another issue being discussed was the necessary interaction between RSVP and
lower layers:

"Simon Oosthoek (EMN)" wrote:
>
> > -----Original Message-----
> > From: Bora Akyol [mailto:akyol@pluris.com]
> >
> > How are you planning on differentiation congestion loss from
> > link layer corruption?
>
> Good question ;-) I think MAC layer awareness of QoS should be able to
> help here. Or just knowing about MAC layer packetloss...

Distinguishing congestion loss from link layer corruption is difficult.  We
struggled with this one, and came to the conclusion that it is important to have
explicit signaling between the MAC and RSVP so that RSVP knows what the current
link bandwidth is.  Note that ISI's RSVP daemon reads link bandwidths from a
configuration file on startup - it has no way of knowing when link conditions
change.  I suspect that other implementations are similar.  This is a big
problem in a dynamic environment.

So I agree fully with Simon that MAC layer awareness of QoS requirements is
important, together with appropriate communication between the MAC layer and
RSVP.  You might want to take a look at the work that was done in the DARPA
GloMo project to define router/radio APIs.

In addition, I think it's important to deal with errors within the link layer,
so that the network layer sees only a varying effective link bandwidth.  This
relates to another point that Simon and Bora were discussing:
 

I got confused. Why should RSVP distinguish between congestion loss and link layer disruption?. RSVP is just a signaling protocol. I think that it is responsibility of other components of the IntServ architecture such as traffic control (eg packet scheduler  and admission control). I don't know if when you say RSVP you refer to RSVP and traffic control components ?.

Maria
 
  

-- 
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: maria@spri.levels.unisa.edu.au
       VILME001@Students.UniSA.Edu.Au

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm
  --------------9E54C311A9536E568EBEC9E8-- From rsvp-owner@ISI.EDU Wed Apr 5 10:54: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 KAA10996 for ; Wed, 5 Apr 2000 10:54:42 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA08962 for rsvp-outgoing; Wed, 5 Apr 2000 05:03:10 -0700 (PDT) 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 FAA08957 for ; Wed, 5 Apr 2000 05:03:09 -0700 (PDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA12102 for ; Wed, 5 Apr 2000 05:03:25 -0700 (PDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA02913; Wed, 5 Apr 2000 05:03:34 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id FAA01741; Wed, 5 Apr 2000 05:07:31 -0700 Message-Id: <4.3.0.20000405045848.01e03c50@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 05 Apr 2000 05:02:00 -0700 To: Telford001@aol.com From: Fred Baker Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 Cc: diffserv@ietf.org (DIFFSERV WG), rsvp@ISI.EDU ('rsvp@isi.edu'), issll@lmcs.mit.edu, martillo@telfordtools.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk At 02:10 PM 4/4/00 -0400, Telford001@aol.com wrote: >I have been thinking about guaranteeing latencies in packet delivery. >If a WAN network provides transport for very large packets, and if a >reservation is made for video traffic that requires a very low latency >at high priority, would it not make sense for intermediate routers to >fragment very large packets so that if a priority low latency packet >arrived at an intermediate router while that router is transmitting >a lower priority packet, the wait before the high priority low latency >packet actually begins to transmit would be low because as soon >as the reservation had been made, the router limited the transmit >MTU size on the relevant interfaces to decrease possible delays >through an intermediate router? In some cases, yes. On relatively low speed lines, some routers use PPP Multilink, even on a single line, in order to get the fragmentation and reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML LCP. The place where this becomes unnecessary is when the speed of the link is fast enough that the jitter introduced by competing traffic is within acceptable bounds. That rate is on the order of megabits per second; for most equipment, T-1 links don't require this. From rsvp-owner@ISI.EDU Wed Apr 5 11:00:20 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 LAA11106 for ; Wed, 5 Apr 2000 11:00:19 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA09318 for rsvp-outgoing; Wed, 5 Apr 2000 05:12:45 -0700 (PDT) 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 FAA09313 for ; Wed, 5 Apr 2000 05:12:43 -0700 (PDT) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA12531 for ; Wed, 5 Apr 2000 05:13:00 -0700 (PDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo-d10.mx.aol.com (mail_out_v25.3.) id c.4a.3a564ac (9823); Wed, 5 Apr 2000 08:11:53 -0400 (EDT) Message-ID: <4a.3a564ac.261c8789@aol.com> Date: Wed, 5 Apr 2000 08:11:53 EDT Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 To: fred@cisco.com CC: diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu, martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 4/5/00 8:04:10 AM Eastern Daylight Time, fred@cisco.com writes: > At 02:10 PM 4/4/00 -0400, Telford001@aol.com wrote: > >I have been thinking about guaranteeing latencies in packet delivery. > >If a WAN network provides transport for very large packets, and if a > >reservation is made for video traffic that requires a very low latency > >at high priority, would it not make sense for intermediate routers to > >fragment very large packets so that if a priority low latency packet > >arrived at an intermediate router while that router is transmitting > >a lower priority packet, the wait before the high priority low latency > >packet actually begins to transmit would be low because as soon > >as the reservation had been made, the router limited the transmit > >MTU size on the relevant interfaces to decrease possible delays > >through an intermediate router? > > In some cases, yes. On relatively low speed lines, some routers use PPP > Multilink, even on a single line, in order to get the fragmentation and > reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML > LCP. > > The place where this becomes unnecessary is when the speed of the link is > fast enough that the jitter introduced by competing traffic is within > acceptable bounds. That rate is on the order of megabits per second; for > most equipment, T-1 links don't require this. It depends on maximum packet sizes and the number of hops. The size of packets on some of the faster media have become quite large, and supporting jumbograms has been rather common. Latencies can also accumulate. With a sufficient number of hops small delays can cause a lot of jitter. Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com From rsvp-owner@ISI.EDU Wed Apr 5 11:00:27 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 LAA11117 for ; Wed, 5 Apr 2000 11:00:26 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA09781 for rsvp-outgoing; Wed, 5 Apr 2000 05:25:01 -0700 (PDT) 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 FAA09775 for ; Wed, 5 Apr 2000 05:25:00 -0700 (PDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA13010 for ; Wed, 5 Apr 2000 05:25:17 -0700 (PDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA02706; Wed, 5 Apr 2000 05:23:30 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id FAA01754; Wed, 5 Apr 2000 05:29:23 -0700 Message-Id: <4.3.0.20000405052259.00db7760@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 05 Apr 2000 05:24:12 -0700 To: Telford001@aol.com From: Fred Baker Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 Cc: diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu, martillo@telfordtools.com In-Reply-To: <4a.3a564ac.261c8789@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk I think we're in violent agreement. At some relatively low speed, the PPP Multilink procedure can be used to fragment competing traffic. At some not-much-higher speed, it becomes irrelevant. We're dickering about the magic number. From rsvp-owner@ISI.EDU Wed Apr 5 12:40:11 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 MAA12613 for ; Wed, 5 Apr 2000 12:40:10 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA12349 for rsvp-outgoing; Wed, 5 Apr 2000 06:40:08 -0700 (PDT) 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 GAA12343 for ; Wed, 5 Apr 2000 06:40:05 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA15443 for ; Wed, 5 Apr 2000 06:40:21 -0700 (PDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA18951; Wed, 5 Apr 2000 09:40:00 -0400 (EDT) Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id JAA19815; Wed, 5 Apr 2000 09:39:33 -0400 (EDT) Received: from luna.mitre.org (luna.mitre.org [128.29.31.17]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id JAA01491; Wed, 5 Apr 2000 09:39:58 -0400 (EDT) Received: from mitre.org (m14961-pc.mitre.org [128.29.105.115]) by luna.mitre.org (8.7.2/8.7.2) with ESMTP id JAA14611; Wed, 5 Apr 2000 09:39:50 -0400 (EDT) Message-ID: <38EB41B7.AC9295D@mitre.org> Date: Wed, 05 Apr 2000 09:37:59 -0400 From: Duncan Thomson Reply-To: duncant@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Maria Elena Villapol CC: "Simon Oosthoek (EMN)" , "'Bora Akyol'" , "'rsvp@isi.edu'" , "Geert Heijenk (EMN)" , "Georgios Karagiannis (EMN)" , "Schult,Nancy L." Subject: Re: RSVP on wireless IP References: <38EA4A6A.6EB3D87B@mitre.org> <38EADFC6.1FE2B862@spri.levels.unisa.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Let's see if I can straighten out the thread a little here. Taking a little liberty with the order in which things were discussed: > Bora Akyol wrote: > > > > How are you planning on differentiation congestion loss from > > link layer corruption? > Duncan Thomson wrote: > > In addition, I think it's important to deal with errors within the link > > layer, so that the network layer sees only a varying effective link > > bandwidth. > Maria Elena Villapol wrote: > > I got confused. Why should RSVP distinguish between congestion loss and link > layer disruption?. RSVP is just a signaling protocol. I think that it is > responsibility of other components of the IntServ architecture such as > traffic control (eg packet scheduler and admission control). I don't know > if when you say RSVP you refer to RSVP and traffic control components ?. > Maria, Yes, I was including components such as admission control when I used the term "RSVP". Perhaps my terminology is not correct. Since I've been working for a while with ISI's RSVP implementation, I tend to lump together in my mind everything that is handled by the RSVP daemon (rsvpd) and refer to that as "RSVP". Anyway, the point is that there is a major distinction between congestion loss and link layer disruption. The intserv architecture is intended to deal with the former. The latter should (I believe) be dealt with either within the link layer, or all the way up at the transport layer. The reason we got into the discussion is that in some environments link characteristics change with time. For example, V.90 modems will "retrain" during the course of a connection, changing the data rate but maintaining link quality. RSVP (admission control) needs to know the link characteristics so that it knows what resources are available for reservation. To be specific, it needs to know the link bandwidth. Knowing this, RSVP can allocate bandwidth to flows in such a way as to prevent congestion loss. My view is that, if the link is variable, then changes in link bandwidth need to be signalled to RSVP, and RSVP needs to have some mechanism for dealing with them. The picture gets much more complicated in the case of shared media. Duncan From rsvp-owner@ISI.EDU Wed Apr 5 12:40: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 MAA12624 for ; Wed, 5 Apr 2000 12:40:18 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA13542 for rsvp-outgoing; Wed, 5 Apr 2000 07:15:30 -0700 (PDT) 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 HAA13537 for ; Wed, 5 Apr 2000 07:15:28 -0700 (PDT) Received: from imo16.mx.aol.com (imo16.mx.aol.com [152.163.225.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA16746 for ; Wed, 5 Apr 2000 07:15:45 -0700 (PDT) From: Telford001@aol.com Received: from Telford001@aol.com by imo16.mx.aol.com (mail_out_v25.3.) id c.37.368082d (3971); Wed, 5 Apr 2000 10:14:29 -0400 (EDT) Message-ID: <37.368082d.261ca444@aol.com> Date: Wed, 5 Apr 2000 10:14:28 EDT Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6 To: fred@cisco.com CC: diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu, martillo@telfordtools.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 101 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 4/5/00 8:40:19 AM Eastern Daylight Time, fred@cisco.com writes: > In some cases, yes. On relatively low speed lines, some routers use PPP > Multilink, even on a single line, in order to get the fragmentation and > reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the ML > LCP. Of course, such a procedure would not work for FR unless PPP were run over the FR or on a lot of the new wireless technologies. > The place where this becomes unnecessary is when the speed of the link is > fast enough that the jitter introduced by competing traffic is within > acceptable bounds. That rate is on the order of megabits per second; for > most equipment, T-1 links don't require this. Not obvious. Joachim Martillo President Telford Tools, Inc. 17 Pleasant Hill Ave. Boston, MA 02126-2813 V 617-298-4107, 298-1617 F 617-298-1745 E martillo@telfordtools.com U http://www.telfordtools.com From rsvp-owner@ISI.EDU Wed Apr 5 14:24: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 OAA14247 for ; Wed, 5 Apr 2000 14:24:37 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA18141 for rsvp-outgoing; Wed, 5 Apr 2000 09:28:50 -0700 (PDT) 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 JAA18136 for ; Wed, 5 Apr 2000 09:28:49 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28705; Wed, 5 Apr 2000 09:29:04 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA01797; Wed, 5 Apr 2000 16:29:04 GMT Date: Wed, 5 Apr 2000 16:29:04 GMT Message-Id: <200004051629.QAA01797@gra.isi.edu> To: rsvp@ISI.EDU, dcharlap@fore.com Subject: Re: Another question: unnecessary objects X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> From rsvp-owner@ISI.EDU Tue Apr 4 18:16:01 2000 *> Date: Tue, 04 Apr 2000 21:09:44 -0400 *> 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: Another question: unnecessary objects *> Content-Transfer-Encoding: 7bit *> Sender: owner-rsvp@ISI.EDU *> Precedence: bulk *> X-Lines: 14 *> *> How should unnecessary objects be handled? *> *> For instance, if a STYLE object is included in a Path message. Or if a *> SCOPE object is included in a non-WF style Resv message. *> *> I can think of two possibilities, either of which might be appropriate: *> *> - Treat it as an unknown object class. For most objects, this will mean *> rejecting the message, since most objects have class numbers of the *> form 0bbbbbbb. *> *> - Ignore the object - process the message as if it didn't exist. *> *> -- David *> Jon Postel had something to say about this, in Section 3.2 of RFC 791. I suggest you follow his oft-quoted advice. Bob Braden From rsvp-owner@ISI.EDU Wed Apr 5 14:29: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 OAA14364 for ; Wed, 5 Apr 2000 14:29:48 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA18654 for rsvp-outgoing; Wed, 5 Apr 2000 09:42:49 -0700 (PDT) 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 JAA18649 for ; Wed, 5 Apr 2000 09:42:47 -0700 (PDT) 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 JAA00379 for ; Wed, 5 Apr 2000 09:43:03 -0700 (PDT) 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 MAA26912; Wed, 5 Apr 2000 12:41:31 -0400 (EDT) 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 MAA09889; Wed, 5 Apr 2000 12:41:05 -0400 (EDT) Message-ID: <38EB6CA4.4C40C53F@fore.com> Date: Wed, 05 Apr 2000 12:41:08 -0400 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Telford001@aol.com CC: fred@cisco.com, diffserv@ietf.org, rsvp@ISI.EDU, issll@lmcs.mit.edu, martillo@telfordtools.com Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Servicesand IPv6 References: <4a.3a564ac.261c8789@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Telford001@aol.com wrote: >>> >>> I have been thinking about guaranteeing latencies in packet >>> delivery. If a WAN network provides transport for very large >>> packets, and if a reservation is made for video traffic that >>> requires a very low latency at high priority, would it not make >>> sense for intermediate routers to fragment very large packets so >>> that if a priority low latency packet arrived at an intermediate >>> router while that router is transmitting a lower priority packet, >>> the wait before the high priority low latency packet actually begins >>> to transmit would be low because as soon as the reservation had been >>> made, the router limited the transmit MTU size on the relevant >>> interfaces to decrease possible delays through an intermediate >>> router? >> >> In some cases, yes. On relatively low speed lines, some routers use >> PPP Multilink, even on a single line, in order to get the >> fragmentation and reassembly. VoIP data goes in the PPP IPCP stream, >> TCP data goes via the ML LCP. >> >> The place where this becomes unnecessary is when the speed of the >> link is fast enough that the jitter introduced by competing traffic >> is within acceptable bounds. That rate is on the order of megabits >> per second; for most equipment, T-1 links don't require this. > > It depends on maximum packet sizes and the number of hops. The size > of packets on some of the faster media have become quite large, and > supporting jumbograms has been rather common. Latencies can also > accumulate. With a sufficient number of hops small delays can cause a > lot of jitter. Yes. Let's take two examples here. A 9K frame transmitted over Gigabit ethernet (where 9K frames are commonly used) and a 1500-byte frame transmitted over a T1 line. If we ignore layer-1 and layer-2 bits and use an approximation of the speed, we can get the approximate time it takes to transmit a frame. 72us for the GigE frame (9KB = 72,000 bits divided by 1,000,000,000 bits/s), and 8ms for the T1 frame (1500 bytes = 12,000 bits divided by 1,500,000 bits/s). Neither of these delays are too bad. Most apps can deal with even an 8ms delay. But these delays may add up as the packet traverses many switches. Imagine a worst-case scenario where a low-latency packet goes through 30 switches and is queued for transmission just as a maximal-size packet has begun transmitting. This creates the maximal queuing delay - generating the worst-case for jitter. On the GigE network, the cumulative delay from being behind a 9K frame at every hop is 2160us - or approximately 2.2ms. This is probably acceptible. Especially when you consider that it's still significantly less than the delay caused by one 1500 byte frame on the T1 network. On the other hand, with the T1 switches, the cumulative delay from being behind a 1500 byte frame at each hop becomes 240ms - nearly 1/4 second. This may well be unacceptible for some applications. One possible solution (as was already proposed) is fragmentation to smaller sizes. Of course, this introduces other problems as well. (Incidentally, this is one of the reasons why ATM can enforce delay and jitter constraints over slow lines. The segmentation and reassembly of frames into cells reduces the transmission delay of a single cell down to 283us over a T1 line, or 8.4ms over a worst-case 30-hop route.) -- David From rsvp-owner@ISI.EDU Thu Apr 6 05: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 FAA06007 for ; Thu, 6 Apr 2000 05:43:14 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA22222 for rsvp-outgoing; Thu, 6 Apr 2000 00:33:41 -0700 (PDT) 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 AAA22217 for ; Thu, 6 Apr 2000 00:33:40 -0700 (PDT) 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 AAA22198 for ; Thu, 6 Apr 2000 00:33:57 -0700 (PDT) Received: from csx08 (csx08.cs.wmich.edu [141.218.40.162]) by hal.cs.wmich.edu (8.9.3/8.9.3) with ESMTP id DAA13194; Thu, 6 Apr 2000 03:33:31 -0400 (EDT) Date: Thu, 6 Apr 2000 03:33:30 -0400 (EDT) From: SARIPALLI SUPRIYA X-Sender: ssaripal@csx08 To: Edgar =?iso-8859-1?Q?Mu=F1oz?= Mercader cc: rsvp@ISI.EDU Subject: Re: Masters Project In-Reply-To: <38EC5659.D6EE03A@mat.upc.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by zephyr.isi.edu id AAA22218 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Hi!! I am doing my Masters project in VoIP..In this process was I interested in RSVP.. I am planning to implement the SCRAPI in JAVA and could extend it for CONFIRM messages, etc. This is a layer on top of RAPI....Is there any way where I could find the the RAPI interface installed directly on to my machine and implement SCARPI on top of it.The only way I could figure out is I had to install the RSVP daemon from the soft releases in RSVP project...I dont require the RSVP daemon..just need the RAPI with the libraries rapi.h.. Internet draft for scrapi is at: www.isi.edu/rsvp/DOCUMENTS/draft-lindell-rsvp-scrapi-02.txt Thanking You.. Supriya ****************************************************************************** Supriya Saripalli T.A CS Department Phone # 616-387-5521 ******************************************************************************* On Thu, 6 Apr 2000, Edgar [iso-8859-1] Muñoz Mercader wrote: > Hi Saripalli > > I am a student working with RSVP protocol. You can find an > implementation in www.isi.edu/rsvp/relase.html. But I find very extrange > that you could not find it. > > Egar > > SARIPALLI SUPRIYA wrote: > > > > 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 > From rsvp-owner@ISI.EDU Thu Apr 6 05:51:12 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 FAA06125 for ; Thu, 6 Apr 2000 05:51:10 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA21197 for rsvp-outgoing; Thu, 6 Apr 2000 00:12:33 -0700 (PDT) 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 AAA21192 for ; Thu, 6 Apr 2000 00:12:32 -0700 (PDT) Received: from dimoni.upc.es (dimoni.upc.es [147.83.2.62]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA20413 for ; Thu, 6 Apr 2000 00:12:42 -0700 (PDT) Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by dimoni.upc.es (8.8.8+Sun/8.8.8) with ESMTP id JAA04906; Thu, 6 Apr 2000 09:12:30 +0200 (MET DST) Received: from mat.upc.es (mobigate.upc.es [147.83.39.90]) by mat.upc.es (8.7.6/8.7.3) with ESMTP id JAA09203; Thu, 6 Apr 2000 09:12:04 +0200 (MET DST) Message-ID: <38EC5659.D6EE03A@mat.upc.es> Date: Thu, 06 Apr 2000 08:18:17 -0100 From: Edgar =?iso-8859-1?Q?Mu=F1oz?= Mercader X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: SARIPALLI SUPRIYA CC: rsvp@ISI.EDU Subject: Re: Masters Project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi Saripalli I am a student working with RSVP protocol. You can find an implementation in www.isi.edu/rsvp/relase.html. But I find very extrange that you could not find it. Egar SARIPALLI SUPRIYA wrote: > > 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 From rsvp-owner@ISI.EDU Thu Apr 6 13:56: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 NAA12015 for ; Thu, 6 Apr 2000 13:56:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA10045 for rsvp-outgoing; Thu, 6 Apr 2000 09:01:25 -0700 (PDT) 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 JAA10040 for ; Thu, 6 Apr 2000 09:01:24 -0700 (PDT) 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 JAA10178 for ; Thu, 6 Apr 2000 09:01:41 -0700 (PDT) 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 2JNQ7FS7; Thu, 6 Apr 2000 11:58:49 -0400 Message-ID: <38ECB612.1EB0E312@globespan.net> Date: Thu, 06 Apr 2000 12:06:42 -0400 From: Sameer Shah Organization: Globespan Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: question regarding Message Id extension in draft-ietf-rsvp-refresh-reduct-03.txt References: <200003131956.TAA04675@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 Hi, The draft says that the Refresh Reduction capable bit will be set in messages received from a node, if the node supports all the extensions suggested in the draft. But a node that supports reliable RSVP message delivery but not Bundle and refresh messages, will not set the Refresh-Reduction-Capable bit. This means that neighbor nodes ought to dynamically discover whether this node supports only the Message Id extension, from messages received from this node. If the messages contain a Message Id object or a Message Id Ack object, then this node supports Message Id extensions. Or if they receive an error message from the node specifying unknown object for the Message Id object, then it does not support Message Id extensions. Would it not be more efficient to provide a bit in the flags field of the common RSVP header to indicate that a node supports only the Message Id extensions, similar to the RR capable bit, instead of using other mechanisms to discover this. Regards, Sameer From rsvp-owner@ISI.EDU Fri Apr 7 00:15:42 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21536 for ; Fri, 7 Apr 2000 00:15:41 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA04446 for rsvp-outgoing; Thu, 6 Apr 2000 19:28:00 -0700 (PDT) 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 TAA04437 for ; Thu, 6 Apr 2000 19:27:58 -0700 (PDT) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA21084; Thu, 6 Apr 2000 19:28:14 -0700 (PDT) Received: from who ([12.78.195.220]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000407022742.UWNK27191.mtiwmhc22.worldnet.att.net@who>; Fri, 7 Apr 2000 02:27:42 +0000 From: "Gregg C Levine" To: "RSVP -TEST" , "RSVP" Subject: RSVP on Linux and UNIX, and Solaris Date: Thu, 6 Apr 2000 22:27:47 -0400 Keywords: Miscellaneous Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Disposition-Notification-To: "Gregg C Levine" Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hello from Gregg C Levine usually at Jedi Knight Computers (Cross posted to both RSVP lists!) To those of you who are subscribed to both lists, like me, bear with this. I am considering RSVP applications on the usual members of the Unix committee, Linux, and UNIX,and Sun Solaris. What I am asking, is does anyone have any success on these three platforms? I do not need programming examples at this time, I just to need to know what has happened, successes, and failures. It would be every subscribers choice, you can report, off lists, what has happened. Please note that this is currently a PC, and Microsoft shop. We do not have an Sun workstation, here for those tests, nor is anyone running here running a flavor of UNIX, such as normal UNIX, or odd man out, Linux. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "Use the Force, Luke." Obi-Wan Kenobi "Trust in the Force, Luke, and wait." Obi-Wan Kenobi From rsvp-owner@ISI.EDU Fri Apr 7 16:20:11 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 QAA17375 for ; Fri, 7 Apr 2000 16:20:10 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA04136 for rsvp-outgoing; Fri, 7 Apr 2000 11:23:31 -0700 (PDT) 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 LAA04131 for ; Fri, 7 Apr 2000 11:23:31 -0700 (PDT) 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 LAA05395 for ; Fri, 7 Apr 2000 11:23:48 -0700 (PDT) Received: from csx25 (csx25.cs.wmich.edu [141.218.40.179]) by hal.cs.wmich.edu (8.9.3/8.9.3) with ESMTP id OAA10744 for ; Fri, 7 Apr 2000 14:23:46 -0400 (EDT) Date: Fri, 7 Apr 2000 14:23:45 -0400 (EDT) From: SARIPALLI SUPRIYA X-Sender: ssaripal@csx25 To: rsvp@ISI.EDU Subject: SCRAPI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi everyone... I am planning to implement the user interface API for RSVP i.e SCRAPI in JAVA...I downloaded the SCRAPI written in C language from the softreleases at isi.edu/rsvp...I am facing few problems with that... I downladed the tar file scrapi01.rel4.2a4.tar.Z from the release ISI distribution. When I try to run this its not able to find the rapi_lib.h and rapi_err.h Am I supposed to download someother files too?? Where can I get the rapi libraries?? Need them for my implementation.. Thanks for your time... Supriya ****************************************************************************** Supriya Saripalli T.A CS Department Phone # 616-387-5521 ******************************************************************************* From rsvp-owner@ISI.EDU Fri Apr 7 20:06: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 UAA21423 for ; Fri, 7 Apr 2000 20:06:56 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA13211 for rsvp-outgoing; Fri, 7 Apr 2000 15:38:48 -0700 (PDT) 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 PAA13206 for ; Fri, 7 Apr 2000 15:38:43 -0700 (PDT) Received: from pup.isi.edu (pup.isi.edu [128.9.160.228]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA06012; Fri, 7 Apr 2000 15:38:59 -0700 (PDT) Message-Id: <200004072238.PAA06012@boreas.isi.edu> To: SARIPALLI SUPRIYA cc: rsvp@ISI.EDU Reply-To: lindell@ISI.EDU Subject: Re: SCRAPI In-Reply-To: Message from SARIPALLI SUPRIYA of "Fri, 07 Apr 2000 14:23:45 EDT." Date: Fri, 07 Apr 2000 15:38:59 -0700 From: Bob Lindell Sender: owner-rsvp@ISI.EDU Precedence: bulk > Hi everyone... > I am planning to implement the user interface API for RSVP i.e SCRAPI in > JAVA...I downloaded the SCRAPI written in C language from the softreleases > at isi.edu/rsvp...I am facing few problems with that... > I downladed the tar file scrapi01.rel4.2a4.tar.Z from the > release ISI distribution. > When I try to run this its not able to find the rapi_lib.h and rapi_err.h > Am I supposed to download someother files too?? > Where can I get the rapi libraries?? Need them for my implementation.. You need the RAPI api code included with rsvpd. Try downloading rsvpd.rel4.2a4-1.tar.gz, it has both rsvpd and SCRAPI bundled together. Bob Lindell From rsvp-owner@ISI.EDU Fri Apr 7 22:05: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 WAA23533 for ; Fri, 7 Apr 2000 22:05:46 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA17340 for rsvp-outgoing; Fri, 7 Apr 2000 17:37:47 -0700 (PDT) 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 RAA17335 for ; Fri, 7 Apr 2000 17:37:47 -0700 (PDT) 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 RAA04981 for ; Fri, 7 Apr 2000 17:38:04 -0700 (PDT) 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 UAA13973 for ; Fri, 7 Apr 2000 20:37:32 -0400 (EDT) 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 UAA27820 for ; Fri, 7 Apr 2000 20:37:34 -0400 (EDT) Message-ID: <38EE7F47.EABBCE05@fore.com> Date: Fri, 07 Apr 2000 20:37:27 -0400 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: Re: Question about integrity References: <200004031706.KAA27071@boreas.isi.edu> <38EE7DBD.11122FB7@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > > I would think that if you cared enough to insert an INTEGRITY object, > then if the node does not support it, it should respond with an error > saying "INTEGRITY not supported". Note that my answer is biased > towards use of RSVP in a backbone type network where authentication > and correctness really are important and the operator is likely to > have knowledge that all of his nodes will support a given capability. Keeping in mind that there doesn't exist any such error. As a matter of fact, Appendix B explicitly lists INTEGRITY failure as a condition that is not signalled to other nodes, but is dealt with silently (possibly involving logging and/or administrative alerts.) -- David From rsvp-owner@ISI.EDU Fri Apr 7 22:06:11 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 WAA23544 for ; Fri, 7 Apr 2000 22:06:10 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA17134 for rsvp-outgoing; Fri, 7 Apr 2000 17:30:36 -0700 (PDT) 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 RAA17129 for ; Fri, 7 Apr 2000 17:30:35 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA03851; Fri, 7 Apr 2000 17:30:53 -0700 (PDT) Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA26361; Fri, 7 Apr 2000 17:30:52 -0700 (PDT) Message-ID: <38EE7DBD.11122FB7@pluris.com> Date: Fri, 07 Apr 2000 17:30:53 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: lindell@ISI.EDU CC: David Charlap , rsvp@ISI.EDU Subject: Re: Question about integrity References: <200004031706.KAA27071@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I would think that if you cared enough to insert an INTEGRITY object, then if the node does not support it, it should respond with an error saying "INTEGRITY not supported". Note that my answer is biased towards use of RSVP in a backbone type network where authentication and correctness really are important and the operator is likely to have knowledge that all of his nodes will support a given capability. Bora ps. Of course we can build in capability negotiation to RSVP :-) Bob Lindell wrote: > > 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. > > I also think it should go ahead and process the message. > > If the sender was really concerned about security, it would make sure > the next hop supported integrity. There are 2 basic cases I can think > of at the moment. > > 1) A sender would require that the replay protection handshake > complete successfully. By definition the next hop supports > integrity. > > 2) A sender does not handshake over a point to point link > that is assumed to be secure from replay attacks. It is > likely in this case that the sender has apriori knowledge > that the peer supports integrity as part of a peering > agreement. > > Bob Lindell From rsvp-owner@ISI.EDU Sat Apr 8 00:54: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 AAA25972 for ; Sat, 8 Apr 2000 00:54:41 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA22493 for rsvp-outgoing; Fri, 7 Apr 2000 20:18:38 -0700 (PDT) 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 UAA22487 for ; Fri, 7 Apr 2000 20:18:34 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA24871 for ; Fri, 7 Apr 2000 20:18:52 -0700 (PDT) Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA00143; Fri, 7 Apr 2000 20:18:45 -0700 (PDT) Message-ID: <38EEA513.40F67543@pluris.com> Date: Fri, 07 Apr 2000 20:18:43 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Charlap CC: rsvp@ISI.EDU Subject: Re: Question about integrity References: <200004031706.KAA27071@boreas.isi.edu> <38EE7DBD.11122FB7@pluris.com> <38EE7F47.EABBCE05@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit The fact that an error or an object doesn't exist did not stop us before (see. RSVP-TE), I suggest that we define such an error condition. Even if we did not, a message should not be accepted under the conditions specified in this thread. This is unacceptable for a backbone application. It may be acceptable for PC-to router and enterprise application for some people, I would rather just drop the message since putting an INTEGRITY object indicates that the sender of the message cared about security enough. Regards Bora Akyol David Charlap wrote: > Bora Akyol wrote: > > > > I would think that if you cared enough to insert an INTEGRITY object, > > then if the node does not support it, it should respond with an error > > saying "INTEGRITY not supported". Note that my answer is biased > > towards use of RSVP in a backbone type network where authentication > > and correctness really are important and the operator is likely to > > have knowledge that all of his nodes will support a given capability. > > Keeping in mind that there doesn't exist any such error. As a matter of > fact, Appendix B explicitly lists INTEGRITY failure as a condition that > is not signalled to other nodes, but is dealt with silently (possibly > involving logging and/or administrative alerts.) > > -- David From rsvp-owner@ISI.EDU Sat Apr 8 22:43:58 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21881 for ; Sat, 8 Apr 2000 22:43:57 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA02143 for rsvp-outgoing; Sat, 8 Apr 2000 17:53:39 -0700 (PDT) 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 RAA02138 for ; Sat, 8 Apr 2000 17:53:39 -0700 (PDT) Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05357 for ; Sat, 8 Apr 2000 17:53:56 -0700 (PDT) Received: from who ([12.78.242.37]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000409005319.FUGQ12683.mtiwmhc26.worldnet.att.net@who> for ; Sun, 9 Apr 2000 00:53:19 +0000 From: "Gregg C Levine" To: "RSVP" Subject: RSVP support on Windows Date: Sat, 8 Apr 2000 20:53:10 -0400 Keywords: Miscellaneous Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Disposition-Notification-To: "Gregg C Levine" Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hello from Gregg C Levine usually at Jedi Knight Computers Just for the record, would somebody provide me support on this:RSVP support exists on all later versions of Windows, after 95. Correct? Gregg C Levine mailto:hansolofalcon@worldnet.att.net "Use the Force, Luke." Obi-Wan Kenobi "Trust in the Force, Luke, and wait." Obi-Wan Kenobi From rsvp-owner@ISI.EDU Sun Apr 9 01:44: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 BAA28560 for ; Sun, 9 Apr 2000 01:44:15 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id VAA08528 for rsvp-outgoing; Sat, 8 Apr 2000 21:01:56 -0700 (PDT) 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 VAA08523 for ; Sat, 8 Apr 2000 21:01:55 -0700 (PDT) Received: from relay03.netaddress.usa.net (relay03.netaddress.usa.net [204.68.24.183]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id VAA19657 for ; Sat, 8 Apr 2000 21:02:13 -0700 (PDT) Received: (qmail 28196 invoked by uid 0); 8 Apr 2000 17:19:46 -0000 Received: (qmail 24705 invoked from network); 6 Apr 2000 22:08:43 -0000 Received: from apps01.netaddress.usa.net (204.68.24.172) by outbound.netaddress.usa.net with SMTP; 6 Apr 2000 22:08:43 -0000 Received: (qmail 1448 invoked by uid 0); 6 Apr 2000 22:08:33 -0000 Received: from power.atlantis.it by apps01 with [Collected by] USA.NET Rover (vM3.3.0.56) for marcoscotti@usa.net with ESMTP id 754eDFwif2354R01; Thu, 06 Apr 2000 22:08:31 GMT Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by power.atlantis.it (8.9.3/8.9.3) with ESMTP id NAA05174 for ; Tue, 25 Jan 2000 13:01:19 +0100 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25659; Tue, 25 Jan 2000 05:14:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25626 for ; Tue, 25 Jan 2000 05:14:30 -0500 (EST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20724 for ; Tue, 25 Jan 2000 05:15:39 -0500 (EST) Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id LAA13589; Tue, 25 Jan 2000 11:13:37 +0100 (MET) Received: from alcatel.be ([138.203.66.143]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id LAA19217; Tue, 25 Jan 2000 11:13:29 +0100 (MET) Message-ID: <388D7741.EB0B6F0@alcatel.be> Date: Tue, 25 Jan 2000 11:13:21 +0100 From: Omar Elloumi Organization: Alcatel Corporate Research Center X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: campbell@comet.columbia.edu, Stefaan De Cnodder , Ping Pan CC: Yoram Bernet , RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: Re: [Diffserv] Re: An apology... References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> <388CC9A7.E91CC41B@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Status: RO Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit "Andrew T. Campbell" wrote: > Yoram Bernet wrote: > > > > A number of folks have pointed out that it was impolite of me to suggest > > that those who are calling for a new QoS signaling protocol are calling into > > question the competence of the original developers of RSVP. > > > > I apologize. > > > > I do believe however, that the statement which appeared in this exchange: > > "We believe that there are much simpler ways of solving the same problems" > > is rather arrogant and is indicative of an all too common tendency to scrap > > what has been done so far and invent something new. > > > > I'm calling for us to have the discipline to study the work that has been > > done and to clearly articulate where and why it falls short and what of it > > can be salvaged, before deciding that something entirely new is necessary... > > > > Y > > Bravo! > A good starting point for such a study is to try to identify the traffic which needs reservation and then to quantify the number of flows that need reservation and how many of them will go through several diffserv domains. Then may be we'll come to the conclusion that RSVP (with may be some aggregation schemes) is enough. I, somewhat, disagree with the analysis done by Ping which is a worst case study. Based on Internet traffic traces we can not say, a priori, if RSVP will scale or not. We need instead to determine the number of flows that need reservation which has nothing to do with the number of flows in the Internet (e.g. we don't, or rarely, need a RSVP session for TCP individual flows). One question that come in mind is: do we need resource reservation for VoIP traffic in DiffServ networks? -- ____________________________________________________________ Omar Elloumi Alcatel Research - Network Architecture - Traffic Technology Francis Wellesplein 1, 2018 Antwerp, Belgium Phone: + 32 3 240 78 33 Fax: + 32 3 240 99 32 http://www.alcatel.com/crc/ ____________________________________________________________ Opinions expressed are those of the sender and do not reflect Alcatel policy or agreement _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From rsvp-owner@ISI.EDU Mon Apr 10 04:59: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 EAA03609 for ; Mon, 10 Apr 2000 04:59:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA04732 for rsvp-outgoing; Sun, 9 Apr 2000 23:45:16 -0700 (PDT) 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 XAA04727 for ; Sun, 9 Apr 2000 23:45:15 -0700 (PDT) Received: from belcebu.upc.es (belcebu.upc.es [147.83.2.63]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA26467 for ; Sun, 9 Apr 2000 23:45:29 -0700 (PDT) Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by belcebu.upc.es (8.8.8+Sun/8.8.8) with ESMTP id IAA23594 for ; Mon, 10 Apr 2000 08:45:11 +0200 (MET DST) Received: from mat.upc.es (171-BARC-X23.libre.retevision.es [62.82.1.171]) by mat.upc.es (8.7.6/8.7.3) with ESMTP id AAA06934 for ; Mon, 10 Apr 2000 00:28:57 +0200 (MET DST) Message-ID: <38F10428.6D0DB9EA@mat.upc.es> Date: Mon, 10 Apr 2000 00:28:57 +0200 From: Edgar =?iso-8859-1?Q?Mu=F1oz?= Mercader X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: [Fwd: Masters Project] Content-Type: multipart/mixed; boundary="------------354F4B2D1F85574D614E9B1B" Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. --------------354F4B2D1F85574D614E9B1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------354F4B2D1F85574D614E9B1B Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <38F1037B.4FC83145@mat.upc.es> Date: Mon, 10 Apr 2000 00:26:03 +0200 From: Edgar =?iso-8859-1?Q?Mu=F1oz?= Mercader X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: SARIPALLI SUPRIYA Subject: Re: Masters Project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!! I am trying to implement a simple application wich it is supposed to make a reservation to send a flow of video (for exemple). The mainly aspect of the project is to work with 2 CISCO 2600 and with a 3600, but I need any easy to use RAPI to implement it and make some test on the behaviour of the routers. At the moment I am trying to execute the ISI implementation locally in my PC (under Linux), but I found some stupid problems with the compilation. I still have some problems to make a silly application to run it, I think it could be caused by the daemon, I think the problem is I am using a 2.2.13 kernel version, which is not the 2.0.36 recomended in the ISI documentation. Do you know something about it ? SARIPALLI SUPRIYA wrote: > Hi !! > Could you just let me know what you are planning to implement in RSVP > using C and C++ if its not a botheration to you... > Thanks for your time > Supriya > > ****************************************************************************** > > Supriya Saripalli > T.A CS Department Phone # 616-387-5521 > ******************************************************************************* --------------354F4B2D1F85574D614E9B1B-- From rsvp-owner@ISI.EDU Mon Apr 10 10:45: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 KAA15101 for ; Mon, 10 Apr 2000 10:45:53 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA17318 for rsvp-outgoing; Mon, 10 Apr 2000 05:25:47 -0700 (PDT) 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 FAA17313 for ; Mon, 10 Apr 2000 05:25:42 -0700 (PDT) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25171 for ; Mon, 10 Apr 2000 05:25:59 -0700 (PDT) Received: from sernt13.essex.ac.uk ([155.245.240.182]) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 12edGQ-0002hs-00 for rsvp@ISI.EDU; Mon, 10 Apr 2000 13:25:58 +0100 Received: from csres11.essex.ac.uk ([155.245.163.111]) by sernt13.essex.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 23KYBVW5; Mon, 10 Apr 2000 13:25:57 +0100 From: K Sun Reply-To: ksun@essex.ac.uk To: rsvp@ISI.EDU Subject: Questions about Refresh reduction? In-Reply-To: <200004051629.QAA01797@gra.isi.edu> Message-ID: Date: Mon, 10 Apr 2000 13:25:53 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, I just browse the draft "RSVP Refresh Overhead Reduction Extensions". However, there is something I could not make sure. 1. Is the Bundle message just suitable for transmit information between two neighbour? Every router should compose its own bundle message to the next hop? 2. Is it true that Bundle message require every message that has been aggregated should be in the same type? Thanks in advance! Sun Kai From rsvp-owner@ISI.EDU Mon Apr 10 11:09: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 LAA16433 for ; Mon, 10 Apr 2000 11:09:18 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA18882 for rsvp-outgoing; Mon, 10 Apr 2000 06:01:10 -0700 (PDT) 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 GAA18877 for ; Mon, 10 Apr 2000 06:01:09 -0700 (PDT) Received: from griffin.host4u.net (griffin.host4u.net [209.150.128.163]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28069 for ; Mon, 10 Apr 2000 06:01:27 -0700 (PDT) Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id IAA32103; Mon, 10 Apr 2000 08:01:23 -0500 Message-Id: <4.3.1.2.20000410084156.00b60510@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Apr 2000 09:02:00 -0400 To: Sameer Shah From: Lou Berger Subject: Re: question regarding Message Id extension in draft-ietf-rsvp-refresh-reduct-03.txt Cc: rsvp@ISI.EDU In-Reply-To: <38ECB612.1EB0E312@globespan.net> References: <200003131956.TAA04675@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Sameer, This is a reasonable alternative to what the draft describes. I wouldn't want to use this alternative as the current approach (using the "Unknown Object Class" error) is the normal way, per rfc2205. to add functionality and detect when such new functionality isn't supported. The use of flags field for the RRC bit was necessitated by the scope of the extensions and the addition of new message types. Given the above, stage of the draft (it's been reviewed in numerous WG sessions and completed last call on 4/5) and apparent lack of support for your requested change, I don't think we should make this change. Lou At 12:06 PM 4/6/00 -0400, Sameer Shah wrote: >Hi, > >The draft says that the Refresh Reduction capable bit will be set in >messages >received from a node, if the node supports all the extensions suggested >in >the draft. But a node that supports reliable RSVP message delivery but >not >Bundle and refresh messages, will not set the Refresh-Reduction-Capable >bit. >This means that neighbor nodes ought to dynamically discover whether >this >node supports only the Message Id extension, from messages received from >this >node. If the messages contain a Message Id object or a Message Id Ack >object, >then this node supports Message Id extensions. Or if they receive an >error >message from the node specifying unknown object for the Message Id >object, then >it does not support Message Id extensions. > >Would it not be more efficient to provide a bit in the flags field of >the common >RSVP header to indicate that a node supports only the Message Id >extensions, >similar to the RR capable bit, instead of using other mechanisms to >discover this. > >Regards, >Sameer From rsvp-owner@ISI.EDU Mon Apr 10 11:16:00 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16893 for ; Mon, 10 Apr 2000 11:15:59 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA18908 for rsvp-outgoing; Mon, 10 Apr 2000 06:01:42 -0700 (PDT) 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 GAA18903 for ; Mon, 10 Apr 2000 06:01:41 -0700 (PDT) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA28077 for ; Mon, 10 Apr 2000 06:01:59 -0700 (PDT) Received: from sernt13.essex.ac.uk ([155.245.240.182]) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 12edpE-0002rB-00 for rsvp@ISI.EDU; Mon, 10 Apr 2000 14:01:56 +0100 Received: from csres11.essex.ac.uk ([155.245.163.111]) by sernt13.essex.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 23KYBV7V; Mon, 10 Apr 2000 14:01:56 +0100 From: K Sun Reply-To: ksun@essex.ac.uk To: rsvp@ISI.EDU Subject: What is "E2E"? In-Reply-To: <200004051629.QAA01797@gra.isi.edu> Message-ID: Date: Mon, 10 Apr 2000 14:01:51 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, I have a question. In "draft-ietf-issll-rsvp-aggr-02.txt", "E2E RSVP Message" has been mentioned. I do not know what "E2E" means. Anybody may help me? Many thanks, Sun Kai From rsvp-owner@ISI.EDU Mon Apr 10 13:29: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 NAA26387 for ; Mon, 10 Apr 2000 13:29:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA26353 for rsvp-outgoing; Mon, 10 Apr 2000 08:21:42 -0700 (PDT) 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 IAA26348 for ; Mon, 10 Apr 2000 08:21:40 -0700 (PDT) Received: from qos.isi.edu (dsl-berson.isi.edu [128.9.16.247]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14390 for ; Mon, 10 Apr 2000 08:21:59 -0700 (PDT) From: Steven Berson Received: from localhost (berson@localhost) by qos.isi.edu (8.9.3/8.9.3) with ESMTP id IAA13323; Mon, 10 Apr 2000 08:21:51 -0700 X-Authentication-Warning: qos.isi.edu: berson owned process doing -bs Date: Mon, 10 Apr 2000 08:21:51 -0700 (PDT) To: K Sun cc: rsvp@ISI.EDU Subject: Re: What is "E2E"? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk On Mon, 10 Apr 2000, K Sun wrote: > I have a question. > In "draft-ietf-issll-rsvp-aggr-02.txt", "E2E RSVP Message" has been > mentioned. I do not know what "E2E" means. Anybody may help me? E2E = end-to-end Regards, Steve From rsvp-owner@ISI.EDU Mon Apr 10 14:31:05 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 OAA29236 for ; Mon, 10 Apr 2000 14:31:02 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA00464 for rsvp-outgoing; Mon, 10 Apr 2000 09:36:37 -0700 (PDT) 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 JAA00455 for ; Mon, 10 Apr 2000 09:36:35 -0700 (PDT) Received: from pup.isi.edu (pup.isi.edu [128.9.160.228]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id JAA11217; Mon, 10 Apr 2000 09:36:49 -0700 (PDT) Message-Id: <200004101636.JAA11217@boreas.isi.edu> To: Bora Akyol cc: David Charlap , rsvp@ISI.EDU Reply-To: lindell@ISI.EDU Subject: Re: Question about integrity In-Reply-To: Message from Bora Akyol of "Fri, 07 Apr 2000 17:30:53 PDT." <38EE7DBD.11122FB7@pluris.com> Date: Mon, 10 Apr 2000 09:36:49 -0700 From: Bob Lindell Sender: owner-rsvp@ISI.EDU Precedence: bulk First, let me correct my previous email message. The word "sender" under points (1) and (2) below should really say "receiver". Receivers protect themselves on accepting the messages they process. Senders are likely to know apriori whether receivers support integrity, but they are unlikely to keep state on whether a receiver has issued a challenge to them as part of a handshake. Now on to the real discussion... First, I think it important to differentiate the concepts of end to end RSVP signalling and the use of the optional hop by hop integrity. RSVP signalling is an end to end signalling between hosts in the Internet. Hosts should expect to be notified of errors when RSVP signalling does not complete successfully along the end to end path. The integrity option, by definition, is hop by hop. There is no expectation by hosts that an integrity option is required along an entire path. The lack of use of the integrity option over portions of a path is not an error, but is dictated by engineering decisions. Adminstrative domains will independently implement security solutions for RSVP signalling. Some may choose to use the RSVP hop by hop integrity option between routers in their domain and with peering routers from other domains. Others may only use it for peering with other domains and may use "secured" links internally, thus not requiring the interior usage of the integrity option. In the end, hosts expect to achieve end to end signalling, be able to request QoS, and be billed only for the resources they have requested. An example may be useful here. Let us say I have two remote campuses which are connected by commercial providers to the Internet. End hosts within these campuses routinely make RSVP QoS requests to the Internet for resources on paths from one campus to the other. I run my own campus networks and I trust the infrastructure. I do not configure the usage of the integrity option between end hosts and routers in my networks. At the peering points between my campuses and the Internet providers I do use integrity because the provider requires it's usage. The provider uses integrity mainly as a protective measure for billing purposes. Combined with policy, the provider will bill me for all RSVP related services which appear to be coming from my routers (using my key(s)). I have no idea how my RSVP signalling requests are protected in the Internet, nor do I care. I do care that I can signal end to end, obtain resources, and be billed correctly for the services I use. Back to the original questions... First, should a receiver process a message that carries an integrity option but it does not implement integrity? I still believe the answer is yes. If a receiver does not need the integrity support to trust the message it receives, it should process the message. Second, is the integrity option geared towards backbone type network where authentication and correctness really are important? I say the answer is a definite yes! This is what I tried to say correctly in my previous response, but didn't get it exactly right. In a backbone environment, you protect yourself and trust no one. Of course, that isn't exactly true, but you must trust your peering domains routing advertisements to some extent if you want to get useful work done. But you probably have an extensive set of filters to reject what you believe may be incorrect. In a backbone, I am likely to require all my peers to secure their RSVP signalling packets with the integrity option to protect my network. My border routers will be ruthless and not accept RSVP messages that are not correctly keyed. But inside my domain, I may see no use to carrying the integrity option between my own routers. Bob Lindell > I would think that if you cared enough to insert an INTEGRITY object, then if > the node does not support it, it should respond with an error saying > "INTEGRITY not supported". Note that my answer is biased towards use of RSVP > in a backbone type network where authentication and correctness really are > important and the operator is likely to have knowledge that all of his nodes > will support a given capability. > > Bora > > ps. Of course we can build in capability negotiation to RSVP :-) > > Bob Lindell wrote: > > > > 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. > > > > I also think it should go ahead and process the message. > > > > If the sender was really concerned about security, it would make sure > > the next hop supported integrity. There are 2 basic cases I can think > > of at the moment. > > > > 1) A sender would require that the replay protection handshake > > complete successfully. By definition the next hop supports > > integrity. > > > > 2) A sender does not handshake over a point to point link > > that is assumed to be secure from replay attacks. It is > > likely in this case that the sender has apriori knowledge > > that the peer supports integrity as part of a peering > > agreement. > > > > Bob Lindell > From rsvp-owner@ISI.EDU Mon Apr 10 20: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 UAA07330 for ; Mon, 10 Apr 2000 20:12:02 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA18005 for rsvp-outgoing; Mon, 10 Apr 2000 15:05:27 -0700 (PDT) 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 PAA17997 for ; Mon, 10 Apr 2000 15:05:25 -0700 (PDT) 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 PAA00556 for ; Mon, 10 Apr 2000 15:05:43 -0700 (PDT) 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 2VCG36TF; Mon, 10 Apr 2000 18:02:47 -0400 Message-ID: <38F25169.5663109B@globespan.net> Date: Mon, 10 Apr 2000 18:10:49 -0400 From: Sameer Shah Organization: Globespan Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: rsvp@ISI.EDU Subject: more comments/suggestions on draft-ietf-rsvp-refresh-reduct-03.txt References: <200003131956.TAA04675@gra.isi.edu> <4.3.1.2.20000410084156.00b60510@mail.labn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi Lou and RSVP drafts authors, Guess its bit late in the IETF process, but have additional comments/ suggestions regarding the Refresh Reduction draft in addition to the question raised earlier and have one question regarding the RSVP-TE extensions to MPLS. This is a longer mail. Related to Refresh Reduction Extensions: 1) Message Id on a per flow descriptor basis in the Resv message - Currently there is a single Message Id on a per Resv message. So this represents the state for all the flow descriptors in the flow descriptor list. This is a problem when you have multiple flow descriptors in the list. If the state for any one of the flow descriptor changes e.g. the label value changes in a specific flow descriptor, this would result in incrementing the Message Id for the Resv message, and the receiver would have to fully process the Resv message, including those flow descriptors that did not change. Or if a new flow descriptor was added to the list, the Message Id would have to be incremented. When the number of receivers are many e.g. in a multicast session, this would lead to redundant processing at the PHop node. I think we should have a Message Id on a per flow descriptor basis similar to the flowspec (for fixed filter), label and record route objects (as in MPLS extensions to RSVP). 2) Preserving Soft State with Srefresh message usage - Two mechanisms are suggested in the draft to preserve RSVP's soft state error recovery mechanism. In the first mechanism a node maintains a checksum, and when it changes, a full refresh is sent. The draft should clarify that if such an event happens, it should be treated as a trigger and the new message should be sent with an incremented Mesage Id. If you do not increment the Message Id, then as per Section 4.5 the next hop will treat the message as a refresh and do only the refresh processing. The other mechanism to avoid state corruption suggests the sending of periodic standard Path and Resv refresh messages and the period value must be longer than the Srefresh interval. In this case too, when the full message is sent, it should be sent with an incremented Message Id, otherwise the next hop may just do the refresh processing. (Though the difference between fully processing a message and refresh processing of a message may be implementation specific, a node may implement refresh processing by simply updating the internal time- to-die values and not looking at any of the other objects). 3) Preserving soft state when using only the Message Id extensions - This issue is similar to the earlier one but applies when the node supports only the reliability extensions and does not support the Bundling and other Refresh Reduction capabilities. As per processing mentioned in Section 4.5 a node that receives the same Message Id for a state may only do the refresh processing and not the full processing. If we apply the definition of refresh processing as defined above, then we again have the problem of soft state corruption. This also should be addressed by sending an incremented Message Id, from time to time so that the next hop node may perform full processing of the message. 4) Aggregating Message Ids in the same Srefresh message - Section 5.3 describes the usage of SRefresh message. Specifically "When the outgoing interface is a point-to-point link, all Path state associated with sessions advertised out the interface SHOULD be included in the same Srefresh message. When the outgoing interface is not a point-to-point link, all unicast session Path state SHOULD be included in the same Srefresh message." and the next paragraph reads "Identifying which Resv state may be refreshed within a single Srefresh message is based simply on the source and destination IP addresses. Any state that was previously advertised in Resv messages with the same IP addresses as an Srefresh message MAY be included." I have a doubt regarding the use of the words SHOULD and MAY in these paragraphs. For Path messages we are saying that all possible sessions SHOULD be included in the Srefresh, but for Resv messages we are saying that all those sessions MAY be included. Should we restrict how nodes implement aggregation of the Message Ids in a Srefresh message ? In the case of Path messages also, we may not want to aggregate all the Message Ids together in order to prevent incurring huge processing during smaller time intervals, if there are many sessions going through the same next hop. 5) Question on bundling Path messages when the next hop is not destination - Section 3.3 describes various scenarios where Path messages could be bundled. They can be bundled when the outgoing link is point-to-point. But if the outgoing link is not point-to-point, does the following statement imply a restriction "It also includes Path and PathTear messages when the next hop is known to be the destination and changes in next hops can be detected." For unicast sessions, if the outgoing link is of type broadcast (e.g. Ethernet) should we still bundle Path messages only if the next hop is the destination. Why cannot we bundle Path messages to a directly connected RSVP next hop eventhough it is not the destination, if it is possible to detect changes in routing. Related to RSVP-TE Extensions to MPLS 6) What is the interpretation of the Resv Confirm object in draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. Should a node generate a Resv Confirm message if it was able to allocate resources for the LSP or should Resv Confirm messages be only generated by the ingress node when the end-to-end LSP is setup on receiving a Resv message. If the latter makes more sense, then there is a problem according to the Resv Message format described in section 3.2. This allows a single Resv Confirm object in a Resv message, but in the MPLS case we have a requirement of multiple Resv Confirm objects (maybe on a per flow descriptor basis). Sameer -- Sameer Shah GlobeSpan Inc. Email: sshah@globespan.net Web: www.globespan.net From rsvp-owner@ISI.EDU Tue Apr 11 06:25:05 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 GAA27149 for ; Tue, 11 Apr 2000 06:25:04 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA14072 for rsvp-outgoing; Tue, 11 Apr 2000 00:37:03 -0700 (PDT) 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 AAA14066 for ; Tue, 11 Apr 2000 00:37:02 -0700 (PDT) Received: from relay03.netaddress.usa.net (relay03.netaddress.usa.net [204.68.24.183]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id AAA11592 for ; Tue, 11 Apr 2000 00:37:20 -0700 (PDT) Received: (qmail 11709 invoked by uid 0); 10 Apr 2000 00:00:19 -0000 Received: (qmail 19577 invoked from network); 6 Apr 2000 21:21:10 -0000 Received: from apps01.netaddress.usa.net (204.68.24.172) by outbound.netaddress.usa.net with SMTP; 6 Apr 2000 21:21:10 -0000 Received: (qmail 27840 invoked by uid 0); 6 Apr 2000 21:20:40 -0000 Received: from power.atlantis.it by apps01 with [Collected by] USA.NET Rover (vM3.3.0.56) for marcoscotti@usa.net with ESMTP id 458eDFVul2361R01; Thu, 06 Apr 2000 21:20:37 GMT Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by power.atlantis.it (8.9.3/8.9.3) with ESMTP id WAA10090 for ; Fri, 21 Jan 2000 22:23:23 +0100 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24363; Fri, 21 Jan 2000 14:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24326 for ; Fri, 21 Jan 2000 14:52:03 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16338 for ; Fri, 21 Jan 2000 14:53:13 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id UAA04618; Fri, 21 Jan 2000 20:53:09 +0100 (MET) Message-Id: <200001211953.UAA04618@malmo.trab.se> From: "Istvan Cselenyi" To: RSVP , diffserv , end2end-interest@ISI.EDU Date: Fri, 21 Jan 2000 20:53:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: Istvan.I.Cselenyi@telia.se CC: Ping Pan Priority: normal In-reply-to: <38848D85.86BB640A@hursley.ibm.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Subject: [Diffserv] QoSSIG BOF X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Status: RO Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7BIT Reading Ping's and earlier threads [1-3] and works [4-11] it seems that there are many people who want to contribute to the future of signaled QoS, but there is no IETF charter for aggregating all these good (not best :-) efforts since * the DS WG excludes new signaling by (re)definition * the MPLS WG deals with QoS routing and TE which are different * the ISSLL WG doesn't really suit to DS * the RSVP WG is closing done Shall we start with a BOF in Adelaide? /Istvan ------------------------------ Links [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html [4] http://icawww1.epfl.ch/srp/ [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated Reservation in the Internet, Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight Resource Reservation for Unicast IP Traffic", International WS on QoS'98, IWQoS'98, May 18-20, 1998 [8] http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt [9] http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-00.txt [10] http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt [11] http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From rsvp-owner@ISI.EDU Tue Apr 11 07:11: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 HAA28732 for ; Tue, 11 Apr 2000 07:11:29 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA17843 for rsvp-outgoing; Tue, 11 Apr 2000 01:46:14 -0700 (PDT) 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 BAA17837 for ; Tue, 11 Apr 2000 01:46:13 -0700 (PDT) Received: from relay03.netaddress.usa.net (relay03.netaddress.usa.net [204.68.24.183]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id BAA17916 for ; Tue, 11 Apr 2000 01:46:31 -0700 (PDT) Received: (qmail 16093 invoked by uid 0); 10 Apr 2000 00:14:01 -0000 Received: (qmail 5461 invoked from network); 6 Apr 2000 20:40:02 -0000 Received: from apps03.netaddress.usa.net (204.68.24.176) by outbound.netaddress.usa.net with SMTP; 6 Apr 2000 20:40:02 -0000 Received: (qmail 4669 invoked by uid 0); 6 Apr 2000 20:31:12 -0000 Received: from power.atlantis.it by apps03.netaddress.usa.net with [Collected by] USA.NET Rover (vM3.3.0.56) for marcoscotti@usa.net with ESMTP id 744eDFuER2399R03; Thu, 06 Apr 2000 20:30:17 GMT Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by atlantis.it (8.8.7/8.8.5) with ESMTP id VAA09086 for ; Thu, 18 Nov 1999 21:09:40 +0100 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11247; Thu, 18 Nov 1999 12:38:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11217 for ; Thu, 18 Nov 1999 12:38:04 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21997 for ; Thu, 18 Nov 1999 12:38:19 -0500 (EST) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA18593 for ; Thu, 18 Nov 1999 09:38:14 -0800 (PST) Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Thu, 18 Nov 1999 09:38:04 -0800 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 18 Nov 1999 12:37:08 -0500 From: "Albert Manfredi" To: "Yoram Bernet \(Exchange\)" Cc: , Subject: RE: [Diffserv] RSVP vs DiffServ Date: Thu, 18 Nov 1999 12:38:00 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <078292D50C98D2118D090008C7E9C6A6073D0951@STAY.platinum.corp.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: 7bit X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Status: RO Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Yoram Bernet wrote: > Albert Manfredi wrote: > > My description would be that RSVP is thought by some > not to "scale > > well" in very large networks, > > RSVP is just a signaling protocol. It is traditionally > associated with > Intserv and with per-flow trafic handling mechanisms. The > scalability > concerns are really with the per-flow trafic handling > mechansism more than > with the signaling per-se. > > and that therefore diffserv is being > > developed to provide QoS within the network core. RSVP > is instead > > used at the edges, > > Let's look at this a little further. What do we mean when > we say "RSVP is > used at the edges". RSVP is an end-to-end signaling > protocol, so - RSVP > travels through every device on the end-to-end path > through the network. Yes, but it doesn't operate to provide QoS knobs within the diffserv domain. As was proposed in one of the diffserv drafts at the recent IETF meeting, it's possible to use RSVP as an admission control protocol at the diffserv edge. Or other means could be used instead. > The > question is - who listens to RSVP? Typically, we would > expect devices to > listen to RSVP if they are serving as ingress points to > valuable or > congested regions of the network. An example is the > ingress router to a > diffserv network (at the edge). Another example might be > a router serving a > WAN connection. The fact that certain devices listen to > RSVP does not > necessarily mean that they apply per-flow traffic > handling. But, to summarize, a diffserv core router does not listen to RSVP. Not unless we really change the diffserv charter. > RSVP is used end-to-end. > Aggregate traffic handling (a.k.a. diffserv) AND per hop behaviors vs per microflow reservations (the latter being the RSVP and ATM approach to guaranteeing QoS) are used within the diffserv core. Next thing you know, this discussion will be moved to diffserv-interest. Bert manfredi@arl.bna.boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From rsvp-owner@ISI.EDU Tue Apr 11 10:56:58 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07535 for ; Tue, 11 Apr 2000 10:56:57 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA28442 for rsvp-outgoing; Tue, 11 Apr 2000 05:55:31 -0700 (PDT) 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 FAA28437 for ; Tue, 11 Apr 2000 05:55:30 -0700 (PDT) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA09988 for ; Tue, 11 Apr 2000 05:55:48 -0700 (PDT) Received: from sernt13.essex.ac.uk ([155.245.240.182]) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 12f0Cp-0006gc-00 for rsvp@ISI.EDU; Tue, 11 Apr 2000 13:55:47 +0100 Received: from csres11.essex.ac.uk ([155.245.163.111]) by sernt13.essex.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 23KYB6LL; Tue, 11 Apr 2000 13:55:46 +0100 From: K Sun Reply-To: ksun@essex.ac.uk To: rsvp@ISI.EDU Subject: Re: What is "E2E"? In-Reply-To: Message-ID: Date: Tue, 11 Apr 2000 13:47:08 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, Thank you for your helps! Best Regards, Sun Kai From rsvp-owner@ISI.EDU Tue Apr 11 17:59: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 RAA22839 for ; Tue, 11 Apr 2000 17:59:50 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA26150 for rsvp-outgoing; Tue, 11 Apr 2000 13:17:43 -0700 (PDT) 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 NAA26145 for ; Tue, 11 Apr 2000 13:17:43 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA06094; Tue, 11 Apr 2000 13:17:58 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA00870; Tue, 11 Apr 2000 20:17:57 GMT Date: Tue, 11 Apr 2000 20:17:57 GMT Message-Id: <200004112017.UAA00870@gra.isi.edu> To: sob@harvard.edu, mankin@ISI.EDU, braden@ISI.EDU Subject: Re: draft-ietf-rsvp-refresh-reduct-02.txt Cc: rsvp@ISI.EDU, lixia@cs.ucla.edu, lberger@labn.net X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> From rsvp-owner@ISI.EDU Mon Mar 13 11:59:46 2000 *> From: Bob Braden *> Date: Mon, 13 Mar 2000 19:56:35 GMT *> 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 *> Content-Length: 228 *> X-Lines: 9 *> *> *> 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 *> One nit that has yet to be picked: I believe that the RFC from this draft will *Update* RFC 2205. Bob From rsvp-owner@ISI.EDU Wed Apr 12 11:20:23 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 LAA24208 for ; Wed, 12 Apr 2000 11:20:22 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA05962 for rsvp-outgoing; Wed, 12 Apr 2000 05:37:37 -0700 (PDT) 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 FAA05957 for ; Wed, 12 Apr 2000 05:37:36 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA00796 for ; Wed, 12 Apr 2000 05:36:09 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 12 Apr 2000 18:15:40 +0530 Received: from Fresno.future.futsoft.com ([172.16.1.23]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA01282 for ; Wed, 12 Apr 2000 17:53:54 +0530 Received: by localhost with Microsoft MAPI; Wed, 12 Apr 2000 18:07:44 +0530 Message-Id: <01BFA4AA.0032FB80.arulvraj@future.futsoft.com> From: "S.Arul Vasantha Raj" To: "'rsvp@isi.edu'" Subject: RSVP on crossing Broadcast network segment. Date: Wed, 12 Apr 2000 18:07:43 +0530 Organization: HDF. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi RSVPians, To introduce self, I have recently jumped in the RSVP cloud to find some Reservation for myself. Started Implementing RSVP protocol for PSoS based Router at Chennai, India. I have a doubt., In Rsvp we have the mechanism to work with the Non Rsvp Cloud, We can know from TTL difference to conclude to Best effort traffic. But, if we have a broadcast technology based network Segment (Ex. CSMA/CD) in the route (Thick Ethernet Backbone) which is shared with few routers, How to deal with on reserving for a specific QoS (like Bandwidth). How will the next RSVP enabled routers know this kind of bandwidth sharing is in place. It may be said it is opaque to RSVP. O.K But still in the above scenario, even the best probability vanishes as unnoticed. The lower layer technology has no support (?) to reserve in a shared medium. I think atleast the information need to be taken over by RSVP. The same case can be related to Token Ring backbone too, If the QoS is requested with Minimum delay traffic. Holding of token will be out of control, where as the RSVP assumes that the requested QoS (Ex. Min Delay) is in place. I think, the intermediate routers or the receiver are need to be informed, like the same as the Non RSVP cloud existence. Comments on the above is most welcomed. If anything misunderstood, please correct me. Thanks and Regards, Arul. S.Arul Vasantha Raj, M.Tech. F S P.L, 280, Anna Salai, Nandanam, Chennai - 600035. Ph. +91-44-4330550 Extn. 412. Mail: arulvraj@future.futsoft.com (Official) arulvraj@usa.net (Personal) I deeply regret for bouncing of any mails if you reply from any free mail server accounts.(Hot mail/ usa.net etc.) A worst! narrow minded!! policy is in place in our server. In this case please use the second mail address. Thanks. From rsvp-owner@ISI.EDU Wed Apr 12 13:16: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 NAA28064 for ; Wed, 12 Apr 2000 13:16:15 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA13000 for rsvp-outgoing; Wed, 12 Apr 2000 08:17:03 -0700 (PDT) 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 IAA12994 for ; Wed, 12 Apr 2000 08:17:01 -0700 (PDT) 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 IAA17874 for ; Wed, 12 Apr 2000 08:17:20 -0700 (PDT) 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 LAA20711 for ; Wed, 12 Apr 2000 11:16:42 -0400 (EDT) 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 LAA19360 for ; Wed, 12 Apr 2000 11:16:44 -0400 (EDT) Message-ID: <38F49369.64956F3B@fore.com> Date: Wed, 12 Apr 2000 11:16:57 -0400 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: Re: RSVP on crossing Broadcast network segment. References: <01BFA4AA.0032FB80.arulvraj@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit "S.Arul Vasantha Raj" wrote: > > Hi RSVPians, > > To introduce self, I have recently jumped in the RSVP cloud to find > some Reservation for myself. Started Implementing RSVP protocol for > PSoS based Router at Chennai, India. > > I have a doubt., > In Rsvp we have the mechanism to work with the Non Rsvp Cloud, We can > know from TTL difference to conclude to Best effort traffic. But, if > we have a broadcast technology based network Segment (Ex. CSMA/CD) > in the route (Thick Ethernet Backbone) which is shared with few > routers, How to deal with on reserving for a specific QoS (like > Bandwidth). How will the next RSVP enabled routers know this kind of > bandwidth sharing is in place. You're right that there's no IP-layer mechanism to detect this, because TTL values are not affected by the medium the packet goes through. On the other hand, a router attached to a bradcast medium knows that it is, given its choice of interface. The only real decision the switch needs to make here is whether its broadcast (say, Ethernet) interface is connected point-to-point to another switch, or if it's connected to a segment with more than two nodes on it. I think the switch can learn this by snooping the interface for packets to/from unknown MAC addresses. Regardless of the mechanism used to detect a shared network segment, I think RSVP can signal this by setting appropriate break bits in the ADSPEC parameters. Note that it doesn't have to set them all - certain parameters (like MTU) can still be determined. > It may be said it is opaque to RSVP. O.K But still in the above > scenario, even the best probability vanishes as unnoticed. The lower > layer technology has no support (?) to reserve in a shared medium. I > think atleast the information need to be taken over by RSVP. You're right. There can be no reservations on a shared medium. Parameters like bandwidth and delay characteristics are meaningless on a non-switched network segment. Setting the break bits on those ADSPEC parameters should indicate to the receiver(s) and downstream routers that no end-to-end reservations can be made for those parameters. -- David From rsvp-owner@ISI.EDU Wed Apr 12 15:27:32 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01638 for ; Wed, 12 Apr 2000 15:27:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA20722 for rsvp-outgoing; Wed, 12 Apr 2000 10:47:43 -0700 (PDT) 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 KAA20717 for ; Wed, 12 Apr 2000 10:47:41 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA11188; Wed, 12 Apr 2000 10:47:51 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA01371; Wed, 12 Apr 2000 17:47:51 GMT Date: Wed, 12 Apr 2000 17:47:51 GMT Message-Id: <200004121747.RAA01371@gra.isi.edu> To: rsvp@ISI.EDU, arulvraj@future.futsoft.com Subject: Re: RSVP on crossing Broadcast network segment. X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk If RSVP is unable to establish a requested reservation on a particular interface because of the nature of the medium, it should set the Break Bit rather than sending a Resv Error message. Bob Braden From rsvp-owner@ISI.EDU Wed Apr 12 15:53: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 PAA02102 for ; Wed, 12 Apr 2000 15:53:11 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA21827 for rsvp-outgoing; Wed, 12 Apr 2000 11:08:23 -0700 (PDT) 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 LAA21822 for ; Wed, 12 Apr 2000 11:08:22 -0700 (PDT) Received: from frida.normandnet.fr (dnsserver.altitude.fr [195.7.102.1]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15698 for ; Wed, 12 Apr 2000 11:08:41 -0700 (PDT) Received: from AIVP-EG (195.7.97.35 [195.7.97.35]) by frida.normandnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 2RGPF07D; Wed, 12 Apr 2000 20:04:07 +0200 Message-Id: <3.0.6.32.20000412200803.009306a0@mail.normandnet.fr> X-Sender: promoconf@mail.normandnet.fr (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 12 Apr 2000 20:08:03 +0200 To: rsvp@ISI.EDU From: AIVP - Info Subject: 7th International Conference Cities & Ports Mime-Version: 1.0 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 LAA21823 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit 7th International Conference Cities & Ports 7e Conference Internationale Villes & Ports 6-9 november 2000 Marseille (France) ===== to rsvp@isi.edu Urban and port development authorities for coastal and river cities from throughout the entire world will be meeting in Marseilles (France), from the 6th to the 9th of November next, for the 7th Cities and Ports (IACP) International Conference. More than 500 delegates representing the port cities of more than 50 countries are expected in Marseilles to debate and exchange views regarding the implementation of sustainable development in port areas. This challenge is of interest to you ? This meeting concerns you ? We propose, without any committment on your behalf, to keep you informed free of charge of the programme development of this conference > by sending a message to : listegb.conference@aivp.net with SUBSCRIBE as subject (mailto:listegb.conference@aivp.net?subject=SUBSCRIBE) >or via our website http://www.aivp.com/7conf/formgb.asp ===== Les responsables du développement urbain et portuaire des villes maritimes et fluviales du monde entier se donnent rendez-vous à Marseille (France) du 6 au 9 novembre prochains pour la 7e Conférence Internationale des Villes et Ports organisée par l'Association Internationale Villes et Ports. (AIVP). Plus de 500 délégués représentants des villes portuaires de plus de 50 pays sont attendus à Marseille pour débattre et échanger leurs expériences autour de la mise en œuvre d'un développement durable des places portuaires. Cet enjeu vous intéresse ? Cette rencontre vous concerne? Nous vous proposons, sans aucun engagement de votre part, de vous tenir informé gratuitement de l'évolution du programme de cette conférence > en envoyant un message à : listefr.conference@aivp.net avec le mot SUBSCRIBE en objet (mailto:listefr.conference@aivp.net?subject=SUBSCRIBE) >ou par notre site web : http://www.aivp.com/7conf/form.asp From rsvp-owner@ISI.EDU Wed Apr 12 15:55:58 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02141 for ; Wed, 12 Apr 2000 15:55:55 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA22624 for rsvp-outgoing; Wed, 12 Apr 2000 11:16:04 -0700 (PDT) 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 LAA22619 for ; Wed, 12 Apr 2000 11:16:03 -0700 (PDT) Received: from svc11.hansol.co.kr ([210.112.11.242]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA16928 for ; Wed, 12 Apr 2000 11:16:22 -0700 (PDT) Received: (qmail 22897 invoked by uid 0); 12 Apr 2000 18:18:55 -0000 Date: Mon, 3 Apr 2000 08:07:57 -0700 From: Yoram Bernet To: Simon Oosthoek (EMN) , "'Bora Akyol'" , "'rsvp@isi.edu'" , issll@lmcs.mit.edu CC: Geert Heijenk (EMN) , Georgios Karagiannis (EMN) Subject: RE: RSVP on wireless IP Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F4195@STAY.platinum.corp.microsoft.com> MIME-Version: 1.0 X-Will-Complete: ok Content-Type: TEXT/PLAIN; CHARSET="iso-8859-1" Content-Transfer-Encoding: 7BIT Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7BIT I tend to view > -----Original Message----- > From: Simon Oosthoek (EMN) [mailto:Simon.Oosthoek@emn.ericsson.se] > Sent: Monday, April 03, 2000 1:10 AM > To: 'Bora Akyol'; 'rsvp@isi.edu' > Cc: Geert Heijenk (EMN); Georgios Karagiannis (EMN) > Subject: RE: RSVP on wireless IP > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: 01 April 2000 06:10 > > To: Simon Oosthoek (EMN); 'rsvp@isi.edu' > > Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) > > > > > > In a wireless environment, what kind of QoS are you planning > > on utilizing. > > Reserved bandwidth, or BER, or CIR type. > > I haven't looked at the details for QoS over wireless IP yet, > so I can't answer this. > > > Do you think that RSVP is a good match for a wireless > > environment when the > > channel varies rapidly? > > It rather depends on the technology used for the wireless > access method. I do believe the MAC layer should provide some > handles for QoS aware operation. > > > Do you think that RSVP will provide the necessary API so that > > you can use > > time-varying error-correcting codes based on BER? > > Is that something that should be taken care of in RSVP? > > > How are you planning on differentiation congestion loss from > > link layer > > corruption? > > Good question ;-) I think MAC layer awareness of QoS should > be able to help here. Or just knowing about MAC layer packetloss... > > > I guess what I am trying to say is that I don't think RSVP > meets the > > requirements for dynamic wireless channels, you may be much > better of > > proxying RSVP requests via an agent architecture > > that sits at the two end of the wireless connection. > > But that would mean that you have at least one hop without > QoS support in the RSVP connection. That could break the > entire QoS for that flow. The least you can do is try to > support QoS awareness in the wireless link, if it then fails > for any reason, then you call it static ;-) > > > Also you may want to bring this up in the PILC group. > > I think I know too little of this to make a useful > contribution yet, but I'll keep it in mind. > > Thanks for your comments, I'm looking forward to more > discussions on this subject, especially when I know more.... > > Cheers > > Simon > From rsvp-owner@ISI.EDU Wed Apr 12 15:59: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 PAA02186 for ; Wed, 12 Apr 2000 15:59:55 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA22642 for rsvp-outgoing; Wed, 12 Apr 2000 11:16:10 -0700 (PDT) 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 LAA22637 for ; Wed, 12 Apr 2000 11:16:09 -0700 (PDT) Received: from svc11.hansol.co.kr ([210.112.11.242]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA16936 for ; Wed, 12 Apr 2000 11:16:26 -0700 (PDT) Received: (qmail 22900 invoked by uid 0); 12 Apr 2000 18:18:56 -0000 Date: Mon, 3 Apr 2000 08:15:23 -0700 From: Yoram Bernet To: Simon Oosthoek (EMN) , "'Bora Akyol'" , "'rsvp@isi.edu'" , issll@lmcs.mit.edu CC: Geert Heijenk (EMN) , Georgios Karagiannis (EMN) Subject: RE: RSVP on wireless IP Message-ID: <078292D50C98D2118D090008C7E9C6A60C2F419A@STAY.platinum.corp.microsoft.com> MIME-Version: 1.0 X-Will-Complete: ok Content-Type: TEXT/PLAIN; CHARSET="iso-8859-1" Content-Transfer-Encoding: 7BIT Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7BIT I tend to view wireless as just another link layer over which QoS is necessary. RSVP is a signaling protocol that is used to request QoS on an end-to-end basis. It is intentionally, sufficiently abstract to support concatenated subnetworks of varying media. The ISSLL working group has defined mappings from RSVP (when it carries Intserv parameters) to various 'link layers' including 802, atm, slow wan, and most recently, diffserv. The current model as I see it, is that an RSVP request is generated by an end system, including a layer-3 abstraction of the QoS it needs. This request propagates along the traffic path, from sender to receiver (and the response in return). At various points, admission control 'agents' are responsible for reviewing the request and comparing it against the resources aailable in the part of the network for which they are responsible. This requires these agents to be able to map the abstract intserv parameters into the parameters appropriate for their specific media, and possibly to generate some link layer specific signaling. RSVP serves to unify the disparate QoS mechanisms of the different media. I think that wireless should be part of the same general model. I expect that the wireless 'base station' (or alternate admission conrtrol agent) would participate in the end-to-end RSVP signaling and would be able to map RSVP requests to its local QoS mechanisms. The SBM, defined by the ISSLL WG might be a good model for such participation. Regards, Yoram > -----Original Message----- > From: Simon Oosthoek (EMN) [mailto:Simon.Oosthoek@emn.ericsson.se] > Sent: Monday, April 03, 2000 1:10 AM > To: 'Bora Akyol'; 'rsvp@isi.edu' > Cc: Geert Heijenk (EMN); Georgios Karagiannis (EMN) > Subject: RE: RSVP on wireless IP > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: 01 April 2000 06:10 > > To: Simon Oosthoek (EMN); 'rsvp@isi.edu' > > Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x) > > > > > > In a wireless environment, what kind of QoS are you planning > > on utilizing. > > Reserved bandwidth, or BER, or CIR type. > > I haven't looked at the details for QoS over wireless IP yet, > so I can't answer this. > > > Do you think that RSVP is a good match for a wireless > > environment when the > > channel varies rapidly? > > It rather depends on the technology used for the wireless > access method. I do believe the MAC layer should provide some > handles for QoS aware operation. > > > Do you think that RSVP will provide the necessary API so that > > you can use > > time-varying error-correcting codes based on BER? > > Is that something that should be taken care of in RSVP? > > > How are you planning on differentiation congestion loss from > > link layer > > corruption? > > Good question ;-) I think MAC layer awareness of QoS should > be able to help here. Or just knowing about MAC layer packetloss... > > > I guess what I am trying to say is that I don't think RSVP > meets the > > requirements for dynamic wireless channels, you may be much > better of > > proxying RSVP requests via an agent architecture > > that sits at the two end of the wireless connection. > > But that would mean that you have at least one hop without > QoS support in the RSVP connection. That could break the > entire QoS for that flow. The least you can do is try to > support QoS awareness in the wireless link, if it then fails > for any reason, then you call it static ;-) > > > Also you may want to bring this up in the PILC group. > > I think I know too little of this to make a useful > contribution yet, but I'll keep it in mind. > > Thanks for your comments, I'm looking forward to more > discussions on this subject, especially when I know more.... > > Cheers > > Simon > From rsvp-owner@ISI.EDU Wed Apr 12 19:49: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 TAA05391 for ; Wed, 12 Apr 2000 19:49:24 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA12574 for rsvp-outgoing; Wed, 12 Apr 2000 15:17:44 -0700 (PDT) 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 PAA12568 for ; Wed, 12 Apr 2000 15:17:41 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA02016; Wed, 12 Apr 2000 15:17:59 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA01753; Wed, 12 Apr 2000 22:17:59 GMT Date: Wed, 12 Apr 2000 22:17:59 GMT Message-Id: <200004122217.WAA01753@gra.isi.edu> To: rsvp@ISI.EDU Subject: Minor glitch in Diagnostic spec (RFC 2745) Cc: braden@ISI.EDU, terzis@cs.ucla.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk The RSVP Diagnostic spec (RFC 2745) contains a minor typo. It refers to a TUNNEL object, which it says is defined in the RSVP Tunnel spec (RFC 2746). This is true, except this object is named SESSION_ASSOC in RFC 2746. Presumably this error will be corrected when the RSVP specs go to DRAFT. Bob Braden Andreas Terzis From rsvp-owner@ISI.EDU Thu Apr 13 10:13: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 KAA02690 for ; Thu, 13 Apr 2000 10:13:07 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA19123 for rsvp-outgoing; Thu, 13 Apr 2000 04:27:12 -0700 (PDT) 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 EAA19114 for ; Thu, 13 Apr 2000 04:27:08 -0700 (PDT) Received: from frida.normandnet.fr (dnsserver.altitude.fr [195.7.102.1]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA29407 for ; Thu, 13 Apr 2000 04:27:27 -0700 (PDT) Message-Id: <200004131127.EAA29407@tnt.isi.edu> Received: from AIVP-EG (195.7.97.35 [195.7.97.35]) by frida.normandnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 2RGPGMJP; Thu, 13 Apr 2000 12:53:53 +0200 Reply-To: infos@aivp.net From: "Infos - AIVP" To: aivp@ISI.EDU Subject: 7a Conferencia Internacional Ciudades y Puertos Date: Thu, 13 Apr 2000 12:15:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit 7a Conferencia Internacional Ciudades y Puertos 7th International Conference Cities & Ports 6-9 november 2000 Marseille (France) ===== Del 6 al 9 del próximo mes de noviembre, los responsables del desarrollo urbano y portuario de las ciudades marítimas y fluviales de todo el mundo se dan cita en Marsella (Francia) para la 7° Conferencia Internacional de las Ciudades y Puertos organizada por la Asociación Internacional Ciudades y Puertos. (AIVP). Se esperan en Marsella a más de 500 delegados representantes de las ciudades portuarias de más de 50 países para discutir e intercambiar sus experiencias sobre la puesta en marcha de un desarrollo sostenible de las plazas portuarias. ¿Le interesa este reto? ¿Le concierne este encuentro? Sin ningún compromiso de su parte, le proponemos mantenerle informado de forma gratuita sobre la evolución del programa de esta conferencia > enviando un mensaje a : listees.conference@aivp.net con la palabra SUBSCRIBE en el objeto del mensaje (mailto:listees.conference@aivp.net?subject=SUBSCRIBE) > via nuestro website http://www.aivp.com/7conf/formes.asp ===== Urban and port development authorities for coastal and river cities from throughout the entire world will be meeting in Marseilles (France), from the 6th to the 9th of November next, for the 7th Cities and Ports (IACP) International Conference. More than 500 delegates representing the port cities of more than 50 countries are expected in Marseilles to debate and exchange views regarding the implementation of sustainable development in port areas. This challenge is of interest to you ? This meeting concerns you ? We propose, without any committment on your behalf, to keep you informed free of charge of the programme development of this conference > by sending a message to : listegb.conference@aivp.net with SUBSCRIBE as subject (mailto:listegb.conference@aivp.net?subject=SUBSCRIBE) >or via our website http://www.aivp.com/7conf/formgb.asp From rsvp-owner@ISI.EDU Fri Apr 14 13:55:07 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 NAA11884 for ; Fri, 14 Apr 2000 13:55:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA26498 for rsvp-outgoing; Fri, 14 Apr 2000 08:58:50 -0700 (PDT) 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 IAA26493 for ; Fri, 14 Apr 2000 08:58:49 -0700 (PDT) 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 IAA29476 for ; Fri, 14 Apr 2000 08:59:08 -0700 (PDT) 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 LAA08738 for ; Fri, 14 Apr 2000 11:58:35 -0400 (EDT) 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 LAA02804 for ; Fri, 14 Apr 2000 11:58:38 -0400 (EDT) Message-ID: <38F74043.FDE52F5C@fore.com> Date: Fri, 14 Apr 2000 11:58:59 -0400 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: Optional Adspec objects Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit A discussion on the MPLS list (which has been resolved) leads me to ask another question. Since this question is RSVP-related and not MPLS-related, I'm posting it here instead of there. in RFC 2205, the BNF lists the Adspec as optional. However RFC 2210 says that it is required (in section 2.1). I have understood this to mean that an Adspec is optional only for hosts. A router receiving a Path without an Adspec must provide the missing Adspec for the next-hop router. On the other hand, neither RFC states this explicitly. So my question is: If a router receives a Path without an Adspec, what should the switch do? Should it generate Path messages with or without Adspecs? And if it should provide them, should it provide information for any service other than the general/default parameters? -- David From rsvp-owner@ISI.EDU Fri Apr 14 16:28: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 QAA13988 for ; Fri, 14 Apr 2000 16:28:35 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA03665 for rsvp-outgoing; Fri, 14 Apr 2000 11:52:58 -0700 (PDT) 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 LAA03660 for ; Fri, 14 Apr 2000 11:52:57 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA29450; Fri, 14 Apr 2000 11:53:14 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA02340; Fri, 14 Apr 2000 18:53:14 GMT Date: Fri, 14 Apr 2000 18:53:14 GMT Message-Id: <200004141853.SAA02340@gra.isi.edu> To: rsvp@ISI.EDU, dcharlap@fore.com Subject: Re: Optional Adspec objects X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> *> A discussion on the MPLS list (which has been resolved) leads me to ask *> another question. Since this question is RSVP-related and not *> MPLS-related, I'm posting it here instead of there. *> *> in RFC 2205, the BNF lists the Adspec as optional. However RFC 2210 *> says that it is required (in section 2.1). *> *> I have understood this to mean that an Adspec is optional only for *> hosts. A router receiving a Path without an Adspec must provide the *> missing Adspec for the next-hop router. *> *> On the other hand, neither RFC states this explicitly. *> *> So my question is: If a router receives a Path without an Adspec, what *> should the switch do? Should it generate Path messages with or without *> Adspecs? And if it should provide them, should it provide information *> for any service other than the general/default parameters? *> *> -- David *> I agree that there is a (small) RSVP protocol spec issue here. The Adspec was originally made optional before our Int-Serv cousins invented general path parameters. The RSVP WG thought that the Adspec would be omitted for any service that did not require advertising, like Controlled Load. But you give a protocol designer a sometimes-unused field, and he (and it was a "he" in this case) will invent new uses for it. So we made the Adspec optional, then we forgot about the implications of general path parameters and the statement in 2210. Maybe it should become required when 2205 goes to Draft; maybe not. On the other hand, the ambiguity really should not matter. If a Path message is received without an Adspec, the logical thing would seem to be to forward it without an Adspec (except the RSVP daemon in the sender host might supply a default Adspec when the application does not specify one.) "Be liberal in what you receive and conservative in what you send". Does this answer your question? Bob Braden From rsvp-owner@ISI.EDU Fri Apr 14 19:07:07 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 TAA15544 for ; Fri, 14 Apr 2000 19:07:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA10863 for rsvp-outgoing; Fri, 14 Apr 2000 14:38:49 -0700 (PDT) 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 OAA10858 for ; Fri, 14 Apr 2000 14:38:47 -0700 (PDT) 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 OAA24397 for ; Fri, 14 Apr 2000 14:39:07 -0700 (PDT) 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 RAA11438 for ; Fri, 14 Apr 2000 17:38:34 -0400 (EDT) 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 RAA10899 for ; Fri, 14 Apr 2000 17:38:38 -0400 (EDT) Message-ID: <38F78FF3.B7F481C3@fore.com> Date: Fri, 14 Apr 2000 17:38:59 -0400 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: Re: Optional Adspec objects References: <200004141853.SAA02340@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 > On the other hand, the ambiguity really should not matter. If a Path > message is received without an Adspec, the logical thing would seem to > be to forward it without an Adspec (except the RSVP daemon in the > sender host might supply a default Adspec when the application does > not specify one.) This is what I needed to know. To me, it seems equally logical to always provide an Adspec, even when one os not received. Of course, if you include GS or CL service blocks in it, you will be sending possibly-incorrect information about the sender's requirements. But I don't think it can hurt if an Adspec with only default/general characteristics is created. But not including one is definitely easier. If it is legal, that is what I'd rather do. > "Be liberal in what you receive and conservative in what you send". Ah, but this depends on what it means to be conservative in what's sent. Is it conservative to send an optional object when it is not required? -- David From rsvp-owner@ISI.EDU Sat Apr 22 07:07: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 HAA14818 for ; Sat, 22 Apr 2000 07:07:33 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id CAA16730 for rsvp-outgoing; Sat, 22 Apr 2000 02:22:56 -0700 (PDT) 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 CAA16725 for ; Sat, 22 Apr 2000 02:22:54 -0700 (PDT) Received: from gregdean (dsl-63-227-11-228.dnvr.uswest.net [63.227.11.228]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id CAA26335 for ; Sat, 22 Apr 2000 02:23:17 -0700 (PDT) Date: Sat, 22 Apr 2000 02:23:17 -0700 (PDT) From: discovery24@juno.com Message-Id: <200004220923.CAA26335@tnt.isi.edu> To: RSVP@ISI.EDU X-Mailer: 80A3811.47E0E202.60ed2c3bc9b1d88668b06e9b2c78f2f9 Subject: Forbidden Secrets!! Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a one time offer and will not be sent again, enjoy your secrets! 300 FREE pages and samples of marketing tips and secrets: Discover the hidden secrets to put your business in the top 3% of the business' on the internet in 90 days! Gauranteed to increase not just your traffic but your sales by 837% Learn what is hot and what is not in today's market! Learn ways to finance your current plans by using proven techniques, at no cost to you. Check it out today to change your tomorrow, go to: http://www.theinsidersecrets.com From rsvp-owner@ISI.EDU Sun Apr 23 02:40:21 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06799 for ; Sun, 23 Apr 2000 02:40:20 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id VAA24870 for rsvp-outgoing; Sat, 22 Apr 2000 21:24:28 -0700 (PDT) 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 VAA24864 for ; Sat, 22 Apr 2000 21:24:26 -0700 (PDT) Received: from mlist.netease.com ([202.106.168.72]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id VAA29928 for ; Sat, 22 Apr 2000 21:24:21 -0700 (PDT) Received: from fs (unknown [202.96.86.23]) by mlist.netease.com (Postfix) with ESMTP id 0A5DC553FC; Wed, 19 Apr 2000 18:56:53 +0800 (CST) From: "Network ProgrammerÍøÂç³ÌÐò¹¤³Ìʦ" Reply-To: netprogrammer@etang.com Subject: ºôµ¸¹q¤l°Ó°Èµ{§Ç To: userall@mlist.netease.com X-Mailer: V3,1,6,1 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 19 Apr 2000 18:22:06 +0800 Message-Id: <20000419105654.0A5DC553FC@mlist.netease.com> Sender: owner-rsvp@ISI.EDU Precedence: bulk ¡@¡@¤G¤Q¤@¥@¬ö´N¦b²´«e¤HÃþ­±Á{ªwªj¸gÀÙ¦M¾÷ªºµo­ý»P²£·~µo®iªº«Ì»Ù°ê»Ú¤¬³sºôµ¸ªº¿³°_,µS¦p´H©]ªF¤É¤§¦°¤é §ïÅܤF¥@¬É¥ø·~ªº¶Ç²Î¸gÀç¤è¦¡µ²¦X³Ð·~¡@²£«~¡@¸g¾P¡@ªA°È¡@¸êª÷ ¤­¤j²£·~­n¯À¤_¤@Åé ´£¨Ñ§Ú­Ì§¹¦¨¢±¢°¥@¬öªº¹Ú·Q¡B¥¼¨Ó»Pº@´º §Ú­Ìªº¥Í¬¡©M°Ó·~¡B¤u¹A·~¤è¦¡ ¦]¬°°ê»Ú¤¬³sºôµ¸ªº­±Á{µÛ¥¨¤jªº§ï­² ¼Æ½X®É¥N¡@¹q¤l®É¥N¡@±a¨Ó¤F¼Æ½X¹q¤l¸gÀÙ ¥¿¸ó¤J§Ú­Ì¤HÃþ¾ú¥vªº¶i¤Æ¹Lµ{ ·sªº¸gÀÙ·N¸q¡@·sªº®ø¶O¦æ¬°¡@·sªº°Ó·~¼Ò¦¡ ·sªº¦¨¥»»P§Q¼í¡K¡K¡K¡K ¤@¤Á³£¬O·sªº ¦b¼Æ½X¬ì§Þªº±Àªi§UÄi¤§¤U ¤@ªÑªÑµLªk§CÀɪº¹q¤l°Ó°È®ö¼éªï­±¦Ó¨Ó ¥¦±N¡@ÄAÂжDzΠ°ê»Ú¤¬³sºôµ¸µL½a°Ó¾÷ªº°ò¦¬O¯à°÷´£¨Ñµ¹«È¤á§óª½±µ¡B§ó§Ö±¶¡B§ó¦³®ÄªºªA°È§@·~¥­¥x¡C ¦b¤µ¦~¬O§Ú°ê¥ø·~¤Wºô¦~¡A±z¡B±zªº¥ø·~Ãø¹D¤£·Q±q¶Ç²Î¸gÀÙ¨«¦V¹q¤l¸gÀٶܡH ·Q¡A«Ü¦h·Q°µ¡A§A­Ì¦³«È¤á¡A¦³¸êª÷¡C¯Ê¤Öªº´N¬O¬°§A­Ì·f«Ø»P¹q¤l¤Æªº°Ó°È¥­¥x¡I¡I §Ú­Ì¤¤¤ß«H®§§Þ¥º¤p²Õ¡@¾Ö¦³¶¯«pªº¶}µo¹ê¤O¡A¦bºôµ¸¦U¬É¤u§@¦h¦~¡I §Ú­Ì¥i¥HÅý§A­Ì±q¶Ç²Î¸gÀÙ¹L´ç¨ì¹q¤l¸gÀÙ§ó¬°§Ö±¶¡B§ó¥[¸`¬Ù¸êª÷¡B§ó¬°¦³®Ä¡C §Ú­Ì¥i¥H¬°±zªº¤½¥q¶q¨­©w°µ¡A¦pªG±z¬O·d¤½¥qºôµ¸ªº§Þ¥º¤H­û¡A§Ú­Ì´£¨Ñ¹ï±z¦³À°§UªºªA°È¥­¥x §Ú­Ì´£¨Ñ¡G ºô¤WÁʪ«µ{§Ç¡]Ãþ¦ü¤_¢·¢·¢³¢·¡^ ¿ï©w³f¦Zµ²½ã¡A³fª«·j¯Á¡A¹Ï¤å¥\¯à¡A¦hºØ¬[ºc¡A¦hºØ¤ä¥I¤è®×¡A±j¤jªº¦Z¥xºÞ²z¨t²Î °Ó«~­q³æµ{§Ç Åý«È¤á«ö·Ó¦Û¤vªº·Nº@¶ñ¼g­q³æ¡A³f«~³W®æ¡A¥\¯à¡A¥æ³f¤é´Áµ¥µ¥¡A¨Ï¥ÎªÌ¥i¥H¥ô·N²K¨ä¥L¿ï¶µ¡D«È¤á¶ñ¼g§¹²¦¡A¥ß§Yµo°e¨ì¨Ï¥ÎªÌ¦Z¥x¾Þ§@¨t²Î¶}©l¾Þ§@¡D °Ó«~µP³º»ùµ{§Ç¡]Ãþ¦ü¤_©ö½ìºô¡^ ©ç½æµ{§Ç¡A¤£¥Î¦h»¡°Õ¡A«Ü¦h¥\¯à «È¤á¤ÏõXµ{§Ç «È¤á¹ï§Aªº²£«~¦³¦ó·N¨£¡A¦³¦ó°ÝÃD´£¥X¦Z¡A¤ÏõXµ¹¨Ï¥ÎªÌ¡A¨Ï¥ÎªÌµª´_¦Z¡A¤ÏõXµ¹«È¤á «È¤á¤¤¥¡ºÞ²zµ{§Ç ¶W¯Å±j¤jªº«È¤áºÞ²z¨t²Î¡A«È¤á¸ê®Æ¡AÁp¨t¤èªkµ¥µ¥¡D¤º¸mºôµ¸¼s§i«Å¶Çµ{§Çªº¯S§Oª©¥»¡A¥i¥H¦V«È¤áµo¥¬¶l¥ó¦Cªí«H®§ ºô¯¸¦Û°Ê§ó·sµ{§Ç ¤£·|°µºô­¶¡H³o¬O­Óµ¹¤£À´¨î§@ªº¤H¥Îªº¡A¥u­n¶ñ¼g«H®§¡A¦Û°Ê¥Í¦¨¤@­Óº¡·Nªº­¶­± ºôµ¸¼s§i«Å¶Çµ{§Ç ¶l¥ó¦Cªí¡A¤£¦Pªº¬O­º³Ð¤ä«ù¢ð¢ü¢õ¢ô¥\¯à¡DÁÙ¦³¡A¦bªA°È¾¹¤W¤@±Ò°Ê¡A¦Z¥x¦Û°Ê¹B¦æ¡Aµ¹§A¸`¬Ù¤Fºôµ¸¶O¥Î©M®É¶¡ ¹q¤l°Ó°È³fª«³øªíµ{§Ç §A¦bºô¤W½æ³B¤F¦h¤Ö³f«~¡A»ù®æ§r¡A¤°¤\ªº²Î²Î¬ö¿ý¡Aª½Æ[ªº¹Ïªí¤è¦¡Åã¥Ü¥X¨Ó¡AÅý§A¤F¸Ñ§Aªº®Ä¯q «È¤áªA°È½×¾Âµ{§Ç¡]Ãþ¦üºô©öµêÀÀªÀ°Ï¡^ ½×¾Â¡A°Q½×ªF¦è¡A¥Î¤áºÞ²z¡A¦hºØ¤ÀÃþ¡A¯Å§O¡K¡K ºô¯¸°ª¯ÅºûÅ@¨t²Î¡@¡]Ãþ¦ü¦Ê¯Sºô¡^ ³o¬O¤@­Ó¥þ¥\¯àºô¯¸¦Û°Ê¥Í¦¨¨t²Î¡A¦Û°Ê¥Í¦¨¨C¤@²Ó·L³¡¤À ·s»Dµ{§Ç ·s»D²K¥[µ{§Ç¡A§A¬O·s»Dºô¡A¨C¤ÑÁcº¾ªº·s»D²K¥[¡A¤£¬O²ÖÃa¤F§A¡C¥b¤Ñ²K¥[§¹²¦ªº·s»D¡A¥Î³o­Ó«¢«¢¡A¥b­Ó¤p®É´N·d©w¡A­¶­±¬¡°Ê¦Û¦p¡I¡I ºô¯¸³X°Ý¸Ô²Ó¬ö¿ý¡Ï³øªíµ{§Ç ¦h¤Ö¤H³X°Ý¡A¤°¤\®É­Ô¡A¤°¤\ÂsÄý¾¹¡A¤°¤\¨t²Î¡AIP¡@¨º­Ó¦a¤è ²á¤Ñµ{§Ç¡]Server Push¡W¸gÅç­È..¡^ ¤ñETHCHATÁÙ­n±j¤j¡C¡I¡I¡I ¼s§i¥I¶O¨t²Î ¨ã¦³±j¤jªºWebºÞ²z¥\¯à:¥Î¤á¥Ó½Ð¦Z,¥i¦b½u¬°¥Î¤á¶}³q¡K¡K ¥æ¤Í¨t²Î ¤ä«ù¦h¥Î¤á. 2 ¥Ó½ÐEMAIL¦^´_¥\¯à. 3 ¤ä«ù¥Î¤á­×§ï. 4 ¤ä«ù¥Î¤á¤Uªº¤Í±¡µn³°¥Î¤áªº­×§ï. 5 ¤ä«ù¥Î¤á±K½X§Ñ°O¦^´_. 6 ¤ä«ù¥Î¤á¤Uªº¤Í±¡µn³°¥Î¤á±K½X§Ñ°O¦^´_. 7 ¤ä«ù¶W¯Å¥Î¤á­×§ï§R°£©Ò¦³¥Î¤á. 8 ¤ä«ù¥Î¤á­×§ï§R°£©Ò¦³¥Î¤á. 9 ¤ä«ù¦Û°Ê¤À­¶.¡K¡K¡K¡K¡K¡K ±j¤jªº·j¯Á¤ÞÀº¨t²Î ³n¥ó¤U¸ü ¤U¸ü±Æ¦W¡@¦¸¼Æ¡@µ¥µ¥ ¼s§i¥æ´«µ{§Ç X:X¡@³o¨Ç¨t²Î µêÀÀ°ì¦Wµ{§Ç *.yeah.net ³o¼Ë§K¶O°ì¦WªA°È ¶W¯Å¤Í±¡³s±µµ{§Ç ¡@ ¦h¥\¯à¯d¨¥ªO¡]¦h¥Î¤á¡^ ¡@ WEBMAIL§K¶O¶l¥ó¨t²Î ·Q163.NET¤@¼Ë ¶W¯Å§ë²¼½Õ¬d¨t²Î¡]¦h¥Î¤á¡A¦h¿ï¾Ü¤è®×¡^ ¥\¯à¦h¦h Perl2exe¡@½sĶ¯}¸ÑªR¨t²Î ¥i¥H¯}ĶETCHAT ½sĶª©¥»§r¡C«Ü±jªº¡A¦Ó¥B¶W¯Å«K©y¡A¤£·Q¥Î¢¸¢¸¢¸¤¸¥hÁʶRETCAHT¡A´N¥Î111¤¸ÁʶR³o­Ó§a¡I¥i¥H§â·½¥N½X©Mª`¸Ñ³£Åã¥Ü¡C ¦h¥\¯à¶W¯Å¶P¥d¨t²Î ¥þ°ê³Ì±j µL¼Ä§ðÀ»µ{§Ç ¥i¥H§ðÀ»¤j³¡¤À¯¸ÂI¾É­PÅõºÈ¡A³t«×·¥§Ö¡A¥u»Ý­n¢²¤ÀÄÁ¡Aºô©öclub.netease.com³£³»¤£¤F´N·í¤F ÁÙ¦³«Ü¦h«Ü¦h¡K¡K ¦pªG±zÁÙ¦³¤°¤\»Ý­n¥i¥H§i¶D§Ú¡A§Ú¥i¥HÀ°§A¶q¨­©w°µ¡C ¦pªG±z·QÁʶR©ÎªÌ·Q¦¨¬°§Úªº¥N²z¡A½Ð¥Î¹q¤l¶l¥ó»P§ÚÁpµ¸ netprogrammer@etang.com netprogrammer@163.net ³o¨Çµ{§Ç«D±`«K©y¡A§Úªº·N¹Ï¬O·G»ù¦h¾P¡A¦U¦ì½æµ{§Çªº¥i¤d¸U¤£­n©Ç§Ú¡I¤ñ¦pºô¤WÁʪ«¨t²Î¡A­Ó¤H¥u°â350¤¸¡A¤Z¬O«e¢±¢¯¦WÁʶRªÌ³£¦³ÃØ°eºôµ¸¼s§i«Å¶Çµ{§Ç¡]»ù­È¢¸¢¯¤¸¡^§Úªº³o­Ó¶l¥ó´N¬O¥Î¥¦µoªíªº¡A«D±`¬Ù¿ú ¡I¦hÁʦhÀu´f¡I¡I §A·Q­n¨ä¥Lµ{§Ç¶Ü¡H¤ñ¦pUBBª`¥Uª©¥»µ¥µ¥,§A­n¤°¤\§Ú°ò¥»³£¦³¡A§i¶D§Ú¡A§Ú¤@©w¥Î¤ñ¥L­Ì«K©y¦n¤L­¿ªº»ù®æ¥X°âµ¹§A¡C¡@Áʪ«¶W¹L1500¤¸¥H¤WªºÃØ°e ³o¨Çµ{§Ç ªº¤@­Ó¡@ ¦pªG§A¤£·Q¦A±µ¨ì¸Ó¶l¥ó,½Ð¨ì¦¹³B http://202.96.86.39/asdf/index.html ¥»¤H¥u¨D¢°¥÷¥þ¾©ÎªÌ­Ý¾¤u§@¡C¥»¤H¦³¸û¦h®É¶¡¥h½s¼gµ{§Ç¡C¥D­n¦b¤j³°¡I ¥»¤H½sµ{±Nªñ4¦~¡A¢Ñ¢Õ¢×¨â¦~¡C ºë³q¢Ñ¢Õ¢×ºôµ¸µ{§Ç½s¼g ºë³q¡GCGI(Perl/C)/PHP/VB/VC/HTML/JS µ{§Ç»y¨¥ MySQL/Apache/Send mail/DNS/FTPµ¥ªA°È¾¹|Linux/HP UNIX/NT Workstation/Windows 9x ¾Þ§@¨t²Î CorelDraw Photoshop µ¥¹Ï§Î³]­p³n¥ó|¼ô±x¡GFlash Dreamware µ¥µ{§Ç ¹ï¤_ºôµ¸¦w¥þ¤F¸Ñ¸û¦h¡A©M«Ø¥ß«Ø¥ß¨¾¤õÀð¡A¹ï¤_¨¾¤õÀð§Þ¥º·¥¬°¤F¸Ñ¡A±q³n¥ó¨ìµw¥ó¡A¯à°÷«Ø¥ßDOSªº¨¾±s±¹¬I ºÞ²z¦h®aµêÀÀ¥D¾÷¡C ¥»¤H¯à°÷¾\Ū­^¤å¡BÁú¤å§Þ¥º¸ê®Æ¡C¤¤¤å¡B¸f»y¡B­^»y¡]¯à°÷À´±o¤j³¡¤À­^¤å§Þ¥º¸ê®Æ¡^ ¦³«Ü¦h²£«~¥i¨ÑÅçµý¥»¤Hªº§Þ¥º¹ê¤O¡C §Æ±æ±z¯à°÷Âà¹F¡IÁÂÁ¡I ¥»¤H§Æ±æ¤u§@¬O¡Gºôµ¸µ{§Ç­û¡B¨t²ÎºûÅ@¡BºôºÞ¡K¡K¡]°¸º¸¥i¥H¨î§@¤@¨Ç¥D­¶¡^ ¡@¡@¤G¤Q¤@¥@¬ö´N¦b²´«e¤HÃþ­±Á{ªwªj¸gÀÙ¦M¾÷ªºµo­ý»P²£·~µo®iªº«Ì»Ù°ê»Ú¤¬³sºôµ¸ªº¿³°_,µS¦p´H©]ªF¤É¤§¦°¤é §ïÅܤF¥@¬É¥ø·~ªº¶Ç²Î¸gÀç¤è¦¡µ²¦X³Ð·~¡@²£«~¡@¸g¾P¡@ªA°È¡@¸êª÷ ¤­¤j²£·~­n¯À¤_¤@Åé ´£¨Ñ§Ú­Ì§¹¦¨¢±¢°¥@¬öªº¹Ú·Q¡B¥¼¨Ó»Pº@´º §Ú­Ìªº¥Í¬¡©M°Ó·~¡B¤u¹A·~¤è¦¡ ¦]¬°°ê»Ú¤¬³sºôµ¸ªº­±Á{µÛ¥¨¤jªº§ï­² ¼Æ½X®É¥N¡@¹q¤l®É¥N¡@±a¨Ó¤F¼Æ½X¹q¤l¸gÀÙ ¥¿¸ó¤J§Ú­Ì¤HÃþ¾ú¥vªº¶i¤Æ¹Lµ{ ·sªº¸gÀÙ·N¸q¡@·sªº®ø¶O¦æ¬°¡@·sªº°Ó·~¼Ò¦¡ ·sªº¦¨¥»»P§Q¼í¡K¡K¡K¡K ¤@¤Á³£¬O·sªº ¦b¼Æ½X¬ì§Þªº±Àªi§UÄi¤§¤U ¤@ªÑªÑµLªk§CÀɪº¹q¤l°Ó°È®ö¼éªï­±¦Ó¨Ó ¥¦±N¡@ÄAÂжDzΠ°ê»Ú¤¬³sºôµ¸µL½a°Ó¾÷ªº°ò¦¬O¯à°÷´£¨Ñµ¹«È¤á§óª½±µ¡B§ó§Ö±¶¡B§ó¦³®ÄªºªA°È§@·~¥­¥x¡C ¦b¤µ¦~¬O§Ú°ê¥ø·~¤Wºô¦~¡A±z¡B±zªº¥ø·~Ãø¹D¤£·Q±q¶Ç²Î¸gÀÙ¨«¦V¹q¤l¸gÀٶܡH ·Q¡A«Ü¦h·Q°µ¡A§A­Ì¦³«È¤á¡A¦³¸êª÷¡C¯Ê¤Öªº´N¬O¬°§A­Ì·f«Ø»P¹q¤l¤Æªº°Ó°È¥­¥x¡I¡I §Ú­Ì¤¤¤ß«H®§§Þ¥º¤p²Õ¡@¾Ö¦³¶¯«pªº¶}µo¹ê¤O¡A¦bºôµ¸¦U¬É¤u§@¦h¦~¡I §Ú­Ì¥i¥HÅý§A­Ì±q¶Ç²Î¸gÀÙ¹L´ç¨ì¹q¤l¸gÀÙ§ó¬°§Ö±¶¡B§ó¥[¸`¬Ù¸êª÷¡B§ó¬°¦³®Ä¡C §Ú­Ì¥i¥H¬°±zªº¤½¥q¶q¨­©w°µ¡A¦pªG±z¬O·d¤½¥qºôµ¸ªº§Þ¥º¤H­û¡A§Ú­Ì´£¨Ñ¹ï±z¦³À°§UªºªA°È¥­¥x §Ú­Ì´£¨Ñ¡G ºô¤WÁʪ«µ{§Ç¡]Ãþ¦ü¤_¢·¢·¢³¢·¡^ ¿ï©w³f¦Zµ²½ã¡A³fª«·j¯Á¡A¹Ï¤å¥\¯à¡A¦hºØ¬[ºc¡A¦hºØ¤ä¥I¤è®×¡A±j¤jªº¦Z¥xºÞ²z¨t²Î °Ó«~­q³æµ{§Ç Åý«È¤á«ö·Ó¦Û¤vªº·Nº@¶ñ¼g­q³æ¡A³f«~³W®æ¡A¥\¯à¡A¥æ³f¤é´Áµ¥µ¥¡A¨Ï¥ÎªÌ¥i¥H¥ô·N²K¨ä¥L¿ï¶µ¡D«È¤á¶ñ¼g§¹²¦¡A¥ß§Yµo°e¨ì¨Ï¥ÎªÌ¦Z¥x¾Þ§@¨t²Î¶}©l¾Þ§@¡D °Ó«~µP³º»ùµ{§Ç¡]Ãþ¦ü¤_©ö½ìºô¡^ ©ç½æµ{§Ç¡A¤£¥Î¦h»¡°Õ¡A«Ü¦h¥\¯à «È¤á¤ÏõXµ{§Ç «È¤á¹ï§Aªº²£«~¦³¦ó·N¨£¡A¦³¦ó°ÝÃD´£¥X¦Z¡A¤ÏõXµ¹¨Ï¥ÎªÌ¡A¨Ï¥ÎªÌµª´_¦Z¡A¤ÏõXµ¹«È¤á «È¤á¤¤¥¡ºÞ²zµ{§Ç ¶W¯Å±j¤jªº«È¤áºÞ²z¨t²Î¡A«È¤á¸ê®Æ¡AÁp¨t¤èªkµ¥µ¥¡D¤º¸mºôµ¸¼s§i«Å¶Çµ{§Çªº¯S§Oª©¥»¡A¥i¥H¦V«È¤áµo¥¬¶l¥ó¦Cªí«H®§ ºô¯¸¦Û°Ê§ó·sµ{§Ç ¤£·|°µºô­¶¡H³o¬O­Óµ¹¤£À´¨î§@ªº¤H¥Îªº¡A¥u­n¶ñ¼g«H®§¡A¦Û°Ê¥Í¦¨¤@­Óº¡·Nªº­¶­± ºôµ¸¼s§i«Å¶Çµ{§Ç ¶l¥ó¦Cªí¡A¤£¦Pªº¬O­º³Ð¤ä«ù¢ð¢ü¢õ¢ô¥\¯à¡DÁÙ¦³¡A¦bªA°È¾¹¤W¤@±Ò°Ê¡A¦Z¥x¦Û°Ê¹B¦æ¡Aµ¹§A¸`¬Ù¤Fºôµ¸¶O¥Î©M®É¶¡ ¹q¤l°Ó°È³fª«³øªíµ{§Ç §A¦bºô¤W½æ³B¤F¦h¤Ö³f«~¡A»ù®æ§r¡A¤°¤\ªº²Î²Î¬ö¿ý¡Aª½Æ[ªº¹Ïªí¤è¦¡Åã¥Ü¥X¨Ó¡AÅý§A¤F¸Ñ§Aªº®Ä¯q «È¤áªA°È½×¾Âµ{§Ç¡]Ãþ¦üºô©öµêÀÀªÀ°Ï¡^ ½×¾Â¡A°Q½×ªF¦è¡A¥Î¤áºÞ²z¡A¦hºØ¤ÀÃþ¡A¯Å§O¡K¡K ºô¯¸°ª¯ÅºûÅ@¨t²Î¡@¡]Ãþ¦ü¦Ê¯Sºô¡^ ³o¬O¤@­Ó¥þ¥\¯àºô¯¸¦Û°Ê¥Í¦¨¨t²Î¡A¦Û°Ê¥Í¦¨¨C¤@²Ó·L³¡¤À ·s»Dµ{§Ç ·s»D²K¥[µ{§Ç¡A§A¬O·s»Dºô¡A¨C¤ÑÁcº¾ªº·s»D²K¥[¡A¤£¬O²ÖÃa¤F§A¡C¥b¤Ñ²K¥[§¹²¦ªº·s»D¡A¥Î³o­Ó«¢«¢¡A¥b­Ó¤p®É´N·d©w¡A­¶­±¬¡°Ê¦Û¦p¡I¡I ºô¯¸³X°Ý¸Ô²Ó¬ö¿ý¡Ï³øªíµ{§Ç ¦h¤Ö¤H³X°Ý¡A¤°¤\®É­Ô¡A¤°¤\ÂsÄý¾¹¡A¤°¤\¨t²Î¡AIP¡@¨º­Ó¦a¤è ²á¤Ñµ{§Ç¡]Server Push¡W¸gÅç­È..¡^ ¤ñETHCHATÁÙ­n±j¤j¡C¡I¡I¡I ¼s§i¥I¶O¨t²Î ¨ã¦³±j¤jªºWebºÞ²z¥\¯à:¥Î¤á¥Ó½Ð¦Z,¥i¦b½u¬°¥Î¤á¶}³q¡K¡K ¥æ¤Í¨t²Î ¤ä«ù¦h¥Î¤á. 2 ¥Ó½ÐEMAIL¦^´_¥\¯à. 3 ¤ä«ù¥Î¤á­×§ï. 4 ¤ä«ù¥Î¤á¤Uªº¤Í±¡µn³°¥Î¤áªº­×§ï. 5 ¤ä«ù¥Î¤á±K½X§Ñ°O¦^´_. 6 ¤ä«ù¥Î¤á¤Uªº¤Í±¡µn³°¥Î¤á±K½X§Ñ°O¦^´_. 7 ¤ä«ù¶W¯Å¥Î¤á­×§ï§R°£©Ò¦³¥Î¤á. 8 ¤ä«ù¥Î¤á­×§ï§R°£©Ò¦³¥Î¤á. 9 ¤ä«ù¦Û°Ê¤À­¶.¡K¡K¡K¡K¡K¡K ±j¤jªº·j¯Á¤ÞÀº¨t²Î ³n¥ó¤U¸ü ¤U¸ü±Æ¦W¡@¦¸¼Æ¡@µ¥µ¥ ¼s§i¥æ´«µ{§Ç X:X¡@³o¨Ç¨t²Î µêÀÀ°ì¦Wµ{§Ç *.yeah.net ³o¼Ë§K¶O°ì¦WªA°È ¶W¯Å¤Í±¡³s±µµ{§Ç ¡@ ¦h¥\¯à¯d¨¥ªO¡]¦h¥Î¤á¡^ ¡@ WEBMAIL§K¶O¶l¥ó¨t²Î ·Q163.NET¤@¼Ë ¶W¯Å§ë²¼½Õ¬d¨t²Î¡]¦h¥Î¤á¡A¦h¿ï¾Ü¤è®×¡^ ¥\¯à¦h¦h Perl2exe¡@½sĶ¯}¸ÑªR¨t²Î ¥i¥H¯}ĶETCHAT ½sĶª©¥»§r¡C«Ü±jªº¡A¦Ó¥B¶W¯Å«K©y¡A¤£·Q¥Î¢¸¢¸¢¸¤¸¥hÁʶRETCAHT¡A´N¥Î111¤¸ÁʶR³o­Ó§a¡I¥i¥H§â·½¥N½X©Mª`¸Ñ³£Åã¥Ü¡C ¦h¥\¯à¶W¯Å¶P¥d¨t²Î ¥þ°ê³Ì±j µL¼Ä§ðÀ»µ{§Ç ¥i¥H§ðÀ»¤j³¡¤À¯¸ÂI¾É­PÅõºÈ¡A³t«×·¥§Ö¡A¥u»Ý­n¢²¤ÀÄÁ¡Aºô©öclub.netease.com³£³»¤£¤F´N·í¤F ÁÙ¦³«Ü¦h«Ü¦h¡K¡K ¦pªG±zÁÙ¦³¤°¤\»Ý­n¥i¥H§i¶D§Ú¡A§Ú¥i¥HÀ°§A¶q¨­©w°µ¡C ¦pªG±z·QÁʶR©ÎªÌ·Q¦¨¬°§Úªº¥N²z¡A½Ð¥Î¹q¤l¶l¥ó»P§ÚÁpµ¸ netprogrammer@etang.com netprogrammer@163.net ³o¨Çµ{§Ç«D±`«K©y¡A§Úªº·N¹Ï¬O·G»ù¦h¾P¡A¦U¦ì½æµ{§Çªº¥i¤d¸U¤£­n©Ç§Ú¡I¤ñ¦pºô¤WÁʪ«¨t²Î¡A­Ó¤H¥u°â350¤¸¡A¤Z¬O«e¢±¢¯¦WÁʶRªÌ³£¦³ÃØ°eºôµ¸¼s§i«Å¶Çµ{§Ç¡]»ù­È¢¸¢¯¤¸¡^§Úªº³o­Ó¶l¥ó´N¬O¥Î¥¦µoªíªº¡A«D±`¬Ù¿ú ¡I¦hÁʦhÀu´f¡I¡I §A·Q­n¨ä¥Lµ{§Ç¶Ü¡H¤ñ¦pUBBª`¥Uª©¥»µ¥µ¥,§A­n¤°¤\§Ú°ò¥»³£¦³¡A§i¶D§Ú¡A§Ú¤@©w¥Î¤ñ¥L­Ì«K©y¦n¤L­¿ªº»ù®æ¥X°âµ¹§A¡C¡@Áʪ«¶W¹L1500¤¸¥H¤WªºÃØ°e ³o¨Çµ{§Ç ªº¤@­Ó¡@ ¦pªG§A¤£·Q¦A±µ¨ì¸Ó¶l¥ó,½Ð¨ì¦¹³B http://202.96.86.39/asdf/index.html ¥»¤H¥u¨D¢°¥÷¥þ¾©ÎªÌ­Ý¾¤u§@¡C¥»¤H¦³¸û¦h®É¶¡¥h½s¼gµ{§Ç¡C¥D­n¦b¤j³°¡I ¥»¤H½sµ{±Nªñ4¦~¡A¢Ñ¢Õ¢×¨â¦~¡C ºë³q¢Ñ¢Õ¢×ºôµ¸µ{§Ç½s¼g ºë³q¡GCGI(Perl/C)/PHP/VB/VC/HTML/JS µ{§Ç»y¨¥ MySQL/Apache/Send mail/DNS/FTPµ¥ªA°È¾¹|Linux/HP UNIX/NT Workstation/Windows 9x ¾Þ§@¨t²Î CorelDraw Photoshop µ¥¹Ï§Î³]­p³n¥ó|¼ô±x¡GFlash Dreamware µ¥µ{§Ç ¹ï¤_ºôµ¸¦w¥þ¤F¸Ñ¸û¦h¡A©M«Ø¥ß«Ø¥ß¨¾¤õÀð¡A¹ï¤_¨¾¤õÀð§Þ¥º·¥¬°¤F¸Ñ¡A±q³n¥ó¨ìµw¥ó¡A¯à°÷«Ø¥ßDOSªº¨¾±s±¹¬I ºÞ²z¦h®aµêÀÀ¥D¾÷¡C ¥»¤H¯à°÷¾\Ū­^¤å¡BÁú¤å§Þ¥º¸ê®Æ¡C¤¤¤å¡B¸f»y¡B­^»y¡]¯à°÷À´±o¤j³¡¤À­^¤å§Þ¥º¸ê®Æ¡^ ¦³«Ü¦h²£«~¥i¨ÑÅçµý¥»¤Hªº§Þ¥º¹ê¤O¡C §Æ±æ±z¯à°÷Âà¹F¡IÁÂÁ¡I ¥»¤H§Æ±æ¤u§@¬O¡Gºôµ¸µ{§Ç­û¡B¨t²ÎºûÅ@¡BºôºÞ¡K¡K¡]°¸º¸¥i¥H¨î§@¤@¨Ç¥D­¶¡^ From rsvp-owner@ISI.EDU Sun Apr 23 03:27: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 DAA02741 for ; Sun, 23 Apr 2000 03:27:18 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id WAA27282 for rsvp-outgoing; Sat, 22 Apr 2000 22:33:30 -0700 (PDT) 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 WAA27277 for ; Sat, 22 Apr 2000 22:33:21 -0700 (PDT) Received: from hotmail.com (f179.law9.hotmail.com [64.4.9.179]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id WAA02262 for ; Sat, 22 Apr 2000 22:33:24 -0700 (PDT) Received: (qmail 63133 invoked by uid 0); 23 Apr 2000 05:33:12 -0000 Message-ID: <20000423053312.63132.qmail@hotmail.com> Received: from 128.230.151.30 by www.hotmail.com with HTTP; Sat, 22 Apr 2000 22:33:12 PDT X-Originating-IP: [128.230.151.30] From: "Mike Badil" To: rsvp@ISI.EDU Subject: A question related to RSVP Date: Sun, 23 Apr 2000 01:33:12 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi I just started to read RSVP. There is a point which I am not really clear, if any of you clarify the question I will be really appritiated. Question is: RSVP makes the reservation in advance, in other word, before the packets start to send, it specified the path which the packets will be traversed. Router allocate resources for the request. Since in RSVP there is no virtual circuit etc. IP packets travels in conventional way. In IP, each packets travels independently, in each node the packets make the decision again. If the packets travels in conventional IP routing way, the path can be different than the specified path because decision can be changed because of the change in routing table. My question is how does RSVP make all the packet to follow pre-specified one?, How does the routers takes care of this situation? because in conventional IP routing packets can choose the next hop in dependent than previous and next packets. If someone answer I will be really appritiated. Thanks in advance. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From rsvp-owner@ISI.EDU Mon Apr 24 01:18:23 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 BAA17679 for ; Mon, 24 Apr 2000 01:18:22 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA08911 for rsvp-outgoing; Sun, 23 Apr 2000 20:29:56 -0700 (PDT) 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 UAA08906 for ; Sun, 23 Apr 2000 20:29:54 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id UAA10114 for ; Sun, 23 Apr 2000 20:29:56 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 24 Apr 2000 09:10:08 +0530 Received: from Fresno.future.futsoft.com ([172.16.1.23]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id IAA26266 for ; Mon, 24 Apr 2000 08:49:45 +0530 Received: by localhost with Microsoft MAPI; Mon, 24 Apr 2000 08:57:10 +0530 Message-Id: <01BFADCB.13187700.arulvraj@future.futsoft.com> From: "S.Arul Vasantha Raj" To: "'rsvp@isi.edu'" Subject: RE: A question related to RSVP Date: Mon, 24 Apr 2000 08:57:08 +0530 Organization: HDF. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi Mike, You are right. RSVP wont establish reservation like VC. The reservation itself is dynamic as conventional IP routing. It reserves resource along the data flow path, based on the decision made by routing protocol in every hop. (Unicast and Multicast). It reestablishes the reservation to next hop when a route change occurs. Also the hop to hop reservation that too in soft state makes it possible to have a reservation in place before it handles data. Here you have to note, Rsvp hop to hop reservation follows the routing protocols decision. But not the reverse. ________________________________________________________________________ ________________________________________ S.Arul Vasantha Raj. FSPL, 280, Anna Salai, Nandanam, Chennai, India - 600035. Mail: arulvraj@usa.net, arulvraj@future.futsoft.com -----Original Message----- From: Mike Badil [SMTP:hasko10@hotmail.com] Sent: Sunday, April 23, 2000 11:03 AM To: rsvp@isi.edu Subject: A question related to RSVP Hi I just started to read RSVP. There is a point which I am not really clear, if any of you clarify the question I will be really appritiated. Question is: RSVP makes the reservation in advance, in other word, before the packets start to send, it specified the path which the packets will be traversed. Router allocate resources for the request. Since in RSVP there is no virtual circuit etc. IP packets travels in conventional way. In IP, each packets travels independently, in each node the packets make the decision again. If the packets travels in conventional IP routing way, the path can be different than the specified path because decision can be changed because of the change in routing table. My question is how does RSVP make all the packet to follow pre-specified one?, How does the routers takes care of this situation? because in conventional IP routing packets can choose the next hop in dependent than previous and next packets. If someone answer I will be really appritiated. Thanks in advance. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From rsvp-owner@ISI.EDU Mon Apr 24 14:12:11 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 OAA10942 for ; Mon, 24 Apr 2000 14:12:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA14267 for rsvp-outgoing; Mon, 24 Apr 2000 09:22:53 -0700 (PDT) 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 JAA14260 for ; Mon, 24 Apr 2000 09:22:46 -0700 (PDT) Received: from mimesweeper.mil3.com ([151.200.220.21]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA06515 for ; Mon, 24 Apr 2000 09:22:50 -0700 (PDT) Received: from mail.mil3.com (mil3.com) by mimesweeper.mil3.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 24 Apr 2000 12:19:50 -0400 Received: from wtn10079 (172.16.10.79) by mail.mil3.com (Worldmail 1.3.167) for rsvp@isi.edu; 24 Apr 2000 12:21:41 -0400 Message-Id: <4.2.0.58.20000424121818.00a2dd90@mail.mil3.com> X-Sender: dznamova@mil3.com@mail.mil3.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Apr 2000 12:20:59 -0400 To: rsvp@ISI.EDU From: Dana Znamova Subject: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, I have the following question regarding RSVP over a network using PIM-SM routing (multicast scenario). The problem is experienced before multicast routing switches to shortest path tree algorithm. In that case all traffic is being forwarded to the randezvous point, and then it may be routed back towards the sender (see the scenario below). For a scenario: Sender ------->Router1 --------->Router 2- Randezvous Point -------->Destination1 ---- ---> Destination2 Scenario in summary: - sender sending to a multicast group (Destination1 and Destination2 joined that group), - second router - Router2 is a randezvous point Routing of Path messages using PIM-SM routing (before shortest-tree is being used): - Path message from sender is recieved on Router2 - Router2 forwards the message to Router2-Randezvous Point - Router2-Randezvous Point forwards the traffic to Destination1 and Router1 - Router1 forwards the traffic to Destination2 Problems: 1. Router1 receives Path message from 2 hops - Sender - Router2 - Randezvous Point RFC 2209 it is assumed that Path message can be received only on 1 incoming interface. If there are 2 incoming interfaces, one of them is considered not to be used for routing of Resv messages. 2. Even if we dropped the assumption that Path message can be received on 1 incoming interface, and considered both states to be forwarding, what about forwarding of Resv messages? RFC 2205 states that RSVP messages are never forwarded on the same interface they arrived. But when Router1 receives Resv message , according to the Path states on Router1, the message should be forwarded to Router2 and Destination2. Since Resv message was received from Router2, the message will not be forwarded to Router2. This will, however, imply that no reservation will be made on the Router1---Router2 link in the direction Router2->Router1. But the traffic routed by PIM-SM also flows from Router2->Router1. Does anybody know how the above case is handled? Can you please point me to the appropriate documentation? If further clarification is needed, please ask. Thanks you very much for your time. Dana ************************************ Dana Znamova OPNET Applications Engineer OPNET Technologies, Inc. www.mil3.com 202-364-4700 ************************************ From rsvp-owner@ISI.EDU Mon Apr 24 18:16: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 SAA16340 for ; Mon, 24 Apr 2000 18:16:39 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id NAA04182 for rsvp-outgoing; Mon, 24 Apr 2000 13:30:25 -0700 (PDT) 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 NAA04176 for ; Mon, 24 Apr 2000 13:30:23 -0700 (PDT) Received: from mailout2.hananet.net ([210.220.163.35]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA19998 for ; Mon, 24 Apr 2000 13:30:22 -0700 (PDT) Received: from thrunet.thrunet.com ([211.44.129.33]) by mailout2.hananet.net (Netscape Messaging Server 4.15) with SMTP id FTJFIO01.X4X for ; Tue, 25 Apr 2000 05:28:00 +0900 From: ÀÌÇö¿ì To: rsvp@ISI.EDU Subject: ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¹«·á mailing service ¾È³»!! Date: Tue, 25 Apr 00 05:26:26 ŸÀ̺£ÀÌ Ç¥Áؽà MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606 Message-ID: Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. --AD_2000_PART_BOUNDARY_19990606 Content-Type: text/plain Content-Transfer-Encoding: 7Bit ¢Î ¸ÅÀÏ ¹Þ¾Æº¸½Ç ¿µ¾î,ÀÏ¾î »ýȰȸȭ ¿¹¹®. ¢º¢º¢º¢º ¹«·á ¼­ºñ½º ¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬ ¢Ï ¿À´ÃÀÇ À¯¿ì¸Ó¢º 2000.04.25(È­) ¡ì¦¡ ÁÖ 2 ȸ ¹ß¼Û(È­,¸ñ) ¹ß¼Û. "Dad, I don't want to go to school today." said the boy. "Why not, son?" "Well, one of the chickens on the school farm died last week and we had chicken soup for lunch the next day. And three days ago one of the pigs died and we had roast pork the next day,,,." "But why don't you want to go today?" "Because the English teacher died yesterday!" "....." "¾Æºü, ³ª ¿À´Ã Çб³ °¡±â ½È¾î." ÇÏ°í ¼Ò³âÀÌ ¸»Çß´Ù. "¿Ö °¡±â ½ÈÁö?" "Áö³­ÁÖ¿¡ Çб³ ³óÀå¿¡¼­ ´ß ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥ ´ÙÀ½³¯ Á¡½ÉÀ¸·Î ´ß ¼öÇÁ¸¦ ¸Ô¾ú¾î. ±×¸®°í 3ÀÏ Àü¿¡´Â µÅÁö ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥ ±× ´ÙÀ½ ³¯¿¡´Â µÅÁö ºÒ°í±â¸¦ ¸Ô¾ú°í,,,." "±×·±µ¥ ¿Ö ¿À´ÃÀº Çб³¿¡ °¡±â ½È¾î?" "¾îÁ¦ ¿µ¾î ¼±»ý´ÔÀÌ µ¹¾Æ°¡¼Ì´Ü ¸»¾ß!" "....." ¢Ï ¿À´ÃÀÇ ÇѸ¶µð ¢º ¿µ¾î(2000.04.25(È­)) ¢ÃI felt on top of the world ¡ì¦¡¦¡¦¡¦¡¦¡ ¸ÅÀÏ(¿ù-±Ý) ¹ß¼Û. »ç¶÷Àº ´©±¸³ª ¼º°øÇÏ¸é ±âºÐÀÌ ÁÁÀº °ÍÀº ´ç¿¬ÇÏÁö¿ä. ¹°·Ð, ¾î¶² »ç¶÷µéÀº ¼º°øÇßÀ» ¶§¿¡ ´õ °â¼ÕÇØÁöÁö¸¸ ´ëºÎºÐÀÇ »ç¶÷µéÀº [³ª¸¦ º¸¶ó! ³»°¡ ÃÖ°í¾ß]¶ó°í »ý°¢ÇÕ´Ï´Ù. ÀÌ¿Í °°Àº ±âºÐÀ» ³ªÅ¸³»´Â Ç¥ÇöÀÌ 'on top of the world'¶ø´Ï´Ù. on top of the world¸¦ Á÷¿ªÇϸé [¼¼»ó ²À´ë±â¿¡]¶ó´Â ÀǹÌÀ̸ç I felt on top of the world. ´Â (¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦À̾ú´Ù.) Áï, (±²ÀåÈ÷ ±âºÐÀÌ ÁÁ¾Ò´Ù)¸¦ ¶æÇÕ´Ï´Ù. ÈçÈ÷ (±âºÐÀÌ ÁÁ¾Ò¾î)¶ó´Â Àǹ̷ΠI felt good. ¸¸À» »ý°¢Çϱ⠽¬¿ì³ª ÀÌ Ç¥Çöµµ ¾Ë°í ÀÖÀ¸¸é °¨Á¤ÀÇ Ç¥ÇöÀ» ´õ Àß ÇÒ ¼ö ÀÖÀ» °Å¿¡¿ä. ¢Á on top of the world´Â ¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦. ±×·¸´Ù¸é out of this world ´Â? ÀÌ ¼¼»óÀÇ ÀÏ°°Áö ¾Ê°Ô wonderful[±Ù»çÇÑ], fantastic[ȯ»óÀûÀÎ]À̶õ ¶æÀÌ¿¡¿ä. A: I heard you were engaged to Marian. B: Actually, I was. A: Oh, really? So, how did you feel on the night of your engagement? B: I felt like I was on top of the world. A: ¸Þ¸®¾È°ú ¾àÈ¥ÇÑ´Ù°í µé¾ú´Âµ¥. B: »ç½Ç ÀÌ¹Ì Çß¾î. A: ¾î, Á¤¸»À̾ß? ±×·¡,¾àÈ¥½ÄÇÑ ±×³¯ ¹ã¿¡ ±âºÐÀÌ ¾î¶®¾î? B: ¼¼»óÀ» ¾òÀº ±âºÐÀ̾úÁö. ¢Ï ¿À´ÃÀÇ ÇѸ¶µð ¢º ÀϾî(2000.04.25(È­))¡ì¦¡ÁÖ 3 ȸ ¹ß¼Û(¿ù,¼ö,±Ý) ¹ß¼Û. ÀÏ¾î ¿¹¹®µµ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼º µÇ¾î ÀÖ½À´Ï´Ù. ----------------------------------------------------------------------- ======================================================================= ¾È³çÇϼ¼¿ä? ÀúÈñ´Â ÀüÈ­¸¦ ÀÌ¿ëÇؼ­ °­»ç¿Í 1:1·Î ¿Ü±¹¾î ÇнÀÀ» ÇÒ ¼ö ÀÖ´Â ¢Ä Online korea ¢Å¶ó°í ÇÕ´Ï´Ù. Çã¶ô¾øÀÌ ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. ºÎµð ³Ê±×·¯¿î ¿ë¼­¸¦...... ÀúÈñ ȸ»ç¿¡¼­´Â »ýÈ° ȸȭ¿¡ °ü½ÉÀÖ´Â ³×ƼÁð ¿©·¯ºÐ¿¡°Ô ¸ÅÀÏ(¿ù-±Ý), ½Ç »ýÈ°¿¡ ÇÊ¿äÇÑ »ýȰȸȭ ÇÑ ¹®À徿À» ¹«·á·Î º¸³» µå¸®°í ÀÖ¾î¿ä. ¼­ºñ½º ³»¿ëÀº ¾Æ·¡¿Í °°ÀÌ ±¸¼º µÇ¿À´Ï ¹Þ¾Æº¸±æ ¿øÇϽô ºÐÀº ¡ì olk@olk.co.kr ¡í·Î "yes"¶ó´Â mailÀ» ÁÖ½Ã¸é µÈ´ä´Ï´Ù. ±×¸®°í, ÀúÈñ ÀüÈ­ ¿Ü±¹¾î °­ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ ¢Â½Ã¹ü°­ÀǢµµ ¹«·á·Î ½Ç½ÃÇÏ°í ÀÖÀ¸´Ï ¸¹ÀÌ ½ÅûÇØ ÁÖ¼¼¿ä. ¹«·á ½Ã¹ü°­ÀÇ ½Åû ¹æ¹ýÀº ¢º www.d-day.co.kr ¢¸ ¿¡ Á¢¼ÓÇϽŠÈÄ "°­ÀǼҰ³"¶õÀ» Ŭ¸¯ÇϽŴÙÀ½ "°­ÀǽÅû"¶õÀ» º¸½Ã¸é ½Ã¹ü°­ÀǸ¦ ½ÅûÇÏ½Ç ¼ö ÀÖ¾î¿ä. ÀüÈ­ 02-588-0510 À¸·Îµµ ½ÅûÇÒ ¼ö ÀÖ´ä´Ï´Ù. ¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀ¸·Î ȸȭ ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÛÀÌ µÇ¾úÀ¸¸é ÇÕ´Ï´Ù. °¨»çÇÕ´Ï´Ù. ºÒÇÊ¿äÇÑ Á¤º¸¿´´Ù¸é ´ë´ÜÈ÷ Á˼ÛÇÕ´Ï´Ù. --AD_2000_PART_BOUNDARY_19990606-- From rsvp-owner@ISI.EDU Mon Apr 24 21:11: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 VAA19056 for ; Mon, 24 Apr 2000 21:11:31 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA14927 for rsvp-outgoing; Mon, 24 Apr 2000 16:22:27 -0700 (PDT) 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 QAA14920 for ; Mon, 24 Apr 2000 16:22:24 -0700 (PDT) Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id QAA29090 for ; Mon, 24 Apr 2000 16:22:25 -0700 (PDT) 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 29ABXLAK; Mon, 24 Apr 2000 19:19:39 -0400 Message-ID: <3904D7F5.2631BBB2@globespan.net> Date: Mon, 24 Apr 2000 19:25:41 -0400 From: Sameer Shah Organization: Globespan Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: typo in draft-ietf-rsvp-refresh-reduct-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Section 4.3 says MESSAGE_ID_ACK Class = 24 (Value to be assigned by IANA of form 0bbbbbbb) Section 5.1 says MESSAGE_ID_LIST Class = 24 (Value to be assigned by IANA of form 0bbbbbbb) The temporarily assigned Class value is same. -- Sameer Shah GlobeSpan Inc. Email: sshah@globespan.net Web: www.globespan.net From rsvp-owner@ISI.EDU Tue Apr 25 10:55: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 KAA15117 for ; Tue, 25 Apr 2000 10:55:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA21442 for rsvp-outgoing; Tue, 25 Apr 2000 05:24:39 -0700 (PDT) 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 FAA21423 for ; Tue, 25 Apr 2000 05:24:36 -0700 (PDT) Received: from griffin.host4u.net (griffin.host4u.net [209.150.128.163]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id FAA29260 for ; Tue, 25 Apr 2000 05:24:39 -0700 (PDT) Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id HAA02803; Tue, 25 Apr 2000 07:24:56 -0500 Message-Id: <4.3.1.2.20000425081052.00bfb760@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 25 Apr 2000 08:25:19 -0400 To: rsvp@ISI.EDU From: Lou Berger Subject: Minor update to draft-ietf-rsvp-refresh-reduct Cc: lberger@labn.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk An update to the refresh overhead reduction draft has been submitted. Most changes are very minor text corrections. The only substantive change is that ALL values that are to be assigned by IANA have been removed. The reason for this is to alert the reader that there are no permanent values. I have asked IANA for assignment of these values for a long time and have received nothing but automatic replies. It is likely that when they get around to assigning values, the values assigned will be different than those used in earlier versions of the draft. For those who don't want to wait for the I-D publication, the draft is available at: http://www.labn.net/docs/draft-ietf-rsvp-refresh-reduct-04.txt Lou From rsvp-owner@ISI.EDU Wed Apr 26 09:24: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 JAA26031 for ; Wed, 26 Apr 2000 09:24:35 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA18602 for rsvp-outgoing; Wed, 26 Apr 2000 03:42:15 -0700 (PDT) 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 DAA18597 for ; Wed, 26 Apr 2000 03:42:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA01099 for ; Wed, 26 Apr 2000 03:42:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22687; Wed, 26 Apr 2000 06:42:39 -0400 (EDT) Message-Id: <200004261042.GAA22687@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-04.txt Date: Wed, 26 Apr 2000 06:42:38 -0400 Sender: owner-rsvp@ISI.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Refresh Overhead Reduction Extensions Author(s) : L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini Filename : draft-ietf-rsvp-refresh-reduct-04.txt Pages : 34 Date : 25-Apr-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-04.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-04.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-04.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: <20000425111549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-refresh-reduct-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-refresh-reduct-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000425111549.I-D@ietf.org> --OtherAccess-- --NextPart-- From rsvp-owner@ISI.EDU Thu Apr 27 14:10: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 OAA04747 for ; Thu, 27 Apr 2000 14:10:27 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA21769 for rsvp-outgoing; Thu, 27 Apr 2000 09:02:24 -0700 (PDT) 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 JAA21764 for ; Thu, 27 Apr 2000 09:02:23 -0700 (PDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA00872 for ; Thu, 27 Apr 2000 09:02:48 -0700 (PDT) Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.21) id <29H4G9TK>; Thu, 27 Apr 2000 11:30:36 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48D094@email.quarrytech.com> From: "Abes, Andi" To: David Charlap , rsvp@ISI.EDU Subject: RE: Optional Adspec objects Date: Thu, 27 Apr 2000 11:30:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk see comments.... > -----Original Message----- > From: David Charlap [mailto:dcharlap@fore.com] > Sent: Friday, April 14, 2000 5:39 PM > To: rsvp@ISI.EDU > Subject: Re: Optional Adspec objects > > > > On the other hand, the ambiguity really should not matter. > If a Path > > message is received without an Adspec, the logical thing > would seem to > > be to forward it without an Adspec (except the RSVP daemon in the > > sender host might supply a default Adspec when the application does > > not specify one.) > > This is what I needed to know. > > To me, it seems equally logical to always provide an Adspec, even when > one os not received. Of course, if you include GS or CL > service blocks > in it, you will be sending possibly-incorrect information about the my understanding of the Adspec is that it provides information about the network usage/capabilities not the senders' requirements. If that is the case, each router can take a snapshot of itself and send it down in the path, with no fear of confusing anyone. > sender's requirements. But I don't think it can hurt if an > Adspec with > only default/general characteristics is created. > > But not including one is definitely easier. If it is legal, that is > what I'd rather do. > > > "Be liberal in what you receive and conservative in what you send". > > Ah, but this depends on what it means to be conservative in what's > sent. Is it conservative to send an optional object when it is not > required? > > -- David > From rsvp-owner@ISI.EDU Fri Apr 28 01:20:27 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 BAA15322 for ; Fri, 28 Apr 2000 01:20:27 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA02031 for rsvp-outgoing; Thu, 27 Apr 2000 20:28:33 -0700 (PDT) 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 UAA02025 for ; Thu, 27 Apr 2000 20:28:31 -0700 (PDT) Received: (from braden@localhost) by boreas.isi.edu (8.8.7/8.8.6) id UAA24838; Thu, 27 Apr 2000 20:28:57 -0700 (PDT) Date: Thu, 27 Apr 2000 20:28:57 -0700 (PDT) From: Bob Braden Message-Id: <200004280328.UAA24838@boreas.isi.edu> To: rsvp@ISI.EDU, dcharlap@fore.com Subject: Re: Optional Adspec objects X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> *> > On the other hand, the ambiguity really should not matter. If a Path *> > message is received without an Adspec, the logical thing would seem to *> > be to forward it without an Adspec (except the RSVP daemon in the *> > sender host might supply a default Adspec when the application does *> > not specify one.) *> *> This is what I needed to know. *> *> To me, it seems equally logical to always provide an Adspec, even when *> one os not received. Of course, if you include GS or CL service blocks I don't think that works. Then the ADSPEC that arrives at the receiver purports to provide E-E data ("general characteristics") on the entire path, but it doesn't. *> in it, you will be sending possibly-incorrect information about the *> sender's requirements. But I don't think it can hurt if an Adspec with *> only default/general characteristics is created. *> *> But not including one is definitely easier. If it is legal, that is *> what I'd rather do. *> *> > "Be liberal in what you receive and conservative in what you send". *> *> Ah, but this depends on what it means to be conservative in what's *> sent. Is it conservative to send an optional object when it is not *> required? It is conservative not to send an optional object when its meaning is doubtful. Bob Braden *> *> -- David *> From rsvp-owner@ISI.EDU Fri Apr 28 03:46:07 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 DAA25703 for ; Fri, 28 Apr 2000 03:46:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id WAA09292 for rsvp-outgoing; Thu, 27 Apr 2000 22:45:04 -0700 (PDT) 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 WAA09240 for ; Thu, 27 Apr 2000 22:45:01 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA00470 for ; Thu, 27 Apr 2000 22:44:54 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 28 Apr 2000 11:24:40 +0530 Received: from joanj.future.futsoft.com ([172.16.1.34]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA28043 for ; Fri, 28 Apr 2000 11:04:16 +0530 Received: by joanj.future.futsoft.com with Microsoft Mail id <01BFB103.34D5AC60@joanj.future.futsoft.com>; Fri, 28 Apr 2000 11:16:31 +0530 Message-Id: <01BFB103.34D5AC60@joanj.future.futsoft.com> From: Joan Of Arc Jeyarani To: "rsvp@isi.edu" Subject: WHY rsvp? Date: Fri, 28 Apr 2000 11:15:46 +0530 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, I have a doubt . Why RSVP is needed while IP can support QOS. Regards, joan, FS, Chennai. From rsvp-owner@ISI.EDU Fri Apr 28 13:06: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 NAA06349 for ; Fri, 28 Apr 2000 13:06:27 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA01203 for rsvp-outgoing; Fri, 28 Apr 2000 08:00:10 -0700 (PDT) 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 IAA01198 for ; Fri, 28 Apr 2000 08:00:09 -0700 (PDT) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA19800 for ; Fri, 28 Apr 2000 08:00:11 -0700 (PDT) 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 KAA25579 for ; Fri, 28 Apr 2000 10:59:36 -0400 (EDT) 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 KAA17036 for ; Fri, 28 Apr 2000 10:59:38 -0400 (EDT) Message-ID: <3909A76D.D8787937@fore.com> Date: Fri, 28 Apr 2000 10:59:57 -0400 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: Re: Optional Adspec objects References: <496A8683261CD211BF6C0008C733261A48D094@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Andi Abes wrote: > David Charlap wrote: >> >> To me, it seems equally logical to always provide an Adspec, even >> when one os not received. Of course, if you include GS or CL >> service blocks in it, you will be sending possibly-incorrect >> information about the sender's requirements. > > my understanding of the Adspec is that it provides information about > the network usage/capabilities not the senders' requirements. WRT the values stored in the Adpec, yes. But WRT the existance of the various service blocks - no. Note the following from RFC 2210: 3.3. RSVP ADSPEC Object An RSVP ADSPEC object is constructed from data fragments contributed by each service which might be used by the application. The ADSPEC begins with an overall message header, followed by a fragment for the default general parameters, followed by fragments for every QoS control service which may be selected by application receivers. The size of the ADSPEC varies depending on the number and size of per-service data fragments present and the presence of non-default general parameters (described in Section 3.3.5). The complete absence of a data fragment for a particular service means that the application sender does not know or care about that service, and is a signal to intermediate nodes not to add or update information about that service to the ADSPEC. It is also a signal to application receivers that they should not select that service when making reservations. In other words, by including an Adspec, a sender is telling the receiver(s) which kinds of reservations (guaranteed-service, controlled- load or something proprietary) it can handle. The recipient may only choose from those kinds presented. Seen from the sender's standpoint, the sender can tell the reciever which kind of reservation to use by not including Adspec services for any other kinds. -- David