From rsvp-owner@ISI.EDU Mon May 1 21:15: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 VAA09101 for ; Mon, 1 May 2000 21:15:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA28916 for rsvp-outgoing; Mon, 1 May 2000 16:19: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 QAA28911 for ; Mon, 1 May 2000 16:19:06 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA11712; Mon, 1 May 2000 16:19:31 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA07950; Mon, 1 May 2000 23:19:30 GMT Date: Mon, 1 May 2000 23:19:30 GMT Message-Id: <200005012319.XAA07950@gra.isi.edu> To: rsvp@ISI.EDU, dznamova@mil3.com Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Cc: zappala@cs.uoregon.edu, braden@ISI.EDU X-Sun-Charset: US-ASCII 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 The RSVP logic for shared trees was not fully worked out in detail. The primary thinking about it, by Daniel Zappala, appears in his RSRR v.2 spec (An expired Internet Draft from Nov 98 that is however available on the ISI RSVP Web page http://www.isi.edu/rsvp/pub.html). *> 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 *> Unfortunately your picture was broken as displayed as ASCII text in my mailer. Is the following picture correct? Sender ----> Router1 -------> Router2 = RP | | V V Destination1 Destination2 Pardon me if I write something stupid, but I think that the original data packets from Sender to RP are encapsulated and sent unicast. If this is true, there are two distinct sessions: Unicast: Sender ----> Router1 -------> Router2 = RP and Multicast: Router2 = RP -------> Router1 | | V V Destination1 Destination2 These are handled independently by RSVP, and this should resolve all the conflicts. Note that the RP must merge the requests from the two multicast destinations, map it into the unicast session for return to the sender. I believe it is also possible for the initial sender-->RP flow to be unencapsulated but use a (one-branch) source tree. This possibility is noted in Zappala's Internet Draft, under the description of "unidirectional shared" tree type. Perhaps the tree type needs to be logically concatenated with the destination address in forming the session, to still divide the flow into two distinct subflows as above. I will be interested to know whether others think this makes sense. Bob Braden *> *> 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 received 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 May 1 22:16: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 WAA10280 for ; Mon, 1 May 2000 22:16:16 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA01859 for rsvp-outgoing; Mon, 1 May 2000 17:21:48 -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 RAA01837 for ; Mon, 1 May 2000 17:21:39 -0700 (PDT) Received: from mimesweeper.mil3.com ([151.200.220.21]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id RAA26269; Mon, 1 May 2000 17:21:38 -0700 (PDT) Received: from mail.mil3.com (mil3.com) by mimesweeper.mil3.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 1 May 2000 20:18:38 -0400 Received: from wtn10079 (172.16.10.79) by mail.mil3.com (Worldmail 1.3.167); 1 May 2000 20:20:27 -0400 Message-Id: <4.2.0.58.20000501194818.00a29ee0@mail.mil3.com> X-Sender: dznamova@mil3.com@mail.mil3.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 May 2000 20:19:41 -0400 To: rsvp@ISI.EDU, braden@ISI.EDU From: Dana Znamova Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Cc: zappala@cs.uoregon.edu In-Reply-To: <200005012319.XAA07950@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, I am sorry my original picture got broken. This is how it was originally (I simplified it to make it more clear): 1. Sender->Router1->Router2->Destination 2. Router1->Destination1 Router2 is a randezvous point. The scenario below is for the case when short-path tree is not yet used. That means that the traffic will flow with unicast destination address to the randezvous point (Router2), and then router2 will send it to Destination, Destination2, and Router1. Router1 will then forward the packet to Destination1. Problem: Path messages will take the same path as data packets. That means that before Path message gets to Destination1, it will get to the randezvous point, and then it will be forwarded "back" to Router1 and Destination2. This implies that Router1 will receive the message twice. 1. on the interface from Sender 2. on the interface from Router2 Routing will know how to forward it, but the question is: HOW MANY PATH STATES SHOULD THE PATH MESSAGE CREATE? One or two? And then, how should the reservation be made? Should it account for the packets being sent "backwards in the direction towards the sender? Moreover, RFC 2209 "Algorithmic Processing of RSVP messages" assumes that RSVP Path message can be received on only one interface (state created based on this message is then considered to be forwarding. Path message received on an interface not expected by routing will create a Path state, but that state will not be used for forwarding of Path messages). Please, be so kind, and let me know how to approach the problem above. I will also read suggested draft RFCs to find out whether they discuss the probelm. Your help is greatly appreciated. Thanks. Dana At 11:19 PM 5/1/00 +0000, you wrote: > *> > *> 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 > >The RSVP logic for shared trees was not fully worked out in detail. >The primary thinking about it, by Daniel Zappala, appears in his >RSRR v.2 spec (An expired Internet Draft from Nov 98 that is >however available on the ISI RSVP Web page http://www.isi.edu/rsvp/pub.html). > > *> 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 > *> > >Unfortunately your picture was broken as displayed as ASCII text >in my mailer. Is the following picture correct? > > Sender ----> Router1 -------> Router2 = RP > | | > V V > Destination1 Destination2 > > >Pardon me if I write something stupid, but I think that the original >data packets from Sender to RP are encapsulated and sent unicast. If >this is true, there are two distinct sessions: > > > Unicast: Sender ----> Router1 -------> Router2 = RP > >and > > Multicast: > > Router2 = RP -------> Router1 > | | > V V > Destination1 Destination2 > > >These are handled independently by RSVP, and this should resolve all >the conflicts. Note that the RP must merge the requests from the >two multicast destinations, map it into the unicast session for >return to the sender. > >I believe it is also possible for the initial sender-->RP flow >to be unencapsulated but use a (one-branch) source tree. This >possibility is noted in Zappala's Internet Draft, under the >description of "unidirectional shared" tree type. Perhaps the >tree type needs to be logically concatenated with the destination >address in forming the session, to still divide the flow into >two distinct subflows as above. > >I will be interested to know whether others think this makes sense. > >Bob Braden > > *> > *> 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 received 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 > *> ************************************ > *> > *> ************************************ Dana Znamova OPNET Applications Engineer OPNET Technologies, Inc. www.mil3.com 202-364-4700 ************************************ From rsvp-owner@ISI.EDU Tue May 2 06:57: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 GAA27000 for ; Tue, 2 May 2000 06:57:42 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA19766 for rsvp-outgoing; Tue, 2 May 2000 01:36:17 -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 BAA19761 for ; Tue, 2 May 2000 01:36:16 -0700 (PDT) Received: from nic.bme.hu (nic.bme.hu [152.66.115.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id BAA16746 for ; Tue, 2 May 2000 01:36:16 -0700 (PDT) Received: from ttt-atm.ttt.bme.hu (ttt-atm.ttt.bme.hu [152.66.246.81]) by nic.bme.hu (Postfix) with ESMTP id C08CA39E54 for ; Tue, 2 May 2000 10:36:23 +0200 (MET DST) Received: from TTT-ATM/SpoolDir by ttt-atm.ttt.bme.hu (Mercury 1.40); 2 May 100 10:38:28 +0100 Received: from SpoolDir by TTT-ATM (Mercury 1.40); 2 May 100 10:20:15 +0100 Received: from ttt-atm.ttt.bme.hu (152.66.79.164) by ttt-atm.ttt.bme.hu (Mercury 1.40) with ESMTP; 2 May 100 10:19:39 +0100 Message-ID: <390E8FF9.C5A166E1@ttt-atm.ttt.bme.hu> Date: Tue, 02 May 2000 10:21:13 +0200 From: Retvari Gabor X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,hu MIME-Version: 1.0 To: RSVP list Subject: Explicit routing... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm interested in investigating the co-operation of routing and RSVP. Therefore I need to know, has any kind of explicit (source-) routing support been invented for RSVP? This means: is the RSVP - Routing interface capable of carrying explicit routing objects (based on my understanding, it is not), has Explicit Routing object been added to the Path message (or is it worth using IP source routing?). Any pointer to related work is appreciated... Thanks in advance: Gabor Retvari/BUTE From rsvp-owner@ISI.EDU Tue May 2 13:32: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 NAA05923 for ; Tue, 2 May 2000 13:32:31 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA09424 for rsvp-outgoing; Tue, 2 May 2000 08:36:45 -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 IAA09417 for ; Tue, 2 May 2000 08:36:43 -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 IAA05295 for ; Tue, 2 May 2000 08:36:31 -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 LAA04799 for ; Tue, 2 May 2000 11:36:17 -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 LAA05392 for ; Tue, 2 May 2000 11:36:14 -0400 (EDT) Message-ID: <390EF612.625D6F18@fore.com> Date: Tue, 02 May 2000 11:36:50 -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 list Subject: Re: Explicit routing... References: <390E8FF9.C5A166E1@ttt-atm.ttt.bme.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Retvari Gabor wrote: > > I'm interested in investigating the co-operation of routing and RSVP. > Therefore I need to know, has any kind of explicit (source-) routing > support been invented for RSVP? > This means: is the RSVP - Routing interface capable of carrying > explicit routing objects (based on my understanding, it is not), has > Explicit Routing object been added to the Path message (or is it worth > using IP source routing?). > Any pointer to related work is appreciated... The MPLS working group has created an explicit-route extension to RSVP as part of their RSVP-TE draft: draft-ietf-mpls-rsvp-lsp-tunnel-05.txt As far as I know, these extensions are not included in any RSVP working group document, and therefore should not be used except when used for signalling MPLS LSPs. -- David From rsvp-owner@ISI.EDU Wed May 3 09:21:26 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01626 for ; Wed, 3 May 2000 09:21:25 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA01353 for rsvp-outgoing; Wed, 3 May 2000 03:27:20 -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 DAA01348 for ; Wed, 3 May 2000 03:27:17 -0700 (PDT) Received: from rubicon.hasler.ascom.ch (rubicon.hasler.ascom.ch [139.79.129.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA01872 for ; Wed, 3 May 2000 03:27:19 -0700 (PDT) Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5]) by rubicon.hasler.ascom.ch (8.9.3/8.9.3) with ESMTP id MAA24655 for ; Wed, 3 May 2000 12:27:41 +0200 (MET DST) Received: from ascom.ch (stva188 [139.79.35.111]) by stva195.pbx.ascom.ch (8.9.3/8.9.3) with ESMTP id MAA17360 for ; Wed, 3 May 2000 12:27:41 +0200 (MET DST) Message-ID: <390FFF1D.368BADB@ascom.ch> Date: Wed, 03 May 2000 12:27:41 +0200 From: Dusan Sarvan Organization: ASCOM Business Systems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: RSVP on IP Phones Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi,

I will be really appreciated if someone can answer my questions:

1. Since RSVP is pretty complex technology, implementing RSVP on the end
devices such as an IP Phone makes this device pretty complex and probably expensive.
Could you tell me please if RSVP is  in implementation on IP phones and is it
implemented by some companies on IP phones?

2. Is it feasible some centralized device such as a Call Manager to play RSVP on a behalf
of IP phones?

Thanks a lot in advance. From rsvp-owner@ISI.EDU Wed May 3 12:52: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 MAA06025 for ; Wed, 3 May 2000 12:52:08 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA10000 for rsvp-outgoing; Wed, 3 May 2000 07:32:16 -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 HAA09995 for ; Wed, 3 May 2000 07:32:15 -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 HAA12535 for ; Wed, 3 May 2000 07:32: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 KAA07457 for ; Wed, 3 May 2000 10:32:14 -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 KAA06323 for ; Wed, 3 May 2000 10:32:16 -0400 (EDT) Message-ID: <39103899.DDC2422E@fore.com> Date: Wed, 03 May 2000 10:32: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 IP Phones References: <390FFF1D.368BADB@ascom.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Dusan Sarvan wrote: > > I will be really appreciated if someone can answer my questions: > > 1. Since RSVP is pretty complex technology, implementing RSVP on the > end devices such as an IP Phone makes this device pretty complex > and probably expensive. IMO, RSVP on the end devices is much simpler to implement than on transit routers. Most of the complexities (like reservation merging, and managing reservations from multiple sessions) don't apply to an end device that will be acting as one sender and one recipient and will probably not have any other RSVP-controlled data flows. > Could you tell me please if RSVP is in implementation on IP phones > and is it implemented by some companies on IP phones? I don'w know about this. > 2. Is it feasible some centralized device such as a Call Manager to > play RSVP on a behalf of IP phones? It's certainly possible, but note: - This call manager needs to know the QoS that the phone will use. If it's not hard-coded then the phone needs to signal it. If not using RSVP, then with something proprietary. This signalling message will have to contain much of the same data that RSVP conveys, so you may not be saving very much. - If the call manager has the QoS and other per-call parameters hard- coded (or possibly configured locally), then the connection to the phone becomes simpler, but it increases administrative overhead for the user - who now has to configure both the phone and the call manager. - This call manager can't control QoS on the last-hop from itself to the phone. Depending on the hardware, this may or may not be a problem. -- David From rsvp-owner@ISI.EDU Wed May 3 13:09: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 NAA06606 for ; Wed, 3 May 2000 13:09:40 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA09789 for rsvp-outgoing; Wed, 3 May 2000 07:25:05 -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 HAA09735 for ; Wed, 3 May 2000 07:25:01 -0700 (PDT) Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA12224 for ; Wed, 3 May 2000 07:25:02 -0700 (PDT) Received: from busybox.arch.bellsouth.net (client107055.atl.mediaone.net [24.31.107.55]) by ns1.arch.bellsouth.net (8.9.1a/goaway) with ESMTP id KAA10802; Wed, 3 May 2000 10:25:30 -0400 (EDT) Message-Id: <4.3.1.0.20000503101223.00c457a0@pop3.arch.bellsouth.net> X-Sender: ck@pop3.arch.bellsouth.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 May 2000 10:24:56 -0400 To: Dusan Sarvan , rsvp@ISI.EDU From: Christian Kuhtz Subject: Re: RSVP on IP Phones In-Reply-To: <390FFF1D.368BADB@ascom.ch> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_153836551==_.ALT" Sender: owner-rsvp@ISI.EDU Precedence: bulk --=====================_153836551==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:27 PM 5/3/00 +0200, Dusan Sarvan wrote: >Hi, > >I will be really appreciated if someone can answer my questions: > >1. Since RSVP is pretty complex technology, implementing RSVP on the end >devices such as an IP Phone makes this device pretty complex and probably >expensive. >Could you tell me please if RSVP is in implementation on IP phones and is it >implemented by some companies on IP phones? I'm not aware of any. Given the abundance of CPU horsepower (not counting DSP resources) in some of these devices, I don't necessarily see this the limitation at this point. And you can source an IP stack capabable of supporting RSVP from various places. >2. Is it feasible some centralized device such as a Call Manager to play >RSVP on a behalf >of IP phones? That could indeed be done. However, the more important question is.. how is the network designed in which you plan to deploy this. In my experience, while RSVP often times looks like a "clean approach" from an academic traffic mgmt approach, but operationally you got a whole 'nother set of headaches and there are other more practical ways of approaching this subject. In scenarios where IP phones are generally stationary, you can "get away" with aggregate "reservations" for bandwidth. The reasoning is like many other scenarios where you have to make a call as to whether you want to go with a dynamic or static mechanism. While dynamic looks "cleaner", sometimes it buys you squat and makes it more difficult than it needs to be. So, whether traffic mgmt task be accomplished by RSVP or some other means is another question. I have yet to run into a case where I could justify introducing the complexity of RSVP, and its potential strain on resources in a service provider network. RSVP on an extremely limited basis in an enterprise network has proven useful, although generally there too there are more cost effective approaches when you look at the big picture. Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." --=====================_153836551==_.ALT Content-Type: text/html; charset="us-ascii" At 12:27 PM 5/3/00 +0200, Dusan Sarvan wrote:

Hi,

I will be really appreciated if someone can answer my questions:

1. Since RSVP is pretty complex technology, implementing RSVP on the end
devices such as an IP Phone makes this device pretty complex and probably expensive.
Could you tell me please if RSVP is  in implementation on IP phones and is it
implemented by some companies on IP phones?

I'm not aware of any.  Given the abundance of CPU horsepower (not counting DSP resources) in some of these devices, I don't necessarily see this the limitation at this point.

And you can source an IP stack capabable of supporting RSVP from various places.

2. Is it feasible some centralized device such as a Call Manager to play RSVP on a behalf
of IP phones?

That could indeed be done.

However, the more important question is.. how is the network designed in which you plan to deploy this.  In my experience, while RSVP often times looks like a "clean approach" from an academic traffic mgmt approach, but operationally you got a whole 'nother set of headaches and there are other more practical ways of approaching this subject.

In scenarios where IP phones are generally stationary, you can "get away" with aggregate "reservations" for bandwidth.  The reasoning is like many other scenarios where you have to make a call as to whether you want to go with a dynamic or static mechanism.  While dynamic looks "cleaner", sometimes it buys you squat and makes it more difficult than it needs to be.  So, whether traffic mgmt task be accomplished by RSVP or some other means is another question. 

I have yet to run into a case where I could justify introducing the complexity of RSVP, and its potential strain on resources in a service provider network.  RSVP on an extremely limited basis in an enterprise network has proven useful, although generally there too there are more cost effective approaches when you look at the big picture.

Cheers,
Chris

--
Christian Kuhtz                                     Architecture, BellSouth.net
<ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm                       Atlanta, GA
                                                    "Speaking for myself only."
 --=====================_153836551==_.ALT-- From rsvp-owner@ISI.EDU Wed May 3 13:51: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 NAA07440 for ; Wed, 3 May 2000 13:51:46 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA14324 for rsvp-outgoing; Wed, 3 May 2000 09:00:43 -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 JAA14318 for ; Wed, 3 May 2000 09:00:41 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA16906 for ; Wed, 3 May 2000 09:00:43 -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 MAA04066; Wed, 3 May 2000 12:01:01 -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 MAA13389; Wed, 3 May 2000 12:00:20 -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 MAA21053; Wed, 3 May 2000 12:00: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 MAA08595; Wed, 3 May 2000 12:00:41 -0400 (EDT) Message-ID: <39104CC3.FFFB3C8A@mitre.org> Date: Wed, 03 May 2000 11:58: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: Dusan Sarvan CC: rsvp@ISI.EDU Subject: Re: RSVP on IP Phones References: <390FFF1D.368BADB@ascom.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Dusan Sarvan wrote: > 2. Is it feasible some centralized device such as a Call Manager to play RSVP on a behalf > of IP phones? No, not really. If the device is centralized then there really is no way for it to signal to the routers that are in the path between the phones to set up RSVP for the phones. Duncan Thomson From rsvp-owner@ISI.EDU Wed May 3 14:22: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 OAA08303 for ; Wed, 3 May 2000 14:22:17 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA16761 for rsvp-outgoing; Wed, 3 May 2000 09:36:57 -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 JAA16756 for ; Wed, 3 May 2000 09:36:56 -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 JAA05410; Wed, 3 May 2000 09:37:21 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA09359; Wed, 3 May 2000 16:37:20 GMT Date: Wed, 3 May 2000 16:37:20 GMT Message-Id: <200005031637.QAA09359@gra.isi.edu> To: rsvp@ISI.EDU, braden@ISI.EDU, dznamova@mil3.com Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Cc: zappala@cs.uoregon.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk Dana, My message and your reply appear to be ships passing in the night. I think that my message contains (implicitly) the answers to your questions, but you did not comment in any way on what I suggested. I think we are in deadlock. Bob Braden From rsvp-owner@ISI.EDU Wed May 3 14:22: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 OAA08313 for ; Wed, 3 May 2000 14:22:20 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA17160 for rsvp-outgoing; Wed, 3 May 2000 09:42:40 -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 JAA17154 for ; Wed, 3 May 2000 09:42:38 -0700 (PDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA06255; Wed, 3 May 2000 09:43:01 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA09365; Wed, 3 May 2000 16:43:01 GMT Date: Wed, 3 May 2000 16:43:01 GMT Message-Id: <200005031643.QAA09365@gra.isi.edu> To: rsvp@ISI.EDU, braden@ISI.EDU Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Cc: zappala@cs.uoregon.edu, lixia@cs.ucla.edu, mankin@ISI.EDU, braden@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk To the (soon-to-be-former ?) RSVP WG: I think there is a genuine technical issue here -- how RSVP deals with PIM SM -- which is not adequately dealt with in any existing Proposed Standard document. I *think* we have [well, really Daniel Zappala has] the outlines of a solution, but the details probably ought to be spelled out in a document. One way forward would be for someone to write an I-D and submit it as an individual contribution for Experimental or Informational status. Bob Braden From rsvp-owner@ISI.EDU Wed May 3 17:17: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 RAA11448 for ; Wed, 3 May 2000 17:17:57 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA28919 for rsvp-outgoing; Wed, 3 May 2000 12:41:09 -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 MAA28914 for ; Wed, 3 May 2000 12:41:08 -0700 (PDT) Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA28245 for ; Wed, 3 May 2000 12:41:10 -0700 (PDT) Received: from FRAPPU (dhcp1.eng.bellsouth.net [205.152.6.5]) by ns1.arch.bellsouth.net (8.9.1a/goaway) with SMTP id PAA15332; Wed, 3 May 2000 15:41:28 -0400 (EDT) From: "Christian Kuhtz" To: , "Dusan Sarvan" Cc: Subject: RE: RSVP on IP Phones Date: Wed, 3 May 2000 15:41:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <39104CC3.FFFB3C8A@mitre.org> Disposition-Notification-To: "Christian Kuhtz" Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Dusan Sarvan wrote: > > > 2. Is it feasible some centralized device such as a Call Manager > to play RSVP on a behalf > > of IP phones? > > No, not really. If the device is centralized then there really is > no way for it > to signal to the routers that are in the path between the phones to > set up RSVP > for the phones. I think there's another conceivable variant in which RSVP might play in this picture. Often times, when deploy call mgrs, you usually don't deploy just one. The inter-call mangler communication is something you could reserve with RSVP if you have a jungle of other devices out there. Given that call mgrs are generally in close proximity to the phones they serve, and call mgrs are usually a little further apart than the to the phones they each serve, you may have more resource contention across such likely "backbone" paths than from the phone to the call mgr. Again, highly architecture dependant and one needs to know a lot more about the big picture to be able to answer the original question appropriately. There's no general yes or no, although the general caveats for RSVP always apply. Cheers, Chris -- Christian Kuhtz, Sr. Network Architect Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From rsvp-owner@ISI.EDU Wed May 3 19:04:02 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12574 for ; Wed, 3 May 2000 19:04:01 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA03406 for rsvp-outgoing; Wed, 3 May 2000 14:16: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 OAA03401 for ; Wed, 3 May 2000 14:16:03 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id OAA02417 for ; Wed, 3 May 2000 14:16:04 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 May 2000 10:57:36 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2172.1); Wed, 3 May 2000 11:04:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4356.2 content-class: urn:content-classes:message Subject: RE: RSVP on IP Phones MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB529.2DD9A2AC" Date: Wed, 3 May 2000 10:58:25 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A601E43F46@STAY.platinum.corp.microsoft.com> Thread-Topic: RSVP on IP Phones Thread-Index: Ab+066OPjRd+c50DSCioc8QME1jYXQAOoj9w From: "Ramesh Pabbati" To: "Dusan Sarvan" , Cc: "Yoram Bernet" , "Villarica Alberto (E-mail)" X-OriginalArrivalTime: 03 May 2000 18:04:23.0640 (UTC) FILETIME=[03301580:01BFB52A] Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFB529.2DD9A2AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 1) On an device like IP telephone only a subset of RSVP functionality needs to be implemented and implementing this subset of RSVP may not increase in the cost of the phone. I have seen an implementation of this already interoperating with Windows 2000 implementation. Since the IP phones have a small number of active connections (<=3D 2) the amount of RSVP state needed to keep will also be small hence will not increase the memory needed on the IP phone.=20 =20 2) It is not feasible for some call manager (CM) to signal on behalf of the IP telephone as it requires call manager to be physically connected to all subnets for which CM needs to act as RSVP proxy. But CM can still do the following. * a) During call setup time CM can generate the PATH message IP phones needs to send out to the receiver and instruct the IP phone to send it at regular intervals.=20 * b) Once the other party answers the phone, CM can generate the RESV message and instruct the IP phone to send it towards the sender at regular intervals. * c) At the end of the call CM can do the same with PathTear messages. * d) Since the CM knows the Identity of the phone (like MAC address or serial number etc) it can generate a identity of the device originating the RSVP message. Since these CMs run a system with more h/w and sw/ than the IP phones, CM can generate a secure identity to be included in the RSVP messages. When the IP phones have SmartCard slots in them the identity of the caller is known to the CM hence they can add a secure user id to the RSVP messages (where by reduce the RSVP code size of the IP phones). * Since CM can be managed centrally the Tspec by each IP phone can be managed by CM as it generates the PATH message.=20 * When the IP phones get PathErr or ResvErr messages, CM can translate them on so that IP phones can display proper message and take appropriate action (busy tone etc) So even though CM can not act as a proxy, it can play an important role to reduce the complexity of the software on the IP phone. =20 Ramesh -----Original Message----- From: Dusan Sarvan [mailto:Dusan.Sarvan@ascom.ch] Sent: Wednesday, May 03, 2000 3:28 AM To: rsvp@ISI.EDU Subject: RSVP on IP Phones Hi,=20 I will be really appreciated if someone can answer my questions:=20 1. Since RSVP is pretty complex technology, implementing RSVP on the end devices such as an IP Phone makes this device pretty complex and probably expensive.=20 Could you tell me please if RSVP is in implementation on IP phones and is it=20 implemented by some companies on IP phones?=20 2. Is it feasible some centralized device such as a Call Manager to play RSVP on a behalf=20 of IP phones?=20 Thanks a lot in advance. ------_=_NextPart_001_01BFB529.2DD9A2AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
1) On=20 an device like IP telephone only a subset of RSVP functionality needs to = be=20 implemented and implementing this subset of RSVP may not increase in the = cost of=20 the phone. I have seen an implementation of this already interoperating = with=20 Windows 2000 implementation. Since the IP phones have a small number of = active=20 connections (<=3D 2) the amount of RSVP state needed to keep will = also be small=20 hence will not increase the memory needed on the IP phone. =
 
2) It=20 is not feasible for some call manager (CM) to signal on behalf of the IP = telephone as it requires call manager to be physically connected to all = subnets=20 for which CM needs to act as RSVP proxy. But CM can still do the=20 following.
  • a)=20 During call setup time CM can generate the PATH message IP phones = needs=20 to send out to the receiver and instruct the IP phone to send it at = regular=20 intervals.
  • b)=20 Once the other party answers the phone, CM can generate the RESV = message and=20 instruct the IP phone to send it towards the sender at regular=20 intervals.
  • c) At=20 the end of the call CM can do the same with PathTear=20 messages.
  • d)=20 Since the CM knows the Identity of the phone (like MAC address or = serial=20 number etc) it can generate a identity of the device originating = the RSVP=20 message. Since these CMs run a system with more h/w and sw/ than the = IP=20 phones, CM can generate a secure identity to be included in the RSVP = messages.=20 When the IP phones have SmartCard slots in them the identity of the = caller is=20 known to the CM hence they can add a secure user id to the RSVP = messages=20 (where by reduce the RSVP code size of the IP = phones).
  • Since=20 CM can be managed centrally the Tspec by each IP phone can be managed = by CM as=20 it generates the PATH message.
  • When=20 the IP phones get PathErr or ResvErr messages, CM can translate them = on so=20 that IP phones can display proper message and take appropriate action = (busy=20 tone etc)
