Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25661; 2 Aug 93 3:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25657; 2 Aug 93 3:00 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01171; 2 Aug 93 3:00 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25650; 2 Aug 93 3:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25646; 2 Aug 93 3:00 EDT Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa01166; 2 Aug 93 3:00 EDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23395; Mon, 2 Aug 1993 09:00:52 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA20872; Mon, 2 Aug 1993 09:00:44 +0200 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9308020700.AA20872@dxcern.cern.ch> Subject: Re: Routing Over Large Clouds To: Noel Chiappa Date: Mon, 2 Aug 1993 09:00:42 +0200 (MET DST) Cc: bill.simpson@um.cc.umich.edu, jmh@anubis.network.com, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu, rolc@network.com In-Reply-To: <9307301701.AA28659@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 30, 93 01:01:39 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 992 Noel, everybody, >--------- Text sent by Noel Chiappa follows: ... > The Right Thing *is* to dissolve IPLPDN, and set up two WG's: one each > *specifically* for i) address resolution mechanisms on large WAN's (since we > have current need for this, plus at least one IPng candidate with a very > determined camp of shortish-fixed-length-internetwork-address advocates), and > ii) routing mechanisms for large WAN's. The charters should *specifically > prohibit* any work on stuff outside the charters, and the Chair's and AD's > have to enforce these. > I'm concerned that the basic architectural dilemma faced by ATM proponents (does ATM support a catenet architecture, or render it obsolete?) has to be faced at the same time as these two issues. You need to read Bob Cole's IP/ATM framework draft to see this spelled out. Of course, if ATM fails in the market, then it doesn't matter. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00163; 2 Aug 93 9:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00145; 2 Aug 93 9:34 EDT Received: from nsco.network.com by CNRI.Reston.VA.US id aa09855; 2 Aug 93 9:34 EDT Received: from att.att.com by nsco.network.com (5.61/1.34) id AA29950; Mon, 2 Aug 93 08:01:08 -0500 Message-Id: <9308021301.AA29950@nsco.network.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmurali@qsun.att.com Date: Mon, 2 Aug 93 08:49 EDT To: frftc@nsco.network.com Cc: ATM@qsun.att.com, and@qsun.att.com, based@qsun.att.com, ifOutUCastPkts@qsun.att.com, interfaces@qsun.att.com Subject: bmurali Hello, In using[applying] the ifTable defined in MIB II for ATM based interfaces, the variable ifOutUCastPkts seems to have a slightly different interpretation per ifTable than most ATM implementations [as shown below]. In fact, as is noted in the Bellcore proposal on ATM managed objects, the "number of cells transmitted" is switch architecture dependent and consequently, the value for ifOutUCastPkts [which is defined as the number of cells received for transmission] may not be uniformly derivable. from the transmitted network +-------+ on channel ------------>| Lport |-------------> ^ +-------+ ^ | | | | | | | | | | | | | | | | | | ifOut No. of Pkts UcastPkts transmitted Given that the definition of ifTable objects should not be changed, we propose the following for ATM based interfaces: . The protocol-specific MIB for ATM interfaces include an object that count the "number of Cells transmitted". . The ifOutUCastPkts, when queried, return noSucName. Comments? /Baktha Cross posted in: frftc@nsco.network.com atommib@thumper.bellcore.com if-mib@thumper.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03885; 2 Aug 93 11:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03881; 2 Aug 93 11:22 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13736; 2 Aug 93 11:22 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03868; 2 Aug 93 11:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03860; 2 Aug 93 11:22 EDT Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa13731; 2 Aug 93 11:22 EDT Received: by ginger.lcs.mit.edu id AA12525; Mon, 2 Aug 93 11:22:49 -0400 Date: Mon, 2 Aug 93 11:22:49 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9308021522.AA12525@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu Subject: Re: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com > The Right Thing *is* to ... set up two WG's: one each ... for i) address > resolution mechanisms on large WAN's ..., and ii) routing mechanisms for > large WAN's. I'm concerned that the basic architectural dilemma faced by ATM proponents (does ATM support a catenet architecture, or render it obsolete?) has to be faced at the same time as these two issues. Excuse me while I fall off my chair laughing! (I'm only laughing because the other option is getting pissed off, and that's not a useful feeling. :-) You may have missed my massive rant to the VC-Routing WG a while back, but as sure as the sun is going to come up tomorrow i) the ATM mesh is going to be part of a global internet, ii) such internet systems have system-wide problems like routing, resource allocation, etc which *cannot* be solved at a purely local level, iii) some parts of the ATM community are going to try to solve these issues at the local level, viewing the ATM mesh as an isolated component, and iv) it won't work. There is nothing you can do to prevent this. While I agree with you that it would be *nice* to solve that basic architetural dilemma, too many people either i) aren't going to see it, or ii) aren't going to get the answer right. I don't know of *any* technique to get through to them; there is an old saying you may know, "there are no so blind as those who will not see"? Only when reality has administered some sharp lessons will people be more receptive. You can't avoid it, so you might as well just sit back and enjoy it. All that can be done is that work can be done in parallel on the Right Answer, so that when the need becomes obvious the solution is in hand, ready to go. Hence, the two working groups. (Actually, the address resolution thing is a temporary kludge, I think, but we still need it for a variety of reasons.) Of course, if ATM fails in the market, then it doesn't matter. Oh, I think ATM is going to succeed, just not quite in the form that's usually visualized. I'll omit the argument as to why and how for now... Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04965; 2 Aug 93 11:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04958; 2 Aug 93 11:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15189; 2 Aug 93 11:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04946; 2 Aug 93 11:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04942; 2 Aug 93 11:53 EDT Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa15173; 2 Aug 93 11:53 EDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04492; Mon, 2 Aug 1993 17:48:25 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA20790; Mon, 2 Aug 1993 17:48:22 +0200 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9308021548.AA20790@dxcern.cern.ch> Subject: Re: Routing Over Large Clouds To: Noel Chiappa Date: Mon, 2 Aug 1993 17:48:22 +0200 (MET DST) Cc: iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-Reply-To: <9308021522.AA12525@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 2, 93 11:22:49 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2515 Noel, et al, >--------- Text sent by Noel Chiappa follows: > > > The Right Thing *is* to ... set up two WG's: one each ... for i) address > > resolution mechanisms on large WAN's ..., and ii) routing mechanisms for > > large WAN's. > > I'm concerned that the basic architectural dilemma faced by ATM proponents > (does ATM support a catenet architecture, or render it obsolete?) has to be > faced at the same time as these two issues. > > Excuse me while I fall off my chair laughing! (I'm only laughing because the > other option is getting pissed off, and that's not a useful feeling. :-) The strange thing is, I agree with you, and I'm glad you said that... > > You may have missed my massive rant to the VC-Routing WG a while back, but as Yes, that list got too much for me :-) > sure as the sun is going to come up tomorrow i) the ATM mesh is going to be > part of a global internet, ii) such internet systems have system-wide problems > like routing, resource allocation, etc which *cannot* be solved at a purely > local level, iii) some parts of the ATM community are going to try to solve > these issues at the local level, viewing the ATM mesh as an isolated > component, and iv) it won't work. ATM cannot solve problems outside itself. That does not mean that systems within an ATM cloud are not allowed to use innovative solutions. What won't work is confusing the two problem spaces. The ATM Forum has already increased the risk of that by confusing the two address spaces. > > There is nothing you can do to prevent this. While I agree with you that it > would be *nice* to solve that basic architetural dilemma, too many people > either i) aren't going to see it, or ii) aren't going to get the answer right. > I don't know of *any* technique to get through to them; there is an old saying > you may know, "there are no so blind as those who will not see"? Only when > reality has administered some sharp lessons will people be more receptive. You > can't avoid it, so you might as well just sit back and enjoy it. > > All that can be done is that work can be done in parallel on the Right Answer, > so that when the need becomes obvious the solution is in hand, ready to go. > Hence, the two working groups. (Actually, the address resolution thing is a > temporary kludge, I think, but we still need it for a variety of reasons.) > I did not comment at all whether the rolc WG should be set up. If you're flushing me out, I think it should be. There. Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08515; 2 Aug 93 14:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08511; 2 Aug 93 14:16 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21273; 2 Aug 93 14:16 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08502; 2 Aug 93 14:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08493; 2 Aug 93 14:16 EDT Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa21257; 2 Aug 93 14:16 EDT Received: by ginger.lcs.mit.edu id AA13713; Mon, 2 Aug 93 14:15:45 -0400 Date: Mon, 2 Aug 93 14:15:45 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9308021815.AA13713@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, jnc@ginger.lcs.mit.edu, rcoltun@sura.net Subject: Re: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US I may be off base with this ... but I would say that the IPv4 and CLNP models are one source of your views that there is broken-ness in the problem with building catenets of ATM networks. I'm not positive I understand what exactly your point is, but don't think that I'm saying that IPv4 or CLNP has the solution to using ATM. I think we need a whole new internetwork layer, one which is neither pure VC nor pure packet, (for many reasons, not just to incorporate ATM). I think the optimal design of data networks is somewhere in the middle. To the extent that this describes the basic concept of ATM, it says that ATM will be a good match to what the future internetwork architecture will be. However, I'm positive we will still need an internetwork layer *above* ATM (for reasons I gave in my long rant to VC-routing). One artifact of this model is a big address vs a multi-tier address such as PIP uses. PIP would nicely support ATM as one (or more) level of the hierarchy. I think that viewing the Internet as one big address space is flawed as opposed to multiple levels. Again, I'm not sure exactly what your point is; if you're saying that a large, flat address space is bad, I absolutely agree with that. If you're saying that a flexible, hierarchical address space is what's needed I agree with that too. Howver, I would think that just makes my point; such an address space is for use by a system-wide routing architecture, not local stuff. Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02904; 3 Aug 93 9:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02900; 3 Aug 93 9:19 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02777; 3 Aug 93 9:19 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05312; Tue, 3 Aug 1993 21:49:33 +1000 (from owner-Big-Internet) Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05304; Tue, 3 Aug 1993 21:49:09 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA29385; Tue, 3 Aug 93 07:48:08 -0400 Date: Tue, 3 Aug 93 07:48:08 -0400 Message-Id: <9308031148.AA29385@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" To: bsimpson@morningstar.com Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US Subject: Re: Routing Over Large Clouds Bill.Simpson writes: I think this should be delayed until we have picked IPng, and then all of the various existing IETF WGs would work on the problems in that context, the same as with multicast. Given that IP will be "out there" for at least another decade, I don't think we should postpone consideration of these problems any longer than we already have. The one positive thing that I note in Stev Knowles' message is that the WG will be in the Routing rather than the Internet Area. What the difference is, I don't know, but hopefully that will be more focused. Hmmm... I'm not sure how to interpret your "positive" then...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08221; 3 Aug 93 13:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08217; 3 Aug 93 13:36 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10630; 3 Aug 93 13:36 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13096; Tue, 3 Aug 93 09:54:50 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12228; Tue, 3 Aug 93 09:55:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03275; Tue, 3 Aug 93 09:52:47 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03269; Tue, 3 Aug 93 09:52:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23417; Tue, 3 Aug 93 09:51:40 PDT Received: from noc.sura.net by Sun.COM (4.1/SMI-4.1) id AA25088; Mon, 2 Aug 93 09:56:36 PDT Received: by noc.sura.net for atm@Sun.COM (5.65b/(SURAnet $Revision: 1.29 $)) id AA02248; Mon, 2 Aug 93 12:56:25 -0400 Date: Mon, 2 Aug 93 12:56:25 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rob Coltun Message-Id: <9308021656.AA02248@noc.sura.net> To: brian@dxcern.cern.ch, jnc@ginger.lcs.mit.edu Subject: Re: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US X-Orig-Sender: atm-request@atm.eng.sun.com Brian and Noel, I may be off base with this (won't be the first time) but I would say that the IPv4 and CLNP models are one source of your views that there is broken-ness in the problem with building catenets of ATM networks. One artifact of this model is a big address vs a multi-tier address such as PIP uses. PIP would nicely support ATM as one (or more) level of the hierarchy. I think that viewing the Internet as one big address space is flawed as opposed to multiple levels. A handful of large corporations that I know of define their networks such that access to and from the Internet has to go through specific entry points and the internal addresses are completely hidden from the outside world (their data-center buildings don't even have signs on the outside, why would they want to allow someone to telnet in?). An ATM network will support using another ATM network as a transit network so a corporate backbone may use a provider for transit traffic to other parts of their corporate net. I think a more useful model of the future Internet is a multi-tiered hierarchy of catenets (ie supported by PIP) of which ATM may be one level. My 2 cents. Got to get back to coding.... ---rob > sure as the sun is going to come up tomorrow i) the ATM mesh is going to be > part of a global internet, ii) such internet systems have system-wide problems > like routing, resource allocation, etc which *cannot* be solved at a purely > local level, iii) some parts of the ATM community are going to try to solve > these issues at the local level, viewing the ATM mesh as an isolated > component, and iv) it won't work. ATM cannot solve problems outside itself. That does not mean that systems within an ATM cloud are not allowed to use innovative solutions. What won't work is confusing the two problem spaces. The ATM Forum has already increased the risk of that by confusing the two address spaces.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16087; 4 Aug 93 20:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16083; 4 Aug 93 20:57 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa00421; 4 Aug 93 20:57 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25048; Wed, 4 Aug 93 17:56:41 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20147; Wed, 4 Aug 93 17:56:42 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA06146; Wed, 4 Aug 93 17:55:14 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA06140; Wed, 4 Aug 93 17:55:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07963; Wed, 4 Aug 93 17:53:47 PDT Received: from relay2.UU.NET by Sun.COM (4.1/SMI-4.1) id AA24935; Wed, 4 Aug 93 17:55:12 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04756; Wed, 4 Aug 93 20:55:05 -0400 Received: from smcwest.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 205320.19853; Wed, 4 Aug 1993 20:53:20 EDT Received: from ccmail by west.smc.com (4.1/SMI-4.1) id AA06672; Wed, 4 Aug 93 17:51:34 PDT Received: from cc:Mail by ccmail (1.30/SMTPLink) id A10403; Wed, 04 Aug 93 17:49:27 PST Date: Wed, 04 Aug 93 17:49:27 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Huang Message-Id: <9308041749.A10403@ccmail> To: atm@sun.com Cc: huang@ccmail.west.smc.com Subject: Subscription to E-mail Discussions X-Orig-Sender: atm-request@atm.eng.sun.com Dear Sirs, My company is a principle member of ATM Forum, and we're interested in receiving E-mail discussions regarding the issues of "IP over ATM" Please put my E-mail address on your mailing list. smtplink%frank_huang@ccmail.west.smc.com Thank you very much.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10674; 11 Aug 93 11:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10670; 11 Aug 93 11:39 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa13768; 11 Aug 93 11:38 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA08819; Wed, 11 Aug 93 08:36:17 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16494; Wed, 11 Aug 93 08:36:16 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16976; Wed, 11 Aug 93 08:35:14 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16970; Wed, 11 Aug 93 08:35:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26958; Wed, 11 Aug 93 08:35:14 PDT Received: from research.att.com by Sun.COM (4.1/SMI-4.1) id AA08547; Wed, 11 Aug 93 08:35:08 PDT Message-Id: <9308111535.AA08547@Sun.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: keshav@research.att.com Date: Wed, 11 Aug 93 11:35 EDT To: atm@sun.com Subject: Holding times for VCs carrying IP X-Orig-Sender: atm-request@atm.eng.sun.com The following paper is available for anonymous FTP from research.att.com:dist/qos/hold.ps.Z. I welcome comments. keshav -------------------------------------------------------- An Empirical Evaluation of Virtual Circuit Holding Times in IP-over-ATM Networks Huzur Saran and S. Keshav* Dept. of C.S. & Engg. I.I.T. Delhi, Hauz Khas New Delhi, India 110016 It is generally recognized that future networks are likely to be connection oriented Asynchronous Transfer Mode (ATM) networks. However, the datagram-oriented Internet Protocol (IP) is the most common network layer protocol in current use. When carrying IP traffic over an ATM network, the ATM adaptation layer needs to determine when to drop a virtual circuit that is opened as a consequence of the arrival of an IP datagram. In this paper we carry out a detailed empirical examination of various holding time policies taking into account the issue of network pricing and offer solutions for two natural pricing scenarios. We find that the data shows temporal locality of reference and that seemingly natural adaptive timeout schemes perform poorly. In view of observed temporal locality in the data, we propose Least Recently Used (LRU)-based holding time policies which use this temporal locality effectively and perform better than any other strategy examined. We show that the fixed timeout scheme where there is a systemwide timeout is equivalent to an LRU-based scheme, and is very effective when the timeout value is chosen correctly. The policies we propose are easy to implement and solve the problem satisfactorily. (*) On leave from AT&T Bell Laboratories, Murray Hill, NJ 07974.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16790; 11 Aug 93 16:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16786; 11 Aug 93 16:40 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26844; 11 Aug 93 16:40 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24657; Wed, 11 Aug 93 13:36:07 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA15786; Wed, 11 Aug 93 13:36:07 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17373; Wed, 11 Aug 93 13:34:45 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17367; Wed, 11 Aug 93 13:34:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20346; Wed, 11 Aug 93 13:34:49 PDT Received: from NAGY.FNAL.GOV by Sun.COM (4.1/SMI-4.1) id AA23780; Wed, 11 Aug 93 13:34:42 PDT Date: Wed, 11 Aug 1993 15:34:40 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "H.A. Kippenhan Jr." To: atm@atm.eng.sun.com Message-Id: <930811153440.36802486@fndcd.fnal.gov> Subject: Availibility of atm discussion archive X-Orig-Sender: atm-request@atm.eng.sun.com Hello ATM readers: I'm pleased to announce that the discussions on the E-mail list atm@atm.eng.sun.com are now being archived on the node NIC.HEP.NET (131.225.100.1). The files of interest can be found in directory ANON_FTP.LISTS-ARCHIVE.ATM.1993. The file names will be of the form: ATM-ARCHIVE.1993-07 A couple of things of interest. I've taken the time to edit out the messages from people who insist on sending subscribe/remove requests to the list (rather than the atm-request address). Also, the archive isn't real-time; that is, a new file will appear early each month (in early September ATM-ARCHIVE.1993-08 will show up). I've tried to contact the list administrators to see if they might have any sort of archive about of discussions prior to July, 1993. So far, no answer (I assume that it's just that they are very busy). If anyone has such an archive and can work with me to make it available via anonymous FTP, I look forward to hearing from you. Best regards. - Kipp - {~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~} { H.A. Kippenhan Jr. | Internet: Kippenhan@FNDCD.FNAL.GOV } { National HEPnet Management | HEPnet/NSI DECnet: FNDCD::KIPPENHAN } { Fermi National Accelerator Lab. | BITnet: Kippenhan@FNDCD.BITNET } { P.O. Box 500 MS: FCC-3E/368 | Telephone: (708) 840-8068 } { Batavia, Illinois 60510 | FAX: (708) 840-8463 } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17712; 11 Aug 93 17:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17708; 11 Aug 93 17:20 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa28770; 11 Aug 93 17:20 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16499; Wed, 11 Aug 93 14:16:00 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19956; Wed, 11 Aug 93 14:15:54 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17519; Wed, 11 Aug 93 14:14:34 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17513; Wed, 11 Aug 93 14:14:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23236; Wed, 11 Aug 93 14:14:39 PDT Received: from hplms26.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA15839; Wed, 11 Aug 93 14:14:32 PDT Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA19803; Wed, 11 Aug 93 14:14:58 -0700 Received: from isenbard.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA21497; Wed, 11 Aug 93 14:14:21 -0700 Received: by isenbard.hpl.hp.com (1.37.109.4/HPL42.42) id AA27136; Wed, 11 Aug 93 14:11:26 -0700 To: "H.A. Kippenhan Jr." Cc: atm@atm.eng.sun.com Subject: Re: Availibility of atm discussion archive In-Reply-To: <930811153440.36802486@fndcd.fnal.gov> References: <930811153440.36802486@fndcd.fnal.gov> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 11 Aug 93 14:11:26 -0700 Message-Id: <930811141126.1708@isenbard.hpl.hp.com> Encoding: 3 TEXT, 2 TEXT SIGNATURE X-Orig-Sender: atm-request@atm.eng.sun.com Kipp, Thanks for the effort of pulling the archive together. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20764; 11 Aug 93 21:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20760; 11 Aug 93 21:43 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06988; 11 Aug 93 21:43 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13436; Wed, 11 Aug 93 18:43:21 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13293; Wed, 11 Aug 93 18:43:23 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17945; Wed, 11 Aug 93 18:42:09 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17939; Wed, 11 Aug 93 18:42:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09242; Wed, 11 Aug 93 18:42:17 PDT Received: from synoptics.com (pobox.synoptics.com) by Sun.COM (4.1/SMI-4.1) id AA12748; Wed, 11 Aug 93 18:42:08 PDT Received: from everest (everest.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA07305; Wed, 11 Aug 93 18:41:12 PDT Received: by everest (4.1/2.0N) id AA09596; Wed, 11 Aug 93 18:41:11 PDT Message-Id: <9308120141.AA09596@everest> Date: Wed, 11 Aug 93 18:41:11 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Farokh J Deboo To: KIPPENHAN@fndcd.fnal.gov Subject: Re: Availibility of atm discussion archive Cc: atm@atm.eng.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com > I've tried to contact the list administrators to see if > they might have any sort of archive about of discussions > prior to July, 1993. Kipp, You may want to look at: ietf.cnri.reston.va.us:ietf-mail-archive/atm. Farokh ----------------------------- % ftp ietf.cnri.reston.va.us. Connected to ietf.cnri.reston.va.us. 220 ietf.CNRI.Reston.VA.US FTP server (Version 6.11 Wed Feb 17 18:54:36 EST 1993) ready. Name (ietf.cnri.reston.va.us.:XXX): anonymous 331 Guest login ok, send e-mail address as password. Password: 230- Welcome to an experimental FTP Server for IETF and ISOC. 230- 230-If you have any unusual problems, please report them via e-mail to 230-root@ietf.CNRI.Reston.VA.US. 230- 230-If you do have problems, please try using a dash (-) as the first character 230-of your password -- this will turn off the continuation messages that may 230-be confusing your ftp client. 230- 230 Guest login ok, access restrictions apply. ftp> cd ietf-mail-archive/atm 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 1409 -rw-rw-r-- 1 1100 1001 48 Dec 1 1992 .92-11.map -rw-rw-r-- 1 1100 1001 32 Jan 5 1993 .92-12.map -rw-r--r-- 1 1100 1001 80 Feb 2 1993 .93-01.map -rw-r--r-- 1 1100 1001 128 Mar 1 22:56 .93-02.map -rw-r--r-- 1 1100 1001 304 Apr 6 19:10 .93-03.map -rw-r--r-- 1 1100 1001 80 May 4 21:29 .93-04.map -rw-r--r-- 1 1100 1001 144 Jun 1 19:31 .93-05.map -rw-r--r-- 1 1100 1001 944 Jul 19 14:43 .93-06.map -rw-r--r-- 1 1100 1001 1776 Aug 2 22:26 .93-07.map -rw-r--r-- 1 1100 1001 112 Aug 2 22:27 .current.map -rw-r--r-- 1 1100 1001 0 Nov 2 1992 92-10 -rw-r--r-- 1 1100 1001 4487 Dec 1 1992 92-11.Z -rw-r--r-- 1 1100 1001 6871 Jan 5 1993 92-12.Z -rw-r--r-- 1 1100 1001 4640 Feb 2 1993 93-01.Z -rw-r--r-- 1 1100 1001 9723 Mar 1 23:01 93-02.Z -rw-r--r-- 1 1100 1001 164275 Apr 6 19:41 93-03 -rw-r--r-- 1 1100 1001 26601 May 5 20:28 93-04 -rw-r--r-- 1 1100 1001 20991 Jun 1 19:31 93-05 -rw-r--r-- 1 1100 1001 294535 Jul 19 14:43 93-06 -rw-r--r-- 1 1100 1001 340581 Aug 2 22:26 93-07 -rw-r--r-- 1 1100 1001 36587 Aug 11 21:20 current -rw-r--r-- 1 1100 1001 469478 Aug 2 22:26 current.old 226 Transfer complete. 1422 bytes received in 0.57 seconds (2.4 Kbytes/s) ftp> quit 221 Goodbye.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20811; 11 Aug 93 21:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20807; 11 Aug 93 21:48 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa07106; 11 Aug 93 21:48 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16152; Wed, 11 Aug 93 18:48:01 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13570; Wed, 11 Aug 93 18:48:03 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17982; Wed, 11 Aug 93 18:46:48 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17976; Wed, 11 Aug 93 18:46:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09403; Wed, 11 Aug 93 18:46:57 PDT Received: from dreggs.cisco.com by Sun.COM (4.1/SMI-4.1) id AA15372; Wed, 11 Aug 93 18:46:49 PDT Received: by dreggs.cisco.com; Wed, 11 Aug 93 18:46:46 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lawrence Lang Message-Id: <9308120146.AA13257@dreggs.cisco.com> Subject: Re: Holding times for VCs carrying IP To: keshav@research.att.com Date: Wed, 11 Aug 93 18:46:46 MDT Cc: atm@sun.com In-Reply-To: <9308111535.AA08547@Sun.COM>; from "keshav@research.att.com" at Aug 11, 93 11:35 am X-Mailer: ELM [version 2.3 PL11] X-Orig-Sender: atm-request@atm.eng.sun.com Isn't this behavior usually heavily influenced by tariffs, at least in the wide area? Larry > > > The following paper is available for anonymous FTP from > research.att.com:dist/qos/hold.ps.Z. I welcome comments. > > keshav > -------------------------------------------------------- > An Empirical Evaluation of Virtual Circuit Holding Times in IP-over-ATM Networks > > Huzur Saran and S. Keshav* > Dept. of C.S. & Engg. > I.I.T. Delhi, Hauz Khas > New Delhi, India 110016 > > > > It is generally recognized that future networks are likely to be > connection oriented Asynchronous Transfer Mode (ATM) networks. > However, the datagram-oriented Internet Protocol (IP) is the most > common network layer protocol in current use. When carrying IP > traffic over an ATM network, the ATM adaptation layer needs to > determine when to drop a virtual circuit that is opened as a > consequence of the arrival of an IP datagram. In this paper we > carry out a detailed empirical examination of various holding > time policies taking into account the issue of network pricing > and offer solutions for two natural pricing scenarios. We find > that the data shows temporal locality of reference and that > seemingly natural adaptive timeout schemes perform poorly. In > view of observed temporal locality in the data, we propose Least > Recently Used (LRU)-based holding time policies which use this > temporal locality effectively and perform better than any other > strategy examined. We show that the fixed timeout scheme where > there is a systemwide timeout is equivalent to an LRU-based > scheme, and is very effective when the timeout value is chosen > correctly. The policies we propose are easy to implement and > solve the problem satisfactorily. > > (*) On leave from AT&T Bell Laboratories, Murray Hill, NJ 07974. > -- ______________________________________________ Lawrence J. Lang Cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, California 94025 USA + 1 415 688 4638 Phone + 1 415 326 1989 Fax llang@cisco.com Email ______________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00936; 12 Aug 93 5:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00924; 12 Aug 93 5:02 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ai01167; 12 Aug 93 5:02 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa00686; 12 Aug 93 3:55 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13174; Thu, 12 Aug 93 00:52:40 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20508; Thu, 12 Aug 93 00:52:46 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18556; Thu, 12 Aug 93 00:51:24 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18550; Thu, 12 Aug 93 00:51:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15630; Thu, 12 Aug 93 00:51:36 PDT Received: from ceres.fokus.gmd.de by Sun.COM (4.1/SMI-4.1) id AA12472; Thu, 12 Aug 93 00:51:18 PDT X400-Received: by mta ceres.fokus.gmd.de in /PRMD=gmd/ADMD=dbp/C=de/; Relayed; Thu, 12 Aug 1993 09:52:19 +0200 X400-Received: by /PRMD=gmd/ADMD=d400/C=de/; Relayed; Thu, 12 Aug 1993 09:33:19 +0200 Date: Thu, 12 Aug 1993 09:33:19 +0200 X400-Originator: gavras@fokus.berlin.gmd.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=gmd/ADMD=d400/C=de/;930812093319] X400-Content-Type: P2-1984 (2) Content-Identifier: 398 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gavras Anastassios Message-Id: <398*/S=gavras/OU=fokus/OU=berlin/PRMD=gmd/ADMD=d400/C=de/@MHS> To: atm-request@atm.eng.sun.com MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Cc: atm@atm.eng.sun.com MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US In-Reply-To: <930811153440.36802486@fndcd.fnal.gov> Subject: Re: Availibility of atm discussion archive X-Orig-Sender: atm-request@atm.eng.sun.com > just that they are very busy). If anyone has such an archive > and can work with me to make it available via anonymous FTP, > I look forward to hearing from you. My archive starts May 1992. If there is interest I can put it on an FTP server. It is in the form: total 3272 -rw-rw---- 1 ag 462688 Jul 6 10:27 atm-apr93 -rw-rw---- 1 ag 193469 Sep 22 1992 atm-aug92 -rw-rw---- 1 ag 297378 Jan 4 1993 atm-dec92 -rw-r----- 1 ag 251514 Apr 28 13:33 atm-feb93 -rw-r----- 1 ag 435034 Apr 28 13:31 atm-jan93 -rw-rw---- 1 ag 86145 Sep 22 1992 atm-jul92 -rw-rw---- 1 ag 116638 Sep 22 1992 atm-jun92 -rw-rw---- 1 ag 162419 Jul 6 11:02 atm-jun93 -rw-r----- 1 ag 323966 Apr 28 13:49 atm-mar93 -rw-rw---- 1 ag 220049 Sep 22 1992 atm-may92 -rw-rw---- 1 ag 293841 Jul 6 10:41 atm-may93 -rw-rw---- 1 ag 43512 Jan 4 1993 atm-nov92 -rw-rw---- 1 ag 121220 Jan 4 1993 atm-oct92 -rw-rw---- 1 ag 197388 Nov 25 1992 atm-sep92 Regards, -- Anastassios Gavras, e-mail:gavras@fokus.gmd.de Tel.:+49 30 25499263 National Research Corporation for Mathematics and Data Processing Research Institute for Open Communication Systems GMD-FOKUS, Hardenbergplatz 2, 10623 Berlin, Germany   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07263; 12 Aug 93 11:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07259; 12 Aug 93 11:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10507; 12 Aug 93 11:06 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29555; Thu, 12 Aug 93 08:01:23 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA25840; Thu, 12 Aug 93 08:01:12 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19094; Thu, 12 Aug 93 07:59:11 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19088; Thu, 12 Aug 93 07:59:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25265; Thu, 12 Aug 93 07:59:17 PDT Received: from ub-gate.UB.com by Sun.COM (4.1/SMI-4.1) id AA27655; Thu, 12 Aug 93 07:59:12 PDT Received: from ast0.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA25583; Thu, 12 Aug 93 07:58:26 PDT Received: by ast0.uucp (4.1/SMI-4.1) id AA20926; Thu, 12 Aug 93 07:58:26 PDT Date: Thu, 12 Aug 93 07:58:26 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Robinson Message-Id: <9308121458.AA20926@ast0.uucp> To: atm@sun.com Subject: atm X-Orig-Sender: atm-request@atm.eng.sun.com I would like to added to the ATM distribution list. Could you do it, or is there someone else I should talk to? Thanks Jim 408-522-3407 ast0!jfr@ub.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08800; 12 Aug 93 12:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08796; 12 Aug 93 12:29 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa13425; 12 Aug 93 12:29 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13160; Thu, 12 Aug 93 09:28:54 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00616; Thu, 12 Aug 93 09:28:53 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19306; Thu, 12 Aug 93 09:27:51 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19300; Thu, 12 Aug 93 09:27:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00827; Thu, 12 Aug 93 09:27:53 PDT Received: from lobster.wellfleet.com by Sun.COM (4.1/SMI-4.1) id AA12965; Thu, 12 Aug 93 09:27:46 PDT Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21160; Thu, 12 Aug 93 12:21:06 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA25652; Thu, 12 Aug 93 12:28:52 EDT Date: Thu, 12 Aug 93 12:28:52 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9308121628.AA25652@cabernet.wellfleet> To: keshav@research.att.com, llang@cisco.com Subject: Re: Holding times for VCs carrying IP Cc: atm@sun.com X-Orig-Sender: atm-request@atm.eng.sun.com Isn't this behavior usually heavily influenced by tariffs, at least in the wide area? Larry > > > The following paper is available for anonymous FTP from > research.att.com:dist/qos/hold.ps.Z. I welcome comments. > > keshav > -------------------------------------------------------- > An Empirical Evaluation of Virtual Circuit Holding Times in IP-over-ATM Networks Given that keshav hasn't replied in at least an hour, I thought that I would jump in here :-). I printed out his paper and read it yesterday. It turns out that they consider tariff explicitly. Of particular concern are two issues: (i) what is the ratio between the costs of keeping a virtual circuit up (including tariff) over time, versus how much it costs to start up a new virtual circuit (including tariff and hidden costs, such as delay); (ii) when will the next packet arrive for a particular virtual circuit. Obviously you don't really know the latter number (if you could accurately predict the future, you would be working on investments rather than data communications), but you can try to predict it based on past history. I think that it is a pretty good paper. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11368; 12 Aug 93 14:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11364; 12 Aug 93 14:20 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa17767; 12 Aug 93 14:20 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25660; Thu, 12 Aug 93 11:17:30 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11584; Thu, 12 Aug 93 11:17:28 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19520; Thu, 12 Aug 93 11:16:15 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19514; Thu, 12 Aug 93 11:16:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08414; Thu, 12 Aug 93 11:16:19 PDT Received: from research.att.com by Sun.COM (4.1/SMI-4.1) id AA24494; Thu, 12 Aug 93 11:16:12 PDT Message-Id: <9308121816.AA24494@Sun.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: keshav@research.att.com Date: Thu, 12 Aug 93 14:14 EDT To: atm@sun.com Subject: Holding times X-Orig-Sender: atm-request@atm.eng.sun.com Continuing Ross's reply (thanks Ross!), we believe that the holding time is influenced by (and I quote from the tex): \item the pricing policy in the network \item the traffic arrival pattern in the network \item the maximum number of open VCs allowed per end-system \item the user's loss of utility from a unit increase in delay We consider each of the four factors in detail in the paper. Specifically, we roll the first and last factors into a holding time threshold, and investigate the behavior of various policies given _measured_ traffic and system limitations. So, yes, we are aware of pricing, and yes, we have explicitly tried to take it into account. keshav   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06133; 13 Aug 93 11:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06129; 13 Aug 93 11:37 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa14215; 13 Aug 93 11:37 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17662; Fri, 13 Aug 93 08:35:58 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA10388; Fri, 13 Aug 93 08:35:58 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20955; Fri, 13 Aug 93 08:34:54 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20949; Fri, 13 Aug 93 08:34:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28537; Fri, 13 Aug 93 08:35:06 PDT Received: from po5.andrew.cmu.edu by Sun.COM (4.1/SMI-4.1) id AA17472; Fri, 13 Aug 93 08:34:50 PDT Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.5/8.5) id LAA06969; Fri, 13 Aug 1993 11:34:45 -0400 Received: via switchmail; Fri, 13 Aug 1993 11:34:44 -0400 (EDT) Received: from white.res.andrew.cmu.edu via qmail ID ; Fri, 13 Aug 1993 11:33:16 -0400 (EDT) Received: from white.res.andrew.cmu.edu via qmail ID ; Fri, 13 Aug 1993 11:33:13 -0400 (EDT) Received: from mms.0.1.23.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.white.res.andrew.cmu.edu.pmax.ul4 via MS.5.6.white.res.andrew.cmu.edu.pmax_ul4; Fri, 13 Aug 1993 11:33:08 -0400 (EDT) Message-Id: Date: Fri, 13 Aug 1993 11:33:08 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jeffrey C. Chen" To: atm@sun.com Subject: ATM FAQ Cc: In-Reply-To: X-Orig-Sender: atm-request@atm.eng.sun.com Is there a FAQ list beign maintained on ATM? If so, where can I get it? Jeff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06797; 13 Aug 93 12:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06792; 13 Aug 93 12:03 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa15358; 13 Aug 93 12:03 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA21296; Fri, 13 Aug 93 09:02:13 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12202; Fri, 13 Aug 93 09:02:11 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21083; Fri, 13 Aug 93 09:01:14 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21077; Fri, 13 Aug 93 09:01:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00199; Fri, 13 Aug 93 09:01:26 PDT Received: from norman.nwnet.net by Sun.COM (4.1/SMI-4.1) id AA21125; Fri, 13 Aug 93 09:01:10 PDT Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA16969; Fri, 13 Aug 93 09:01:06 -0700 Date: Fri, 13 Aug 1993 08:59:38 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Robel Reply-To: Allen Robel Subject: Re: ATM FAQ To: "Jeffrey C. Chen" Cc: atm@sun.com In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Orig-Sender: atm-request@atm.eng.sun.com I'm posting this reply to the list because its probably about time again to redirect people with these sorts of questions elsewhere... On Fri, 13 Aug 1993, Jeffrey C. Chen wrote: > Is there a FAQ list beign maintained on ATM? If so, where can I get it? Jeff, Yes. ftp.nwnet.net in /user-docs/cell-relay Since the atm@sun list is supposed to be for folks that are in the process of defining standards for IP over ATM, I'd suggest future questions like the one above be posted to the cell-relay list. You can subscribe by sending a note to: cell-relay-request@cascade.nwnet.net post via usenet to comp.dcom.cell-relay. regards, Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07838; 13 Aug 93 12:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07834; 13 Aug 93 12:37 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa16952; 13 Aug 93 12:37 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25874; Fri, 13 Aug 93 09:36:22 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14786; Fri, 13 Aug 93 09:36:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21219; Fri, 13 Aug 93 09:35:12 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21213; Fri, 13 Aug 93 09:35:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AB02240; Fri, 13 Aug 93 09:35:24 PDT Received: from thumper.bellcore.com by Sun.COM (4.1/SMI-4.1) id AA25696; Fri, 13 Aug 93 09:35:07 PDT Received: from vorpal.bellcore.com by thumper.bellcore.com (4.1/4.7) id for atm@Sun.COM; Fri, 13 Aug 93 12:35:03 EDT Received: by vorpal.bellcore.com (4.1/4.7) id for jc7k+@andrew.cmu.edu; Fri, 13 Aug 93 12:35:01 EDT Date: Fri, 13 Aug 93 12:35:01 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shikhar Bajaj Message-Id: <9308131635.AA18695@vorpal.bellcore.com> To: atm@sun.com, jc7k+@andrew.cmu.edu Subject: Re: ATM FAQ X-Orig-Sender: atm-request@atm.eng.sun.com > > Is there a FAQ list beign maintained on ATM? If so, where can I get it? > > Jeff > > The archives for comp.dcom.cell-relay are available by anonymous ftp at ftp.nwnet.net in user-docs/cell-relay/archive. The archive is updated each month. Shikhar   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09716; 16 Aug 93 17:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09712; 16 Aug 93 17:38 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa05324; 16 Aug 93 17:38 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24159; Mon, 16 Aug 93 14:38:09 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03060; Mon, 16 Aug 93 14:38:10 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26092; Mon, 16 Aug 93 14:36:52 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26086; Mon, 16 Aug 93 14:36:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19923; Mon, 16 Aug 93 14:36:58 PDT Received: from synoptics.com (pobox.synoptics.com) by Sun.COM (4.1/SMI-4.1) id AA23984; Mon, 16 Aug 93 14:36:49 PDT Received: from milliways (milliways.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA20820; Mon, 16 Aug 93 14:35:49 PDT Received: by milliways (4.1/2.0N) id AA10434; Mon, 16 Aug 93 14:35:49 PDT Message-Id: <9308162135.AA10434@milliways> Date: Mon, 16 Aug 93 14:35:49 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: atm@sun.com Subject: Classical ARP draft X-Orig-Sender: atm-request@atm.eng.sun.com I just noticed that there is no ar$hrd number assigned for NSAP addresses in RFC1340 (assigned numbers). Has someone applied for one? Is ATM really the first network to use NSAPs as "hardware" addresses? Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Distributed Network Systems Group FAX: +1 408 988 5525 SynOptics Communications Inc. E-m: asmith@synoptics.com ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09843; 16 Aug 93 17:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09838; 16 Aug 93 17:50 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa05696; 16 Aug 93 17:50 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25941; Mon, 16 Aug 93 14:48:51 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04323; Mon, 16 Aug 93 14:48:54 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26147; Mon, 16 Aug 93 14:47:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26141; Mon, 16 Aug 93 14:47:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20725; Mon, 16 Aug 93 14:47:55 PDT Received: from synoptics.com (pobox.synoptics.com) by Sun.COM (4.1/SMI-4.1) id AA25819; Mon, 16 Aug 93 14:47:47 PDT Received: from milliways (milliways.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA20947; Mon, 16 Aug 93 14:46:47 PDT Received: by milliways (4.1/2.0N) id AA10439; Mon, 16 Aug 93 14:46:47 PDT Message-Id: <9308162146.AA10439@milliways> Date: Mon, 16 Aug 93 14:46:47 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: atm@sun.com Subject: Classical ARP (my previous query) X-Orig-Sender: atm-request@atm.eng.sun.com Ok, maybe I should have read the last page .......   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05347; 20 Aug 93 10:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05343; 20 Aug 93 10:50 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa11384; 20 Aug 93 10:50 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16538; Fri, 20 Aug 93 07:48:57 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA10944; Fri, 20 Aug 93 07:48:55 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA02464; Fri, 20 Aug 93 07:47:56 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA02458; Fri, 20 Aug 93 07:47:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27398; Fri, 20 Aug 93 07:48:02 PDT Received: from worldlink.worldlink.com (worldlink.com) by Sun.COM (4.1/SMI-4.1) id AA16449; Fri, 20 Aug 93 07:47:56 PDT Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA10809; Fri, 20 Aug 93 10:48:31 -0400 Date: Fri, 20 Aug 93 10:48:31 -0400 Message-Id: <9308201448.AA10809@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Piscitello To: Ross Callon Cc: atm@sun.com Subject: Re: Holding times for VCs carrying IP X-Orig-Sender: atm-request@atm.eng.sun.com you don't really know the latter number (if you could accurately predict the future, you would be working on investments rather than data communications), but you can try to predict it based on past history. huh? I don't really see how you can do this without a really big sampling (big = long, long measurement); anyway, this is not a new problem; we had it with X.25, remember?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04434; 21 Aug 93 19:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04430; 21 Aug 93 19:46 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20120; 21 Aug 93 19:46 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19644; Sat, 21 Aug 93 16:46:01 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27434; Sat, 21 Aug 93 16:46:05 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04795; Sat, 21 Aug 93 16:44:59 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04789; Sat, 21 Aug 93 16:44:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22981; Sat, 21 Aug 93 16:45:07 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA19609; Sat, 21 Aug 93 16:44:59 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27992; Sat, 21 Aug 93 16:44:24 -0700 Subject: ATM WG meeting times at Houston IETF To: atm@eng.sun.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Sat, 21 Aug 93 16:44:23 -0700 Message-Id: <930821164423.2782@matmos.hpl.hp.com> Encoding: 15 TEXT, 2 TEXT SIGNATURE X-Orig-Sender: atm-request@atm.eng.sun.com All ATM WG'ers. The next IETF meeting, is as you know, is during November 1-5 in Houston. We've been assigned Tuesday at 0930 and Thursday at 0930 for working group meeting times. I tried to get us three meeting times again, but was held at two by our AD. Either we will need to be more efficient than we have been at past meetings, or I'll need an agenda in hand in order to get a third day. Please submit any agenda items to me and I will begin putting together the agenda for our two (maybe three) meeting times. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24412; 23 Aug 93 2:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24408; 23 Aug 93 2:11 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa24059; 23 Aug 93 2:11 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15237; Sun, 22 Aug 93 23:10:37 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08672; Sun, 22 Aug 93 23:10:42 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA06753; Sun, 22 Aug 93 23:09:25 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA06747; Sun, 22 Aug 93 23:09:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08923; Sun, 22 Aug 93 23:09:35 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA15095; Sun, 22 Aug 93 23:09:23 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07763; Sun, 22 Aug 93 23:08:37 -0700 Subject: next version of Classical IP and ARP over ATM draft To: atm@eng.sun.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Sun, 22 Aug 93 23:08:37 -0700 Message-Id: <930822230837.7525@matmos.hpl.hp.com> Encoding: 13 TEXT, 787 TEXT X-Orig-Sender: atm-request@atm.eng.sun.com Attached in the next version of the classical draft. I apologize for the length of time it has taken to get to this state since Amsterdam. This draft is current with the results from the WG meeting at Amsterdam. The address resolution portion has been completely rewritten for the single ARP server model. I've passed the text via the ad hoc PVC committee a few times already. I would like to try to get technical closure on this draft within the next three weeks so we can move it along in its process. Mark --------------------------- cut here -------------------------------- Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires February 20, 1994 August 20, 1993 Classical IP and ARP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This document does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging are beyond the scope of this paper. 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Laubach [Page 1] DRAFT Classical IP and ARP over ATM August 1993 Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF and the ad hoc PVC committee at the Amsterdam meeting. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TSS and ANSI standards for addressing in ATM. The characteristics and features of ATM networks are different than those found in LAN's: o ATM provides a virtual circuit switched environment. VC setup may be done on either a Permanent Virtual Circuit (PVC) or dynamic Switched Virtual Circuit (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). o ATM standards provide several formats for the exchange of Protocol Data Units (PDU's), these formats are called ATM Laubach [Page 2] DRAFT Classical IP and ARP over ATM August 1993 Adaptation Layers (AAL's). When a virtual circuit is created a specific AAL type is associated with the VC. This type is specified either by administrative control for PVC's or via signalling for SVC's. There are five different AAL format types, which are commonly referred to as "AALn", where "n" is a number from one 1 through 5. There is no field in an ATM cell header which carries this AAL type value, rather it is known at each hop of the path due to the call setup mechanism. The AAL5 format specifies a packet format with a maximum size of 64K - 8 user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating end of PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. o ATM-FORUM signalling defines point-to-point and point-to- multipoint circuit setup [9]. Multipoint-to-multipoint virtual circuits are not not yet a conformance requirement of the ATM- FORUM. o ATM-FORUM local LAN addresses (in the address resolution protocol context) use the same basic format as GOSIP NSAP's [11]. Note: ATM-FORUM addresses should not be construed at being GOSIP NSAP's, they are not, the administration is different, which fields get filled out are different, etc. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets. o IP destinations map to VC's via ARP and end-to-end IP routing stays the same, consistent with current model. o ARP's stay within the LIS, current ARP architecture stays the same. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for all these VC's. Laubach [Page 3] DRAFT Classical IP and ARP over ATM August 1993 The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VC's (e.g., TCP and UDP ports map directly onto VC's) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Applications map directly to VC's, requiring changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's are global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per application and per VC basis. The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. o Standards for global IP over ATM will take some time to complete and deploy. This memo details the treatment of the classical model of IP and ARP over ATM. There are those would like to have IP-over-ATM begin by Laubach [Page 4] DRAFT Classical IP and ARP over ATM August 1993 breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is a station attached to the ATM network that is configured as a member of two or more LIS's. This configuration may result in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets would communicate via an intermediate router even though a direct virtual circuit between the two hosts may be available over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [4] when using SVC's. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pairs of stations. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM address of the individual IP station. Each host must be configured to accept datagrams Laubach [Page 5] DRAFT Classical IP and ARP over ATM August 1993 destined for this address o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM hardware address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target hardware addresses for SVC connections. That server must have authoritative responsibility for resolving ARP requests of all IP stations within the LIS. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams. This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the default ATM AAL5 protocol data unit size is 9188 octets. In classical IP subnets, values other than the default can only be used if and only if all stations in the LIS have been configured to use the non- default value. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. ADDRESS RESOLUTION Laubach [Page 6] DRAFT Classical IP and ARP over ATM August 1993 Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [9] and all IP stations are required to support these protocols. Use of these protocols differ depending on whether permanent virtual circuits (PVC's) or switched virtual circuits (SVC's) are used. Permanent Virtual Circuits An IP station must have a mechanism for determining what PVC's it has, and in particular which PVC's are being used for LLC/SNAP encapsulated protocols. The details of the mechanism are beyond the scope of this memo. All IP stations supporting permanent virtual circuits are required to use the Inverse Address Resolution Protocol (InARP) as defined in [9] on those virtual circuits using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant virtual circuit from the virtual circuit on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM source and/or target hardware address is unknown, the corresponding hardware address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. From [9]: "When the requesting station receives the InARP reply, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances." It is the responsibility of each IP station supporting ATM permanent virtual circuits to re-validate ARP table entries as part of the aging process. See the section below on "ARP Table Aging - All Stations". Switched Virtual Circuits ATM switched virtual circuits require support for ARP in the non- broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for resolving the ARP requests of all IP stations within the LIS. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point virtual circuit. The server, upon receiving a new virtual circuit specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the Laubach [Page 7] DRAFT Classical IP and ARP over ATM August 1993 client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. The ARP server mechanism requires that each client be administratively configured with the ATM hardware address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. This ARP server must be administratively configured so that it knows it is the ARP server. The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. This memo recognizes that a single ARP Server is not as robust as multiple servers which synchronize their databases correctly. This document is defining the client-server interaction by using a simple, single server approach as a reference model, and does not prohibit more robust approaches which use the same client-server interface. ARP Server Operational Requirements The ARP server accepts switched virtual circuit connections from other ATM stations. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM hardware address. The server will add (or update) the map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP hardware address does not match the table entry hardware address and there is an open virtual circuit associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table or a negative ARP reply (ARP_NAK). The ARP_NAK response is an extension to the ARP protocol and is used to improve the robustness of the ARP server mechanism. With ARP_NAK, a client can determine the difference between a catastrophic server failure and an ARP table lookup failure. The ARP_NAK packet format is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for transmission with the ARP_REQUEST operation code reset to ARP_NAK. ARP table information timeout update: when the server receives an ARP Laubach [Page 8] DRAFT Classical IP and ARP over ATM August 1993 request over a virtual circuit, and the source information (IP and hardware address) match the association already in the ARP table, and the hardware address matches that associated with the virtual circuit (in the SVC environment), then the server may update the timeout on the ARP table entry. ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh ARP information about other IP stations. ARP clients are required to: 1. Initiate the virtual circuit connection to the ARP server for transmitting and receiving ARP and InARP packets. 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP table entries. 5. Provide an ARP table aging function to remove old ARP tables entries after a convenient period of time. Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. ARP Table Aging - All stations A client or server must have knowledge of any open VC's it has (permanent or switched), their association with an ARP table entry, and in particular, which VC's support LLC/SNAP encapsulation. Client ARP table entries are valid for a maximum time of 15 minutes. Server ARP table entries are valid for a minimum time of 20 minutes. Prior to aging (removing) an ARP table entry, all stations must generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the Laubach [Page 9] DRAFT Classical IP and ARP over ATM August 1993 entry is deleted. ARP and InARP Packet Format Internet addresses are assigned independent of ATM-FORUM NSAP addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to ATM hardware addresses when needed. The ARP and InARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shln 8 bits Octet length of source hardware address (m) ar$spln 8 bits Octet length of source protocol address (n) ar$op 16 bits Operation code (request or reply) ar$thln 8 bits Octet length of target hardware address (p) ar$tpln 8 bits Octet length of target protocol address (q) ar$sha moctets source hardware address ar$spa noctets source protocol address ar$tha poctets target hardware address ar$tpa qoctets target protocol address Where: ar$hrd - assigned to ATM-FORUM NSAP address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$shln - length of the source hardware NSAP address length. ar$spln - length in bytes of the source protocol address. For IP ar$spln is 4. ar$op - The operation type value (decimal): ARP_REQUEST = 1 ARP_REPLY = 2 InARP_REQUEST = 8 InARP_REPLY = 9 ARP_NAK = ?? ar$thln - length of the target hardware NSAP address length. Laubach [Page 10] DRAFT Classical IP and ARP over ATM August 1993 ar$tpln - length in bytes of the target protocol address. For IP ar$tpln is 4. ar$sha - source NSAP address. ar$spa - source protocol address. ar$tha - target NSAP address. ar$tpa - target protocol address. The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be ATM-FORUM specified NSAP addresses [9]. The same NSAP encoding SHALL be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 hardware addresses may be used but not both. ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 octets) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. Laubach [Page 11] DRAFT Classical IP and ARP over ATM August 1993 The LLC/SNAP encapsulation for ARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ARP'ing outside the LIS or by a global ARP mechanism are beyond the scope of this memo. 10. IP Broadcast Address ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict stations from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Stations, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. This memo recognizes the future development of ATM multicast service addressing by the ATM-FORUM. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward. 12. Security Security issues are not discussed in this memo. This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this memo. 13. Open Issues o A proposal was put before the Internet Assigned Numbers Authority Laubach [Page 12] DRAFT Classical IP and ARP over ATM August 1993 to approve a request to create an ARP hardware type of "ATM-FORUM NSAP address". IANA has not responded as of this date. o Well known ATM hardware address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", ATM-FORUM, 480 San Antonio Road, Suite 100, Mountain View, CA 94040, June 1993. Laubach [Page 13] DRAFT Classical IP and ARP over ATM August 1993 [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, USC/Information Sciences Institute, August 1989. [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, USC/Information Sciences Institute, July 1991. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 14]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27750; 23 Aug 93 9:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27746; 23 Aug 93 9:35 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02954; 23 Aug 93 9:35 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18167; Mon, 23 Aug 93 06:34:38 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12955; Mon, 23 Aug 93 06:34:36 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07361; Mon, 23 Aug 93 06:33:39 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07355; Mon, 23 Aug 93 06:33:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20100; Mon, 23 Aug 93 06:33:44 PDT Received: from relay.fore.com by Sun.COM (4.1/SMI-4.1) id AA18041; Mon, 23 Aug 93 06:33:40 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA08063; Mon, 23 Aug 93 09:33:32 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA10826; Mon, 23 Aug 93 09:33:36 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA20301; Mon, 23 Aug 93 09:33:31 EDT Date: Mon, 23 Aug 93 09:33:31 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9308231333.AA20301@marlin.fore.com> To: atm@eng.sun.com, laubach@matmos.hpl.hp.com Subject: Re: ATM WG meeting times at Houston IETF X-Orig-Sender: atm-request@atm.eng.sun.com > We've been assigned Tuesday at 0930 and Thursday at 0930 for working > group meeting times. I tried to get us three meeting times again, but > was held at two by our AD. Either we will need to be more efficient > than we have been at past meetings, or I'll need an agenda in hand in > order to get a third day. > > Please submit any agenda items to me and I will begin putting together > the agenda for our two (maybe three) meeting times. Actually, two might be ideal. With ROLC being in a different area, the likelihood of conflict between ROLC and ATM will be quite high. Most ATM WG'ers are also ROLC WG'ers... Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28376; 23 Aug 93 9:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28369; 23 Aug 93 9:56 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03597; 23 Aug 93 9:56 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28350; 23 Aug 93 9:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220; 23 Aug 93 9:52 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481; 23 Aug 93 9:52 EDT Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 06:53:15 -0700 Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA13355; Mon, 23 Aug 93 08:47:34 -0500 Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 23 Aug 93 08:52 CDT Message-Id: X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "George H. Clapp" Subject: dissolution of IPLPDN To: IPLPDN WG Date: Mon, 23 Aug 93 8:52:00 CDT Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00759; 23 Aug 93 11:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00755; 23 Aug 93 11:37 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06651; 23 Aug 93 11:37 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03316; Mon, 23 Aug 93 08:35:46 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16677; Mon, 23 Aug 93 08:35:45 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07664; Mon, 23 Aug 93 08:34:50 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07658; Mon, 23 Aug 93 08:34:49 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28667; Mon, 23 Aug 93 08:34:51 PDT Received: from Eng.Sun.COM (zigzag-bb) by snail.Sun.COM (4.1/SMI-4.1) id AA15551; Mon, 23 Aug 93 08:34:46 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16593; Mon, 23 Aug 93 08:34:45 PDT Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4) id AA01822; Mon, 23 Aug 1993 08:34:40 +0800 Date: Mon, 23 Aug 1993 08:34:40 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Hinden Message-Id: <9308231534.AA01822@bigriver.Eng.Sun.COM> To: "George H. Clapp" Cc: IPLPDN WG , IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF In-Reply-To: Subject: re: dissolution of IPLPDN Content-Length: 513 X-Orig-Sender: atm-request@atm.eng.sun.com George, As the IESG Area Director who helped start IPLPDN, I wish to congratulate you and the IPLPDN working group for a job well done. I think we all found out there was a lot important work which needed to be done in this area. The work done by IPLPDN under your leadership was very good and solved real problems for people. It helped create additional environments to run IP which did not exist when the group was started. I personally thank you and the IPLPDN working group for a job well done. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03143; 23 Aug 93 13:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03136; 23 Aug 93 13:48 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10968; 23 Aug 93 13:48 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03117; 23 Aug 93 13:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03044; 23 Aug 93 13:46 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10911; 23 Aug 93 13:46 EDT Received: from nic.cerf.net by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 10:46:48 -0700 Received: from [198.67.38.102] by nic.cerf.net (4.1/CERFnet-1.0) id AA06836; Mon, 23 Aug 93 10:50:09 PDT Date: Mon, 23 Aug 93 10:50:08 PDT Message-Id: <9308231750.AA06836@nic.cerf.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: High Bandwidth Services Startup X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Berger Subject: dissolution of IPLPDN Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com Robert J. Berger Internet: rberger@cerf.net InterNex Information Services 1050 Chestnut Street Suite 202, Menlo Park, CA 94025 Voice: 415-473-3060 Fax: 415-473-3062 Email after 8/25: rberger@internex.net   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00392; 23 Aug 93 19:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00383; 23 Aug 93 19:13 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02204; 23 Aug 93 19:13 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA20845; Mon, 23 Aug 93 16:12:58 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04637; Mon, 23 Aug 93 16:12:55 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA08379; Mon, 23 Aug 93 16:11:51 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA08373; Mon, 23 Aug 93 16:11:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06020; Mon, 23 Aug 93 16:11:57 PDT Received: from cpmx.saic.com by Sun.COM (4.1/SMI-4.1) id AA20685; Mon, 23 Aug 93 16:11:49 PDT Message-Id: <9308232311.AA20685@Sun.COM> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700 Date: 23 Aug 1993 12:53:18 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: QM Administrator Subject: dissolution of IPLPDN To: IPLPDN WG Cc: IETF , ietf-ppp@ucdavis.edu, IP over ATM WG , rolc@network.com X-Orig-Sender: atm-request@atm.eng.sun.com Mail*Link(r) SMTP dissolution of IPLPDN Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267; 23 Aug 93 9:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220; 23 Aug 93 9:52 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481; 23 Aug 93 9:52 EDT Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 06:53:15 -0700 Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA13355; Mon, 23 Aug 93 08:47:34 -0500 Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 23 Aug 93 08:52 CDT Message-Id: Sender:ietf-request@IETF.CNRI.Reston.VA.US From: "George H. Clapp" Subject: dissolution of IPLPDN To: IPLPDN WG Date: Mon, 23 Aug 93 8:52:00 CDT Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00576; 23 Aug 93 19:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00572; 23 Aug 93 19:23 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02392; 23 Aug 93 19:23 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00494; 23 Aug 93 19:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ac00475; 23 Aug 93 19:17 EDT Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa02122; 23 Aug 93 19:11 EDT Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700 Date: 23 Aug 1993 12:53:18 U X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: QM Administrator Subject: dissolution of IPLPDN To: IPLPDN WG CC: IETF , ietf-ppp@ucdavis.edu, IP over ATM WG , rolc@network.com Message-ID: <9308231911.aa02122@CNRI.Reston.VA.US> Mail*Link(r) SMTP dissolution of IPLPDN Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267; 23 Aug 93 9:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220; 23 Aug 93 9:52 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481; 23 Aug 93 9:52 EDT Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 06:53:15 -0700 Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA13355; Mon, 23 Aug 93 08:47:34 -0500 Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 23 Aug 93 08:52 CDT Message-Id: Sender:ietf-request@IETF.CNRI.Reston.VA.US From: "George H. Clapp" Subject: dissolution of IPLPDN To: IPLPDN WG Date: Mon, 23 Aug 93 8:52:00 CDT Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00626; 23 Aug 93 19:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00618; 23 Aug 93 19:26 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02461; 23 Aug 93 19:26 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00603; 23 Aug 93 19:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ad00475; 23 Aug 93 19:17 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02127; 23 Aug 93 19:11 EDT Received: from cpmx.SAIC.COM by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 16:12:22 -0700 Message-Id: <199308232312.AA20723@venera.isi.edu> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700 Date: 23 Aug 1993 12:53:18 U X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: QM Administrator Subject: dissolution of IPLPDN To: IPLPDN WG Cc: IETF , ietf-ppp@ucdavis.edu, IP over ATM WG , rolc@network.com Mail*Link(r) SMTP dissolution of IPLPDN Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267; 23 Aug 93 9:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220; 23 Aug 93 9:52 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481; 23 Aug 93 9:52 EDT Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 06:53:15 -0700 Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA13355; Mon, 23 Aug 93 08:47:34 -0500 Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 23 Aug 93 08:52 CDT Message-Id: Sender:ietf-request@IETF.CNRI.Reston.VA.US From: "George H. Clapp" Subject: dissolution of IPLPDN To: IPLPDN WG Date: Mon, 23 Aug 93 8:52:00 CDT Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00971; 23 Aug 93 20:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00967; 23 Aug 93 20:43 EDT Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa04087; 23 Aug 93 20:43 EDT Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA06197; Mon, 23 Aug 93 16:26:11 PDT X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from cpmx.saic.com by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA05484; Mon, 23 Aug 93 16:10:34 PDT Message-Id: <9308232310.AA05484@ucdavis.ucdavis.edu> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700 Date: 23 Aug 1993 12:53:18 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: QM Administrator Subject: dissolution of IPLPDN To: IPLPDN WG Cc: IETF , ietf-ppp@ucdavis.edu, IP over ATM WG , rolc@network.com Mail*Link(r) SMTP dissolution of IPLPDN Reflecting discussions at the last two IETF meetings, this note is to announce that the IP over Large Public Data Networks WG has disbanded. Unfinished work will be continued in the IP over ATM, PPP-EXT, and Routing over Large Clouds Working Groups. IPLPDN is closing down because issues had migrated to the IP over ATM WG and because of an Area Director policy to create working groups that focus on specific issues rather than on general topics. The mail list will continue to be maintained, and RFCs which are on the standards track will be shepherded through by email. These RFCs include... o Multiprotocol over Frame Relay o Inverse ARP o Multiprotocol over X.25 Please let me know if there are other RFCs that are should be listed. There was some recent email to the effect that IPLPDN solved the easy problems and punted on the hard ones. This criticism of IPLPDN is not really troubling because I am confident of the quality of work done by the group. I owe it to my colleagues in the group, though, to respond. IPLPDN dealt with problems that *had* to be solved to enable near-term, interoperable implementations of virtual private networks over public, switched data services. We produced excellent work that has been widely accepted and implemented. You would be hard pressed to find a vendor of SMDS and Frame Relay equipment who does not implement RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground- breaking work on address resolution in large environments. The work on Shortcut Routing and Directed ARP has advanced the understanding of people who are now participating in the IP over ATM and ROLC WGs. Finally, we went a long way towards nailing down "multiprotocol over circuit switched services" (included circuit ISDN), and this work should be completed soon in the PPP group. This recent criticism is unfortunate, and I'm sorry that we are ending on a bit of a sour note. But I'm confident that the work done by IPLPDN will continue to have value and that these comments will be recognized as misplaced. IPLPDN was a great group that stayed focused on solving technical problems. It was terrific fun, and I'm glad to have had the chance to participate. George Clapp voice: 708-248-6507 fax: 708-248-3996 email: clapp@ameris.center.il.ameritech.com ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267; 23 Aug 93 9:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220; 23 Aug 93 9:52 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481; 23 Aug 93 9:52 EDT Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 23 Aug 1993 06:53:15 -0700 Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA13355; Mon, 23 Aug 93 08:47:34 -0500 Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 23 Aug 93 08:52 CDT Message-Id: Sender:ietf-request@IETF.CNRI.Reston.VA.US From: "George H. Clapp" Subject: dissolution of IPLPDN To: IPLPDN WG Date: Mon, 23 Aug 93 8:52:00 CDT Cc: IP over ATM WG , ietf-ppp@ucdavis.edu, rolc@network.com, IETF   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07261; 24 Aug 93 14:16 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15602; 24 Aug 93 14:16 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07242; 24 Aug 93 14:16 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07123; 24 Aug 93 14:12 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atm@sun.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-atm-classic-ip-02.txt Date: Tue, 24 Aug 93 14:11:59 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9308241412.aa07123@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Asynchronous Transfer Mode Working Group of the IETF. Title : Classical IP and ARP over ATM Author(s) : M. Laubach Filename : draft-ietf-atm-classic-ip-02.txt Pages : 14 This memo describes an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in RFC1209. This document does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging are beyond the scope of this paper. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-atm-classic-ip-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-atm-classic-ip-02.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-atm-classic-ip-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atm-classic-ip-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00711; 26 Aug 93 3:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00707; 26 Aug 93 3:16 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa01532; 26 Aug 93 3:16 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26035; Thu, 26 Aug 93 00:16:01 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09550; Thu, 26 Aug 93 00:16:07 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA12241; Thu, 26 Aug 93 00:15:01 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA12235; Thu, 26 Aug 93 00:15:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08945; Thu, 26 Aug 93 00:15:13 PDT Received: from thuer.netcs.com ([192.76.152.15]) by Sun.COM (4.1/SMI-4.1) id AA25956; Thu, 26 Aug 93 00:14:59 PDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA29699; Thu, 26 Aug 1993 09:14:30 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA08874; Wed, 25 Aug 93 09:14:26 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9308250714.AA08874@keks.netcs.com> Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Date: Wed, 25 Aug 93 9:14:24 MEST Cc: iplpdn@CNRI.Reston.VA.US, atm@sun.com, ietf-ppp@ucdavis.edu, rolc@nsco.network.com, ietf@venera.isi.edu In-Reply-To: ; from "George H. Clapp" at Aug 23, 93 8:52 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 X-Orig-Sender: atm-request@atm.eng.sun.com > > This recent criticism is unfortunate, and I'm sorry that we are ending on > a bit of a sour note. But I'm confident that the work done by IPLPDN will > continue to have value and that these comments will be recognized as > misplaced. IPLPDN was a great group that stayed focused on solving technical > problems. It was terrific fun, and I'm glad to have had the chance to > participate. One point I can't resist to mention: The discussion "multiprotocol over circuit switched ISDN" was started too late. Here, in non-US countries, we now have a variety of methods for IP and other protocols over the ISDN. I hope that finally ppp will be widely accepted (just to have ONE standard, but it will now take some time to established and accepted method). ppp may not be the most efficient method, but anyhow. Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11) > > George Clapp > voice: 708-248-6507 > fax: 708-248-3996 > email: clapp@ameris.center.il.ameritech.com >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09934; 26 Aug 93 14:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09930; 26 Aug 93 14:56 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19288; 26 Aug 93 14:56 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09892; 26 Aug 93 14:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09888; 26 Aug 93 14:55 EDT Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa19245; 26 Aug 93 14:55 EDT Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700 Date: 26 Aug 1993 11:39:16 +0000 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CPSMTP01 Admin Subject: Re: dissolution of IPLPDN To: "George H. Clapp" CC: atm@sun.com, ietf-ppp@ucdavis.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, rolc@nsco.network.com Message-ID: <9308261455.aa19245@CNRI.Reston.VA.US> Mail*Link(r) SMTP RE>dissolution of IPLPDN > > This recent criticism is unfortunate, and I'm sorry that we are ending on > a bit of a sour note. But I'm confident that the work done by IPLPDN will > continue to have value and that these comments will be recognized as > misplaced. IPLPDN was a great group that stayed focused on solving technical > problems. It was terrific fun, and I'm glad to have had the chance to > participate. One point I can't resist to mention: The discussion "multiprotocol over circuit switched ISDN" was started too late. Here, in non-US countries, we now have a variety of methods for IP and other protocols over the ISDN. I hope that finally ppp will be widely accepted (just to have ONE standard, but it will now take some time to established and accepted method). ppp may not be the most efficient method, but anyhow. Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11) > > George Clapp > voice: 708-248-6507 > fax: 708-248-3996 > email: clapp@ameris.center.il.ameritech.com > ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717; 26 Aug 93 3:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681; 26 Aug 93 3:14 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472; 26 Aug 93 3:13 EDT Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 00:14:37 -0700 Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA29699; Thu, 26 Aug 1993 09:14:30 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA08874; Wed, 25 Aug 93 09:14:26 +0200 Sender:ietf-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9308250714.AA08874@keks.netcs.com> Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Date: Wed, 25 Aug 93 9:14:24 MEST Cc: iplpdn@CNRI.Reston.VA.US, atm@sun.com, ietf-ppp@ucdavis.edu, rolc@nsco.network.com, ietf@isi.edu In-Reply-To: ; from "George H. Clapp" at Aug 23, 93 8:52 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09947; 26 Aug 93 14:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09940; 26 Aug 93 14:56 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19304; 26 Aug 93 14:56 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09915; 26 Aug 93 14:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09882; 26 Aug 93 14:55 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19228; 26 Aug 93 14:55 EDT Received: from cpmx.SAIC.COM by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 11:55:43 -0700 Message-Id: <199308261855.AA15591@venera.isi.edu> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700 Date: 26 Aug 1993 11:39:16 +0000 X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CPSMTP01 Admin Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Cc: atm@sun.com, ietf-ppp@ucdavis.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, rolc@nsco.network.com Mail*Link(r) SMTP RE>dissolution of IPLPDN > > This recent criticism is unfortunate, and I'm sorry that we are ending on > a bit of a sour note. But I'm confident that the work done by IPLPDN will > continue to have value and that these comments will be recognized as > misplaced. IPLPDN was a great group that stayed focused on solving technical > problems. It was terrific fun, and I'm glad to have had the chance to > participate. One point I can't resist to mention: The discussion "multiprotocol over circuit switched ISDN" was started too late. Here, in non-US countries, we now have a variety of methods for IP and other protocols over the ISDN. I hope that finally ppp will be widely accepted (just to have ONE standard, but it will now take some time to established and accepted method). ppp may not be the most efficient method, but anyhow. Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11) > > George Clapp > voice: 708-248-6507 > fax: 708-248-3996 > email: clapp@ameris.center.il.ameritech.com > ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717; 26 Aug 93 3:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681; 26 Aug 93 3:14 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472; 26 Aug 93 3:13 EDT Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 00:14:37 -0700 Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA29699; Thu, 26 Aug 1993 09:14:30 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA08874; Wed, 25 Aug 93 09:14:26 +0200 Sender:ietf-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9308250714.AA08874@keks.netcs.com> Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Date: Wed, 25 Aug 93 9:14:24 MEST Cc: iplpdn@CNRI.Reston.VA.US, atm@sun.com, ietf-ppp@ucdavis.edu, rolc@nsco.network.com, ietf@isi.edu In-Reply-To: ; from "George H. Clapp" at Aug 23, 93 8:52 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09963; 26 Aug 93 14:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09959; 26 Aug 93 14:59 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa19352; 26 Aug 93 14:59 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03702; Thu, 26 Aug 93 11:56:54 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06686; Thu, 26 Aug 93 11:57:05 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13113; Thu, 26 Aug 93 11:55:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13107; Thu, 26 Aug 93 11:55:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08525; Thu, 26 Aug 93 11:55:53 PDT Received: from cpmx.saic.com by Sun.COM (4.1/SMI-4.1) id AA03546; Thu, 26 Aug 93 11:55:47 PDT Message-Id: <9308261855.AA03546@Sun.COM> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700 Date: 26 Aug 1993 11:39:16 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CPSMTP01 Admin Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Cc: atm@sun.com, ietf-ppp@ucdavis.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, rolc@nsco.network.com X-Orig-Sender: atm-request@atm.eng.sun.com Mail*Link(r) SMTP RE>dissolution of IPLPDN > > This recent criticism is unfortunate, and I'm sorry that we are ending on > a bit of a sour note. But I'm confident that the work done by IPLPDN will > continue to have value and that these comments will be recognized as > misplaced. IPLPDN was a great group that stayed focused on solving technical > problems. It was terrific fun, and I'm glad to have had the chance to > participate. One point I can't resist to mention: The discussion "multiprotocol over circuit switched ISDN" was started too late. Here, in non-US countries, we now have a variety of methods for IP and other protocols over the ISDN. I hope that finally ppp will be widely accepted (just to have ONE standard, but it will now take some time to established and accepted method). ppp may not be the most efficient method, but anyhow. Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11) > > George Clapp > voice: 708-248-6507 > fax: 708-248-3996 > email: clapp@ameris.center.il.ameritech.com > ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717; 26 Aug 93 3:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681; 26 Aug 93 3:14 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472; 26 Aug 93 3:13 EDT Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 00:14:37 -0700 Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA29699; Thu, 26 Aug 1993 09:14:30 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA08874; Wed, 25 Aug 93 09:14:26 +0200 Sender:ietf-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9308250714.AA08874@keks.netcs.com> Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Date: Wed, 25 Aug 93 9:14:24 MEST Cc: iplpdn@CNRI.Reston.VA.US, atm@sun.com, ietf-ppp@ucdavis.edu, rolc@nsco.network.com, ietf@isi.edu In-Reply-To: ; from "George H. Clapp" at Aug 23, 93 8:52 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10683; 26 Aug 93 15:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10679; 26 Aug 93 15:47 EDT Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa20622; 26 Aug 93 15:47 EDT Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA20170; Thu, 26 Aug 93 12:07:30 PDT X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from cpmx.saic.com by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA19674; Thu, 26 Aug 93 11:54:32 PDT Message-Id: <9308261854.AA19674@ucdavis.ucdavis.edu> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700 Date: 26 Aug 1993 11:39:16 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CPSMTP01 Admin Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Cc: atm@sun.com, ietf-ppp@ucdavis.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, rolc@nsco.network.com Mail*Link(r) SMTP RE>dissolution of IPLPDN > > This recent criticism is unfortunate, and I'm sorry that we are ending on > a bit of a sour note. But I'm confident that the work done by IPLPDN will > continue to have value and that these comments will be recognized as > misplaced. IPLPDN was a great group that stayed focused on solving technical > problems. It was terrific fun, and I'm glad to have had the chance to > participate. One point I can't resist to mention: The discussion "multiprotocol over circuit switched ISDN" was started too late. Here, in non-US countries, we now have a variety of methods for IP and other protocols over the ISDN. I hope that finally ppp will be widely accepted (just to have ONE standard, but it will now take some time to established and accepted method). ppp may not be the most efficient method, but anyhow. Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11) > > George Clapp > voice: 708-248-6507 > fax: 708-248-3996 > email: clapp@ameris.center.il.ameritech.com > ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717; 26 Aug 93 3:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681; 26 Aug 93 3:14 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472; 26 Aug 93 3:13 EDT Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 00:14:37 -0700 Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA29699; Thu, 26 Aug 1993 09:14:30 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA08874; Wed, 25 Aug 93 09:14:26 +0200 Sender:ietf-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9308250714.AA08874@keks.netcs.com> Subject: Re: dissolution of IPLPDN To: "George H. Clapp" Date: Wed, 25 Aug 93 9:14:24 MEST Cc: iplpdn@CNRI.Reston.VA.US, atm@sun.com, ietf-ppp@ucdavis.edu, rolc@nsco.network.com, ietf@isi.edu In-Reply-To: ; from "George H. Clapp" at Aug 23, 93 8:52 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29