Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22046; 3 Dec 94 3:33 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22042; 3 Dec 94 3:33 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28687; 3 Dec 94 3:33 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA159968631; Fri, 2 Dec 1994 23:10:31 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA159658627; Fri, 2 Dec 1994 23:10:27 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA07595; Fri, 2 Dec 94 17:35:19 EST Received: from rgc ([199.118.103.103]) by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA01228; Fri, 2 Dec 94 17:36:59 EST Message-Id: Date: Fri, 2 Dec 94 18:34:37 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: framework doc Reply-To: Robert.G.Cole@att.com To: IP over ATM X-Mailer: VersaTerm Link v1.1.3 A couple of comments regarding the framework document. 1) Mark has placed the latest copy on his ftp server (please see attached note below). Once we have completed the changes discussed next, we will send him an update. 2) Based upon the comments we received over the last couple of weeks from many folks (and in particular Curtis V, Grenville A, Joel H and Andy M.) we are restructuring sections 4 and 5 of the document. Specifically, we are replacing ISO terminology with more traditional IP terminology, we are restructuring sections 4 and 5 of the document somewhat to describe svc, pvc, and lightweight subnet models, (considering them as different methods of encapsulation), and discussing four end-to-end models, namely, the classical IP, the Ohta model, the SVC-WATM/ROLC model, and the peer model. We updated the references (still keeping I-Drafts, ATM-Forum pointers). Will get to that issue once the more fundamental comments are addressed. Any thoughts? 3) We will try to get the revised draft onto Mark's ftp server prior to the meeting and will bring some paper copies for anyone interested as well. Thanks, Bob and Dave ************** Date: Fri, 18 Nov 1994 10:10:42 -0800 (PST) From: Mark Laubach To: ip-atm@matmos.hpl.hp.com Subject: FTP location for framework-01.ps The "IP over ATM: A Framework Document" Version 01 11/17/94, by R.G. Cole and D. Shur is now available via ftp as: file://ftp.com21.com/pub/ip-atm/framework-01.ps Mosaic users can also get to this via: http://www.com21.com/pages/ietf.html This file is more network friendly as it only occupies 107K of space and not the 1.1M as previously mailed. Some of you may not have received the prior mailing. Mark Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02381; 3 Dec 94 13:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02377; 3 Dec 94 13:55 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07926; 3 Dec 94 13:55 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA192035838; Sat, 3 Dec 1994 09:30:38 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA191725833; Sat, 3 Dec 1994 09:30:33 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id JAA13252; Sat, 3 Dec 1994 09:14:25 -0800 Date: Sat, 3 Dec 1994 09:14:25 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: ip-atm@matmos.hpl.hp.com Subject: new framework postscript available Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The newest framework document is available via ftp anonymous: ftp.com21.com:~ftp/pub/ip-atm/framework-02.ps Please note that com21.com will be off the internet for approximately one hour between 1PM and 3PM Pacific time today. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02391; 3 Dec 94 13:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02387; 3 Dec 94 13:55 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07933; 3 Dec 94 13:55 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA191655814; Sat, 3 Dec 1994 09:30:14 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA191345809; Sat, 3 Dec 1994 09:30:09 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA01729; Sat, 3 Dec 1994 12:09:55 -0500 Message-Id: <199412031709.MAA01729@curtis.ansremote.com> To: Robert.G.Cole@att.com Cc: IP over ATM Reply-To: curtis@ans.net Subject: Re: framework doc In-Reply-To: Your message of "Fri, 02 Dec 1994 18:34:37 GMT." Date: Sat, 03 Dec 1994 12:08:55 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , "Robert G. Cole" writes: > > 2) Based upon the comments we received over the last couple of > weeks from many folks (and in particular Curtis V, Grenville A, Joel H > and Andy M.) we are restructuring sections 4 and 5 of the document. > Specifically, we are replacing ISO terminology > with more traditional IP terminology, we are restructuring > sections 4 and 5 of the document somewhat to describe svc, pvc, and > lightweight subnet models, (considering them as > different methods of encapsulation), and > discussing four end-to-end models, namely, the classical IP, > the Ohta model, the SVC-WATM/ROLC model, and the peer model. We updated the > references (still keeping I-Drafts, ATM-Forum pointers). Will get > to that issue once the more fundamental comments are addressed. Any thoughts > ? > Bob, Thank you for updating the document. It may take time to get sections 4 and 5 worked out. I think we need to build a rational taxonomy rather than just enumerating the proposals on the table. IMO making the distinction between ATM internetworks and ATM subnets is an important one and needs emphasis. Also, we should not be trying to propose routing protocols themselves, but need to be careful to be proposing architectures for which routing algorithms are scalable to the target sizes (ie: there are problems with subnet monoliths and we should point this out, but not try to solve it). We also need to pay much more attention to the need to support routing information and to reflect differing routing policy and propogate information needed down stream to make routing policy decisions. We should also point out limitations to "solutions" such as NHRP which do not support this and explicitly do not support multihomed routers (we don't want to be representing something as a general solution if it is explicitly limited to certain topologies). To the extent that we can, IMO we should try to make IP over ATM integrate well with the existing Internet technologies, so we have less of an IP vs ATM situation and more of a IP over everything now with a smooth migration to IP over ATM (as long as or as soon as IP over ATM works well). If we are going to put "private memorandum" in the bibliography, then perhaps we should make the memorandum easily available (like put it on the Web server). This document would be much better of in HTML than FRAME and postscript, since it references so many other documents which are critical to really understanding this work and since this work is an attempt to tie together much of the work of this WG. If you dump frame to ascii, I'll volunteer to do the initial ascii to HTML conversion (without otherwise changing the document). You can still go HTML source to formatted ascii or postscript, so HTML would be a better source format. (btw- any well done RFCs in HTML I can borrow from if I do get this job?). Curtis ps- Sorry for making comments so late in the process. I look forward to seeing the new version and hope to be able to turn around comments in a more timely manner.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13355; 6 Dec 94 23:24 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13351; 6 Dec 94 23:24 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20533; 6 Dec 94 23:24 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA085297715; Tue, 6 Dec 1994 18:35:15 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sicmail.epfl.ch by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA084987711; Tue, 6 Dec 1994 18:35:11 -0800 Received: from disunms.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <01077-0@sicmail.epfl.ch>; Wed, 7 Dec 1994 03:33:59 +0100 Received: from disuns2.epfl.ch by di.epfl.ch (5.0/Epfl-4.9-s/MX) id AA18823; Wed, 7 Dec 1994 03:33:55 +0100 Date: Wed, 7 Dec 1994 03:33:55 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Werner Almesberger Message-Id: <9412070233.AA18823@di.epfl.ch> To: ip-atm@matmos.hpl.hp.com Subject: small bugs in draft-ietf-ipatm-sig-02 Content-Length: 1232 As promised, here's my list of small bugs and things I didn't like or understand in draft-ietf-ipatm-sig-02: 3.1, "MUST monitor [...] lowest [...] layer" Why ? As long as it just _knows_ what's going on (e.g. by monitoring all upper layers), we shouldn't care about how it is implemented. Inconsistency in 3rd paragraph of 3.3: I see some conflict between the MUST and the SHOULD NOT. Shouldn't the SHOULD NOT rather be a MUST NOT, at least as far as ignoring PDUs is concerned ? Unclear wording in Best Effort requesting 7.2: The "MAY" could be related to the mechanism of requesting BE or to the decision to request BE. RELEASE COMPLETE vs. RELEASE after CALL PROCEEDING: After CALL PROCEEDING, calls are clared with a RELEASE instead of a RELEASE COMPLETE. Appendix A.2 gets this right, but there are many incorrect spots in sections 4 and 7. Also, RELEASE [COMPLETE] crossing doesn't appear anywhere. Protocol deadlock in section 3.1: If the calling endstation decides to wait for the reply, but the endstation decides not to respond (draft says "MAY" in both cases), they'll wait forever. Maybe a timeout or a "MUST" could resolve this. That's all for now. I hope it's useful. - Werner   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18375; 7 Dec 94 1:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18371; 7 Dec 94 1:49 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22539; 7 Dec 94 1:49 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA092570151; Tue, 6 Dec 1994 22:02:31 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA092260142; Tue, 6 Dec 1994 22:02:22 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id BAA13301 for ; Wed, 7 Dec 1994 01:02:17 -0500 Message-Id: <199412070602.BAA13301@thumper.bellcore.com> To: ip-atm@matmos.hpl.hp.com Subject: slides from San Jose Date: Wed, 07 Dec 1994 01:02:14 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage I had a request for my slides to be put online, so they may now be obtained in .ps form by anonymous ftp from thumper.bellcore.com /pub/gja/ipatm-ipmc/IPmc.slides.SanJose.ps and /pub/gja/ipatm-ipmc/IPmcserv.slides.SanJose.ps With the inscrutability only possible with postscript viewers the ghostview/ghostscript installed on the machines at San Jose doesn't render all the bits of my diagrams, whereas the (I believe) older versions on my home machine do. You mileage may vary :-) cheers, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18614; 7 Dec 94 2:18 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa18610; 7 Dec 94 2:18 EST Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id CAA13600 for ; Wed, 7 Dec 1994 02:11:36 -0500 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id BAA15013; Wed, 7 Dec 1994 01:39:56 -0500 Message-Id: <199412070639.BAA15013@thumper.bellcore.com> To: rolc@maelstrom.acton.timeplex.com Cc: ip-atm@matmos.hpl.hp.com Subject: From ARP to NHRP.... Date: Wed, 07 Dec 1994 01:39:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage Peoples, While contemplating my hotel room roof after the monday rolc meeting I wondered about the apparent sentiment in the rolc meeting the the rfc1577 to nhrp transition would involve three periods: - Hosts use LIS ARP Server - Hosts must/can choose between ARP Server or NHRP Server. - Hosts only have NHRP Server. I wonder why we don't remodel the future evolution of rfc1577 and the nhrp draft so that evolution to nhrp does _not_ involve a period of co-resident/parallel protocols. The evolution that I see then goes something like this: - RFC1577 based solutions appear in the market, host interface code built on query/response to ARP Server. - 'NHRP capability' (overlay of interconnected NHSs) evolves. - The ARP Server's of pre-existing LISs are upgraded as desired to re-write ARP requests that they cannot resolve locally into NHRP requests which they then issue on behalf of LIS hosts. (- NHRP-only hosts begin to appear, directly utilising their 'local' NHS.) In essence the ARP Server 'front ends' for Classical hosts in the early phase of NHRP deployment across the ATM cloud. Actually, in the warm after glow of the IETF social, I even wonder if we need to make hosts 'NHRP aware' is the pure sense. Perhaps we'd get away with extending the rfc1577 ARP packet format to include some dummy fields to pass back NHRP-ish information when available. I suppose this makes NHRP a 'mechanism for ARP Servers to locate a cut-through route' rather than a 'mechanism for hosts to locate a cut-through route'. Feel free to compose elegant objections that I will no doubt understand fully after a good nights sleep :-) cheers, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11069; 7 Dec 94 15:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11065; 7 Dec 94 15:55 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13262; 7 Dec 94 15:55 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA132945677; Wed, 7 Dec 1994 10:41:17 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA132635673; Wed, 7 Dec 1994 10:41:13 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id NAA05771 for ; Wed, 7 Dec 1994 13:41:07 -0500 Message-Id: <199412071841.NAA05771@thumper.bellcore.com> To: ip-atm@matmos.hpl.hp.com Subject: clarifying mcserv draft Date: Wed, 07 Dec 1994 13:41:04 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage One question raised during my presentation yesterday regarded my use of ARP_REPLY to return a multicast server's identity rather than just an ARP_MULTI within one entry. At the time the most significant reason slipped my mind. Basically, when a group is being served by a multicast server there must be a way to suppress host response to subsequent ARP_MCJOINs or ARP_MCLEAVEs covering that group. So, when a host gets back an ARP_REPLY it can arrange locally to suspend MCJOIN/MCLEAVE processing on its outgoing VC for that group. The further issue of whether to use pt-pt or pt-mpt with one leaf under these circumstances is one we can probably (?) leave open at this stage. An implementor may choose between (a) ARP_REPLY always leads to a pt-pt unicast VC, which implies no reactions to later MCJOIN/MCLEAVEs. (b) ARP_REPLY to non-Class D addresses is pt-pt, for Class D addresses it is pt-mpt with a local tag saying 'ignore later MCJOIN/MCLEAVEs'. I'm not convinced that a mechanism is needed to return multiple mc servers for load sharing - groups with high traffic load should either get a high performance mc server, or none at all (i.e. use a vc-mesh). cheers, gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11323; 7 Dec 94 16:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11319; 7 Dec 94 16:25 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13919; 7 Dec 94 16:25 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA134518169; Wed, 7 Dec 1994 11:22:49 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightning.synoptics.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA134208166; Wed, 7 Dec 1994 11:22:46 -0800 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA29111; Wed, 7 Dec 94 11:21:42 PST Received: from milliways (milliways.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA08958; Wed, 7 Dec 94 11:21:26 PST Received: by milliways (4.1/2.0N) id AA00395; Wed, 7 Dec 94 11:17:40 PST Message-Id: <9412071917.AA00395@milliways> Date: Wed, 7 Dec 94 11:17:40 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: ip-atm@matmos.hpl.hp.com Subject: Re: clarifying mcserv draft > From atmpost@matmos.hpl.hp.com Wed Dec 7 10:58:20 1994 > To: ip-atm@matmos.hpl.hp.com > Subject: clarifying mcserv draft > Date: Wed, 07 Dec 1994 13:41:04 -0500 > From: Grenville Armitage > Content-Length: 1198 > I'm not convinced that a mechanism is needed to return multiple > mc servers for load sharing - groups with high traffic load should > either get a high performance mc server, or none at all (i.e. use > a vc-mesh). Another reason for multiple mc servers is for scaling of VCCs. With an server-based architecture, the number of VCCs that a mc server has to support is sometimes the scaling limitation, rather than the throughput load. There is also the redundancy issue - localising failures and all that. It would be good to support this if it does not add too much complexity to the host implementation. Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11340; 7 Dec 94 16:28 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa11336; 7 Dec 94 16:28 EST Received: from wawa.ans.net (wawa.ans.net [147.225.1.85]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id QAA12723 for ; Wed, 7 Dec 1994 16:05:05 -0500 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA10704; Wed, 7 Dec 1994 20:56:42 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <9412072056.AA10704@wawa.ans.net> To: Grenville Armitage Cc: rolc@maelstrom.acton.timeplex.com, ip-atm@matmos.hpl.hp.com, curtis@wawa.ans.net Subject: Re: From ARP to NHRP.... In-Reply-To: (Your message of Wed, 07 Dec 94 01:39:49 EST.) <199412070639.BAA15013@thumper.bellcore.com> Date: Wed, 07 Dec 94 20:56:42 +0000 > While contemplating my hotel room roof after the monday rolc > meeting I wondered about the apparent sentiment in the rolc meeting > the the rfc1577 to nhrp transition would involve three periods: > > - Hosts use LIS ARP Server > - Hosts must/can choose between ARP Server or NHRP Server. > - Hosts only have NHRP Server. In the middle step, hosts register with both for the benefit of rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one is querying the RFC1577 server on a LIS, it can go away. If I understood what was proposed at the meeting. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13010; 7 Dec 94 18:37 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa13006; 7 Dec 94 18:37 EST Received: from terra.com21.com (terra.com21.com [140.174.223.21]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id SAA17286 for ; Wed, 7 Dec 1994 18:35:08 -0500 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id PAA05996; Wed, 7 Dec 1994 15:17:13 -0800 Date: Wed, 7 Dec 1994 15:17:12 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Curtis Villamizar cc: Grenville Armitage , rolc@maelstrom.acton.timeplex.com, ip-atm@matmos.hpl.hp.com, curtis@wawa.ans.net Subject: Re: From ARP to NHRP.... In-Reply-To: <9412072056.AA10704@wawa.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Curtis Villamizar wrote: > > While contemplating my hotel room roof after the monday rolc > > meeting I wondered about the apparent sentiment in the rolc meeting > > the the rfc1577 to nhrp transition would involve three periods: > > > > - Hosts use LIS ARP Server > > - Hosts must/can choose between ARP Server or NHRP Server. > > - Hosts only have NHRP Server. > > In the middle step, hosts register with both for the benefit of > rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one > is querying the RFC1577 server on a LIS, it can go away. If I > understood what was proposed at the meeting. I though I heard that the middle step requires hosts to register with ATMARP, which will cross-feed oneway to the NHRP server (co-located). NHRP is then used for off-LIS queries. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13822; 7 Dec 94 19:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13818; 7 Dec 94 19:57 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17784; 7 Dec 94 19:57 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA146132880; Wed, 7 Dec 1994 15:28:00 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA145822874; Wed, 7 Dec 1994 15:27:54 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id PAA05853; Wed, 7 Dec 1994 15:00:55 -0800 Date: Wed, 7 Dec 1994 15:00:55 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: ip-atm@matmos.hpl.hp.com Subject: draft: san jose meeting minutes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a draft of the minutes, please review and get comments and corrections back to me asap. Thanks, Mark --------------------- IP over ATM Working Group Minutes IETF Meeting, December 6, 1994 San Jose, California ATM Forum Liaison Report, Drew Perkins Drew will send an email report to the mailing list for the Kyoto meeting (last week of November). Docs complete: o LANE is now complete, all minor and major questions have been answered. o IISP complete o CMIP, SNMP mibs (m4) completed o Test specifications completed LANE emulation has made UNI mapping independent (UNI 3.0 and 3.1 supported). Information bus support. A ready indicate packet is now used (added, regular LANE data cell) after connect.ACK. New work items for soft PVP's. Multiprotocol over ATM group: identified requirements and different references models for how the system ought to work. Single end system host behavior (query/response). Signaling: leaf initiated join in progress, authenticated connection work will start next meeting. ATM DXI sent to straw ballot, for channelized DS3. Circuit emulation: emulation of D1 circuits sent to straw ballot. Support of early packet drop (cell drop, frame drop) begining to get specified. Inverse T1 multiplexing. 155 Mbps over UTP3. Phy group is now allowed to specify more than one interface. Residential broadband work starting up, they are calling for contributions. Q: Multiprotocol BOF models: LANE model, combined with Classical and NHRP model. ...some discussion. Dario Ercole, Interpersonal Mutlimedia Communications over ATM Shown at Interop '94. Connect Paris with Torino. OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. They discovered that they could not run IP over ATM over a public network if they did not perform rate control. This means application level rate control and inter-switch rate control. The NNI between the switches generated "big packets". RFC1577 over wide-area? Who is going to provide/specify the recommendations for the policing function? Andy Malis: very much dependent on the type of network the traffic is being sent through. Dario agrees. Ken Howard: isn't ATM deregulated in Europe? What about multiple vendors and solutions? Dario: this topis is not network specific. Consensus is that this is more of an ATM specific issue and that IP over ATM will make use of available services. While not an issue of this working group's charter, performance of ATM does impact performance of IP over ATM. Grenville Armitage, IP Multicast Draft Rewview. Grenville gave an overview of his two Internet-drafts. Goals: work within RFC1577 context, Utilize UNI 3.1 multicast services. Non-goal: UNI 4.0, IP multicast routing. Mark: recommend that having a separate registration server, i.e. de-couple ATMARP_REQUEST from the multicast-request. Comment: please don't have the user type in two 20 byte addresses. Maybe there's a clever way to do this? Question about whether the two server can live at the same LLC entity? Mark raised point of if the ARP type coding is distinct, this is possible that it and an ATMARP server could live above 0x0806, however, old implementations must be tolerant of receiving these types without doing nasty things. RFC1577 rewrite could specific that hosts must be tolerant of receiving other type codes. Q: Do you perceive any bounds on the size of the mcleave and join messages? A: ARP_MULTI response is quite large and currently exceeds the bounds on host adapters. Q: What happens when the arp server fails? What happens to the VC's that are active on the host? A: currently not addressed. Drew suggested resyncing after a period of time. Drew: I think the document needs to augmented that failure ought to reset all state. A: yes, I need some text for this. Drew: the document has a discussion of binding to LLC entities. Perhaps it can be skipped, as it might cause more controversy and/or confusion. It is not necessary for this to be in the document. Statement: need to draw out the end system architecture from the actual implementation. It think it useful to understand how the protocol works. Comments were to move it into the framework document. Multicast Server Discussion: Suggestion was to name the service: Multicast Address Registration Server (MARS). Drew: when mcserver, why use an ARP_REPLY instead of an ARP_MULTI with a single member. [Discussion about how to set up a mcast vc.] [Further discussion about supporting multiple mc servers.] Issue of checking. Issue of reassembly resources in hosts. Framework Document Discussion, David Shur Curtis suggested issuing the document in HTML which converts easily to both postscript and text. This would allow easy review and posting as an I-D. General consensus that we need to close on this real soon, via a series of interactive discussions on the email list. Consensus that Grenville's LLC material from the multicast document should be moved to the Framework document. Work Plan presentation Mark put up the suggested FY95 work plan, as follows: 1. UNI 3.0 Signaling draft -> Informational RFC (submitted) 2. UNI 3.1 Signaling draft -> proposed (re-submitted 12/4) 3. Framework draft -> Informational RFC 4. Multicast draft(s) -> proposed (?) 5. RFC1483 proposed -> draft 6. RFC1577 proposed -> proposed (?) 7. RFC1626 proposed -> draft 8. UNI 4.0 Signaling draft. Point was raised that ITU has a contribution for the RFC1483 rewrite. Questions were raised regarding when to start the RFC1577 rewrite. Mark proposed starting this in the March/April timeframe. Drew suggested getting started sooner. A statement was made that RFC1626 should be rolled into the RFC1577 rewrite. We were not able to discuss this and clarify why they are different. # end of minutes.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13938; 7 Dec 94 20:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13934; 7 Dec 94 20:14 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18047; 7 Dec 94 20:14 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148334723; Wed, 7 Dec 1994 15:58:43 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148024719; Wed, 7 Dec 1994 15:58:39 -0800 Received: from terra.com21.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA18955; Wed, 7 Dec 1994 15:58:53 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id PAA06486; Wed, 7 Dec 1994 15:33:44 -0800 Date: Wed, 7 Dec 1994 15:33:44 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: stev-iesg@ftp.com, topolcic@bbn.com Cc: ip-atm@matmos.hpl.hp.com Subject: IP over ATM Summary, 6 October 1994, San Jose IETF Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Summary of IP over ATM Working Group Meeting 6 October 1994, San Jose IETF. The ATM Forum Liaison report was given by Drew Perkins. A presentation was made on IP over ATM performance problems at the Paris Interop by Dario Ercole. The request was made that the working group provide some form of solution/opinion to the policing issue. Consensus is that this is more of an ATM specific issue and that IP over ATM will make use of available services. While not an issue of this working group's charter, performance of ATM does impact performance of IP over ATM. Grenville Armitage presented the internet drafts draft-armitage-ipatm-ipmc-02.txt and draft-armitage-ipatm-mcserv-00.txt. Comments were generated. The WG consensus was to add these to the work plan for FY95. We will be discussing revisions on the email list. The framework draft was discussed with co-author David Shur. It will be discussed in detail on the email list. A suggestion was made to turn the document into HTML so that we can view on the web, and generate text and postscript for internet-draft submission easily. The FY95 work plan was presented. More discussion will appear on the email list about it. 122 people attended the single session meeting. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14127; 7 Dec 94 20:43 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14123; 7 Dec 94 20:43 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18447; 7 Dec 94 20:43 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA147794515; Wed, 7 Dec 1994 15:55:15 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightning.synoptics.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA147484512; Wed, 7 Dec 1994 15:55:12 -0800 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA02010; Wed, 7 Dec 94 15:54:14 PST Received: from milliways (milliways.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA13811; Wed, 7 Dec 94 15:53:56 PST Received: by milliways (4.1/2.0N) id AA00676; Wed, 7 Dec 94 15:50:10 PST Message-Id: <9412072350.AA00676@milliways> Date: Wed, 7 Dec 94 15:50:10 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: ip-atm@matmos.hpl.hp.com Subject: Corrections Re: draft: san jose meeting minutes Mark, A few corrections for the minutes ... > From atmpost@matmos.hpl.hp.com Wed Dec 7 15:39:15 1994 > Date: Wed, 7 Dec 1994 15:00:55 -0800 (PST) > From: Mark Laubach > To: ip-atm@matmos.hpl.hp.com > Subject: draft: san jose meeting minutes > Content-Length: 6087 > supported). Information bus support. A ready indicate packet ^^^^^^^^^^^ "Intelligent" > is now used (added, regular LANE data cell) after connect.ACK. ^^^^^^^^^^^^^^^^^^^^^^ "AAL5 SDU with LANE Control header fitting into a single cell" > Phy group is now allowed to specify more than one interface. ^^^^^^^^^^ "mid-speed-range PHY standard" Thanks. Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17827; 7 Dec 94 23:04 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa17823; 7 Dec 94 23:04 EST Received: from wawa.ans.net (wawa.ans.net [147.225.1.85]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id WAA22758 for ; Wed, 7 Dec 1994 22:57:27 -0500 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA13467; Thu, 8 Dec 1994 03:49:53 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <9412080349.AA13467@wawa.ans.net> To: Mark Laubach Cc: Curtis Villamizar , Grenville Armitage , rolc@maelstrom.acton.timeplex.com, ip-atm@matmos.hpl.hp.com Subject: Re: From ARP to NHRP.... In-Reply-To: (Your message of Wed, 07 Dec 94 15:17:12 PST.) Date: Thu, 08 Dec 94 03:49:53 +0000 > On Wed, 7 Dec 1994, Curtis Villamizar wrote: > > > While contemplating my hotel room roof after the monday rolc > > > meeting I wondered about the apparent sentiment in the rolc meeting > > > the the rfc1577 to nhrp transition would involve three periods: > > > > > > - Hosts use LIS ARP Server > > > - Hosts must/can choose between ARP Server or NHRP Server. > > > - Hosts only have NHRP Server. > > > > In the middle step, hosts register with both for the benefit of > > rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one > > is querying the RFC1577 server on a LIS, it can go away. If I > > understood what was proposed at the meeting. > > I though I heard that the middle step requires hosts to register with > ATMARP, which will cross-feed oneway to the NHRP server (co-located). > NHRP is then used for off-LIS queries. > > Mark That sounds perfectly resonable. Then in step 3, ATM ARP is still used for registry only and NHRP is used exclusively for queries? Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17861; 7 Dec 94 23:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17857; 7 Dec 94 23:12 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21165; 7 Dec 94 23:12 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA156886714; Wed, 7 Dec 1994 19:18:34 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sicmail.epfl.ch by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA156576711; Wed, 7 Dec 1994 19:18:31 -0800 Received: from disunms.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <22730-0@sicmail.epfl.ch>; Thu, 8 Dec 1994 04:18:10 +0100 Received: from disuns2.epfl.ch by di.epfl.ch (5.0/Epfl-4.9-s/MX) id AA29602; Thu, 8 Dec 1994 04:18:07 +0100 Date: Thu, 8 Dec 1994 04:18:07 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Werner Almesberger Message-Id: <9412080318.AA29602@di.epfl.ch> To: ip-atm@matmos.hpl.hp.com Subject: signaling draft again Content-Length: 676 Upon closer examination of what the signaling draft doesn't say, I've noticed that quite a few "unusual" responses of Q.2931 are missing, e.g. the CONNECT-STATUS case. Although the draft says that one should use the ATM Forum spec as the reference, it more or less describes Q.2931, so I think it would be a good idea to get this right, e.g. by making an appendix with a Q.2931 point-to-point user side state machine. If this is considered a useful addition and if nobody else wants to do it, I'd volunteer to write that state machine description. Sorry for not bringing this up earlier, but I only realized after the meeting that so much was missing. Opinions ? - Werner   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23505; 8 Dec 94 2:44 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa23501; 8 Dec 94 2:43 EST Received: from [134.196.226.1] (gb_remote_usr1.timeplex.com [134.196.226.1]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id CAA29502; Thu, 8 Dec 1994 02:37:30 -0500 Message-Id: <199412080737.CAA29502@maelstrom.acton.timeplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Dec 1994 23:36:19 -0800 To: Curtis Villamizar , Mark Laubach Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: From ARP to NHRP.... Cc: Curtis Villamizar , Grenville Armitage , rolc@maelstrom.timeplex.com, ip-atm@matmos.hpl.hp.com, malis@maelstrom.acton.timeplex.com >> > > While contemplating my hotel room roof after the monday rolc >> > > meeting I wondered about the apparent sentiment in the rolc meeting >> > > the the rfc1577 to nhrp transition would involve three periods: >> > > - Hosts use LIS ARP Server >> > > - Hosts must/can choose between ARP Server or NHRP Server. >> > > - Hosts only have NHRP Server. >> > In the middle step, hosts register with both for the benefit of >> > rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one >> > is querying the RFC1577 server on a LIS, it can go away. If I >> > understood what was proposed at the meeting. >> I though I heard that the middle step requires hosts to register with >> ATMARP, which will cross-feed oneway to the NHRP server (co-located). >> NHRP is then used for off-LIS queries. >That sounds perfectly resonable. Then in step 3, ATM ARP is still >used for registry only and NHRP is used exclusively for queries? Attempting to clear up the confusion ... here is how the transition will work: Step 1: Only ARP servers are used as per RFC 1577. Step 2: NHRP is phased in: 2a. Hosts continue to register with the ARP server (until ARP servers go away, for the benefit of non-NHRP hosts). ARP servers will leak registrations to NHRP servers, so NHRP hosts don't have to register twice if they don't wish to (but then they must agree to certain defaults, such as the registration timeout period). If NHRP hosts wish to set these values, then they must also register with the NHRP server. Explicit registrations always take precedence over leaked registrations. 2b. NHRP source hosts send all address resolution requests to the NHRP server (without regard to the "mask and match" operation). 2c. NHRP source hosts may send ARP requests to their ARP server if they get a NHRP NAK and the destination is in the same LIS. Step 3: NHRP servers completely replace ARP servers. All hosts are NHRP-capable. ARP servers no longer exist. Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03213; 8 Dec 94 12:55 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa03208; 8 Dec 94 12:55 EST Received: from tigger.jvnc.net (tigger.jvnc.net [128.121.50.145]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id MAA18568; Thu, 8 Dec 1994 12:52:03 -0500 Received: from ietf-temp-224.ietf.toaster.net. (ietf-temp-224.ietf.toaster.net) by tigger.jvnc.net with SMTP id AB20107 (5.65c/IDA-1.4.4 for rolc@maelstrom.timeplex.com); Thu, 8 Dec 1994 12:50:35 -0500 Message-Id: Date: Thu, 8 Dec 94 09:48:44 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" Subject: Re: From ARP to NHRP.... Reply-To: dave@corecom.com To: Andy Malis , Curtis Villamizar , Mark Laubach Cc: Grenville Armitage , rolc@maelstrom.timeplex.com, ip-atm@matmos.hpl.hp.com, malis@maelstrom.acton.timeplex.com X-Mailer: VersaTerm Link v1.1.1 Andy's summary reflects my understanding as well. The only thing I'd add is that I believe we agreed that NHRP servers would never leak mappings to an ARP server. >Attempting to clear up the confusion ... here is how the transition will >work: > >Step 1: Only ARP servers are used as per RFC 1577. > >Step 2: NHRP is phased in: > 2a. Hosts continue to register with the ARP server (until > ARP servers go away, for the benefit of non-NHRP hosts). > ARP servers will leak registrations to NHRP servers, so NHRP > hosts don't have to register twice if they don't wish to > (but then they must agree to certain defaults, such as the > registration timeout period). If NHRP hosts wish to set > these values, then they must also register with the NHRP > server. Explicit registrations always take precedence over > leaked registrations. > 2b. NHRP source hosts send all address resolution requests > to the NHRP server (without regard to the "mask and match" > operation). > 2c. NHRP source hosts may send ARP requests to their ARP > server if they get a NHRP NAK and the destination is in the > same LIS. > >Step 3: NHRP servers completely replace ARP servers. All hosts > are NHRP-capable. ARP servers no longer exist. > >Andy > >__________________________________________________________________________ >Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 >Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 > > > David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA 1.215.830.0692 dave@corecom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07360; 8 Dec 94 21:14 EST Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa07353; 8 Dec 94 21:14 EST Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa18567; 8 Dec 94 21:14 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA217883275; Thu, 8 Dec 1994 16:34:35 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA217573272; Thu, 8 Dec 1994 16:34:32 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id QAA16217; Thu, 8 Dec 1994 16:17:44 -0800 Date: Thu, 8 Dec 1994 16:17:43 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Werner Almesberger Cc: ip-atm@matmos.hpl.hp.com Subject: Re: signaling draft again In-Reply-To: <9412080318.AA29602@di.epfl.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Although the draft says that one should use the ATM Forum spec as the > reference, it more or less describes Q.2931, so I think it would be a > good idea to get this right, e.g. by making an appendix with a Q.2931 > point-to-point user side state machine. If this is considered a useful > addition and if nobody else wants to do it, I'd volunteer to write > that state machine description. > > Opinions ? Werner, It was a decision of the WG to focus on the ATM Forum's UNI 3.1 signaling for our standardization efforts for this document. Regards, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15450; 9 Dec 94 2:11 EST Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa15446; 9 Dec 94 2:11 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22789; 9 Dec 94 2:11 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA230803200; Thu, 8 Dec 1994 22:06:40 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA230493195; Thu, 8 Dec 1994 22:06:35 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id BAA01030; Fri, 9 Dec 1994 01:03:19 -0500 Message-Id: <199412090603.BAA01030@curtis.ansremote.com> To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com Reply-To: curtis@ans.net Subject: Re: draft: san jose meeting minutes In-Reply-To: Your message of "Wed, 07 Dec 1994 15:00:55 PST." Date: Fri, 09 Dec 1994 01:02:24 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar wrt the minutes. In message , Mark Laub ach writes: > > Framework Document Discussion, David Shur > > Curtis suggested issuing the document in HTML which converts > easily to both postscript and text. This would allow easy review > and posting as an I-D. I also volunteered to do the conversion if I can get the text of the document in ascii. After the meeting David and I spoke, but I think the decision of whether to take me up on it hinges on what Bob wants to do. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04565; 9 Dec 94 14:51 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04561; 9 Dec 94 14:51 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22583; 9 Dec 94 14:51 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA274197571; Fri, 9 Dec 1994 10:26:11 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sicmail.epfl.ch by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA273887565; Fri, 9 Dec 1994 10:26:05 -0800 Received: from disunms.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <03797-0@sicmail.epfl.ch>; Fri, 9 Dec 1994 19:25:46 +0100 Received: from disuns2.epfl.ch by di.epfl.ch (5.0/Epfl-4.9-s/MX) id AA29628; Fri, 9 Dec 1994 19:25:42 +0100 Date: Fri, 9 Dec 1994 19:25:42 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Werner Almesberger Message-Id: <9412091825.AA29628@di.epfl.ch> To: ip-atm@matmos.hpl.hp.com Subject: "preferred" socket API ? Content-Length: 601 Sorry for posting this slightly inappropriate question to the list, but I think here's the place where people with answers are most likely to be be hanging out ... My group's in the process of adding ATM capabilities to Linux. Now we need a socket API for this (extensions for "native" ATM as well as RFC1577). I'd prefer to have a more or less "standard" API (if it's not too ugly) instead of inventing our own. Could anybody please point me to relevant material if there's any ? Please respond by mail so that not more bandwidth is wasted on ip-atm. I'll also answer "me too"s. Thanks ! - Werner   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05016; 9 Dec 94 15:45 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05012; 9 Dec 94 15:45 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26407; 9 Dec 94 15:45 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA275689643; Fri, 9 Dec 1994 11:00:43 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA275379639; Fri, 9 Dec 1994 11:00:39 -0800 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA19490; Fri, 9 Dec 1994 11:00:35 -0800 Received: from mail2.netcom.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA13558; Fri, 9 Dec 1994 11:00:53 -0800 Received: from mail.hill.com by mail2.netcom.com (8.6.9/Netcom) id KAA02347; Fri, 9 Dec 1994 10:56:19 -0800 Received: from cc:Mail by mail.hill.com id AA787007301; Fri, 09 Dec 94 13:06:29 EST Date: Fri, 09 Dec 94 13:06:29 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: kumquat Encoding: 64 Text Message-Id: <9411097870.AA787007301@mail.hill.com> To: comp.dcom.cell-relay@indiana.edu, comp.dcom.frame-relay@indiana.edu, bmwg@harvard.edu, wireless@tandem.com, fiber-channel-ext@think.com, frftc@acc.com, giga-owner@tele.pitt.edu, hippi@think.com, ip-atm@hplms2.hpl.hp.com, kludge@mordred.gatech.edu, smdstc@thumper.bellcore.com, smds-users@nas.nasa.gov, snmp-wg@ns.psi.net, socks@unify.com, comp-dcom-lans@cs.utexas.edu, fddi-synch@merit.edu Cc: kumquat@hill.com, jrbumblis@mmm.com Subject: Call for Papers: 20th Local Computer Network Conference ********** CALL FOR PAPERS ********** 20th Annual Conference on Local Computer Networks "The Conference on Practical Leading Edge Computer Networking" October 15-18, 1995, Minneapolis, Minnesota, USA =============================================================== Sponsored by: IEEE Computer Society TC-Computer Communications =============================================================== Theme: The emphasis on this year's conference is on practical experience using computer networks in both the local area and in the global area. This unique approach simulates a workshop environment and allows for an effective interchange among users, researchers, and vendors. Some of the primary goals of the conference are to enable those involved in the local computer network field to share experiences, lessons learned, and prototype data and analysis. Because of these objectives, papers based on experience are especially solicited. The focus of the 20th LCN will be Practical Experience Using and Deploying Local Computer Networks. Papers that cover these areas are explicitly sought and will be given preference. Information for Authors: All authors must submit 5 full copies of the full technical paper by mail or delivery service. DO NOT SUBMIT COMPLETE PAPERS BY FAX. The first page must contain: title of the paper, author's names including affiliations, complete mailing address, telephone and FAX numbers, Internet or Bitnet address, and a 250 word (maximum) abstract (double-spaced) in English to Joe Bumblis, Program Chair, at the address below. Sessions are being organized on: o Internetworking/Routers/Bridges o High Performance Protocols o Multimedia o Metropolitan Area Networks o Distributed Applications o LAN/MAN/WAN Integration o Wide Area Networks o Standards o ATM o Network Management o Fibre Channel Networking o Remote Monitoring o High Speed Networks o Wireless Networks o Error Control Techniques o Emerging Technologies o Congestion Control o Realtime Networks o FDDI and FDDI-II o AI Networks Send papers to: Joe Bumblis, Program Chair Important Dates: 3M 3M Center, Building 224-4N-27 Submission: March 21, 1995 St. Paul, MN 55144-1000 Acceptance: June 27, 1995 Camera Copy: August 1, 1995 +1 612-737-4763 (office) Conference Summary +1 612-736-7689 (fax) - Tutorials - Technical Paper Sessions jrbumblis@mmm.com - Panel Discussions   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03571; 10 Dec 94 18:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03567; 10 Dec 94 18:57 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11440; 10 Dec 94 18:57 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA047049611; Sat, 10 Dec 1994 14:46:51 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from fore.com (relay.fore.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA046739606; Sat, 10 Dec 1994 14:46:46 -0800 Received: from dolphin (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id RAA27613; Sat, 10 Dec 1994 17:46:05 -0500 Received: from loach.fore.com by dolphin (4.1/SMI-4.1) id AA20841; Sat, 10 Dec 94 17:46:39 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Received: by loach.fore.com (4.1/SMI-4.1) id AA26052; Sat, 10 Dec 94 17:44:21 EST Date: Sat, 10 Dec 94 17:44:21 EST Message-Id: <9412102244.AA26052@loach.fore.com> To: ip-atm@matmos.hpl.hp.com, almesber@di.epfl.ch Subject: Re: "preferred" socket API ? Werner, I'm afraid that there is as yet no standard API. The ATM Forum and other groups such as Winsock are working on one(s), but these are not available yet. Drew > From atmpost@matmos.hpl.hp.com Fri Dec 9 13:51:28 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > Date: Fri, 9 Dec 1994 19:25:42 +0100 > From: almesber@di.epfl.ch (Werner Almesberger) > To: ip-atm@matmos.hpl.hp.com > Subject: "preferred" socket API ? > > Sorry for posting this slightly inappropriate question to the list, > but I think here's the place where people with answers are most likely > to be be hanging out ... > > My group's in the process of adding ATM capabilities to Linux. Now we > need a socket API for this (extensions for "native" ATM as well as > RFC1577). I'd prefer to have a more or less "standard" API (if it's > not too ugly) instead of inventing our own. Could anybody please > point me to relevant material if there's any ? > > Please respond by mail so that not more bandwidth is wasted on > ip-atm. I'll also answer "me too"s. Thanks ! > > - Werner >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00291; 11 Dec 94 3:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00287; 11 Dec 94 3:50 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00776; 11 Dec 94 3:50 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA064542190; Sat, 10 Dec 1994 23:49:50 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from stone.ucs.indiana.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA064232185; Sat, 10 Dec 1994 23:49:45 -0800 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA05104; Sun, 11 Dec 94 02:49:40 EST Date: Sun, 11 Dec 1994 02:49:39 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Cell-Relay Gopher Janitor Reply-To: Cell-Relay Gopher Janitor Subject: Re: framework doc To: Curtis Villamizar Cc: ip-atm@matmos.hpl.hp.com In-Reply-To: <199412031709.MAA01729@curtis.ansremote.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII >be a better source format. (btw- any well done RFCs in HTML I can >borrow from if I do get this job?). Curtis, I did 1483. I'll leave it up to you to decide if its well done. http://cell-relay.indiana.edu/cell-relay/docs/rfc/1483/1483.TOC.html regards, --------------------------------------------------------------------------- Allen Robel | 812-855-0962 worx | http://cell-relay/allen/home.html robelr@indiana.edu | 812-855-8299 fax | "a page with no excuse..." ---------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02406; 11 Dec 94 13:55 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02402; 11 Dec 94 13:55 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07538; 11 Dec 94 13:55 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA097407973; Sun, 11 Dec 1994 09:46:13 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from stone.ucs.indiana.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA097097970; Sun, 11 Dec 1994 09:46:10 -0800 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA07289; Sun, 11 Dec 94 12:46:06 EST Date: Sun, 11 Dec 1994 12:46:05 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Cell-Relay Gopher Janitor Subject: Re: draft: san jose meeting minutes To: Curtis Villamizar Cc: Mark Laubach , ip-atm@matmos.hpl.hp.com In-Reply-To: <199412090603.BAA01030@curtis.ansremote.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Dec 1994, Curtis Villamizar wrote: > I also volunteered to do the conversion if I can get the text of the > document in ascii. After the meeting David and I spoke, but I think > the decision of whether to take me up on it hinges on what Bob wants > to do. One other thing. If you've got framemaker (fmbatch) there's a converter out there that'll save you some work. Just do an archie on fm2html... allen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02664; 11 Dec 94 14:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02660; 11 Dec 94 14:42 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08107; 11 Dec 94 14:42 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA101832113; Sun, 11 Dec 1994 10:55:13 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA101522108; Sun, 11 Dec 1994 10:55:08 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id NAA00793; Sun, 11 Dec 1994 13:50:57 -0500 Message-Id: <199412111850.NAA00793@curtis.ansremote.com> To: Cell-Relay Gopher Janitor Cc: Curtis Villamizar , ip-atm@matmos.hpl.hp.com Reply-To: curtis@ans.net Subject: Re: framework doc In-Reply-To: Your message of "Sun, 11 Dec 1994 02:49:39 EST." Date: Sun, 11 Dec 1994 13:50:50 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , Cell-Rel ay Gopher Janitor writes: > >be a better source format. (btw- any well done RFCs in HTML I can > >borrow from if I do get this job?). > > Curtis, > > I did 1483. I'll leave it up to you to decide if its well done. > > http://cell-relay.indiana.edu/cell-relay/docs/rfc/1483/1483.TOC.html > > regards, > > --------------------------------------------------------------------------- > Allen Robel | 812-855-0962 worx | http://cell-relay/allen/home.html > robelr@indiana.edu | 812-855-8299 fax | "a page with no excuse..." > --------------------------------------------------------------------------- Thanks. It is well done, but there is one thing I would do differently. Rather than putting each section in a separate file, I'd use the and and put the whole thing except table of contents in one file. This makes it easier to read sequentially and much easier to print (you don't get page breaks between sections) or convert to ascii or postscript for submission to the RFC editor. What I meant was HTML that could be used as the source format of the document. It's just a matter of getting the RFC boilerplate in HTML. The right justified block is the tricky thing (or maybe not, I'm just not sure how to do it short of using 
 and
). Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00810; 12 Dec 94 5:44 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa00806; 12 Dec 94 5:44 EST Received: from techst02.technion.ac.il (s2214961@techst02.technion.ac.il [132.68.7.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id FAA14531; Mon, 12 Dec 1994 05:36:18 -0500 Received: (from s2214961@localhost) by techst02.technion.ac.il (8.6.9/8.6.6) id MAA19676; Mon, 12 Dec 1994 12:34:08 +0200 Date: Mon, 12 Dec 1994 12:34:02 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eli Harel To: Andy Malis cc: Curtis Villamizar , Mark Laubach , Grenville Armitage , rolc@maelstrom.timeplex.com, ip-atm@matmos.hpl.hp.com, malis@maelstrom.acton.timeplex.com Subject: take my name out of your list. thanks In-Reply-To: <199412080737.CAA29502@maelstrom.acton.timeplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Andy Malis wrote: > >> > > While contemplating my hotel room roof after the monday rolc > >> > > meeting I wondered about the apparent sentiment in the rolc meeting > >> > > the the rfc1577 to nhrp transition would involve three periods: > >> > > - Hosts use LIS ARP Server > >> > > - Hosts must/can choose between ARP Server or NHRP Server. > >> > > - Hosts only have NHRP Server. > >> > In the middle step, hosts register with both for the benefit of > >> > rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one > >> > is querying the RFC1577 server on a LIS, it can go away. If I > >> > understood what was proposed at the meeting. > >> I though I heard that the middle step requires hosts to register with > >> ATMARP, which will cross-feed oneway to the NHRP server (co-located). > >> NHRP is then used for off-LIS queries. > >That sounds perfectly resonable. Then in step 3, ATM ARP is still > >used for registry only and NHRP is used exclusively for queries? > > Attempting to clear up the confusion ... here is how the transition will > work: > > Step 1: Only ARP servers are used as per RFC 1577. > > Step 2: NHRP is phased in: > 2a. Hosts continue to register with the ARP server (until > ARP servers go away, for the benefit of non-NHRP hosts). > ARP servers will leak registrations to NHRP servers, so NHRP > hosts don't have to register twice if they don't wish to > (but then they must agree to certain defaults, such as the > registration timeout period). If NHRP hosts wish to set > these values, then they must also register with the NHRP > server. Explicit registrations always take precedence over > leaked registrations. > 2b. NHRP source hosts send all address resolution requests > to the NHRP server (without regard to the "mask and match" > operation). > 2c. NHRP source hosts may send ARP requests to their ARP > server if they get a NHRP NAK and the destination is in the > same LIS. > > Step 3: NHRP servers completely replace ARP servers. All hosts > are NHRP-capable. ARP servers no longer exist. > > Andy > > __________________________________________________________________________ > Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 > Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01045; 12 Dec 94 6:21 EST Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa01041; 12 Dec 94 6:21 EST Received: from techst02.technion.ac.il (root@techst02.technion.ac.il [132.68.7.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id GAA15267 for ; Mon, 12 Dec 1994 06:21:04 -0500 Received: (from s2214961@localhost) by techst02.technion.ac.il (8.6.9/8.6.6) id MAA19546; Mon, 12 Dec 1994 12:32:40 +0200 Date: Mon, 12 Dec 1994 12:32:34 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eli Harel To: Curtis Villamizar cc: Grenville Armitage , rolc@maelstrom.acton.timeplex.com, ip-atm@matmos.hpl.hp.com, curtis@wawa.ans.net Subject: take my name out of your list. thanks. In-Reply-To: <9412072056.AA10704@wawa.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Curtis Villamizar wrote: > > > While contemplating my hotel room roof after the monday rolc > > meeting I wondered about the apparent sentiment in the rolc meeting > > the the rfc1577 to nhrp transition would involve three periods: > > > > - Hosts use LIS ARP Server > > - Hosts must/can choose between ARP Server or NHRP Server. > > - Hosts only have NHRP Server. > > In the middle step, hosts register with both for the benefit of > rfc1577 only hosts on the LIS, but *should* query NHRP. Once no one > is querying the RFC1577 server on a LIS, it can go away. If I > understood what was proposed at the meeting. > > Curtis >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01121; 12 Dec 94 6:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01117; 12 Dec 94 6:37 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02824; 12 Dec 94 6:37 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149848640; Mon, 12 Dec 1994 02:37:20 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149538637; Mon, 12 Dec 1994 02:37:17 -0800 Received: from techst02.technion.ac.il by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA05364; Mon, 12 Dec 1994 02:37:36 -0800 Received: (from s2214961@localhost) by techst02.technion.ac.il (8.6.9/8.6.6) id MAA19492; Mon, 12 Dec 1994 12:32:08 +0200 Date: Mon, 12 Dec 1994 12:32:02 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eli Harel To: Andrew Smith Cc: ip-atm@matmos.hpl.hp.com Subject: take my name out of your list. thanks. In-Reply-To: <9412071917.AA00395@milliways> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Andrew Smith wrote: > > > From atmpost@matmos.hpl.hp.com Wed Dec 7 10:58:20 1994 > > To: ip-atm@matmos.hpl.hp.com > > Subject: clarifying mcserv draft > > Date: Wed, 07 Dec 1994 13:41:04 -0500 > > From: Grenville Armitage > > Content-Length: 1198 > > > I'm not convinced that a mechanism is needed to return multiple > > mc servers for load sharing - groups with high traffic load should > > either get a high performance mc server, or none at all (i.e. use > > a vc-mesh). > > Another reason for multiple mc servers is for scaling of VCCs. With an > server-based architecture, the number of VCCs that a mc server has to > support is sometimes the scaling limitation, rather than the throughput > load. There is also the redundancy issue - localising failures and all > that. > > It would be good to support this if it does not add too much > complexity to the host implementation. > > > > Andrew > > > > ******************************************************************************** > Andrew Smith TEL: +1 408 764 1574 > Technology Synergy Unit FAX: +1 408 988 5525 > Bay Networks, Inc. E-m: asmith@baynetworks.com > Santa Clara, CA > ******************************************************************************** >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01204; 12 Dec 94 6:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01199; 12 Dec 94 6:48 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02950; 12 Dec 94 6:48 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148658502; Mon, 12 Dec 1994 02:35:02 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148338498; Mon, 12 Dec 1994 02:34:58 -0800 Received: from techst02.technion.ac.il by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA05324; Mon, 12 Dec 1994 02:35:16 -0800 Received: (from s2214961@localhost) by techst02.technion.ac.il (8.6.9/8.6.6) id MAA19412; Mon, 12 Dec 1994 12:30:39 +0200 Date: Mon, 12 Dec 1994 12:30:33 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eli Harel To: Werner Almesberger Cc: ip-atm@matmos.hpl.hp.com Subject: please take my nama out of your list. thanks. In-Reply-To: <9412070233.AA18823@di.epfl.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Werner Almesberger wrote: > As promised, here's my list of small bugs and things I didn't like > or understand in draft-ietf-ipatm-sig-02: > > 3.1, "MUST monitor [...] lowest [...] layer" > Why ? As long as it just _knows_ what's going on (e.g. by > monitoring all upper layers), we shouldn't care about how it is > implemented. > > Inconsistency in 3rd paragraph of 3.3: > I see some conflict between the MUST and the SHOULD NOT. > Shouldn't the SHOULD NOT rather be a MUST NOT, at least as > far as ignoring PDUs is concerned ? > > Unclear wording in Best Effort requesting 7.2: > The "MAY" could be related to the mechanism of requesting BE > or to the decision to request BE. > > RELEASE COMPLETE vs. RELEASE after CALL PROCEEDING: > After CALL PROCEEDING, calls are clared with a RELEASE instead > of a RELEASE COMPLETE. Appendix A.2 gets this right, but there > are many incorrect spots in sections 4 and 7. > > Also, RELEASE [COMPLETE] crossing doesn't appear anywhere. > > Protocol deadlock in section 3.1: > If the calling endstation decides to wait for the reply, but > the endstation decides not to respond (draft says "MAY" in > both cases), they'll wait forever. > > Maybe a timeout or a "MUST" could resolve this. > > That's all for now. I hope it's useful. > > - Werner >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01368; 12 Dec 94 7:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01364; 12 Dec 94 7:26 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03446; 12 Dec 94 7:26 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA150238693; Mon, 12 Dec 1994 02:38:13 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149928689; Mon, 12 Dec 1994 02:38:09 -0800 Received: from techst02.technion.ac.il by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA05372; Mon, 12 Dec 1994 02:38:26 -0800 Received: (from s2214961@localhost) by techst02.technion.ac.il (8.6.9/8.6.6) id MAA19587; Mon, 12 Dec 1994 12:33:13 +0200 Date: Mon, 12 Dec 1994 12:33:07 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eli Harel To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com Subject: take my name out of your list.thanks In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Dec 1994, Mark Laubach wrote: > > This is a draft of the minutes, please review and get comments > and corrections back to me asap. > > Thanks, > Mark > --------------------- > IP over ATM Working Group Minutes > IETF Meeting, December 6, 1994 > San Jose, California > > ATM Forum Liaison Report, Drew Perkins > > Drew will send an email report to the mailing list for the Kyoto > meeting (last week of November). > > Docs complete: > o LANE is now complete, all minor and major questions have been answered. > o IISP complete > o CMIP, SNMP mibs (m4) completed > o Test specifications completed > > LANE emulation has made UNI mapping independent (UNI 3.0 and 3.1 > supported). Information bus support. A ready indicate packet > is now used (added, regular LANE data cell) after connect.ACK. > New work items for soft PVP's. > > Multiprotocol over ATM group: identified requirements and different > references models for how the system ought to work. Single end > system host behavior (query/response). > > Signaling: leaf initiated join in progress, authenticated connection > work will start next meeting. ATM DXI sent to straw ballot, for > channelized DS3. > > Circuit emulation: emulation of D1 circuits sent to straw ballot. > Support of early packet drop (cell drop, frame drop) begining to > get specified. > > Inverse T1 multiplexing. 155 Mbps over UTP3. > > Phy group is now allowed to specify more than one interface. > > Residential broadband work starting up, they are calling for > contributions. > > Q: Multiprotocol BOF models: LANE model, combined with > Classical and NHRP model. ...some discussion. > > Dario Ercole, Interpersonal Mutlimedia Communications over ATM > > Shown at Interop '94. Connect Paris with Torino. > OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. > They discovered that they could not run IP over ATM over a > public network if they did not perform rate control. This means > application level rate control and inter-switch rate control. > The NNI between the switches generated "big packets". > > RFC1577 over wide-area? Who is going to provide/specify > the recommendations for the policing function? > > Andy Malis: very much dependent on the type of network the > traffic is being sent through. Dario agrees. > > Ken Howard: isn't ATM deregulated in Europe? What about > multiple vendors and solutions? Dario: this topis is not > network specific. > > Consensus is that this is more of an ATM specific issue and > that IP over ATM will make use of available services. While > not an issue of this working group's charter, performance of > ATM does impact performance of IP over ATM. > > Grenville Armitage, IP Multicast Draft Rewview. > > Grenville gave an overview of his two Internet-drafts. > > Goals: work within RFC1577 context, Utilize UNI 3.1 multicast > services. Non-goal: UNI 4.0, IP multicast routing. > > Mark: recommend that having a separate registration server, > i.e. de-couple ATMARP_REQUEST from the multicast-request. > Comment: please don't have the user type in two 20 byte > addresses. Maybe there's a clever way to do this? > Question about whether the two server can live at the > same LLC entity? Mark raised point of if the ARP type > coding is distinct, this is possible that it and an > ATMARP server could live above 0x0806, however, old implementations > must be tolerant of receiving these types without doing nasty > things. RFC1577 rewrite could specific that hosts must be tolerant > of receiving other type codes. > > Q: Do you perceive any bounds on the size of the mcleave and join > messages? A: ARP_MULTI response is quite large and currently > exceeds the bounds on host adapters. > > Q: What happens when the arp server fails? What happens to the > VC's that are active on the host? A: currently not addressed. > Drew suggested resyncing after a period of time. > > Drew: I think the document needs to augmented that failure ought > to reset all state. A: yes, I need some text for this. > > Drew: the document has a discussion of binding to LLC entities. > Perhaps it can be skipped, as it might cause more controversy > and/or confusion. It is not necessary for this to be in the > document. > > Statement: need to draw out the end system architecture from > the actual implementation. It think it useful to understand > how the protocol works. Comments were to move it into the > framework document. > > Multicast Server Discussion: > > Suggestion was to name the service: Multicast Address Registration > Server (MARS). > > Drew: when mcserver, why use an ARP_REPLY instead of an ARP_MULTI > with a single member. [Discussion about how to set up a mcast > vc.] [Further discussion about supporting multiple mc servers.] > Issue of checking. Issue of reassembly resources in hosts. > > Framework Document Discussion, David Shur > > Curtis suggested issuing the document in HTML which converts > easily to both postscript and text. This would allow easy review > and posting as an I-D. > > General consensus that we need to close on this real soon, via > a series of interactive discussions on the email list. > > Consensus that Grenville's LLC material from the multicast document > should be moved to the Framework document. > > Work Plan presentation > > Mark put up the suggested FY95 work plan, as follows: > > 1. UNI 3.0 Signaling draft -> Informational RFC (submitted) > 2. UNI 3.1 Signaling draft -> proposed (re-submitted 12/4) > 3. Framework draft -> Informational RFC > 4. Multicast draft(s) -> proposed (?) > 5. RFC1483 proposed -> draft > 6. RFC1577 proposed -> proposed (?) > 7. RFC1626 proposed -> draft > 8. UNI 4.0 Signaling draft. > > Point was raised that ITU has a contribution for the RFC1483 rewrite. > > Questions were raised regarding when to start the RFC1577 rewrite. > Mark proposed starting this in the March/April timeframe. Drew > suggested getting started sooner. > > A statement was made that RFC1626 should be rolled into the RFC1577 > rewrite. We were not able to discuss this and clarify why they are > different. > > # end of minutes. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02068; 12 Dec 94 9:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02064; 12 Dec 94 9:23 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05865; 12 Dec 94 9:23 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA160277649; Mon, 12 Dec 1994 05:07:29 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from postoffice3.mail.cornell.edu by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA159937645; Mon, 12 Dec 1994 05:07:25 -0800 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id IAA10318; Mon, 12 Dec 1994 08:07:17 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Dec 1994 08:07:24 -0500 To: curtis@ans.net Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Brim Subject: Re: framework doc Cc: Cell-Relay Gopher Janitor , Curtis Villamizar , ip-atm@matmos.hpl.hp.com At 1:50 PM 12/11/94, Curtis Villamizar wrote: >What I meant was HTML that could be used as the source format of the >document. It's just a matter of getting the RFC boilerplate in HTML. >The right justified block is the tricky thing (or maybe not, I'm just >not sure how to do it short of using 
 and
). Perhaps you could try a table with ; Tue, 13 Dec 1994 14:00:22 CDT Date: 13 Dec 1994 14:00:22 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: NSIMHA@vax2.cstp.umkc.edu Subject: Questions on ATM.... To: ip-atm@hplms2.hpl.hp.com Message-Id: <01HKLIGKKYN6FTEFGK@VAX2.CSTP.UMKC.EDU> Organization: University of Missouri - Kansas City, CSTP X-Vms-To: IN%"ip-atm@hpl.hp.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I had a couple of questions for the gurus 1) Is it possible to have an ATM backbone network based only on Virtual Path(VP) switching and no VC switching? 2) What was the rationale of selecting rate based flow control over other forms of flow control for ATM? Thank you, Regards Nick Simha [nsimha@cstp.umkc.edu]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10259; 14 Dec 94 17:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10255; 14 Dec 94 17:49 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17618; 14 Dec 94 17:49 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA030887632; Wed, 14 Dec 1994 12:40:32 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from vax2.cstp.umkc.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA030577627; Wed, 14 Dec 1994 12:40:27 -0800 Received: from VAX2.CSTP.UMKC.EDU by VAX2.CSTP.UMKC.EDU (PMDF #3182 ) id <01HKMY6YP528FTENNT@VAX2.CSTP.UMKC.EDU>; Wed, 14 Dec 1994 14:40:13 CDT Date: 14 Dec 1994 14:40:13 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: DVENKAT@vax2.cstp.umkc.edu Subject: ATM-switching .... some interesting questions. To: ip-atm@matmos.hpl.hp.com Message-Id: <01HKMY6YP52AFTENNT@VAX2.CSTP.UMKC.EDU> Organization: University of Missouri - Kansas City, CSTP X-Vms-To: IN%"ip-atm@matmos.hpl.hp.com" X-Vms-Cc: DVENKAT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hi there, I had a couple of questions on ATM switching. 1. How is the output port ( i.e the port address) determined in the switch during the time of connection setup ? ( i know that , once the connection is set up the output port is determined based on the VPI/VCI values in the header). 2. how is the new VPI/VCI value determined during connection set up? can any one help me on these things.. regards venkatesh Internet: DVENKAT@CSTP.UMKC.EDU University of Missouri - Kansas City Computer Science Telecommunications Program   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10821; 14 Dec 94 18:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10817; 14 Dec 94 18:42 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18534; 14 Dec 94 18:42 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA034340869; Wed, 14 Dec 1994 13:34:29 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA034030865; Wed, 14 Dec 1994 13:34:25 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id NAA24332; Wed, 14 Dec 1994 13:17:09 -0800 Date: Wed, 14 Dec 1994 13:17:09 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: DVENKAT@vax2.cstp.umkc.edu Cc: ip-atm@matmos.hpl.hp.com Subject: Re: ATM-switching .... some interesting questions. In-Reply-To: <01HKMY6YP52AFTENNT@VAX2.CSTP.UMKC.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Venkatesh, Thanks for addressing these questions to the IP over ATM working group. I think you'll get a faster turn around time to them if you ask in the comp.dcom.cell-relay newsgroup. They are much more tuned into ATM technology there, rather the protocol-over-ATM focus of this list. Thanks, Mark > Hi there, > I had a couple of questions on ATM switching. > > 1. How is the output port ( i.e the port address) determined in the switch > during the time of connection setup ? ( i know that , once the connection is > set up the output port is determined based on the VPI/VCI values in the > header). > > 2. how is the new VPI/VCI value determined during connection set up? > > can any one help me on these things..   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15823; 14 Dec 94 23:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15819; 14 Dec 94 23:08 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23249; 14 Dec 94 23:08 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA067660240; Wed, 14 Dec 1994 18:57:20 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA067350237; Wed, 14 Dec 1994 18:57:17 -0800 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA29637; Wed, 14 Dec 1994 18:57:16 -0800 Received: from msd.hitachi.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA15429; Wed, 14 Dec 1994 18:57:39 -0800 Received: from spd.hitachi.com (hicom.spd.hitachi.com) by hitachi.com (4.1/SMI-4.1) id AA14062; Wed, 14 Dec 94 18:55:38 PST Received: from bullet.spd.hitachi.com by spd.hitachi.com (4.1/SMI-4.1) id AA17736; Wed, 14 Dec 94 18:54:31 PST Date: Wed, 14 Dec 94 18:54:31 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shiri Kadambi Message-Id: <9412150254.AA17736@spd.hitachi.com> To: ip-atm@hplms2.hpl.hp.com Subject: Add to the ATM mailing list Please add me to the ATM mailing list. My e-mail address is s_kadambi@hitachi.com. I am with Hitachi computers and my telephone number is (408) 986-9770. Thanks, Shiri Kadambi ( Principal Engineer ) ( Hitachi Computers America., 3101 Tasman Dr, Santa Clara, CA 95054 )   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04300; 15 Dec 94 11:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04296; 15 Dec 94 11:42 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09676; 15 Dec 94 11:42 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA108504977; Thu, 15 Dec 1994 07:22:57 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA108194974; Thu, 15 Dec 1994 07:22:54 -0800 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA08812; Thu, 15 Dec 1994 07:22:53 -0800 Received: from relay2.UU.NET by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA20592; Thu, 15 Dec 1994 07:23:18 -0800 Received: from cixgate by relay2.UU.NET with SMTP id QQxukb06522; Thu, 15 Dec 1994 10:20:15 -0500 Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA14076; Thu, 15 Dec 94 14:23:16 GMT Received: from hqsmtp.OPS.3Com.COM by gw.3Com.COM with SMTP id AA26488 (5.65c/IDA-1.4.4 for ); Thu, 15 Dec 1994 06:19:15 -0800 Received: by hqsmtp.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA1934; Thu, 15 Dec 94 06:20:03 -0800 Message-Id: <9412151420.AA1934@hqsmtp.ops.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id 8A318A032CD53D12852561150054B311; Thu, 15 Dec 94 06:20:03 To: ip-atm Cc: majordomo Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Duane/US/3Com Date: 15 Dec 94 8:24:23 EDT Subject: Please remove me from IP-ATM list Mime-Version: 1.0 Content-Type: Text/Plain Please excuse the list wide distribution, I was not able to be removed via "-Request" or "majordomo" !!! Please remove me from the IP-ATM list George_Duane@3com.com or George_Duane@3mail.3com.com Thanks, Ged   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04466; 15 Dec 94 11:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04460; 15 Dec 94 11:58 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10215; 15 Dec 94 11:58 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA109205481; Thu, 15 Dec 1994 07:31:21 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from vax2.cstp.umkc.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA108895476; Thu, 15 Dec 1994 07:31:16 -0800 Received: from VAX2.CSTP.UMKC.EDU by VAX2.CSTP.UMKC.EDU (PMDF #3182 ) id <01HKO1OCD8DCFTESCL@VAX2.CSTP.UMKC.EDU>; Thu, 15 Dec 1994 09:30:56 CDT Date: 15 Dec 1994 09:30:56 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: DVENKAT@vax2.cstp.umkc.edu Subject: atm stuff.. To: ip-atm@matmos.hpl.hp.com Message-Id: <01HKO1OCDI0YFTESCL@VAX2.CSTP.UMKC.EDU> Organization: University of Missouri - Kansas City, CSTP X-Vms-To: IN%"ip-atm@matmos.hpl.hp.com" X-Vms-Cc: DVENKAT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hi there, i know this is not the place to ask these type of questions. please bear with me.. so here are some, 1. consider sending PCM voice samples ovre ATM . we can do it over either AAL1 or AAL3/4. The tradeoff between the two alternatives concerns the end-to-end delay. can anyone of you help me out on examining the tradeoff..( i mean which delay is more.. why..and sort of that stuff..)? The second question is about interworking.. 2. In Mode 2 (an operating mode) ATM DXI, the DTE alaways performs AAL 3/4 encapsulation before the DXI framing even when the VCC is configured for AAL 5. I seems wierd.. why is it so..? and one more, 3. can anyone highlight the difference between ATM Q.2931 signalling and the signalling used in ISDN,i.e Q.931/Q.921 ? Thanks a lot , venkatesh Internet: DVENKAT@CSTP.UMKC.EDU University of Missouri - Kansas City Computer Science Telecommunications Program Internet: DVENKAT@CSTP.UMKC.EDU University of Missouri - Kansas City Computer Science Telecommunications Program   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06289; 15 Dec 94 14:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06285; 15 Dec 94 14:03 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14376; 15 Dec 94 14:03 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA113752066; Thu, 15 Dec 1994 09:21:07 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nbkanata.Newbridge.COM (Newbridge.COM) by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA113342060; Thu, 15 Dec 1994 09:21:00 -0800 Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA20415; Thu, 15 Dec 94 12:15:34 EST Received: from fields.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA19199; Thu, 15 Dec 94 12:03:33 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <9412151703.AA19199@Newbridge.COM> Subject: Re: atm stuff.. To: DVENKAT@vax2.cstp.umkc.edu Date: Thu, 15 Dec 1994 12:03:32 -0500 (EST) Cc: ip-atm@matmos.hpl.hp.com In-Reply-To: <01HKO1OCDI0YFTESCL@VAX2.CSTP.UMKC.EDU> from "DVENKAT@vax2.cstp.umkc.edu" at Dec 15, 94 09:30:56 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: 999 DVENKAT@vax2.cstp.umkc.edu writes: +-------- |1. consider sending PCM voice samples ovre ATM . we can do it over either |AAL1 or AAL3/4. The tradeoff between the two alternatives concerns the |end-to-end delay. can anyone of you help me out on examining the |tradeoff..( i mean which delay is more.. why..and sort of that stuff..)? +------- As a data point, the ATM Forum is about to release a specification for "Circuit Emulation Service" that uses AAL1 that is intended to carry Constant Bit Rate (CBR) traffic (including PCM voice). The CES provides both "structured" Nx64kbits/s Service" and "unstructured" DS1/E1 Service. The CES carries the data, optionally the signalling associated with timeslots on an E1 or T1 and end-to-end timing. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07188; 15 Dec 94 15:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07184; 15 Dec 94 15:00 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15435; 15 Dec 94 15:00 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA116995787; Thu, 15 Dec 1994 10:23:07 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ptcmtl.montreal.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA116685779; Thu, 15 Dec 1994 10:22:59 -0800 Received: from ptcpcjd.montreal.hp.com by ptcmtl.montreal.hp.com with SMTP (1.38.193.4/15.5+ECS 3.3) id AA22399; Thu, 15 Dec 1994 13:22:11 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jacques Doyon Message-Id: <9412151322.ZM6887@ptcpcjd> Date: Thu, 15 Dec 1994 13:22:49 -0500 Return-Receipt-To: "Jacques Doyon" X-Mailer: ZM-Win (3.2.1 11Sep94) To: ip-atm@matmos.hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Please, remove tom@montreal.hp.com from your list and replace it by the followings: jacques@montreal.hp.com and reda@montreal.hp.com Thanks a lot -- Jacques Doyon e-mail:jacques@montreal.hp.com Hewlett-Packard/Protocol Test Center Tel.: (514) 856-6555 3333, Place Cavendish, Suite 501 FAX: (514)856-2880 Saint-Laurent (Quebec) H4M 2X6   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08045; 16 Dec 94 16:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08040; 16 Dec 94 16:41 EST Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa14719; 16 Dec 94 16:41 EST Received: from sdiv.cray.com (daemon@ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA15884; Fri, 16 Dec 1994 15:36:42 -0600 Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26165; Fri, 16 Dec 1994 15:36:39 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26122; Fri, 16 Dec 1994 15:36:31 -0600 Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA15849 for ; Fri, 16 Dec 1994 15:36:23 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: cn2@arch4.ho.att.com Received: from arch4.ho.att.com by ig2.att.att.com id AA22061; Fri, 16 Dec 94 14:15:29 EST Received: from arch5.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA09846; Fri, 16 Dec 94 14:04:39 EST Received: by arch5.ho.att.com (4.1/EMS-1.2 GIS) id AA13711; Fri, 16 Dec 94 14:04:37 EST Date: Fri, 16 Dec 94 14:04:37 EST Message-Id: <9412161904.AA13711@arch5.ho.att.com> To: vcl@arch4.ho.att.com, joel@arch4.ho.att.com, sig11@roses.stanford.edu, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-aachen.de, ir-l%uccvma.bitnet@cunyvm.cuny.edu, s-comput%tcsvm.BITNET@uunet.uu.net, smds@CNRI.Reston.VA.US, iplpdn@CNRI.Reston.VA.US, cip@bbn.com, icad-request@santafe.edu, sigmedia@bellcore.com, sound@acm.org, announcements.chi@xerox.com, tcplw@cray.com, arl@arl1.wustl.edu, ccrc@dworkin.wustl.edu, g-troup@dworkin.wustl.edu, f-troup@aurora.cis.upenn.edu, end2end-interest@venera.isi.edu, atm@bbn.com, rem-conf@es.net, ietf@venera.isi.edu, tccc@cs.umass.edu Subject: Community Networking Call For Participation Content-Length: 5473 ============================================================================= Call for Participation ============================================================================= SECOND INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME June 20-22, 1995 Princeton, New Jersey, USA Sponsored by the IEEE Communications Society In collaboration with ACM SIGCOMM* Community networking concerns the network infrastructures that will bring integrated multimedia services to home users. Community networking differs in many ways from enterprise networking in its services, technologies, and economics. In contrast to enterprise networking applications, community networking services will not necessarily be work oriented and will range from entertainment to shopping to information services. At present, community networking technology is driven by the requirements of video-on-demand, most notably high bandwidth (compared to narrowband), bandwidth asymmetry, and the delay-jitter constraints imposed by today's limited-storage TV set-top devices. As various other services develop, community networking will evolve to include integrated multimedia communication and user-to-user applications. Community networking must also provide access to resources located outside the community, in an increasingly global repository of information of every conceivable type. This workshop will give researchers and professionals the chance to share their views and advance the state of the art in this field. RELEVANT AREAS: Contributions are encouraged in the five areas listed below with relevant topics: 1. APPLICATIONS AND REQUIREMENTS: types of applications; coding; set-top operating systems; QoS networking requirements (symmetric/asymmetric bandwidth, delay, and losses); security and privacy; service models; user interface and navigation facilities. 2. LOCAL DISTRIBUTION TECHNOLOGY: topology; fiber/cable/UTP/wireless; modulation, bandwidth allocation; MAC (reverse channel); role of ATM; dependencies on equipment/network in the home (e.g., TV set-top). 3. ADDRESSING, SIGNALING, AND UPPER-LAYER PROTOCOLS: local vs. global addressing; the service provider view vs. the common carrier view: the video-dialtone gateway; role of B-ISDN protocols; network- and transport-layer protocols; network management; APIs. 4. INTERNETWORKING AND ARCHITECTURE: the gateway: accessing other networks (data, telephone); server placement and network optimization; the regional distribution centers; testbeds; network traffic models; network cost structure and its implications on service pricing; medium- and long-term network evolution; the impact of regulatory constraints. 5. COMMUNITY ASPECTS, OPPORTUNITIES FOR GROWTH: the success of community networking depends of the degree to which it meets community needs and invites the full participation of community members; community needs, desires and aspirations; networking approaches that have worked well in the past and others that have not; obstacles to success that need to be overcome. INSTRUCTIONS FOR SUBMITTING ABSTRACTS: Please send via electronic mail a detailed abstract (up to 3 pages in ASCII or PostScript) describing a position statement in one of the areas above to cn2@arch4.ho.att.com Note that submissions longer than the limit above will not be reviewed. Only if electronic submission is impossible, a hardcopy version may be sent to: Joel Winthrop AT&T Bell Laboratories 101 Crawfords Corner Rd., RM 1K-306 Holmdel, NJ 07733, USA Participation in the workshop will be by invitation only based on the Program Committee's review of position statements. Some of the authors will be asked to submit papers and to present them during the workshop. Workshop size limitation may preclude attendance of all authors of multi-author abstracts. DATES: Deadline for submitting abstracts . . . . . . . . March 17, 1995 Acceptance notification . . . . . . . . . . . . . April 17, 1995 Papers due (limited to 8 pages) . . May 19, 1995 PROGRAM COMMITTEE: Program Chair: Joel Winthrop AT&T Bell Labs, Holmdel, New Jersey Publication Chair: Vince Lesch AT&T Bell Labs, Holmdel, New Jersey Committee Members: Joydeep Bose National Computer Board, Singapore Jurgen Brommelhoff Digital Equipment Corporation G. Keith Cambron Pacific Bell Andrew Davidson Phillips Interactive Media of America Jeff H. Derby IBM Corporation Alexander D. Gelman Bellcore Riccardo Gusella Hewlett-Packard Laboratories, Palo Alto, California Gordon Kerr BT Labs Andrew Laursen Oracle Corporation Andrew Lippman MIT, Media Lab Tetsuya Miki NTT Transmission Systems Laboratories Mario Morino Morino Foundation Martin De Prycker Alcatel Bell Telephone, Antwerp, Belgium David Skellern Macquarie University, Sydney Albert J. Stienstra Philips Research Mario P. Vecchi Time Warner Cable, Inc. William E. Wall Scientific-Atlanta, Inc. * Approval Pending   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06276; 19 Dec 94 12:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06272; 19 Dec 94 12:40 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11161; 19 Dec 94 12:40 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06237; 19 Dec 94 12:39 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06233; 19 Dec 94 12:36 EST Received: from maelstrom.acton.timeplex.com by CNRI.Reston.VA.US id aa10740; 19 Dec 94 12:36 EST Received: from maelstrom.timeplex.com (malis@localhost) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id MAA27949; Mon, 19 Dec 1994 12:37:41 -0500 Message-Id: <199412191737.MAA27949@maelstrom.acton.timeplex.com> To: iplpdn@CNRI.Reston.VA.US cc: malis@maelstrom.acton.timeplex.com, dave@corecom.com, jcl@mail.bellcore.com, clapp@ameris.center.il.ameritech.com, stev+iesg@ftp.com, ip-atm@matmos.hpl.hp.com, smds@CNRI.Reston.VA.US, iesg@CNRI.Reston.VA.US Subject: RFC 1209 (IP over SMDS) advancement to Draft Standard Date: Mon, 19 Dec 1994 12:37:41 -0500 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis IPLPDNers, I've been asked by Stev Knowles to chair a virtual (over the net) IPLPDN "meeting" in order to advance RFC 1209, "The Transmission of IP Datagrams over the SMDS Service", from Proposed Standard to Draft Standard. Note that rfc-index.txt incorrectly lists 1209 as DS, but RFC 1720 (STD 1) correctly lists it as Proposed. As part of the process, the Working Group is required to list known RFC 1209 implementations. Please, if you have implemented RFC 1209, drop me a line (just to me is fine) to let me know. If you would like this, or any of the following, information to be confidential, that is fine - just let me know. We also need to know if: - There are any parts of the RFC that you did NOT implement, so the WG can consider removing any features that were never implemented by anyone. Given the brevity of the RFC, this is probably unlikely (except perhaps the IP multicasting support). - If your implementation has, to your knowledge, interoperated with (or failed to interoperate with) other implementations. - If you encountered any problems with the RFC itself (inconsistencies, unclear sections, etc.) that can or should be improved. Also, please send me a message if you, for any reason, feel that RFC 1209 should NOT be advanced. Including your reason would help! :-) After a week or so, I will issue a summary listing non-confidential information received. Because of the age of the iplpdn list, I've also sent this to the ip-atm and smds lists as well. Sorry for any duplicates. From this point on, please restrict mail to the iplpdn list itself. I will also be posting a version of this message on comp.dcom.cell-relay. Requests to be added to or deleted from the iplpdn mailing list go to iplpdn-request@cnri.reston.va.us [DO NOT just reply to this message - your request will not be received by the list maintainer]. Thanks, Andy Virtual Chair, IETF IP over Large Public Data Networks Working Group __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12669; 19 Dec 94 19:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12665; 19 Dec 94 19:12 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19913; 19 Dec 94 19:12 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA066356072; Mon, 19 Dec 1994 14:27:52 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from xap.xyplex.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA066046067; Mon, 19 Dec 1994 14:27:47 -0800 Received: from HQgate.xyplex.com by xap.xyplex.com id ; Mon, 19 Dec 94 17:29:42 -0500 Received: by hqgate.xyplex.com with Microsoft Mail id <2EF5C298@hqgate.xyplex.com>; Mon, 19 Dec 94 17:27:52 est Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Grimm, Chris" To: atm_forum Subject: mailing list Date: Mon, 19 Dec 94 17:27:00 est Message-Id: <2EF5C298@hqgate.xyplex.com> Encoding: 7 TEXT X-Mailer: Microsoft Mail V3.0 hello , please add me . chris grimm Xyplex cgrimm@eng.xyplex.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12813; 19 Dec 94 19:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12809; 19 Dec 94 19:23 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20107; 19 Dec 94 19:23 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA067147047; Mon, 19 Dec 1994 14:44:08 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA066837043; Mon, 19 Dec 1994 14:44:03 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id OAA27074; Mon, 19 Dec 1994 14:26:04 -0800 Date: Mon, 19 Dec 1994 14:26:04 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: "Grimm, Chris" Cc: atm_forum Subject: Re: mailing list In-Reply-To: <2EF5C298@hqgate.xyplex.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hiya, this is not an ATM Forum mailing list. This is a mailing list of the IP over ATM working group of the Internet Engineering Task Force. And, as with all internet mailing lists, messages about un/subscriptions need to go to the mailbox name with a "-request" appended; i.e. ip-atm-request@matmos.hpl.hp.com. The 1000+ people on this list don't need to see this messages. Thanks, Mark On Mon, 19 Dec 1994, Grimm, Chris wrote: > > hello , > please add me . > > chris grimm > Xyplex > cgrimm@eng.xyplex.com >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13594; 19 Dec 94 19:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13589; 19 Dec 94 19:54 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20672; 19 Dec 94 19:54 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA069008708; Mon, 19 Dec 1994 15:11:48 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA068698693; Mon, 19 Dec 1994 15:11:33 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id OAA27479; Mon, 19 Dec 1994 14:52:35 -0800 Date: Mon, 19 Dec 1994 14:52:35 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199412192252.OAA27479@terra.com21.com> To: ip-atm@matmos.hpl.hp.com Subject: updated draft minutes from san jose [Sorry about sending that last response to the whole list, you didn't ] [need to see that either. ] I've taken in the few comments about the minutes and here is the updated draft. I need to submit these by this Friday. Please let me know if there are any other comments. Mark IP over ATM Working Group MInutes IETF Meeting, December 6, 1994 San Jose, California ATM Forum Liaison Report, Drew Perkins Drew will send an email report to the mailing list for the Kyoto meeting (last week of November). ATM Forum Documents complete: o LANE is now complete, all minor and major questions have been answered. o IISP complete o CMIP, SNMP mibs (m4) completed o Test specifications completed LANE emulation has made UNI mapping independent (UNI 3.0 and 3.1 supported). Information bus support. A ready indicate packet is now used (added, regular LANE data cell) after connect.ACK. New work items for soft PVP's. Multiprotocol over ATM group: identified requirements and different references models for how the system ought to work. Single end system host behavior (query/response). Signaling: leaf initiated join in progress, authenticated connection work will start next meeting. ATM DXI sent to straw ballot, for channelized DS3. Circuit emulation: emulation of D1 circuits sent to straw ballot. Support of early packet drop (cell drop, frame drop) begining to get specified. Inverse T1 multiplexing. 155 Mbps over UTP3. Phy group is now allowed to specify more than one interface. Residential broadband work starting up, they are calling for contributions. Q: Multiprotocol BOF models: LANE model, combined with Classical and NHRP model. ...some discussion. RFC1577 Implementer's Round-up: There are now about ten implementations in progress and maybe also that Digital has even passed the first interoperability test with two other vendors who prefer to remain anonymous. Dario Ercole, Interpersonal Mutlimedia Communications over ATM Shown at Interop '94. Connect Paris with Torino. OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. They discovered that they could not run IP over ATM over a public network if they did not perform rate control. This means application level rate control and inter-switch rate control. The NNI between the switches generated "big packets". RFC1577 over wide-area? Who is going to provide/specify the recommendations for the policing function? Andy Malis: very much dependent on the type of network the traffic is being sent through. Dario agrees. Ken Howard: isn't ATM deregulated in Europe? What about multiple vendors and solutions? Dario: this topis is not network specific. Consensus is that this is more of an ATM specific issue and that IP over ATM will make use of available services. While not an issue of this working group's charter, performance of ATM does impact performance of IP over ATM. Grenville Armitage, IP Multicast Draft Rewview. Grenville gave an overview of his two Internet-drafts. Goals: work within RFC1577 context, Utilize UNI 3.1 multicast services. Non-goal: UNI 4.0, IP multicast routing. Mark: recommend that having a separate registration server, i.e. de-couple ATMARP_REQUEST from the multicast-request. Comment: please don't have the user type in two 20 byte addresses. Maybe there's a clever way to do this? Question about whether the two server can live at the same LLC entity? Mark raised point of if the ARP type coding is distinct, this is possible that it and an ATMARP server could live above 0x0806, however, old implementations must be tolerant of receiving these types without doing nasty things. RFC1577 rewrite could specific that hosts must be tolerant of receiving other type codes. Q: Do you perceive any bounds on the size of the mcleave and join messages? A: ARP_MULTI response is quite large and currently exceeds the bounds on host adapters. Q: What happens when the arp server fails? What happens to the VC's that are active on the host? A: currently not addressed. Drew suggested resyncing after a period of time. Drew: I think the document needs to augmented that failure ought to reset all state. A: yes, I need some text for this. Drew: the document has a discussion of binding to LLC entities. Perhaps it can be skipped, as it might cause more controversy and/or confusion. It is not necessary for this to be in the document. Statement: need to draw out the end system architecture from the actual implementation. It think it useful to understand how the protocol works. Comments were to move it into the framework document. Multicast Server Discussion: Suggestion was to name the service: Multicast Address Registration Server (MARS). Drew: when mcserver, why use an ARP_REPLY instead of an ARP_MULTI with a single member. [Discussion about how to set up a mcast vc.] [Further discussion about supporting multiple mc servers.] Issue of checking. Issue of reassembly resources in hosts. Framework Document Discussion, David Shur Curtis suggested issuing the document in HTML which converts easily to both postscript and text. This would allow easy review and posting as an I-D. He is willing to do the conversion if he can get the document text in ASCII. It is up to the authors at this point to give it to him. General consensus that we need to close on this real soon, via a series of interactive discussions on the email list. Consensus that Grenville's LLC material from the multicast document should be moved to the Framework document. Work Plan presentation Mark put up the suggested FY95 work plan, as follows: 1. UNI 3.0 Signaling draft -> Informational RFC (submitted) 2. UNI 3.1 Signaling draft -> proposed (re-submitted 12/4) 3. Framework draft -> Informational RFC 4. Multicast draft(s) -> proposed (?) 5. RFC1483 proposed -> draft 6. RFC1577 proposed -> proposed (?) 7. RFC1626 proposed -> draft 8. UNI 4.0 Signaling draft. Point was raised that ITU has a contribution for the RFC1483 rewrite. Questions were raised regarding when to start the RFC1577 rewrite. Mark proposed starting this in the March/April timeframe. Drew suggested getting started sooner. A statement was made that RFC1626 should be rolled into the RFC1577 rewrite. We were not able to discuss this and clarify why they are different. # end of minutes.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18424; 19 Dec 94 23:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18420; 19 Dec 94 23:41 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24956; 19 Dec 94 23:41 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA078233109; Mon, 19 Dec 1994 19:11:49 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA077923105; Mon, 19 Dec 1994 19:11:45 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id UAA01591; Mon, 19 Dec 1994 20:27:00 -0500 Message-Id: <199412200127.UAA01591@curtis.ansremote.com> To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com Reply-To: curtis@ans.net Subject: Re: updated draft minutes from san jose In-Reply-To: Your message of "Mon, 19 Dec 1994 14:52:35 PST." <199412192252.OAA27479@terra.com21.com> Date: Mon, 19 Dec 1994 20:26:04 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <199412192252.OAA27479@terra.com21.com>, Mark Laubach writes: > > Framework Document Discussion, David Shur > > Curtis suggested issuing the document in HTML which converts > easily to both postscript and text. This would allow easy review > and posting as an I-D. He is willing to do the conversion if > he can get the document text in ASCII. It is up to the authors > at this point to give it to him. Shouldn't this read - the authors should decide whether they want to take Curtis up on this offer? Or something like that? The rest doesn't have to do with the minutes. > General consensus that we need to close on this real soon, via > a series of interactive discussions on the email list. I will send my comments on the framework doc to the list. > Consensus that Grenville's LLC material from the multicast document > should be moved to the Framework document. What portion of Grenville's document was that. Could you give section numbers or page numbers? Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22698; 20 Dec 94 0:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22694; 20 Dec 94 0:57 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26688; 20 Dec 94 0:57 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA081088451; Mon, 19 Dec 1994 20:40:51 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from athos.maths.adelaide.edu.au by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA080778445; Mon, 19 Dec 1994 20:40:45 -0800 Received: by athos.maths.adelaide.edu.au (5.64+1.3.1+0.50/UA-5.19) id AA18195; Tue, 20 Dec 1994 15:10:30 +1030 Date: Tue, 20 Dec 1994 15:10:30 +1030 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Kennington Message-Id: <9412200440.AA18195@athos.maths.adelaide.edu.au> To: ip-atm@matmos.hpl.hp.com Subject: 1 VC per TCP (again) Cc: akenning@spam.maths.adelaide.edu.au Many months back, I asked about mapping each TCP connection to a different VC, and got many useful comments. Now I'm implementing this concept. Does anyone have the necessary software to do the splitting/recombination for this mapping please? We are setting up a small ATM network over satellite links, and we wil put some IP traffic onto this network from sparc stations. However, with the 1 VC per IP host pair mapping, we cannot expedite interactive traffic in preference to file transfers and video etc. Hence we need to intercept IP traffic leaving a sparc station (probably running SunOS 4.x.y), read the socket numbers, and then pass the packets on to the Fore Systems SBA-200 card (or SBA-100 card) on different VCs according to the socket number. In the other direction, we need to just recombine all IP packets and hand them on the the operating system IP software somehow. Does anyone out there have this sort of software please? Thanks in advance, Alan Kennington. PS. Any suggestions on better ways of doing the 1 VC per TCP split in this particular setup would be most welcome. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Alan Kennington internet: akenning@maths.adelaide.edu.au Teletraffic Research Centre work tel: +61 8 303 3031 University of Adelaide work fax: +61 8 303 4395 Adelaide SA 5005 Australia   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04718; 20 Dec 94 11:42 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04714; 20 Dec 94 11:42 EST Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa09426; 20 Dec 94 11:42 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA119226951; Tue, 20 Dec 1994 07:22:31 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA118916944; Tue, 20 Dec 1994 07:22:24 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id KAA27401; Tue, 20 Dec 1994 10:21:13 -0500 Message-Id: <199412201521.KAA27401@thumper.bellcore.com> To: curtis@ans.net Cc: Mark Laubach , ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: updated draft minutes from san jose In-Reply-To: Your message of Mon, 19 Dec 1994 20:26:04 -0500. <199412200127.UAA01591@curtis.ansremote.com> Date: Tue, 20 Dec 1994 10:21:07 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage [..] >>> Consensus that Grenville's LLC material from the multicast document >>> should be moved to the Framework document. >> >>What portion of Grenville's document was that. Could you give section >>numbers or page numbers? That is probably a good question, but it was not much clearer at the meeting itself. Perhaps Drew can remember what parts irked him the most :-) I initially interpreted Drew's question on the LLC material to be about Appendix A (and B?), with Section 3 needing to be trimmed a little. However, having mulled it over for the last week I'm still trying to decide if the Framework doc is the right place for it. My first goal is to split the multicast draft in two - extracting the 'how to account for the implicit LLC layer in your designs' parts of the present draft into a separate doc. We can decide its future from there. cheers, gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11410; 20 Dec 94 18:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11402; 20 Dec 94 18:54 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19232; 20 Dec 94 18:54 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137552734; Tue, 20 Dec 1994 14:32:15 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137242725; Tue, 20 Dec 1994 14:32:05 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id OAA05500; Tue, 20 Dec 1994 14:14:12 -0800 Date: Tue, 20 Dec 1994 14:14:11 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Curtis Villamizar Cc: ip-atm@matmos.hpl.hp.com Subject: Re: updated draft minutes from san jose In-Reply-To: <199412200127.UAA01591@curtis.ansremote.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Shouldn't this read - the authors should decide whether they want to > take Curtis up on this offer? Or something like that? Thanks, I changed the text. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11434; 20 Dec 94 18:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11429; 20 Dec 94 18:57 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19289; 20 Dec 94 18:56 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA138002946; Tue, 20 Dec 1994 14:35:46 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137692925; Tue, 20 Dec 1994 14:35:25 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id OAA05519; Tue, 20 Dec 1994 14:16:53 -0800 Date: Tue, 20 Dec 1994 14:16:53 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Grenville Armitage Cc: curtis@ans.net, ip-atm@matmos.hpl.hp.com Subject: Re: updated draft minutes from san jose In-Reply-To: <199412201521.KAA27401@thumper.bellcore.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I'm still trying to decide if the Framework doc is the right place for > it. My first goal is to split the multicast draft in two - > extracting the 'how to account for the implicit LLC layer in your > designs' parts of the present draft into a separate doc. We can > decide its future from there. The WG decided at the meeting that its future is to put the implicit LLC layer text into its own section in the framework document. Please work with the authors to collect it there. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12649; 20 Dec 94 21:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12645; 20 Dec 94 21:07 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22791; 20 Dec 94 21:07 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA150242781; Tue, 20 Dec 1994 17:19:41 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ims.ac.jp (ims1.ims.ac.jp) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149922775; Tue, 20 Dec 1994 17:19:35 -0800 Received: from [133.48.140.221] by ims.ac.jp (8.6.8+2.4Wb2/TISN-1.3M/R2) id AAA22715; Wed, 21 Dec 1994 00:03:19 +0900 Date: Wed, 21 Dec 1994 00:03:19 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kunihiko Tanaka Message-Id: <199412201503.AAA22715@ims.ac.jp> Apparently-To:   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab12695; 20 Dec 94 21:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12691; 20 Dec 94 21:13 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22866; 20 Dec 94 21:13 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA151183047; Tue, 20 Dec 1994 17:24:07 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ims.ac.jp (ims1.ims.ac.jp) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA150873041; Tue, 20 Dec 1994 17:24:01 -0800 Received: from [133.48.140.221] by ims.ac.jp (8.6.8+2.4Wb2/TISN-1.3M/R2) id AAA22667; Wed, 21 Dec 1994 00:01:41 +0900 Date: Wed, 21 Dec 1994 00:01:41 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kunihiko Tanaka Message-Id: <199412201501.AAA22667@ims.ac.jp> Apparently-To:   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12705; 20 Dec 94 21:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12701; 20 Dec 94 21:14 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22882; 20 Dec 94 21:13 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA150762916; Tue, 20 Dec 1994 17:21:56 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ims.ac.jp (ims1.ims.ac.jp) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA150452912; Tue, 20 Dec 1994 17:21:52 -0800 Received: from [133.48.140.221] by ims.ac.jp (8.6.8+2.4Wb2/TISN-1.3M/R2) id XAA21992; Tue, 20 Dec 1994 23:49:40 +0900 Date: Tue, 20 Dec 1994 23:49:40 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kunihiko Tanaka Message-Id: <199412201449.XAA21992@ims.ac.jp> Apparently-To:   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12715; 20 Dec 94 21:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12711; 20 Dec 94 21:14 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22908; 20 Dec 94 21:14 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA151743169; Tue, 20 Dec 1994 17:26:09 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ims.ac.jp (ims1.ims.ac.jp) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA151433164; Tue, 20 Dec 1994 17:26:04 -0800 Received: from [133.48.140.221] by ims.ac.jp (8.6.8+2.4Wb2/TISN-1.3M/R2) id AAA22782; Wed, 21 Dec 1994 00:07:36 +0900 Date: Wed, 21 Dec 1994 00:07:36 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kunihiko Tanaka Message-Id: <199412201507.AAA22782@ims.ac.jp> Apparently-To:   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13058; 20 Dec 94 21:43 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13054; 20 Dec 94 21:43 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23396; 20 Dec 94 21:43 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA152123310; Tue, 20 Dec 1994 17:28:30 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ims.ac.jp (ims1.ims.ac.jp) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA151813297; Tue, 20 Dec 1994 17:28:17 -0800 Received: from [133.48.140.221] by ims.ac.jp (8.6.8+2.4Wb2/TISN-1.3M/R2) id AAA22680; Wed, 21 Dec 1994 00:02:09 +0900 Date: Wed, 21 Dec 1994 00:02:09 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kunihiko Tanaka Message-Id: <199412201502.AAA22680@ims.ac.jp> Apparently-To:   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21434; 21 Dec 94 2:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21430; 21 Dec 94 2:44 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28033; 21 Dec 94 2:44 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA169203042; Tue, 20 Dec 1994 22:57:22 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplabs.hpl.hp.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA168903038; Tue, 20 Dec 1994 22:57:19 -0800 Received: from nacho.cisco.com by hplabs.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA170393037; Tue, 20 Dec 1994 22:57:17 -0800 Received: from [171.69.60.202] (fbaker-mac.cisco.com [171.69.60.202]) by nacho.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id WAA28973; Tue, 20 Dec 1994 22:02:40 -0800 X-Sender: fred@nacho.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Dec 1994 22:02:43 -0800 To: Alan Kennington Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: 1 VC per TCP (again) Cc: ip-atm@matmos.hpl.hp.com At 8:40 PM 12/19/94, Alan Kennington wrote: >Any suggestions on better ways of doing the 1 VC per TCP split in this >particular setup would be most welcome. It seems to me that you're going at it backwards. You don't want the data link looking into the transport headers to figure out how to data link, you want a TOS paradigm, with telnet and SMTP announcing delay sensitivity and FTP announcing bandwidth sensitivity. Configure two (or more) VCIs per host pair, one for each TOS, and have IP obey that criterion in circuit selection. ============================================================================= If you're not living on the edge, you're taking up too much room!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00702; 21 Dec 94 5:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00698; 21 Dec 94 5:25 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02022; 21 Dec 94 5:25 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA187012532; Wed, 21 Dec 1994 01:35:32 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from tech.ascom.ch (aare.tech.ascom.ch) by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA186702527; Wed, 21 Dec 1994 01:35:27 -0800 Received: from uranus (uranus.be.tech.ascom.ch) by tech.ascom.ch (4.1/SMI-4.1) id AA10220; Wed, 21 Dec 94 10:35:11 +0100 Received: from locarno by uranus (4.1/SMI-4.1/1.1) id AA19715; Wed, 21 Dec 94 10:35:10 +0100 Date: Wed, 21 Dec 94 10:35:10 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Beat Stettler Message-Id: <9412210935.AA19715@uranus> To: ip-atm@matmos.hpl.hp.com Subject: Re: 1 VC per TCP (again) > > Many months back, I asked about mapping each TCP connection to a different > VC, and got many useful comments. Now I'm implementing this concept. > Does anyone have the necessary software to do the splitting/recombination > for this mapping please? > > We are setting up a small ATM network over satellite links, and we wil > put some IP traffic onto this network from sparc stations. However, with > the 1 VC per IP host pair mapping, we cannot expedite interactive traffic > in preference to file transfers and video etc. > Hence we need to intercept IP traffic leaving a sparc station > (probably running SunOS 4.x.y), read the socket numbers, and then pass > the packets on to the Fore Systems SBA-200 card (or SBA-100 card) on different > VCs according to the socket number. > In the other direction, we need to just recombine all IP packets and hand them > on the the operating system IP software somehow. > > Does anyone out there have this sort of software please? > > Thanks in advance, > Alan Kennington. > > PS. Any suggestions on better ways of doing the 1 VC per TCP split in this > particular setup would be most welcome. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Alan Kennington internet: akenning@maths.adelaide.edu.au > Teletraffic Research Centre work tel: +61 8 303 3031 > University of Adelaide work fax: +61 8 303 4395 > Adelaide SA 5005 > Australia > J just sent to Alan following mail. If anyone else has good ideas please let me know. Thank you Beat --- Included Message --- Hi Alan, I am on a pretty similar implementation with ETH Zuerich and Ascom Tech AG. Basically, we will implement a Network Interface below the IP Routing Software. That means that the ATM Net is considered as a IP Subnet, which receives all IP Packets, that have to go over the ATM Side. We then have to find out what ATM Adress belongs to the next hop. (ATM ARP RFC 1577) We then encapsulate the IP Packets according to RFC 1483 / RFC 1626 and send it over ATM AAL 5. We just got two SBA 200 Fore Cards for the Sun and also Ascom is develloping its own ATM Switch, which the Software might run on. We were also thinking long about whether to map each IP Source/Destination pair on one VC or to work on a Port to port base. We found that it made more sense to seperate on a Source/Destination base just because we otherwise had to go up on the TCP layer to find out what port the packet belongs to. But we did not want to implement the whole IP Stack, since this is done by many others already. We wanted to leave IP as it is, that means we leave all the IP protocols (RIP, ICMP, EGP) alone and concentrate on a ATM specific ARP mechanism, on signalling and on Traffic shaping. So we reduced the whole problem on implementig the media access sublayer. If you know the book " Internetworking with TCP/IP, Design, Implementation and Internals" from D. Comer (Prentice Hall). There you can see what i mean. (page 61) There is also a whole IP Stack implementation in C code which is very useful. We were evaluating different Hardware Platforms to let the Software run. Of course we thaught about using the fore cards. Fore delivers already an IP driver and its own signalling protocol (SPANS) which can be turned off. But we have not found a way yet to - make the Sun (Sun OS or Solaris 2) give us the Ip packet just for one (ATM) network interface (Fore Card). We dont have the Source Code of the device Driver. So we dont know how to sit between the routing software and the fore card. - make the Fore Card running without SPANS due to the fact that we dont have a ATM switch wich understands UNI 3.1 Signalling which we implement. I am not a big Unix Freak and i am a little afraid of touching the Kernel. Please let me know how you want to do that. And if you get any good software that has already implemented what we want to do, then I would be very thankful if you let me know. Thank you very much Beat _______________________________________________________________________________ ASCOM TECH |\/\/\/| Beat Stettler EMail: stettler@tech.ascom.ch | | Morgenstr.129 EMail: stettler@systech.tik.ethz.ch | (o)(o) 3018 Bern tel:+41 31 999 3720 C _) Switzerland fax:+41 31 999 3607 | ,___| | / _________________________________oOOo___/____\_____oOOo________ Cheer up! _____   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07428; 21 Dec 94 13:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07424; 21 Dec 94 13:44 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11670; 21 Dec 94 13:44 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA205788750; Wed, 21 Dec 1994 08:52:30 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sun4.iol.unh.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA205478745; Wed, 21 Dec 1994 08:52:25 -0800 Received: by sun4.iol.unh.edu (4.1/SMI-4.1) id AA06115; Wed, 21 Dec 94 11:53:12 EST Date: Wed, 21 Dec 94 11:53:12 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ronald W. Pashby" Message-Id: <9412211653.AA06115@sun4.iol.unh.edu> To: ip-atm@matmos.hpl.hp.com Subject: UNH ATM Interoperability Testing ----- Begin Included Message ----- Date: Wed, 21 Dec 94 11:48:01 EST From: Mailer-Daemon (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: rwp The ATM Consortium of the University of New Hampshire's Interoperability Lab would like to announce that it's fourth Multi-Vendor ATM Interoperability Test Period will be held from February 20 through 24, 1995. The testing will be free to ATM Consortium members and $4,500 for non members. (Consortium membership is $9,000 per year.) The major focus for this test period will be on interoper- ability of SVC connections as specified in the UNI 3.0, implementations of RFC-1577 (Classical IP and ARP over ATM) and implementations of IETF-draft "ATM Signaling Support for IP over ATM." Basic interoperability testing will also be performed for those devices that do not support standard SVCs or RFC-1577. Advance registration, by January 16, 1995, is required for participation in this test. For further info regarding the upcoming test period, please contact Ron Pashby at (603)862-0204 or pashby@unh.edu.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13371; 21 Dec 94 21:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13367; 21 Dec 94 21:26 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20910; 21 Dec 94 21:26 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA222365717; Wed, 21 Dec 1994 16:21:57 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA222055710; Wed, 21 Dec 1994 16:21:50 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id QAA13225; Wed, 21 Dec 1994 16:03:34 -0800 Date: Wed, 21 Dec 1994 16:03:34 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199412220003.QAA13225@terra.com21.com> To: minutes@CNRI.Reston.VA.US Cc: ip-atm@matmos.hpl.hp.com, stev-iesg@ftp.com, topolcic@bbn.com Subject: Final minutes, IPATM WG, San Jose Meeting IP over ATM Working Group Minutes IETF Meeting, December 6, 1994 San Jose, California Working group overview: Chair: Mark Laubach Internet Area Director(s): Stev Knowles Claudio Topolcic Mailing lists: General Discussion: ip-atm@matmos.hpl.hp.com To Subscribe: majordomo@matmos.hpl.hp.com List Archive: ftp.hep.net:~ftp/lists-archive/atm WG Documents: ftp.com21.com:~ftp/pub/ip-atm WWW Server: http://www.com21.com/ ATM Forum Liaison Report, Drew Perkins Drew will send an email report to the mailing list for the Kyoto meeting (last week of November). Docs complete: o LANE is now complete, all minor and major questions have been answered. o IISP complete o CMIP, SNMP mibs (m4) completed o Test specifications completed LANE emulation has been made UNI mapping independent (UNI 3.0 and 3.1 supported). Intelligent bus support added. A ready indicate packet has been added (on data connections) and its use is now mandatory New work items for soft PVP's in PNNI. Multiprotocol over ATM group: identified some requirements and different references models for how the system ought to work. Single end system host behavior (query/response). Signaling: leaf initiated join in progress, authenticated connection work will start next meeting. ATM DXI sent to straw ballot, for channelized DS3. Circuit emulation: emulation of D1 circuits sent to straw ballot. Support of early packet drop (cell drop, frame drop) begining to get specified. Inverse T1 multiplexing. 155 Mbps over UTP3. Phy group is now allowed to specify more than one interface. Residential broadband work starting up, they are calling for contributions. Q: Multiprotocol BOF models: LANE model, combined with Classical and NHRP model. ...some discussion. RFC1577 Implementer's Round-up: There are now about ten implementations in progress and maybe also that Digital has even passed the first interoperability test with two other vendors who prefer to remain anonymous. Dario Ercole, Interpersonal Mutlimedia Communications over ATM Shown at Interop '94. Connect Paris with Torino. OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. They discovered that they could not run IP over ATM over a public network if they did not perform rate control. This means application level rate control and inter-switch rate control. The NNI between the switches generated "big packets". RFC1577 over wide-area? Who is going to provide/specify the recommendations for the policing function? Andy Malis: very much dependent on the type of network the traffic is being sent through. Dario agrees. Ken Hayward: isn't ATM deregulated in Europe? What about multiple vendors and solutions? Dario: this topis is not network specific. Consensus is that this is more of an ATM specific issue and that IP over ATM will make use of available services. While not an issue of this working group's charter, performance of ATM does impact performance of IP over ATM. Grenville Armitage, IP Multicast Draft Rewview. Grenville gave an overview of his two Internet-drafts. Goals: work within RFC1577 context, Utilize UNI 3.1 multicast services. Non-goal: UNI 4.0, IP multicast routing. Mark: recommend that having a separate registration server, i.e. de-couple ATMARP_REQUEST from the multicast-request. Comment: please don't have the user type in two 20 byte addresses. Maybe there's a clever way to do this? Question about whether the two server can live at the same LLC entity? Mark raised point of if the ARP type coding is distinct, this is possible that it and an ATMARP server could live above 0x0806, however, old implementations must be tolerant of receiving these types without doing nasty things. RFC1577 rewrite could specific that hosts must be tolerant of receiving other type codes. Q: Do you perceive any bounds on the size of the mcleave and join messages? A: ARP_MULTI response is quite large and currently exceeds the bounds on host adapters. Q: What happens when the arp server fails? What happens to the VC's that are active on the host? A: currently not addressed. Drew suggested resyncing after a period of time. Drew: I think the document needs to augmented that failure ought to reset all state. A: yes, I need some text for this. Drew: the document has a discussion of binding to LLC entities. Perhaps it can be skipped, as it might cause more controversy and/or confusion. It is not necessary for this to be in the document. Statement: need to draw out the end system architecture from the actual implementation. It think it useful to understand how the protocol works. Comments were to move it into the framework document. Multicast Server Discussion: Suggestion was to name the service: Multicast Address Registration Server (MARS). Drew: when mcserver, why use an ARP_REPLY instead of an ARP_MULTI with a single member. [Discussion about how to set up a mcast vc.] [Further discussion about supporting multiple mc servers.] Issue of checking. Issue of reassembly resources in hosts. Framework Document Discussion, David Shur Curtis suggested issuing the document in HTML which converts easily to both postscript and text. This would allow easy review and posting as an I-D. He is willing to do the conversion if he can get the document text in ASCII. It is up to the authors at this point to give it to him. General consensus that we need to close on this real soon, via a series of interactive discussions on the email list. Consensus that Grenville's LLC material from the multicast document should be moved to the Framework document. Work Plan presentation Mark put up the suggested FY95 work plan, as follows: 1. UNI 3.0 Signaling draft -> Informational RFC (submitted) 2. UNI 3.1 Signaling draft -> proposed (re-submitted 12/4) 3. Framework draft -> Informational RFC 4. Multicast draft(s) -> proposed (?) 5. RFC1483 proposed -> draft 6. RFC1577 proposed -> proposed (?) 7. RFC1626 proposed -> draft 8. UNI 4.0 Signaling draft. Point was raised that ITU has a contribution for the RFC1483 rewrite. Questions were raised regarding when to start the RFC1577 rewrite. Mark proposed starting this in the March/April timeframe. Drew suggested getting started sooner. A statement was made that RFC1626 should be rolled into the RFC1577 rewrite. We were not able to discuss this and clarify why they are different. # end of minutes.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20780; 21 Dec 94 23:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20776; 21 Dec 94 23:56 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23134; 21 Dec 94 23:56 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA235679458; Wed, 21 Dec 1994 20:10:58 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA235369454; Wed, 21 Dec 1994 20:10:54 -0800 Received: from arch4.ho.att.com by ig1.att.att.com id AA06020; Wed, 21 Dec 94 13:12:18 EST Received: from dahlia.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA16439; Wed, 21 Dec 94 13:14:13 EST Received: by dahlia.ho.att.com (4.1/EMS-1.1 SunOS) id AA07828; Wed, 21 Dec 94 13:13:53 EST Date: Wed, 21 Dec 94 13:13:53 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: shur@arch4.ho.att.com Message-Id: <9412211813.AA07828@dahlia.ho.att.com> To: gja@thumper.bellcore.com, laubach@terra.com21.com Subject: Re: updated draft minutes from san jose Cc: curtis@ans.net, ip-atm@matmos.hpl.hp.com > > I'm still trying to decide if the Framework doc is the right place for > > it. My first goal is to split the multicast draft in two - > > extracting the 'how to account for the implicit LLC layer in your > > designs' parts of the present draft into a separate doc. We can > > decide its future from there. > > The WG decided at the meeting that its future is to put the implicit LLC > layer text into its own section in the framework document. Please work > with the authors to collect it there. > > Thanks, > Mark > We are working on a section covering different forms of encapsulation, and thought to cover the above point there. If you have any specific text you would like to see included please let Bob Cole and/or myself know. Thanks, David.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01191; 22 Dec 94 6:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01187; 22 Dec 94 6:27 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02812; 22 Dec 94 6:27 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA260092855; Thu, 22 Dec 1994 02:40:55 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from POSTAL.CSELT.STET.IT by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA259782849; Thu, 22 Dec 1994 02:40:49 -0800 Received: from DN-EI3500 by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01HKXWQ6Z1G0000RLT@POSTAL.CSELT.STET.IT>; Thu, 22 Dec 1994 10:55:14 MET Received: from [163.162.7.247] (163.162.7.247) by EI3500.CSELT.STET.IT; Thu, 22 Dec 94 10:51 GMT +1 Date: Thu, 22 Dec 1994 10:56:57 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dario.Ercole@cselt.stet.it Subject: Re: Final minutes, IPATM WG, San Jose Meeting To: ip-atm@matmos.hpl.hp.com Message-Id: X-Envelope-To: ip-atm@matmos.hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: ercole@satchmo.cselt.stet.it >Dario Ercole, Interpersonal Mutlimedia Communications over ATM > > Shown at Interop '94. Connect Paris with Torino. > OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. > They discovered that they could not run IP over ATM over a > public network if they did not perform rate control. This means > application level rate control and inter-switch rate control. > The NNI between the switches generated "big packets". > > RFC1577 over wide-area? Who is going to provide/specify > the recommendations for the policing function? > > Andy Malis: very much dependent on the type of network the > traffic is being sent through. Dario agrees. > > Ken Hayward: isn't ATM deregulated in Europe? What about > multiple vendors and solutions? Dario: this topis is not > network specific. > > Consensus is that this is more of an ATM specific issue and > that IP over ATM will make use of available services. While > not an issue of this working group's charter, performance of > ATM does impact performance of IP over ATM. > I think there was also consensus (at least Drew Perking nodded) that ATM equipment available NOW for ATM LANs and WANs perform *peak-rate* policing (if any). Maybe in a near future, after the recent ATM Forum decision on Traffic Management, different and more sofisticated policing schemes will be implemented by the vendors on their switches. But I do not expect this to happen before one year; until then people willing to use ATM on both LAN and WAN will have to live with this problem. problem in the US, were the WAN link are mostly leased lined, and not ATM VP connections. I am sorry I am posting this comment so late, but I had to re-join the list yesterday, because I apparently got "unsubscribed" last month. By the way, someone asked for a copy of my viewgraphs. What is the best way to make them available ? -- Dario ================================================================ Dario ERCOLE - CSELT S.p.a. Via Reiss Romoli 274, 10148 Torino (Italy) Tel: +39 11 228 5051 - Fax: +39 11 228 5069 e-mail: Dario.Ercole@cselt.stet.it   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07354; 22 Dec 94 13:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07350; 22 Dec 94 13:13 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11363; 22 Dec 94 13:13 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA275384845; Thu, 22 Dec 1994 08:47:25 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA275074836; Thu, 22 Dec 1994 08:47:16 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id LAA00258; Thu, 22 Dec 1994 11:35:59 -0500 Message-Id: <199412221635.LAA00258@curtis.ansremote.com> To: Dario.Ercole@cselt.stet.it Cc: ip-atm@matmos.hpl.hp.com Reply-To: curtis@ans.net Subject: Re: Final minutes, IPATM WG, San Jose Meeting In-Reply-To: Your message of "Thu, 22 Dec 1994 10:56:57 +0100." Date: Thu, 22 Dec 1994 11:34:55 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Dario, Your IETF presentation was very interesting. Thank you for the update on the European efforts. I disagree with your apparent conclusions on the direction IP over ATM should be taking. In message , Dario.Ercole@cselt.stet.it writes: > >Dario Ercole, Interpersonal Mutlimedia Communications over ATM > > > > Shown at Interop '94. Connect Paris with Torino. > > OC3<>OC3<>34mbps<>34mbs. Sun Workstations with SBA200's. > > They discovered that they could not run IP over ATM over a > > public network if they did not perform rate control. This means > > application level rate control and inter-switch rate control. > > The NNI between the switches generated "big packets". > > > > RFC1577 over wide-area? Who is going to provide/specify > > the recommendations for the policing function? > > > > Andy Malis: very much dependent on the type of network the > > traffic is being sent through. Dario agrees. > > > > Ken Hayward: isn't ATM deregulated in Europe? What about > > multiple vendors and solutions? Dario: this topis is not > > network specific. > > > > Consensus is that this is more of an ATM specific issue and > > that IP over ATM will make use of available services. While > > not an issue of this working group's charter, performance of > > ATM does impact performance of IP over ATM. > > > > I think there was also consensus (at least Drew Perking nodded) that ATM > equipment available NOW for ATM LANs and WANs perform *peak-rate* policing > (if any). Maybe in a near future, after the recent ATM Forum decision on > Traffic Management, different and more sofisticated policing schemes will > be implemented by the vendors on their switches. But I do not expect this > to happen before one year; until then people willing to use ATM on both LAN > and WAN will have to live with this problem. Are you suggesting that traffic policing is a solution to IP over ATM performance problems? That notions seems to me to be extremely flawed. Perhaps you mean end-station rate shaping. That would make some sense, however in a world that will not be entirely ATM for a very long time, this is still highly impractical. It is probably not even practical just for Europe. IMO: The problem with your network is that you (probably not you personally) allowed switches with absolutely tiny buffer capacities to be deployed. You will have a low performance backbone until you are able to upgrade these switches. At this point you need to slow down the hosts and border routers by rate shaping just to get things to work at all, but this is not a solution to recommend for new ATM deployments. > problem in the US, were the WAN link are mostly leased lined, and not ATM > VP connections. The problem is that this planet is bigger than Europe and not under one centralized administration that can declare global ATM cutover day and set aside the funding to make it happen all at once. I don't know what the source is, but I was once told that the amount of money spent on regional networks in the US was at least an order of magnitude greater than that spent on backbones, and the amount spent on campus networks (all thos corporate and college ethernets) is well over an order of magnitude greater than the amount spent on regionals, and the cost of end stations still another order of magnitude. This seems very resonable to me. (anyone find this surprising)? This would imply that providing an ATM backbone is only a small part of the conversion to ATM. > I am sorry I am posting this comment so late, but I had to re-join the list > yesterday, because I apparently got "unsubscribed" last month. > > By the way, someone asked for a copy of my viewgraphs. What is the best way > to make them available ? Anon ftp or http. Send the URL to the list. > -- Dario > > ================================================================ > Dario ERCOLE - CSELT S.p.a. > Via Reiss Romoli 274, 10148 Torino (Italy) > Tel: +39 11 228 5051 - Fax: +39 11 228 5069 > e-mail: Dario.Ercole@cselt.stet.it Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13568; 22 Dec 94 19:23 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13564; 22 Dec 94 19:23 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18856; 22 Dec 94 19:23 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA290187700; Thu, 22 Dec 1994 15:08:20 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hpindch.cup.hp.com (hpindtz.cup.hp.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA289887696; Thu, 22 Dec 1994 15:08:17 -0800 Received: by hpindch.cup.hp.com with SMTP (1.37.109.11/15.5+IOS 3.20+cup+OMrelay) id AA208517378; Thu, 22 Dec 1994 15:02:58 -0800 Full-Name: Bob Tausworthe Message-Id: <199412222302.AA208517378@hpindch.cup.hp.com> To: ip-atm@matmos.hpl.hp.com Subject: Pointers to NHRP Date: Thu, 22 Dec 94 15:02:55 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tozz@hpindch.cup.hp.com Could some kind soul point me in the right direction to get more information on NHRP? I realise that it is not a final spec but a work in progress. I also gather that at least part of its purpose is to replace the ARP server in 1577 and solve some of the "single point of failure" issues that 1577 creates with address resolution. Bob Tausworthe Hewlett Packard tozz@cup.hp.com (408) 447-2873   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04506; 23 Dec 94 11:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04500; 23 Dec 94 11:00 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07290; 23 Dec 94 11:00 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA036563435; Fri, 23 Dec 1994 06:37:15 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from maelstrom.acton.timeplex.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA036253430; Fri, 23 Dec 1994 06:37:10 -0800 Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id JAA28224; Fri, 23 Dec 1994 09:38:18 -0500 Received: from maelstrom.timeplex.com (malis@localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id JAA03754; Fri, 23 Dec 1994 09:38:15 -0500 Message-Id: <199412231438.JAA03754@enigma.acton.timeplex.com> To: tozz@hpindch.cup.hp.com Cc: ip-atm@matmos.hpl.hp.com, malis@maelstrom.timeplex.com Subject: Re: Pointers to NHRP In-Reply-To: Your message of "Thu, 22 Dec 1994 15:02:55 PST." <199412222302.AA208517378@hpindch.cup.hp.com> Date: Fri, 23 Dec 1994 09:38:15 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Bob, > Could some kind soul point me in the right direction to get more information > on NHRP? I realise that it is not a final spec but a work in progress. I also > gather that at least part of its purpose is to replace the ARP server in > 1577 and solve some of the "single point of failure" issues that 1577 > creates with address resolution. I would be glad to! The work on NHRP is ongoing in the Routing Over Large Clouds Working Group of the IETF. I just took the liberty of adding you to the mailing list. :-) Anyone else out there reading this that wants to be added, just reply to this message (to me only!!!!) or send a note to rolc-request@maelstrom.timeplex.com (which is me). The current NHRP spec is draft-ietf-rolc-nhrp-03.txt, which was issued just before the San Jose meeting. It is now undergoing revision as a result of that meeting. If you would like to catch up on the WG mail, the list archives can be found via anonymous FTP to ietf.cnri.reston.va.us, in directory /ietf-mail-archive/rolc/. In this directory, the file "rolc.arc" is the archive for all the mail sent to a previous incarnation of the rolc list (which moved in 5/94). The current mail is in the file "current", and is saved in separate files with names like "94-10" on a monthly basis. Also, the working group charter and meeting minutes can be found in the /ietf/rolc/ directory on ietf.cnri.reston.va.us and mirrors, such as ds.internic.net. Both ietf.cnri.reston.va.us and ds.internic.net support gopher access as well as anonymous FTP. I just noticed that the December minutes haven't made it into the server yet, so I'll send them to you in a follow-on message. Regards, Andy Chair, ROLC WG __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08320; 23 Dec 94 14:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08316; 23 Dec 94 14:03 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11337; 23 Dec 94 14:03 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA044285420; Fri, 23 Dec 1994 09:57:00 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from POSTAL.CSELT.STET.IT by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA043975416; Fri, 23 Dec 1994 09:56:56 -0800 Received: from DN-EI3500 by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01HKZERCVUZ40002MF@POSTAL.CSELT.STET.IT>; Fri, 23 Dec 1994 12:42:18 MET Received: from [163.162.7.247] (163.162.7.247) by EI3500.CSELT.STET.IT; Fri, 23 Dec 94 12:38 GMT +1 Date: Fri, 23 Dec 1994 12:44:24 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dario.Ercole@cselt.stet.it Subject: Re: Final minutes, IPATM WG, San Jose Meeting To: curtis@ans.net Cc: ip-atm@matmos.hpl.hp.com Message-Id: X-Envelope-To: ip-atm@matmos.hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT X-Sender: ercole@satchmo.cselt.stet.it At 11:34 22-12-1994, Curtis Villamizar wrote: >Dario, > >Your IETF presentation was very interesting. Thank you for the update >on the European efforts. I disagree with your apparent conclusions on >the direction IP over ATM should be taking. Thanks, Curtis. I was not suggesting that IP over ATM should take any new direction. My concern is: what will happen when users buy ATM sustems that declare themselves RFC1577-compliant, and cannot have them work over an ATM WAN like the one I described ? If this is recognised as a potential problem by the working group (and it seems it is not), it should be pointed out and passed over to someone whose can take care of it (ATM Forum ?). >Are you suggesting that traffic policing is a solution to IP over ATM >performance problems? That notions seems to me to be extremely >flawed. Perhaps you mean end-station rate shaping. That would make >some sense, however in a world that will not be entirely ATM for a >very long time, this is still highly impractical. It is probably not >even practical just for Europe. > I am not suggesting that traffic policing is a solution. I am saying that peak-rate traffic policing can be a problem for the transport of IP over ATM (as any Variable Bit Rate traffic) over an ATM WAN. Policing may not be necessary if the ATM network (local or wide-area) is privately owned. The case is different if the ATM network is public, that is offering a service to a number of paying customer. In this case I believe policing is necessary, because the network must protect itself and the other user from the possible incorrect behaviour of one user. I still believe that peak-rate policing, coupled with small buffers and small Cell Delay Variation Tolerance, is actually a bad way to use the ATM technology. Unfortunately, this is what we have today (in Europe). I know the planet is bigger than Europe, so I was hoping someone could describe similar experiences in other parts of the world (I am sure there are MANY more than in Europe) and tell me if and why and I am wrong. >IMO: The problem with your network is that you (probably not you >personally) allowed switches with absolutely tiny buffer capacities to >be deployed. You will have a low performance backbone until you are >able to upgrade these switches. At this point you need to slow down >the hosts and border routers by rate shaping just to get things to >work at all, but this is not a solution to recommend for new ATM >deployments. I am not in a position to discuss the European ATM Pilot (EAP) and the way it has been implemented. My presentation was not centered on the EAP, so the motivations that led to some of the choices were not described. If someone would like to receive more detailed informations on the EAP, please send e-mail. I do agree that it is not *the* ultimate ATM WAN, but, alas, I am performing experiments over ATM LANs and WANs, and the EAP is the only ATM WAN I can use. -- Dario ================================================================ Dario ERCOLE - CSELT S.p.a. Via Reiss Romoli 274, 10148 Torino (Italy) Tel: +39 11 228 5051 - Fax: +39 11 228 5069 e-mail: Dario.Ercole@cselt.stet.it   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10832; 23 Dec 94 15:58 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13464; 23 Dec 94 15:58 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10811; 23 Dec 94 15:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10782; 23 Dec 94 15:55 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13426; 23 Dec 94 15:55 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10776; 23 Dec 94 15:55 EST To: IETF-Announce: ; cc: ip-atm@hpl.hp.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: IESG Secretary Subject: Last Call: ATM Signaling Support for IP over ATM to Proposed Standard Date: Fri, 23 Dec 94 15:55:46 -0500 X-Orig-Sender: scoya@CNRI.Reston.VA.US Message-ID: <9412231555.aa10776@IETF.CNRI.Reston.VA.US> The IESG has received a request from the IP Over Asynchronous Transfer Mode Working Group to consider "ATM Signaling Support for IP over ATM" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by January 6, 1995. IESG Secretary   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11973; 23 Dec 94 18:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11969; 23 Dec 94 18:25 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15855; 23 Dec 94 18:25 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11960; 23 Dec 94 18:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11956; 23 Dec 94 18:23 EST Received: from linus.mitre.org by CNRI.Reston.VA.US id aa15817; 23 Dec 94 18:23 EST Received: (maybury@localhost) by linus.mitre.org (8.6.7/RCF-6S) id SAA06804; Fri, 23 Dec 1994 18:08:23 -0500 Date: Fri, 23 Dec 1994 18:08:23 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Mark T. Maybury" Message-Id: <199412232308.SAA06804@linus.mitre.org> To: vcl@arch4.ho.att.com, joel@arch4.ho.att.com, sig11@roses.stanford.edu, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-aachen.de, ir-l%uccvma.bitnet@cunyvm.cuny.edu, s-comput%tcsvm.BITNET@cunyvm.cuny.edu, smds@CNRI.Reston.VA.US, iplpdn@CNRI.Reston.VA.US, cip@bbn.com, icad-request@santafe.edu, sigmedia@bellcore.com, sound@acm.org, announcements.chi@xerox.com, tcplw@cray.com, arl@arl1.wustl.edu, ccrc@dworkin.wustl.edu, g-troup@dworkin.wustl.edu, f-troup@aurora.cis.upenn.edu, end2end-interest@venera.isi.edu, atm@bbn.com, rem-conf@es.net, ietf@venera.isi.edu, tccc@cs.umass.edu Subject: Intelligent Multimedia Information Retrieval <> <> <> <> <> <> <> <> <> <> <> <> IJCAI-95 Workshop on INTELLIGENT MULTIMEDIA INFORMATION RETRIEVAL Fourteenth International Joint Conference on Artificial Intelligence (IJCAI-95) Montreal, Canada 1 day during 19th-21st August 1995 (to be determined) BACKGROUND In the past there has been concerted effort, largely performed in independent research communities, addressing the automated processing of single media (e.g., text, imagery, audio). The advent of large, multimedia digital libraries has focused attention on the integrated processing and coordination of multiple media including the traditional focus on textual sources and the increasing emphasis on media with spatial and temporal properties (e.g., sound, maps, graphics, images, video). While there have been focused workshops on integration and coordination of multimedia in interfaces and a national conference on the general subject of multimedia, to date there has been no targeted forum to address processing issues which cross media boundaries but have a fundamental basis in processing human language and artifacts. OBJECTIVES Research in this area is in the formative stages and is just now beginning to address difficult fundamental problems, such as the representation and reasoning about spatial and temporal media. IJCAI-95 presents an opportunity to move toward an integrated view of media processing by addressing a specific technical area: multimedia information retrieval. The language processing, speech processing, image/video processing and spatial/temporal reasoning communities have much to offer and much to learn from one another. The purpose of this workshop is to bring together researchers and practitioners to report on current advances in multimedia information retrieval systems and their underlying theories, to foster scientific interchange among these individuals, and as a group to evaluate current efforts and make recommendations for future investigations. A report on the workshop will be submitted to appropriate magazines (e.g., AI Magazine, IEEE Expert, ACL's FINITE String). An edited collection to include the best papers is planned. ISSUES Submissions (papers and/or video/computer demonstrations) are invited on original research in all aspects of multimedia information retrieval, including, but not limited to: * Content-based analysis and retrieval of multimedia sources (e.g., parsing and integrating text, imagery, maps, audio, video) * Application of speech, language, and image processing methods and techniques to multimedia (e.g., signal analysis, parsing, generation, discourse and user modeling) * Multimedia browsing/visualization tools and cross-media query (e.g, visual, linguistic, and auditory) * Multimedia document/presentation design and display * Tailoring multimedia interaction to particular users, tasks, and contexts * Intra- and inter-media representation languages * Architectures for multimedia information retrieval * Evaluation methods and metrics for multimedia information retrieval * Psychoperceptual and cognitive issues in multimodal information retrieval * Control of user's attention, tension, mood, and sense of continuity by use of appropriate sound, color, and editing * Innovative applications of multimedia information retrieval SUBMISSIONS Interested participants should e-mail (prefered) or forward FIVE copies of a 2,000 to 3,000 word position paper (4-5 pages, double spaced) addressing a specific intelligent multimedia information retrieval issue or reporting novel results to: Mark Maybury, MS-K331, The MITRE Corporation, Bedford, MA 01730 Tel: (617) 271-7230. maybury@mitre.org Submissions must be *received* by February 1, 1994. Please include name, affiliation, address, phone, and e-mail address. Video submissions should be complemented with a written abstract or position paper. Criteria for selection will include clarity, orginality, relevance, and significance of results. Attendance at the workshop will be limited to approximately 30 participants. All participants must register with the main IJCAI conference. The IJCAI WWW home pge is http://ijcai.org/. ORGANIZING COMMITTEE Mark Maybury (chair) The MITRE Corporation, Bedford, MA (maybury@mitre.org) Bill Hefley, Software Engineering Institute, Carnegie Mellon Univ. (weh@sei.cmu.edu) Peter Schauble, Swiss Federal Institute of Technology, Zurich (schauble@inf.ethz.ch) Alex "Sandy" Pentland, MIT Media Lab (sandy@media.mit.edu) Stephen Smoliar, Inst of Systems Science, Univ Singapore, 0511 (smoliar@iss.nus.sg) Oliviero Stock, IRST, Italy (stock@irst.it) Wolfgang Wahlster, DFKI, Germany (wahlster@dfki.uni-sb.de) Kent Wittenburg, Bellcore (kentw@bellcore.com) Kazuo Tanaka, NTT, Japan (tanaka@aether.ntt.JP) Philippe Aigrain, IRIT, France (aigrain@cerise.irit.fr) IJCAI SCHEDULE December 1, 1994 -- Call for participation February 1, 1995 -- Submission deadline February 2, 1995 -- Allocation to reviewers February 30, 1995 -- Notification of acceptance (via e-mail) March 15, 1995 -- Camera-ready workshop paper due April 5, 1995 -- Workshop schedule/participants finalized May 5, 1995 -- Workshop notes due to CRC ???, 1995 -- IJCAI early registration deadline ???, 1995 -- IJCAI late registration deadline August 19, 20, or 21 -- Workshop November 1, 1995 -- Workshop report to Workshops Chair ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09111; 27 Dec 94 18:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09107; 27 Dec 94 18:17 EST Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa07578; 27 Dec 94 18:17 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA022425256; Tue, 27 Dec 1994 13:54:16 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from fore.com (relay.fore.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA022105223; Tue, 27 Dec 1994 13:53:43 -0800 Received: from dolphin (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id QAA14145; Tue, 27 Dec 1994 16:52:35 -0500 Received: from loach.fore.com by dolphin (4.1/SMI-4.1) id AA09797; Tue, 27 Dec 94 16:53:21 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Received: by loach.fore.com (4.1/SMI-4.1) id AA29653; Tue, 27 Dec 94 16:53:18 EST Date: Tue, 27 Dec 94 16:53:18 EST Message-Id: <9412272153.AA29653@loach.fore.com> To: curtis@ans.net, gja@thumper.bellcore.com Subject: Re: updated draft minutes from san jose Cc: laubach@terra.com21.com, ip-atm@matmos.hpl.hp.com Sorry for the delay in responding. I was "particularly irked" :-) by section 3. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > From atmpost@matmos.hpl.hp.com Tue Dec 20 10:52:33 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > To: curtis@ans.net > Cc: Mark Laubach , ip-atm@matmos.hpl.hp.com, > gja@thumper.bellcore.com > Subject: Re: updated draft minutes from san jose > Date: Tue, 20 Dec 1994 10:21:07 -0500 > From: Grenville Armitage > > [..] > >>> Consensus that Grenville's LLC material from the multicast document > >>> should be moved to the Framework document. > >> > >>What portion of Grenville's document was that. Could you give section > >>numbers or page numbers? > > That is probably a good question, but it was not much clearer at the > meeting itself. Perhaps Drew can remember what parts irked him the > most :-) > > I initially interpreted Drew's question on the LLC material to be > about Appendix A (and B?), with Section 3 needing to be trimmed > a little. However, having mulled it over for the last week I'm > still trying to decide if the Framework doc is the right place for > it. My first goal is to split the multicast draft in two - > extracting the 'how to account for the implicit LLC layer in your > designs' parts of the present draft into a separate doc. We can > decide its future from there. > > cheers, > gja >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09305; 27 Dec 94 19:28 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09301; 27 Dec 94 19:28 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08853; 27 Dec 94 19:28 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA026221014; Tue, 27 Dec 1994 15:30:14 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from fore.com (relay.fore.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA025911008; Tue, 27 Dec 1994 15:30:08 -0800 Received: from dolphin (dolphin.fore.com [192.88.243.27]) by fore.com (8.6.9/8.6.5) with SMTP id SAA14291 for ; Tue, 27 Dec 1994 18:29:15 -0500 Received: from loach.fore.com by dolphin (4.1/SMI-4.1) id AA12931; Tue, 27 Dec 94 18:30:00 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Received: by loach.fore.com (4.1/SMI-4.1) id AA29773; Tue, 27 Dec 94 18:29:59 EST Date: Tue, 27 Dec 94 18:29:59 EST Message-Id: <9412272329.AA29773@loach.fore.com> To: ip-atm@matmos.hpl.hp.com Subject: Re: updated draft minutes from san jose > On Tue, 27 Dec 1994, Drew Perkins wrote: > > > Sorry for the delay in responding. I was "particularly irked" :-) by section 3. > > > > Drew In particular, I don't believe that the discussion about LLC entities is approprite for this document. It is another topic altogether and distracts from the issue at hand, i.e. IP multicast. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00925; 28 Dec 94 11:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00920; 28 Dec 94 11:07 EST Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa08858; 28 Dec 94 11:07 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA069896840; Wed, 28 Dec 1994 07:00:41 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA069586836; Wed, 28 Dec 1994 07:00:36 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA19712; Wed, 28 Dec 94 09:58:27 EST Received: from rgc ([199.118.103.103]) by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA27073; Wed, 28 Dec 94 10:00:23 EST Message-Id: Date: Wed, 28 Dec 94 09:57:40 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: framework revisions Reply-To: Robert.G.Cole@att.com To: IP over ATM Cc: "Shur, David" , curtis@ans.net X-Mailer: VersaTerm Link v1.1.3 To all: Based upon various discussions and comments to the group, we are planning on making a number of changes to the framework document, as summarized below: References to internet drafts, documents mailed to the list, and non-publically available docs (e.g., ATM Forum) will be removed and replaced by sentences acknowledging the contributions of the individuals or organizations involved. We will provide a text version (as well as postscript) of the next version of draft (around the end of January). At that time, we will provide both text and Framemaker versions to Curtis to enable him to do HTML conversion (that is, Curtis, if your still up to it at that time). Section 4 will be restructured roughly as follows (we will post new text to this section as soon as we get it worked up): First we will list the main attributes of ATM networks that, when overlayed with IP, and in order to provide standard IP services, require interworking functionality to be provided or particular ATM services to be selected. (Aspects which are not specific to ATM or do not require any specific functionality, e.g., geographical dispersion, number of nodes, whether routers are present, etc, will be listed separately and will not play a major role in the taxonomy). We will then enumerate a few example subnet types corresponding to specific values of the aforementioned attributes. The attributes are: 1)The type of virtual circuits used (i.e., PVCs versus SVCs), where the PVC environment requires the use of either static tables for ATM to IP address mapping, or the use of inverse ARP, while the SVC environment requires ARP server functionality. 2)The number and type of ATM administrative domains/networks. In particular, in the single domain/network case, all attached systems may be safely assumed to be using a single common addressing format, while in the multiple domain case, attached stations may not all be using the same common format, with corresponding implications on address resolution. Also security/authentication is much more of a concern in the multiple domain case. 3)The type of support for multicast services. If point-to-point services only are available, then a multicast server is required. If point-to-multipoint services are available, then multicast can be supported via meshes of point-to-multipoint connections (although use of a server may be necessary due to limits on the number of multipoint VCs able to be supported). 4)The presence of logical link identifiers (VPI/VCIs) which enable binding between virtual circuits and higher level entities in the TCP/IP protocol stack instead of LLC/SNAP end-points , only. (E.g., single VC per protocol binding, TULIP, TUNIC). 5)The nature of the services provided (Adapatation layer types, Quality-of-service, connection-mode, etc.). (Most models discussed by the group assume AAL5 with best effort service). We would then present some example subnet models (not discussed by this working group), for example an SVC LAN over an ATM internet(multiple ADs) where multiple ATM address formats are possible which complicate ARP responses (see appendix), or an ATM clns subnet (essentially IP over SMDS). Finally we would end section 4 by giving a preface to the end-to-end models by pointing out that there are several other emerging attributes of ATM networking that are encouraging development of multiple end-to-end models (ranging from traditional "classical IP", to ROLC "NHRP" preserving routing control but short cutting transport, to peer models). These are 1) a belief of ubiquitous ATM deployment supporting the direct interconnection of large numbers of hosts, and 2) the development of an "internet" style routing capability. The first has revised discussion of methods to "short cut" multiple IP hops accross a single ATM network, i.e., ROLC "NHRP" models, and the second is encouraging the discussion of "peer"models, which place ATM routing and IP level routing on an equal footing. These are discussed in Section 6. Section 5 will follow pretty much the current structure - where we describe the various end-to-end models, including Overlay (Classical IP over ATM), Ohta, ROLC, Integrated (we will call this out explicitly now), and Peer. P. S. We will cover the bit about LLC/SNAP entities invoking ATM in attribute 4 in section 4 above, along with per VC, TUNIC and TULIP multiplexing as well. Any comments? Thanks, Bob and Dave Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01091; 28 Dec 94 11:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01087; 28 Dec 94 11:27 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09330; 28 Dec 94 11:27 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA070687239; Wed, 28 Dec 1994 07:07:19 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ftp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA070377228; Wed, 28 Dec 1994 07:07:08 -0800 Received: from ftp.com by ftp.com ; Wed, 28 Dec 1994 10:06:59 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 28 Dec 1994 10:06:59 -0500 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA26414; Wed, 28 Dec 94 10:06:03 EST Date: Wed, 28 Dec 94 10:06:03 EST Message-Id: <9412281506.AA26414@mailserv-D.ftp.com> To: laubach@terra.com21.com Subject: RFC Submission . . . . Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev@ftp.com Cc: stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net Repository: mailserv-D.ftp.com, [message accepted at Wed Dec 28 10:05:54 1994] Originating-Client: d-cell.ftp.com Content-Length: 15721 the RFC editor recieved this, and has officially passed it on to you folks for your consideration . . . . . From: jkrey@isi.edu To: iesg@isi.edu Subject: Informational RFC-Transmitting IP over ATM AAL5 using DXI protocol Cc: rfc-editor@isi.edu, ahnidi@mci.net IESG: The RFC Editor has received the following Informational RFC submission, "Transmitting IP over ATM AAL5 using DXI protocol". The RFC Editor is sending it on to the IESG for Working Group review. Joyce and --jon. =============================================== Date: Tue, 27 Dec 1994 15:43:07 -0500 From: Abir Hnidi To: rfc-editor@ISI.EDU Subject: Informational RFC Cc: ahnidi@mci.net Below is an informational RFC that I am submitting to be considered for publishing to the Internet community. Please let me know if you have any questions, or need any further information. Abir Hnidi InternetMCI Engineering IP Development Group Tel: 703-715-7152 Email: ahnidi@mci.net Network Working Group Abir Hnidi Request for Comments MCI Category: Informational December 1994 Transmitting IP over ATM AAL5 using DXI protocol Status of this Memo: This memo provides information for the Internet community about how Data Exchange Interface protocol (DXI) is used to transmit IP over ATM AAL5. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract: This document describes Data Exchange Interface Protocol (DXI), and how it is used to transmit IP traffic over ATM AAL5 ( Adaption ATM level 5). Also, it discusses the ATM DXI frame format for both ATM DXI mode 1 and mode2 and explains how DXI LMI can be implemented in order to provide network management information. 1. ATM Cell Format: The ATM protocol stack consists of three layers, AAL (Adaption ATM layer), ATM (Asynchronous Tansfer Mode layer), and Physical layer. The ATM network architecture looks like the following: DTE DTE ----- ----- | AAL | | AAL | ----- ----- ----- ----- | ATM | | ATM | | ATM | | ATM | ----- --- ----- --- ----- --- ----- | PHY | | PHY | | PHY | | PHY | ----- ----- ----- ----- UNI B-ISSI UNI ATM Network Where: UNI: User-Network-Interface B-ISSI: BraodBand-Inter-Switching System Interface UNI defines the specifications of connecting a CPE to an ATM switch. B-ISSI specifies how two ATM switches, within the same network, are interconnected. Whereas, NNI (Node-Network-Interface) specifies the standards of connecting two ATM networks together. The ATM cell format of UNI interface is shown below: 8 7 6 5 4 3 2 1 ---------------------- | GFC | VPI | ---------------------- | VPI | VCI | ---------------------- | VCI | ---------------------- | VCI | PT |CLP| ---------------------- | HEC | ---------------------- | | = Payload = | 48 Octets | ---------------------- Where: GFC: Generic Flow Control: 4 bit field that provides local functions such as flow control. VPI: Virtual Path Identifier: 8 bit field that identifies the virtual path across an ATM switch. VCI: Virtual Circuit Identifier: 16 bit field that identifies the virtual circuit across an ATM switch. PT: Payload Type: 3 bit field that identifies the type of information the cell carries, such as user data W/Out congestion, Operation and Administration information (OAM). CLP: Cell Loss Priority: 1 bit that is used to implement taffic policing scheme where, upon exceeding the agreed on data rate, each cell has this bit set to 1, so that it is discarded when congestion occurs. HEC: Header Error Check: 8 bit field that is used to detect any errors occured in the cell header ( For example, Corrupted bits in the VPI/VCI fields). The ATM cell format for Network-Node-Interface is as follows: 8 7 6 5 4 3 2 1 ---------------------- | VPI | ---------------------- | VPI | VCI | ---------------------- | VCI | ---------------------- | VCI | PT |CLP| ---------------------- | HEC | ---------------------- | | = Payload = | 48 Octets | ---------------------- The NNI cell format is almost identical to UNI cell format. The only difference is that the GFC field is replaced by four additional bits for VPI. This would allow an ATM switch to have up to 2.68e+08 virtual paths compared to 1.67e+07 in the UNI case. 2. ATM Protocol Stack: As it was mentioned before, the ATM architecture consists of three layers, AAL, ATM and Physical layers. The AAL, Adaption ATM Layer, consists of two sublayers, Convergence sublayer (CS), and Segmentation And Reassembly sublayer (SAR). The Convergence Sublayer performs functions required by the AAL type, and it is divided into two parts, CPCS (Common Part Convergence Sublayer) and SSCS (Service Specific Convergence Sublayer). Whereas, the SAR sublayer is responsible for segmenting higher level SDUs (Servcie Data Unit) into 48 Octet cells. Also, at the other end, it is responsible for reassembling the cells into an SDU before it passes it up to a higher layer. The ATM layer builds the 53 Octet cell by adding a 5 octet header to each cell. Then, it multiplexes the cells into a constant cell stream before it passes it down to the Physical layer. The Physical layer consists of two sublayers, Transmission Convergence (TC) and Physical Medium (PM) sublayers. TC sublayer is responsible for frame adaption and generation, cell delineation, HEC generation and cell rate decoupling. PM sublayer is a medium specific that adopts the ATM cells to different data frame formats depending on the physical medium. The ATM layers are summarized in the figure below: --------------------- | CPCS | |.....................| AAL Layer | SSCS | --------------------- | ATM | ATM Layer --------------------- | TC | |.....................| Physical Layer | PM | --------------------- 3. AAL Classes of Service: Several classes of service have been defined to cover all different applications that are/will be supported by ATM protocol (Audio, Video Connectionless, and Connection-Oriented). The different classes of service are Class A or CBR (Constant Bit Rate), Class B or VBR (Variable Bit Rate), Class C or UBR (Unspecified Bit Rate), Class D or VBR with no timing information, and finally ABR Class (Available Bit Rate). CBR or Class A supports real time applications that contain video or audio information and that are carried over fixed rate circuits. AAL1 fits in this class. VBR or class B supports real time applications with variable source rate and timing relationship between the source and the destination. AAL2 fits in this group. UBR or Class c supports applications that do not utilize CBR efficiently, where real time delay is not an issue, however loss is such as TCP/IP protocol. AAL5 fits in this group. VBR with no timing information or class D is very similar to VBR but with no timing relationship between the source and the destination. This is suitable for data protocols that are sensitive to loss but not delay such as SMDS. AAL3/4 fits in this group. Finally, ABR is another class that is currently being defined to support non real-time applications where QoS (Quality Of Servcie) can be improved by adding fairness and control of loss and delay. 4. ATM DXI Protocol: The ATM DXI protocol has been defined to allow a DTE (Router) and a DCE (ATM DSU) to co-operate to provide a User-Network Interface to an ATM switch, as it is shown below: --------- ------ ------------ | Router |----| ADSU |---------| ATM Switch | --------- ------ ------------ DXI UNI The DTE encapsulates a higher layer SDU into DXI frame which supports up to 65526 octet long SDU. The encapsulation method is covered in details in RFC 1490. The DTE passes the DXI frame through the DXI physical level to an ADSU (Physical layer uses V35, EIA/TIA 449/530, or EIA/TIA 612/613 HSSI Interface). The ADSU receives the DXI frame, strips off the DXI header and trailer, and encapsulates the DTE-SDU in AAL5 CPCS-PDU. Then, the ADSU performs both the SAR and the ATM layer functions before it sends the cells out across the UNI connection to the ATM switch. The whole process is explained in the figure below: ------- --------------- | SDU | | DTE SDU | ------- --------------- | | | | CPCS | | DXI | | DXI |.......| | DLK | | DLK | SAR | | | | |-------| --------- | | | | ATM | | ATM | ------- --------------- --------- |DXI PHY|-----|DXI PHY|UNI PHY|---------| ATM PHY | ------- --------------- --------- DTE DXI DCE (ADSU) UNI ATM Switch 5. ATM DXI Frame Format: The DXI frame level (Data Link Level) was derived from HDLC protocol where three mode of operations were defined: * Mode 1A: AAL5 only * Mode 1B: AAL3/4 for at least one VC. AAL5 for other VCs. * Mode 2 : AAL5 and AAL3/4, one per VC. The format of the frame sent between the DTE and the DCE (ADSU) varies depending on the AAL it uses. However, only AAL5 format is discussed in this memo. The DXI frame format for Mode 1A and Mode 1B using AAL5 is shown below: 8b 16 bits 0 =< n = < 9232 Oct 16/32b 8b ----------------------------------------------------- | F | DXI Header | DTE-SDU | DXI FCS | F | ----------------------------------------------------- / \ / \ ---------------------------------------------------- | DFA | RS | 0 | DFA |CN|RS|CLP| 1 | ---------------------------------------------------- 6 bits 1b 1b 4 bits 1b 1b 1b 1b Where: DFA: DXI Frame Address CN: Congestion Notification Bit CLP: Cell Loss Priority Bit RS: Reserved. The DXI frame format for Mode 2 using AAL5 is shown below: 8b 32 bits 0 =< n = < 9232 Octs 16/32b 8b ----------------------------------------------------- | F | DXI Header | DTE-SDU | DXI FCS | F | ----------------------------------------------------- / \ / \ ----------------------------------------------------------- | DFA | RS | 0 | DFA |CN|RS|CLP| 1 | DFA | ----------------------------------------------------------- 6 bits 1b 1b 4 bits 1b 1b 1b 1b 16 bits 6. Mapping Mode 1 DXI DFA to VPI/VCI: The DTE interface sends the DXI frame to the DCE (ADSU). The ADSU, based on the DFA address in the DXI frame, maps the DFA address to VPI/VCI values that are inserted in the cell header before it is sent out to the ATM switch. The mapping between DXI DFA and VPI/VCI is explained by the example below: Suppose that a DXI DFA address of 524. This is mapped by the ADSU into VPI/VCI of 0/44 as follows: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 524 = 1 0 0 0 0 0 1 1 0 0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ---------------------------------------------------- |1 0 0 0 0 0 | RS | 0 |1 1 0 0|CN|RS|CLP| 1 | DXI Frame ---------------------------------------------------- 6 bits 1b 1b 4 bits 1b 1b 1b 1b b2 b3 b4 b5 b0 b1 b6 b7 b8 b9 ---------------------------------------------------- | ....|0 0 0 0 |....| 1 0 1 1 0 0 | ........ | ATM Cell ---------------------------------------------------- <-----------------><----------------------> VPI = 0 VCI = 44 7. DXI ILMI (Interim Local Management Interface): The ATM forum has developed the Interim Local Management Interface (ILMI) to address the management functions of ATM interfaces. MIBII modules have been defined for the following functions: * ATM Interface Confirmation Group * ATM Interface DS3 PLCP Group * ATM Interface TC Sublayer Group * ATM Interface Virtual Link (VPL/VCL) Configuration Group. * ATM VP/VC Cross Connect Group * AAL5 Connection Performance Statistics Group Details of the functionality of these groups are covered in RFC1695 The use of ATM DXI LMI is explained in the figure below: ILMI Messages <-------------------------------> ATM LMI ------- ------- -------- | DTE |---| DCE |-----------------| ATM | ------- DXI ------- UNI -------- | | SNMP Messages ------- | NMS | ------- The MIB (Management Information Base) defined by ILMI provides status and confirmation information from an UME (UNI Management Entity) that resides in an ATM switch regarding its UNI. The ATM switch sends ILMI messages to the DTE requesting information on a VPI/VCI (VPI/VCI 0/16 is reserved for ILMI messages). Also, the DTE (Router) might request some information reagrding statistics (such as cells dropped/lost), and therefore, it sends DXI LMI messages to its DCE (ADSU). The DXI LMI supports NMS using SNMP, however, in order to support ILMI, the DTE (Router) must have both an SNMP agent and an ILMI proxy agent. The format of the DXI LMI frame that is sent between the DTE and the DCE is as follows ----------------------------------------------------- | F | DXI Header | LMI PDU | DXI FCS | F | ----------------------------------------------------- The LMI PDU (Protocol Data Unit) specifies the LMI message used. The following ILMI messages have been defined so far in the ATM DXI 1.0 specifications: * GetRequest * GetNextRequest * SetRequest * GetResponse 8. Security Considerations: Security Considerations are not discussed in this document. 9. References: [1] ATM Forum, ATM DXI Specifications, version 1.0 August 1993 [2] Managing ATM-Based BroadBand Networks Stephen Farkouh, IEEE Communications Magazine, May 1993 [3] ATM Forum, ATM User-Network Interface Specifications Prentice-Hall 1993 [4] ATM Service Architecture, From Applications to Scheduling Mark Garrett, Bellcore, September 1994 [5] Definitions of Managed Objects for ATM Management, Version 8.0 Using SMIv2 RFC1695, M.Ahmed, K. Tesnik, August 1994 [6] Multiprotocol Interconnect Over Frame Relay RFC 1490, T. Bradley, C. Brown, A. Malis. July 1993. [7] Analyzing BroadBand Networks Mark A. Miller, 1994 Author's address: Abir Hnidi MCI 2100 Reston Parkway Reston, VA 22091 Email: ahnidi@mci.net   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01533; 28 Dec 94 12:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01529; 28 Dec 94 12:22 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00804; 28 Dec 94 12:22 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA073010444; Wed, 28 Dec 1994 08:00:44 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA072700436; Wed, 28 Dec 1994 08:00:36 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id LAA20324; Wed, 28 Dec 1994 11:00:20 -0500 Message-Id: <199412281600.LAA20324@thumper.bellcore.com> To: Robert.G.Cole@att.com Cc: IP over ATM , "Shur,\ David" , curtis@ans.net, gja@thumper.bellcore.com Subject: Re: framework revisions In-Reply-To: Your message of Wed, 28 Dec 1994 09:57:40 -0800. Date: Wed, 28 Dec 1994 11:00:18 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage [..] >>4)The presence of logical link identifiers (VPI/VCIs) which enable >>binding between virtual circuits and higher level entities in the >>TCP/IP protocol stack instead of LLC/SNAP end-points , only. >>(E.g., single VC per protocol binding, TULIP, TUNIC). Maybe I'm being a little too jumpy, but I sure hope you don't phrase it like this. The "presence of logical link identifiers (VPI/VCIs)" is common to _all_ IP over ATM mechanisms, and shouldn't be called out as some nifty gadget that enables TULIP, etc. The real point is that various IE encodings within UNI 3.1 allow a VC originator to specify a range of 'layer X' entities as the destination "AAL User", and that the AAL specs don't prohibit any particular layer X from attaching directly to a local AAL service. Taken together these points mean LLC/SNAP encapsulation is just (the default) one of a range of methods. [..] >>Any comments? Just one more - will you be explicitly 'flagging' the association between existing RFCs and some the models/reasons you'll be describing? I would like the Framework doc to help newcomers understand the existing ip-atm WG docs in addition to providing a general overview. cheers, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01807; 28 Dec 94 12:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01803; 28 Dec 94 12:50 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01469; 28 Dec 94 12:50 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA074431992; Wed, 28 Dec 1994 08:26:32 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA074121989; Wed, 28 Dec 1994 08:26:29 -0800 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA11841 for ip-atm@matmos.hpl.hp.com; Wed, 28 Dec 94 11:24:27 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA21095; Wed, 28 Dec 1994 08:22:20 -0800 Message-Id: <199412281622.IAA21095@aland.bbn.com> To: stev@ftp.com Cc: laubach@terra.com21.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net Subject: Re: RFC Submission . . . . In-Reply-To: Your message of Wed, 28 Dec 94 10:06:03 -0500. <9412281506.AA26414@mailserv-D.ftp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 28 Dec 94 08:22:15 -0800 Hi Stev (et al.) I read the RFC and had a few comments. I think sections 1 through 3 are superfluous (they are simply a compressed intro to ATM and an RFC can assume a technical background by its reader). I also noted that protocol doesn't use the IP over AAL5 ATM standard but rather uses Frame Relay Encapsulation, and thus should properly be entitled "Transmitting Frame Relay over ATM using DXI Protocol." Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02563; 28 Dec 94 14:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02559; 28 Dec 94 14:46 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04010; 28 Dec 94 14:46 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA078749209; Wed, 28 Dec 1994 10:26:49 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA078439191; Wed, 28 Dec 1994 10:26:31 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id KAA01253; Wed, 28 Dec 1994 10:06:47 -0800 Date: Wed, 28 Dec 1994 10:06:47 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: stev@ftp.com Cc: stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, craig@aland.bbn.com Subject: Re: RFC Submission . . . . In-Reply-To: <9412281506.AA26414@mailserv-D.ftp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Stev, Craig, et al., I agree with Craig's comments. The ATM NAP community is working in the IP/AAL5/DXI topic area. It would be most helpful to see some comments from them on this draft. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02967; 28 Dec 94 15:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02963; 28 Dec 94 15:32 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05009; 28 Dec 94 15:31 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA081671566; Wed, 28 Dec 1994 11:06:06 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ftp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA081361563; Wed, 28 Dec 1994 11:06:03 -0800 Received: from ftp.com by ftp.com ; Wed, 28 Dec 1994 14:05:55 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 28 Dec 1994 14:05:55 -0500 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29570; Wed, 28 Dec 94 14:04:58 EST Date: Wed, 28 Dec 94 14:04:58 EST Message-Id: <9412281904.AA29570@mailserv-D.ftp.com> To: laubach@terra.com21.com Subject: Re: RFC Submission . . . . Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev@ftp.com Cc: stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, craig@aland.bbn.com Repository: mailserv-D.ftp.com, [message accepted at Wed Dec 28 14:04:50 1994] Originating-Client: d-cell.ftp.com Content-Length: 348 The ATM NAP community is working in the IP/AAL5/DXI topic area. It would be most helpful to see some comments from them on this draft. while this may be useful, it is beyond my purview. if you woudl like to solicite their comments and either report back, or have them mail them in themselves, that woudl be fine with me.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03001; 28 Dec 94 15:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02997; 28 Dec 94 15:38 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05157; 28 Dec 94 15:38 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA079489879; Wed, 28 Dec 1994 10:37:59 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA079179872; Wed, 28 Dec 1994 10:37:52 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id NAA02123; Wed, 28 Dec 1994 13:35:33 -0500 Message-Id: <199412281835.NAA02123@curtis.ansremote.com> To: Robert.G.Cole@att.com Cc: IP over ATM , "Shur,\ David" , curtis@ans.net Reply-To: curtis@ans.net Subject: Re: framework revisions In-Reply-To: Your message of "Wed, 28 Dec 1994 09:57:40 PST." Date: Wed, 28 Dec 1994 13:34:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , "Robert G. Cole" writes: > > We will provide a text version (as well as postscript) of the next > version of draft (around the end of January). At that time, we will > provide both text and Framemaker versions to Curtis to enable him to > do HTML conversion (that is, Curtis, if your still up to it at that time). Yes. It seems you still want to keep the source in Frame. Please make separate EPS files of the diagrams. I think Frame can do that. Thanks. > Section 4 will be restructured roughly as follows (we will post new text to > this section as soon as we get it worked up): > > First we will list the main attributes of ATM networks that, when > overlayed with IP, and in order to provide standard IP services, > require interworking functionality to be provided or particular ATM > services to be selected. (Aspects which are not specific to ATM or do > not require any specific functionality, e.g., geographical dispersion, > number of nodes, whether routers are present, etc, will be listed > separately and will not play a major role in the taxonomy). We will > then enumerate a few example subnet types corresponding to specific > values of the aforementioned attributes. Geographical dispersion simply distinguishes a WAN from a LAN. Unless you consider beaurocratic complexity to be the distinguishing feature of a WAN. ;-) Number of nodes determines whether scaling has to be a major consideration. Whether multihomed routers a present has a major impact on the feasibility of certain models such as NHRP and the ATMF Integrated proposal and TULIP/TUNIC. > The attributes are: > > 1)The type of virtual circuits used (i.e., PVCs versus SVCs), where the > PVC environment requires the use of either static tables for ATM to IP > address mapping, or the use of inverse ARP, while the SVC environment > requires ARP server functionality. > > 2)The number and type of ATM administrative domains/networks. In > particular, in the single domain/network case, all attached systems > may be safely assumed to be using a single common addressing format, > while in the multiple domain case, attached stations may not all be > using the same common format, with corresponding implications on > address resolution. Also security/authentication is much more of a > concern in the multiple domain case. > > 3)The type of support for multicast services. If point-to-point services > only are available, then a multicast server is required. If > point-to-multipoint services are available, then multicast can be > supported via meshes of point-to-multipoint connections (although use > of a server may be necessary due to limits on the number of multipoint > VCs able to be supported). > > 4)The presence of logical link identifiers (VPI/VCIs) which enable > binding between virtual circuits and higher level entities in the > TCP/IP protocol stack instead of LLC/SNAP end-points , only. > (E.g., single VC per protocol binding, TULIP, TUNIC). Your sentence doesn't make sense to me. VPI/VCIs are always present. TULIP/TUNIC can always be used if SVCs are supported. There are just some scaling efficiency (and therefore maybe feasibility) issues associated with high numbers of VCIs and high connection setup rates. There is also a feasibility issue > 5)The nature of the services provided (Adapatation layer types, > Quality-of-service, connection-mode, etc.). (Most models discussed by > the group assume AAL5 with best effort service). > > We would then present some example subnet models (not discussed by this > working group), for example an SVC LAN over > an ATM internet(multiple ADs) where multiple ATM address formats are possible > which complicate ARP responses (see appendix), or an ATM clns subnet > (essentially IP over SMDS). A LAN over an internet? Are you talking about bridging and tunnelling? If so, I fail to see how this is an IP over ATM topic. You can do bridging and tunnelling over anything that supports IP and sure you can do it over non-IP as well. A LAN implies geographic locality or in the bridging world implies the appearance of a single legacy LAN media segment which for IP implies a single LIS. An internet implies multiple LIS. Maybe I should stop guessing at what you meant by this and let you tell me. Isn't an ATM CLNS the "Convential Model" which was already discussed? I don't recall it getting much support. Just what we need. More models. :-( > Finally we would end section 4 by giving a preface to the end-to-end models b > y > pointing out that there are several other emerging > attributes of ATM networking that are encouraging development of > multiple end-to-end models (ranging from traditional "classical IP", > to ROLC "NHRP" preserving routing control but short cutting transport, > to peer models). These are 1) a belief of ubiquitous > ATM deployment supporting the direct interconnection of large > numbers of hosts, and 2) the development of an "internet" style routing > capability. The first has revised discussion of methods to "short > cut" multiple IP hops accross a single ATM network, i.e., ROLC "NHRP" > models, and the second is encouraging the discussion of "peer"models, > which place ATM routing and IP level routing on an equal footing. These > are discussed in Section 6. There is an apparent discrepency in two of your statements above. First you say "there are several other emerging attributes". Then you say "These are 1) a belief". I think you are far more accurate the second time. I don't think a belief is well described as "an emerging attribute". I would like to see it made clear that there is no evidence to lead to a conclusion that there will be ubiquitous ATM in the near future (in this decade at least) and that the absense of ubiquitous ATM result in feasibility problems with some models. > Section 5 will follow pretty much the current structure - where we > describe the various end-to-end models, including Overlay (Classical > IP over ATM), Ohta, ROLC, Integrated (we will call this out explicitly now), > and Peer. Your CNLS (IP over SMDS) probably belongs here. Please explain how it differs from Convential (Ohta). Your other SVC LAN over multiple AD internet might belong here depending on what it means. > P. S. We will cover the bit about LLC/SNAP entities invoking ATM in > attribute 4 in section 4 above, along with per VC, TUNIC and TULIP > multiplexing as well. Encapsulation is almost orthogonal everything else in section 4. I think it deserves its own section entitled "Encapsulation". The choices are LLC/SNAP, null, TUNIC and TULIP, (although you could roll another if you wanted to further confuse the industry). > Any comments? Sounds encouraging, though it seems we are going to have to go through at least another iteration before we are done reorganizing the document. I think adding the LAN over internet and the CNLS thing is a real bad idea and would approeciate it if you would not do it. > Thanks, > > > Bob and Dave Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03320; 28 Dec 94 16:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03316; 28 Dec 94 16:41 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06761; 28 Dec 94 16:41 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA085045379; Wed, 28 Dec 1994 12:09:39 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA084735375; Wed, 28 Dec 1994 12:09:35 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id OAA02191; Wed, 28 Dec 1994 14:14:25 -0500 Message-Id: <199412281914.OAA02191@curtis.ansremote.com> To: Craig Partridge Cc: stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@ns.mci.net Reply-To: curtis@ans.net Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Wed, 28 Dec 1994 08:22:15 PST." <199412281622.IAA21095@aland.bbn.com> Date: Wed, 28 Dec 1994 14:12:10 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <199412281622.IAA21095@aland.bbn.com>, Craig Partridge writes: > > Hi Stev (et al.) > > I read the RFC and had a few comments. > > I think sections 1 through 3 are superfluous (they are simply a compresse > d > intro to ATM and an RFC can assume a technical background by its reader). > > I also noted that protocol doesn't use the IP over AAL5 ATM standard but > rather uses Frame Relay Encapsulation, and thus should properly be entitled > "Transmitting Frame Relay over ATM using DXI Protocol." > > Craig Craig, It's really IP over FR over AAL5 using DXI. It happens to be a component of the temporary kludge being used at the ATM NAPs due to lack of anything else that could give us the end result we needed 9which was an ATM LIS with end points on the LIS running BGP4 and capable of carrying IP traffic loads between major IP providers). In less than 6 months it should be replaced by IP over LLC/SNAP over AAL5 ala RFC1483. Maybe we don't even want to document this temporary situation and possibly encourage vendors to go down a dead end path. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03366; 28 Dec 94 16:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03362; 28 Dec 94 16:44 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06837; 28 Dec 94 16:44 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA085775797; Wed, 28 Dec 1994 12:16:37 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from maelstrom.acton.timeplex.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA085455779; Wed, 28 Dec 1994 12:16:19 -0800 Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id PAA00805; Wed, 28 Dec 1994 15:16:22 -0500 Received: from maelstrom.timeplex.com (malis@localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id PAA08501; Wed, 28 Dec 1994 15:16:21 -0500 Message-Id: <199412282016.PAA08501@enigma.acton.timeplex.com> To: Craig Partridge Cc: stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, malis@maelstrom.timeplex.com Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Wed, 28 Dec 1994 08:22:15 PST." <199412281622.IAA21095@aland.bbn.com> Date: Wed, 28 Dec 1994 15:16:20 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Craig, > I read the RFC and had a few comments. As do I .... > I think sections 1 through 3 are superfluous (they are simply a > compressed intro to ATM and an RFC can assume a technical background > by its reader). I agree. > I also noted that protocol doesn't use the IP over AAL5 ATM standard but > rather uses Frame Relay Encapsulation, and thus should properly be entitled > "Transmitting Frame Relay over ATM using DXI Protocol." Here I don't agree. Rather, the RFC builds upon the intent of the ATM Forum DXI interface and documents existing practice. The intent of the DXI interface (especially mode 1) is to allow frame-based access to ATM, with no additional development, by existing FR DTEs [especially routers]. This is discussed on p. 9 of the DXI spec. Because the DTEs use existing FR interface code, they also use RFC 1490 encapsulation. This is discussed in Appendix A of RFC 1483. The relevance of this RFC to the Internet community is that it documents the interface at the ATM NAPs between the routers and the ATM switches. It's also much easier to read than the actual DXI spec. I have a separate comment on section 5 of the RFC for the author. I believe the description of the Mode 2 frame format is incomplete, because Mode 2 always uses the AAL 3/4 CPCS_PDU header and trailer, even when the DTE SDU is sent over the ATM network using AAL5. See Figures 2.4 and 2.10 in the DXI spec. I would advise Abir to either expand the Mode 2 discussion or remove it entirely - I'm not aware of its use in practice. I also notice that Mode 2 wasn't included in section 6, so again, either section 6 should be expanded to include Mode 2, or it Mode 2 should just be removed completely from the document. [Here's where I get to hear from everyone who's implemented or is using Mode 2]. Mark wrote: > The ATM NAP community is working in the IP/AAL5/DXI topic area. It > would be most helpful to see some comments from them on this draft. I would be interested in seeing their comments as well. Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04138; 28 Dec 94 17:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04134; 28 Dec 94 17:46 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08261; 28 Dec 94 17:46 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA088179869; Wed, 28 Dec 1994 13:24:29 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA087869860; Wed, 28 Dec 1994 13:24:20 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id PAA02945; Wed, 28 Dec 1994 15:51:07 -0500 Message-Id: <199412282051.PAA02945@curtis.ansremote.com> To: Mark Laubach Cc: stev@ftp.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@ns.mci.net, craig@aland.bbn.com Reply-To: curtis@ans.net Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Wed, 28 Dec 1994 10:06:47 PST." Date: Wed, 28 Dec 1994 15:49:45 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , Mark Laub ach writes: > > Stev, Craig, et al., > > I agree with Craig's comments. > > The ATM NAP community is working in the IP/AAL5/DXI topic area. It would > be most helpful to see some comments from them on this draft. > > Mark Mark, Was that "topic area" or "toxic area"? :-) btw - Abir Hnidi is the MCInet "NAP person". Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04524; 28 Dec 94 19:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04520; 28 Dec 94 19:17 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09884; 28 Dec 94 19:17 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA091094547; Wed, 28 Dec 1994 14:42:28 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA090784542; Wed, 28 Dec 1994 14:42:22 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id OAA03303; Wed, 28 Dec 1994 14:21:26 -0800 Date: Wed, 28 Dec 1994 14:21:26 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Curtis Villamizar Cc: Craig Partridge , stev@ftp.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@ns.mci.net Subject: Re: RFC Submission . . . . In-Reply-To: <199412281914.OAA02191@curtis.ansremote.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 28 Dec 1994, Curtis Villamizar wrote: > ... In less than 6 months it should be replaced by IP over LLC/SNAP over > AAL5 ala RFC1483. Maybe we don't even want to document this temporary > situation and possibly encourage vendors to go down a dead end path. Would it not be a better idea for this informational RFC to document the transition plan, rather than just today's starting point? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08108; 28 Dec 94 23:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08104; 28 Dec 94 23:16 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14237; 28 Dec 94 23:16 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA100930725; Wed, 28 Dec 1994 19:12:05 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA100620720; Wed, 28 Dec 1994 19:12:00 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id WAA06436; Wed, 28 Dec 1994 22:09:17 -0500 Message-Id: <199412290309.WAA06436@thumper.bellcore.com> To: curtis@ans.net Cc: Robert.G.Cole@att.com, IP over ATM , "Shur, David" , gja@thumper.bellcore.com Subject: Re: framework revisions In-Reply-To: Your message of Wed, 28 Dec 1994 13:34:33 -0500. <199412281835.NAA02123@curtis.ansremote.com> Date: Wed, 28 Dec 1994 22:09:16 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage [..] >>> P. S. We will cover the bit about LLC/SNAP entities invoking ATM in >>> attribute 4 in section 4 above, along with per VC, TUNIC and TULIP >>> multiplexing as well. >> >>Encapsulation is almost orthogonal everything else in section 4. I >>think it deserves its own section entitled "Encapsulation". Consider me a supporter of this point (me? biassed?). I currently have some text and diagrams on the encapsulation issue that could constitute a stand-alone section with a little massage (MSWord format at the moment). Hassle me later next week. gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01729; 29 Dec 94 9:24 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01725; 29 Dec 94 9:24 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06643; 29 Dec 94 9:24 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA133907189; Thu, 29 Dec 1994 05:19:49 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA133597186; Thu, 29 Dec 1994 05:19:46 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA16035; Thu, 29 Dec 94 08:17:35 EST Received: from rgc-ddd.ho.att.com by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA29081; Thu, 29 Dec 94 08:19:27 EST Message-Id: Date: Thu, 29 Dec 94 08:16:43 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: Re: framework revisions To: Grenville Armitage Cc: IP over ATM , "Shur, David" , curtis@ans.net X-Mailer: VersaTerm Link v1.1.3 Grenville, > [..] >>>4)The presence of logical link identifiers (VPI/VCIs) which enable >>>binding between virtual circuits and higher level entities in the >>>TCP/IP protocol stack instead of LLC/SNAP end-points , only. >>>(E.g., single VC per protocol binding, TULIP, TUNIC). > >Maybe I'm being a little too jumpy, but I sure hope you don't phrase >it like this. The "presence of logical link identifiers (VPI/VCIs)" is >common to _all_ IP over ATM mechanisms, and shouldn't be called out >as some nifty gadget that enables TULIP, etc. The real point is that Although common to most ATM mechanisms (but not all, e.g., IP over clns or smds or whatever the appropriate reference), it is not common to all subnets, e.g., IP over ethernet, TR, FDDI, etc. The discussion in this "introductory" section is to point out attributes of atm which allow for different IP ATM interactions or models. >various IE encodings within UNI 3.1 allow a VC originator to specify >a range of 'layer X' entities as the destination "AAL User", and that >the AAL specs don't prohibit any particular layer X from attaching >directly to a local AAL service. Taken together these points mean >LLC/SNAP encapsulation is just (the default) one of a range of methods. I don't think you're too jumpy . I think this is a good point, that the presence of logical link identifiers (VPI/VCIs) alone is not sufficient to allow any particular layer X to attach directly to a local AAL service, but requires the appropriate IE encodings within the Q.9xxx signaling protocol as well. Taken together, is this specific to ATM, or does Q.931 support similar IE encodings, offering the same capability to FR subnets, for example? > > [..] >>>Any comments? > >Just one more - will you be explicitly 'flagging' the association >between existing RFCs and some the models/reasons you'll be describing? >I would like the Framework doc to help newcomers understand the existing >ip-atm WG docs in addition to providing a general overview. We took a crack at attempt this, by putting in the last section in the document (see Section 6) a table cross referencing the various models and the WG's documents. However, I am not sure that a simple table is enough and that more text may be required. Let us know what you think? > >cheers, >gja Thanks, Bob Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02227; 29 Dec 94 10:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02223; 29 Dec 94 10:11 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07665; 29 Dec 94 10:11 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA138160810; Thu, 29 Dec 1994 06:20:10 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137850807; Thu, 29 Dec 1994 06:20:07 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA04828; Thu, 29 Dec 94 09:17:57 EST Received: from rgc-ddd.ho.att.com by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA04013; Thu, 29 Dec 94 09:19:46 EST Message-Id: Date: Thu, 29 Dec 94 09:16:43 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: Re: framework revisions To: Grenville Armitage , curtis@ans.net Cc: Robert.G.Cole@att.com, IP over ATM , "Shur, David" X-Mailer: VersaTerm Link v1.1.3 Grenville, > > [..] >>>> P. S. We will cover the bit about LLC/SNAP entities invoking ATM in >>>> attribute 4 in section 4 above, along with per VC, TUNIC and TULIP >>>> multiplexing as well. >>> >>>Encapsulation is almost orthogonal everything else in section 4. I >>>think it deserves its own section entitled "Encapsulation". > >Consider me a supporter of this point (me? biassed?). I currently have >some text and diagrams on the encapsulation issue that could constitute >a stand-alone section with a little massage (MSWord format at the >moment). Hassle me later next week. Thanks, we will. > >gja > Bob Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02272; 29 Dec 94 10:16 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02268; 29 Dec 94 10:16 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07915; 29 Dec 94 10:16 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137320032; Thu, 29 Dec 1994 06:07:13 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA137010028; Thu, 29 Dec 1994 06:07:08 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA00603; Thu, 29 Dec 94 09:04:56 EST Received: from rgc-ddd.ho.att.com by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA03148; Thu, 29 Dec 94 09:06:37 EST Message-Id: Date: Thu, 29 Dec 94 09:03:53 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: Re: framework revisions To: curtis@ans.net, Robert.G.Cole@att.com Cc: IP over ATM , "Shur, David" X-Mailer: VersaTerm Link v1.1.3 Curtis, > >In message , "Robert G. Cole" writes: >> >> We will provide a text version (as well as postscript) of the next >> version of draft (around the end of January). At that time, we will >> provide both text and Framemaker versions to Curtis to enable him to >> do HTML conversion (that is, Curtis, if your still up to it at that time). > >Yes. It seems you still want to keep the source in Frame. Please >make separate EPS files of the diagrams. I think Frame can do that. >Thanks. I think we would like to keep it in Frame until the next revision at the end of Jan, then have it converted to HTML. I expect that there will still be quite a few changes following and we are hoping that HTML will help simplify these revisions and generating the ascii and ps versions for draft submission. > > >Whether multihomed routers a present has a major impact on the >feasibility of certain models such as NHRP and the ATMF Integrated >proposal and TULIP/TUNIC. What is the issue wrt multihomed routers and NHRP and the ATMF Integrated proposal? Is the problem that the router treats the interfaces as logically seperate, that is it relies on routing over the same interface as the determining factor in deciding whether the route double-dips into the same atm subnet, and hence can be short-cut? How should we represent these issues in the text, as "configuration constraints" associated with the appropriate subnet or end-to-end models? >> >> We would then present some example subnet models (not discussed by this >> working group), for example an SVC LAN over >> an ATM internet(multiple ADs) where multiple ATM address formats are possible >> which complicate ARP responses (see appendix), or an ATM clns subnet >> (essentially IP over SMDS). > >A LAN over an internet? Are you talking about bridging and >tunnelling? If so, I fail to see how this is an IP over ATM topic. >You can do bridging and tunnelling over anything that supports IP and >sure you can do it over non-IP as well. > >A LAN implies geographic locality or in the bridging world implies the >appearance of a single legacy LAN media segment which for IP implies a >single LIS. An internet implies multiple LIS. Maybe I should stop >guessing at what you meant by this and let you tell me. We'll drop the reference to LAN here because we were not trying to allude to geographic locality, but rather to the classical IP model. We were trying (although not very successfully) to get at a point you raised earlier regarding issues surrounding atm internets, i.e., an atm subnet comprised of multiple administrative domains. At least one issue not addressed in the classical IP model is when the hosts are using different ATMF address formats, which may arise when some of the hosts are homed to a "private atm switch" and others of the same LIS are homed to a "public atm switch" supporting only the E.164 ATMF address formats. Here, an ARP message (from the public attached host) must return both an E.164 point of egress and the private format of the other host. Either that or the ATM routing must somehow determine the E.164 point of egress. In either case, I don't know how this would work. Maybe this is just another one of the "configuration constraints" to point out in disucssing the Classical IP model (I believe that the framework doc text already points this out). > >Isn't an ATM CLNS the "Convential Model" which was already discussed? >I don't recall it getting much support. > >Just what we need. More models. :-( I am not 100% clear on what the conventional model is, the AAL3/4 twist alluded to in the text was our twist as one possible implementation. I suppose that other implementations are possible. Regarding support, the meeting minutes from Toronto stated that the group wanted reference to the conventional model included. As the draft now stands it is discussed in, a rather short, section 5.2. It's up to the group to decide its fate. > >> Finally we would end section 4 by giving a preface to the end-to-end models b >> y >> pointing out that there are several other emerging >> attributes of ATM networking that are encouraging development of >> multiple end-to-end models (ranging from traditional "classical IP", >> to ROLC "NHRP" preserving routing control but short cutting transport, >> to peer models). These are 1) a belief of ubiquitous >> ATM deployment supporting the direct interconnection of large >> numbers of hosts, and 2) the development of an "internet" style routing >> capability. The first has revised discussion of methods to "short >> cut" multiple IP hops accross a single ATM network, i.e., ROLC "NHRP" >> models, and the second is encouraging the discussion of "peer"models, >> which place ATM routing and IP level routing on an equal footing. These >> are discussed in Section 6. > >There is an apparent discrepency in two of your statements above. >First you say "there are several other emerging attributes". Then you >say "These are 1) a belief". I think you are far more accurate the >second time. I don't think a belief is well described as "an emerging >attribute". I would like to see it made clear that there is no >evidence to lead to a conclusion that there will be ubiquitous ATM in >the near future (in this decade at least) and that the absense of >ubiquitous ATM result in feasibility problems with some models. I agree with using the term "belief", but I don't understand the 'feasibility problems" that would arise without a ubiquitous deployment (unless you are refering to utility of such models). > >> Section 5 will follow pretty much the current structure - where we >> describe the various end-to-end models, including Overlay (Classical >> IP over ATM), Ohta, ROLC, Integrated (we will call this out explicitly now), >> and Peer. > >Your CNLS (IP over SMDS) probably belongs here. Please explain how it >differs from Convential (Ohta). (See comment above) > >Your other SVC LAN over multiple AD internet might belong here >depending on what it means. > >> P. S. We will cover the bit about LLC/SNAP entities invoking ATM in >> attribute 4 in section 4 above, along with per VC, TUNIC and TULIP >> multiplexing as well. > >Encapsulation is almost orthogonal everything else in section 4. I >think it deserves its own section entitled "Encapsulation". The That's a possibility. We didn't think it belonged as a seperate subnet model and hence felt it should not be in the same section as the subnet models. >choices are LLC/SNAP, null, TUNIC and TULIP, (although you could roll >another if you wanted to further confuse the industry). > Thanks for your comments, Bob Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02558; 29 Dec 94 10:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02554; 29 Dec 94 10:46 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08632; 29 Dec 94 10:46 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA139472583; Thu, 29 Dec 1994 06:49:43 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ns.mci.net by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA139162579; Thu, 29 Dec 1994 06:49:39 -0800 Received: from loopback.mci.net (loopback.mci.net [127.0.0.1]) by ns.mci.net (8.6.9/8.6.6) with SMTP id JAA00565; Thu, 29 Dec 1994 09:48:42 -0500 Message-Id: <199412291448.JAA00565@ns.mci.net> X-Authentication-Warning: ns.mci.net: Host loopback.mci.net didn't use HELO protocol To: craig@aland.bbn.com, curtis@ans.net Cc: stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@ns.mci.net Subject: Re: RFC Submission . . . . Date: Thu, 29 Dec 1994 09:48:41 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Abir Hnidi Curtis wrote: > It's really IP over FR over AAL5 using DXI. It happens to be a > component of the temporary kludge being used at the ATM NAPs due to > lack of anything else that could give us the end result we needed > which was an ATM LIS with end points on the LIS running BGP4 and > capable of carrying IP traffic loads between major IP providers). In > less than 6 months it should be replaced by IP over LLC/SNAP over AAL5 > ala RFC1483. Maybe we don't even want to document this temporary > situation and possibly encourage vendors to go down a dead end path. Even if the DXI protocol might have a short life cycle, it would be still beneficial and imformative for the Internet community to document how DXI protocol is implemented. I don't agree that this RFC will send the wrong message to the vendors. I think that IP-ATM WG has made it clear that RFCs 1483/1577 is the direction that IP over ATM is taking in the future, therefore, there should be no confusion as far as the vendors are concerned. Abir   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03876; 29 Dec 94 12:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03872; 29 Dec 94 12:31 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11200; 29 Dec 94 12:31 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA144268480; Thu, 29 Dec 1994 08:28:00 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightstream.LightStream.COM by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA143958472; Thu, 29 Dec 1994 08:27:52 -0800 Received: from wyvern.LightStream.COM by lightstream.LightStream.COM (4.1/SMI-4.1) id AA27826; Thu, 29 Dec 94 11:26:02 EST Received: by wyvern.LightStream.COM (4.1/SMI-4.1) id AA18000; Thu, 29 Dec 94 11:26:23 EST Message-Id: <9412291626.AA18000@wyvern.LightStream.COM> To: Craig Partridge Cc: stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net Subject: Re: RFC Submission . . . . Date: Thu, 29 Dec 1994 11:26:22 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rich Bradford Craig, > I think sections 1 through 3 are superfluous (they are simply a > compressed intro to ATM and an RFC can assume a technical background > by its reader). I agree that they are superfluous for people on this list. However, There are a lot of people who'll read it who'll be just cutting their teeth on ATM (e.g. students). People advanced in a subject can easily see when to skip forward, while a good introduction can cut down on ramp-up. I'd recommend leaving it in. -- Rich Bradford, rbradford@lightstream.com (617)262-1210   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04204; 29 Dec 94 13:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04200; 29 Dec 94 13:07 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12045; 29 Dec 94 13:07 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA146680487; Thu, 29 Dec 1994 09:01:27 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from zephyr.isi.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA146370482; Thu, 29 Dec 1994 09:01:22 -0800 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Thu, 29 Dec 1994 09:00:24 -0800 Date: Thu, 29 Dec 1994 09:00:24 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Postel Message-Id: <199412291700.AA04198@zephyr.isi.edu> To: rbradfor@lightstream.com, gja@thumper.bellcore.com Subject: Re: RFC Submission . . . . Cc: craig@aland.bbn.com, stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net Hi. How about making it two documents: (1) intro to ATM, and (2) this particular way of doing IP over ATM. --jon.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04604; 29 Dec 94 13:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04596; 29 Dec 94 13:19 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12437; 29 Dec 94 13:19 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA145560138; Thu, 29 Dec 1994 08:55:38 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA145250107; Thu, 29 Dec 1994 08:55:07 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id LAA14615; Thu, 29 Dec 1994 11:51:51 -0500 Message-Id: <199412291651.LAA14615@thumper.bellcore.com> To: Rich Bradford Cc: Craig Partridge , stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, gja@thumper.bellcore.com Subject: Re: RFC Submission . . . . In-Reply-To: Your message of Thu, 29 Dec 1994 11:26:22 -0500. <9412291626.AA18000@wyvern.LightStream.COM> Date: Thu, 29 Dec 1994 11:51:50 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage [Craig wrote..] >>> I think sections 1 through 3 are superfluous (they are simply a [..] [Rich wrote..] >>I agree that they are superfluous for people on this list. However, >>There are a lot of people who'll read it who'll be just cutting >>their teeth on ATM (e.g. students). [..] >>I'd recommend leaving it in. I disagree. Take the text out but replace it with a list of 3 or 4 easily obtained references that students and newcomers can ferret out for themselves, e.g. IEEE Network articles, some recent text books, other online publications, etc. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04655; 29 Dec 94 13:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04650; 29 Dec 94 13:22 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12521; 29 Dec 94 13:22 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA146300469; Thu, 29 Dec 1994 09:01:09 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA145990465; Thu, 29 Dec 1994 09:01:05 -0800 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08739 for ip-atm@matmos.hpl.hp.com; Thu, 29 Dec 94 12:00:30 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA22250; Thu, 29 Dec 1994 08:58:17 -0800 Message-Id: <199412291658.IAA22250@aland.bbn.com> To: Rich Bradford Cc: Craig Partridge , stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu Subject: Re: RFC Submission . . . . In-Reply-To: Your message of Thu, 29 Dec 94 11:26:22 -0500. <9412291626.AA18000@wyvern.LightStream.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Thu, 29 Dec 94 08:58:02 -0800 I agree that they are superfluous for people on this list. However, There are a lot of people who'll read it who'll be just cutting their teeth on ATM (e.g. students). People advanced in a subject can easily see when to skip forward, while a good introduction can cut down on ramp-up. Rich: By this logic, every IETF document should contain an intro section explaining how TCP/IP and the Internet work. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05277; 29 Dec 94 13:45 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05273; 29 Dec 94 13:45 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13234; 29 Dec 94 13:45 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148222533; Thu, 29 Dec 1994 09:35:33 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA147912527; Thu, 29 Dec 1994 09:35:27 -0800 Received: from localhost (laubach@localhost) by terra.com21.com (8.6.5/8.6.5) id JAA01131; Thu, 29 Dec 1994 09:15:38 -0800 Date: Thu, 29 Dec 1994 09:15:38 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach To: Grenville Armitage Cc: Rich Bradford , Craig Partridge , stev@ftp.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, gja@thumper.bellcore.com Subject: Re: RFC Submission . . . . In-Reply-To: <199412291651.LAA14615@thumper.bellcore.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Dec 1994, Grenville Armitage wrote: > > [Craig wrote..] > >>> I think sections 1 through 3 are superfluous (they are simply a > [..] > [Rich wrote..] > >>I agree that they are superfluous for people on this list. However, > >>There are a lot of people who'll read it who'll be just cutting > >>their teeth on ATM (e.g. students). > [..] > >>I'd recommend leaving it in. > > I disagree. Take the text out but replace it with a list of 3 or 4 easily > obtained references that students and newcomers can ferret out for > themselves, e.g. IEEE Network articles, some recent text books, other > online publications, etc. Gentlemen, et al., Our AD asked us to review this informational RFC submission. It is really not an IPATM working group item, so we don't need to beat it up like it were one.... W.r.t. sections 1-3 all we need say is that members of the WG felt that Section 1-3 need to be rewritten. Some felt that the sections were superfluous, others felt the sections should be condensed, others felt that references should be added. I'm more interested in giving technical feedback on the remainder of the submission. I've heard that the IP<>FrameRelay<>AAL5<>DXI documentation at this time could give a misleading sense of status to the method. I've also suggest myself that this submission detail the transition plan, rather than just the starting point..... What concise feedback can we give to the IESG on these remaining portions of the work? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05335; 29 Dec 94 13:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05331; 29 Dec 94 13:48 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13561; 29 Dec 94 13:48 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148842963; Thu, 29 Dec 1994 09:42:43 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148532956; Thu, 29 Dec 1994 09:42:36 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id LAA00339; Thu, 29 Dec 1994 11:54:59 -0500 Message-Id: <199412291654.LAA00339@curtis.ansremote.com> To: "Robert G. Cole" Cc: Grenville Armitage , IP over ATM , "Shur,\ David" , curtis@ans.net Reply-To: curtis@ans.net Subject: Re: framework revisions In-Reply-To: Your message of "Thu, 29 Dec 1994 08:16:43 PST." Date: Thu, 29 Dec 1994 11:54:01 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , "Robert G. Cole" writes: > Grenville, > > > [..] > >>>4)The presence of logical link identifiers (VPI/VCIs) which enable > >>>binding between virtual circuits and higher level entities in the > >>>TCP/IP protocol stack instead of LLC/SNAP end-points , only. > >>>(E.g., single VC per protocol binding, TULIP, TUNIC). > > > >Maybe I'm being a little too jumpy, but I sure hope you don't phrase > >it like this. The "presence of logical link identifiers (VPI/VCIs)" is > >common to _all_ IP over ATM mechanisms, and shouldn't be called out > >as some nifty gadget that enables TULIP, etc. The real point is that > > Although common to most ATM mechanisms (but not all, e.g., IP over clns or > smds or whatever the appropriate reference), it is not common to all > subnets, e.g., IP over ethernet, TR, FDDI, etc. The discussion in this > "introductory" section is to point out attributes of atm which allow > for different IP ATM interactions or models. The fact that ATM has the potential to save 20 bytes of header and then pad out 0-44 bytes in some cases is detail that belongs in the encapsulation section. Encapsulation efficiency is not one of ATMs strong points just because TULIP/TUNIC is possible and isn't important enough to justify keeping it in section 4. > >various IE encodings within UNI 3.1 allow a VC originator to specify > >a range of 'layer X' entities as the destination "AAL User", and that > >the AAL specs don't prohibit any particular layer X from attaching > >directly to a local AAL service. Taken together these points mean > >LLC/SNAP encapsulation is just (the default) one of a range of methods. > > I don't think you're too jumpy . I think this is a good point, > that the presence of logical link identifiers > (VPI/VCIs) alone is not sufficient to allow any particular layer X to > attach directly to a local AAL service, but requires the appropriate > IE encodings within the Q.9xxx signaling protocol as well. > > Taken together, is this specific to ATM, or does Q.931 support > similar IE encodings, offering the same capability to FR subnets, for example > ? This is all true. But it belongs in the encapsulation section. The possibility does exist to trim bytes off the encapsulation scheme to improve encapsulation efficiency, at the cost of requiring more VCs and at the cost of being incompatible with the recommendations of RFC1483. It is purely an encapsulation issue. Bob- the major argument is not with the text itself. It is just in the wrong place! You could state things a bit more clearly, but if you just put this in the encapsulation section it will be obvious that TULIP/TUNIC are not some unique special capability of ATM, but rather the possibility to gain back a few bytes of header with some known disadvantages. > > > > [..] > >>>Any comments? > > > >Just one more - will you be explicitly 'flagging' the association > >between existing RFCs and some the models/reasons you'll be describing? > >I would like the Framework doc to help newcomers understand the existing > >ip-atm WG docs in addition to providing a general overview. > > We took a crack at attempt this, by putting in the last section in the > document (see Section 6) a table cross referencing the various models > and the WG's documents. However, I am not sure that a simple table is > enough and that more text may be required. Let us know what you think? That table sufferred from the gross inadequacy of the categorization scheme. If we get a better categorization, we have a better chance of putting together a meaningful table. > >cheers, > >gja > > Thanks, > > Bob Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05420; 29 Dec 94 13:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05415; 29 Dec 94 13:53 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13667; 29 Dec 94 13:53 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149983268; Thu, 29 Dec 1994 09:47:49 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightstream.LightStream.COM by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149673260; Thu, 29 Dec 1994 09:47:40 -0800 Received: from wyvern.LightStream.COM by lightstream.LightStream.COM (4.1/SMI-4.1) id AA29281; Thu, 29 Dec 94 12:46:48 EST Received: by wyvern.LightStream.COM (4.1/SMI-4.1) id AA18055; Thu, 29 Dec 94 12:47:09 EST Message-Id: <9412291747.AA18055@wyvern.LightStream.COM> To: Craig Partridge Cc: Rich Bradford , stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, rbradfor@lightstream.com Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Thu, 29 Dec 1994 08:58:02 PST." <199412291658.IAA22250@aland.bbn.com> Date: Thu, 29 Dec 1994 12:47:09 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rich Bradford > I agree that they are superfluous for people on this list. However, > There are a lot of people who'll read it who'll be just cutting > their teeth on ATM (e.g. students). People advanced in a subject > can easily see when to skip forward, while a good introduction can > cut down on ramp-up. > >Rich: > > By this logic, every IETF document should contain an intro section >explaining how TCP/IP and the Internet work. > >Craig I wouldn't go quite that far, but I would say that there are some which wouldn't have been hurt with some "excess verbage". However, I'll concede a couple of pointers to other on-line material would do as well. Rich   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05712; 29 Dec 94 14:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05708; 29 Dec 94 14:17 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14167; 29 Dec 94 14:17 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA149263070; Thu, 29 Dec 1994 09:44:30 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA148953062; Thu, 29 Dec 1994 09:44:22 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id MAA00372; Thu, 29 Dec 1994 12:38:13 -0500 Message-Id: <199412291738.MAA00372@curtis.ansremote.com> To: "Robert G. Cole" Cc: curtis@ans.net, Robert.G.Cole@att.com, IP over ATM , "Shur,\ David" Reply-To: curtis@ans.net Subject: Re: framework revisions In-Reply-To: Your message of "Thu, 29 Dec 1994 09:03:53 PST." Date: Thu, 29 Dec 1994 12:37:18 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , "Robert G. Cole" writes: > Curtis, > > > > >In message , "Robert G. Cole" writes: > >> > >> We will provide a text version (as well as postscript) of the next > >> version of draft (around the end of January). At that time, we will > >> provide both text and Framemaker versions to Curtis to enable him to > >> do HTML conversion (that is, Curtis, if your still up to it at that time). > > > >Yes. It seems you still want to keep the source in Frame. Please > >make separate EPS files of the diagrams. I think Frame can do that. > >Thanks. > > I think we would like to keep it in Frame until the next revision at the end > of > Jan, then have it converted to HTML. I expect that there will still be quite > a few changes following and we are hoping that HTML will help simplify > these revisions and generating the ascii and ps versions for draft submission If it easier to comment on the document in HTML and make revisions going forward, why do we want to keep it in frame during January? > >Whether multihomed routers a present has a major impact on the > >feasibility of certain models such as NHRP and the ATMF Integrated > >proposal and TULIP/TUNIC. > > What is the issue wrt multihomed routers and NHRP and the ATMF Integrated > proposal? Is the problem that the router treats the interfaces > as logically seperate, that is it relies on routing over the same > interface as the determining factor in deciding whether the route > double-dips into the same atm subnet, and hence can be short-cut? > How should we represent these issues in the text, as "configuration > constraints" associated with the appropriate subnet or end-to-end models? In practice, this is not a matter of configuration constraints wrt attaching routers to ATM. It is more a matter of whether an ATM network can be attached as a peer in more than one place to the existing Internet which already has a great deal of redundancy. Perhaps I can make the point more clear by way of example. If you were to go ahead and creat BobNet tommorrow and attach it to the Internet, you would probably not want a single point of failure. What you would probably do is attach at 2-3 places (New York, Chicago, and California come to mind for some reason). If the New York power grid went down or an AmTrak derailment shreaded your fiber to New York (or something less dramatic happenned that cut you off at New York), you wouldn't lose connectivity between BobNet and the rest of the Internet. This is only unimportant if you don't care much about the rest of the Internet because you think BobNet will be so much bigger. :-) You could not exchange routing information in this tolopogy with NHRP. The authors acknowledge this and don't claim NHRP was intended for this. The Integrated proposal, if I understand it correctly, also relies on providing "address resolution" information for the purpose of setting up VCs through the ATM. Although I don't follow ATMF closely, I hear that more recent discussion of integrating PNNI with other non-ATM routing protocols is beginning to acknowledge the need to carry routing attributes of other protocols in order to maintain loop prevention common to a few important inter-AS (or inter-AD) routing protocols (namely BGP and IDRP). The latter would support an internet in which ADs were not all ATM and in which ADs were redundantly connected to each other. > >> We would then present some example subnet models (not discussed by this > >> working group), for example an SVC LAN over > >> an ATM internet(multiple ADs) where multiple ATM address formats are possi > ble > >> which complicate ARP responses (see appendix), or an ATM clns subnet > >> (essentially IP over SMDS). > > > >A LAN over an internet? Are you talking about bridging and > >tunnelling? If so, I fail to see how this is an IP over ATM topic. > >You can do bridging and tunnelling over anything that supports IP and > >sure you can do it over non-IP as well. > > > >A LAN implies geographic locality or in the bridging world implies the > >appearance of a single legacy LAN media segment which for IP implies a > >single LIS. An internet implies multiple LIS. Maybe I should stop > >guessing at what you meant by this and let you tell me. > > We'll drop the reference to LAN here because we > were not trying to allude to geographic locality, but > rather to the classical IP model. We were trying (although not very > successfully) to get at a point you raised > earlier regarding issues surrounding atm internets, i.e., an atm subnet > comprised of multiple administrative domains. At least one issue > not addressed in the classical IP model is when the hosts are > using different ATMF address formats, which may arise when some > of the hosts are homed to a "private atm switch" and others > of the same LIS are homed to a "public atm switch" supporting > only the E.164 ATMF address formats. Here, an ARP message (from the > public attached host) must return both an E.164 point of egress and the > private format of the other host. Either that or the ATM routing must > somehow determine the E.164 point of egress. In either case, I don't > know how this would work. Maybe this is just another one of the > "configuration constraints" to point out in disucssing the Classical > IP model (I believe that the framework doc text already points this out). In the classic model, if the ATM address formats were sufficiently incompatible that you could not set up a direct VC between certain pairs of hosts, you would split the LIS. Trying to make a huge RFC1577 LIS across incompatible address formats is just plain stupid. You subdivide into LIS and use other means to make direct connections across LIS boundaries where appropriate. You would do this for scaling reasons even without the problem incompatible address formats. Yes it is a configuration constraint. You make a very large RFC1577 internet out of small LIS and cut through the LIS where possible and where it is to your advantage to do so. > >Isn't an ATM CLNS the "Convential Model" which was already discussed? > >I don't recall it getting much support. > > > >Just what we need. More models. :-( > > I am not 100% clear on what the conventional model is, the AAL3/4 twist > alluded to in the text was our twist as one possible implementation. I > suppose that other implementations are possible. Regarding support, > the meeting minutes from Toronto stated that the group wanted reference > to the conventional model included. As the draft now stands it is discussed > in, a rather short, section 5.2. It's up to the group to decide > its fate. I don't think your ATM CLNS SMDS over ATM model has not shown even as much support within this group yet than the Conventional model, so how about if we leave your new model out unless you are prepared to first write a draft describing it and try to gain support for the model from the WG. I'd like to see you leave the description Convential as is, although I would prefer getting rid of it entirely since it appears to have no support in this group, no vendor support, and no implementations. > >> Finally we would end section 4 by giving a preface to the end-to-end model > s b > >> y > >> pointing out that there are several other emerging > >> attributes of ATM networking that are encouraging development of > >> multiple end-to-end models (ranging from traditional "classical IP", > >> to ROLC "NHRP" preserving routing control but short cutting transport, > >> to peer models). These are 1) a belief of ubiquitous > >> ATM deployment supporting the direct interconnection of large > >> numbers of hosts, and 2) the development of an "internet" style routing > >> capability. The first has revised discussion of methods to "short > >> cut" multiple IP hops accross a single ATM network, i.e., ROLC "NHRP" > >> models, and the second is encouraging the discussion of "peer"models, > >> which place ATM routing and IP level routing on an equal footing. These > >> are discussed in Section 6.> > > >There is an apparent discrepency in two of your statements above. > >First you say "there are several other emerging attributes". Then you > >say "These are 1) a belief". I think you are far more accurate the > >second time. I don't think a belief is well described as "an emerging > >attribute". I would like to see it made clear that there is no > >evidence to lead to a conclusion that there will be ubiquitous ATM in > >the near future (in this decade at least) and that the absense of > >ubiquitous ATM result in feasibility problems with some models. > > I agree with using the term "belief", but I don't understand the 'feasibility > problems" that would arise without a ubiquitous deployment (unless > you are refering to utility of such models). See previous discussion of the limitations of NHRP and the original Ross Callon Integrated proposal. If these are described in the framework documents, the assumptions required for feasibility must be raised since the assumption of ATM ubiquity and simple topology outside of the ATM portion of the topology is not true for the current Internet and for many smaller internets as well. > >> Section 5 will follow pretty much the current structure - where we > >> describe the various end-to-end models, including Overlay (Classical > >> IP over ATM), Ohta, ROLC, Integrated (we will call this out explicitly now > ), > >> and Peer. > > > >Your CNLS (IP over SMDS) probably belongs here. Please explain how it > >differs from Convential (Ohta). > > (See comment above) I'd like to see you leave them both out. > >Your other SVC LAN over multiple AD internet might belong here > >depending on what it means. > > > >> P. S. We will cover the bit about LLC/SNAP entities invoking ATM in > >> attribute 4 in section 4 above, along with per VC, TUNIC and TULIP > >> multiplexing as well. > > > >Encapsulation is almost orthogonal everything else in section 4. I > >think it deserves its own section entitled "Encapsulation". The > > That's a possibility. We didn't think it belonged as a seperate subnet > model and hence felt it should not be in the same section as the > subnet models. Great. So how about making an encapsulation section and putting it there. > >choices are LLC/SNAP, null, TUNIC and TULIP, (although you could roll > >another if you wanted to further confuse the industry). > > > > Thanks for your comments, > > Bob Thanks for you patience. As always sprinkle liberally with smiley. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05970; 29 Dec 94 14:43 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05966; 29 Dec 94 14:43 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15246; 29 Dec 94 14:43 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA153856109; Thu, 29 Dec 1994 10:35:09 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA153546106; Thu, 29 Dec 1994 10:35:06 -0800 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA25518 for ip-atm@matmos.hpl.hp.com; Thu, 29 Dec 94 13:34:43 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA22408; Thu, 29 Dec 1994 10:32:39 -0800 Message-Id: <199412291832.KAA22408@aland.bbn.com> To: Mark Laubach Cc: stev@ftp.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net Subject: Re: RFC Submission . . . . In-Reply-To: Your message of Thu, 29 Dec 94 09:15:38 -0800. Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Thu, 29 Dec 94 10:32:38 -0800 What concise feedback can we give to the IESG on these remaining portions of the work? Mark: Based on all the discussion I've seen I'd suggest the following as a draft reply... Sections 1-3 need to be revised. In particular, the WG suggests - the presentation of ATM be replaced with citations to one of the several widely available ATM books and articles. (Personally I'd suggest de Prycker and Handel & Huber plus the UNI 3.0 spec). - the early sections make clear that this RFC is documenting the currently DXI interface used at the NSF NAPs and that this interface is an interim interface (which is why this document is informational) - if possible, that the trajectory of the transition plan to RFC 1483 encapsulation be mentioned. The title be revised to make clear that it refers to an interim NSF NAP encapsulation [I'm suggesting this as a balance among Andy's, Curtis' and my notes] Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06614; 29 Dec 94 15:29 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06610; 29 Dec 94 15:29 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16778; 29 Dec 94 15:29 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA155457787; Thu, 29 Dec 1994 11:03:07 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from maelstrom.acton.timeplex.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA155147762; Thu, 29 Dec 1994 11:02:42 -0800 Received: from maelstrom.timeplex.com (malis@localhost) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id OAA13195; Thu, 29 Dec 1994 14:01:06 -0500 Message-Id: <199412291901.OAA13195@maelstrom.acton.timeplex.com> To: Mark Laubach Cc: Grenville Armitage , Rich Bradford , Craig Partridge , stev@ftp.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, malis@maelstrom.timeplex.com Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Thu, 29 Dec 1994 09:15:38 PST." Date: Thu, 29 Dec 1994 14:01:06 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Mark, > I'm more interested in giving technical feedback on the remainder of the > submission. I've heard that the IP<>FrameRelay<>AAL5<>DXI documentation > at this time could give a misleading sense of status to the method. I've > also suggest myself that this submission detail the transition plan, > rather than just the starting point..... > > What concise feedback can we give to the IESG on these remaining portions > of the work? Did you see my message yesterday? At the risk of being redundant, I'll resend my previous technical comments: ----- I have a separate comment on section 5 of the RFC for the author. I believe the description of the Mode 2 frame format is incomplete, because Mode 2 always uses the AAL 3/4 CPCS_PDU header and trailer, even when the DTE SDU is sent over the ATM network using AAL5. See Figures 2.4 and 2.10 in the DXI spec. I would advise Abir to either expand the Mode 2 discussion or remove it entirely - I'm not aware of its use in practice. I also notice that Mode 2 wasn't included in section 6, so again, either section 6 should be expanded to include Mode 2, or Mode 2 should just be removed completely from the document. ----- After thinking about it a bit more, I would like to add a second comment. The RFC should include somewhere a note explicitly stating that while stations using the DXI interface can interoperate with each other, they cannot interoperate with non-DXI (i.e. native ATM) RFC 1577 implementations. It should also state that the association between destination IP addresses and PVC VPI/VCIs has to be manually configured (there is no ARP functionality). I also want to note that I agree with Abir's statement: "Even if the DXI protocol might have a short life cycle, it would be still beneficial and imformative for the Internet community to document how DXI protocol is implemented." My own feeling is that the DXI interface is useful technology (otherwise the DSU vendors wouldn't be selling any), and not documenting it outside of the ATM Forum isn't going to make it go away. Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07306; 29 Dec 94 16:29 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07302; 29 Dec 94 16:29 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18147; 29 Dec 94 16:29 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA157960388; Thu, 29 Dec 1994 11:46:28 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from kentrox.com (kentrox.kentrox.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA157650383; Thu, 29 Dec 1994 11:46:23 -0800 Received: by kentrox.com (/\==/\ Smail3.1.28.1 #28.5) id ; Thu, 29 Dec 94 11:45 PST Received: by kentrox.com (4.1/SMI-4.1) id AA19582; Thu, 29 Dec 94 11:45:31 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Hanson Message-Id: <9412291945.AA19582@kentrox.com> Subject: Re: RFC Submission . . . . To: ahnidi@ns.mci.net, stev@ftp.com Date: Thu, 29 Dec 94 11:45:29 PST Cc: topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu X-Mailer: ELM [version 2.3 PL0] Abir, Stev, et al., I applaud Abir's timely efforts at documenting for informational purposes how IP over AAL5 may be transported when ATM DXI is involved. It is good to lay all the cards out on the table and to identify how it has been done and how it is hoped to be done. In that spirit, I have some additional comments and suggestions for making the RFC even more useful. 1. Identify the "likely-to-be-seen" ATM DXI modes and options. - ATM DXI 1.0 specifies modes 1a, 1b, and 2. A extension of mode 1b exists which retains Mode 2's 4-byte header without adding Mode 2's extra utilization of AAL3/4 CPCS between DTE and DCE. Some ATM DSUs support this mode in order to support non-"ATM DXI"-capable routers that use Frame Relay VCs with the 4-byte header option. It also is somewhat more efficient than your normal ATM Forum mode 2. 2. Clarify the "specified" FCS options and the "possible" FCS options. - ATM DXI 1.0 restricts modes 1a and 1b to 16-bit FCS. The proposed RFC maintains that 16-bit or 32-bit is allowed. This is fine, so long as the DTE and the DCE are configured identically. - ATM DXI 1.0 restricts mode 2 to 32-bit FCS. The proposed RFC again maintains that 16-bit or 32-bit is allowed, which is fine so long as the DTE and the DCE are configured identically. - Obviously, an extended mode 1b can use either 16-bit or 32-bit FCS, so long as ... etc. 3. Enumerate the likely and preferred "encapsulation possibilities". - It should be remembered that the encapsulation technique is always "per connection". Consequently, since there are many cases in which connections span Frame Relay and ATM clouds, and many cases in which interoperability with older down-rev Frame Relay DTE is expected by customers, a set of encapsulation possibilities that can all reasonably serve the purpose of multiprotocol encapsulation should also be expected. Here is a list of anticipated multiprotocol encapsulations that may be seen on any given VC over ATM DXI, given in order from the "most preferred" to the "least preferred": - Multiprotocol over ATM (per RFC 1483). This technique uses an LLC/SNAP header of AA-AA-03-00-00-00-08-00 for IP and uses an LLC/SNAP header of AA-AA-03-00-00-00-08-06 for ARP (i.e., ATMARP and InATMARP [see RFC 1577]). This is the most preferred of the various multiprotocol encapsulation techniques, but is yet not supported by all DTE in the field. - Frame Relay (per RFC 1490). This technique uses an NLPID header of 03-CC for IP and uses a SNAP header of 03-00-80-00-00-00-08-06 for ARP (i.e., ARP, RARP, and Inverse ARP [see RFC 1293 and RFC 1490]). This is the multiprotocol encapsulation technique found on all current Frame Relay DTE, but it is not supported by many older DTE in the field. - Frame Relay (prior to RFCs 1294/1490). This technique uses an ethertype header of 08-00 for IP and uses an ethertype header of 08-06 for ARP. This is the least preferred of the multiprotocol encapsulation techniques, but is sometimes the only technique that is supported by older Frame Relay DTE. In addition, "VC-based multiplexing" (per RFC 1483) may be used. This is essentially a "null" encapsulation where multiple protocols are multiplexed using independent VCs instead of using protocol identifiers embedded within encapsulation headers. - I think this RFC would also be an excellent place to identify some other issues associated with Frame Relay and ATM interworking. The proposed RFC could help clarify some important misunderstandings. - The notions of Service Interworking and Network Interworking could be described. - The notion that the interworking is effectively a per-VC issue could be clarified. - The possibility that the network interworking function can be performed by the ATM DSU on a per-VC basis should certainly be stressed. In this regard, it would be helpful to state that either 2-byte or 4-byte headers may be embedded within the AAL5 CPCS-PDU that is traversing the ATM network on its way either FROM or TOWARDS the Frame Relay network. 4. Identify support of SNMP within the ATM DSU as an alternative to LMI. - Usage of the ILMI communication protocol (i.e., via VPI/VCI 0/16) to access MIB-II and RFC 1695 objects has clearly been left as a vendor implementation choice by the ATM Forum. Management stations have the option of accessing ATM and Physical layer statistics directly from the ATM DSU when it has its own embedded SNMP agent. In these cases, utilization of the ATM DXI's LMI between the DTE (router) and the DCE (ATM DSU) are not required. 5. Clarify some "acronymization". - "AAL" is an acronym for "ATM Adaptation Layer", even though the Bellcore TA-NWT-001113 mistakenly uses the term "Adaption" on the title page. :-) - "HEC" is described variously in many documents as an acronym for either "Header Error Check" or "Header Error Control". The varied usage is too widely spread to contain at this time, unless either Al Gore or Congress wishes to step in and help us all out. :-) - "PTI" (instead of "PT") is the full acronym for the term "Payload Type Identifier". - Perhaps most importantly, using "ATM DXI" instead of "DXI" would help clarify which DXI being referred to, since "DXI" might refer to either ATM DXI or SMDS DXI (and, by this time, possibly others). I agree with earlier comments that sections 1, 2, and 3 are superfluous. I partially agree with an earlier comment that they serve the purpose of introducing the background material for newcomers, but unless the sections are introduced as "introductory", they do seem to delay getting to the meat of the matter. Regards, Gary _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ ______ _/ _/ | /// | TM Gary Hanson gary@kentrox.com _/ _/ | ADC|Kentrox P.O. Box 10704 503-641-3321 (FAX) _/ _/ |______| Portland, Oregon 97210 800-733-5511 x6333 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08329; 29 Dec 94 17:29 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08325; 29 Dec 94 17:29 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20092; 29 Dec 94 17:29 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA159392282; Thu, 29 Dec 1994 12:18:02 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gatekeeper.mcimail.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA159082276; Thu, 29 Dec 1994 12:17:56 -0800 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA20099; Thu, 29 Dec 94 20:21:44 GMT Received: from mcimail.com by mailgate.mcimail.com id av18273; 29 Dec 94 20:17 WET Date: Thu, 29 Dec 94 12:57 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Dwight <0006078043@mcimail.com> To: ip-atm Subject: Re: RFC Submission . . . . Message-Id: <93941229175739/0006078043DC2EM@MCIMAIL.COM> Rich Bradford wrote: > Craig, >> I think sections 1 through 3 are superfluous (they are simply a >> compressed intro to ATM and an RFC can assume a technical background >> by its reader). > I agree that they are superfluous for people on this list. However, > There are a lot of people who'll read it who'll be just cutting > their teeth on ATM (e.g. students). People advanced in a subject > can easily see when to skip forward, while a good introduction can > cut down on ramp-up. > > I'd recommend leaving it in. ----------------- I guess I'm ambivalent, but if we leave them (and especially if the reason we do so is to benefit folk new to ATM) they need to be correct. Here are some changes I would recommend: > [...] > > 2. ATM Protocol Stack: > > As it was mentioned before, the ATM architecture consists of three > layers, AAL, ATM and Physical layers. > > The AAL, Adaption ATM Layer, consists of two sublayers, Convergence > sublayer (CS), and Segmentation And Reassembly sublayer (SAR). > The Convergence Sublayer performs functions required by the AAL type, > and it is divided into two parts, CPCS (Common Part Convergence > Sublayer) and SSCS (Service Specific Convergence Sublayer). Whereas, > the SAR sublayer is responsible for segmenting higher level SDUs > (Servcie Data Unit) into 48 Octet cells. Also, at the other end, it is > responsible for reassembling the cells into an SDU before it passes it > up to a higher layer. The spirit is correct but the terminology is not. The term "Service Data Unit" (SDU) refers to the "payload" at the layer of interest. The term "Protocol Data Unit" (PDU) refers to payload + header/trailer. In the above, it would be more correct to state that "SAR sublayer is responsible for segmenting higher level PDUs (Protocol Data Units)..." > The ATM layer builds the 53 Octet cell by adding a 5 octet header to > each cell. Then, it multiplexes the cells into a constant cell stream > before it passes it down to the Physical layer. I'm not sure what the last sentence means. Generally, multiplexing is not considered a protocol function. I'm also not sure what is meant by "constant cell stream". > The Physical layer consists of two sublayers, Transmission Convergence > (TC) and Physical Medium (PM) sublayers. TC sublayer is responsible UNI 3.0 refers to the latter as "Physical Medium Dependent (PMD)". To avoid confusion we should probably use the same terminology. > [...] > The ATM layers are summarized in the figure below: > > > --------------------- > | CPCS | > |.....................| AAL Layer > | SSCS | > --------------------- > | ATM | ATM Layer > --------------------- > | TC | > |.....................| Physical Layer > | PM | > --------------------- This figure has SSCS and CPCS inverted. SSCS should be "on top", since this layer is logically between the User Part and CPCS. The text should probably also indicate somewhere that SSCS is optional. > 3. AAL Classes of Service: > > Several classes of service have been defined to cover all different > applications that are/will be supported by ATM protocol (Audio, Video > Connectionless, and Connection-Oriented). The different classes of > service are Class A or CBR (Constant Bit Rate), Class B or VBR > (Variable Bit Rate), Class C or UBR (Unspecified Bit Rate), Class D or > VBR with no timing information, and finally ABR Class (Available Bit > Rate). The above seems to want to map ITU B-ISDN service classes, to their 'common names'. Its mapping is incorrect, however; I believe Class B is "real-time" VBR, Class C is "non-realtime" VBR, Class D is a [non-realtime] connectionless service, Class X is UBR and Class Y is ABR. > CBR or Class A supports real time applications that contain video or > audio information and that are carried over fixed rate circuits. AAL1 > fits in this class. It isn't correct to say "AAL1 fits in this [or any other] class". AAL1 is not a service. It [and all AAL's] is a protocol, designed to meet the requirements of a service category. This might be better worded "AAL1 is designed to meet the requirements of this service class". > VBR or class B supports real time applications with variable source > rate and timing relationship between the source and the destination. > AAL2 fits in this group. No and no. See previous 2 comments. > UBR or Class c supports applications that do not utilize CBR > efficiently, where real time delay is not an issue, however loss is > such as TCP/IP protocol. AAL5 fits in this group. No and no. See previous 2 comments. > VBR with no timing information or class D is very similar to VBR but > with no timing relationship between the source and the > destination. This is suitable for data protocols that are sensitive to > loss but not delay such as SMDS. AAL3/4 fits in this group. No and no. See previous 2 comments. > [...] ------------------------------------------------------------------------ Tim Dwight MCI Advanced Systems Architecture tdwight@mcimail.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09070; 29 Dec 94 18:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09065; 29 Dec 94 18:07 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21006; 29 Dec 94 18:07 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA164138403; Thu, 29 Dec 1994 14:00:03 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from faline.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA163758397; Thu, 29 Dec 1994 13:59:57 -0800 Received: (from mwg@localhost) by faline.bellcore.com (8.6.9/8.6.6) id QAA26253; Thu, 29 Dec 1994 16:59:48 -0500 Date: Thu, 29 Dec 1994 16:59:48 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark W Garrett Message-Id: <199412292159.QAA26253@faline.bellcore.com> To: ip-atm@matmos.hpl.hp.com Subject: Re: RFC Submission . . . . Cc: tdwight@mcimail.com > Tim Dwight writes: > I guess I'm ambivalent, but if we leave them (and especially if the > reason we do so is to benefit folk new to ATM) they need to be correct. > Here are some changes I would recommend: Some clarification about the QOS stuff, although it's immaterial to the RFC if the section gets turned into references only. However this may help folks who wonder why ATM QOS definitions sometimes seem inconsistant. (Unfortunately, it's because there are several versions, written years apart, which *are* inconsistent.) > The above seems to want to map ITU B-ISDN service classes, to their > 'common names'. Its mapping is incorrect, however; It's true that Abir Hnidi is mixing up several of the myriad interpretations of ATM service definition. Basically the A, B, C, D labels refer to AAL-style service classes which are documented in ITU recommendation I.362 (see also dePrycker's book, sec 3.7, and the UNI 3.0 spec, sec A.4.1). The CBR, r-t-VBR, n-r-t-VBR, UBR, ABR are the service categories being hammered out now in the ATM Forum Traffic Management WG. These can eventually be referenced in the ``ATM Forum Traffic Management Specification Version 4.0'', which is supposed to be finalized around April 1995. (If you're curious about these, you can find the ATM forum contribution that Hnidi cites in URL, ftp://thumper.bellcore.com/pub/mwg/ATMF.qos.mwg. Although, please note that the text is only a contribution---the final documentation will be subject to editing and revision. As a rule Forum contributions, like IDs, should not be referenced, since they are not generally published.) So these are two different QOS architectures and they don't map onto one another neatly, although some of the things do coincide, like A = CBR. There is another, older stab that ITU took at this, which is the ATM Bearer Capabilities. These are labeled A, B, C, D and X, and are actually the origin of the service classes which are closely associated with the AALs, labeled 1, 2, 3/4, 5. The BC stuff is documented, if tersely, in ITU F.811 and F.812. > I believe Class B is "real-time" VBR, Yes, these map pretty well. > Class C is "non-realtime" VBR, Yes, although there are several flavors, e.g. in the recent ATMF model UBR, n-r-t-VBR and ABR are all non-realtime and variable rate. > Class D is a [non-realtime] connectionless service, Yes. > Class X is UBR and No. Class X is a bearer capability that says the user identifies a couple of Bearer Capability attributes (constant/variable rate, timing information, and connection-less/oriented). UBR is a Forum service category that doesn't have firmly specified rates or delays--- essentially what people understand by the term "best effort". UBR and Class-X should not be equated. > Class Y is ABR. I believe that T1 changed "Class-Y" to "ABR" to reflect what is going on in the Forum. This stuff is too volatile now to write down. Best to cite the Forum TM document when it issues after April. -Mark ------------------------------------------------------------------------------- Bellcore Rm. 2L-237 +1 201 829-4439 Mark W. Garrett 445 South St. mwg@faline.bellcore.com Morristown NJ 07960-6438 USA (FAX 201 829-2504) WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html -------------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11025; 29 Dec 94 22:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11021; 29 Dec 94 22:47 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26562; 29 Dec 94 22:47 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA176775148; Thu, 29 Dec 1994 18:39:08 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from monica.dsc.ufpb.br by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA176455054; Thu, 29 Dec 1994 18:37:34 -0800 Received: by monica.dsc.ufpb.br (4.1/SMI-4.1) id AA01536; Thu, 29 Dec 94 23:34:15 EDT Date: Thu, 29 Dec 1994 23:14:21 -0200 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Helder L. S. da Rocha {Pos. COPIN/Prof. Ulrich 09" Subject: Re: RFC Submission . . . . To: Jon Postel Cc: rbradfor@lightstream.com, gja@thumper.bellcore.com, craig@aland.bbn.com, stev@ftp.com, laubach@terra.com21.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net In-Reply-To: <199412291700.AA04198@zephyr.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Dec 1994, Jon Postel wrote: > > Hi. > > How about making it two documents: > > (1) intro to ATM, and > > (2) this particular way of doing IP over ATM. > > --jon. > That's a great idea. It would be even better if that "intro to ATM" document was published as a detailed FYI (to keep it always up to date), providing basic ATM concepts, that could be used as an introduction to all future ATM-related RFCs. -- Helder Rocha M.D. Student at Federal University of Paraiba - BRAZIL   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03656; 30 Dec 94 12:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03652; 30 Dec 94 12:20 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10758; 30 Dec 94 12:20 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA221034621; Fri, 30 Dec 1994 08:23:42 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from venera.isi.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA220724618; Fri, 30 Dec 1994 08:23:38 -0800 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 30 Dec 1994 08:22:02 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Posted-Date: Fri, 30 Dec 1994 08:20:03 -0800 (PST) Message-Id: <199412301620.AA06476@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Fri, 30 Dec 1994 08:20:07 -0800 Subject: Re: RFC Submission . . . . To: Andy Malis Date: Fri, 30 Dec 1994 08:20:03 -0800 (PST) Cc: laubach@terra.com21.com, gja@thumper.bellcore.com, rbradfor@lightstream.com, craig@aland.bbn.com, stev@ftp.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net, malis@maelstrom.timeplex.com In-Reply-To: <199412291901.OAA13195@maelstrom.acton.timeplex.com> from "Andy Malis" at Dec 29, 94 02:01:06 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 731 Andy sez: After thinking about it a bit more, I would like to add a second comment. The RFC should include somewhere a note explicitly stating that while stations using the DXI interface can interoperate with each other, they cannot interoperate with non-DXI (i.e. native ATM) RFC 1577 implementations. It should also state that the association between destination IP addresses and PVC VPI/VCIs has to be manually configured (there is no ARP functionality). To which I echo This item has the potential for serious problems in NAP transition and should be in a document that is detailing the existing conditions at the ATM-NAPS. (It was brought up in the several early NAP coordination mtgs and was handwaved) --bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04491; 30 Dec 94 14:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04487; 30 Dec 94 14:14 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13340; 30 Dec 94 14:14 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA225100644; Fri, 30 Dec 1994 10:04:04 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA224790639; Fri, 30 Dec 1994 10:03:59 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id NAA04838; Fri, 30 Dec 1994 13:00:49 -0500 Message-Id: <199412301800.NAA04838@curtis.ansremote.com> To: bmanning@isi.edu Cc: Andy Malis , laubach@terra.com21.com, gja@thumper.bellcore.com, rbradfor@lightstream.com, craig@aland.bbn.com, stev@ftp.com, stev-iesg@ftp.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@ns.mci.net Reply-To: curtis@ans.net Subject: Re: RFC Submission . . . . In-Reply-To: Your message of "Fri, 30 Dec 1994 08:20:03 PST." <199412301620.AA06476@zed.isi.edu> Date: Fri, 30 Dec 1994 12:59:30 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <199412301620.AA06476@zed.isi.edu>, bmanning@isi.edu writes: > Andy sez: > > > After thinking about it a bit more, I would like to add a second > comment. The RFC should include somewhere a note explicitly stating > that while stations using the DXI interface can interoperate with each > other, they cannot interoperate with non-DXI (i.e. native ATM) RFC > 1577 implementations. It should also state that the association > between destination IP addresses and PVC VPI/VCIs has to be manually > configured (there is no ARP functionality). > > > To which I echo > > This item has the potential for serious problems in NAP transition > and should be in a document that is detailing the existing conditions > at the ATM-NAPS. (It was brought up in the several early NAP > coordination mtgs and was handwaved) > > --bill Bill, There is product on the horizon (alpha in a month or two) that will take care of this by allowing different VC on the same interface use different encapsulations. This was discussed briefly at the last meeting as a means of accomplishing a smooth transition (I think you were there, so you must have missed this point). Any pair of NAP attachments can then agree to transition to RFC-1483 between that pair only and not affect RFC-1490 VCs to sites that haven't upgraded. There are some possible performance issues during the transition, but that is a matter of how the products themselves are designed. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05370; 30 Dec 94 15:59 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05366; 30 Dec 94 15:59 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16244; 30 Dec 94 15:59 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA229737256; Fri, 30 Dec 1994 11:54:16 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA229427249; Fri, 30 Dec 1994 11:54:09 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA25839; Fri, 30 Dec 94 13:51:57 EST Received: from rgc ([199.118.103.103]) by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA15429; Fri, 30 Dec 94 13:53:53 EST Message-Id: Date: Fri, 30 Dec 94 13:50:50 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: Re: framework revisions Reply-To: Robert.G.Cole@att.com To: curtis@ans.net, "Robert G. Cole" Cc: Grenville Armitage , IP over ATM , "Shur, David" X-Mailer: VersaTerm Link v1.1.3 Curtis, > > >> >Just one more - will you be explicitly 'flagging' the association >> >between existing RFCs and some the models/reasons you'll be describing? >> >I would like the Framework doc to help newcomers understand the existing >> >ip-atm WG docs in addition to providing a general overview. >> >> We took a crack at attempt this, by putting in the last section in the >> document (see Section 6) a table cross referencing the various models >> and the WG's documents. However, I am not sure that a simple table is >> enough and that more text may be required. Let us know what you think? > >That table sufferred from the gross inadequacy of the categorization >scheme. If we get a better categorization, we have a better chance of >putting together a meaningful table. > >Curtis > I hope that this will be the case, that an improved categorization (and I think we are heading in this direction) will make the table more meaningful. Bob Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05506; 30 Dec 94 16:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05502; 30 Dec 94 16:13 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16557; 30 Dec 94 16:13 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA230277479; Fri, 30 Dec 1994 11:57:59 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA229967469; Fri, 30 Dec 1994 11:57:49 -0800 Received: from hogpa.ho.att.com by ig1.att.att.com id AA28027; Fri, 30 Dec 94 14:08:53 EST Received: from rgc ([199.118.103.103]) by hogpa.ho.att.com (4.1/EMS-1.0.2 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA18296; Fri, 30 Dec 94 14:10:43 EST Message-Id: Date: Fri, 30 Dec 94 14:07:40 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert G. Cole" Subject: Re: framework revisions Reply-To: Robert.G.Cole@att.com To: curtis@ans.net, "Robert G. Cole" Cc: Robert.G.Cole@att.com, IP over ATM , "Shur, David" X-Mailer: VersaTerm Link v1.1.3 Curtis, > >I don't think your ATM CLNS SMDS over ATM model has not shown even as >much support within this group yet than the Conventional model, so how >about if we leave your new model out unless you are prepared to first >write a draft describing it and try to gain support for the model from >the WG. I'd like to see you leave the description Convential as is, >although I would prefer getting rid of it entirely since it appears to >have no support in this group, no vendor support, and no implementations. > The intent was not to "create" new models. Again, this section of the document (section 3) is introductory to the rest of the text. We are proposing that this section present those aspect of ATM which lend it the flexibility to offer "multiple faces" to IP, hence the reason for the numerous subnet and end-to-end models discussed by the WG, and to set up the categorization of the models to follow. The example of IP over SMDS was offered as an example ATM subnet model not discussed by the WG. Maybe it is best to just drop the (not discussed) example in this section? Bob Robert G. Cole AT&T Business Multimedia Services, Technical Marketing rgc@qsun.att.com +1 908 949 1950 (voice) attmail!rgcole +1 908 949 8887 (fax) AT&T Bell Laboratories Room 3L-533 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05721; 30 Dec 94 16:57 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05717; 30 Dec 94 16:57 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18046; 30 Dec 94 16:57 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA232801015; Fri, 30 Dec 1994 12:56:55 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from primus.cstp.umkc.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA232491011; Fri, 30 Dec 1994 12:56:51 -0800 Received: by CSTP.UMKC.EDU (MX V4.1 AXP) id 59; Fri, 30 Dec 1994 14:55:57 CST Date: Fri, 30 Dec 1994 14:55:57 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nsimha@cstp.umkc.edu To: ip-atm@matmos.hpl.hp.com Message-Id: <00989B7D.EAE0B7FC.59@CSTP.UMKC.EDU> Subject: Please remove me from this list..... Please remove me from this list. Yes, I did try sending this request to the 'right' place( several times in fact) but, the listserver cannot find my address on ip-atm list. Thank you, Regards Nick Simha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05982; 30 Dec 94 17:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05978; 30 Dec 94 17:54 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19124; 30 Dec 94 17:54 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA235793877; Fri, 30 Dec 1994 13:44:37 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from jack.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA235483870; Fri, 30 Dec 1994 13:44:30 -0800 Received: (kzm@localhost) by jack.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA24440; Fri, 30 Dec 1994 13:44:15 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199412302144.NAA24440@jack.cisco.com> Subject: Re: RFC Submission . . . . To: stev@ftp.com Date: Fri, 30 Dec 94 13:44:15 PST Cc: topolcic@bbn.com, ip-atm@matmos.hpl.hp.com, rfc-editor@isi.edu, ahnidi@mci.net In-Reply-To: <9412281506.AA26414@mailserv-D.ftp.com>; from "stev@ftp.com" at Dec 28, 94 10:06 am X-Mailer: ELM [version 2.3 PL11] > 7. DXI ILMI (Interim Local Management Interface): > > The ATM forum has developed the Interim Local Management Interface > (ILMI) to address the management functions of ATM interfaces. MIBII > modules have been defined for the following functions: > * ATM Interface Confirmation Group > * ATM Interface DS3 PLCP Group > * ATM Interface TC Sublayer Group > * ATM Interface Virtual Link (VPL/VCL) Configuration Group. > * ATM VP/VC Cross Connect Group > * AAL5 Connection Performance Statistics Group > Details of the functionality of these groups are covered in RFC1695 I suggest deleting all but the first sentence of the above. While the two sentences are individually correct, the implied relationship between them is incorrect: it wrongly suggests that the RFC1695 MIB is accessible via the ILMI, which it is not (or at least not according to any standard). It is the ILMI MIB (latest definition is in the UNI 3.1 spec) which is accessible via the ILMI, as suggested in a subsequent paragraph. (Note that RFC1695 contains a comparison of the overlap between its own MIB and the ILMI 3.0 MIB). This wrong impression is especially unfortunate because the use of SNMP packet formats by the ILMI tends to lead to confusion as to the ILMI's purpose. The subsequent diagram is helpful in this regard. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06743; 30 Dec 94 20:15 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06739; 30 Dec 94 20:15 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21742; 30 Dec 94 20:15 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA241522220; Fri, 30 Dec 1994 16:03:40 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from curtis.ansremote.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA241212215; Fri, 30 Dec 1994 16:03:35 -0800 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id RAA07155; Fri, 30 Dec 1994 17:01:21 -0500 Message-Id: <199412302201.RAA07155@curtis.ansremote.com> To: Robert.G.Cole@att.com Cc: curtis@ans.net, "Robert G. Cole" , IP over ATM , "Shur,\ David" Reply-To: curtis@ans.net Subject: Re: framework revisions In-Reply-To: Your message of "Fri, 30 Dec 1994 14:07:40 EST." Date: Fri, 30 Dec 1994 17:01:11 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message , "Robert G. Cole" writes: > Curtis, > > > > >I don't think your ATM CLNS SMDS over ATM model has not shown even as > >much support within this group yet than the Conventional model, so how > >about if we leave your new model out unless you are prepared to first > >write a draft describing it and try to gain support for the model from > >the WG. I'd like to see you leave the description Convential as is, > >although I would prefer getting rid of it entirely since it appears to > >have no support in this group, no vendor support, and no implementations. > > > > The intent was not to "create" new models. Again, this section of the > document (section 3) is introductory to the rest of the text. We are > proposing that this section present those aspect of ATM which lend > it the flexibility to offer "multiple faces" to IP, hence the reason for > the numerous subnet and end-to-end models discussed by the WG, and > to set up the categorization of the models to follow. The > example of IP over SMDS was offered as an example ATM subnet > model not discussed by the WG. Maybe it is best to just drop the (not > discussed) example in this section? > > Bob Bob, The IP over ATM (or really the almost anything over ATM) standards world is already considerably fragmented due to too many ways to do the same thing and not enough consensus on which are better or even worth doing. I'd rather the framework document made the choices more obvious rather than add to the confusion. We can concentrate on those things for which consensus has been formed and also give fair treatment to reasonable proposals that have surfaced and have at least enough consensus to be considered worth further discussion and later consideration. I'd like to see us document where we are now and where we are or may be headed, rather than document all the ratholes we've been through. Adding mention of more possible models that no one has even discussed does not further that goal. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11810; 1 Jan 95 0:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11806; 1 Jan 95 0:27 EST Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23601; 1 Jan 95 0:27 EST Received: by matmos.hpl.hp.com (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA021183640; Sat, 31 Dec 1994 20:14:00 -0800 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from noc.msc.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/15.5+ECS 3.3+HPL1.1SU) id AA020873632; Sat, 31 Dec 1994 20:13:52 -0800 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA11948; Sat, 31 Dec 94 22:12:22 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Received: (salo@localhost) by uh.msc.edu (8.6.8.1/8.6.6) id WAA09272; Sat, 31 Dec 1994 22:12:21 -0600 Date: Sat, 31 Dec 1994 22:12:21 -0600 Message-Id: <199501010412.WAA09272@uh.msc.edu> To: ahnidi@mci.net, ip-atm@matmos.hpl.hp.com Subject: Re: RFC Submission . . . . Cc: atm-nap@msc.edu, rfc-editor@isi.edu, stev-iesg@ftp.com, topolcic@bbn.com Some comments on sections 4, 5 and 6 of the proposed RFC RTransmitting IP over ATM AAL5 using DXI protocolS by Abir Hnidi of MCI (ahnidi@mci.net) follow. I have the following major comments about these sections: 1) The DXI specification does not say that RFC 1490 encapsulation, or any other encapsulation, is to be used. To the contrary, the specification states: RAll modes of operation of the DXI are capable of transparently supporting Service Specific Convergence Sublayers (SSCS) and other higher layers.S Later, the specification continues: RThe use and support of the SSCS is beyond the scope of this document.S As a result, the DXI specification does not assume RFC 1490, RFC 1483, or any other encapsulation. To the contrary, it explicitly allows any encapsulation. One implication of this is that the sections of the document which describe the DXI formats and protocols should contain no reference to RFC 1490. [Another, broader result is that the document ought to specify RFC 1577 rather than RFC 1490 encapsulation. I (hope that I) will expand on this topic in another mail message.] 2) The document needs to be more clear about when it is describing the ATM DXI formats and protocols, (the protocols that cross the, e.g., HSSI cable between the DTE and the DCE), and the formats and protocols that cross the UNI and the ATM network. The former, (DXI), are primarily of interest to router and ADSU vendors, while the latter are of interest to those trying to ensure interoperability across an ATM network. DXI UNI UNI DXI --------- ------ ------------- ------ -------- | Router |---| ADSU |---| ATM Network |---| ADSU |---| Router | --------- ------ ------------- ------ -------- |-----| |-----------------------| |-----| DXI end-to-end protocol DXI Note that the formats and protocols used across the ATM network need not be implemented by a router/ADSU pair; a workstation or router with a native ATM interface could implement the same formats and protocols. The Router/ADSU and ATM host would interoperate, if they both implement the same protocol. DXI UNI UNI -------- ------ ------------- ----------------- | Router |---| ADSU |---| ATM Network |---| ATM host/router | -------- ------ ------------- ----------------- |-----| |-----------------------| DXI end-to-end protocol This line of reasoning, at its extreme, could lead to the conclusion that the DXI formats and protocols are largely extraneous to the document, because they are largely unrelated to interoperability across the ATM network. Specifically, the DXI formats and protocols are relevant only to the extent that they constrain the end-to-end protocol, (such as limiting the maximum SDU size or range of permissible VCI/VPIs). I will ignore this possible conclusion long enough to make some comments on the summary of the DXI specification contained in the document. 3) These sections should more accurately reflect the DXI specification. I have tried to indicate areas where these section differ from the DXI spec. 4) The document ought to state that only PVCs are used. Additional comments will [allegedly] follow in future mail messages. Tim Salo salo@msc.edu salo@cray.com (612) 337-3555 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 4. ATM DXI Protocol: > > The ATM DXI protocol has been defined to allow a DTE (Router) and a > DCE (ATM DSU) to co-operate to provide a User-Network Interface to > an ATM switch, as it is shown below: > > --------- ------ ------------ > | Router |----| ADSU |---------| ATM Switch | > --------- ------ ------------ > DXI UNI > > The DTE encapsulates a higher layer SDU into DXI frame which supports > up to 65526 octet long SDU. ^^^^^ This is a bit confusing; Mode 1a and Mode 1b support only 9232 octet SDUs. Also, Mode 2 supports 65,535 octet SDUs Note that the SDU contains 4 bytes of AAL3/4 CPCS_PDU Header and 4 bytes of AAL3/4 CPCS_PDU Trailer, (even if AAL5 is used across the UNI). This seems to leave 65,527 octets for the AAL5 payload. > The encapsulation method is covered in > details in RFC 1490. Actually, the DXI spec says nothing about higher-level encapsulation. For example, either RFC 1490 or RFC 1483 encapsulation could be used, at least as far as the DXI specification is concerned. In other words, the choice of whether to use 1490, 1483/1577, null or some other encapsulation is completely up to the DTE (router) according to the DXI specification. I believe this is also true with respect to the two dominant ADSU implementations. > The DTE passes the DXI frame through the DXI > physical level to an ADSU (Physical layer uses V35, EIA/TIA 449/530, > or EIA/TIA 612/613 HSSI Interface). The ADSU receives the DXI frame, > strips off the DXI header and trailer, and encapsulates the DTE-SDU in > AAL5 CPCS-PDU. Then, the ADSU performs both the SAR and the ATM layer > functions before it sends the cells out across the UNI connection to > the ATM switch. In Mode 2, the AAL3/4 CPCS_PDU Header and Trailer are also stripped. > The whole process is explained in the figure below: > > ------- --------------- > | SDU | | DTE SDU | > ------- --------------- > | | | | CPCS | > | DXI | | DXI |.......| > | DLK | | DLK | SAR | > | | | |-------| --------- > | | | | ATM | | ATM | > ------- --------------- --------- > |DXI PHY|-----|DXI PHY|UNI PHY|---------| ATM PHY | > ------- --------------- --------- > DTE DXI DCE (ADSU) UNI ATM Switch > > > 5. ATM DXI Frame Format: > > The DXI frame level (Data Link Level) was derived from HDLC protocol > where three mode of operations were defined: > * Mode 1A: AAL5 only > * Mode 1B: AAL3/4 for at least one VC. AAL5 for other VCs. > * Mode 2 : AAL5 and AAL3/4, one per VC. > > The format of the frame sent between the DTE and the DCE (ADSU) varies > depending on the AAL it uses. However, only AAL5 format is discussed > in this memo. > > The DXI frame format for Mode 1A and Mode 1B using AAL5 is shown > below: > > 8b 16 bits 0 =< n = < 9232 Oct 16/32b 8b ^^ Should be R ----------------------------------------------------- > | F | DXI Header | DTE-SDU | DXI FCS | F | > ----------------------------------------------------- > / \ > / \ > > ---------------------------------------------------- > | DFA | RS | 0 | DFA |CN|RS|CLP| 1 | > ---------------------------------------------------- > 6 bits 1b 1b 4 bits 1b 1b 1b 1b > > Where: > > DFA: DXI Frame Address > CN: Congestion Notification Bit > CLP: Cell Loss Priority Bit > RS: Reserved. And set to zero. > > The DXI frame format for Mode 2 using AAL5 is shown below: > > 8b 32 bits 0 =< n = < 9232 Octs 16/32b 8b ^^ Should be R ----------------------------------------------------- > | F | DXI Header | DTE-SDU | DXI FCS | F | > ----------------------------------------------------- Actually, the format is: 8b 32 bits 32 bits 0 =< n = < 65535 Octs ----------------------------------------------------------/ | F | DXI Header |AAL3/4 CPCS_PDU Header| DTE_SDU ----------------------------------------------------------/ 32 bits 32 bits 8b \------------------------------------------------------------- DTE_SDU Continued |AAL3/4 CPCS_PDU Trailer| DXI FCS | F | \------------------------------------------------------------- The DTE (router) inserts the AAL3/4 CCS_PDU Header and Trailer whether AAL3/4 or AAL5 is being used. The DCE (ADSU) strips the AAL3/4 CCS_PDU Header and Trailer when AAL5 is being used on the UNI. > / \ > / \ > > ----------------------------------------------------------- > | DFA | RS | 0 | DFA |CN|RS|CLP| 1 | DFA | > ----------------------------------------------------------- > 6 bits 1b 1b 4 bits 1b 1b 1b 1b 16 bits > > > 6. Mapping Mode 1 DXI DFA to VPI/VCI: It seems like if you describe the Mode 1 mapping between the DXI DFA and a VPI/VCI pair, you ought to do the same for Mode 2. > The DTE interface sends the DXI frame to the DCE (ADSU). The ADSU, > based on the DFA address in the DXI frame, maps the DFA address to > VPI/VCI values that are inserted in the cell header before it is > sent out to the ATM switch. > > The mapping between DXI DFA and VPI/VCI is explained by the example > below: > > Suppose that a DXI DFA address of 524. This is mapped by the ADSU into > VPI/VCI of 0/44 as follows: > > > b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 > 524 = 1 0 0 0 0 0 1 1 0 0 > > > b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 > ---------------------------------------------------- > |1 0 0 0 0 0 | RS | 0 |1 1 0 0|CN|RS|CLP| 1 | DXI Frame > ---------------------------------------------------- > 6 bits 1b 1b 4 bits 1b 1b 1b 1b > > > b2 b3 b4 b5 b0 b1 b6 b7 b8 b9 > ---------------------------------------------------- > | ....|0 0 0 0 |....| 1 0 1 1 0 0 | ........ | ATM Cell > ---------------------------------------------------- > <-----------------><----------------------> > VPI = 0 VCI = 44 >