So=20 even though CM can not act as a proxy, it can play an important role to = reduce=20 the complexity of the software on the IP phone.
 
Ramesh
-----Original Message-----
From: Dusan Sarvan=20 [mailto:Dusan.Sarvan@ascom.ch]
Sent: Wednesday, May 03, 2000 = 3:28=20 AM
To: rsvp@ISI.EDU
Subject: RSVP on IP=20 Phones

Hi,=20

I will be really appreciated if someone can answer = my=20 questions:=20

1. Since RSVP is pretty complex technology, = implementing=20 RSVP on the end
devices such as an IP = Phone=20 makes this device pretty complex and probably expensive. =
Could you tell me please if RSVP is  in implementation = on=20 IP phones and is it
implemented by = some=20 companies on IP phones?=20

2. Is it feasible some centralized device such as a = Call=20 Manager to play RSVP on a behalf
of=20 IP phones?=20

Thanks a lot in = advance.

------_=_NextPart_001_01BFB529.2DD9A2AC-- From rsvp-owner@ISI.EDU Thu May 4 10:52:59 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07268 for ; Thu, 4 May 2000 10:52:58 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA09075 for rsvp-outgoing; Thu, 4 May 2000 04:15: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 EAA09067 for ; Thu, 4 May 2000 04:15:24 -0700 (PDT) Received: from backrosh.inter.net.il (backrosh.inter.net.il [192.116.202.45]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA29618; Thu, 4 May 2000 04:15:23 -0700 (PDT) Received: from 192.116.213.130 ([192.116.213.130]) by backrosh.inter.net.il (8.10.1/8.10.1) with SMTP id e44BFjP13960; Thu, 4 May 2000 14:15:45 +0300 (IDT) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by 192.116.213.130 ; Thu, 04 May 2000 14:11:48 -0700 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 4 May 2000 14:14:43 +0300 Message-ID: From: Mervyn Kaplan To: "'rsvp@ISI.EDU'" , rsvp-test@ISI.EDU Subject: RSVP end point implementation Date: Thu, 4 May 2000 14:14:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-rsvp@ISI.EDU Precedence: bulk Hi, I am interested in implementing RSVP on an end point (on a VxWorks platform), without the functionality required for the routers. I thought of using the ISI implementation that is available to download, but it includes the code required on routers implementing RSVP. Does anybody know where I could get the source code for only an end point implementation? Or could somebody provide me with some pointers as to what I need to include from the ISI implementation for an end point implementation. Thanks Mervyn. From rsvp-owner@ISI.EDU Fri May 5 19:46:56 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01272 for ; Fri, 5 May 2000 19:46:55 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA16548 for rsvp-outgoing; Fri, 5 May 2000 15:00:12 -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 PAA16543 for ; Fri, 5 May 2000 15:00:11 -0700 (PDT) Received: from cs.uoregon.edu (vitalstatistix.cs.uoregon.edu [128.223.4.19]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id PAA14046; Fri, 5 May 2000 15:00:12 -0700 (PDT) Received: from dyna6-208.cs.uoregon.edu (dyna6-208.cs.uoregon.edu [128.223.6.208]) by cs.uoregon.edu (8.9.1a/8.9.1) with ESMTP id PAA05867; Fri, 5 May 2000 15:00:37 -0700 (PDT) Date: Fri, 05 May 2000 14:59:36 -0700 From: Daniel Zappala To: Bob Braden , rsvp@ISI.EDU cc: zappala@cs.uoregon.edu, lixia@cs.ucla.edu, mankin@ISI.EDU Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface Message-ID: <5028488.3166527576@dyna6-208.cs.uoregon.edu> In-Reply-To: <200005031643.QAA09365@gra.isi.edu> X-Mailer: Mulberry/2.0.0 (MacOS Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob -- At the very least, the current RSRR interface (version 1) ought to be an RFC since it is widely distributed in both mrouted and RSVP. I have a group of students who have been doing a GUI interface for it and we will be trying to wrap up the code and make it available by the end of the term. (This will let you diagram a network, then display real-time updates of the multicast routing state for (S,G) by calling RSRR at each of the nodes.) My (limited) understanding of the IETF is that things that go into RFCs have been implemented/tested so I had thought the interaction with PIM would still only qualify for an Internet draft. If the standard is looser than this, and you would just like me to turn the current (somewhat speculative) draft into an RFC, I can do that. I still think it would be a good idea to get some experience with PIM and RSRR, and I could probably find a student to do that over the summer. Daniel Zappala zappala@cs.uoregon.edu --On Wednesday, May 3, 2000 4:43 PM +0000 Bob Braden wrote: > > To the (soon-to-be-former ?) RSVP WG: I think there is a genuine > technical issue here -- how RSVP deals with PIM SM -- which is not > adequately dealt with in any existing Proposed Standard document. I > *think* we have [well, really Daniel Zappala has] the outlines of a > solution, but the details probably ought to be spelled out in a > document. > > One way forward would be for someone to write an I-D and submit it > as an individual contribution for Experimental or Informational > status. > > Bob Braden > From rsvp-owner@ISI.EDU Wed May 10 10:53: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 KAA27211 for ; Wed, 10 May 2000 10:53:22 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA27852 for rsvp-outgoing; Wed, 10 May 2000 04:59:20 -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 EAA27847 for ; Wed, 10 May 2000 04:59:18 -0700 (PDT) Received: from mail.holix.com.tw ([210.65.24.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id EAA08664 for ; Wed, 10 May 2000 04:59:16 -0700 (PDT) Message-Id: <200005101159.EAA08664@venera.isi.edu> Received: from tang (c173.h061013123.is.net.tw [61.13.123.173]) by mail.holix.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id KK1AN5NZ; Wed, 10 May 2000 19:11:06 +0800 From: "SCC" Reply-To: CappuccinoJ@yahoo.com.tw Subject: ·Q§ä³Ì·sªº¡iµ{¦¡¡j¶Ü To: bettyya@ISI.EDU X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 10 May 2000 18:36:16 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ¢¨¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢© ¢i¡@¡@ ¥»¼s§i«Y©e°U¡y ¤j ¥þ ¡z ¼s§i¦Û°Êµo«H²Î¥N¬°µo¥X ¢i ¢i ¦p±z¤£·Q¦¬¨ì¦¹¼s§i½Ð§Y¨è§R°£,¨Ã½Ð±µ¨ü§Ú­Ìªº¹Dºp¡C ¢i ¢i http://members.spree.com/family/jooy/email.html ¢i ¢ª¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¢« ¦n¤ù¤@ªi±µ¤@ªi¡A¥R¹êªº¤º®e¡A§¹µ½ªº¤ÀÃþ¡A¸Ô²Óªº¸Ñ»¡¡A§¹¾ãªº¯}¸Ñ¬O¥»¯¸ªº¯SÂI¡I ·Q§ä³Ì·sªº¡iµ{¦¡¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹CÀ¸¡j¶Ü¡H ·Q§ä³Ì·sªº¡i­µ¼Ö¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹q¼v¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¤u§@³nÅé¡j¶Ü¡H ¡iºâ©R¡j¡A¡iªÑ¥«¤ÀªR¡j¡A¡i¥®¨à±Ð¾Ç¡j¡A¡i¤é¤å³nÅé¡j¡A¡i®a®x¹B¥Î¡j ¡i¬ü¤u°Êµe¡j¡A¡i½Ķ¡j¡A¡i¦Ê¬ì¡j¡È¡È¡I ¤@­Ó¨}¤ß¸gÀ窺¸É¯¸¡A¥R¹êªº¤º®e¡A2000¦h®Mªº·s³nÅé¡A±z­n§äªº§Ú­Ì³o¸Ì³£¦³¡C 5¤ë¶W±j·s¤ù±À¥X 200 ¦h®M³nÅé¡C ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ§¹¾ã"¥ø·~"¥¿¦¡ª© Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ¼Ð·Ç¥¿¦¡ª©¡i³æ¤ù¸Ë¡j Microsoft PhotoDraw 2000 ¡ª¤é¤å¡ª±M·~¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft SITE SERVER V3.0 "¤é¤å""¥ø·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional Edition ¤é¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional INT'L Edition ­^¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Technical Edition ¤é¤å"¤uµ{"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISUAL STUDIO MSDN LIBRARY V6.01A ¤é¤å¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows 98 ²Ä¤Gª© Second Edition ¤¤¤å"²Åé"¼Ð·Ç¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows Millennium B2 V4.90.2490 "¤¤¤å"¥úºÐ§¹¾ãBETAª© Microsoft Windows Millennium B2 V4.90.2491 "­^¤å"¥úºÐ§¹¾ãBETAª© MS Systems Management Server V2.0 SERVER PACK 1 "­^¤å"¥úºÐ§¹¾ã¥¿¦¡ª© MySQL+LinuxPPC R5 ¤¤¤å¤Æ For Linux NeMo Dev V1.0.1 -- Nokia Data suite V3.0 OBJECTIVITY V5.2 ­^¤åª© For Linux Out Post 69 Pinnacle Studio 400 V1.05 PoolDraw V5.0 PROTEL 99 Service Pack 3 ­^¤å¯}¸Ñ¡©§¹¾ã¡¨¥[±jª© (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ÞÃZ¤J«Ç (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ë²y³¥À\°O (¶W¯ÅµL¼Ä´xªùª¯)¡G«c¤MÃä½t ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡y¥®¨à¦¨ªø¨t¦C¢°¡z ¡y¥®¨à¦¨ªø¨t¦C¢±¡z ¡y¥®¨à¦¨ªø¨t¦C¢³¡z ¡i¥®¨à¬ü»yµ£¸Ü¥@¬É¡Ï¥®¸X¶éµ£ÁÁABC¡j¤j¦X¿è ¡iµ£ÁÁ°Û¹C¡Ï¥®¨àÃý«ß¡j¤j¦X¿è ¡iµÛ¦WJAVA³]­p°ÓJAVA¤¬°Ê¦¡±Ð¾Ç¡j­^¤å§¹¾ã¥¿¦¡ª© 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢° 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢± 21¥@¬ö¬y¦æMP3±M¿è(157) 3D ¾·~«OÄÖ²y PRO Bowl 3D ¢¸¢¸¦~¥@¬ö¥½¤­¤j¤Ñ¦Z²{³õ«lºq¹ê¿ý ACER EASY AXESS V1.30.43 ¡u§A¦n¶Ü¡I¡v¼v­µ·¾³q¨t²Î Adobe Acrobat v4.05 ¥¿¦¡ª© Adobe InDesign ­^¤åª© For MAC Advanced Design System V1.3 Artisoft I.Share V3.5 ¥¿¦¡ª© BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- Blue Point Linux ORC V1.0 ¤¤¤åª© For PC BOYZONE ¨k«Ä¯S°Ï¦X°Û¹Î BuySite v6.1 ¥¿¦¡ª© (»Ý¦w¸ËSQL) C¢ÒÀs¡Ð¦h´CÅé¡m²³ø¡®±Ð§÷¡n Corel WordPerfect Office 2000 ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª©¡j Cumulus Single User Edition V5.0.1 Build 160 DBMaker V3.51 ­^¤åª©+¤¤¤åª© For Linux Deneba Canvas 7 for MAC Dyno 2000 V3.08 ¥¿¦¡ª© FormTool V4.0 IBM Lotus SmartSuite Millenium Edition V9.5.2 ¥¿¦¡ª© ICEM CFD SOLARIS EDITION V4.0.7 Intel LANDesk Management Suite V6.3 INTERNETºô­¶»s§@±Ð¾Ç ??? ¡Ï Macromedia Director V8.0 ­^¤åª© For MAC Macromedia DreamWeaver 3.0 ­^¤åª© For MAC Majesty:The Fqantasy Kingdom SIM McAfee Total Virus Defense Suite ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª© Metacreation Painter V5.5 Web Edition CT "¤¤¤å"±M·~¥¿¦¡ª© MGI YM Digital Makeover Magic ¥¿¦¡ª© Microsoft Creative Writer 2 PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤@¶° PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤G¶° PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤T¶° PVCS Professional Plus V2.5.00G Remedy Action Request System V4.0.3 ¥¿¦¡ª© Sarah McLachlan²ï©Ô§J³Ò§JÄõ ServerGuard ¦øªA¾¹¨¾¤õÀð For Linux Slackware 7.0 For PC SMART CAM V11.0 ­^¤å"¯}¸Ñ"¥úºÐ§¹¾ãª© Sonnet V6.0a SPICE GIRL »¶©f¦X°Û¹Î Statistica AX V5.5 ¡i¦h°ê»y¨¥¡j¥¿¦¡ª© Tango 2000 Application Server TestStand V1.0.2 ¥¿¦¡ª© The Merck Index On CD-ROM V12.3 Top of the Pops Mix Factory 2 Transcender A+ CoreCert V1.0 ¥¿¦¡ª© TurboLinux 4.0 ¤¤¤åª© For PC Veritas Backup Exec V8.0 WinLinux 2000 ­^¤åª© For PC XYZ 2000¦~¢²¤ë³Ì·s¦è¬v¬y¦æ±M¿è¢Û¢Ñ¢Ò¢±¢·¢µ XYZ 2000¦~¢²¤ë³Ì·s¦è¬v¬y¦æ±M¿è¢Û¢Ñ¢Ò¢±¢·¢¶ XYZ MP3-COOL ²Ä¢°¢¯¢¯¿è XYZ MP3-COOL ²Ä¢°¢¯¢°¿è XYZ MP3-COOL ²Ä¢°¢¯¢±¿è XYZ MP3-COOL ²Ä¢°¢¯¢²¿è XYZ MP3-COOL ²Ä¢°¢¯¢³¿è XYZ MP3-COOL ²Ä¢¸¢µ¿è XYZ MP3-COOL ²Ä¢¸¢¶¿è XYZ MP3-COOL ²Ä¢¸¢·¿è XYZ MP3-COOL ²Ä¢¸¢¸¿è ¢æÀÉ®× ²Ä¥|¿è Y2K¥ú³t¾Ô±N ¤T°¦²´¢²¢æ¢²¢wÂà½ü¤ý¤Û¹Ú ¤T°êºt¸q °Ñ ¡i¤¤¤åª©¡j ¤k¯«¾Ç¶é ¡i¤¤¤åª©¡j ¤¤°ê´Ñ¤ý¡i¤¤¤åª©¡j ¤Û»R¤Ñ¨Ï(¹Ú¤Ûª©)¡i¤¤¤åª©¡j ¤é»y°ò¦¤Jªù ¢´¢¯­µ®Ô®Ô¤W¤f¡i¤¤¤åª©¡j ¤ýµá ¡i°Û¹C¤j¥@¬É¡j ¥j®õº¸ 2000 Tyrian 2000 ¥¢¸¨ªº¥j¤å©ú¡i¤¤¤åª©¡j ¥Í¦º¨M¾Ô¢±¢w¥½¤é¶Ç»¡ Life or Death 2 : Legend of Doomsday ¥Ö¥d¥C¢w¤f³U©Çª«"©Çª«¥d¤ù"¤j§@¾Ô Pokemon Play It! Trading CardGame ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤@¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤C¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤E¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤G¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤K¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤@¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤G¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤T¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¥|¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤­¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤»¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¥|¶°¡G ¦t©z¯Sĵ¶¤ PHOENIX ¨D±B365¤é¢º¡i¤¤¤åª©¡j ¨ßÄ_Ä_¾úÀI°O BUGS BUNNY:Lost in Time ©R¬ÛÀ]¤§¥|¬W©R²z»P¤R¨ö¦N¤¿ ©Ê¥»µ½¨t¦C ²Ä¤@¿è¡G ªZ¸Ëª½ª@¾÷ GUNSHIP ª¾ÃѦʬìÄ_®w ª¾ÃѦʬìÄ_®w ªíºt¤u§@§{(§Ú©M§Ú©M¥L©M¥L) «_ÀI¢± RISK 2 «¢°Õ²r¨k¨q¡m¥¿¦b¤W¬Mªº·s¤ù¡n ¬O½Ö·dªº°­¢³(¥¼¤W¬M) ¬ÛÁn¥ËªÙ¡ã½Ö°äÄV§Ú ¬ü°ê¾´Î¤jÁp·ù2001 ¡i¯}¸Ñª©¡j ¬ü»y§Ö¨®¢w³y¦r¤u¼t¡m¤¤¤åª©¡n ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª© ---­Ó©Ê¦r«¬±M¿è ¤¤¤åª© ­Ù¦J¡ã­ì®¶«L¶Ç©_ ¥þ®M¹q¤l®Ñ ®üÅQ¤ý Ancient Conques °hÅ]¶Ç»¡¡i¤¤¤åª©¡j °¨¹aÁ¦¤j§L MILITATO °ª¤¤½g¡m¥~°ê¾ú¥v+¦a²z+¥»°ê¦a²z¤j¶iÀ»¡n¡i3¦X1¡j °«°} Demolition Racer °ÊºAºô­¶»s§@±Ð¾Ç????? ¡i¢±¦X¢°¡j °ò¦¨àµ£¬ü»y °ö¼W¯Z ±þ¤H¤£¯w²´¡m¥¿¦b¤W¬Mªº·s¤ù¡n ²×·¥¾Ô°Ï2 Battle Zoon ¢º ²ö¤å½«¡ã©¿µM¤§¶¡VCD ³¨³½«a­xÁÉ Championship BASS ³¶¡Ð¬ü¬Ü¼g¯uÀ]¡i¤¤¤åª©¡j ³½ªº´_¤³ Fish's Revenge ³Ð¥@¶Ç©_¢w¶ë¬£©Ô¤§®Ö Septerra Core ¡i ³Ð·N®a¢w½ì¨ý¹q¸£¤Jªù ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´cÆF¤J«I The Devil Inside µ£¥d«Ø¿v¢± µØ±d"¦r¥Ñ¦r¦b °µ¦Û¤v" µØ±d¦r«¬¶W­Èª© µêÀÀ¥úºÐ 2000 V5.1 ¤¤¤å¥¿¦¡ª©¡m¤ä´©Windows2000¡n ¶W¯Å¾÷¨®ÁÉ2000 SuperBiKe 2000 SBK ¶W¯à¤O®æ°«2012¡i¤¤¤åª©¡j ¶WÀÀ¯u¼²²y¢² Virtual Pool Hall ¶Ã¥@©_½t¡i¤¤¤åª©¡j ¶Ä§L¾Ô³õ Soldier of Fortune ·L³n NT 4.0 TERMINAL SERVER SP4 "¤é¤å"¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n NT 4.0 TERMINAL SERVER SP5 "­^¤å"¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n WINDOWS 2000 §@·~¨t²Î³Ì·sª©¡i¤ÀªR/°£¿ù/¤ä´©¡j¥úºÐ ·L³n WINDOWS 2000 §@·~¨t²Î³Ì·sª©¡i¤ÀªR/°£¿ù/¤ä´©¡j¥úºÐ ­^¤åª© ·L³n WINDOWS 2000 µwÅé¬Û®e´ú¸Õµ{¦¡ V9.0 ­^¤å¥¿¦¡ª© ·L³n Windows NT Workstation & Server 4.0 Service Pack 6A "¤é¤å"¥ú ·L³n Windows NT Workstation 4.0 WITH Service Pack 6 ¤¤¤å¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n´Î²y2001 MS Baseball 2001 ·s¤d¸U­Ó¬°¤°»ò¨t¦C¢w--- ¸U¯«·µ ¸õ´Ñ¤pºëÆF¡i¤¤¤åª©¡j ¹Ú¤Û½Õ°s®v Last Call ¹ê¥Î¥ßÅé¥d¤ù¤T¤ÀÄÁ³t¦¨ ¢Ò¢×¢ç ¹ê¥ÎÆ[¥ú¤é»y½g ¡Ï ª½Ä±¦¡¤é»y±Ð¾Çªk¡m¢±¦X¢°¡n ºu¥Û¥i¼Ö ºu¥Û°Û¤ù¡ã¥Ï±¼¤j·Ð¸£ ºu¥Û°Û¤ù¡ã±¡ºq¤j´_¬¡ ºu¥Û°Û¤ù¡ã·R«ë¤j©M¸Ñ ºÆ¨g¼³§JµP¢± Card Crazy 2 ºÐ¥¿¦¡ª© ºô¸ô¥æ¤Í³t¦¨(¤¤¤åª©) »hç°ªº¥@¬É (¤¤¤åª©) »Èªe¾Ô°ê¦C¶Ç¢å¢w¬P®üÅQ¥D ¼Ú¬w¨¬²y¤jÁp·ù Euro League Football ½a ¤H MP3 ­µ¼Ö ¡] 45 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 46 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 47 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 48 ¡^ ½a ¤H MP3 ­µ¼Ö ( 49 ) ½²¨ÌªL¡ã§Ú¥i¥H ¾Ô°«¯«±N¢³ ¾÷°Ê¤H ACTION MAN À±ÁÉ¨È Messiah Àô«O¤p­¸«L¡ã¤¤¤åª© Á­½¸¡ãIPISÁ­½¸ONEºë¿ï¶°1 MTV Â׵آ±¢¯¢¯¢¯¥þ¥Á¶}°Û VCD Äúµ§¤p·s ¡Ï ¤Ó¶§¯«¢±¸¹ ¡Ï ¤Ó¶§¯«¢²¸¹¡m¢²¦X¢°¡n¡i¤¤¤åª©¡j Å]ªkªù¤§¤Q¦r­x Å]ªkªù¤§­^¶¯µL¼Ä¢²¢w¦º¤`¤§¼v Heroes of Might and Magic ¢» :TheShadow of Death ÅåÁn¦y¥s¢²¡m¥¿¦b¤W¬Mªº·s¤ù¡n ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b From rsvp-owner@ISI.EDU Thu May 11 15:14:59 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06303 for ; Thu, 11 May 2000 15:14:59 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA01365 for rsvp-outgoing; Thu, 11 May 2000 09:56: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 JAA01352 for ; Thu, 11 May 2000 09:56:24 -0700 (PDT) Received: from mail.holix.com.tw ([210.65.24.2]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id JAA01367 for ; Thu, 11 May 2000 09:56:21 -0700 (PDT) Message-Id: <200005111656.JAA01367@venera.isi.edu> Received: from tang (as20po44.ht.ficnet.net.tw [210.243.73.44]) by mail.holix.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id KWSF3CF3; Fri, 12 May 2000 00:58:30 +0800 From: "SCC" Reply-To: CappuccinoJ@yahoo.com.tw Subject: ·Q§ä³Ì·sªº¡iµ{¦¡¡j¶Ü To: bettyya@ISI.EDU X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Thu, 11 May 2000 23:48:02 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ¢¨¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢v¢© ¢i¡@¡@ ¥»¼s§i«Y©e°U¡y ¤j ¥þ ¡z ¼s§i¦Û°Êµo«H²Î¥N¬°µo¥X ¢i ¢i ¦p±z¤£·Q¦¬¨ì¦¹¼s§i½Ð§Y¨è§R°£,¨Ã½Ð±µ¨ü§Ú­Ìªº¹Dºp¡C ¢i ¢i http://members.spree.com/family/jooy/email.html ¢i ¢ª¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¡Ä¢« ¦n¤ù¤@ªi±µ¤@ªi¡A¥R¹êªº¤º®e¡A§¹µ½ªº¤ÀÃþ¡A¸Ô²Óªº¸Ñ»¡¡A§¹¾ãªº¯}¸Ñ¬O¥»¯¸ªº¯SÂI¡I ·Q§ä³Ì·sªº¡iµ{¦¡¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹CÀ¸¡j¶Ü¡H ·Q§ä³Ì·sªº¡i­µ¼Ö¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹q¼v¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¤u§@³nÅé¡j¶Ü¡H ¡iºâ©R¡j¡A¡iªÑ¥«¤ÀªR¡j¡A¡i¥®¨à±Ð¾Ç¡j¡A¡i¤é¤å³nÅé¡j¡A¡i®a®x¹B¥Î¡j ¡i¬ü¤u°Êµe¡j¡A¡i½Ķ¡j¡A¡i¦Ê¬ì¡j¡È¡È¡I ¤@­Ó¨}¤ß¸gÀ窺¸É¯¸¡A¥R¹êªº¤º®e¡A2000¦h®Mªº·s³nÅé¡A±z­n§äªº§Ú­Ì³o¸Ì³£¦³¡C 5¤ë¶W±j·s¤ù±À¥X 200 ¦h®M³nÅé¡C ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ§¹¾ã"¥ø·~"¥¿¦¡ª© Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ¼Ð·Ç¥¿¦¡ª©¡i³æ¤ù¸Ë¡j Microsoft PhotoDraw 2000 ¡ª¤é¤å¡ª±M·~¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft SITE SERVER V3.0 "¤é¤å""¥ø·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional Edition ¤é¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional INT'L Edition ­^¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Technical Edition ¤é¤å"¤uµ{"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISUAL STUDIO MSDN LIBRARY V6.01A ¤é¤å¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows 98 ²Ä¤Gª© Second Edition ¤¤¤å"²Åé"¼Ð·Ç¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows Millennium B2 V4.90.2490 "¤¤¤å"¥úºÐ§¹¾ãBETAª© Microsoft Windows Millennium B2 V4.90.2491 "­^¤å"¥úºÐ§¹¾ãBETAª© MS Systems Management Server V2.0 SERVER PACK 1 "­^¤å"¥úºÐ§¹¾ã¥¿¦¡ª© MySQL+LinuxPPC R5 ¤¤¤å¤Æ For Linux NeMo Dev V1.0.1 -- Nokia Data suite V3.0 OBJECTIVITY V5.2 ­^¤åª© For Linux Out Post 69 Pinnacle Studio 400 V1.05 PoolDraw V5.0 PROTEL 99 Service Pack 3 ­^¤å¯}¸Ñ¡©§¹¾ã¡¨¥[±jª© (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ÞÃZ¤J«Ç (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ë²y³¥À\°O (¶W¯ÅµL¼Ä´xªùª¯)¡G«c¤MÃä½t ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡y¥®¨à¦¨ªø¨t¦C¢°¡z ¡y¥®¨à¦¨ªø¨t¦C¢±¡z ¡y¥®¨à¦¨ªø¨t¦C¢³¡z ¡i¥®¨à¬ü»yµ£¸Ü¥@¬É¡Ï¥®¸X¶éµ£ÁÁABC¡j¤j¦X¿è ¡iµ£ÁÁ°Û¹C¡Ï¥®¨àÃý«ß¡j¤j¦X¿è ¡iµÛ¦WJAVA³]­p°ÓJAVA¤¬°Ê¦¡±Ð¾Ç¡j­^¤å§¹¾ã¥¿¦¡ª© 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢° 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢± 21¥@¬ö¬y¦æMP3±M¿è(157) 3D ¾·~«OÄÖ²y PRO Bowl 3D ¢¸¢¸¦~¥@¬ö¥½¤­¤j¤Ñ¦Z²{³õ«lºq¹ê¿ý ACER EASY AXESS V1.30.43 ¡u§A¦n¶Ü¡I¡v¼v­µ·¾³q¨t²Î Adobe Acrobat v4.05 ¥¿¦¡ª© Adobe InDesign ­^¤åª© For MAC Advanced Design System V1.3 Artisoft I.Share V3.5 ¥¿¦¡ª© BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- Blue Point Linux ORC V1.0 ¤¤¤åª© For PC BOYZONE ¨k«Ä¯S°Ï¦X°Û¹Î BuySite v6.1 ¥¿¦¡ª© (»Ý¦w¸ËSQL) C¢ÒÀs¡Ð¦h´CÅé¡m²³ø¡®±Ð§÷¡n Corel WordPerfect Office 2000 ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª©¡j Cumulus Single User Edition V5.0.1 Build 160 DBMaker V3.51 ­^¤åª©+¤¤¤åª© For Linux Deneba Canvas 7 for MAC Dyno 2000 V3.08 ¥¿¦¡ª© FormTool V4.0 IBM Lotus SmartSuite Millenium Edition V9.5.2 ¥¿¦¡ª© ICEM CFD SOLARIS EDITION V4.0.7 Intel LANDesk Management Suite V6.3 INTERNETºô­¶»s§@±Ð¾Ç ??? ¡Ï Macromedia Director V8.0 ­^¤åª© For MAC Macromedia DreamWeaver 3.0 ­^¤åª© For MAC Majesty:The Fqantasy Kingdom SIM McAfee Total Virus Defense Suite ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª© Metacreation Painter V5.5 Web Edition CT "¤¤¤å"±M·~¥¿¦¡ª© MGI YM Digital Makeover Magic ¥¿¦¡ª© Microsoft Creative Writer 2 PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤@¶° PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤G¶° PUFFY ©¬¦m ­µ¼Ö¼Ö¶é ²Ä¤T¶° PVCS Professional Plus V2.5.00G Remedy Action Request System V4.0.3 ¥¿¦¡ª© Sarah McLachlan²ï©Ô§J³Ò§JÄõ ServerGuard ¦øªA¾¹¨¾¤õÀð For Linux Slackware 7.0 For PC SMART CAM V11.0 ­^¤å"¯}¸Ñ"¥úºÐ§¹¾ãª© Sonnet V6.0a SPICE GIRL »¶©f¦X°Û¹Î Statistica AX V5.5 ¡i¦h°ê»y¨¥¡j¥¿¦¡ª© Tango 2000 Application Server TestStand V1.0.2 ¥¿¦¡ª© The Merck Index On CD-ROM V12.3 Top of the Pops Mix Factory 2 Transcender A+ CoreCert V1.0 ¥¿¦¡ª© TurboLinux 4.0 ¤¤¤åª© For PC Veritas Backup Exec V8.0 WinLinux 2000 ­^¤åª© For PC XYZ 2000¦~¢²¤ë³Ì·s¦è¬v¬y¦æ±M¿è¢Û¢Ñ¢Ò¢±¢·¢µ XYZ 2000¦~¢²¤ë³Ì·s¦è¬v¬y¦æ±M¿è¢Û¢Ñ¢Ò¢±¢·¢¶ XYZ MP3-COOL ²Ä¢°¢¯¢¯¿è XYZ MP3-COOL ²Ä¢°¢¯¢°¿è XYZ MP3-COOL ²Ä¢°¢¯¢±¿è XYZ MP3-COOL ²Ä¢°¢¯¢²¿è XYZ MP3-COOL ²Ä¢°¢¯¢³¿è XYZ MP3-COOL ²Ä¢¸¢µ¿è XYZ MP3-COOL ²Ä¢¸¢¶¿è XYZ MP3-COOL ²Ä¢¸¢·¿è XYZ MP3-COOL ²Ä¢¸¢¸¿è ¢æÀÉ®× ²Ä¥|¿è Y2K¥ú³t¾Ô±N ¤T°¦²´¢²¢æ¢²¢wÂà½ü¤ý¤Û¹Ú ¤T°êºt¸q °Ñ ¡i¤¤¤åª©¡j ¤k¯«¾Ç¶é ¡i¤¤¤åª©¡j ¤¤°ê´Ñ¤ý¡i¤¤¤åª©¡j ¤Û»R¤Ñ¨Ï(¹Ú¤Ûª©)¡i¤¤¤åª©¡j ¤é»y°ò¦¤Jªù ¢´¢¯­µ®Ô®Ô¤W¤f¡i¤¤¤åª©¡j ¤ýµá ¡i°Û¹C¤j¥@¬É¡j ¥j®õº¸ 2000 Tyrian 2000 ¥¢¸¨ªº¥j¤å©ú¡i¤¤¤åª©¡j ¥Í¦º¨M¾Ô¢±¢w¥½¤é¶Ç»¡ Life or Death 2 : Legend of Doomsday ¥Ö¥d¥C¢w¤f³U©Çª«"©Çª«¥d¤ù"¤j§@¾Ô Pokemon Play It! Trading CardGame ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤@¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤C¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤E¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤G¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤K¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤@¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤G¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¤T¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¥|¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤Q¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤­¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¤»¶°¡G ¥ø·~ºÞ²z¨t¦CÁ¿®y¡ã²Ä¥|¶°¡G ¦t©z¯Sĵ¶¤ PHOENIX ¨D±B365¤é¢º¡i¤¤¤åª©¡j ¨ßÄ_Ä_¾úÀI°O BUGS BUNNY:Lost in Time ©R¬ÛÀ]¤§¥|¬W©R²z»P¤R¨ö¦N¤¿ ©Ê¥»µ½¨t¦C ²Ä¤@¿è¡G ªZ¸Ëª½ª@¾÷ GUNSHIP ª¾ÃѦʬìÄ_®w ª¾ÃѦʬìÄ_®w ªíºt¤u§@§{(§Ú©M§Ú©M¥L©M¥L) «_ÀI¢± RISK 2 «¢°Õ²r¨k¨q¡m¥¿¦b¤W¬Mªº·s¤ù¡n ¬O½Ö·dªº°­¢³(¥¼¤W¬M) ¬ÛÁn¥ËªÙ¡ã½Ö°äÄV§Ú ¬ü°ê¾´Î¤jÁp·ù2001 ¡i¯}¸Ñª©¡j ¬ü»y§Ö¨®¢w³y¦r¤u¼t¡m¤¤¤åª©¡n ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª© ---­Ó©Ê¦r«¬±M¿è ¤¤¤åª© ­Ù¦J¡ã­ì®¶«L¶Ç©_ ¥þ®M¹q¤l®Ñ ®üÅQ¤ý Ancient Conques °hÅ]¶Ç»¡¡i¤¤¤åª©¡j °¨¹aÁ¦¤j§L MILITATO °ª¤¤½g¡m¥~°ê¾ú¥v+¦a²z+¥»°ê¦a²z¤j¶iÀ»¡n¡i3¦X1¡j °«°} Demolition Racer °ÊºAºô­¶»s§@±Ð¾Ç????? ¡i¢±¦X¢°¡j °ò¦¨àµ£¬ü»y °ö¼W¯Z ±þ¤H¤£¯w²´¡m¥¿¦b¤W¬Mªº·s¤ù¡n ²×·¥¾Ô°Ï2 Battle Zoon ¢º ²ö¤å½«¡ã©¿µM¤§¶¡VCD ³¨³½«a­xÁÉ Championship BASS ³¶¡Ð¬ü¬Ü¼g¯uÀ]¡i¤¤¤åª©¡j ³½ªº´_¤³ Fish's Revenge ³Ð¥@¶Ç©_¢w¶ë¬£©Ô¤§®Ö Septerra Core ¡i ³Ð·N®a¢w½ì¨ý¹q¸£¤Jªù ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´Iº¸¯S¯À§÷»È¦æ¢w¹Ï®×Á`¶× ´cÆF¤J«I The Devil Inside µ£¥d«Ø¿v¢± µØ±d"¦r¥Ñ¦r¦b °µ¦Û¤v" µØ±d¦r«¬¶W­Èª© µêÀÀ¥úºÐ 2000 V5.1 ¤¤¤å¥¿¦¡ª©¡m¤ä´©Windows2000¡n ¶W¯Å¾÷¨®ÁÉ2000 SuperBiKe 2000 SBK ¶W¯à¤O®æ°«2012¡i¤¤¤åª©¡j ¶WÀÀ¯u¼²²y¢² Virtual Pool Hall ¶Ã¥@©_½t¡i¤¤¤åª©¡j ¶Ä§L¾Ô³õ Soldier of Fortune ·L³n NT 4.0 TERMINAL SERVER SP4 "¤é¤å"¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n NT 4.0 TERMINAL SERVER SP5 "­^¤å"¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n WINDOWS 2000 §@·~¨t²Î³Ì·sª©¡i¤ÀªR/°£¿ù/¤ä´©¡j¥úºÐ ·L³n WINDOWS 2000 §@·~¨t²Î³Ì·sª©¡i¤ÀªR/°£¿ù/¤ä´©¡j¥úºÐ ­^¤åª© ·L³n WINDOWS 2000 µwÅé¬Û®e´ú¸Õµ{¦¡ V9.0 ­^¤å¥¿¦¡ª© ·L³n Windows NT Workstation & Server 4.0 Service Pack 6A "¤é¤å"¥ú ·L³n Windows NT Workstation 4.0 WITH Service Pack 6 ¤¤¤å¥úºÐ§¹¾ã¥¿¦¡ª© ·L³n´Î²y2001 MS Baseball 2001 ·s¤d¸U­Ó¬°¤°»ò¨t¦C¢w--- ¸U¯«·µ ¸õ´Ñ¤pºëÆF¡i¤¤¤åª©¡j ¹Ú¤Û½Õ°s®v Last Call ¹ê¥Î¥ßÅé¥d¤ù¤T¤ÀÄÁ³t¦¨ ¢Ò¢×¢ç ¹ê¥ÎÆ[¥ú¤é»y½g ¡Ï ª½Ä±¦¡¤é»y±Ð¾Çªk¡m¢±¦X¢°¡n ºu¥Û¥i¼Ö ºu¥Û°Û¤ù¡ã¥Ï±¼¤j·Ð¸£ ºu¥Û°Û¤ù¡ã±¡ºq¤j´_¬¡ ºu¥Û°Û¤ù¡ã·R«ë¤j©M¸Ñ ºÆ¨g¼³§JµP¢± Card Crazy 2 ºÐ¥¿¦¡ª© ºô¸ô¥æ¤Í³t¦¨(¤¤¤åª©) »hç°ªº¥@¬É (¤¤¤åª©) »Èªe¾Ô°ê¦C¶Ç¢å¢w¬P®üÅQ¥D ¼Ú¬w¨¬²y¤jÁp·ù Euro League Football ½a ¤H MP3 ­µ¼Ö ¡] 45 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 46 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 47 ¡^ ½a ¤H MP3 ­µ¼Ö ¡] 48 ¡^ ½a ¤H MP3 ­µ¼Ö ( 49 ) ½²¨ÌªL¡ã§Ú¥i¥H ¾Ô°«¯«±N¢³ ¾÷°Ê¤H ACTION MAN À±ÁÉ¨È Messiah Àô«O¤p­¸«L¡ã¤¤¤åª© Á­½¸¡ãIPISÁ­½¸ONEºë¿ï¶°1 MTV Â׵آ±¢¯¢¯¢¯¥þ¥Á¶}°Û VCD Äúµ§¤p·s ¡Ï ¤Ó¶§¯«¢±¸¹ ¡Ï ¤Ó¶§¯«¢²¸¹¡m¢²¦X¢°¡n¡i¤¤¤åª©¡j Å]ªkªù¤§¤Q¦r­x Å]ªkªù¤§­^¶¯µL¼Ä¢²¢w¦º¤`¤§¼v Heroes of Might and Magic ¢» :TheShadow of Death ÅåÁn¦y¥s¢²¡m¥¿¦b¤W¬Mªº·s¤ù¡n ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b From rsvp-owner@ISI.EDU Sat May 13 06:00: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 GAA07201 for ; Sat, 13 May 2000 06:00:17 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA05418 for rsvp-outgoing; Sat, 13 May 2000 00:59:55 -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 AAA05412 for ; Sat, 13 May 2000 00:59:53 -0700 (PDT) Received: from msc.bstec.net.tw (msc.bstec.net.tw [210.200.71.9]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12293 for ; Sat, 13 May 2000 00:59:51 -0700 (PDT) Received: from tang (as20po181.ht.ficnet.net.tw [210.243.73.181]) by msc.bstec.net.tw (8.9.2/8.8.8) with ESMTP id QAA29113; Sat, 13 May 2000 16:28:22 GMT (envelope-from light777@kimo.com.tw) Message-Id: <200005131628.QAA29113@msc.bstec.net.tw> From: "light777" Reply-To: light777@kimo.com.tw Subject: ºô¸ô¥Í¬¡À] To: light777@msc.bstec.net.tw X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sat, 13 May 2000 15:42:25 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ---------------------------------------------------- ¥»¼s§i«Y©e°U­¸¯q³Ð·N¦æ¾P¥N¬°µo¥X,¦p±z¤£·Q¦¬¨ì¦¹¼s§i, ½Ð§Y¨è§R°£,¨Ã½Ð±µ¨ü§Ú­Ìªº¹Dºp. ---------------------------------------------------- ±z¦n¡G ¡@¡@­º¥ý¯¬ºÖ±z¡G·s¦~§Ö¼Ö¡A¸U¨Æ¦p·N¡C ¡@¡@¨Ã¯¬ºÖ±z¡G±¡¤H¸`§Ö¼Ö¡C »OÆW¸É©«¶°´²¤¤¤ß¡A¥X²£»P¦¬¶°·s¤ùªº³t«×µ´¹ï¬O²Ä¤@¡A¤j²³¤Æªº»ù®æ¡A³Ì¥R¹êªº¤º®e¡I¥X³f³t«×³Ì§Ö¡I·í¤é¦¬¥ó¡A¹j¤é¥X³f¡I PS.¦Û²£¦Û¾P,»ù®æ¹ê¦b,°â«áªA°È§¹¾ã,½Ðºô¤Í©ñ¤ß!! ½u¤W­qÁÊ½Ð¦Ü http://www.xooming.to/ecd/ --------------------------------------------------------- ½Ð¤£­nª½±µ¦^ÂÐ¥»«H¡A·|¦¬¤£¨ì¡C ¡°¦pªG±z¤£·Q¦A±µ¦¬¥»°T®§¡A½Ðª½±µ«ö¤U­±³o­ÓE-mail¦^«H§Y¥i: cdnew3@ms47.url.com.tw?subject=no_mail (½Ð¤£­n§ó§ï¥D¦®) ¦A¦¸¯¬ºÖ±z¡G·sªº¤@¦~¨Æ¨Æ¶¶¤ß¡C %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From rsvp-owner@ISI.EDU Mon May 15 00:38: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 AAA16696 for ; Mon, 15 May 2000 00:38:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA11249 for rsvp-outgoing; Sun, 14 May 2000 19:48:03 -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 TAA11243 for ; Sun, 14 May 2000 19:48:02 -0700 (PDT) Received: from mail.etang.com ([202.101.42.211]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id TAA27204 for ; Sun, 14 May 2000 19:48:02 -0700 (PDT) Received: from cg (unknown [202.110.179.21]) by mail.etang.com (Postfix) with ESMTP id 2E4871C412B83; Mon, 15 May 2000 06:48:28 +0800 (CST) From: "chat" Reply-To: aktter@etang.com Subject: ÁÄÌ죿£¿£¿ To: chat@etang.com X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 Date: Tue, 16 May 2000 04:30:29 +0800 Message-Id: <20000514224828.2E4871C412B83@mail.etang.com> Sender: owner-rsvp@ISI.EDU Precedence: bulk ½ñÌìÈ¥ÁËÇ×ÃܽӴ¥ÓïÒôÁÄÌìÊÒ£¬·¢ÏÖÕæµÄºÜÓÐÒâ˼ ʹÓÃÒ»Ö§×îÆÕͨµÄÂó¿Ë·ç¾ÍÄÜÔÚÍøÉϽøÐÐ×ÔÓÉÇëÎúµÄ½»Ì¸£¬ÏÖ´ú¿Æ¼¼Ö®·¢´ïÕæÊÇÈÃÈ˳Ծª°¡£¡£¡È¥¿´¿´°É£¡£¡£¡ http://www.sehoo.com/chat/ From rsvp-owner@ISI.EDU Tue May 23 03:23: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 DAA28108 for ; Tue, 23 May 2000 03:23:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id WAA07778 for rsvp-outgoing; Mon, 22 May 2000 22:10:08 -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 WAA07772 for ; Mon, 22 May 2000 22:10:06 -0700 (PDT) Received: from rubicon.hasler.ascom.ch (rubicon.hasler.ascom.ch [139.79.129.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id WAA08990 for ; Mon, 22 May 2000 22:10:04 -0700 (PDT) Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5]) by rubicon.hasler.ascom.ch (8.9.3/8.9.3) with ESMTP id HAA18704 for ; Tue, 23 May 2000 07:10:38 +0200 (MET DST) Received: from ascom.ch (stva188 [139.79.35.111]) by stva195.pbx.ascom.ch (8.9.3/8.9.3) with ESMTP id HAA06236 for ; Tue, 23 May 2000 07:10:37 +0200 (MET DST) Message-ID: <392A12CD.B14C62D4@ascom.ch> Date: Tue, 23 May 2000 07:10:37 +0200 From: Dusan Sarvan Organization: ASCOM Business Systems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: Mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Mailing list From rsvp-owner@ISI.EDU Tue May 23 06:48: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 GAA29523 for ; Tue, 23 May 2000 06:48:05 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA14786 for rsvp-outgoing; Tue, 23 May 2000 01:12:07 -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 BAA14781 for ; Tue, 23 May 2000 01:12:06 -0700 (PDT) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id BAA14937 for ; Tue, 23 May 2000 01:12:03 -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 RAA05673 for ; Tue, 23 May 2000 17:42:35 +0930 (CST) Message-ID: <392A40CD.F0AB085D@spri.levels.unisa.edu.au> Date: Tue, 23 May 2000 17:56:53 +0930 From: Maria Elena Villapol X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: RSVP Subject: One data flow Content-Type: multipart/alternative; boundary="------------9DA6E525EF2C87ECC758261E" Sender: owner-rsvp@ISI.EDU Precedence: bulk --------------9DA6E525EF2C87ECC758261E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Currentely, I am modelling RSVP for an unicast network which just includes one sender host one receiver host and one router connected them. I considered one RSVP session. Given the above topology and that I considered one session, there may be more than one flow in the session? I believe, no, am I correct? Thank in advanced 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 --------------9DA6E525EF2C87ECC758261E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

Currentely, I am modelling RSVP for an unicast network which just includes one sender host one receiver host and one router connected them. I considered one RSVP session. Given the above topology and that I considered one session, there may be more than one flow in the session? I believe, no, am I correct?

Thank in advanced

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
  --------------9DA6E525EF2C87ECC758261E-- From rsvp-owner@ISI.EDU Tue May 23 11:40: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 LAA05323 for ; Tue, 23 May 2000 11:40:35 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA26494 for rsvp-outgoing; Tue, 23 May 2000 06:24:05 -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 GAA26489 for ; Tue, 23 May 2000 06:24:04 -0700 (PDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id GAA26114 for ; Tue, 23 May 2000 06:24:01 -0700 (PDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <26GSK8AN>; Tue, 23 May 2000 21:24:37 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED5577@exs23.ex.nus.edu.sg> From: Ge Yu To: RSVP , "'Maria Elena Villapol'" Subject: RE: One data flow Date: Tue, 23 May 2000 21:24:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rsvp@ISI.EDU Precedence: bulk I think different applications in the sender may have different flow in the same session. rgds Ge Yu > ---------- > From: Maria Elena Villapol[SMTP:maria@SPRI.Levels.UniSA.Edu.Au] > Sent: Tuesday, May 23, 2000 4:26 PM > To: RSVP > Subject: One data flow > > Hi all, > > Currentely, I am modelling RSVP for an unicast network which just includes > one sender host one receiver host and one router connected them. I > considered one RSVP session. Given the above topology and that I > considered one session, there may be more than one flow in the session? I > believe, no, am I correct? > > Thank in advanced > > 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 > > From rsvp-owner@ISI.EDU Tue May 23 15:20: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 PAA08369 for ; Tue, 23 May 2000 15:20:57 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA08563 for rsvp-outgoing; Tue, 23 May 2000 10:11:08 -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 KAA08558 for ; Tue, 23 May 2000 10:11:06 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.fore.com [169.144.68.6]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id KAA09200 for ; Tue, 23 May 2000 10:11:04 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10842 for ; Tue, 23 May 2000 13:11:04 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07104 for ; Tue, 23 May 2000 13:11:05 -0400 (EDT) Message-ID: <392ABBAE.40243725@marconi.com> Date: Tue, 23 May 2000 13:11:10 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: RSVP Subject: Re: One data flow References: <30A14FB41CC5D311854D00508B5EEF0201ED5577@exs23.ex.nus.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Currentely, I am modelling RSVP for an unicast network which just > includes one sender host one receiver host and one router connected > them. I considered one RSVP session. Given the above topology and > that I considered one session, there may be more than one flow in the > session? I believe, no, am I correct? Multiple data flows to the same recipient (as defined by IP address, L3 protocol and port number) will all be in the same session. This is the definition of a session. These multiple flows, however, will be separate RSVP paths. An RSVP sender is defined as source IP address and source port. Since multiple applications sending to one destination from a single host will still have different source ports, they will be treated as different senders by the RSVP protocol. These different paths may or may not share resources on the router. This will depend on whether the receiving end makes FF, SE or WF-style reservations. -- David From rsvp-owner@ISI.EDU Wed May 24 06:49:04 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02034 for ; Wed, 24 May 2000 06:49:03 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA20913 for rsvp-outgoing; Wed, 24 May 2000 00:50:18 -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 AAA20908 for ; Wed, 24 May 2000 00:50:17 -0700 (PDT) Received: from belcebu.upc.es (belcebu.upc.es [147.83.2.63]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA15656 for ; Wed, 24 May 2000 00:49:50 -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 JAA17261 for ; Wed, 24 May 2000 09:50:02 +0200 (MET DST) Received: from mat.upc.es (emunoz@[147.83.39.218]) by mat.upc.es (8.8.8/8.8.8) with ESMTP id JAA16181 for ; Wed, 24 May 2000 09:50:22 +0200 (MET DST) Message-ID: <392BA851.AB79CA28@mat.upc.es> Date: Wed, 24 May 2000 09:00:49 -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: rsvp@ISI.EDU Subject: [Fwd: rsvpd-4.2a4-linux-990416.dif problems] 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 AAA20909 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I writted this mail to Alexey asking for a solution, but he seems to have a lot of work. Can anybody help me? Thank in advanced Edgar -------- Original Message -------- Subject: [Fwd: rsvpd-4.2a4-linux-990416.dif problems] Date: Tue, 16 May 2000 10:21:27 +0200 From: Edgar Muñoz Mercader To: emunoz@mat.upc.es Hi Alexey, I am working with rel4.2a4 ISI implementation of RSVP, and I apply your linux patch (rsvpd-4.2a4-linux-990416.dif) to the original files. The problem I found is that it do not compile properly. I enter 'make depend' and it works fine after a few changes in Makefiles, but when I try 'make' to compile it I have a lot of problems as you can see a bit below. I think the problem is that I am not using the same include files for the kernel than you. I suppose this because in all the problems a include file of de /usr/include/linux directory is involved. I tried two relases of them: 2.2.13 kernel version (as my kernel, I am workin with Suse6.3) and 2.0.37 kernel version, and I find different kind of problems: #with include files of kernel 2.0.37-19: #'linux/netlink.h', 'linux/rtnetlink.h' and 'linux/in6.h' do not exist. # #with include files of kernel 2.2.13-1: #Redefinition of structures 'ifmap', 'ifreq' and 'ifconf' in 'linux/if.h' and 'net/if.h' #Redefinition of structures 'in_addr', 'ip_mreq' and 'sockaddr_in' in 'linux/in.h' and #'netinet/in.h' I tried two version of C libraries: gilbc-2.1 and glibc-2.0.7. But I think de main problem are the include files for the kernel (/usr/include/files), they are or too old or too new. Please send me a solution, I think most of my problems will finish automatically if I install your source kernel and the include files. Best regards Edgar Munoz From rsvp-owner@ISI.EDU Wed May 24 13:20: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 NAA09488 for ; Wed, 24 May 2000 13:20:30 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA07354 for rsvp-outgoing; Wed, 24 May 2000 07:59:55 -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 HAA07349 for ; Wed, 24 May 2000 07:59:53 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.fore.com [169.144.68.6]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id HAA01500 for ; Wed, 24 May 2000 07:59:35 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04402 for ; Wed, 24 May 2000 10:59:35 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16400 for ; Wed, 24 May 2000 10:59:35 -0400 (EDT) Message-ID: <392BEE5F.FB0673B9@marconi.com> Date: Wed, 24 May 2000 10:59:43 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: Re: [Fwd: rsvpd-4.2a4-linux-990416.dif problems] References: <392BA851.AB79CA28@mat.upc.es> 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 HAA07350 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Edgar Muñoz Mercader wrote: > > Hi Alexey, > > I am working with rel4.2a4 ISI implementation of RSVP, and I apply > your linux patch (rsvpd-4.2a4-linux-990416.dif) to the original files. > The problem I found is that it do not compile properly. I'm not too familiar with the ISI implementation, although I have browsed through the sources a bit. If you are using a 2.2 kernel, I don't think you should apply any patches. The patch is supposed to enable router-alert processing in the kernel IP stack (although, after looking at the patch, it doesn't seem to do that, either.) The 2.2 kernel already supports router alert, so I don't think the patch should be required. I know that the 2.2 kernel has a number of features that were not in the 2.0.x kernel (including router-alert and a more robust API for raw sockets). These new features should make RSVP implementations easier to develop, but I would also expect them to break code intended for earlier kernels. If the ISI code is compatible with multiple versions of UNIX, and not just Linux, it may be possible to make it work simply by changing the configuration-defines. If it is Linux-specific, it may need to be changed a bit. -- David From rsvp-owner@ISI.EDU Thu May 25 14:10:56 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16642 for ; Thu, 25 May 2000 14:10:54 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA23443 for rsvp-outgoing; Thu, 25 May 2000 08:43:36 -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 IAA23436 for ; Thu, 25 May 2000 08:43:34 -0700 (PDT) Received: from superpoll01.superpoll.net ([210.200.222.168]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id IAA22081 for ; Thu, 25 May 2000 08:43:30 -0700 (PDT) Message-Id: <200005251543.IAA22081@venera.isi.edu> Received: from vincent (ZENKY [210.200.222.133]) by superpoll01.superpoll.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id LTTKRSD2; Thu, 25 May 2000 22:49:56 +0800 From: superpoll To: rsvp@ISI.EDU Subject: ¥þ²yµØ¤Hºô¸ô¥æ©ö¦æ¬°¤j½Õ¬d Date: 2000/5/25 PM 10:54:45 Mime-Version: 1.0 Content-Type: text/html; charset=big5 Sender: owner-rsvp@ISI.EDU Precedence: bulk ¼Æ³Õºô¸ê°TªÑ¥÷¦³­­¤½¥qºô¸ô¥«½Õ°Ý¨÷

¨â©¤¤T¦a¹q¤l¥æ©ö¦æ¬°¤j½Õ¬d

°Ý¨÷»¡©ú
±z¦n,³o¬O¤@¥÷¥Ñ¥xÆW¤j¾ÇºÞ²z¾Ç°|¶Ç¼½¬ì§Þ»P´CÅéºÞ²z¬ã¨s¤¤¤ß»PSuperPoll.net ©Òµ¦¹ºªº¡u¨â©¤¤T ¦a¹q¤l¥æ©ö¦æ¬°¤j½Õ¬d¡v°Ý¨÷¡A½Ð¨Ì±z¹ê»Úªººô¸ô¨Ï¥Î¦æ¬°¥[¥H¶ñµª¡A¥»¶µ½Õ¬d¶i¦æ®É¶¡¬°5/20-5/25¡A±N©ó5/27©ó°ê»Úª¾¦W´CÅéµoªí½Õ¬dµ² ªG¡A¨Ã¦b°ê»Ú³q°Óªk«ß¨Æ°È©Ò«ß®v¨£ÃÒ¤U¤½¶}©â¥X±o¼úªÌ¡A­PÃØÁ`»ù­È¹F300¸U·s¥x¹ô ¥H¤WÃØ«~¡C

ÄúºÃ, ÕâÊÇÒ»·ÝÓĘ́Íå´óѧ¹ÜÀíѧԺ´«²¥¿Æ¼¼ÓëýÌå¹ÜÀíÑо¿ÖÐÐÄÓëSuperPoll.net Ëù²ß»®µÄ¡¸Á½°¶ÈýµØµç×Ó½»Ò×ÐÐΪ´óµ÷²é¡¹ÎÊ¾í£¬Çë ÒÀÄúʵ¼ÊµÄÍøÂçʹÓÃÐÐΪ¼ÓÒÔÌî´ð£¬±¾Ïîµ÷²é½øÐÐʱ¼äΪ5/20-5/25£¬½«ÓÚ5/27ÓÚ¹ú¼ÊÖªÃûýÌå·¢±íµ÷²é½á¹û£¬²¢ÔÚ±´¿ËÂó¿Ï¶÷·¨ÂÉÊÂÎñËùÂÉ Ê¦¼û֤Ϲ«¿ª³é³öµÃ½±Õߣ¬ÖÂÔù×ܼÛÖµ´ï10ÍòÃÀ½ðÔùÆ·


 ¥»°Ý¨÷¦@¤À¬°¤T­Ó¤£¦Pª©¥»¡A½Ð´N±z©Ò©~¦í¤§¦a°Ï¤Î¨Ï¥Î»y¨t¿ï¾Ü¨ä¤¤¾A·íªº°Ý¨÷ª©¥»¶i¦æ§@µª¡AÁÂÁ±zªº¦X§@¡I

 ±¾ÎÊ¾í¹²·ÖΪÈý¸ö²»Í¬°æ±¾£¬Çë¾ÍÄúËù¾Óס֮µØÇø¼°Ê¹ÓÃÓïϵ Ñ¡ÔñÆäÖÐÊʵ±µÄÎʾí°æ±¾½øÐÐ×÷´ð£¬Ð»Ð»ÄúµÄºÏ×÷£¡

Taiwan¡@China¡@Hong Kong
tel:002-886-2-2655-1988
e-mail:info@superpoll.net  
From rsvp-owner@ISI.EDU Sat May 27 04:58: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 EAA15661 for ; Sat, 27 May 2000 04:58:32 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id XAA28519 for rsvp-outgoing; Fri, 26 May 2000 23:42:19 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA28514 for ; Fri, 26 May 2000 23:42:17 -0700 (PDT) Received: from yeon.kotel.co.kr ([147.6.65.48]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA24133 for ; Fri, 26 May 2000 23:42:49 -0700 (PDT) Received: from cira - 147.6.72.23 by yeon.kotel.co.kr with Microsoft SMTPSVC(5.5.1775.675.6); Sat, 27 May 2000 15:36:06 +0900 Message-ID: <022401bfc7a6$9c5555c0$17480693@kotel.co.kr> From: "APCC2000 Secretary" To: Subject: APCC2000 paper submission due date is EXTENDED to 17 JUNE!! Date: Sat, 27 May 2000 15:41:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit 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: 7bit WE APOLOGIZE FOR ANY DUPLICATE OR UNWANTED MESSAGES. PLEASE FORWARD THIS MESSAGE TO YOUR COLLEAGUES WHO MIGHT BE INTERESTED. ------------------ The DUE DATE for paper submission to APCC2000 is EXTENDED to 17 JUNE. APCC2000 Organizing Committee has decided to extend the due date in order to give more chances to submit your papers to APCC2000. We are very thankful for your interests and paper submissions and believe this year event will be the greatest conference. With best regards, Hongbeom Jeon Secretary, APCC2000 Organizing Committee. ============================================= CALL FOR PAPERS The 6th Asia-Pacific Conference on Communications (APCC2000) 30 Oct. - 2 Nov. 2000, Seoul, Korea http://www.apcc2000.com ============================================= The Asia-Pacific Conference on Communications (APCC) provides a forum for greater regional interaction and dissemination of information on the latest developments in the rapidly expanding field of communications. The major objective of APCC is to provide researchers and engineers in the Asia-Pacific region with an opportunity to discuss topics related to advanced telecommunication technologies and services, while at the same time, open the door to the world. The 6th APCC (APCC2000) will be held in Seoul, Korea during 30 Oct. ~2 Nov. 2000. You are invited to submit papers for presentation at the conference and for publication in the conference record. Papers describing original works in all aspects of communications are invited. ============================================= Areas of Interests include, but are not limited to, the following areas: - ATM and B-ISDN - Broadband Access Systems - Communications Switching - Communications Software - Communication Theory - Gigabit Networking - IMT-2000 - Information Infrastructure - Internet Application and Technology - Mobile and Personal Communications - MPLS, MPOA, VoATM, VoIP, etc. - Multimedia Communications - Multiprotocol Network Evolution - Network Operations and Management - Network Security - Optical Communication Technologies - Quality Assurance Management - Satellite and Space Communications - Signal Processing and Communications Electronics - Traffic Management and Control - Virtual Private Networking - Wireless Communications ============================================= Tutorials: You are invited to submit proposal for full-day or half-day tutorials relating to above areas. Proposals must include an outline, intended audience and a brief biography of the speaker. Please send your proposal to Technical Program Committee of APCC2000 at program@mail.apcc2000.com. ============================================= Instructions for Authors: Prospective authors must submit a full paper in English for the review by Technical Program Committee. Each submission of paper should not exceed 3,000 words including an abstract of 100 words. Authors are encouraged to format their papers to fit within five conference proceeding pages. Please follow the instructions given below carefully. Instructions: - Maximum five pages - ISO A4 size - Written in English - Two-column format - Times New Roman font, 10 points - 2.5 cm margins on all four sides Each copy of the paper should include a cover page specifying all of the following information: - Title of the paper - Name of all authors - Name of contact author, affiliation, return address, e-mail, telephone and fax numbers of contact author - Designation of the primary technical subject area covered by the paper (as listed above) Each submitted paper including a cover page must be printable on ISO A4 white papers. All other pages but a cover page should be marked with the title of the paper, name of the first author, and page numbers. All submitted papers will be received at APCC2000 On-line Paper Submission Center available on APCC2000 web site. Papers in PDF format are strongly encouraged, however papers in MS Word 6.0 or higher format or in Postscript compatible with Aladdin Ghostscript 5.50 format are also accepted. After notification of acceptance, with camera ready manuscript submission, registration by at least one author is required in order for your paper to be published. Otherwise, the acceptance of your paper will be canceled. ============================================= Submit Papers to: An on-line submission form with file (i.e., Adobe Acrobat PDF, etc) attachment capability is now available on the APCC2000 web site (http://www.apcc2000.com). Submitting via web is strongly encouraged, however, if you have serious problem in On-line Paper Submission, please send five copies of your paper to: Dr. Hyeong Ho Lee (APCC2000 TPC Secretariat) Router Technology Department, ETRI 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Korea program@mail.apcc2000.com ============================================= Important Dates: Papers submission: June 17, 2000 Tutorial proposal: June 17, 2000 Notification of acceptance: July 31, 2000 Camera-ready papers/tutorials: September 25, 2000 ============================================= Sponsored by: Korean Institute of Communication Science Co-Sponsored by: - The Institute of Electronics Engineers of Korea - Korea Information Science Society - IEEE Communication Society Asia-Pacific Board, SPCE Technical Committee - Korea Telecom - Electronics and Telecommunications Research Institute (ETRI) ============================================= APCC Steering Committee: B.G. Lee, Seoul National University D.N. Cooper, CSIRO Z.Y. Deng, China Institute of Communications T. Miki, University of Electro-Communications A.J. Gibbs, NEC Australia B.M. Ali, University Putra Malaysia T. Aoyama, University of Tokyo J.L. Hullett, Curtin University of Technology J.K. Kim, KAIST C.C. Ko, National University of Singapore L.S. Lee, National Taiwan University S.H. Lee, Korea Telecom M.L. Liou, Hong Kong Univ. of Science & Tech. H. Miyahara, Osaka University N. Ohta, Sony D.P. Taylor, University of Canterbury P. Thajchayapong, King Mongkut's Inst. of Tech. H. Tominaga, Waseda University C.H. Wei, National Chiao-Tung University C.H. Yim, ETRI J.P. Zhou, Beijing Univ. of Posts & Telecom. ============================================= General Chairman: Yong Kyung Lee, Korea Telecom Freetel Technical Program Committee: Chair: Chu Hwan Yim, ETRI Organizing Committee: Chair: Sanghoon Lee, Korea Telecom Treasurer: Ha Bong Chung, Hongik University Registration: Dae Young Kim, Chungnam National University Publication: Jong Hee Lee, Modacom Co., Ltd. Publicity: Cheol Hee Kang, Korea University Social Program: Hwang Soo Lee, SK Telecom Local Arrangement: June Nyun Kim, Choongang University ============================================= From rsvp-owner@ISI.EDU Sun May 28 18:16:56 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10717 for ; Sun, 28 May 2000 18:16:55 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id NAA18648 for rsvp-outgoing; Sun, 28 May 2000 13:22:36 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id NAA18642 for ; Sun, 28 May 2000 13:22:35 -0700 (PDT) Received: from emo.mgc.com.tw (root@emo.mgc.com.tw [210.241.247.115]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id NAA28988 for ; Sun, 28 May 2000 13:23:08 -0700 (PDT) Received: from tang (as5po121.ht.ficnet.net.tw [202.145.67.121]) by emo.mgc.com.tw (8.8.6/8.8.6) with ESMTP id EAA05275; Mon, 29 May 2000 04:11:54 +0800 (CST) Message-Id: <200005282011.EAA05275@emo.mgc.com.tw> From: "guest" Reply-To: et291772@libra.seed.net.tw Subject: §ä¤£¨ì³Ì·sµ{¦¡¶Ü To: below@emo.mgc.com.tw X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sun, 28 May 2000 23:28:05 +0800 Sender: owner-rsvp@ISI.EDU Precedence: bulk ¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹ ¡¹ ´º®ð¦n¡A­n¼s§i! ´º®ð¤£¦n§ó»Ý­n¼s§i...... ¡¹ ¡¹ ¡y©ö­¸¡z¼s§i§Ö»¼¡A¬°±z¥Nµo E-mail µ¹³Ì·s³Ì¦³®Äªº¶R¥D ¡¹ ¡¹ ¬°±z³Ð³y°]´I¡A¥N«ÈµoE-mailªA°È: http://0935.net/smail¡¹ ¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹¡¹ ¦n¤ù¤@ªi±µ¤@ªi¡A¥R¹êªº¤º®e¡A§¹µ½ªº¤ÀÃþ¡A¸Ô²Óªº¸Ñ»¡¡A§¹¾ãªº¯}¸Ñ¬O¥»¯¸ªº¯SÂI¡I ·Q§ä³Ì·sªº¡iµ{¦¡¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹CÀ¸¡j¶Ü¡H ·Q§ä³Ì·sªº¡i­µ¼Ö¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¹q¼v¡j¶Ü¡H ·Q§ä³Ì·sªº¡i¤u§@³nÅé¡j¶Ü¡H ¡iºâ©R¡j¡A¡iªÑ¥«¤ÀªR¡j¡A¡i¥®¨à±Ð¾Ç¡j¡A¡i¤é¤å³nÅé¡j¡A¡i®a®x¹B¥Î¡j ¡i¬ü¤u°Êµe¡j¡A¡i½Ķ¡j¡A¡i¦Ê¬ì¡j¡È¡È¡I ¥R¹êªº¤º®e¡A2000¦h®Mªº·s³nÅé¡A±z­n§äªº§Ú­Ì³o¸Ì³£¦³¡C 5¤ë¶W±j·s¤ù±À¥X 200 ¦h®M³nÅé¡C ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ§¹¾ã"¥ø·~"¥¿¦¡ª© Microsoft Office 2000 PREMIUM V9.0 ³c°â"¤¤¤å²Åé"¥úºÐ¼Ð·Ç¥¿¦¡ª©¡i³æ¤ù¸Ë¡j Microsoft PhotoDraw 2000 ¡ª¤é¤å¡ª±M·~¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft SITE SERVER V3.0 "¤é¤å""¥ø·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional Edition ¤é¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Professional INT'L Edition ­^¤å"±M·~"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISIO 2000 V6.0X Technical Edition ¤é¤å"¤uµ{"¥úºÐ§¹¾ã¥¿¦¡ª© MICROSOFT VISUAL STUDIO MSDN LIBRARY V6.01A ¤é¤å¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows 98 ²Ä¤Gª© Second Edition ¤¤¤å"²Åé"¼Ð·Ç¥úºÐ§¹¾ã¥¿¦¡ª© Microsoft Windows Millennium B2 V4.90.2490 "¤¤¤å"¥úºÐ§¹¾ãBETAª© Microsoft Windows Millennium B2 V4.90.2491 "­^¤å"¥úºÐ§¹¾ãBETAª© MS Systems Management Server V2.0 SERVER PACK 1 "­^¤å"¥úºÐ§¹¾ã¥¿¦¡ª© MySQL+LinuxPPC R5 ¤¤¤å¤Æ For Linux NeMo Dev V1.0.1 -- Nokia Data suite V3.0 OBJECTIVITY V5.2 ­^¤åª© For Linux Out Post 69 Pinnacle Studio 400 V1.05 PoolDraw V5.0 PROTEL 99 Service Pack 3 ­^¤å¯}¸Ñ¡©§¹¾ã¡¨¥[±jª© (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ÞÃZ¤J«Ç (¶W¯ÅµL¼Ä´xªùª¯)¡G¤ë²y³¥À\°O (¶W¯ÅµL¼Ä´xªùª¯)¡G«c¤MÃä½t ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡ãUFO´¦¶}«Õ¯B¤§Á¼¨t¦C(¤@) ¡y¥®¨à¦¨ªø¨t¦C¢°¡z ¡y¥®¨à¦¨ªø¨t¦C¢±¡z ¡y¥®¨à¦¨ªø¨t¦C¢³¡z ¡i¥®¨à¬ü»yµ£¸Ü¥@¬É¡Ï¥®¸X¶éµ£ÁÁABC¡j¤j¦X¿è ¡iµ£ÁÁ°Û¹C¡Ï¥®¨àÃý«ß¡j¤j¦X¿è ¡iµÛ¦WJAVA³]­p°ÓJAVA¤¬°Ê¦¡±Ð¾Ç¡j­^¤å§¹¾ã¥¿¦¡ª© 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢° 2000¦~ ¤¤­^¤å¤p»¡¤j¥þ¢± 21¥@¬ö¬y¦æMP3±M¿è(157) 3D ¾·~«OÄÖ²y PRO Bowl 3D ¢¸¢¸¦~¥@¬ö¥½¤­¤j¤Ñ¦Z²{³õ«lºq¹ê¿ý ACER EASY AXESS V1.30.43 ¡u§A¦n¶Ü¡I¡v¼v­µ·¾³q¨t²Î Adobe Acrobat v4.05 ¥¿¦¡ª© Adobe InDesign ­^¤åª© For MAC Advanced Design System V1.3 Artisoft I.Share V3.5 ¥¿¦¡ª© BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- BBC »Åª¯Ä_¨©--- Blue Point Linux ORC V1.0 ¤¤¤åª© For PC BOYZONE ¨k«Ä¯S°Ï¦X°Û¹Î BuySite v6.1 ¥¿¦¡ª© (»Ý¦w¸ËSQL) C¢ÒÀs¡Ð¦h´CÅé¡m²³ø¡®±Ð§÷¡n Corel WordPerfect Office 2000 ­^¤å¥úºÐ§¹¾ã¥¿¦¡ª©¡j Cumulus Single User Edition V5.0.1 Build 160 DBMaker V3.51 ­^¤åª©+¤¤¤åª© For Linux Deneba Canvas 7 for MAC Dyno 2000 V3.08 ¥¿¦¡ª© FormTool V4.0 IBM Lotus SmartSuite Millenium Edition V9.5.2 ¥¿¦¡ª© ICEM CFD SOLARIS EDITION V4.0.7 Intel LANDesk Management Suite V6.3 INTERNETºô­¶»s§@±Ð¾Ç Macromedia Director V8.0 ­^¤åª© For MAC Macromedia DreamWeaver 3.0 ­^¤åª© For MAC ¢b¢c¢d¢e¢f¢g¢h¢i ¥»¯¸ºô§} ¡Ghttp://www.hoo.to/good/ ¢i¢h¢g¢f¢e¢d¢c¢b From rsvp-owner@ISI.EDU Tue May 30 06:34:04 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22724 for ; Tue, 30 May 2000 06:34:04 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id AAA16118 for rsvp-outgoing; Tue, 30 May 2000 00:55:43 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA16113 for ; Tue, 30 May 2000 00:55:42 -0700 (PDT) Received: from nausicaa.coritel.it ([193.205.242.5]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id AAA07195 for ; Tue, 30 May 2000 00:56:15 -0700 (PDT) Received: from coritel.it (fermat.coritel.it [193.205.242.41]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id JAA14236; Tue, 30 May 2000 09:48:25 +0200 (MET DST) Message-ID: <3933744A.26B5F8B5@coritel.it> Date: Tue, 30 May 2000 09:56:59 +0200 From: Roberto Mameli Organization: CoRiTeL X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Edgar =?iso-8859-1?Q?Mu=F1oz?= Mercader CC: rsvp@ISI.EDU Subject: Re: [Fwd: rsvpd-4.2a4-linux-990416.dif problems] References: <392BA851.AB79CA28@mat.upc.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Edgar Muñoz Mercader wrote: > Hi all, > > I writted this mail to Alexey asking for a solution, but he seems to > have a lot of work. Can anybody help me? > > Thank in advanced > Edgar > > -------- Original Message -------- > Subject: [Fwd: rsvpd-4.2a4-linux-990416.dif problems] > Date: Tue, 16 May 2000 10:21:27 +0200 > From: Edgar Muñoz Mercader > To: emunoz@mat.upc.es > > Hi Alexey, > > I am working with rel4.2a4 ISI implementation of RSVP, and I apply your > linux patch (rsvpd-4.2a4-linux-990416.dif) to the original files. The > problem I found is that it do not compile properly. > > I enter 'make depend' and it works fine after a few changes in > Makefiles, but when I try 'make' to compile it I have a lot of problems > as you can see a bit below. I think the problem is that I am not using > the same include files for the kernel than you. I suppose this because > in all the problems a include file of de /usr/include/linux directory is > involved. I tried two relases of them: 2.2.13 kernel version (as my > kernel, I am workin with Suse6.3) and 2.0.37 kernel version, and I find > different kind of problems: > #with include files of kernel 2.0.37-19: > #'linux/netlink.h', 'linux/rtnetlink.h' and 'linux/in6.h' do not exist. > # > #with include files of kernel 2.2.13-1: > #Redefinition of structures 'ifmap', 'ifreq' and 'ifconf' in > 'linux/if.h' and 'net/if.h' #Redefinition of structures 'in_addr', > 'ip_mreq' and 'sockaddr_in' in 'linux/in.h' and #'netinet/in.h' > > I tried two version of C libraries: gilbc-2.1 and glibc-2.0.7. But I > think de main problem are the include files for the kernel > (/usr/include/files), they are or too old or too new. > > Please send me a solution, I think most of my problems will finish > automatically if I install your source kernel and the include files. > > Best regards > Edgar Munoz Hi Edgar, instead of using the original rel4.2a4 version and patching it for Linux, try to download and install the newer version for Linux (rel4.2a4-1). You can find it on the ISI FTP site... it is easier to use and you shouldn't find all those problems. Regards Roberto -- Roberto Mameli CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni EMAIL : mameli@coritel.it URL : http://www.coritel.it TEL : +39-06-20410038 ADDRESS : Via di Tor Vergata, 135 FAX : +39-06-20410037 00133 Roma - ITALY From rsvp-owner@ISI.EDU Wed May 31 05:30: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 FAA02021 for ; Wed, 31 May 2000 05:30:57 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id XAA08370 for rsvp-outgoing; Tue, 30 May 2000 23:59:46 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id XAA08365 for ; Tue, 30 May 2000 23:59:45 -0700 (PDT) Received: from public.fhnet.cn.net (ns.fhnet.cn.net [202.99.8.1]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id XAA04925 for ; Tue, 30 May 2000 23:59:17 -0700 (PDT) Received: from x ([210.72.252.80]) by public.fhnet.cn.net (8.9.2/8.9.2) with ESMTP id OAA07115; Wed, 31 May 2000 14:27:09 +0800 (CST) Message-Id: <200005310627.OAA07115@public.fhnet.cn.net> From: "www.001.com.cn" Reply-To: j1986@etang.com Subject: ÕâÊǷ⽫¸Ä±äÄúÒ»ÉúÃüÔ˵ÄEMAIL To: ÅóÓѵÄÅóÓÑ@public.fhnet.cn.net X-Mailer: V3,1,6,1 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 31 May 2000 13:19:00 +0800 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = http

http://www=2E001=2Ecom=2E= cn=BD=AB=B8=C4=B1=E4=C4=FA=D2=BB=C9=FA=C3= =FC=D4=CB

http://www=2Eworld001=2E= com=BD=AB=B8=C4=B1=E4=C4=FA=D2=BB=C9=FA=C3= =FC=D4=CB

001=CD=B6=D7=CA=B0=D9=CD=F2=A3=AC=C6=B8=C7=EB=C8=AB= =C7=F2=B8=F7=D0=D0=D2=B5=D7=A8=BC=D2=D4=DA=CF=DF=C3=E2=B7=D1=D7=C9=D1=AF=A1= =A3

=C4=FA=C9= =FA=BB=EE=D3=D0=B7=B3=C4=D5=A3=BF=C4=E3=D4=DA=C9=FA=BB=EE=D6=D0=D3=F6=B5=BD= =C4=D1=CA=C2=A3=BF=D5=D2=B2=BB=B5=BD=B3=C6=D0=C4=B5=C4=C5=E4=C5=BC=A3=AC=C5= =F3=D3=D1=A3=BF

=C4=FA=C9= =FA=BB=EE=D6=D0=B5=C4=D2=BB=C7=D0=B7=B3=C4=D5=BD=AB=D4=DA   001=C8=AB=C7=F2=BB=A5=D6=FA=CD=F8<= /a>  =D3=AD=C8=D0=B6=F8=BD=E2=A1=A3=C4=E3=BD=AB=B5=C3=B5=BD=CE=D2=C3=C7=BA=CD=C8=AB=CA=C0=BD=E7=D7=A8=BC=D2=BA=CD=C8=C8= =D0=C4=C8=CB=B5=C4=B6=A6=C1=A6=B0=EF=D6=FA=BA= =CD=D7=C9=D1=AF

 = =C8=C3=C8=AB=C7=F2=B5=C4=D7=A8=BC=D2=B6=BC=C0=B4=B0=EF=D6=FA=C4= =E3=A3=A1

 001=CD=B6=D7=CA=B0=D9=CD=F2=A3=AC=C6=B8=C7=EB=C8=AB= =C7=F2=B8=F7=D0=D0=D2=B5=D7=A8=BC=D2=D4=DA=CF=DF=C3=E2=B7=D1=D7=C9=D1=AF=A1= =A3

=C3=E2=B7=D1=C8=A8=CD=FE= =D0=C4=C0=ED=D7=A8=BC=D2=D7=C9=D1=AF

=C3=E2=B7=D1=C8=A8=CD=FE= =D2=C6=C3=F1=BC=D3=C4=C3=B4=F3=D7=C9=D1=AF=A3=AC=CA=A1=C8=A5=C4=FA=B0=BA=B9= =F3=B5=C4=CA=FD=CD=F2=D4=AA=B5=C4=D2=C6=C3=F1=C2=C9=CA=A6=B7=D1=A1=A3=A3=A8= =D7=EE=C8=C8=BB=B0=CC=E2=A3=AC=B1=BE=BF=C6=A3=AC=D2=BB=C4=EA=B9=A4=D7=F7=BE= =AD=D1=E9=A3=AC=B4=F3=D1=A7=D3=A2=D3=EF=CB=C4=BC=B6=D2=D4=C9=CF=A3=AC=D7=EE= =BA=C3=D1=A7=B5=E7=C4=D4=B5=C4=BA=CD=C6=E4=CB=FB=B8=F7=C0=E0=B9=A4=B3=CC=CA= =A6=D7=A8=D2=B5=A3=AC=BC=B4=BF=C9=B0=EC=C0=ED=A1=A3=A3=A9

=C3=E2=B7=D1=B9=C9=C6=B1= =CD=B6=D7=CA=D7=C9=D1=AF=BA=CD=CC=D6=C2=DB

=C3=E2=B7=D1=D4=DA=CF=DF= =D2=BD=C1=C6=D7=A8=BC=D2=D5=EF=B6=CF

=C3=E2=B7=D1=B8=F7=B9=FA= =D2=C6=C3=F1=C1=F4=D1=A7=D7=C9=D1=AF

=C3=E2=B7=D1=C8=AB=C7=F2= =D5=F7=BB=E9

=C3=E2=B7=D1=B5=E7=C4=D4= =D3=B2=BC=FE=C8=ED=BC=FE=CE=CA=CC=E2=D7=C9=D1=AF

=C3=E2=B7=D1=B7=A2=B2=BC= =BD=F4=BC=B1=C7=F3=BE=C8=A3=AC

=C3=E2=B7=D1=D1=B0=D2=BD= =CE=CA=D2=A9

=C3=E2=B7=D1=B7=A2=B2=BC= =B9=E3=B8=E6

=D7=D4=D1=A7=BF=BC=CA=D4= =D7=C9=D1=AF

=C6=FB=B3=B5=D7=C9=D1=AF=

=C5=EB=E2=BF=BC=BC=CA=F5= =D7=C9=D1=AF=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1= =A3=A1=A3=A1=A3=A1=A3

=CB=F9=D3=D0=C9=FA=BB=EE= =C4=D1=CC=E2=D7=C9=D1=AF=BB=A5=D6=FA=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3= =A1=A3=A1=A3=A1=A3=A1=A3=A1

=BF=EC=C0=B4001 =C8=AB=C7=F2=BB=A5=D6=FA=CD=F8------------=D5=E6=D5=FD=B5=C4=BB=A5=D6=FA=CA=C0=CD=E2=CC= =D2=D4=B0, =CD=F8=C9=CF=BE=AB=C9=F1=BC=D2=D4=B0

=C4=FA= =BB=B9=BF=C9=C9=EA=C7=EB=B5=C3=B5=BD=C3=E2=B7=D1=B5=C4=C2=DB=CC=B3=C8=ED=BC= =FE=BA=CD=B7=FE=CE=F1=C6=F7=BF=D5=BC=E4=B9=D2=BD=D3=D4=DA=C4=FA=B5=C4=D6=F7= =D2=B3=BB=F2=D5=BE=B5=E3=CF=C2=C3=E6=A1=A3

http://www=2E001=2Ecom=2E= cn

http://www=2Eworld001=2E= com   = ;=CB=FB=C3=C7=BD=AB=B8=C4=B1=E4=C4=FA=B5=C4=D2= =BB=C9=FA

=CE=D2=C3=C7=B8=FC=BB=B6= =D3=AD=C4=FA=D4=DA=D5=E2=C0=EF=CE=DE=CB=BD=B5=D8=B0=EF=D6=FA=C6=E4=CB=FB=D0= =E8=D2=AA=B0=EF=D6=FA=B5=C4=C8=CB=A3=A1=D5=E2=D1=F9=D2=BB=C0=B4=C4=FA=BD=AB= =B5=C3=B5=BD=CE=D2=C3=C7=CD=F8=D5=BE=B5=C4=B9=C9=B7=DD=A3=AC=BA=CD=B9=E3=B8= =E6=CA=D5=C8=EB=B7=D6=B3=C9=A3=AC=D3=D0=BF=C9=C4=DC=B3=C9=CE=AA=D5=E6=D5=FD= =B5=C4=B0=D9=CD=F2=B8=BB=CE=CC=A3=A1=CE=D2=C3=C7=B2=A2=B2=BB=CA=C7=C0=D7=B7= =E6=A3=AC=B5=AB=CE=D2=C3=C7=D5=FD=D4=DA=CF=F2=CB=FB=D1=A7=CF=B0=A1=A3=CE=D2= =C3=C7=CF=E0=D0=C5: =D6=FA=C8=CB=D5=DF=B1=D8= =D7=D4=D6=FA=A3=A1

(=B9=E3=D6=DD=B5=E7=D3=CA=CD=F8=D6=C2=D0=C5=CF=E4=CB=F9=D3=D0=D5= =DF=A3=BA =B4=D3=C5=F3=D3=D1=B4=A6=B5=C3=B5=BD=C4=FA=B5= =C4EMAIL=B5=D8=D6=B7=A3=AC=C8=E7=B9=FB=C4=FA=B8=D0=BE= =F5=B1=BE=D3=CA=BC=FE=B8=F8=C4=FA=B4=F8=C0=B4=B2=BB=B1=E3=A3=AC=C7=EB=BD=D3= =CA=DC=CE=D2=C3=C7=C9=EE=C9=EE=B5=C4=C7=B8=D2=E2=A3=AC=B2=A2=C7=EB=C1=A2=BC= =B4=BB=D8=B8=B4=A3=BAj1986@263=2Enet =CE=D2=C3=C7=BD=AB=BB=E1=D4=DA=D3=CA=BC=FE=C1=D0=B1=ED=D6=D0=C9=BE=B3=FD=C4= =FA=B5=C4=D3=CA=CF=E4=A1=A3)

A4-4 ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: text/plain; name="world001.txt" Content-Transfer-Encoding: quoted-printable Content-Description: world001.txt Content-Disposition: inline; filename="world001.txt" Content-Transfer-Encoding: quoted-printable http://www=2E001=2Ecom=2Ecn=BD=AB=B8=C4=B1=E4=C4=FA=D2=BB=C9=FA=C3=FC=D4=CB= http://www=2Eworld001=2Ecom=BD=AB=B8=C4=B1=E4=C4=FA=D2=BB=C9=FA=C3=FC=D4=CB= 001=CD=B6=D7=CA=B0=D9=CD=F2=A3=AC=C6=B8=C7=EB=C8=AB=C7=F2=B8=F7=D0=D0=D2=B5= =D7=A8=BC=D2=D4=DA=CF=DF=C3=E2=B7=D1=D7=C9=D1=AF=A1=A3 =C4=FA=C9=FA=BB=EE=D3=D0=B7=B3=C4=D5=A3=BF=C4=E3=D4=DA=C9=FA=BB=EE=D6=D0=D3= =F6=B5=BD=C4=D1=CA=C2=A3=BF=D5=D2=B2=BB=B5=BD=B3=C6=D0=C4=B5=C4=C5=E4=C5=BC= =A3=AC=C5=F3=D3=D1=A3=BF =C4=FA=C9=FA=BB=EE=D6=D0=B5=C4=D2=BB=C7=D0=B7=B3=C4=D5=BD=AB=D4=DA 001=C8= =AB=C7=F2=BB=A5=D6=FA=CD=F8 =D3=AD=C8=D0=B6=F8=BD=E2=A1=A3=C4=E3=BD=AB=B5=C3= =B5=BD=CE=D2=C3=C7=BA=CD=C8=AB=CA=C0=BD=E7=D7=A8=BC=D2=BA=CD=C8=C8=D0=C4=C8= =CB=B5=C4=B6=A6=C1=A6=B0=EF=D6=FA=BA=CD=D7=C9=D1=AF =C8=C3=C8=AB=C7=F2=B5=C4=D7=A8=BC=D2=B6=BC=C0=B4=B0=EF=D6=FA=C4=E3=A3=A1 001=CD=B6=D7=CA=B0=D9=CD=F2=A3=AC=C6=B8=C7=EB=C8=AB=C7=F2=B8=F7=D0=D0=D2=B5= =D7=A8=BC=D2=D4=DA=CF=DF=C3=E2=B7=D1=D7=C9=D1=AF=A1=A3 =C3=E2=B7=D1=C8=A8=CD=FE=D0=C4=C0=ED=D7=A8=BC=D2=D7=C9=D1=AF =C3=E2=B7=D1=C8=A8=CD=FE=D2=C6=C3=F1=BC=D3=C4=C3=B4=F3=D7=C9=D1=AF=A3=AC=CA= =A1=C8=A5=C4=FA=B0=BA=B9=F3=B5=C4=CA=FD=CD=F2=D4=AA=B5=C4=D2=C6=C3=F1=C2=C9= =CA=A6=B7=D1=A1=A3=A3=A8=D7=EE=C8=C8=BB=B0=CC=E2=A3=AC=B1=BE=BF=C6=A3=AC=D2= =BB=C4=EA=B9=A4=D7=F7=BE=AD=D1=E9=A3=AC=B4=F3=D1=A7=D3=A2=D3=EF=CB=C4=BC=B6= =D2=D4=C9=CF=A3=AC=D7=EE=BA=C3=D1=A7=B5=E7=C4=D4=B5=C4=BA=CD=C6=E4=CB=FB=B8= =F7=C0=E0=B9=A4=B3=CC=CA=A6=D7=A8=D2=B5=A3=AC=BC=B4=BF=C9=B0=EC=C0=ED=A1=A3= =A3=A9 =C3=E2=B7=D1=B9=C9=C6=B1=CD=B6=D7=CA=D7=C9=D1=AF=BA=CD=CC=D6=C2=DB =C3=E2=B7=D1=D4=DA=CF=DF=D2=BD=C1=C6=D7=A8=BC=D2=D5=EF=B6=CF =C3=E2=B7=D1=B8=F7=B9=FA=D2=C6=C3=F1=C1=F4=D1=A7=D7=C9=D1=AF =C3=E2=B7=D1=C8=AB=C7=F2=D5=F7=BB=E9 =C3=E2=B7=D1=B5=E7=C4=D4=D3=B2=BC=FE=C8=ED=BC=FE=CE=CA=CC=E2=D7=C9=D1=AF =C3=E2=B7=D1=B7=A2=B2=BC=BD=F4=BC=B1=C7=F3=BE=C8=A3=AC =C3=E2=B7=D1=D1=B0=D2=BD=CE=CA=D2=A9 =C3=E2=B7=D1=B7=A2=B2=BC=B9=E3=B8=E6 =D7=D4=D1=A7=BF=BC=CA=D4=D7=C9=D1=AF =C6=FB=B3=B5=D7=C9=D1=AF =C5=EB=E2=BF=BC=BC=CA=F5=D7=C9=D1=AF=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1= =A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3 =CB=F9=D3=D0=C9=FA=BB=EE=C4=D1=CC=E2=D7=C9=D1=AF=BB=A5=D6=FA=A3=A1=A3=A1=A3= =A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1 =BF=EC=C0=B4001 =C8=AB=C7=F2=BB=A5=D6=FA=CD=F8------------=D5=E6=D5=FD=B5=C4= =BB=A5=D6=FA=CA=C0=CD=E2=CC=D2=D4=B0, =CD=F8=C9=CF=BE=AB=C9=F1=BC=D2=D4=B0 =C4=FA=BB=B9=BF=C9=C9=EA=C7=EB=B5=C3=B5=BD=C3=E2=B7=D1=B5=C4=C2=DB=CC=B3=C8= =ED=BC=FE=BA=CD=B7=FE=CE=F1=C6=F7=BF=D5=BC=E4=B9=D2=BD=D3=D4=DA=C4=FA=B5=C4= =D6=F7=D2=B3=BB=F2=D5=BE=B5=E3=CF=C2=C3=E6=A1=A3 http://www=2E001=2Ecom=2Ecn http://www=2Eworld001=2Ecom =CB=FB=C3=C7=BD=AB=B8=C4=B1=E4=C4=FA=B5=C4=D2= =BB=C9=FA =CE=D2=C3=C7=B8=FC=BB=B6=D3=AD=C4=FA=D4=DA=D5=E2=C0=EF=CE=DE=CB=BD=B5=D8=B0= =EF=D6=FA=C6=E4=CB=FB=D0=E8=D2=AA=B0=EF=D6=FA=B5=C4=C8=CB=A3=A1=D5=E2=D1=F9= =D2=BB=C0=B4=C4=FA=BD=AB=B5=C3=B5=BD=CE=D2=C3=C7=CD=F8=D5=BE=B5=C4=B9=C9=B7= =DD=A3=AC=BA=CD=B9=E3=B8=E6=CA=D5=C8=EB=B7=D6=B3=C9=A3=AC=D3=D0=BF=C9=C4=DC= =B3=C9=CE=AA=D5=E6=D5=FD=B5=C4=B0=D9=CD=F2=B8=BB=CE=CC=A3=A1=CE=D2=C3=C7=B2= =A2=B2=BB=CA=C7=C0=D7=B7=E6=A3=AC=B5=AB=CE=D2=C3=C7=D5=FD=D4=DA=CF=F2=CB=FB= =D1=A7=CF=B0=A1=A3=CE=D2=C3=C7=CF=E0=D0=C5: =D6=FA=C8=CB=D5=DF=B1=D8=D7=D4=D6= =FA=A3=A1 (=B9=E3=D6=DD=B5=E7=D3=CA=CD=F8=D6=C2=D0=C5=CF=E4=CB=F9=D3=D0=D5=DF=A3=BA = =B4=D3=C5=F3=D3=D1=B4=A6=B5=C3=B5=BD=C4=FA=B5=C4EMAIL=B5=D8=D6=B7=A3=AC=C8=E7= =B9=FB=C4=FA=B8=D0=BE=F5=B1=BE=D3=CA=BC=FE=B8=F8=C4=FA=B4=F8=C0=B4=B2=BB=B1= =E3=A3=AC=C7=EB=BD=D3=CA=DC=CE=D2=C3=C7=C9=EE=C9=EE=B5=C4=C7=B8=D2=E2=A3=AC= =B2=A2=C7=EB=C1=A2=BC=B4=BB=D8=B8=B4=A3=BAj1986@263=2Enet =CE=D2=C3=C7=BD=AB= =BB=E1=D4=DA=D3=CA=BC=FE=C1=D0=B1=ED=D6=D0=C9=BE=B3=FD=C4=FA=B5=C4=D3=CA=CF= =E4=A1=A3) ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From rsvp-owner@ISI.EDU Wed May 31 08:08: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 IAA05626 for ; Wed, 31 May 2000 08:08:41 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id DAA17128 for rsvp-outgoing; Wed, 31 May 2000 03:21:12 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA17123 for ; Wed, 31 May 2000 03:21:10 -0700 (PDT) Received: from uni-paderborn.de (uni-paderborn.de [131.234.22.30]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id DAA11489 for ; Wed, 31 May 2000 03:21:43 -0700 (PDT) Received: from nukus.c-lab.de ([131.234.81.49]:4319 "EHLO uni-paderborn.de") by mail.uni-paderborn.de with ESMTP id ; Wed, 31 May 2000 12:20:06 +0200 Message-ID: <3934E757.597A6052@uni-paderborn.de> Date: Wed, 31 May 2000 12:20:07 +0200 From: Simon Schneider X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: rsvp@ISI.EDU Subject: guaranteed service delay formula Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm currently working with RFC2212 - Guaranteed Service. I'm especially interested in the formula for the end-to-end delay: [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot . Unfortunately, there's no deeper explanation of this formula in the RFC. Can anyone explain to me how this formula is derived from the parameters ? What is the intuitive meaning of it ? Thank you, cheers, Simon From rsvp-owner@ISI.EDU Wed May 31 17:01: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 RAA24875 for ; Wed, 31 May 2000 17:01:16 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id MAA11549 for rsvp-outgoing; Wed, 31 May 2000 12:09:39 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA11544 for ; Wed, 31 May 2000 12:09:37 -0700 (PDT) Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25549 for ; Wed, 31 May 2000 12:10:16 -0700 (PDT) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA13170 for ; Wed, 31 May 2000 12:10:00 -0700 Message-Id: <3.0.5.32.20000531120903.031b4310@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 31 May 2000 12:09:03 -0700 To: rsvp@ISI.EDU From: Marty Bickford Subject: iBAND4: Free Educational Passes & QoS Demonstration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rsvp@ISI.EDU Precedence: bulk ----------------------------------------------------------- iBAND4 - Internet Traffic Management & Service Provisioning for IP Network Engineers & Techno-Savvy Colleagues San Francisco Airport Marriott Hotel Conference: June 11-13 + Workshops: June 14 http://www.stardust.com/iband4/ ----------------------------------------------------------- Free Educational Passes ----------------------- Stardust.com is happy to offer a limited number of free conference passes to educators and non-commercial researchers. If you are interested in obtaining a pass, please email Marty Bickford . iBAND4 is the fourth in the only series of events focused on bandwidth management, traffic engineering and service provisioning. iBAND is your chance to explore the latest thinking about smart bandwidth. Learn about the new standards and technologies, deployment strategies, and business opportunities. Get access to information, insight, knowledge and experts not available at less-focused industry shows. QoS Network Showcase -------------------- The iBAND4 Showcase is the third in a series of networks engineered by members of the QoS Forum. This time around, the showcase features solutions to two substantial classes of problem being confronted by managers of IP networks: - Napster/MP3-based traffic saturation - Denial of Service Attacks Within this showcase, you can see new Quality of Service and Policy Management capabilities in hosts, applications, routers, switches and network analysis tools. Engineered into several different network topologies, these interoperable products harness new protocol standards and show how network managers can use them to address real problems confronting their IP networks. Keynotes outline QoS-enabled, Policy-based B2B networks! -------------------------------------------------------- Evan Kaplan, ceo of Aventail: "B2B Models & the Fundamental Need for Policy-based Networking" Tony Naughtin, ceo of InterNAP: "The Real-World Marriage of QoS and Policy" Brian Carpenter, dir of Internet technology & standards for IBM: "The Evolution and Integration of Emerging Standards" IPv6 and IP Multicast Workshops ------------------------------- Attend one of these advanced technology workshops to understand how the protocols work and how they can be integrated into your network. IP Multicast at a Crossroads http://www.stardust.com/iband4/multicast.htm IPv6 - Understanding the Next Generation http://www.stardust.com/iband4/ipv6.htm The iBAND workshops will be taught on June 14th. Space is very limited. For more information call (408)879-8080 or visit http://www.stardust.com/iband4/ Sign-up Now and Save Money -------------------------- The price will move to $1,395 after June 2nd. Register today at http://www.stardust.com/iband4/ or call (408)879-8080. --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.com