Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12407; 1 Sep 93 16:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12403; 1 Sep 93 16:23 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa24214; 1 Sep 93 16:23 EDT Received: from Eng.Sun.COM ([129.145.1.4]) by Sun.COM (4.1/SMI-4.1) id AA09678; Wed, 1 Sep 93 12:34:31 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04970; Wed, 1 Sep 93 12:34:15 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22378; Wed, 1 Sep 93 12:31:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22372; Wed, 1 Sep 93 12:31:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19737; Wed, 1 Sep 93 12:31:51 PDT Received: from po4.andrew.cmu.edu by Sun.COM (4.1/SMI-4.1) id AA09210; Wed, 1 Sep 93 12:31:09 PDT Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA07393; Wed, 1 Sep 1993 15:28:38 -0400 Received: via switchmail; Wed, 1 Sep 1993 15:28:36 -0400 (EDT) Received: from unix11.andrew.cmu.edu via qmail ID ; Wed, 1 Sep 1993 15:28:17 -0400 (EDT) Received: from unix11.andrew.cmu.edu via qmail ID ; Wed, 1 Sep 1993 15:28:10 -0400 (EDT) Received: from VUI.Andrew.3.70.CUILIB.3.45.SNAP.NOT.LINKED.unix11.andrew.cmu.edu.pmax.ul4 via MS.5.6.unix11.andrew.cmu.edu.pmax_ul4; Wed, 1 Sep 1993 15:28:10 -0400 (EDT) Message-Id: Date: Wed, 1 Sep 1993 15:28:10 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "George Mather, Jr." To: atm@sun.com Subject: Subscribe Cc: X-Orig-Sender: atm-request@atm.eng.sun.com Please subscribe me to the ATM mail service. Iwas subscibed at one time, but have not received any mail and am assumong my name was purged. Thank You, George E. mather, Jr.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14237; 1 Sep 93 18:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14233; 1 Sep 93 18:42 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa29335; 1 Sep 93 18:42 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11047; Wed, 1 Sep 93 15:34:10 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA25683; Wed, 1 Sep 93 15:35:20 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22674; Wed, 1 Sep 93 15:31:38 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22668; Wed, 1 Sep 93 15:31:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07605; Wed, 1 Sep 93 15:31:45 PDT Received: from NAGY.FNAL.GOV ([131.225.220.13]) by Sun.COM (4.1/SMI-4.1) id AA15662; Wed, 1 Sep 93 13:16:07 PDT Date: Wed, 1 Sep 1993 14:43:20 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "H.A. Kippenhan Jr." To: atm@atm.eng.sun.com Message-Id: <930901144320.396002b9@fndcd.fnal.gov> Subject: Monthly Administrative posting X-Orig-Sender: atm-request@atm.eng.sun.com Hello ATM readers: I'm pleased to announce that the discussions on the E-mail list atm@atm.eng.sun.com are now being archived on the node NIC.HEP.NET (131.225.100.1). The files of interest can be found in directory ANON_FTP.LISTS-ARCHIVE.ATM.1993. The file names will be of the form: ATM-ARCHIVE.1992-** ATM-ARCHIVE.1993-** The latest file (August, 1993) now available is: ATM-1993-08 A couple of things of to note. I've taken the time to edit out the messages from people who insist on sending subscribe/remove requests to the list (rather than the atm-request address). Also, the archive isn't real-time; that is, a new file will appear early each month (in early October ATM-ARCHIVE.1993-09 will show up). The archive is now inclusive from October, 1992 through August, 1993. I'm indebted to a couple of very helpful readers of the list for their assistance in getting previous postings. Best regards. - Kipp - {~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~} { H.A. Kippenhan Jr. | Internet: Kippenhan@FNDCD.FNAL.GOV } { National HEPnet Management | HEPnet/NSI DECnet: FNDCD::KIPPENHAN } { Fermi National Accelerator Lab. | BITnet: Kippenhan@FNDCD.BITNET } { P.O. Box 500 MS: FCC-3E/368 | Telephone: (708) 840-8068 } { Batavia, Illinois 60510 | FAX: (708) 840-8463 } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00741; 2 Sep 93 2:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00710; 2 Sep 93 2:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aj01539; 2 Sep 93 2:44 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa22739; 2 Sep 93 1:00 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01701; Wed, 1 Sep 93 11:50:48 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01311; Wed, 1 Sep 93 11:51:42 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22292; Wed, 1 Sep 93 11:48:18 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22286; Wed, 1 Sep 93 11:48:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15271; Wed, 1 Sep 93 11:48:20 PDT Received: from sally.informatik.rwth-aachen.de by Sun.COM (4.1/SMI-4.1) id AA00980; Wed, 1 Sep 93 11:47:39 PDT Received: from urmel.informatik.rwth-aachen.de by sally.informatik.rwth-aachen.de (4.1/sally-2) id AA02667; Wed, 1 Sep 93 11:48:39 +0200 Received: from tom.informatik.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-10) id AA09408; Wed, 1 Sep 93 11:48:56 +0200 Received: From IKARUS/WORKQUEUE by tom.informatik.rwth-aachen.de via Charon-4.0A-VROOM with IPX id 100.930901115042.384; 01 Sep 93 11:50:25 -0100 Message-Id: To: atm@sun.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: katja@i4.informatik.rwth-aachen.de Organization: Informatik IV * RWTH Aachen Date: 1 Sep 1993 11:54:41 MEZ-1 Subject: ATM Multicast / Multipeer Facilities Priority: normal X-Mailer: Pegasus Mail/Mac v2.02 X-Orig-Sender: atm-request@atm.eng.sun.com Hi, Can anyone help me to get information about the ATM Multicast / Multipeer facilities. I am looking for technical reports, publications, CCITT recommondations dealing with this topic. Any info will be very much appreciated. Thanks in advance Katja Keimer Department of Computer Science RWTH Aachen katja@i4.informatik.rwth-aachen.de   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29562; 6 Sep 93 21:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29558; 6 Sep 93 21:37 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa13207; 6 Sep 93 21:37 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18916; Mon, 6 Sep 93 18:33:51 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16315; Mon, 6 Sep 93 18:35:15 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA00712; Mon, 6 Sep 93 18:23:23 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA00706; Mon, 6 Sep 93 18:23:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03714; Mon, 6 Sep 93 18:23:27 PDT Received: from ics.uci.edu (paris.ics.uci.edu) by Sun.COM (4.1/SMI-4.1) id AA18618; Mon, 6 Sep 93 18:23:18 PDT Received: from valentine.ics.uci.edu by Paris.ics.uci.edu id aa09675; 6 Sep 93 17:12 PDT To: atm@sun.com, cell-relay@mythos.ucs.indiana.edu, comp-protocols-tcp-ip@ucbvax.berkeley.edu, frftc@nsco.network.com, members@farnet.org, nren-discuss@psi.com, rem-conf@es.net, smdstc@nsco.network.com, wireless@tandem.com, isdn%list.prime.COM@ics.uci.edu Cc: suda@valentine.ics.uci.edu Reply-To: suda@ics.uci.edu Subject: IEEE Comp. Comm. Workshop: Call for Participation Date: Mon, 06 Sep 1993 17:11:33 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tatsuya Suda Message-Id: <9309061712.aa09675@Paris.ics.uci.edu> X-Orig-Sender: atm-request@atm.eng.sun.com Dear colleagues: Enclosed is an advance program of the 8th IEEE Workshop on Computer Communications along with a workshop registration form at the end of this message. I hope you will be able to join us in the workshop! Please note that the 6th IEEE Workshop on Local and Metropolitan Area Networks will be held at the same location right before this workshop. TS The 8th IEEE Workshop on Computer Communications IEEE COMMUNICATIONS SOCIETY Technical Committee on Computer Communications Sept.1, 1993 Dear Colleague: I am enclosing the advance technical program and registration materials for the 8th IEEE Workshop on Computer Communications sponsored by the Technical Committee on Computer Communications of the IEEE Communications Society. The workshop will be held October 17-20 at the L'Auberge Del Mar Resort and Spa, Del Mar (San Diego), California. This year we are holding the workshop in conjunction with the Metropolitan Area Network Workshop, October 13-16. This year we will continue to offer special rates for graduate students on a very limited basis. Each application for this rate must be accompanied by a letter by the student's advisor stating his/her qualifications. Only graduate students who are close to completion of a doctoral program and will receive the maximum benefit from the workshop need apply. Students will be selected primarily by postmark date as space allows. The L'Auberge Del Mar Resort and Spa is located in the exclusive seaside village of Del Mar. L'Auberge features 123 luxury guest rooms & suites; European health and beauty spa; fine dining; shopping; championship tennis courts; swimming and lap pools; all with a spectacular ocean view. It is twenty minutes from major San Diego tourist attractions and airport; less than a mile from Del Mar Racetrack. There is a footpath to the beach. It is a Four-star rated hotel recently affiliated with the prestigious Hotel Bel-Air. I am personally looking forward to exploring state of the art technology at this year's workshop with you. I am sure you will enjoy exciting discussions in this luxurious and tranquil setting. Sincerely, Tatsuya Suda Workshop Chair Department of Information and Computer Science University of California, Irvine Irvine, CA 92717-3425 phone: (714) 856-5474 fax: (714) 856-4056 internet: ieeewksp@ics.uci.edu ============================================================================= Technical Program IEEE Communications Society Technical Committee on Computer Communications 8th Annual Computer Communications Workshop L'Auberge Inn at Del Mar (San Diego), California October 17-20, 1993 Oct. 17: Registration Oct. 18-20: Technical Sessions _____________________________________________________________________________ The annual IEEE Computer Communications Workshop is dedicated to informative discussions and presentations of important and timely research in communications. The focus of this year's workshop is on current trends in network technology and management for broadband, optical and wireless networks. As novel technologies and services have begun to evolve toward a wider realization, new research issues have developed. This workshop has been organized to explore these issues in detail, permitting a technical understanding of their interrelatedness and laying a foundation for further research. _____________________________________________________________________________ _____________________________________________________________________________ Sunday, October 17 ____________________________________________________________________________ 5:00pm - 9:00pm Registration Wine & Cheese Reception _____________________________________________________________________________ _____________________________________________________________________________ Monday, October 18 _____________________________________________________________________________ 7:00am Registration Continental Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session I: Measurements of High Speed Networks Organizer: John Daigle (MITRE Corp.) Brief Description: Presentation and discussion of measurements taken from gigabit testbed networks will take place in this session. Tentative Speakers: Gary Minden (U. Kansas) and John Daigle (MITRE Corp.) Existing and Proposed Testing and Measurement in Gigabit Testbed Programs Arne Nilsson (NCSU) Traffic Characteristics in the VISTAnet Allison Mankin (Naval Research Labs) A Comparison of Measurement Results from the BLANCA and NRL High Speed Optical Network -- WANs and LANs Prominent speaker to be added _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session II: Local Area ATM Organizer: Thomas La Porta (AT&T Bell Labs) Tatsuya Suda (UC Irvine) Brief Description: ATM technologies, although originally targeted for use in wide area, public networks, are rapidly being harnessed by those in the LAN community. ATM's accommodation of high link speeds and multimedia capability have made it attractive in small, high- demand networked environments. Research issues raised by the introduction of ATM technology into the local environment will be discussed in this session. Tentative Speakers: Peter Newman (Adaptive Corp.) LAN Emulation for ATM Networks Vijay Kumar (AT&T Bell Labs) A Multimedia ATM LAN Al Leon-Garcia (U. Toronto) & You-Ze Cho (Kyungpook National University, Korea) Burst-Level Bandwidth Management in Local ATM Networks Thomas La Porta (AT&T Bell Labs) Homogeneous Signaling for ATM LANs, MANs, and WANs Victor Li (USC) and Irfan Khan (SRI Int'l) High Speed Network Traffic Modeling and Management _____________________________________________________________________________ 12:30pm- 2:30pm Lunch _____________________________________________________________________________ 2:30pm - 5:00pm Technical Session III: ATM Performance Issues - (half hour break at 3:30) Supporting Broadband Services Organizers: Jack Brassil (AT&T Bell Labs) Mark Karol (AT&T Bell Labs) Brief Description: B-ISDNs are expected to carry various forms of traffic (voice, video data), each of which places distinct requirements on network transport systems. The purpose of this session is to discuss performance issues associated with supporting various anticipated traffic types. Tentative Speakers: Kai Eng (AT&T Bell Labs) State of the Art in Gigabit ATM Switching Magda El Zarki & Pramod Pancha (U. Pennsylvania) Understanding VBR Video Sources for Transmission over ATM-based Networks Arvind Krishna, Hamid Ahmadi, Moshe Sidi & Khosrow Sohraby (IBM T.J. Watson) Delay and Jitter Analysis in Wireless Environments Izhak Rubin & Ho-Ting Wu(UCLA) Local and Metropolitan ATM Ring Networks: Throughput Capacity and Local Fairness Regulation Hisashi Kobayashi (Princeton) A Diffusion Approximation of ATM Traffic for Statistical Multiplexing _____________________________________________________________________________ 5:30pm Cocktail Party 8:30pm Town Hall Meeting _____________________________________________________________________________ _____________________________________________________________________________ Tuesday, October 19 _____________________________________________________________________________ 7:00am Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session IV: Multicast Communications Organizer: Nachum Shacham (SRI Int'l.) Tentative Speakers: Lixia Zhang (Xerox PARC) RSVP: A Multicast ReSerVation Protocol Mostafa Ammar (Georgia Inst. of Technology) Probabilistic Multicast: Generalizing the Multicast Paradigm to Improve Scalability" Nachum Shacham (SRI Int'l.) Hierarchical Multicast over ATM Deborah Estrin (USC) Wide-area Multicast Routing Support for Sparse Groups _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session V: Directions in Network Management Organizers: Carl Sunshine (Aerospace Corp.) Joseph Betser (Aerospace Corp.) Brief Description: Network management systems have been evolving rapidly, with competing technologies and many product offerings for both management stations and subnet monitors. Some standards are emerging, but problems of scalability, integration and security remain to be solved. This session will focus on exploring these issues. Tentative Speakers: Joseph Betser (Aerospace Corp.) Current Trends in Technology and Products Mike Erlinger (Harvey Mudd College and Aerospace Corp.) Subnet Monitoring and RMON Steve Waldbusser (CMU) New Developments with SNMP and SNMPv2 Liang Wu (Bellcore) Quality of Service Management in ATM Networks Yechiam Yemini (Columbia U) Management by Delegation _____________________________________________________________________________ 12:30pm- 2:30pm Lunch Break _____________________________________________________________________________ 2:30pm - 5:00pm Technical Session VI: Host Interface Design for (half hour break at 3:30) High Speed Networks Organizer: Sean O'Malley (U. Arizona) Brief Description: As network performance has increased, the network- host interface has emerged as a significant bottleneck in overall network performance. In addition, this increase in network performance has blurred some of the distinctions between WANs, LANs, distributed memory multiprocessor interconnection networks, and intrahost communication channels. Thus the traditional approach to network host interface design appears to provide neither the performance nor the flexibility required by modern computer systems. This session will include presentations of novel approaches to network host interface design. Tentative Speakers: Darleen Fisher (NSF) An Update on Gigabit Network Testbeds Danny Cohen (ISI) The ATOMIC LAN Bruce Davie (Bellcore) The OSIRIS ATM Interface: Experience and Insights Vineet Kumar (Intel) The Intel Paragon HIPPI Interface John Kubiantowicz (MIT LCS) Fast Messaging in the Alewife Multiprocessor David Tennenhouse (MIT LCS) The Design Space for Network Host Interface _____________________________________________________________________________ 6:00pm Dinner Banquet 8:30pm Town Hall Meeting _____________________________________________________________________________ _____________________________________________________________________________ Wednesday, October 20 _____________________________________________________________________________ 7:00am Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session VII: Optical Technology and the Future of Networking Organizers: Joseph Bannister (Aerospace Corp.) Biswanath Mukherjee (UC Davis) Brief Description: Optical technologies will provide the principal foundation for networks of the future. The trends, opportunities, risks and concerns with optical networks will be discussed. Tentative Speakers: Jon Sauer (U. Colorado) Deflection Routing Networks for Computer Interconnection Mario Gerla (UCLA) Cost-Technology Tradeoffs in Multifiber WDM Networks Tony Acampora and Tom Stern (Columbia) All-Optical Network Architectures Based on Wavelength Routing Vincent Chan (Lincoln Labs) Wideband Optical Network of the Future _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session VIII: Wireless Network Communications Organizer: Khosrow Sohraby (IBM - T.J. Watson) Brief Description: It is expected that, in the future, wireless networks will be supporting a broad range of services such as voice, data, and video. This session will deal with various challenging issues in such networks. Tentative Speaker: Hamid Ahmadi (IBM T.J. Watson) Design Issues for Wireless Local Area Networks S. Nanda (AT&T Bell Labs) A Data Link Protocol for Wireless Links Mahmoud Naghshineh (Columbia) An Architecture and Methodology for Mobile-Executed Cell Hand-off in Wireless ATM Networks Leandros Tassiulas (Polytechnic U.) Efficient Spectrum Management for High Capacity Wireless Networks _____________________________________________________________________________ 12:30pm - 1:00pm Wrap-up Session _____________________________________________________________________________ ============================================================================= REGISTRATION INFORMATION Registration with payment must be received by Monday, September 13, 1993. Registration received after this date cannot be guaranteed acceptance. Please mail or fax a copy of the registration form to: Robin Sharp Phone: (714) 856-5474 IEEE Computer Communications Workshop FAX: (714) 856-4056 Information and Computer Science University of California Irvine, CA 92717-3425 USA Please make checks payable to "IEEE 1993 Computer Communications Workshop". For workshop inquiries, you may contact us through email at: ieeewksp@ics.uci.edu. Cancellations/substitutions must be submitted in writing and received by Monday, September 13, 1993. Workshop fees include workshop attendance, refreshments at breaks, lunches, workshop reception and dinner banquet, and one copy of the conference materials. FEE: $275 *IEEE members $315 Nonmembers $100 Students (subject to approval) *IEEE members must include membership number to receive member discount. ============================================================================= REGISTRATION FORM First Name________________________ Last Name_________________________ Title__________________________________________________________________ Badge Name_____________________________________________________________ Company/Institution____________________________________________________ Address________________________________________________________________ City____________________ State_________ Country__________ Zip__________ Telephone____________________________ Fax______________________________ Email__________________________________________________________________ IEEE Member Number_____________________________________________________ Special Meal Requirements: Vegetarian__________ Kosher__________ Other(Specify)_____________ Amount Enclosed (must be in U.S. dollars) $____________ ============================================================================= The 8th IEEE Workshop on Computer Communications ACCOMMODATION INFORMATION A block of rooms has been reserved at: L'Auberge Del Mar Resort and Spa 1540 Camino Del Mar Del Mar (San Diego), California 92014 Phone: (619) 259-1515 or (800) 553-1336 Fax: (619) 755-4940 The hotel will hold these rooms until October 1, 1993. Hotel arrangements should be made directly to the hotel by phone or the reservation form provided. To receive the special rates (see reservation form), please mention you will be attending the IEEE Computer Communications Workshop. We are holding our workshop in conjunction with the IEEE Metropolitan Area Network Workshop which is being held October 13-16. ----------------------------------------------------------------------------- TRANSPORTATION INFORMATION It is recommended that you fly into San Diego for the easiest access to the workshop location. The San Diego Airport is serviced by all major airlines. If you need assistance with your travel arrangements, the hotel has an on-site travel agency, Ranch and Coast Travel at (619) 481-1230. International travellers may find more convenient flights into Los Angeles Airport. There are also flights available from Los Angeles Airport to San Diego Airport. If you choose not to fly into San Diego Airport from Los Angeles Airport, a rental car is necessary to travel from Los Angeles to the hotel. TRANSPORTATION FROM SAN DIEGO AIRPORT TO L'AUBERGE: Limousine service $40 (4-6 people) phone hotel for arrangements Super Shuttle $25 phone: (619) 278-8877 Taxi $35-40 DIRECTIONS TO L'AUBERGE DEL MAR RESORT AND SPA DIRECTIONS BY CAR: From San Diego Airport From John Wayne (Orange County) Airport (travel time: approximately (travel time: approximately 90 minutes) 20 minutes) and Los Angeles Airport (LAX) (travel time: approximately 3 hrs) Take I-5 North to Del Mar Heights Take 405 Fwy. to I-5 South Road, Take I-5 South to Via De La Valle exit Turn Left (west) on to Del Mar Turn Right (west) on to Jimmy Durante Heights Road, Blvd. (The road will veer left and Follow to Camino Del Mar. turn into Camino Del Mar). Turn Right at light on to Camino L'Auberge is located at the first Del Mar. stop light on the righthand (west) Continue to the intersection Camino side. Del Mar and 15th Street. L'Auberge is located on the westside corner. ============================================================================ L'AUBERGE DEL MAR RESORT AND SPA 1540 CAMINO DEL MAR CALIFORNIA 92014 619-259-1515 Fax-619-755-4940 Nationwide-800-553-1336 HOTEL RESERVATION FORM GROUP NAME: IEEE Communications Society/Technical Committee on Computer Communications Workshop GROUP DATES: OCTOBER 17TH - 21ST, 1993 PLEASE CIRCLE DESIRED ACCOMMODATIONS: $110.00 - Single $120.00 - Single/Garden View $125.00 - Double $130.00 - Double/Garden View $250.00 - Suite $350.00 - Suite ______________________________________________________________________ LAST NAME FIRST NAME PHONE NUMBER ______________________________________________________________________ ADDRESS ARRIVAL DATE:__________ ARRIVAL TIME:________ DEPART. DATE:__________ PLEASE INCLUDE FIRST NIGHT'S DEPOSIT OR CREDIT CARD NUMBER TO CONFIRM YOUR RESERVATION. CREDIT CARD #:______________________________ EXPIRATION DATE:_________ RESERVATIONS RECEIVED PRIOR TO 10/1/93 RECEIVE PRIORITY CONSIDERATION AT L'AUBERGE DEL MAR. RESERVATIONS MADE AFTER THE ABOVE DATE WILL BE ON A SPACE AVAILABILITY BASIS ONLY. SUITES SUBJECT TO AVAILABILITY - PLEASE CALL THE HOTEL DIRECTLY. NO CHARGE FOR CHILDREN 17 OR UNDER IF STAYING IN ROOM WITH PAYING ADULT. RATES ARE SUBJECT TO 10% OCCUPANCY TAX. CHECK-IN TIME IS 4:00PM CHECK-OUT TIME IS 12 NOON. PLEASE CONTACT HOTEL FOR REQUESTS REGARDING EARLY CHECK-IN. ---------------------------------- SIGNATURE ============================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12765; 7 Sep 93 15:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12761; 7 Sep 93 15:11 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06643; 7 Sep 93 15:11 EDT Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13499; Tue, 7 Sep 93 12:05:18 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05628; Tue, 7 Sep 93 12:04:27 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA01879; Tue, 7 Sep 93 11:52:42 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA01873; Tue, 7 Sep 93 11:52:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04498; Tue, 7 Sep 93 11:52:42 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA11095; Tue, 7 Sep 93 11:52:35 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA17234; Tue, 7 Sep 93 11:49:41 -0700 Date: Tue, 7 Sep 93 11:49:41 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309071849.AA17234@matmos.hpl.hp.com> To: atm@eng.sun.com Subject: Last Call in WG for Classical IP draft X-Orig-Sender: atm-request@atm.eng.sun.com ATM'ers: Attached is the current Classical IP and ARP over ATM draft. A few nits and reference glitches have been cleaned up since the last post a couple weeks ago. Otherwise, things are looking pretty stable. I'd like to move this along the process and submit to the IESG on Monday the 13th if there are no outstanding technical issues with the memo. Please review it and get back to the list if there are any problems. Mark -------------------------------------------------------------------- Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires March 2, 1994 September 2, 1993 Classical IP and ARP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This document does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The Laubach [Page 1] DRAFT Classical IP and ARP over ATM September 1993 concepts and models presented in [1], written by Dave Piscitello and Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF and the ad hoc PVC committee at the Amsterdam IETF meeting. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TSS and ANSI standards for addressing in ATM. The characteristics and features of ATM networks are different than those found in LAN's: o ATM provides a virtual circuit switched environment. VC setup may be done on either a Permanent Virtual Circuit (PVC) or dynamic Switched Virtual Circuit (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). Laubach [Page 2] DRAFT Classical IP and ARP over ATM September 1993 o ATM standards provide several formats for the exchange of Protocol Data Units (PDU's), these formats are called ATM Adaptation Layers (AAL's). When a virtual circuit is created a specific AAL type is associated with the VC. This type is specified either by administrative control for PVC's or via signalling for SVC's. There are five different AAL format types, which are commonly referred to as "AALn", where "n" is a number from one 1 through 5. There is no field in an ATM cell header which carries this AAL type value, rather it is known at each hop of the path due to the call setup mechanism. The AAL5 format specifies a packet format with a maximum size of 64K - 8 user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating end of PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. o ATM-FORUM signalling defines point-to-point and point-to- multipoint circuit setup [9]. Multipoint-to-multipoint virtual circuits are not not yet a conformance requirement of the ATM- FORUM. o ATM-FORUM local LAN addresses (in the address resolution protocol context) use the same basic format as GOSIP NSAP's [11]. Note: ATM-FORUM addresses should not be construed at being GOSIP NSAP's, they are not, the administration is different, which fields get filled out are different, etc. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets. o IP destinations map to VC's via ARP and end-to-end IP routing stays essentially the same, consistent with current model. o ARP's stay within the LIS, current ARP architecture stays the same. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for Laubach [Page 3] DRAFT Classical IP and ARP over ATM September 1993 all these VC's. The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VC's (e.g., TCP and UDP ports map directly onto VC's) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Applications map directly to VC's, requiring changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's are global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per application and per VC basis. The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. o Standards for global IP over ATM will take some time to complete and deploy. Laubach [Page 4] DRAFT Classical IP and ARP over ATM September 1993 This memo details the treatment of the classical model of IP and ARP over ATM. There are those would like to have IP-over-ATM begin by breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is a station attached to the ATM network that is configured as a member of two or more LIS's. This configuration may result in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets would communicate via an intermediate router even though a direct virtual circuit between the two hosts may be available over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP protocol addresses to ATM hardware addresses via ARP [3] when using SVC's and for resolving ATM hardware addresses to IP protocol addresses via InARP [12] when using SVC's and PVC's. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pairs of stations. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network. Laubach [Page 5] DRAFT Classical IP and ARP over ATM September 1993 The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM address of the individual IP station. Each host must be configured to accept datagrams destined for this address o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM hardware address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target hardware addresses for SVC connections. That server must have authoritative responsibility for resolving ARP requests of all IP stations within the LIS. Note: if the LIS is operating with PVC's only, then this parameter may be set to null and the IP station is not required to send ARP requests to the ARP server. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams. This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the default ATM AAL5 protocol data unit size is 9188 octets. In classical IP subnets, values other than the default can only be used if and only if all stations in the LIS have been configured to use the non- Laubach [Page 6] DRAFT Classical IP and ARP over ATM September 1993 default value. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. ADDRESS RESOLUTION Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12] and all IP stations are required to support these protocols. Use of these protocols differ depending on whether permanent virtual circuits (PVC's) or switched virtual circuits (SVC's) are used. Permanent Virtual Circuits An IP station must have a mechanism for determining what PVC's it has, and in particular which PVC's are being used for LLC/SNAP encapsulated protocols. The details of the mechanism are beyond the scope of this memo. All IP stations supporting permanent virtual circuits are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those virtual circuits using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant virtual circuit from the virtual circuit on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM source and/or target hardware address is unknown, the corresponding hardware address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. From [12]: "When the requesting station receives the InARP reply, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances." It is the responsibility of each IP station supporting ATM permanent virtual circuits to re-validate ARP table entries as part of the aging process. See the section below on "ARP Table Aging - All Stations". Switched Virtual Circuits ATM switched virtual circuits require support for ARP in the non- broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for Laubach [Page 7] DRAFT Classical IP and ARP over ATM September 1993 resolving the ARP requests of all IP stations within the LIS. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point virtual circuit. The server, upon receiving a new virtual circuit specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. The ARP server mechanism requires that each client be administratively configured with the ATM hardware address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. This ARP server must be administratively configured so that it knows it is the ARP server. The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. This memo recognizes that a single ARP Server is not as robust as multiple servers which synchronize their databases correctly. This document is defining the client-server interaction by using a simple, single server approach as a reference model, and does not prohibit more robust approaches which use the same client-server interface. ARP Server Operational Requirements The ARP server accepts switched virtual circuit connections from other ATM stations. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM hardware address. The server will add (or update) the map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP hardware address does not match the table entry hardware address and there is an open virtual circuit associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table or a negative ARP reply (ARP_NAK). The ARP_NAK response is an extension to the ARP protocol and is used to improve the robustness of the ARP server mechanism. With ARP_NAK, a client Laubach [Page 8] DRAFT Classical IP and ARP over ATM September 1993 can determine the difference between a catastrophic server failure and an ARP table lookup failure. The ARP_NAK packet format is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for transmission with the ARP_REQUEST operation code reset to ARP_NAK. ARP table information timeout update: when the server receives an ARP request over a virtual circuit, and the source information (IP and hardware address) match the association already in the ARP table, and the hardware address matches that associated with the virtual circuit (in the SVC environment), then the server may update the timeout on the ARP table entry. ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh ARP information about other IP stations. ARP clients are required to: 1. Initiate the virtual circuit connection to the ARP server for transmitting and receiving ARP and InARP packets. 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP table entries. 5. Provide an ARP table aging function to remove old ARP tables entries after a convenient period of time. Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. ARP Table Aging - All stations A client or server must have knowledge of any open VC's it has (permanent or switched), their association with an ARP table entry, and in particular, which VC's support LLC/SNAP encapsulation. Laubach [Page 9] DRAFT Classical IP and ARP over ATM September 1993 Client ARP table entries are valid for a maximum time of 15 minutes. Server ARP table entries are valid for a minimum time of 20 minutes. Prior to aging (removing) an ARP table entry, all stations must generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the entry is deleted. ARP and InARP Packet Format Internet addresses are assigned independent of ATM-FORUM NSAP addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to ATM hardware addresses when needed. The ARP and InARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shln 8 bits Octet length of source hardware address (m) ar$spln 8 bits Octet length of source protocol address (n) ar$op 16 bits Operation code (request or reply) ar$thln 8 bits Octet length of target hardware address (p) ar$tpln 8 bits Octet length of target protocol address (q) ar$sha moctets source hardware address ar$spa noctets source protocol address ar$tha poctets target hardware address ar$tpa qoctets target protocol address Where: ar$hrd - assigned to ATM-FORUM NSAP address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$shln - length of the source hardware NSAP address length. ar$spln - length in bytes of the source protocol address. For IP ar$spln is 4. ar$op - The operation type value (decimal): Laubach [Page 10] DRAFT Classical IP and ARP over ATM September 1993 ARP_REQUEST = 1 ARP_REPLY = 2 InARP_REQUEST = 8 InARP_REPLY = 9 ARP_NAK = ?? ar$thln - length of the target hardware NSAP address length. ar$tpln - length in bytes of the target protocol address. For IP ar$tpln is 4. ar$sha - source NSAP address. ar$spa - source protocol address. ar$tha - target NSAP address. ar$tpa - target protocol address. The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be ATM-FORUM specified NSAP addresses [9]. The same NSAP encoding SHALL be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 hardware addresses may be used but not both. ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 octets) indicates that the following Laubach [Page 11] DRAFT Classical IP and ARP over ATM September 1993 two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. The LLC/SNAP encapsulation for ARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ARP'ing outside the LIS or by a global ARP mechanism are beyond the scope of this memo. 10. IP Broadcast Address ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict stations from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Stations, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. This memo recognizes the future development of ATM multicast service addressing by the ATM-FORUM. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward. 12. Security Security issues are not discussed in this memo. This memo recognizes the future development of ATM and IP facilities Laubach [Page 12] DRAFT Classical IP and ARP over ATM September 1993 for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this memo. 13. Open Issues o A proposal was put before the Internet Assigned Numbers Authority to approve a request to create an ARP hardware type of "ATM-FORUM NSAP address". IANA has not responded as of this date. o Well known ATM hardware address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. Laubach [Page 13] DRAFT Classical IP and ARP over ATM September 1993 [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", ATM-FORUM, 480 San Antonio Road, Suite 100, Mountain View, CA 94040, June 1993. [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, USC/Information Sciences Institute, August 1989. [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, USC/Information Sciences Institute, July 1991. [12] Bradely, T., and Brown, C., "Inverse Address Resolution Protocol", RFC1293, USC/Information Sciences Institute, January 1992. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 14]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17356; 7 Sep 93 21:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17352; 7 Sep 93 21:46 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26826; 7 Sep 93 21:46 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA08705; Tue, 7 Sep 93 18:43:33 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24263; Tue, 7 Sep 93 18:45:54 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA02497; Tue, 7 Sep 93 18:42:35 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA02491; Tue, 7 Sep 93 18:42:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01738; Tue, 7 Sep 93 18:42:43 PDT Received: from mulga.cs.mu.OZ.AU by Sun.COM (4.1/SMI-4.1) id AA08614; Tue, 7 Sep 93 18:42:32 PDT Received: from mullian.ee.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18134 Wed, 8 Sep 1993 11:42:27 +1000 (from gja@mullian.ee.mu.OZ.AU) Received: by mullian.ee.mu.OZ.AU (4.1) id AA25945; Wed, 8 Sep 93 11:42:26 EST Message-Id: <9309080142.25945@mullian.ee.mu.OZ.AU> To: Mark Laubach Cc: atm@eng.sun.com, gja@mullian.ee.mu.oz.au Subject: Re: Last Call in WG for Classical IP draft In-Reply-To: Your message of Tue, 07 Sep 1993 11:49:41 -0700. <9309071849.AA17234@matmos.hpl.hp.com> Date: Wed, 08 Sep 1993 11:42:25 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage X-Orig-Sender: atm-request@atm.eng.sun.com [..] >>Please review it and get back to the list if >>there are any problems. Hi Mark. I'm a bit of a lurker on this list, but I thought I'd make a comment (hopefully not too off beam :) [..] >>5. Introduction [..] >> o ATM standards provide several formats for the exchange of >> Protocol Data Units (PDU's), these formats are called ATM >> Adaptation Layers (AAL's). When a virtual circuit is created a >> specific AAL type is associated with the VC. This type is >> specified either by administrative control for PVC's or via >> signalling for SVC's. There are five different AAL format types, >> which are commonly referred to as "AALn", where "n" is a number >> from one 1 through 5. There is no field in an ATM cell header >> which carries this AAL type value, rather it is known at each hop >> of the path due to the call setup mechanism. I wonder whether the last half of the last sentence should in fact read ", rather it is known at each end of the path due to the call setup mechanism." It just strikes me that a 'hop' is between cell switches. If this is so, the present wording might be interpreted to mean that switch nodes play some part in the AAL function, which they don't. Of course, if 'hop' is meant as an IP-entity to IP-entity hop (thus between the termination points of a VCC) then your sentence is fine and I'll just slink back into lurk mode :-) regards, gja ========================================================================== Grenville Armitage | Dept. of Electrical Engineering |Internet gja@mullian.ee.mu.oz.au University of Melbourne | Parkville 3052 Victoria |voice +[61][3]344 9195 Australia |fax +[61][3]344 6678 ==========================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01651; 8 Sep 93 8:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01647; 8 Sep 93 8:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ab02094; 8 Sep 93 8:03 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa01042; 8 Sep 93 7:05 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02832; Wed, 8 Sep 93 01:36:22 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01714; Wed, 8 Sep 93 01:38:43 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03032; Wed, 8 Sep 93 01:34:36 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03026; Wed, 8 Sep 93 01:34:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11897; Wed, 8 Sep 93 01:34:38 PDT Received: from zurich.ibm.com by Sun.COM (4.1/SMI-4.1) id AA02683; Wed, 8 Sep 93 01:34:37 PDT Message-Id: <9309080834.AA02683@Sun.COM> Received: from ZURLVM1 by zurich.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3571; Wed, 08 Sep 93 04:34:39 EDT Date: Wed, 8 Sep 93 10:34:10 SET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jean-Yves Le Boudec To: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft X-Orig-Sender: atm-request@atm.eng.sun.com >>> o ATM standards provide several formats for the exchange of >>> Protocol Data Units (PDU's), these formats are called ATM >>> Adaptation Layers (AAL's). When a virtual circuit is created a >>> specific AAL type is associated with the VC. This type is >>> specified either by administrative control for PVC's or via >>> signalling for SVC's. There are five different AAL format types, >>> which are commonly referred to as "AALn", where "n" is a number >>> from one 1 through 5. There is no field in an ATM cell header >>> which carries this AAL type value, rather it is known at each hop >>> of the path due to the call setup mechanism. > >I wonder whether the last half of the last sentence should in fact >read ", rather it is known at each end of the path due to the call >setup mechanism." > >It just strikes me that a 'hop' is between cell switches. If this is >so, the present wording might be interpreted to mean that switch nodes >play some part in the AAL function, which they don't. Switching fabrics do not play any role in the AAL. However, if the Q.93B protocol is used hop by hop to setup the ATM connection, then the control software in every switch MAY know about the AAL type supported by the ATM connection. This is because the Q.93B setup message carries an AAL information element. However, this information element is optional, and is meant to be used between end-systems. Bear in mind though that the ATM Bearer Capability (caaried in setup mess mandatory) indicates the class of connection, and this maps directly to an AAL type. The class of connection addresses such things as whether end to end timing is needed (such as for AAL1) or not (such as for AAL5), whether a fixed bit rate is needed (AAL1 ) or not, etc. So, at the end, the intermediate switches do know something about the AAL type. Whether they use it is an implementation issue. JY LeB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01661; 8 Sep 93 8:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01657; 8 Sep 93 8:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ae02094; 8 Sep 93 8:03 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa01143; 8 Sep 93 7:23 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12534; Wed, 8 Sep 93 04:20:33 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09548; Wed, 8 Sep 93 04:22:11 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03291; Wed, 8 Sep 93 04:10:04 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03277; Wed, 8 Sep 93 04:10:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14781; Wed, 8 Sep 93 04:10:05 PDT Received: from iscp.bellcore.com by Sun.COM (4.1/SMI-4.1) id AA12177; Wed, 8 Sep 93 04:10:03 PDT Received: from doozer.iscp.bellcore.com by iscp.bellcore.com (AIX 3.1/UCB 5.61/4.03) id AA56094; Wed, 8 Sep 93 07:08:52 -0400 Received: by doozer.iscp.bellcore.com (AIX 3.2/UCB 5.64/4.03) id AA15252; Wed, 8 Sep 1993 07:08:57 -0400 Message-Id: <9309081108.AA15252@doozer.iscp.bellcore.com> To: Jean-Yves Le Boudec Cc: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft In-Reply-To: (Your message of Wed, 08 Sep 93 10:34:10 T.) <9309080834.AA02683@Sun.COM> Date: Wed, 08 Sep 93 07:08:56 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Alperin X-Orig-Sender: atm-request@atm.eng.sun.com please correct me where I am wrong, but "Jean-Yves Le Boudec" writes: Switching fabrics do not play any role in the AAL. However, if the Q.93B protocol is used hop by hop to setup the ATM connection, then the control software in every switch MAY know about the AAL type supported by the ATM connection. This is because the Q.93B setup message carries an AAL information element. However, this information element is optional, and is meant to be used between end-systems. My understanding is that Q.93B is only for the UNI, and once a "call" is initiated through Q.93B, the entire end-to-end connection of the VP will be established as an atomic entity using Q.93B at the ends and an NNI (B-ISUP, Q.93B+, ?) between the nodes. Does the above statement imply that the NNI will know what AAL is being used at the UNI? Does it imply that the "call" is set up as needed? I mean, this is not dynamic routing at each node, but rather a circuit across the network? Therefore, the Q.93B is not used 'hop-by-hop", and an entire ATM network should look like a single "hop" at the IP level, correct? jon alperin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04321; 8 Sep 93 10:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04317; 8 Sep 93 10:20 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa07133; 8 Sep 93 10:20 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24483; Wed, 8 Sep 93 07:15:13 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14636; Wed, 8 Sep 93 07:17:05 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03589; Wed, 8 Sep 93 07:03:30 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA03583; Wed, 8 Sep 93 07:03:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18361; Wed, 8 Sep 93 07:03:35 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (4.1/SMI-4.1) id AA23400; Wed, 8 Sep 93 07:03:31 PDT Received: by inet-gw-1.pa.dec.com; id AA23774; Wed, 8 Sep 93 07:03:28 -0700 Received: by flashy.tay2.dec.com (5.65/MS-081993); id AA27638; Wed, 8 Sep 1993 10:03:26 -0400 Message-Id: <9309081403.AA27638@flashy.tay2.dec.com> Date: Wed, 8 Sep 1993 09:49:03 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft X-Vms-To: SMTP%"atm@sun.com" X-Orig-Sender: atm-request@atm.eng.sun.com If I were to get picky, I'd mention lots of other little ATM detail bugs in the Classical IP over ATM draft. Perhaps it should be reviewed by an ATM-not-IP expert, or a few words should be put in front to note that the document is not meant to be normative with regard to the nature of ATM, only to the way it defines the IP layer. >This type is >specified either by administrative control for PVC's or via >signalling for SVC's. There are five different AAL format types, >which are commonly referred to as "AALn", where "n" is a number >from one 1 through 5. There is no field in an ATM cell header >which carries this AAL type value, rather it is known at each hop >of the path due to the call setup mechanism. Of course AAL type is not known at each ATM-layer hop of the path, just at the end points, which are IP-layer hops. Q.93B is derived from Q.931. As a general rule, certain codepoints in Q.93x protocols are only passed end to end, and not actually looked at by the switching entities. AAL type is such a field; intermediate switches are not supposed to look or care. Factual bug: There are not five different AAL format types numbered 1 to 5. Types 3 and 4 were merged into AAL3/4 some time ago, and the proposed AAL 2 has not been completed or approved. The text simply makes assumptions about ATM that are obvious but untrue... nothing really harmful, but it's typical of the text's treatment of ATM. It does, to me, tend to degrade the quality of the final document. "Jean-Yves Le Boudec" notes, > Bear in mind though that the ATM Bearer Capability (caaried in setup mess >mandatory) indicates the class of connection, and this maps directly >to an AAL type. This isn't quite true either. AAL Type and BC Class were decoupled some years ago. AAL3 and AAL4 were merged even though the putative class of connection differed (by error, btw; Class C and Class D are essentially identical at the ATM layer), and AAL5 is aimed at the same classes of service. AAL5 is just a different approach to protocol design from AAL3/4. Anyway, this is all wordsmithing. The gist of the Classical draft is more important and it shouldn't get lost among the ATM tutorial bugs. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13534; 8 Sep 93 16:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13530; 8 Sep 93 16:44 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa23355; 8 Sep 93 16:44 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA28437; Wed, 8 Sep 93 13:40:48 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24387; Wed, 8 Sep 93 13:43:15 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04188; Wed, 8 Sep 93 13:39:11 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04182; Wed, 8 Sep 93 13:39:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15117; Wed, 8 Sep 93 13:39:14 PDT Received: from uu2.psi.com by Sun.COM (4.1/SMI-4.1) id AA28118; Wed, 8 Sep 93 13:39:06 PDT Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA25210 for atm@Sun.COM; Wed, 8 Sep 93 16:39:00 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA09840; Wed, 8 Sep 93 13:36:47 PDT Message-Id: <9309082036.AA09840@aland.bbn.com> To: "k1io, FN42jk" Cc: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 08 Sep 93 13:36:46 -0700 X-Orig-Sender: atm-request@atm.eng.sun.com > If I were to get picky, I'd mention lots of other little ATM detail > bugs in the Classical IP over ATM draft. Perhaps it should be reviewed > by an ATM-not-IP expert, or a few words should be put in front to > note that the document is not meant to be normative with regard to the > nature of ATM, only to the way it defines the IP layer. Fred: Please do mention the other little ATM detail bugs. Part of the credibility of the IETF standards comes from a serious interest in making the specs as correct as we can. The specs still often have glitches, limitations, etc., but the point is we try very hard to avoid them. (In cases of limitations we just can't find a way around, the document should clearly call them out as known limitations for which a solution is not yet found). Besides, on a more personal level, Mark's a careful guy and I know he'd like any document with his name on it to be accurate. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14321; 8 Sep 93 17:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14317; 8 Sep 93 17:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa24480; 8 Sep 93 17:06 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02738; Wed, 8 Sep 93 14:01:53 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA26945; Wed, 8 Sep 93 14:04:21 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04319; Wed, 8 Sep 93 14:00:32 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04313; Wed, 8 Sep 93 14:00:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17183; Wed, 8 Sep 93 14:00:36 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (4.1/SMI-4.1) id AA02431; Wed, 8 Sep 93 14:00:21 PDT Received: by inet-gw-1.pa.dec.com; id AA12150; Wed, 8 Sep 93 14:00:18 -0700 Received: by flashy.tay2.dec.com (5.65/MS-081993); id AA00311; Wed, 8 Sep 1993 17:00:16 -0400 Message-Id: <9309082100.AA00311@flashy.tay2.dec.com> Date: Wed, 8 Sep 1993 16:56:59 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft X-Vms-To: SMTP%"atm@Sun.com" X-Orig-Sender: atm-request@atm.eng.sun.com Here are a couple of other minor suggested changes to the Classical IP over ATM draft, since Craig asked nicely. :-) > ATM provides a virtual circuit switched environment. VC setup may > be done on either a Permanent Virtual Circuit (PVC) or dynamic > Switched Virtual Circuit (SVC) basis. SVC call management > signalling is performed via Q.93B implementations [7,9]. To be really picky, it's a Virtual Channel, not Virtual Circuit. And then there are Virtual Paths, so somebody else with a good sense of ex-CCITT vocabulary might want to comment if "virtual connection" is the right phrase, or what. (ATM's at a lower layer than Virtual Circuit would imply.) > o ATM standards provide several formats for the exchange of > Protocol Data Units (PDU's), these formats are called ATM > Adaptation Layers (AAL's). The term PDU is too general; even a cell is a PDU. Try: The function of mapping information into ATM cells is performed in the ATM Adaptation Layer, which makes direct use of the ATM service. ATM standards provide several optional AAL protocols.... (then my previous comment comes in.) Also, the Address issue exists: ATM supports both the GOSIP-NSAP-like format and the E.164 format, the latter being the norm on public nets. Classical IP may want to support this too, as well as the ATM-FORUM local LAN address. (I'm thinking of remote workstations, ATM at home, ATM via a cable TV company's new digital fiber-to-the-home, etc. No reason to confine ourselves to today's economic realm of possibility!) fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14798; 8 Sep 93 17:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14794; 8 Sep 93 17:21 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa24995; 8 Sep 93 17:21 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA06458; Wed, 8 Sep 93 14:17:29 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28649; Wed, 8 Sep 93 14:19:53 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04429; Wed, 8 Sep 93 14:15:24 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04423; Wed, 8 Sep 93 14:15:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18335; Wed, 8 Sep 93 14:15:28 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA05936; Wed, 8 Sep 93 14:15:20 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA06670; Wed, 8 Sep 93 14:12:17 -0700 To: "k1io, FN42jk" Cc: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft In-Reply-To: <9309081403.AA27638@flashy.tay2.dec.com> References: <9309081403.AA27638@flashy.tay2.dec.com> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 8 Sep 93 14:12:16 -0700 Message-Id: <930908141216.6475@matmos.hpl.hp.com> Encoding: 35 TEXT, 2 TEXT SIGNATURE X-Orig-Sender: atm-request@atm.eng.sun.com > If I were to get picky, I'd mention lots of other little ATM detail > bugs in the Classical IP over ATM draft. Perhaps it should be reviewed > by an ATM-not-IP expert, or a few words should be put in front to > note that the document is not meant to be normative with regard to the > nature of ATM, only to the way it defines the IP layer. Fred, The document has been reviewed by many ATM experts. I have found though that each one has a different perspective and their input is welcome. > Of course AAL type is not known at each ATM-layer hop of the path, > just at the end points, which are IP-layer hops.... This nit has been cleaned up. > Factual bug: There are not five different AAL format types numbered > 1 to 5. Types 3 and 4 were merged into AAL3/4 some time ago, and > the proposed AAL 2 has not been completed or approved. I'll clean up the description also. Thanks for this nit. > The text simply > makes assumptions about ATM that are obvious but untrue... nothing > really harmful, but it's typical of the text's treatment of ATM. It > does, to me, tend to degrade the quality of the final document. Please point out more nits. Other ATM experts have not pointed out these untruth's yet. > Anyway, this is all wordsmithing. The gist of the Classical draft is > more important and it shouldn't get lost among the ATM tutorial bugs. Thanks for the comments. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15443; 8 Sep 93 18:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15439; 8 Sep 93 18:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27403; 8 Sep 93 18:06 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15150; Wed, 8 Sep 93 15:02:40 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03535; Wed, 8 Sep 93 15:05:03 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04683; Wed, 8 Sep 93 15:00:20 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04677; Wed, 8 Sep 93 15:00:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21790; Wed, 8 Sep 93 15:00:23 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA14618; Wed, 8 Sep 93 15:00:06 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07542; Wed, 8 Sep 93 14:56:41 -0700 To: "k1io, FN42jk" Cc: atm@sun.com Subject: Re: Last Call in WG for Classical IP draft In-Reply-To: <9309082100.AA00311@flashy.tay2.dec.com> References: <9309082100.AA00311@flashy.tay2.dec.com> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 8 Sep 93 14:56:40 -0700 Message-Id: <930908145640.6475@matmos.hpl.hp.com> Encoding: 41 TEXT, 2 TEXT SIGNATURE X-Orig-Sender: atm-request@atm.eng.sun.com > To be really picky, it's a Virtual Channel, not Virtual Circuit. And > then there are Virtual Paths, so somebody else with a good sense of > ex-CCITT vocabulary might want to comment if "virtual connection" is > the right phrase, or what. (ATM's at a lower layer than Virtual > Circuit would imply.) Yeah, "virtual channel" is what I've seen in the texts. I used "virtual circuit" due to the commonplace use in the community. FORE is using "virtual connection" in their documentation for the ASX-100. I'd be happy to go to "virtual channel" if I hear no objections on this list. > > o ATM standards provide several formats for the exchange of > > Protocol Data Units (PDU's), these formats are called ATM > > Adaptation Layers (AAL's). > > The term PDU is too general; even a cell is a PDU. Try: > > The function of mapping information into ATM cells is performed in the > ATM Adaptation Layer, which makes direct use of the ATM service. ATM > standards provide several optional AAL protocols.... > (then my previous comment comes in.) I dunno about "PDU" being too general. Combining Martin de Prycker's text and you may be better: the function of mapping user PDU's (Protocol Data Unit) into the information field of the ATM cell and vice versa is performed in the ATM Adaptation Layer (AAL). > Also, the Address issue exists: ATM supports both the GOSIP-NSAP-like > format and the E.164 format, the latter being the norm on public nets. > Classical IP may want to support this too, as well as the ATM-FORUM > local LAN address. (I'm thinking of remote workstations, ATM at home, > ATM via a cable TV company's new digital fiber-to-the-home, etc. No > reason to confine ourselves to today's economic realm of possibility!) E.164 is supported in the classical draft via encoding the E.164 address in an NSAP for ARP. Our public network pundits at Bellcore have not expressed any concern at this time and they have reviewed the draft thoroughly. Are you are saying that ARP needs to support E.164 native in addition to ATM-FORUM NSAP's? This would mean the classical draft needs to define a separate hardware type encoding and data format for E.164. We need to get some consensous immediately on the issue if this needs to be done. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00850; 9 Sep 93 5:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ad00830; 9 Sep 93 5:02 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa03759; 8 Sep 93 20:53 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA07121; Wed, 8 Sep 93 17:46:19 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20369; Wed, 8 Sep 93 17:48:43 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA05001; Wed, 8 Sep 93 17:44:53 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA04995; Wed, 8 Sep 93 17:44:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02358; Wed, 8 Sep 93 17:45:00 PDT Received: from mulga.cs.mu.OZ.AU by Sun.COM (4.1/SMI-4.1) id AA06996; Wed, 8 Sep 93 17:44:50 PDT Received: from mullian.ee.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26190 Thu, 9 Sep 1993 10:44:28 +1000 (from gja@mullian.ee.mu.OZ.AU) Received: by mullian.ee.mu.OZ.AU (4.1) id AA08670; Thu, 9 Sep 93 10:44:27 EST Message-Id: <9309090044.8670@mullian.ee.mu.OZ.AU> To: "k1io, FN42jk" Cc: atm@sun.com, gja@mullian.ee.mu.oz.au Subject: Re: Last Call in WG for Classical IP draft In-Reply-To: Your message of Wed, 08 Sep 1993 16:56:59 -0400. <9309082100.AA00311@flashy.tay2.dec.com> Date: Thu, 09 Sep 1993 10:44:26 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Grenville Armitage X-Orig-Sender: atm-request@atm.eng.sun.com [..] >>To be really picky, it's a Virtual Channel, not Virtual Circuit. And >>then there are Virtual Paths, so somebody else with a good sense of >>ex-CCITT vocabulary might want to comment if "virtual connection" is >>the right phrase, or what. (ATM's at a lower layer than Virtual >>Circuit would imply.) The lurker again, I'll bite :-) The draft may wish to make a couple of distinctions: - A single end-to-end connection is a Virtual Channel Connection, or VCC. - A VCC is constructed from the concatenation of Virtual Channel links (i.e. between switches, identified by a unique VCI on each hop). So "virtual connection" would appear a reasonable phrase for the draft to use, provided it is defined at the beginning as meaning a VCC. Virtual Paths are not as immediately relevant to IP entities, so it may not be worth the effort describing them in depth in the draft. However, for sake of completeness: - A Virtual Path Connection carries 'bundles' of VCCs between virtual path endpoints. - A VPC is the concatenation of Virtual Path links (i.e. between switches where only the VPI is switched - all VCCs retain their VCIs). - Whereas a VCC terminates on an ATM layer, a VP end-point may be an ATM layer or a switch that performs VC switching (on the VCI as well as VPI). Ultimately, however, the end-to-end connection that IP entities will see is still a VCC. User-user VPCs are useful to those who wish to manage their own collection of VCCs between the same two points, but this doesn't appear necessary in the current IP-over-ATM model. [Refs - my 1990 copies of I.150 and I.311 (esp. section 2.2.2 and 2.3.2). I don't think the basic def's have changed, my later editions are not at hand :( ] gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01003; 9 Sep 93 5:03 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ak00932; 9 Sep 93 5:03 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa09439; 8 Sep 93 23:25 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17995; Wed, 8 Sep 93 20:23:04 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27883; Wed, 8 Sep 93 20:25:36 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA05267; Wed, 8 Sep 93 20:21:57 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA05261; Wed, 8 Sep 93 20:21:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07245; Wed, 8 Sep 93 20:22:06 PDT Received: from giaeb.cc.monash.edu.au by Sun.COM (4.1/SMI-4.1) id AA17904; Wed, 8 Sep 93 20:21:50 PDT Message-Id: <9309090321.AA17904@Sun.COM> Received: by giaeb.cc.monash.edu.au (16.8/16.2) id AA25731; Thu, 9 Sep 93 13:19:38 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mahbub hassan Subject: Mail List To: atm@sun.com Date: Thu, 9 Sep 93 13:19:38 EST Mailer: Elm [revision: 70.30] X-Orig-Sender: atm-request@atm.eng.sun.com I would like to be included in this mail list.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16402; 9 Sep 93 23:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16398; 9 Sep 93 23:22 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26775; 9 Sep 93 23:22 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA21893; Thu, 9 Sep 93 20:16:34 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09886; Thu, 9 Sep 93 20:19:15 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07117; Thu, 9 Sep 93 20:15:32 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA07111; Thu, 9 Sep 93 20:15:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07322; Thu, 9 Sep 93 20:15:41 PDT Received: from han.hana.nm.kr by Sun.COM (4.1/SMI-4.1) id AA21795; Thu, 9 Sep 93 20:15:19 PDT Received: from sokri.etri.re.kr by han.hana.nm.kr (4.1/KUM-0.1) id AA15190; Fri, 10 Sep 93 12:17:03 KST Received: from winky.etri.re.kr by sokri.etri.re.kr (4.0/SOKRI-0.1) id AA16105; Tue, 10 Sep 02 09:56:47 KDT Received: by winky.etri.re.kr (4.1/ETRI-0.1) id AA04676; Tue, 7 Sep 93 21:27:10 KDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dae Young Kim Message-Id: <9309071127.AA04676@winky.etri.re.kr> Subject: subscribe me To: atm@sun.com Date: Tue, 7 Sep 1993 21:27:09 +0900 (KDT) X-Mailer: ELM [version 2.4 PL21-h3] Content-Type: text Content-Length: 84 X-Orig-Sender: atm-request@atm.eng.sun.com Please subscribe me in your mailing list! e-mail address : dykim@winky.etri.re.kr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16676; 10 Sep 93 19:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16672; 10 Sep 93 19:29 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10623; 10 Sep 93 19:29 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17133; Fri, 10 Sep 93 16:24:46 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01894; Fri, 10 Sep 93 16:27:35 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA08664; Fri, 10 Sep 93 16:23:18 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA08658; Fri, 10 Sep 93 16:23:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25890; Fri, 10 Sep 93 16:23:25 PDT Received: from noc.msc.edu by Sun.COM (4.1/SMI-4.1) id AA16918; Fri, 10 Sep 93 16:23:17 PDT Received: from wy.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA26811; Fri, 10 Sep 93 18:23:05 -0500 Received: by wy.msc.edu (5.65/MSC/v3.1r(920220)) id AA12932; Fri, 10 Sep 93 18:23:13 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Spengler Message-Id: <9309102323.AA12932@wy.msc.edu> Subject: Re: Last Call in WG for Classical IP draft To: atm@sun.com Date: Fri, 10 Sep 1993 18:23:11 -0500 (CDT) Cc: mks@msc.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3027 X-Orig-Sender: atm-request@atm.eng.sun.com Mark, A bit close to the wire, but just a few comments... > > the last cell indicating end of PDU. ATM standards guarantee that > on a given VC, cell ordering is preserved end-to-end. > Since we're giving a mini-tutorial, you should also note that AAL5 (using a null SSCS) provides a non-assured data transfer service - it is up to higher-level protocols to provide retransmission. > > Characteristics of the global model are: > > [...] > > o ARP's are global, ARP architecture needs to change to support a > robust global client/server model. > In the global model, the ARP protocol will most likely not be used, although there must be a new address resolution scheme (e.g. NBMA ARP). > > The parameter values MUST be user configurable: > > o ATM Hardware Address (atm$ha). The ATM address of the individual > IP station. Each host must be configured to accept datagrams > destined for this address > The last sentence is only applicable to signalling. Once the VCC is setup the hardware address isn't used across the VCC. Perhaps it should read "...configured to accept connection requests for this address." > > Permanent Virtual Circuits > > [...] > In a > strict PVC environment, the receiver shall infer the relevant virtual > circuit from the virtual circuit on which the InARP request > (InARP_REQUEST) or response (InARP_REPLY) was received. I'm a little confused here. > > ARP Server Operational Requirements > > [...] > ARP table entries persist until aged or > invalidated. VC call tear down does not remove ARP table entries. Should entries be aged while a VCC to that entry's destination remains open?? > > ARP Client Operational Requirements > > 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any > VC appropriately. Who will send ARP_REQUEST packets to a client?? > > 4. Generate and transmit InARP_REQUEST packets as needed and to > process InARP_REPLY packets appropriately. InARP_REPLY packets > should be used to build/refresh ARP table entries. This should only be when using PVCs. > > ARP Table Aging - All stations > > [...] > > Prior to aging (removing) an ARP table entry, all stations must > generate an InARP_REQUEST on any open VC associated with that entry. > If an InARP_REPLY is received, that table entry is updated and not > deleted. If there is no open VC associated with the table entry, the > entry is deleted. As long as there is an open VCC, why should the ARP entry be aged? Since ATM is connection-oriented, the mapping shouldn't change with a channel open - a system reconfig/reboot should clear the circuit. Thanks mike -- Mike Spengler Minnesota Supercomputer Center, Inc. Email: mks@msc.edu 1200 Washington Ave. So. Phone: +1 612 337 3557 Minneapolis MN 55415 FAX: +1 612 337 3400   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06062; 13 Sep 93 3:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06058; 13 Sep 93 3:41 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa03325; 13 Sep 93 3:41 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00701; Mon, 13 Sep 93 00:38:28 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19055; Mon, 13 Sep 93 00:41:43 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA12349; Mon, 13 Sep 93 00:37:19 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA12343; Mon, 13 Sep 93 00:37:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11109; Mon, 13 Sep 93 00:37:32 PDT Received: from dxmint.cern.ch by Sun.COM (4.1/SMI-4.1) id AA00647; Mon, 13 Sep 93 00:37:19 PDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23871; Mon, 13 Sep 1993 09:37:17 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA02206; Mon, 13 Sep 1993 09:37:07 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309130737.AA02206@dxcern.cern.ch> Subject: Re: Last Call in WG for Classical IP draft To: atm@sun.com Date: Mon, 13 Sep 1993 09:37:02 +0200 (MET DST) In-Reply-To: <930908145640.6475@matmos.hpl.hp.com> from "Mark Laubach" at Sep 8, 93 02:56:40 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1511 X-Orig-Sender: atm-request@atm.eng.sun.com > > > Also, the Address issue exists: ATM supports both the GOSIP-NSAP-like > > format and the E.164 format, the latter being the norm on public nets. > > Classical IP may want to support this too, as well as the ATM-FORUM > > local LAN address. (I'm thinking of remote workstations, ATM at home, > > ATM via a cable TV company's new digital fiber-to-the-home, etc. No > > reason to confine ourselves to today's economic realm of possibility!) > > E.164 is supported in the classical draft via encoding the E.164 address in > an NSAP for ARP. Our public network pundits at Bellcore have not expressed > any concern at this time and they have reviewed the draft thoroughly. Are > you are saying that ARP needs to support E.164 native in addition to > ATM-FORUM NSAP's? This would mean the classical draft needs to define a > separate hardware type encoding and data format for E.164. We need to get > some consensous immediately on the issue if this needs to be done. So the model is that in a LIS which uses the ITU/TSS standard for ATM adddresses, instead of the ATM-Forum implementors' agreement, the ATM-Forum format is used to embed the standard format in ARP messages. This works but is unclean. The issue is whether to clean it up by adding a second hardware type for use in a LIS with ITU/TSS addresses. I would vote for doing this, but it is not important enough to start a flame war. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07228; 13 Sep 93 16:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07224; 13 Sep 93 16:38 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa25971; 13 Sep 93 16:38 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26221; Mon, 13 Sep 93 13:25:37 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11828; Mon, 13 Sep 93 13:25:34 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13387; Mon, 13 Sep 93 13:24:34 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13381; Mon, 13 Sep 93 13:24:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09830; Mon, 13 Sep 93 13:24:34 PDT Received: from att.att.com (gw1.att.com) by Sun.COM (4.1/SMI-4.1) id AA26030; Mon, 13 Sep 93 13:24:31 PDT Message-Id: <9309132024.AA26030@Sun.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rgc@qsun.att.com Date: Mon, 13 Sep 93 15:51 EDT To: atm@sun.com Subject: E.164 addressing X-Orig-Sender: atm-request@atm.eng.sun.com Sorry for the delay in responding to the discussion regarding the address formats to be supported in Mark's Classical IP over ATM document. The ATM Forum, in addition to the three NSAP modeled address formats for the private UNI, has agreed to support E.164 as the native numbering plan for public UNIs. The Forum's version 2.4 (dated 5 Aug 93) of the UNI specification specifically states that the public UNI shall support one of the above choices, e.g. either native E.164 or all three NSAP modeled formats. It is therefore conceivable that a public UNI would support only E.164 addressing. Therefore, we believe that this option should be supported in Mark's document on Classical IP over ATM in order to be consistent with the current agreements in the ATM Forum. Kamlesh Tewani, ktt@arch2.att.com Bob Cole, rgc@qsun.att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07603; 13 Sep 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07599; 13 Sep 93 16:59 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa28528; 13 Sep 93 16:59 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA28750; Mon, 13 Sep 93 13:37:58 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13473; Mon, 13 Sep 93 13:37:53 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13436; Mon, 13 Sep 93 13:36:47 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13430; Mon, 13 Sep 93 13:36:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10764; Mon, 13 Sep 93 13:36:47 PDT Received: from dreggs.cisco.com by Sun.COM (4.1/SMI-4.1) id AB28506; Mon, 13 Sep 93 13:36:45 PDT Received: by dreggs.cisco.com; Mon, 13 Sep 93 13:36:30 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lawrence Lang Message-Id: <9309132036.AA28291@dreggs.cisco.com> Subject: Re: E.164 addressing To: rgc@qsun.att.com Date: Mon, 13 Sep 93 13:36:30 MDT Cc: atm@sun.com In-Reply-To: <9309132024.AA26030@Sun.COM>; from "rgc@qsun.att.com" at Sep 13, 93 3:51 pm X-Mailer: ELM [version 2.3 PL11] X-Orig-Sender: atm-request@atm.eng.sun.com > > > Sorry for the delay in responding to the discussion regarding the > address formats to be supported in Mark's Classical IP over ATM document. > > The ATM Forum, in addition to the three NSAP modeled address > formats for the private UNI, has agreed to > support E.164 as the native numbering plan for public UNIs. > The Forum's version 2.4 (dated 5 Aug 93) of the UNI specification > specifically states that the public UNI shall support > one of the above choices, e.g. either native E.164 or > all three NSAP modeled formats. It is therefore conceivable that > a public UNI would support only E.164 addressing. Therefore, Conceivable, but not desirable, IMHO. I sure hope public carriers have the good sense to choose with the more general E.164 NSAP format. Larry > we believe that this option should be supported in > Mark's document on Classical IP over ATM in order to be consistent with > the current agreements in the ATM Forum. > > > Kamlesh Tewani, ktt@arch2.att.com > Bob Cole, rgc@qsun.att.com > -- ______________________________________________ Lawrence J. Lang Cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, California 94025 USA + 1 415 688 4638 Phone + 1 415 326 1989 Fax llang@cisco.com Email ______________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08121; 13 Sep 93 17:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08115; 13 Sep 93 17:19 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa01028; 13 Sep 93 17:19 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05061; Mon, 13 Sep 93 14:08:24 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA17403; Mon, 13 Sep 93 14:08:21 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13612; Mon, 13 Sep 93 14:07:12 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13606; Mon, 13 Sep 93 14:07:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13590; Mon, 13 Sep 93 14:07:12 PDT Received: from relay.fore.com by Sun.COM (4.1/SMI-4.1) id AA04792; Mon, 13 Sep 93 14:07:03 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA15552; Mon, 13 Sep 93 17:07:23 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA05777; Mon, 13 Sep 93 17:06:53 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA27211; Mon, 13 Sep 93 17:06:52 EDT Date: Mon, 13 Sep 93 17:06:52 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309132106.AA27211@marlin.fore.com> To: atm@sun.com, rgc@qsun.att.com Subject: Re: E.164 addressing X-Orig-Sender: atm-request@atm.eng.sun.com > The ATM Forum, in addition to the three NSAP modeled address > formats for the private UNI, has agreed to > support E.164 as the native numbering plan for public UNIs. > The Forum's version 2.4 (dated 5 Aug 93) of the UNI specification > specifically states that the public UNI shall support > one of the above choices, e.g. either native E.164 or > all three NSAP modeled formats. It is therefore conceivable that > a public UNI would support only E.164 addressing. Therefore, > we believe that this option should be supported in > Mark's document on Classical IP over ATM in order to be consistent with > the current agreements in the ATM Forum. I believe that SMDS also uses E.164 addresses. We can just use ARP hardware type 14 (SMDS) if we loosen it's definition to "E.164 networks". Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08390; 13 Sep 93 17:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08386; 13 Sep 93 17:30 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02309; 13 Sep 93 17:30 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05863; Mon, 13 Sep 93 14:12:57 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18111; Mon, 13 Sep 93 14:12:27 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13640; Mon, 13 Sep 93 14:10:50 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13634; Mon, 13 Sep 93 14:10:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13807; Mon, 13 Sep 93 14:10:44 PDT Received: from hubbub.cisco.com by Sun.COM (4.1/SMI-4.1) id AA05370; Mon, 13 Sep 93 14:10:24 PDT Received: from lager.cisco.com by hubbub.cisco.com with SMTP id AA29037 (5.67a/IDA-1.5 for atm@sun.com); Mon, 13 Sep 1993 14:09:34 -0700 Message-Id: <199309132109.AA29037@hubbub.cisco.com> To: rgc@qsun.att.com Cc: atm@sun.com Subject: Re: E.164 addressing In-Reply-To: Your message of "Mon, 13 Sep 93 15:51:00 EDT." <9309132024.AA26030@Sun.COM> Date: Mon, 13 Sep 93 14:09:34 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Forster X-Orig-Sender: atm-request@atm.eng.sun.com > The ATM Forum, in addition to the three NSAP modeled address formats for > the private UNI, has agreed to support E.164 as the native numbering plan > for public UNIs. The Forum's version 2.4 (dated 5 Aug 93) of the UNI > specification specifically states that the public UNI shall support one > of the above choices, e.g. either native E.164 or all three NSAP modeled > formats. It is therefore conceivable that a public UNI would support > only E.164 addressing. Therefore, we believe that this option should be > supported in Mark's document on Classical IP over ATM in order to be > consistent with the current agreements in the ATM Forum. Robert and Kamlesh, I respectfully disagree with you. E.164 addresses can be expressed in the ATM Forum-style NSAP's, so I don't see the need to support native E.164. I'd rather take this opportunity to minimize the number of variants without loss of generality - such opportunities seem very uncommon in ATM these days. Clearly the ATM network itself will never see the difference, since we're discussing the format of ARP packets, and the ATM net is not supposed to look into the ATM payload, let alone inside an ARP packet. -- Jim -- Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab09127; 13 Sep 93 17:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09123; 13 Sep 93 17:56 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa05620; 13 Sep 93 17:56 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11889; Mon, 13 Sep 93 14:45:53 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA22969; Mon, 13 Sep 93 14:45:50 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13862; Mon, 13 Sep 93 14:44:35 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13856; Mon, 13 Sep 93 14:44:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16459; Mon, 13 Sep 93 14:44:36 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA11621; Mon, 13 Sep 93 14:44:33 PDT Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20140; Mon, 13 Sep 93 14:40:45 -0700 Message-Id: <9309132140.AA20140@matmos.hpl.hp.com> To: rgc@qsun.att.com Cc: atm@sun.com Subject: Re: E.164 addressing In-Reply-To: Your message of Mon, 13 Sep 1993 15:51:00 -0400 Date: Mon, 13 Sep 1993 14:40:45 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach X-Orig-Sender: atm-request@atm.eng.sun.com ... all three NSAP modeled formats. It is therefore conceivable that a public UNI would support only E.164 addressing. Therefore, we believe that this option should be supported in Mark's document on Classical IP over ATM in order to be consistent with the current agreements in the ATM Forum. This means adding another or documenting the existing ARP hardware type "atm" (which is, I believe an E.164) type in the classical document. There are caveats/understandings for this: 1. The arp hardware type must be consistent across the LIS. 2. Some administrative care is necessary when configuring IP stations for generating and replying to the proper ARP types as per the LIS configuration. 3. Does this extend to NBMA? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09507; 13 Sep 93 18:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09503; 13 Sep 93 18:03 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06876; 13 Sep 93 18:02 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13029; Mon, 13 Sep 93 14:51:58 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24147; Mon, 13 Sep 93 14:51:54 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13912; Mon, 13 Sep 93 14:50:50 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13879; Mon, 13 Sep 93 14:50:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16843; Mon, 13 Sep 93 14:50:16 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA12612; Mon, 13 Sep 93 14:50:03 PDT Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20263; Mon, 13 Sep 93 14:46:06 -0700 Message-Id: <9309132146.AA20263@matmos.hpl.hp.com> To: Drew Daniel Perkins Cc: atm@sun.com, rgc@qsun.att.com Subject: Re: E.164 addressing In-Reply-To: Your message of Mon, 13 Sep 1993 17:06:52 -0400 Date: Mon, 13 Sep 1993 14:46:06 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach X-Orig-Sender: atm-request@atm.eng.sun.com From: ddp@fore.com (Drew Daniel Perkins) Subject: Re: E.164 addressing I believe that SMDS also uses E.164 addresses. We can just use ARP hardwar e type 14 (SMDS) if we loosen it's definition to "E.164 networks". .... ARP hardware type "atm" as registered by John Burnet from Adaptive/NET,\ uses E.164 addresses. John, do you have details? Personally, I would much rather the ATM driver/interface worry about packing and unpacking an E.164 address into an NSAP format for ARP/InARP. I would much rather have only one ARP packet format to worry about and to not have to add in another variable in when it comes to implementing IP over ATM. The keep it simple approach seems to me to be best. Remember, the format of the information within the ARP does not have to match the ATM address format used within the LIS provided that there is a straightforward way to go back and forth between the two. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09619; 13 Sep 93 18:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09615; 13 Sep 93 18:15 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa09140; 13 Sep 93 18:14 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15102; Mon, 13 Sep 93 15:02:38 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA25587; Mon, 13 Sep 93 15:02:37 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13993; Mon, 13 Sep 93 15:01:31 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA13987; Mon, 13 Sep 93 15:01:31 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA17926; Mon, 13 Sep 93 15:01:33 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA06809; Mon, 13 Sep 93 15:01:30 PDT Received: from turbo.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA22069; Mon, 13 Sep 93 18:01:28 EDT Received: from danang.East.Sun.COM by turbo.East.Sun.COM (4.1/SMI-4.1) id AA04523; Mon, 13 Sep 93 17:57:34 EDT Received: by danang.East.Sun.COM (5.0/SMI-SVR4) id AA01466; Mon, 13 Sep 93 17:57:53 EDT Date: Mon, 13 Sep 93 17:57:53 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nhon Van Tran - Sun USOPS IR Message-Id: <9309132157.AA01466@danang.East.Sun.COM> To: atm@sun.com Subject: Pls remove me from this aliase X-Sun-Charset: US-ASCII Content-Length: 58 X-Orig-Sender: atm-request@atm.eng.sun.com I do not really know why I am getting these .. Thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09676; 13 Sep 93 18:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09672; 13 Sep 93 18:19 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa09706; 13 Sep 93 18:19 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15544; Mon, 13 Sep 93 15:05:05 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA25992; Mon, 13 Sep 93 15:05:02 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14013; Mon, 13 Sep 93 15:03:45 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14007; Mon, 13 Sep 93 15:03:44 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18093; Mon, 13 Sep 93 15:03:46 PDT Received: from Corp.Sun.COM (lemay) by snail.Sun.COM (4.1/SMI-4.1) id AA06951; Mon, 13 Sep 93 15:03:43 PDT Received: from mtliban.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA21086; Mon, 13 Sep 93 15:03:41 PDT Received: by mtliban.Corp.Sun.COM (4.1/SMI-4.1) id AA21703; Mon, 13 Sep 93 15:01:51 PDT Date: Mon, 13 Sep 93 15:01:51 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Fixed Assets - Corp. Finance" Message-Id: <9309132201.AA21703@mtliban.Corp.Sun.COM> To: atm@sun.com Subject: Re: E.164 addressing Cc: aliases@sun.com X-Orig-Sender: atm-request@atm.eng.sun.com Hello all: What kind of alias is this? and who is monitoring it? I don't believe I asked to be added onto it. Is there a particular person that is keeping this alias up? if so, I would like to know and would like to be taken off it. To Aliases@sun: If you are the one, then take me off this alias: atm@sun.com Thanks, Joseph Chalhoub > From atm-request@atm.Eng Mon Sep 13 14:50:02 1993 > To: rgc@qsun.att.com > Cc: atm@Sun.COM > Subject: Re: E.164 addressing > In-Reply-To: Your message of Mon, 13 Sep 1993 15:51:00 -0400 > Date: Mon, 13 Sep 1993 14:40:45 -0700 > From: Mark Laubach > Sender: atm-request@atm.Eng > Content-Length: 768 > X-Lines: 25 > > > ... > all three NSAP modeled formats. It is therefore conceivable that > a public UNI would support only E.164 addressing. Therefore, > we believe that this option should be supported in > Mark's document on Classical IP over ATM in order to be consistent with > the current agreements in the ATM Forum. > > This means adding another or documenting the existing ARP hardware > type "atm" (which is, I believe an E.164) type in the classical > document. > > There are caveats/understandings for this: > > 1. The arp hardware type must be consistent across the LIS. > > 2. Some administrative care is necessary when configuring IP stations > for generating and replying to the proper ARP types as per the LIS > configuration. > > 3. Does this extend to NBMA? > > Mark > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09788; 13 Sep 93 18:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09784; 13 Sep 93 18:34 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa11643; 13 Sep 93 18:34 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18647; Mon, 13 Sep 93 15:22:47 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28717; Mon, 13 Sep 93 15:22:44 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14224; Mon, 13 Sep 93 15:21:31 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14217; Mon, 13 Sep 93 15:21:30 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20042; Mon, 13 Sep 93 15:21:32 PDT Received: from Corp.Sun.COM (lemay) by snail.Sun.COM (4.1/SMI-4.1) id AA08357; Mon, 13 Sep 93 15:21:30 PDT Received: from durian.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA22468; Mon, 13 Sep 93 15:21:29 PDT Received: by durian.Corp.Sun.COM (4.1/SMI-4.1) id AA18641; Mon, 13 Sep 93 15:21:28 PDT Date: Mon, 13 Sep 93 15:21:28 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beth Tran, HR/ADMIN Legal Systems" Message-Id: <9309132221.AA18641@durian.Corp.Sun.COM> To: atm@sun.com Subject: Please take me off this aliases X-Orig-Sender: atm-request@atm.eng.sun.com Please take me off atm@sun.com Thanks Beth   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09892; 13 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09888; 13 Sep 93 18:53 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa14309; 13 Sep 93 18:53 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA20363; Mon, 13 Sep 93 15:31:45 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00176; Mon, 13 Sep 93 15:31:34 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14385; Mon, 13 Sep 93 15:30:25 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14379; Mon, 13 Sep 93 15:30:24 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20805; Mon, 13 Sep 93 15:30:27 PDT Received: from Eng.Sun.COM (zigzag-bb) by snail.Sun.COM (4.1/SMI-4.1) id AA08880; Mon, 13 Sep 93 15:30:24 PDT Received: from ciao.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29913; Mon, 13 Sep 93 15:30:24 PDT Received: by ciao.Eng.Sun.COM (4.1/SMI-4.1) id AA06428; Mon, 13 Sep 93 15:27:44 PDT Date: Mon, 13 Sep 93 15:27:44 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Zina Tabachnikova Message-Id: <9309132227.AA06428@ciao.Eng.Sun.COM> To: atm@sun.com Subject: Re: Pls remove me from this aliase X-Orig-Sender: atm-request@atm.eng.sun.com I do not really know why I am getting these .. Thanks > From atm-request@atm.Eng.Sun.COM Mon Sep 13 15:12:17 1993 > Date: Mon, 13 Sep 93 17:57:53 EDT > From: Nhon.Tran@East (Nhon Van Tran - Sun USOPS IR) > To: atm@Sun.COM > Subject: Pls remove me from this aliase > X-Sun-Charset: US-ASCII > Content-Length: 58 > Sender: atm-request@atm.Eng.Sun.COM > > > I do not really know why I am getting these .. > > Thanks. > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09961; 13 Sep 93 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09957; 13 Sep 93 19:00 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa15098; 13 Sep 93 18:59 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA21094; Mon, 13 Sep 93 15:36:50 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00809; Mon, 13 Sep 93 15:36:26 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14413; Mon, 13 Sep 93 15:35:02 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14407; Mon, 13 Sep 93 15:35:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21160; Mon, 13 Sep 93 15:35:03 PDT Received: from motgate.mot.com by Sun.COM (4.1/SMI-4.1) id AA20804; Mon, 13 Sep 93 15:34:29 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA13258; Mon, 13 Sep 1993 17:34:26 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15) id AA24319; Mon, 13 Sep 1993 17:34:23 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA12440 (5.65a+/IDA-1.4.2 for laubach@matmos.hpl.hp.com); Mon, 13 Sep 93 18:34:11 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA02987 (5.65a+/IDA-1.4.2 for atm@sun.com); Mon, 13 Sep 93 18:34:09 -0400 Message-Id: <9309132234.AA02987@dbg.dev.cdx.mot.com> To: Mark Laubach Cc: atm@sun.com Subject: Re: E.164 addressing In-Reply-To: Your message of "Mon, 13 Sep 93 14:46:06 PDT." <9309132146.AA20263@matmos.hpl.hp.com> Date: Mon, 13 Sep 93 18:34:07 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp X-Orig-Sender: atm-request@atm.eng.sun.com The semantics of an E.164 number in the "Type = International Number, Plan = E.164" format and the semantics of an E.164 number in the "Plan = OSI NSAP" format are different. The former locates an interface to a public B-ISDN using the E.164 numbering plan (or, by extension an ATM endpoint connected to such an interface). The latter is the Initial Domain Part (IDP) of the ATM Address of an ATM endpoint; i.e., the E.164 address serves to guarantee uniqueness to the area, system identifier and selector, albeit with some presumption that the public network interface identifed by the E.164 number is somewhere in the immediate neighborhood. In another words, we really do need different representations (Drew's idea works fine) for E.164 addresses in the "Plan = E.164" format and for NSAP-encoded addresses. Rgds, Dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09979; 13 Sep 93 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09975; 13 Sep 93 19:00 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa15111; 13 Sep 93 19:00 EDT Received: from Eng.Sun.COM ([129.144.1.38]) by Sun.COM (4.1/SMI-4.1) id AA21104; Mon, 13 Sep 93 15:38:07 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00845; Mon, 13 Sep 93 15:36:34 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14421; Mon, 13 Sep 93 15:35:17 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14415; Mon, 13 Sep 93 15:35:16 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21183; Mon, 13 Sep 93 15:35:18 PDT Received: from EBay.Sun.COM (female) by snail.Sun.COM (4.1/SMI-4.1) id AA09189; Mon, 13 Sep 93 15:35:15 PDT Received: from denali.EBay.Sun.COM by EBay.Sun.COM (4.1/SMI-4.1) id AA03548; Mon, 13 Sep 93 15:35:14 PDT Received: by denali.EBay.Sun.COM (4.1/SMI-4.1) id AA18818; Mon, 13 Sep 93 15:40:56 PDT Date: Mon, 13 Sep 93 15:40:56 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marc Haverland Message-Id: <9309132240.AA18818@denali.EBay.Sun.COM> To: "Beth Tran, HR/ADMIN Legal Systems" Cc: atm@sun.com, aliases@sun.com Subject: Re: Please take me off this aliases In-Reply-To: <9309132221.AA18641@durian.Corp.Sun.COM> References: <9309132221.AA18641@durian.Corp.Sun.COM> X-Orig-Sender: atm-request@atm.eng.sun.com Beth Tran, HR/ADMIN Legal Systems writes: > > Please take me off atm@sun.com > Thanks > Beth There seems to have been some problem with the administration of this alias, as many people have asked to be removed. However, it appears to be one maintained by aliases@sun.com. If this is the case, please note that nobody *on* this alias will be able to remove anyone from this alias. Add/remove requests should always be sent to aliases@sun.com for all @sun aliases. Regards... marc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10844; 13 Sep 93 20:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10836; 13 Sep 93 20:24 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa01887; 13 Sep 93 20:24 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03604; Mon, 13 Sep 93 17:14:45 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13082; Mon, 13 Sep 93 17:14:45 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15140; Mon, 13 Sep 93 17:13:41 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15134; Mon, 13 Sep 93 17:13:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27430; Mon, 13 Sep 93 17:13:44 PDT Received: from relay.fore.com by Sun.COM (4.1/SMI-4.1) id AA03342; Mon, 13 Sep 93 17:13:26 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA16043; Mon, 13 Sep 93 20:13:32 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA13838; Mon, 13 Sep 93 20:13:03 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA05093; Mon, 13 Sep 93 20:13:02 EDT Date: Mon, 13 Sep 93 20:13:02 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309140013.AA05093@marlin.fore.com> To: laubach@matmos.hpl.hp.com, dan@merlin.dev.cdx.mot.com Subject: Re: E.164 addressing Cc: atm@sun.com X-Orig-Sender: atm-request@atm.eng.sun.com > The semantics of an E.164 number in the "Type = International Number, Plan = > E.164" format and the semantics of an E.164 number in the "Plan = OSI NSAP" > format are different. The former locates an interface to a public B-ISDN using > the E.164 numbering plan (or, by extension an ATM endpoint connected to such an > interface). The latter is the Initial Domain Part (IDP) of the ATM Address of > an ATM endpoint; i.e., the E.164 address serves to guarantee uniqueness to the > area, system identifier and selector, albeit with some presumption that the public network interface identifed by the E.164 number is > somewhere in the immediate neighborhood. > > In another words, we really do need different representations (Drew's idea works > fine) for E.164 addresses in the "Plan = E.164" format and for NSAP-encoded > addresses. Dan, I assume you are referring to my "first" idea of using two different hardware types and not the second one where I flip-flopped and recommended using only one for NSAPs... I still adhere to the latter idea which seems to conflict with what I believe you said. Clearly, the ATM Forum intends for a user on a private UNI to be able to establish connections with a user on a public UNI (not a network on a public UNI). The only way to do this is to use an E.164 number encoded in an NSAP. Unfortunately, we haven't specified how the addresses get translated when crossing the Private/Public boundary. Do we put zero's in RD, Area and ESI? Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11180; 13 Sep 93 21:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11176; 13 Sep 93 21:20 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10376; 13 Sep 93 21:20 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11960; Mon, 13 Sep 93 18:16:24 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01062; Mon, 13 Sep 93 15:37:46 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14438; Mon, 13 Sep 93 15:36:01 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14432; Mon, 13 Sep 93 15:36:00 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21217; Mon, 13 Sep 93 15:36:03 PDT Received: from Eng.Sun.COM (zigzag-bb) by snail.Sun.COM (4.1/SMI-4.1) id AB09230; Mon, 13 Sep 93 15:36:00 PDT Received: from taichung.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00740; Mon, 13 Sep 93 15:36:00 PDT Received: by taichung.Eng.Sun.COM (4.1/SMI-4.1) id AA16970; Mon, 13 Sep 93 15:40:22 PDT Date: Mon, 13 Sep 93 15:40:22 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tommy Hsieh Message-Id: <9309132240.AA16970@taichung.Eng.Sun.COM> To: atm@sun.com Subject: Please take me off this aliases too. X-Orig-Sender: atm-request@atm.eng.sun.com Please take me off atm@sun.com. Thanks. -tommy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11218; 13 Sep 93 21:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11214; 13 Sep 93 21:25 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa11306; 13 Sep 93 21:25 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12679; Mon, 13 Sep 93 18:22:28 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01297; Mon, 13 Sep 93 15:39:40 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14455; Mon, 13 Sep 93 15:37:36 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14449; Mon, 13 Sep 93 15:37:34 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21290; Mon, 13 Sep 93 15:37:37 PDT Received: from Corp.Sun.COM (lemay) by snail.Sun.COM (4.1/SMI-4.1) id AA09312; Mon, 13 Sep 93 15:37:35 PDT Received: from corpaffairs.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA23691; Mon, 13 Sep 93 15:37:34 PDT Received: by corpaffairs.Corp.Sun.COM (4.1/SMI-4.1) id AA28618; Mon, 13 Sep 93 15:39:09 PDT Date: Mon, 13 Sep 93 15:39:09 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Serda - Corporate Affairs/Sun Foundation Message-Id: <9309132239.AA28618@corpaffairs.Corp.Sun.COM> To: atm@sun.com Subject: Please take me off this aliases X-Orig-Sender: atm-request@atm.eng.sun.com Me too. Thanks Gary Serda ----- Begin Included Message ----- From atm-request@atm.Eng Mon Sep 13 15:29:18 1993 From: Beth.Tran@Corp (Beth Tran, HR/ADMIN Legal Systems) To: atm@Sun.COM Subject: Please take me off this aliases Sender: atm-request@atm.Eng Content-Length: 44 X-Lines: 4 Please take me off atm@sun.com Thanks Beth ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11334; 13 Sep 93 21:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11329; 13 Sep 93 21:42 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa13981; 13 Sep 93 21:42 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13943; Mon, 13 Sep 93 18:38:23 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04711; Mon, 13 Sep 93 16:01:46 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14750; Mon, 13 Sep 93 15:59:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14744; Mon, 13 Sep 93 15:59:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22879; Mon, 13 Sep 93 15:59:51 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA24547; Mon, 13 Sep 93 15:59:10 PDT Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA21544; Mon, 13 Sep 93 15:55:26 -0700 Message-Id: <9309132255.AA21544@matmos.hpl.hp.com> To: atm@sun.com Subject: Classical draft holding.... Date: Mon, 13 Sep 1993 15:55:25 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach X-Orig-Sender: atm-request@atm.eng.sun.com I'm holding off on submitting the classical draft until we get some rough consensous on the E.164 issue. The options are as follows: Ignore it for now, and submit classical draft as is, and 1. Assume we can handle E.164 in ATM-FORUM NSAP's, or 2. Can deal with it in a future update the memo, or, 3. Document another ARP hardware type for native E.164. This assumes we can handle the confusion of having two ARP packet formats for ATM. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11510; 13 Sep 93 22:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11506; 13 Sep 93 22:01 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa16580; 13 Sep 93 22:01 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15427; Mon, 13 Sep 93 18:57:32 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04179; Mon, 13 Sep 93 15:59:13 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14717; Mon, 13 Sep 93 15:57:52 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14711; Mon, 13 Sep 93 15:57:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22766; Mon, 13 Sep 93 15:57:54 PDT Received: from relay.fore.com by Sun.COM (4.1/SMI-4.1) id AA24130; Mon, 13 Sep 93 15:57:17 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA15916; Mon, 13 Sep 93 18:57:32 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA10806; Mon, 13 Sep 93 18:57:06 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA02139; Mon, 13 Sep 93 18:57:04 EDT Date: Mon, 13 Sep 93 18:57:04 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309132257.AA02139@marlin.fore.com> To: ddp@fore.com, laubach@matmos.hpl.hp.com Subject: Re: E.164 addressing Cc: atm@sun.com, rgc@qsun.att.com X-Orig-Sender: atm-request@atm.eng.sun.com > From: ddp@fore.com (Drew Daniel Perkins) > Subject: Re: E.164 addressing > > I believe that SMDS also uses E.164 addresses. We can just use ARP hardwar > e > type 14 (SMDS) if we loosen it's definition to "E.164 networks". > > .... > > ARP hardware type "atm" as registered by John Burnet from Adaptive/NET,\ > uses E.164 addresses. John, do you have details? > > Personally, I would much rather the ATM driver/interface worry about > packing and unpacking an E.164 address into an NSAP format for > ARP/InARP. I would much rather have only one ARP packet format to > worry about and to not have to add in another variable in when it > comes to implementing IP over ATM. The keep it simple approach seems > to me to be best. > > Remember, the format of the information within the ARP does not have > to match the ATM address format used within the LIS provided that there > is a straightforward way to go back and forth between the two. Hmmm, this is more interesting than it appears at first... The ATM Forum clearly intended for hosts on a Private UNI using NSAPS to be able to communicate with hosts on a Public UNI using straight E.164 addresses. I had originally thought that we should use two different ARP hardware types for these, thinking that they would be on different LIS's. But, what if you try to put both of these on the same LIS? You may want both to use the same hardware type in this case just to simply things. It quickly becomes an implementation issue, but I think you will have to know about and convert between the two types of addresses somewhere in your code; either in the ARP layer or the Q.93B signalling interface. Conclusion: Let's just use NSAPS for Classical IP in all cases... Drew   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14987; 13 Sep 93 23:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14983; 13 Sep 93 23:03 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa25872; 13 Sep 93 23:03 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19620; Mon, 13 Sep 93 19:58:44 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA22290; Mon, 13 Sep 93 19:58:45 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15747; Mon, 13 Sep 93 19:57:44 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15741; Mon, 13 Sep 93 19:57:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05389; Mon, 13 Sep 93 19:57:13 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (4.1/SMI-4.1) id AA19544; Mon, 13 Sep 93 19:57:08 PDT Received: by inet-gw-1.pa.dec.com; id AA25887; Mon, 13 Sep 93 19:57:07 -0700 Received: by flashy.tay2.dec.com (5.65/MS-081993); id AA29668; Mon, 13 Sep 1993 22:57:06 -0400 Message-Id: <9309140257.AA29668@flashy.tay2.dec.com> Date: Mon, 13 Sep 1993 22:34:23 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: atm@sun.com Subject: Re: E.164 addressing X-Vms-To: US1RMC::"ddp@fore.com" X-Vms-Cc: SMTP%"atm@Sun.com" X-Orig-Sender: atm-request@atm.eng.sun.com Now things are getting complicated. Let me try to understand where this mess came from. 1) CCITT wrote Q.931 which has a "type of number" field, but always uses E.164 syntax and usually E.164 semantics (always, on public ISDN). This begat 2) CCITT adapted Q.931 into Q.93B, and left E.164 in there. But CCITT recognizes OSI as well, and allows "type of number" to be NSAP. 3) ATM Forum decides that UNI is always NSAP-like, while NNI or public UNI may be E.164. So workstations typically be on a private UNI using NSAP-like (note this is not a true NSAP) addresses, but some may be on a public UNI using E.164. Here is where ATM Forum addressing gets risky. Q.931 precedent (N-ISDN) uses intra-switch addresses which are typically either the low order bits of the public address (i.e., Direct Dialing In extension numbers) or a subaddress space (extension numbers behind a single listed diretory number). Q.93B anticipated this. ATM Forum's NSAP-like address format uses intra-switch addrresses which may contain a full E.164 value and an "extension" number (48-bit etc.) comingled into one field. Q.93B did not anticipate this at first. ARP just illustrates the problem of confusing two different concepts, if not three. One is subnetwork point of attachment, as in the E.164 high order of some ATM-NSAP addresses. One is a terminal's actual address, as in a full ATM-NSAP. A third is the other possible GOSIP format. Until we iron out the semantics of what ARP is trying to accomplish in all cases, including ITU-pure E.164 addresses, we will not be able to settle ARP conclusively. Note that in Q.931, a PBX (functionally equivalent to a local ATM switch providing workstations with UNI) uses E.164 numbers on its public side and either short-form local numbers or full E.164 numbers on its user side. The short form is "extension number" in usual parlance, but given the normality of DDI, every UNI typcally HAS a true E.164 number of its own by which it can be addressed from the world. I may dial only 4 digits internally, but you can dial me from outside without even knowing that I'm behind a PBX. This does require telco numbers, which is not something we can tolerate in the ATM world, but there is a case to be made for _allowing_ telco numbers on the ATM UNI. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00540; 14 Sep 93 5:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00536; 14 Sep 93 5:46 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10362; 14 Sep 93 5:46 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15974; Tue, 14 Sep 93 00:31:45 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28396; Tue, 14 Sep 93 00:31:45 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16513; Tue, 14 Sep 93 00:30:40 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16507; Tue, 14 Sep 93 00:30:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11255; Tue, 14 Sep 93 00:30:48 PDT Received: from datanet.tele.fi by Sun.COM (4.1/SMI-4.1) id AA15767; Tue, 14 Sep 93 00:30:35 PDT Message-Id: <9309140730.AA15767@Sun.COM> Received: from datanet.tele.fi by datanet.tele.fi id <04480-0@datanet.tele.fi>; Tue, 14 Sep 1993 10:30:48 +0300 To: dan@merlin.dev.cdx.mot.com Cc: laubach@matmos.hpl.hp.com, atm@sun.com In-Reply-To: <9309132234.AA02987@dbg.dev.cdx.mot.com> "dan@merlin.dev.cdx.mot.com" Subject: E.164 addressing Date: Tue, 14 Sep 1993 10:30:48 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: atm-request@atm.eng.sun.com do we really need two representations for atm addresses? why can't we convert an ATM address with E.164 plan to an ATM address with OSI NSAP plan by using an E.164 AFI, by placing the E.164 number in the IDI and by leaving the DSP empty. such an NSAP would locate an interface to the public B-ISDN in the same way as the E.164 number itself. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00761; 14 Sep 93 6:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00757; 14 Sep 93 6:46 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa23289; 14 Sep 93 2:04 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01761; Mon, 13 Sep 93 23:01:07 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA26150; Mon, 13 Sep 93 23:01:08 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16228; Mon, 13 Sep 93 22:59:54 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16222; Mon, 13 Sep 93 22:59:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08951; Mon, 13 Sep 93 23:00:01 PDT Received: from datanet.tele.fi by Sun.COM (4.1/SMI-4.1) id AA01618; Mon, 13 Sep 93 22:59:48 PDT Message-Id: <9309140559.AA01618@Sun.COM> Received: from datanet.tele.fi by datanet.tele.fi id <03974-0@datanet.tele.fi>; Tue, 14 Sep 1993 09:00:07 +0300 To: llang@cisco.com Cc: rgc@qsun.att.com, atm@sun.com In-Reply-To: <9309132036.AA28291@dreggs.cisco.com> "llang@cisco.com" Subject: E.164 addressing Date: Tue, 14 Sep 1993 09:00:07 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: atm-request@atm.eng.sun.com Conceivable, but not desirable, IMHO. I sure hope public carriers have the good sense to choose with the more general E.164 NSAP format. larry, don't worry about that. competition will surely make even AT&T one day support other than E.164 address format. telecom finland will do so from the very beginning. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00835; 14 Sep 93 6:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id al00757; 14 Sep 93 6:46 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa09171; 14 Sep 93 5:34 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA22287; Tue, 14 Sep 93 01:38:26 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00583; Tue, 14 Sep 93 01:38:23 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16685; Tue, 14 Sep 93 01:37:28 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA16679; Tue, 14 Sep 93 01:37:27 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA13217; Tue, 14 Sep 93 01:37:30 PDT Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA08445; Tue, 14 Sep 93 01:37:28 PDT Received: from bagsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA10681; Tue, 14 Sep 93 09:37:28 BST Received: from liberator.UK.Sun.COM (liberator-bb) by bagsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA07898; Tue, 14 Sep 93 09:37:04 BST Received: from express.uk.sun.com by liberator.UK.Sun.COM (4.1/SMI-4.0) id AA12977; Tue, 14 Sep 93 09:37:23 BST Date: Tue, 14 Sep 93 09:37:23 BST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Franks - SunExpress IR Message-Id: <9309140837.AA12977@liberator.UK.Sun.COM> To: atm@sun.com, Nhon.Tran@east.sun.com Subject: Re: Pls remove me from this aliase X-Orig-Sender: atm-request@atm.eng.sun.com neither do I, please remove me. thanks bob -> From atm-request@atm.Eng Mon Sep 13 23:12:27 1993 -> Date: Mon, 13 Sep 93 17:57:53 EDT -> From: Nhon.Tran@East (Nhon Van Tran - Sun USOPS IR) -> To: atm@Sun.COM -> Subject: Pls remove me from this aliase -> X-Sun-Charset: US-ASCII -> Content-Length: 58 -> Sender: atm-request@atm.Eng -> X-Lines: 5 -> -> -> I do not really know why I am getting these .. -> -> Thanks. -> ->   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00899; 14 Sep 93 7:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00895; 14 Sep 93 7:07 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26211; 14 Sep 93 7:07 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01578; Tue, 14 Sep 93 04:02:27 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02918; Tue, 14 Sep 93 04:02:22 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17017; Tue, 14 Sep 93 03:59:43 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17011; Tue, 14 Sep 93 03:59:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15422; Tue, 14 Sep 93 03:59:47 PDT Received: from dxmint.cern.ch by Sun.COM (4.1/SMI-4.1) id AA01420; Tue, 14 Sep 93 03:59:44 PDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24139; Tue, 14 Sep 1993 12:59:42 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA09907; Tue, 14 Sep 1993 12:59:29 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309141059.AA09907@dxcern.cern.ch> Subject: Can we finesse E.164 issue? To: atm@sun.com Date: Tue, 14 Sep 1993 12:59:28 +0200 (MET DST) In-Reply-To: <9309132255.AA21544@matmos.hpl.hp.com> from "Mark Laubach" at Sep 13, 93 03:55:25 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1025 X-Orig-Sender: atm-request@atm.eng.sun.com Can we finesse this issue and effectively choose all three of Mark's options? > > Ignore it for now, and submit classical draft as is, and Not quite, add a sentence saying that we > 1. Assume we can handle E.164 in ATM-FORUM NSAP's, but of course if this is proved wrong we > 2. Can deal with it in a future update the memo, and add a note saying that the SMDS ARP hardware type can consistently be used to > 3. Document another ARP hardware type for native E.164. if it later proves necessary. > This assumes we can handle the confusion of having two ARP > packet formats for ATM. > Personally I don't find this confusing at all. If I connect a host to an E.164 network I would expect to get E.164 answers to ARP requests, not artificial ATM-Forum answers. In any case hosts will need a configuration parameter to tell them whether they are connected to an ATM-Forum or to an E.164 address space. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01519; 14 Sep 93 8:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01515; 14 Sep 93 8:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa03504; 14 Sep 93 8:06 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04203; Tue, 14 Sep 93 05:01:10 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05214; Tue, 14 Sep 93 05:01:08 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17236; Tue, 14 Sep 93 04:59:59 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17230; Tue, 14 Sep 93 04:59:58 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16325; Tue, 14 Sep 93 05:00:04 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA14249; Tue, 14 Sep 93 04:59:59 PDT Received: from bigdog.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA03190; Tue, 14 Sep 93 07:59:58 EDT Received: from moxie.East.Sun.COM by bigdog.East.Sun.COM (4.1/SMI-4.1-900117) id AA04358; Tue, 14 Sep 93 07:59:53 EDT Received: by moxie.East.Sun.COM (4.1/SMI-4.1) id AA03157; Tue, 14 Sep 93 07:59:54 EDT Date: Tue, 14 Sep 93 07:59:54 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michele Walker - SunExpress IR Message-Id: <9309141159.AA03157@moxie.East.Sun.COM> To: atm@sun.com Subject: Please remove me from this alias Cc: aliases@sun.com X-Orig-Sender: atm-request@atm.eng.sun.com Please remove me from this alias also. thanks. Michele Walker > From atm-request@atm.Eng Mon Sep 13 18:13:25 1993 > Date: Mon, 13 Sep 93 15:01:51 PDT > From: Joseph.Chalhoub@Corp (Fixed Assets - Corp. Finance) > To: atm@Sun.COM > Subject: Re: E.164 addressing > Cc: aliases@Sun.COM > Sender: atm-request@atm.Eng > Content-Length: 1532 > > > Hello all: > > What kind of alias is this? and who is monitoring it? I don't > believe I asked to be added onto it. Is there a particular > person that is keeping this alias up? if so, I would like to know > and would like to be taken off it. > > To Aliases@sun: If you are the one, then take me off this > alias: atm@sun.com > > Thanks, > Joseph Chalhoub > > > > > > From atm-request@atm.Eng Mon Sep 13 14:50:02 1993 > > To: rgc@qsun.att.com > > Cc: atm@Sun.COM > > Subject: Re: E.164 addressing > > In-Reply-To: Your message of Mon, 13 Sep 1993 15:51:00 -0400 > > Date: Mon, 13 Sep 1993 14:40:45 -0700 > > From: Mark Laubach > > Sender: atm-request@atm.Eng > > Content-Length: 768 > > X-Lines: 25 > > > > > > ... > > all three NSAP modeled formats. It is therefore conceivable that > > a public UNI would support only E.164 addressing. Therefore, > > we believe that this option should be supported in > > Mark's document on Classical IP over ATM in order to be consistent with > > the current agreements in the ATM Forum. > > > > This means adding another or documenting the existing ARP hardware > > type "atm" (which is, I believe an E.164) type in the classical > > document. > > > > There are caveats/understandings for this: > > > > 1. The arp hardware type must be consistent across the LIS. > > > > 2. Some administrative care is necessary when configuring IP stations > > for generating and replying to the proper ARP types as per the LIS > > configuration. > > > > 3. Does this extend to NBMA? > > > > Mark > > > > > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01704; 14 Sep 93 8:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01700; 14 Sep 93 8:13 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa04293; 14 Sep 93 8:13 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01762; Mon, 13 Sep 93 16:49:21 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA10368; Mon, 13 Sep 93 16:49:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15072; Mon, 13 Sep 93 16:48:06 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA15066; Mon, 13 Sep 93 16:48:05 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA26380; Mon, 13 Sep 93 16:48:08 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA28550; Mon, 13 Sep 93 16:48:03 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA06544; Mon, 13 Sep 93 16:58:42 PDT Date: Mon, 13 Sep 93 16:58:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309132358.AA06544@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: atm Cc: Jeannie.Linder@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Jeannie.Linder@EBay Mon Sep 13 09:26:02 1993 Date: Mon, 13 Sep 93 09:19:14 PDT From: Jeannie.Linder@EBay (jeannie linder) To: aliases@Sun.COM Subject: atm Content-Length: 74 hi! please remove me from the "atm@sun" alias. thanks, jeannie linder ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02027; 14 Sep 93 8:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02023; 14 Sep 93 8:27 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06560; 14 Sep 93 8:27 EDT Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02541; Mon, 13 Sep 93 16:53:33 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24082; Mon, 13 Sep 93 16:13:35 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14894; Mon, 13 Sep 93 16:11:20 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA14888; Mon, 13 Sep 93 16:11:19 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23940; Mon, 13 Sep 93 16:11:22 PDT Received: from EBay.Sun.COM (female) by snail.Sun.COM (4.1/SMI-4.1) id AA11340; Mon, 13 Sep 93 16:11:18 PDT Received: from salescorp.EBay.Sun.COM by EBay.Sun.COM (4.1/SMI-4.1) id AA07053; Mon, 13 Sep 93 16:11:15 PDT Received: by salescorp.EBay.Sun.COM (4.1/SMI-4.1) id AA20169; Mon, 13 Sep 93 16:14:34 PDT Date: Mon, 13 Sep 93 16:14:34 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Looh Ting Message-Id: <9309132314.AA20169@salescorp.EBay.Sun.COM> To: atm@sun.com, Gary.Serda@corp.sun.com Subject: Re: Please take me off this aliases Cc: atm-request@atm.eng.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com me too. thanks Looh ----- Begin Included Message ----- From atm-request@atm.Eng Mon Sep 13 16:05:30 1993 Date: Mon, 13 Sep 93 15:39:09 PDT From: Gary.Serda@Corp (Gary Serda - Corporate Affairs/Sun Foundation) To: atm@Sun.COM Subject: Please take me off this aliases Sender: atm-request@atm.Eng Content-Length: 368 Me too. Thanks Gary Serda ----- Begin Included Message ----- >From atm-request@atm.Eng Mon Sep 13 15:29:18 1993 From: Beth.Tran@Corp (Beth Tran, HR/ADMIN Legal Systems) To: atm@Sun.COM Subject: Please take me off this aliases Sender: atm-request@atm.Eng Content-Length: 44 X-Lines: 4 Please take me off atm@sun.com Thanks Beth ----- End Included Message ----- ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03567; 14 Sep 93 9:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03562; 14 Sep 93 9:20 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa12908; 14 Sep 93 9:20 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA08814; Tue, 14 Sep 93 06:13:26 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06766; Tue, 14 Sep 93 06:13:24 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17534; Tue, 14 Sep 93 06:12:15 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17528; Tue, 14 Sep 93 06:12:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17950; Tue, 14 Sep 93 06:12:20 PDT Received: from cheetah.vlsi.uwaterloo.ca by Sun.COM (4.1/SMI-4.1) id AA08657; Tue, 14 Sep 93 06:11:58 PDT Received: by cheetah.vlsi.uwaterloo.ca id ; Tue, 14 Sep 93 09:11:56 -0400 Date: Tue, 14 Sep 93 09:11:56 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Kesidis Message-Id: <9309141311.AA17050@cheetah.vlsi.uwaterloo.ca> To: atm@atm.eng.sun.com Subject: remove me from alias X-Orig-Sender: atm-request@atm.eng.sun.com Please remove me from the atm@sun alias too. -George Kesidis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04488; 14 Sep 93 9:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04484; 14 Sep 93 9:51 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa16312; 14 Sep 93 9:51 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11990; Tue, 14 Sep 93 06:46:26 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07138; Tue, 14 Sep 93 06:46:25 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17674; Tue, 14 Sep 93 06:45:24 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA17668; Tue, 14 Sep 93 06:45:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18969; Tue, 14 Sep 93 06:45:30 PDT Received: from nsco.network.com by Sun.COM (4.1/SMI-4.1) id AA11875; Tue, 14 Sep 93 06:45:25 PDT Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA15227; Tue, 14 Sep 93 08:48:36 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA13726; Tue, 14 Sep 93 08:44:07 CDT Date: Tue, 14 Sep 93 08:44:07 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309141344.AA13726@anubis.network.com> To: atm@sun.com Subject: Re: Classical draft holding.... X-Orig-Sender: atm-request@atm.eng.sun.com After reading the comments on E.164 addresses, I have a comment: It is true that there are semantic differences associated, by context, with the use of direct E.164 and NSAP encapsulated E.164. However, it is probably true in practice that this is not strictly a public/private distinction. A private might (ignoring the ATM Forum) use E.164, while some public providers will probably use NSAPs, some with E.164 inside them. Given public/private interconnect, it also follows that some border switches will have to convert between the two. [No padding is necessary, as NSAPs have a length field associated with them.] Given the various combinations, it is clear that sometimes the system device driver on the originating station will have to understand both, and sometimes it will be able to use either. As such, I think that system should have the smarts, rather than the protocol. (I can envision cases where the responding entities thinks one form is correct, when it is actually the other. It may not be possible, but I can imagine it.) It seems that versatility and capability are enhanced if the ARP mechanism uses one address type. Now, to throw in a new monkey-wrench. Does the physical address field in the ARP request/response need to be able to carry both an address and a sub-address? Thanks, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12252; 14 Sep 93 13:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12246; 14 Sep 93 13:36 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa12881; 14 Sep 93 13:36 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15224; Tue, 14 Sep 93 10:28:11 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21962; Tue, 14 Sep 93 10:28:10 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18137; Tue, 14 Sep 93 10:26:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18131; Tue, 14 Sep 93 10:26:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02529; Tue, 14 Sep 93 10:26:51 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA14973; Tue, 14 Sep 93 10:26:46 PDT Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05068; Tue, 14 Sep 93 10:22:38 -0700 Message-Id: <9309141722.AA05068@matmos.hpl.hp.com> To: Joel Halpern Cc: atm@sun.com Subject: Re: Classical draft holding.... In-Reply-To: Your message of Tue, 14 Sep 1993 08:44:07 -0500 Date: Tue, 14 Sep 1993 10:22:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach X-Orig-Sender: atm-request@atm.eng.sun.com Now, to throw in a new monkey-wrench. Does the physical address field in the ARP request/response need to be able to carry both an address and a sub-address? I was thinking about this last night too but am lacking documents here at SIGCOMM to research this a little deeper. I can change the ARP packet format to have both an ATM address and ATM sub-address field for both source and target. I can restrict the classical document to set the ATM address fields to null/zero for now and to use the ATM-FORUM NSAP in the sub-address fields. This should meet our immediate needs and would give us the growth room for the future and still keep the same ARP packet format. Comments? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14781; 14 Sep 93 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14777; 14 Sep 93 14:38 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20415; 14 Sep 93 14:38 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17580; Tue, 14 Sep 93 10:39:47 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23536; Tue, 14 Sep 93 10:39:37 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18189; Tue, 14 Sep 93 10:38:03 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18183; Tue, 14 Sep 93 10:38:02 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03458; Tue, 14 Sep 93 10:38:06 PDT Received: from Corp.Sun.COM (lemay) by snail.Sun.COM (4.1/SMI-4.1) id AA03513; Tue, 14 Sep 93 10:38:01 PDT Received: from commish.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA23969; Tue, 14 Sep 93 10:37:43 PDT Received: by commish.Corp.Sun.COM (4.1/SMI-4.1) id AA13154; Tue, 14 Sep 93 10:38:40 PDT Date: Tue, 14 Sep 93 10:38:40 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Larsen Message-Id: <9309141738.AA13154@commish.Corp.Sun.COM> To: atm@sun.com, rgc@qsun.att.com Subject: Re: E.164 addressing X-Orig-Sender: atm-request@atm.eng.sun.com How did I get on this distribution list? Please remove me....thank you... Regards, greg.larsen@corp.sun.com ----- Begin Included Message ----- From atm-request@atm.Eng Mon Sep 13 14:58:47 1993 To: ddp@fore.com (Drew Daniel Perkins) Cc: atm@Sun.COM, rgc@qsun.att.com Subject: Re: E.164 addressing Content-Length: 944 X-Lines: 29 From: ddp@fore.com (Drew Daniel Perkins) Subject: Re: E.164 addressing I believe that SMDS also uses E.164 addresses. We can just use ARP hardwar e type 14 (SMDS) if we loosen it's definition to "E.164 networks". .... ARP hardware type "atm" as registered by John Burnet from Adaptive/NET,\ uses E.164 addresses. John, do you have details? Personally, I would much rather the ATM driver/interface worry about packing and unpacking an E.164 address into an NSAP format for ARP/InARP. I would much rather have only one ARP packet format to worry about and to not have to add in another variable in when it comes to implementing IP over ATM. The keep it simple approach seems to me to be best. Remember, the format of the information within the ARP does not have to match the ATM address format used within the LIS provided that there is a straightforward way to go back and forth between the two. Mark ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14813; 14 Sep 93 14:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14809; 14 Sep 93 14:39 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20544; 14 Sep 93 14:39 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17268; Tue, 14 Sep 93 10:38:11 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23313; Tue, 14 Sep 93 10:38:03 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18177; Tue, 14 Sep 93 10:36:43 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18171; Tue, 14 Sep 93 10:36:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03347; Tue, 14 Sep 93 10:36:46 PDT Received: from matmos.hpl.hp.com by Sun.COM (4.1/SMI-4.1) id AA16919; Tue, 14 Sep 93 10:36:28 PDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05363; Tue, 14 Sep 93 10:32:37 -0700 Date: Tue, 14 Sep 93 10:32:37 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309141732.AA05363@matmos.hpl.hp.com> To: atm@sun.com Subject: further classical comments X-Orig-Sender: atm-request@atm.eng.sun.com Apologies, this didn't go out to the whole list. I'm in the process of integrating and responding to this today. Mark Date: Thu, 9 Sep 93 13:29:04 EDT From: John Amenyo To: laubach@matmos.hpl.hp.com Cc: pgross@ans.net, jta@ans.net Subject: Comments on "Classical IP..." Message-Id: Hello, Phill Gross of ANS (pgross@ans.net) suggested that I take a look at your draft document "Classical IP and ARP over ATM". I have attached a list of comments about points where I had difficulty in reading or understanding the document. Let me state forthwith that I found your effort to be an important contribution to the advancement of the state-of-the-art of "IP over ATM". I hope you find the comments useful. If I can be of any help, please let me know. jtA -------------attachment----------- a) o IP destinations map to VC's via ARP and end-to-end IP routing stays essentially the same, consistent with current model. o All members of an LIS must have a mechanism for resolving IP protocol addresses to ATM hardware addresses via ARP [3] when using SVC's and for resolving ATM hardware addresses to IP protocol addresses via InARP [12] when using SVC's and PVC's. COMMENTS: What is being mapped/resolved? Is it VPC/VCCs or ATM addresses? I was confused throughout the whole document that this distinction is not kept clear. I suggest that the relevant sentences be rewritten to indicate that IP addresses are being resolved into ATM addresses during ARP and vice versa during InARP. Why is there an emphasis on "ATM hardware addresses" instead of on "ATM addresses"? Incidentally, as noted by others on the discussion list, all references in the document to "virtual circuit" should be changed to "virtual channel". E.g., VCC, PVC, SVC. b) o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pairs of stations. COMMENT: It reads better to say that: "... the virtual topology underlying the intercommunication among the members of an LIS is fully meshed..." c) It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. COMMENT: Is it allowed in the ATM UNI specs that "a single physical ATM interface [more than one] individual ATM address[...]"? d) Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12] and all IP stations are required to support these protocols. COMMENTS: Is there above strictly true? Notice that later on the need for an ARP server is introduced and required. This will seem to suggest that ARP and InARP requests are not broadcasted to all IP stations in an ATM-based LIS; instead, ARP and InARP requests and replies are between IP stations and the ARP server of the LIS. However, if all the IP stations of an ATM-based LIS can participate in ARP and InARP exchanges in the LIS, what is the need for the ARP server and when does it come into play? Furthermore, it states latter that the ARP_NAK is an extension to the ARP protocol in [3]. Hence, it must be clarified that an IP station needs to support a specific extension of ARP. e) All IP stations supporting permanent virtual circuits are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those virtual circuits using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant virtual circuit from the virtual circuit on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM source and/or target hardware address is unknown, the corresponding hardware address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. COMMENTS: What is a "strict PVC environment" and therefore what is a "non-strict or flexible PVC environment" and how useful is this distinction? How will a receiver (of an InARP request) *infer* the relevant VPC/VCC ...? Change "...target hardware address..." to "...target ATM address..." Again note the conflation of the concepts of a VPC/VCC and an ATM address. f) ATM switched virtual circuits require support for ARP in the non- broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for resolving the ARP requests of all IP stations within the LIS. COMMENTS: The recognition of the "non-broadcast, non-multicast" nature of the current ATM-based networks seems to be in conflict with the requirements of [3] and [12], which this document wants to be supported. As noted in two paragraphs later, insisting on exactly one ARP server per and ATM-based LIS may be lead to performance bottlenecks (if the number of IP stations in an LIS is quite large and/or there are frequent changes to the LIS composition). It may be useful for the current document to accept up front that multiple ARP servers per LIS may be needed and suggest explicit inter-coordination mechanisms for the multiple ARP servers. g) The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point virtual circuit. The server, upon receiving a new virtual circuit specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. COMMENTS: What does the phrase "... upon receiving a new virtual circuit..." mean? I suggest this should be changed to either "... upon receiving a new connection request..." or to "...upon the completion of an ATM-level call/connection set up ..." Incidentally, is an ARP server an IP station or just an ATM-level network element (e.g., does it have both an IP and ATM address or just an ATM address)? Would it be relevant for the document to specify whether the VPC/VCC between an ARP client (IP station) and an ARP server is permanent or switched? h) The ARP server mechanism requires that each client be administratively configured with the ATM hardware address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. This ARP server must be administratively configured so that it knows it is the ARP server. COMMENTS: What does it mean that "...[an] ARP server must be administratively configured so that it *knows* it is the ARP server..."? How does it know? How does it use this information? Once again, does the document take a position on whether the ARP server is an IP station on an ATM-level network element? i) The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. COMMENTS: This sentence, about *shared ARP servers" across multiple LIS, seems to violate the spirit or at least the impetus behind the introduction of "Classical IP and ARP over ATM"! Earlier in the document, it has been repeatedly stated that the ARP server of an LIS is "located within" the LIS. This sentence now implicitly indicates that ARP servers can be shared by multiple LIS. This will violate issues of ownership, administrative control and the need for logical separations (e.g., firewalls). The Classical IP/ARP over ATM is most useful in supporting multiple virtual (private) networks (VPN) over the same ATM-based network fabric/infrastructure. I call this the Condominium (or Hotel) Principle in the use of ATM networks. Allowing the sharing of resources, such as ARP servers, may not be a good idea in this context. Note that the same physical unit/box can be implemented to support the ARP servers of more than one LIS. However, the ARP servers should be kept separate, both conceptually and logically. (C.f., routers/gateways that straddle more than one LIS). j) The ARP server accepts switched virtual circuit connections from other ATM stations. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM hardware address. The server will add (or update) the map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP hardware address does not match the table entry hardware address and there is an open virtual circuit associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. COMMENTS: Change "...accepts switched virtual circuit connections..." to "...accepts ATM-level connections (requests)..." The concept of an "IP station" was defined earlier, but the concept of an "ATM station" was never defined. Note the comments made earlier about "shared ARP servers". k) ARP table information timeout update: when the server receives an ARP request over a virtual circuit, and the source information (IP and hardware address) match the association already in the ARP table, and the hardware address matches that associated with the virtual circuit (in the SVC environment), then the server may update the timeout on the ARP table entry. COMMENTS: I am *completely* confused by the above sentence! E.g., an ARP server will receive all ARP requests over a VPC/VCC, so why draw attention to this fact? Once again, what is being resolved, is it ATM addresses or VPC/VCC "ids"? Are they the same? Always? Sometimes? Also, I can't grasp the logic of the timeout update. May need to re-write. l) ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh ARP information about other IP stations. COMMENT: Change "...to gain and refresh ARP information..." to "...to gain and refresh its own ARP table entry/information..." m) 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP table entries. COMMENT: Change "...used to build/refresh ARP table entries." to "...used to build/refresh its own client ARP table entries." n) 5. Provide an ARP table aging function to remove old ARP tables entries after a convenient period of time. COMMENT: Change "...remove old ARP tables entries..." to "...remove its own old client ARP table entries..." o) Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. COMMENT: Although it may seem obvious, the ARP/InARP model was never defined in the document. Therefore, only the cognoscenti may immediately understand the use of words like: request, reply, ARP table, client. Would it be too much to ask to insert a brief description of the model, earlier in the document? p) ARP Table Aging - All stations A client or server must have knowledge of any open VC's it has (permanent or switched), their association with an ARP table entry, and in particular, which VC's support LLC/SNAP encapsulation. COMMENTS: Are "IP stations" or "ATM stations" being meant in the subtitle? Change "A client or server must..." to "An ARP client or server must..." q) Internet addresses are assigned independent of ATM-FORUM NSAP addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to ATM hardware addresses when needed. COMMENTS: What is meant by "Internet address"? It should be changed to refer to "IP address". Also, it may be a good idea to change references to "host" or "hosts" to become "IP host" or "IP hosts". Furthermore, why the reference to "(IP) hosts" and not to "IP stations"? r) The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. COMMENT: Change "... of the AAL5 SDU." to "... of the AAL5 CPCS-SDU." s) Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. COMMENT: Refer to earlier comments about the apparent conflict between supporting [3] and [12] and the role of an ARP server located within an LIS. t) [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [12] Bradely, T., and Brown, C., "Inverse Address Resolution Protocol", RFC1293, USC/Information Sciences Institute, January 1992.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15077; 14 Sep 93 14:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15073; 14 Sep 93 14:53 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa22203; 14 Sep 93 14:53 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17922; Tue, 14 Sep 93 10:41:22 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23778; Tue, 14 Sep 93 10:41:17 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18204; Tue, 14 Sep 93 10:39:24 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18198; Tue, 14 Sep 93 10:39:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03572; Tue, 14 Sep 93 10:39:23 PDT Received: from relay.fore.com by Sun.COM (4.1/SMI-4.1) id AA17423; Tue, 14 Sep 93 10:38:54 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA17045; Tue, 14 Sep 93 13:39:12 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA22053; Tue, 14 Sep 93 13:38:41 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA15279; Tue, 14 Sep 93 13:38:35 EDT Date: Tue, 14 Sep 93 13:38:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309141738.AA15279@marlin.fore.com> To: atm@sun.com, jmh@anubis.network.com Subject: Re: Classical draft holding.... X-Orig-Sender: atm-request@atm.eng.sun.com > It is true that there are semantic differences associated, by context, > with the use of direct E.164 and NSAP encapsulated E.164. However, it > is probably true in practice that this is not strictly a public/private > distinction. A private might (ignoring the ATM Forum) use E.164, while > some public providers will probably use NSAPs, some with E.164 inside > them. Given public/private interconnect, it also follows that some > border switches will have to convert between the two. [No padding is > necessary, as NSAPs have a length field associated with them.] In section "5.1.3.1 Private Networks" it says: "However, the ATM address will always be 20 octets". This seems to indicate that addresses WILL always be padded. > Now, to throw in a new monkey-wrench. Does the physical address field > in the ARP request/response need to be able to carry both an address and > a sub-address? Ouch! I suspect that it does. Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15938; 14 Sep 93 15:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15934; 14 Sep 93 15:29 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26502; 14 Sep 93 15:29 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA06069; Tue, 14 Sep 93 12:25:08 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05627; Tue, 14 Sep 93 12:25:10 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18691; Tue, 14 Sep 93 12:23:43 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18685; Tue, 14 Sep 93 12:23:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12239; Tue, 14 Sep 93 12:23:46 PDT Received: from motgate.mot.com by Sun.COM (4.1/SMI-4.1) id AA05799; Tue, 14 Sep 93 12:23:39 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA02774; Tue, 14 Sep 1993 14:23:38 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15) id AA10017; Tue, 14 Sep 1993 14:23:28 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA26075 (5.65a+/IDA-1.4.2 for jmh@anubis.network.com); Tue, 14 Sep 93 15:23:17 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03614 (5.65a+/IDA-1.4.2 for atm@sun.com); Tue, 14 Sep 93 15:23:15 -0400 Message-Id: <9309141923.AA03614@dbg.dev.cdx.mot.com> To: Joel Halpern Cc: atm@sun.com Subject: Re: Classical draft holding.... In-Reply-To: Your message of "Tue, 14 Sep 93 08:44:07 CDT." <9309141344.AA13726@anubis.network.com> Date: Tue, 14 Sep 93 15:23:13 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp X-Orig-Sender: atm-request@atm.eng.sun.com > A private might (ignoring the ATM Forum) use E.164 Problem is that private networks are never assigned blocks of numbers in the public network numbering plan except insofar as they are directly connected, PBX-like to the public network. > Given public/private interconnect, it also follows that some > border switches will have to convert between the two Yep, that's specified in the ATM Forum Spec [and will be an issue as we get into VC Routing :-( ] > No padding is > necessary, as NSAPs have a length field associated with them. Not so. There is a length field in the Called and Calling Party Number IE, but the agreement was that the length of an NSAP address is always 20 octets. > Does the physical address field > in the ARP request/response need to be able to carry both an address and > a sub-address? I was just about to say no, but there is one case where it is necessary: if the host is connected to a public network which only supports E.164 addressing in E.164/international format, and wants to communicate with a host or router which is connected to a private network that uses an NSAP format, the router needs to provide the E.164 number that locates the interface between the public network and the private network, and the NSAP address of the ATM Endpoint.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16187; 14 Sep 93 15:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16183; 14 Sep 93 15:36 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27362; 14 Sep 93 15:36 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA06617; Tue, 14 Sep 93 12:27:54 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05950; Tue, 14 Sep 93 12:27:51 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18704; Tue, 14 Sep 93 12:26:18 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18698; Tue, 14 Sep 93 12:26:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12441; Tue, 14 Sep 93 12:26:17 PDT Received: from lanslide.hls.com by Sun.COM (4.1/SMI-4.1) id AA06216; Tue, 14 Sep 93 12:26:04 PDT Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA01220; Tue, 14 Sep 93 12:25:51 PDT Received: by msgate.hls.com with Microsoft Mail id <2C961DCD@msgate.hls.com>; Tue, 14 Sep 93 12:38:53 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: ip over atm Subject: E.164 Formats and Classical ARP over ATM Date: Tue, 14 Sep 93 12:25:00 PDT Message-Id: <2C961DCD@msgate.hls.com> Encoding: 143 TEXT X-Mailer: Microsoft Mail V3.0 X-Orig-Sender: atm-request@atm.eng.sun.com My (long) 2c worth on this: It strikes that the issue here is really nothing to do with address formats, per se, but with protocol architectures. For those of you who were not involved with the (interminable!) discussions over the multiple E.164 address formats at the Forum, in my opinion, the crux of the argument came down to whether or not public networks (i.e. likely users of the non-NSAP E.164 address formats) wished to participate in the _private_ NNI protocols that would operate over private ATM networks, and would use the NSAP encoded _private_ ATM addresses. While some of the PTTs (e.g. Finish Telecom, as represented by Juha) said that they too would use private ATM addressing, many of the others were equally adamant that they would use E.164 only, and, by implication, not participate in P-NNI protocols. This suggests that such public networks would operate as _subnetworks_ of the private ATM networks, much as Frame Relay and X.25, for instance, operate as subnetworks of IP networks today. In order to get connectivity to private ATM nodes, strict protocol layering requires that directly attached public end nodes then need to support _two_ levels of addressing, the lowest level using E.164 addresses, and the upper level using NSAP encoded addresses. _Direct_ connectivity between nodes using NSAP addresses, and between nodes using E.164 addresses _only_, as suggested by some emails, I would suggest, is not a semantic issue, but a violation of layering. In turn, this suggests that an _additional ATM_ address resolution is required at the public/private interface, to map the private ATM addressing into the public E.164 addresses. Typically, as I once went through during the addressing discussions at the Forum, this would require that the private ATM addresses, of whatever format, be mapped into the subaddress fields of the signaling request, and that through some resolution mechanism, the address fields be filled with the E.164 addresses of the end nodes on the public network. It should be noted that this assumes that this resolution occur _within_ the _ATM network_, not in some external entity like a router, since this would preclude end to end signaling flows (i.e. they would be stopped by the router). On the other hand, if people always wanted to put a router at the ingress/egress point to a public ATM network (e.g. for firewalls etc) then the router would internally need to do this resolution (independent of the IP resolution). (Its not clear to me, however, whether the IP over ATM draft should necessarily mandate the need for a router in this configuration). In any case,this subnetwork concept was adopted as part of the reference configuration for the private NNI protocol at the recent Forum meeting in Boston. Admittedly, however, when this decision was taken, no one was too clear on how this resolution would actually occur, and what the protocol stack might be on the public network end station, though, of course, everyone agrees that interoperability between public and private stations is absolutely required. In terms of the IP ARP discussion, the significance of this is that essentially, assuming that it is defined as a protocol operating over the _private_ ATM protocol layer, it should never see the public E.164 addresses at all; instead, as noted above, an additional _ATM_ address resolution is required at the public/private network boundary. This also requires that a public node needs to support _both_ address types, so that is responding to an ARP request, for instance, it would respond with its NSAP encoded address, which would, in turn, need to be resolved to its E.164 address. By extension, one would presumably need to define separate ARP like mechanisms (much as operate over Frame relay today), to allow end nodes to determine mappings from NSAP encoded addresses to E.164 addresses, and vice versa. Logically, these mechanisms would be quite distinct from the IP over (private) ATM ARP mechanisms. Of course, defining all these additional mechanisms is a real pain. We could either accept it as the price of having to support both public and private ATM networks, or maybe work on some simple algorithmic ways of transforming between the address formats - e.g. the no brainer solution of always mapping the E.164 address into the NSAP encoded E.164 address, in which case the ARP mechanism would presumably only need to know about the latter. In such a case, the ingress point into the ATM network could presumably respond to the ARP request, if it knows the node to be reachable through one of its ports, or simply forward it to the nodes to which it is attached. Some additional (ATM level) mechanism would still presumably be need to be defined to allow nodes to identify which of their inteface are to ATM subnetworks, and hence where an address resolution needs to be performed (this is one of the requirements for the P-NNI protocol). We also need some protocol layering model for how public nodes will work, and how the addresses will be mapped from E.164 into NSAP. Regardless of this, I suspect we also need mechanisms akin to inverse ARP to allow public nodes to discover their logical connectivity, particularly since many public network connections (logical NNIs, operating over public UNI, as defined by the P-NNI group) may be PVCs, to start off with. Would this group work on those mechanisms too? I would suggest, in any case, that the scope of the draft Classical ARP over ATM RFC be amended to incorporate some discussion of the ATM subnetwork case, since it will clearly be an important case to support (assuming people think public network ATM deployment is imminent...). Any thoughts on all this? Is my conception of a layered model incorrect? Perhaps someone else who goes to the Forum can confirm or refute my impressions of what we were talking about there. Anthony Alles.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16214; 14 Sep 93 15:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16210; 14 Sep 93 15:39 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27745; 14 Sep 93 15:39 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA07746; Tue, 14 Sep 93 12:32:57 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06635; Tue, 14 Sep 93 12:32:52 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18754; Tue, 14 Sep 93 12:31:40 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18747; Tue, 14 Sep 93 12:31:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13008; Tue, 14 Sep 93 12:31:40 PDT Received: from motgate.mot.com by Sun.COM (4.1/SMI-4.1) id AA06920; Tue, 14 Sep 93 12:29:16 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA03119; Tue, 14 Sep 1993 14:29:05 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15) id AA10565; Tue, 14 Sep 1993 14:29:02 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA26207 (5.65a+/IDA-1.4.2 for laubach@matmos.hpl.hp.com); Tue, 14 Sep 93 15:29:01 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03624 (5.65a+/IDA-1.4.2 for atm@sun.com); Tue, 14 Sep 93 15:28:59 -0400 Message-Id: <9309141928.AA03624@dbg.dev.cdx.mot.com> To: Mark Laubach Cc: atm@sun.com Subject: Re: Classical draft holding.... In-Reply-To: Your message of "Tue, 14 Sep 93 10:22:38 PDT." <9309141722.AA05068@matmos.hpl.hp.com> Date: Tue, 14 Sep 93 15:28:58 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp X-Orig-Sender: atm-request@atm.eng.sun.com > I can change the ARP packet format to have both an ATM address and ATM > sub-address field for both source and target. I can restrict the > classical document to set the ATM address fields to null/zero for now > and to use the ATM-FORUM NSAP in the sub-address fields. This should > meet our immediate needs and would give us the growth room for the > future and still keep the same ARP packet format. Based on my response to Joel, suppose you had an E.164 field and an NSAP field, either or both of which could be used. If the host is attached to a private network or a 'progressive' public network, it will encode the content of the NSAP field in the called party number IE. If it is attached to a 'reactionary' public network, it will encode the content of the E.164 field in the called party number IE and the content of the NSAP field in the called party subaddress IE.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16719; 14 Sep 93 16:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16715; 14 Sep 93 16:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02035; 14 Sep 93 16:06 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12011; Tue, 14 Sep 93 12:52:35 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08424; Tue, 14 Sep 93 12:52:28 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18979; Tue, 14 Sep 93 12:50:27 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18973; Tue, 14 Sep 93 12:50:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14496; Tue, 14 Sep 93 12:50:24 PDT Received: from att.att.com (gw1.att.com) by Sun.COM (4.1/SMI-4.1) id AA11502; Tue, 14 Sep 93 12:50:00 PDT Message-Id: <9309141950.AA11502@Sun.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rgc@qsun.att.com Date: Tue, 14 Sep 93 15:41 EDT Original-From: qsun!rgc (Robert G Cole +1 908 949 1950) To: atm@sun.com Subject: e.164 X-Orig-Sender: atm-request@atm.eng.sun.com We were not saying that public networks will ONLY support E.164 addresses. In fact the ATM forum spec allows for three cases: 1 ) only E.164, 2 ) only private ATM address structure (all three NSAP modeled formats), 3) both Therefore, any scheme we devise should allow for all the above. This means, we believe, that there needs to be a robust method for the router to construct the appropriate connect request packet with all the addresses properly intrepreted. This means that schemes which simply extract E.164 from the private NSAP modeled formats will not work for case 3 above. There is nothing that precludes a private network operator from using one of its E.164 interface identifiers as a network identifier in the NSAP modeled private ATM address. So there needs to be a mechanism to distinguish between the two forms. Bob and Kamlesh,   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16735; 14 Sep 93 16:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16731; 14 Sep 93 16:07 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02128; 14 Sep 93 16:07 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12012; Tue, 14 Sep 93 12:52:35 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08422; Tue, 14 Sep 93 12:52:27 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18970; Tue, 14 Sep 93 12:50:19 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA18963; Tue, 14 Sep 93 12:50:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14483; Tue, 14 Sep 93 12:50:16 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (4.1/SMI-4.1) id AA11470; Tue, 14 Sep 93 12:49:46 PDT Received: by inet-gw-1.pa.dec.com; id AA27043; Tue, 14 Sep 93 12:49:35 -0700 Received: by flashy.tay2.dec.com (5.65/MS-081993); id AA04505; Tue, 14 Sep 1993 15:49:33 -0400 Message-Id: <9309141949.AA04505@flashy.tay2.dec.com> Date: Tue, 14 Sep 1993 15:39:48 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: atm@sun.com Subject: Re: E.164 addressing X-Vms-To: US1RMC::"Juha.Heinanen@datanet.tele.fi" X-Vms-Cc: SMTP%"atm@Sun.com" X-Orig-Sender: atm-request@atm.eng.sun.com >do we really need two representations for atm addresses? why can't we convert an ATM address with E.164 plan to an ATM address with OSI NSAP plan by using an E.164 AFI, by placing the E.164 number in the IDI and by leaving the DSP empty. This isn't guaranteed to work. The "CCITT" full address format, from Q.931 and I think allowed in Q.93B, has an E.164 (or similar) "address", and a 20-octet subaddress. The subaddress is intentionally the size of an NSAP. This way, you can send the E.164 address to identify the Subnetwork-like Point of Attachment and the subaddress to identify the destination. Encoding E.164 into the NSAP format doesn't permit subaddresses to be used, so it restricts connectivity to those of us who do not choose to use the pseudo-OSI format. (Why is it, btw, that some of the most rabid OSI-haters in the world suddenly like NSAPs, but would't give two shakes for a TUBA? Just wondering out loud.) I was happier with Mark's idea: Permit the ARP-ish format to have a subaddress field, and always put the NSAP into the subaddress field. If NSAP is all you use, then the E.164 address field can have a null value. The E.164 should, of course, have a type_of_number associated with it, as in Q.931. SMDS isn't quite the same, since it is NEVER a private E.164-format number, but at least it does have a field. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17292; 14 Sep 93 16:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17288; 14 Sep 93 16:26 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa05507; 14 Sep 93 16:26 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17643; Tue, 14 Sep 93 13:22:21 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11452; Tue, 14 Sep 93 13:22:22 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19227; Tue, 14 Sep 93 13:21:10 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19221; Tue, 14 Sep 93 13:21:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16709; Tue, 14 Sep 93 13:21:14 PDT Received: from radiomail.net by Sun.COM (4.1/SMI-4.1) id AA17407; Tue, 14 Sep 93 13:21:06 PDT Received: from ulf (ulf.radiomail.net) by radiomail.net with SMTP id AA13141 (5.65c+/IDA-1.4.4 for ); Tue, 14 Sep 1993 13:19:42 -0700 Message-Id: <199309142019.AA13141@radiomail.net> Date: Tue, 14 Sep 1993 13:18:44 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach (via RadioMail) Cc: atm@sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Classical draft holding.... To: dan@merlin.dev.cdx.mot.com X-Orig-Sender: atm-request@atm.eng.sun.com >> Does the physical address field >> in the ARP request/response need to be able to carry both an address and >> a sub-address? >I was just about to say no, but there is one case where it is necessary: if >the >host is connected to a public network which only supports E.164 addressing in >E.164/international format, and wants to communicate with a host or router >which >is connected to a private network that uses an NSAP format, the router needs >to >provide the E.164 number that locates the interface between the public network >and the private network, and the NSAP address of the ATM Endpoint. This is true for connection setup, but need this be true for ARP? From the standpoint of either station, the NSAP should be unique and sufficent for resolving ARP requests, right or are we overloading the ARP table to also include all the call setup addressing information? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17451; 14 Sep 93 16:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17447; 14 Sep 93 16:35 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06497; 14 Sep 93 16:34 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18569; Tue, 14 Sep 93 13:28:13 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11930; Tue, 14 Sep 93 13:28:15 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19294; Tue, 14 Sep 93 13:26:52 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19288; Tue, 14 Sep 93 13:26:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17109; Tue, 14 Sep 93 13:26:58 PDT Received: from motgate.mot.com by Sun.COM (4.1/SMI-4.1) id AA18332; Tue, 14 Sep 93 13:26:42 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA07796; Tue, 14 Sep 1993 15:26:38 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15) id AA17488; Tue, 14 Sep 1993 15:26:36 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA00216 (5.65a+/IDA-1.4.2 for laubach@radiomail.net); Tue, 14 Sep 93 16:26:34 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03660 (5.65a+/IDA-1.4.2 for atm@sun.com); Tue, 14 Sep 93 16:26:31 -0400 Message-Id: <9309142026.AA03660@dbg.dev.cdx.mot.com> To: Mark Laubach (via RadioMail) Cc: atm@sun.com Subject: Re: Classical draft holding.... In-Reply-To: Your message of "Tue, 14 Sep 93 13:18:44 PDT." <199309142019.AA13141@radiomail.net> Date: Tue, 14 Sep 93 16:26:29 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp X-Orig-Sender: atm-request@atm.eng.sun.com > This is true for connection setup, but need this be true for ARP? From the > standpoint > of either station, the NSAP should be unique and sufficent for resolving ARP > requests, right or are we overloading the ARP table to also include all the > call setup addressing information? Unless I completely misunderstand your architecture, it seems to me that you'd need to get enough information from ARP to set up an ATM call/connection to the next router or host. In this scenario, 'enough information' would include both addresses.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18443; 14 Sep 93 17:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18439; 14 Sep 93 17:44 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa17111; 14 Sep 93 17:44 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00398; Tue, 14 Sep 93 14:38:43 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19565; Tue, 14 Sep 93 14:38:43 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19572; Tue, 14 Sep 93 14:36:50 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19566; Tue, 14 Sep 93 14:36:49 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA22076; Tue, 14 Sep 93 14:36:56 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA13565; Tue, 14 Sep 93 14:36:47 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA13954; Tue, 14 Sep 93 14:47:26 PDT Date: Tue, 14 Sep 93 14:47:26 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142147.AA13954@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: please remove Cc: Ghufran.Ahmed@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Ghufran.Ahmed@EBay Mon Sep 13 16:29:58 1993 Date: Mon, 13 Sep 93 16:20:38 PDT From: Ghufran.Ahmed@EBay (Ghufran Ahmed) To: requests@Sun.COM Content-Length: 50 please remove me from the atm@sun alias. ghufran ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18490; 14 Sep 93 17:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18485; 14 Sep 93 17:55 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa18403; 14 Sep 93 17:55 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02691; Tue, 14 Sep 93 14:50:27 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20988; Tue, 14 Sep 93 14:50:23 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19687; Tue, 14 Sep 93 14:49:04 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19681; Tue, 14 Sep 93 14:49:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22969; Tue, 14 Sep 93 14:49:09 PDT Received: from lanslide.hls.com by Sun.COM (4.1/SMI-4.1) id AA02454; Tue, 14 Sep 93 14:49:00 PDT Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA07490; Tue, 14 Sep 93 14:48:47 PDT Received: by msgate.hls.com with Microsoft Mail id <2C963F4F@msgate.hls.com>; Tue, 14 Sep 93 15:01:51 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: Subbu Subramaniam Cc: ip over atm Subject: Re: E.164 Formats and Classical ARP over ATM Date: Tue, 14 Sep 93 14:49:00 PDT Message-Id: <2C963F4F@msgate.hls.com> Encoding: 101 TEXT X-Mailer: Microsoft Mail V3.0 X-Orig-Sender: atm-request@atm.eng.sun.com Subbu, >From: Subbu Subramaniam >To: anthony >Subject: Re: E.164 Formats and Classical ARP over ATM >Date: Tuesday, 14 September 1993 2:10PM > >Anthony, > >I think your email summarizes most of the issues regarding addressing. >However, I have a couple of questions/comments. > > I fail to see why we need to layer these two addresses in a > hierarchy, and why not place them side-by-side (the ATM interface > in question has 2 addresses -- one in the NSAP encoded format, and > the other, its native address). If we place them aside each other > rather than above or below, it should (architecturlally) be possible > to connect from an NSAP-based address to E.164 address and vice-versa > (as long as, of course, the addresses are resolved correctly. The > easiest solution, as you proposed is perhaps the direct translation > of the NSAP encoded version to the native E.164 and vice-cersa.). > > Are you in agreement here? I think I do agree, even though from a strict protocol layering viewpoint I don't think that 'side by side' addresses (which surely implies side by side protocol layers!) makes too much sense. From a pragmatic viewpoint, however, I think the approach suggested by people about having the ARP return, for a public node, the NSAP address as the subaddress and the E.164 address as the main address (why that particular order, BTW? Even though this is the way the addresses will be carried in _signaling requests_, from the protocol layering viewpoint, the E.164 address is the subaddress) makes a lot of sense. That way, a single ARP request can return both the relevant addresses (whether or not they are algorithmically related), and save an address resolution. Note, however, that this is only useful in a border node (i.e. a node that is at the ingress point to a public network), since this is the only node that has to do the NSAP to E.164 address resolution. A private node would only use the NSAP address, and leave the subaddress field blank. > [... deleted ....] > > >Some additional (ATM level) mechanism would still presumably be need to be >defined to allow >nodes to identify which of their inteface are to ATM subnetworks, and hence >where an >address resolution needs to be performed (this is one of the requirements >for the P-NNI >protocol). We also need some protocol layering model for how public nodes >will work, and >how the addresses will be mapped from E.164 into NSAP. > > I dont understand this at all. By a "node" do you mean a switch > or a router? If it is a router, then in the classical case, we > will be ARPing for the router's ATM addres, so we dont need to > look further. From the viewpoint of the P-NNI protocol, 'node' refers to a switching system (to use the terminology we defined at the last meeting), which needs to do the address resolution before forwarding a signal request across a logical NNI (i.e. into the subnetwork). In this case, the switching system needs some means of identifying which of its ports are actually private NNI (and hence don't need the address resolution) and which are 'logical NNI' and do. The same protocol architecture applies, I think, also to the case where the node is a router; while signaling requests terminate on the routers, the router now needs to know which of its ports are connected to public UNI, and perform the address resolution, first from the IP address of the next hop router, or end node, to the next hop router's or end node's NSAP address, then from the NSAP address to the E.164 address. As noted above, and as you suggest, perhaps a single ARP resolution could be used to find out both those latter addresses, unless they are algorithmically related (which does seem the simplest solution to me - why would it ever be otherwise???). Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18739; 14 Sep 93 18:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab18735; 14 Sep 93 18:15 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20715; 14 Sep 93 18:15 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04195; Tue, 14 Sep 93 14:58:42 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21990; Tue, 14 Sep 93 14:58:38 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19775; Tue, 14 Sep 93 14:56:28 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19769; Tue, 14 Sep 93 14:56:27 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA23522; Tue, 14 Sep 93 14:56:26 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA15064; Tue, 14 Sep 93 14:56:07 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA14122; Tue, 14 Sep 93 15:06:44 PDT Date: Tue, 14 Sep 93 15:06:44 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142206.AA14122@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: Please take me off this aliases Cc: duval%buoux.inria.@sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From duval@buoux.inria.fr Tue Sep 14 00:34:20 1993 Date: Tue, 14 Sep 1993 09:25:32 +0200 From: Patrick Duval To: atm-request@atm.Eng.Sun.COM Cc: aliases@Sun.COM Subject: Please take me off this aliases Content-Length: 61 Please take me off atm@sun.com Thanks Patrick.Duval@inria.fr ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18749; 14 Sep 93 18:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18745; 14 Sep 93 18:15 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20740; 14 Sep 93 18:15 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04398; Tue, 14 Sep 93 14:59:52 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA22119; Tue, 14 Sep 93 14:59:28 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19796; Tue, 14 Sep 93 14:56:53 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19790; Tue, 14 Sep 93 14:56:52 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA23601; Tue, 14 Sep 93 14:56:59 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA15090; Tue, 14 Sep 93 14:56:36 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA14133; Tue, 14 Sep 93 15:07:13 PDT Date: Tue, 14 Sep 93 15:07:13 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142207.AA14133@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: please remove me Cc: jackson@icrl.mew.mei.co.jp X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From jackson@icrl.mew.mei.co.jp Tue Sep 14 01:14:38 1993 Date: Tue, 14 Sep 93 16:44:51 +0900 From: jackson@icrl.mew.mei.co.jp (Spencer Jackson) To: aliases@Sun.COM Subject: please remove me Content-Length: 136 Please remove me from this mailing list. I don't think I need a blow-by-blow of ATM software development. thank you, Spencer Jackson ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18767; 14 Sep 93 18:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18763; 14 Sep 93 18:17 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa20980; 14 Sep 93 18:17 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04414; Tue, 14 Sep 93 14:59:56 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA22186; Tue, 14 Sep 93 14:59:50 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19812; Tue, 14 Sep 93 14:57:10 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA19806; Tue, 14 Sep 93 14:57:09 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA23640; Tue, 14 Sep 93 14:57:16 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA15120; Tue, 14 Sep 93 14:57:06 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA14136; Tue, 14 Sep 93 15:07:45 PDT Date: Tue, 14 Sep 93 15:07:45 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142207.AA14136@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: atm@Sun.COM Cc: jackson@icrl.mew.mei.co.jp X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Lucy.Farmer@UK Tue Sep 14 01:36:38 1993 Date: Tue, 14 Sep 93 09:25:51 BST From: Lucy.Farmer@UK (Lucy Farmer - Sun CSIR) To: aliases@Sun.COM Subject: atm@Sun.COM Content-Length: 57 Please remove from my alias: atm@Sun.COM Thanks, Lucy ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19329; 14 Sep 93 19:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19325; 14 Sep 93 19:07 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa26894; 14 Sep 93 19:07 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA14812; Tue, 14 Sep 93 16:03:51 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29482; Tue, 14 Sep 93 16:03:53 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20336; Tue, 14 Sep 93 16:02:39 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20330; Tue, 14 Sep 93 16:02:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29210; Tue, 14 Sep 93 16:02:44 PDT Received: from motgate.mot.com by Sun.COM (4.1/SMI-4.1) id AA14653; Tue, 14 Sep 93 16:02:35 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA20538; Tue, 14 Sep 1993 18:02:33 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15) id AA05779; Tue, 14 Sep 1993 18:02:27 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA08989 (5.65a+/IDA-1.4.2 for anthony@msgate.hls.com); Tue, 14 Sep 93 19:02:24 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03760 (5.65a+/IDA-1.4.2 for atm@sun.com); Tue, 14 Sep 93 19:02:23 -0400 Message-Id: <9309142302.AA03760@dbg.dev.cdx.mot.com> To: "Alles, Anthony" Cc: atm@sun.com Subject: Re: E.164 Formats and Classical ARP over ATM In-Reply-To: Your message of "Tue, 14 Sep 93 12:25:00 PDT." <2C961DCD@msgate.hls.com> Date: Tue, 14 Sep 93 19:02:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp X-Orig-Sender: atm-request@atm.eng.sun.com > My (long) 2c worth on this: I'm not sure whether we agree or disagree, but here goes: > the crux of the > argument came down to whether or not public networks (i.e. likely users of > the non-NSAP E.164 address formats) wished to participate in the _private_ > NNI protocols that would operate over private ATM networks, and would use > the NSAP encoded _private_ ATM addresses. Far more complex situation than that. The issues were the relationship between the incumbent Public Networks and their incumbent suppliers; ability of the incubent suppliers to leverage existing base of signalling and call control software; entrenched operations and provisioning systems in the Public Networks; perception of more reactionary elements in some Public Networks that ties to the existing numbering plan (which is administered in North America by the local exchange carriers), might serve to suppress the "evil" forces of competition (these are the same guys who have secret ceremonies in the bottom of manholes involving Judge Greene voodoo dolls and pointed instruments :-)); FUD. I'm not sure that the issues surrounding P-NNI had even surfaced in most parts of that community at that time. > In order to get connectivity to private ATM nodes, strict protocol layering > requires... I don't agree that strict layering is called for. Even in the sadly maligned OSI network layer, the notion of subnetworks is not a matter of strict layering, but of cooperating roles. I'd suggest that the right model of a non-participating subnetwork is more like an opaque cloud. In some cases, somebody will probably try to connect a solitary router or host to one of these things, and I suppose that it is incumbent on us to make it work. > In turn, this suggests that an _additional ATM_ address resolution is > required at the > public/private interface, to map the private ATM addressing into the public > E.164 > addresses. Typically, as I once went through during the addressing > discussions > at the Forum, this would require that the private ATM addresses, of whatever > format, > be mapped into the subaddress fields of the signaling request, and that > through some > resolution mechanism, the address fields be filled with the E.164 addresses > of the > end nodes on the public network. It should be noted that this assumes that > this > resolution occur _within_ the _ATM network_, not in some external entity > like a > router, since this would preclude end to end signaling flows (i.e. they > would be > stopped by the router). Here, we're in almost full agreement, except for the fact that there may be cases where there is no ATM boundary node. Now, I know where you're coming from, and I personally agree, that this is unlikely in the real world. On the other hand, our telco bretheren (to say nothing of the cable guys and others) have a need to accomodate this case, and it would be wrong to rain on their parade. > Its not clear to me, however, whether the IP over ATM draft should necessarily > mandate the need for a > router in this configuration). Heck, no. > In any case,this subnetwork concept was adopted as part of the reference > configuration for the private NNI protocol I think you're overstating here... we agreed to a notion of 'subnetwork' but didn't get down to the architectural nitty gritty of what that meant (did it imply strict layering, for example). > This also requires that a public node needs to support _both_ address types, > so that is responding to an ARP request, for instance, it would respond with > its NSAP encoded address, which would, in > turn, need to be resolved to its E.164 address. Whoa!!! who said anything about public networks responding to ARP requests? It would not be precluded, of course, but the intent was that these switches would talk Public UNI-flavored Q.93b, using the type=international, plan=E.164 format and nothing else, and especially not ARP. > By extension, one would presumably need to define separate ARP like mechanisms > (much as operate over Frame relay today), to allow end nodes to determine > mappings from NSAP encoded addresses to E.164 addresses, and vice versa. > Logically, these mechanisms would be quite distinct from the IP over > (private) ATM ARP mechanisms. I'm not sure what you're suggesting here... > Of course, defining all these additional mechanisms is a real pain. Nothing in life comes easy. Consider it job security :-) > or maybe work on some simple algorithmic ways of transforming between the > address formats That has been suggested before and only works in very simple topologies, in relatively static networks, and with the understanding that administrative pain will periodically be applied. Sorry, it has to be a non-algorithmic binding, which implies that over the long run some kind of distribution protocol will be needed. > We also need some protocol layering model for how public nodes Have you discussed it with those folks? I have an impression that you might not get what you're looking for without a fight. > Would this group work on those mechanisms too? I would > suggest, in any case, > that the scope of the draft Classical ARP over ATM RFC be amended to > incorporate some > discussion of the ATM subnetwork case, since it will clearly be an important > case to support I'm beginning to understand the problem: you're confusing IP over ATM issues with 'private' ATM over 'public' ATM issues. The former are clearly to be resolved here, the latter are the ATM Forum's row to hoe (and I'd rather finesse them into non-problems then define them as problems and then solve them). Rgds, Dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19405; 14 Sep 93 19:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19401; 14 Sep 93 19:13 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27557; 14 Sep 93 19:13 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15256; Tue, 14 Sep 93 16:06:37 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29792; Tue, 14 Sep 93 16:06:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20346; Tue, 14 Sep 93 16:04:20 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20340; Tue, 14 Sep 93 16:04:19 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29420; Tue, 14 Sep 93 16:04:27 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA20533; Tue, 14 Sep 93 16:04:18 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15085; Tue, 14 Sep 93 16:14:57 PDT Date: Tue, 14 Sep 93 16:14:57 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142314.AA15085@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: unsubscribe Cc: Jay.Raman@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Jay.Raman@EBay Mon Sep 13 13:48:30 1993 Date: Mon, 13 Sep 93 13:37:57 PDT From: Jay.Raman@EBay (Jay Raman) To: aliases@Sun.COM Subject: unsubscribe Content-Length: 53 Please delete my name from atm@Sun alias Thanks Jay ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19417; 14 Sep 93 19:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19413; 14 Sep 93 19:14 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27673; 14 Sep 93 19:14 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15448; Tue, 14 Sep 93 16:07:43 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29952; Tue, 14 Sep 93 16:07:29 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20355; Tue, 14 Sep 93 16:04:48 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20349; Tue, 14 Sep 93 16:04:47 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29440; Tue, 14 Sep 93 16:04:55 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA20566; Tue, 14 Sep 93 16:04:45 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15098; Tue, 14 Sep 93 16:15:24 PDT Date: Tue, 14 Sep 93 16:15:24 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142315.AA15098@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: atm@sun.com Cc: Duane.Day@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Duane.Day@EBay Mon Sep 13 13:57:53 1993 Date: Mon, 13 Sep 93 13:39:29 PDT From: Duane.Day@EBay (Duane Day) To: aliases@Sun.COM Subject: atm@sun.com Content-Length: 341 I don't know whether or not it's an alias that you folks maintain, but somehow I seem to have recently been added to the atm@sun alias. I haven't gotten any response from the messages I've sent to atm-request@atm.Eng; can you remove me from atm@sun or failing that, perhaps give me the name of the alias administrator? thanks much, Duane ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19437; 14 Sep 93 19:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19433; 14 Sep 93 19:17 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa28134; 14 Sep 93 19:17 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15893; Tue, 14 Sep 93 16:10:05 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00338; Tue, 14 Sep 93 16:09:54 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20370; Tue, 14 Sep 93 16:05:18 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20364; Tue, 14 Sep 93 16:05:17 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29477; Tue, 14 Sep 93 16:05:25 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA20603; Tue, 14 Sep 93 16:05:16 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15101; Tue, 14 Sep 93 16:15:55 PDT Date: Tue, 14 Sep 93 16:15:55 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142315.AA15101@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: Please remove me from this alias Cc: Martin.Franklin@corp.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Martin.Franklin@Corp Mon Sep 13 14:01:40 1993 Date: Mon, 13 Sep 93 13:49:32 PDT From: Martin.Franklin@Corp (Martin Franklin) To: aliases@Sun.COM Subject: Please remove me from this alias X-Sun-Charset: US-ASCII Content-Length: 225 Some one put me on this alias Please remove me. atm@Sun.COM Martin Franklin Mail: martin.franklin@Sun.COM IR Strategic Systems Information Highway Sun Microsystems Disclaimer: #include ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19606; 14 Sep 93 19:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19602; 14 Sep 93 19:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02696; 14 Sep 93 19:53 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa19596; 14 Sep 93 19:53 EDT Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16555; Tue, 14 Sep 93 16:15:00 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00377; Tue, 14 Sep 93 16:14:31 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20392; Tue, 14 Sep 93 16:07:02 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20386; Tue, 14 Sep 93 16:07:00 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29608; Tue, 14 Sep 93 16:07:08 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA20743; Tue, 14 Sep 93 16:06:59 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15142; Tue, 14 Sep 93 16:17:38 PDT Date: Tue, 14 Sep 93 16:17:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142317.AA15142@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: Please remove Cc: Dave.Maclean@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Dave.Maclean@EBay Mon Sep 13 14:36:19 1993 Date: Mon, 13 Sep 93 14:25:33 PDT From: Dave.Maclean@EBay (Dave MacLean) To: aliases@Sun.COM Subject: Please remove Content-Length: 84 I don't know how I got on the atm@sun.com alias, but I want off now please. - dave ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19616; 14 Sep 93 19:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19612; 14 Sep 93 19:53 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa02691; 14 Sep 93 19:53 EDT Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16601; Tue, 14 Sep 93 16:15:08 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00427; Tue, 14 Sep 93 16:14:55 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20402; Tue, 14 Sep 93 16:07:18 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20396; Tue, 14 Sep 93 16:07:17 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29630; Tue, 14 Sep 93 16:07:25 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA20779; Tue, 14 Sep 93 16:07:17 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15146; Tue, 14 Sep 93 16:17:56 PDT Date: Tue, 14 Sep 93 16:17:56 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142317.AA15146@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: Please remove from alias!!! Cc: Mike.Kubicar@eng.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Mike.Kubicar@Eng Mon Sep 13 14:36:52 1993 Date: Mon, 13 Sep 93 14:29:01 PDT From: Mike.Kubicar@Eng (Mike Kubicar) To: aliases@Sun.COM Subject: Please remove from alias!!! X-Sun-Charset: US-ASCII Content-Length: 175 I don't know how I managed to get on this alias, but I am getting tons of mail address to "atm@sun.com". Please remove me from this alias. Thanks, Mike Kubicar ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19922; 14 Sep 93 20:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19918; 14 Sep 93 20:21 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06003; 14 Sep 93 20:21 EDT Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17114; Tue, 14 Sep 93 16:18:14 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00762; Tue, 14 Sep 93 16:18:12 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20461; Tue, 14 Sep 93 16:10:23 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20455; Tue, 14 Sep 93 16:10:22 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1) id AA29849; Tue, 14 Sep 93 16:10:29 PDT Received: from tehilliah.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA21007; Tue, 14 Sep 93 16:10:17 PDT Received: by tehilliah.Corp.Sun.COM (4.1/SMI-4.1) id AA15182; Tue, 14 Sep 93 16:20:56 PDT Date: Tue, 14 Sep 93 16:20:56 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: User for request email from snail Message-Id: <9309142320.AA15182@tehilliah.Corp.Sun.COM> To: atm@atm.eng.sun.com Subject: Please take me off -atm alias Cc: Vincent.Yau@ebay.sun.com X-Orig-Sender: atm-request@atm.eng.sun.com ----- Begin Included Message ----- From Vincent.Yau@EBay Mon Sep 13 14:54:05 1993 Date: Mon, 13 Sep 93 14:46:46 PDT From: Vincent.Yau@EBay (Vincent Yau) To: aliases@Sun.COM Subject: Please take me off X-Sun-Charset: US-ASCII Content-Length: 83 Please take me off the following aliases: 1) cplusplus 2) atm Thanks --Vincent ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19980; 14 Sep 93 20:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19974; 14 Sep 93 20:26 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06429; 14 Sep 93 20:26 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA20173; Tue, 14 Sep 93 16:42:27 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03724; Tue, 14 Sep 93 16:42:18 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20780; Tue, 14 Sep 93 16:40:09 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20773; Tue, 14 Sep 93 16:40:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02126; Tue, 14 Sep 93 16:40:14 PDT Received: from lanslide.hls.com by Sun.COM (4.1/SMI-4.1) id AA19613; Tue, 14 Sep 93 16:38:52 PDT Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA11846; Tue, 14 Sep 93 16:38:26 PDT Received: by msgate.hls.com with Microsoft Mail id <2C965903@msgate.hls.com>; Tue, 14 Sep 93 16:51:31 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: dan Cc: atm Subject: Re: E.164 Formats and Classical ARP over ATM Date: Tue, 14 Sep 93 16:39:00 PDT Message-Id: <2C965903@msgate.hls.com> Encoding: 236 TEXT X-Mailer: Microsoft Mail V3.0 X-Orig-Sender: atm-request@atm.eng.sun.com Dan, >From: dan >To: Alles, Anthony >Cc: atm >Subject: Re: E.164 Formats and Classical ARP over ATM >Date: Tuesday, 14 September 1993 7:02PM >I'm not sure whether we agree or disagree...: I don't know either! :-) >> the crux of the >> argument came down to whether or not public networks (i.e. likely users of >> the non-NSAP E.164 address formats) wished to participate in the _private_ >> NNI protocols that would operate over private ATM networks, and would use >> the NSAP encoded _private_ ATM addresses. >Far more complex situation than that. The issues were the relationship >between >the incumbent Public Networks and their incumbent suppliers; ability of the >incubent suppliers to leverage existing base of signalling and call control >software; entrenched operations and provisioning systems in the Public >Networks; >perception of more reactionary elements in some Public Networks that ties to >the >existing numbering plan (which is administered in North America by the local >exchange carriers), might serve to suppress the "evil" forces of competition >(these are the same guys who have secret ceremonies in the bottom of manholes >involving Judge Greene voodoo dolls and pointed instruments :-)); FUD. I'm >not >sure that the issues surrounding P-NNI had even surfaced in most parts of >that >community at that time. Well, here I agree entirely with you, though I'm glad you said all this and not me (I'm trying to learn to be diplomatic! :-)) ! The chances that the people involved in these discussions understood anything at all about the P-NNI, I agree, is pretty small, but nonetheless, I think that what the addressing issue resolves down to is the interaction between public and private switches and the P-NNI protocol, and, in turn, to what that says about protocols that operate over private networks, such as IP ARP. >> In order to get connectivity to private ATM nodes, strict protocol layering >> requires... >I don't agree that strict layering is called for. Even in the sadly maligned >OSI network layer, the notion of subnetworks is not a matter of strict >layering, >but of cooperating roles. I'd suggest that the right model of a >non-participating subnetwork is more like an opaque cloud. In some cases, >somebody will probably try to connect a solitary router or host to one of >these >things, and I suppose that it is incumbent on us to make it work. Actually, I tend to be a bit of a puritan when it comes to protocol layering - indeed I've always thought ISO 8648 was one of the very few useful (and readable!) things to come out of ISO. Nonetheless, as I mentioned in my reply to Subbu, I agree that efficiencies can be gained by not adhering to strict layering, with respect to the ARP mechanism (though I wonder whether we are getting to IP centric here - what if there were other types of service that also needed to do the NSAP to E.164 address resolution - would they also have/be able to use the IP ARP mechanism, or is there really a need for a separate mechanism?). >> In turn, this suggests that an _additional ATM_ address resolution is >> required at the >> public/private interface, to map the private ATM addressing into the public >> E.164 >> addresses. Typically, as I once went through during the addressing >> discussions >> at the Forum, this would require that the private ATM addresses, of >whatever >> format, >> be mapped into the subaddress fields of the signaling request, and that >> through some >> resolution mechanism, the address fields be filled with the E.164 addresses >> of the >> end nodes on the public network. It should be noted that this assumes that >> this >> resolution occur _within_ the _ATM network_, not in some external entity >> like a >> router, since this would preclude end to end signaling flows (i.e. they >> would be >> stopped by the router). > >Here, we're in almost full agreement, except for the fact that there may be >cases where there is no ATM boundary node. Now, I know where you're coming >from, and I personally agree, that this is unlikely in the real world. On >the >other hand, our telco bretheren (to say nothing of the cable guys and others) >have a need to accomodate this case, and it would be wrong to rain on their >parade. I'm not sure what you mean by this - surely there has to be some node at the public network ingress point which needs to know that it is talking to a subnetwork? Can you expand on scenarios (surely pathalogical??) in which this might not be the case? >> In any case,this subnetwork concept was adopted as part of the reference >> configuration for the private NNI protocol > >I think you're overstating here... we agreed to a notion of 'subnetwork' but >didn't get down to the architectural nitty gritty of what that meant (did it >imply strict layering, for example). Well, I thought it was clear! :-) >> This also requires that a public node needs to support _both_ address >types, >> so that is responding to an ARP request, for instance, it would respond >with >> its NSAP encoded address, which would, in >> turn, need to be resolved to its E.164 address. >Whoa!!! who said anything about public networks responding to ARP requests? I think you misunderstood me here - clearly public network _switches_ would only ever need to know about E.164 addresses - that's why they would be a subnetwork after all. On the other hand, an ATM end-system node directly attached to a public network would, I contend, need to know about both address types, and would respond to an ARP (who else would anyway?), if, in fact, it wished to have communication with ATM end systems attached to private ATM networks. Of course, if it didn't want to do that, then it would not need to support both (e.g. will your ATM telephone want to talk to your ATM workstation???). >> By extension, one would presumably need to define separate ARP like >mechanisms >> (much as operate over Frame relay today), to allow end nodes to determine >> mappings from NSAP encoded addresses to E.164 addresses, and vice versa. >> Logically, these mechanisms would be quite distinct from the IP over >> (private) ATM ARP mechanisms. >I'm not sure what you're suggesting here... How does an ATM node (border switching system or router) know what entities it is connected to through the subnetwork (e.g. public network), particularly if the connections were PVCs? This would require an inverse ARP mechanism, would it not? >> or maybe work on some simple algorithmic ways of transforming between the >> address formats >That has been suggested before and only works in very simple topologies, in >relatively static networks, and with the understanding that administrative >pain >will periodically be applied. Sorry, it has to be a non-algorithmic binding, >which implies that over the long run some kind of distribution protocol will >be >needed. How about the short term? Can you expand on why this is a bad thing? >> We also need some protocol layering model for how public nodes >Have you discussed it with those folks? I have an impression that you might >not >get what you're looking for without a fight. As noted above, I am not talking about the public network switches, but about the end systems. >> Would this group work on those mechanisms too? I would >> suggest, in any case, >> that the scope of the draft Classical ARP over ATM RFC be amended to >> incorporate some >> discussion of the ATM subnetwork case, since it will clearly be an >important >> case to support > >I'm beginning to understand the problem: you're confusing IP over ATM issues >with 'private' ATM over 'public' ATM issues. The former are clearly to be >resolved here, the latter are the ATM Forum's row to hoe (and I'd rather >finesse >them into non-problems then define them as problems and then solve them). Its not so much, I think, that the issues are confused, but that whatever protocols, such as ARP, are defined, need to operate across networks that may include public network subnetworks. The issue then is whether this hierarchy is visible or not to the service, and what it does about it. Certainly, if we decide to draw a definite line between the IP to NSAP resolution, and the NSAP to E.164 resolution, then it might be more suitable to define the latter at the Forum. > >Rgds, >Dan Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19988; 14 Sep 93 20:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19979; 14 Sep 93 20:26 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06442; 14 Sep 93 20:26 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa19968; 14 Sep 93 20:26 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18178; Tue, 14 Sep 93 16:28:44 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02121; Tue, 14 Sep 93 16:27:36 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20641; Tue, 14 Sep 93 16:25:49 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20635; Tue, 14 Sep 93 16:25:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01106; Tue, 14 Sep 93 16:25:55 PDT Received: from uu2.psi.com by Sun.COM (4.1/SMI-4.1) id AA17714; Tue, 14 Sep 93 16:23:38 PDT Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17224 for atm@sun.com; Tue, 14 Sep 93 19:23:18 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15757; Tue, 14 Sep 93 16:20:59 PDT Message-Id: <9309142320.AA15757@aland.bbn.com> To: atm@sun.com Subject: How many SUN Employees are There? Reply-To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Tue, 14 Sep 93 16:20:58 -0700 X-Orig-Sender: atm-request@atm.eng.sun.com Hi folks: It seems someone at Sun crossed the IETF's ATM list with some other large list, much to the distress of the Sun folks who are now all sending notes asking to be taken off the ATM list. If this keeps up, we'll soon have a wonderful set of messages to analyze the internal technical structure of Sun! :-) Based on who's asked to be removed, anyone want to hazard a guess as to what kind of list was merged into the IETF list? :-) Craig PS: All completely tongue in cheek here.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19999; 14 Sep 93 20:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19995; 14 Sep 93 20:26 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06451; 14 Sep 93 20:26 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17502; Tue, 14 Sep 93 16:22:09 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01501; Tue, 14 Sep 93 16:21:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20618; Tue, 14 Sep 93 16:20:08 PDT Received: from hsiwen.Eng.Sun.COM by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20612; Tue, 14 Sep 93 16:20:07 PDT Received: by hsiwen.Eng.Sun.COM (5.0/SMI-SVR4) id AA03053; Tue, 14 Sep 93 16:25:52 PDT Date: Tue, 14 Sep 93 16:25:52 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Yang Message-Id: <9309142325.AA03053@hsiwen.Eng.Sun.COM> To: atm@atm.eng.sun.com Subject: same problem X-Sun-Charset: US-ASCII Content-Length: 629 X-Orig-Sender: atm-request@atm.eng.sun.com Please remove me from this alias. Paul ----- Begin Included Message ----- From Duane.Day@EBay Mon Sep 13 13:57:53 1993 Date: Mon, 13 Sep 93 13:39:29 PDT From: Duane.Day@EBay (Duane Day) To: aliases@Sun.COM Subject: atm@sun.com Content-Length: 341 I don't know whether or not it's an alias that you folks maintain, but somehow I seem to have recently been added to the atm@sun alias. I haven't gotten any response from the messages I've sent to atm-request@atm.Eng; can you remove me from atm@sun or failing that, perhaps give me the name of the alias administrator? thanks much, Duane ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20012; 14 Sep 93 20:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20008; 14 Sep 93 20:26 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa06492; 14 Sep 93 20:26 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26208; Tue, 14 Sep 93 17:22:55 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08178; Tue, 14 Sep 93 17:22:58 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21392; Tue, 14 Sep 93 17:21:45 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21386; Tue, 14 Sep 93 17:21:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05626; Tue, 14 Sep 93 17:21:53 PDT Received: from radiomail.net by Sun.COM (4.1/SMI-4.1) id AA26090; Tue, 14 Sep 93 17:21:45 PDT Received: from ulf (ulf.radiomail.net) by radiomail.net with SMTP id AA21168 (5.65c+/IDA-1.4.4 for ); Tue, 14 Sep 1993 17:20:17 -0700 Message-Id: <199309150020.AA21168@radiomail.net> Date: Tue, 14 Sep 1993 17:19:13 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach (via RadioMail) Cc: atm@sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: How many SUN Employees are There? To: Craig Partridge X-Orig-Sender: atm-request@atm.eng.sun.com > If this keeps up, we'll soon have a wonderful set of messages to >analyze the internal technical structure of Sun! :-) Based on who's >asked to be removed, anyone want to hazard a guess as to what kind of list >was merged into the IETF list? :-) Well, it's probably time I moved the list to HP - we need to tell the world how many employees we have there... Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20498; 14 Sep 93 21:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20494; 14 Sep 93 21:06 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10955; 14 Sep 93 21:06 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00201; Tue, 14 Sep 93 18:02:21 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11471; Tue, 14 Sep 93 18:02:25 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21700; Tue, 14 Sep 93 18:01:24 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA21694; Tue, 14 Sep 93 18:01:24 PDT Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07917; Tue, 14 Sep 93 18:01:33 PDT Received: from Eng.Sun.COM (zigzag-bb) by snail.Sun.COM (4.1/SMI-4.1) id AB00334; Tue, 14 Sep 93 18:01:24 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11406; Tue, 14 Sep 93 18:01:29 PDT Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4) id AA15409; Tue, 14 Sep 1993 18:01:20 +0800 Date: Tue, 14 Sep 1993 18:01:20 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Hinden Message-Id: <9309150101.AA15409@bigriver.Eng.Sun.COM> To: Mark Laubach (via RadioMail) Cc: Craig Partridge , atm@sun.com In-Reply-To: <199309150020.AA21168@radiomail.net> Subject: Re: How many SUN Employees are There? Content-Length: 240 X-Orig-Sender: atm-request@atm.eng.sun.com I think the problem has been fixed. I think what was showing up today was leftover requests to me removed from yesterday. I would agree that it is time to move this list to HP. I think Sun has had our share of "fun" managing it :-) Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24433; 14 Sep 93 23:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24429; 14 Sep 93 23:36 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27500; 14 Sep 93 23:36 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09522; Tue, 14 Sep 93 20:31:53 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16626; Tue, 14 Sep 93 20:31:58 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22192; Tue, 14 Sep 93 20:30:57 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22186; Tue, 14 Sep 93 20:30:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12180; Tue, 14 Sep 93 20:31:07 PDT Received: from by Sun.COM (4.1/SMI-4.1) id AB09451; Tue, 14 Sep 93 20:30:56 PDT Received: from uuisis by mail.uunet.ca with UUCP id <101306(2)>; Tue, 14 Sep 1993 23:30:36 -0400 Subject: Removal of chris@uuisis.isis.org from ALL aliases To: atm@sun.com, atm-request@atm.eng.sun.com, laubach@radiomail.net, craig@aland.bbn.com, aliases@sun.com Date: Tue, 14 Sep 1993 23:17:27 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: root Cc: itdavid@ucdavis.edu X-Mailer: ELM [version 2.3 PL6] Message-Id: <9309142317.aa20956@uuisis.isis.org> Source-Info: From (or Sender) name not authenticated. X-Orig-Sender: atm-request@atm.eng.sun.com Please check all your alias files/lists and remove from them all entries for chris@uuisis.isis.org. This user has been gone a long long time. Unfortunately it would appear that the bounced mail messages have been finding their way back to itdavid@ucdavis.edu. I have succeeded in creating a bogus Chris account in order to capture some of the traffic being bounced - in less than an hour I have captured 11 messages.... there are a lot of bounced messages flying all over the place. Personally I believe it would be best if these lists were regenerated from scratch - based on what I saw in the traffic captured - they are very badly scrambled. Rick Beetham SA UUISIS   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25851; 14 Sep 93 23:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25847; 14 Sep 93 23:44 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa28381; 14 Sep 93 23:44 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10097; Tue, 14 Sep 93 20:40:47 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16978; Tue, 14 Sep 93 20:40:50 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22277; Tue, 14 Sep 93 20:39:29 PDT Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA22271; Tue, 14 Sep 93 20:39:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12437; Tue, 14 Sep 93 20:39:39 PDT Received: from hubbub.cisco.com by Sun.COM (4.1/SMI-4.1) id AA17720; Tue, 14 Sep 93 16:23:30 PDT Received: from lager.cisco.com by hubbub.cisco.com with SMTP id AA27466 (5.67a/IDA-1.5 for atm@sun.com); Tue, 14 Sep 1993 16:23:22 -0700 Message-Id: <199309142323.AA27466@hubbub.cisco.com> To: rgc@qsun.att.com Cc: atm@sun.com Subject: Re: e.164 In-Reply-To: Your message of "Tue, 14 Sep 93 15:41:00 EDT." <9309141950.AA11502@Sun.COM> Date: Tue, 14 Sep 93 16:23:21 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Forster X-Orig-Sender: atm-request@atm.eng.sun.com Well, in 24 hours I've flip-flopped. I now think it would be easier to to have two different HW address types in the ARP packet, one for native E.164 and one for ATMF NSAP-like addresses. Clearly the host/router has to use the correct format when it wants to make a call, and it seems easiest to just admit that and face it directly, instead of trying to hide it (like I thought yesterday). While apparently ugly, it's simple and mindless, and therefore we stand a chance of doing it right. I agree with the comment that we should seek to get the SMDS HW type (14) description changed to E.164, and a new HW type for ATMF NSAP-like addresses. -- Jim PS: Is there (I sure hope not) a situation in which the address that a host/router A thinks of as its own address, is in fact unusable by someone else? In other words: A knows its address, and opens a VC to B (the arp server). A passes its address, in a ARP packet, to B. B stores it. Later C asks for A's address. Can C always use it to open a VC to A (ignore access list type issues)? If the answer is not yes, then we need to limit the scope of this classical draft to cases where this (transitivity of addresses?) is true. > We were not saying that public networks will ONLY support E.164 > addresses. In fact the ATM forum spec allows for three cases: > > 1 ) only E.164, > > 2 ) only private ATM address structure (all three NSAP modeled formats), > > 3) both > > Therefore, any scheme we devise should allow for all the above. This > means, we believe, that there needs to be a robust method for the router > to construct the appropriate connect request packet with all the > addresses properly intrepreted.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07468; 15 Sep 93 12:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07464; 15 Sep 93 12:30 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa04280; 15 Sep 93 12:30 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04344; Wed, 15 Sep 93 09:22:29 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29961; Wed, 15 Sep 93 09:22:27 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23312; Wed, 15 Sep 93 09:20:36 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23306; Wed, 15 Sep 93 09:20:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29872; Wed, 15 Sep 93 09:19:08 PDT Received: from dxmint.cern.ch by Sun.COM (4.1/SMI-4.1) id AA26554; Wed, 15 Sep 93 01:06:19 PDT Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17495; Wed, 15 Sep 1993 10:06:17 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA14057; Wed, 15 Sep 1993 10:06:06 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309150806.AA14057@dxcern.cern.ch> Subject: Re: E.164 Formats and Classical ARP over ATM To: atm@sun.com Date: Wed, 15 Sep 1993 10:06:05 +0200 (MET DST) In-Reply-To: <2C965903@msgate.hls.com> from "Alles, Anthony" at Sep 14, 93 04:39:00 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 439 X-Orig-Sender: atm-request@atm.eng.sun.com Now has everybody understood the incredible mess caused by the ATM Forum's attempt to change the ATM address format from one designed for B-ISDN (a Level 2 network) to one designed for Level 3? All this confusion was entirely predictable from the day the ATM Forum made its choice. Good luck to the manufacturers in squaring this circle. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10137; 15 Sep 93 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10132; 15 Sep 93 14:38 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa17700; 15 Sep 93 14:38 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AB25989; Wed, 15 Sep 93 11:25:32 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AB13646; Wed, 15 Sep 93 11:25:29 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23621; Wed, 15 Sep 93 11:23:07 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23615; Wed, 15 Sep 93 11:23:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06151; Wed, 15 Sep 93 11:21:39 PDT Received: from chenas.inria.fr by Sun.COM (4.1/SMI-4.1) id AA25268; Wed, 15 Sep 93 00:37:42 PDT Received: from polytechnique.polytechnique.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA13851; Wed, 15 Sep 1993 09:37:35 +0200 (MET) Received: by polytechnique.polytechnique.fr (5.65c/SMI-4.1.3) id AA10750; Wed, 15 Sep 1993 09:45:08 +0200 Received: by cezanne.polytechnique.fr (4.1/5.65c-IDA-polytechnique) id AA23851; Wed, 15 Sep 93 09:35:47 +0100 Date: Wed, 15 Sep 93 09:35:47 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: fmartin@cezanne.polytechnique.fr Message-Id: <9309150835.AA23851@cezanne.polytechnique.fr> To: atm@sun.com Subject: alias removal Reply-To: fmartin@poly.polytechnique.fr X-Orig-Sender: atm-request@atm.eng.sun.com Please remove my alias from the Email list. Thank you. Franck Martin -- ----------------------------------------------------------- Franck MARTIN // ///// // // Tel: (33) 1-69-33-45-86 // // // Fax: (33) 1-69-33-30-14 //// ///// // // Laboratoire d'Informatique de l'Ecole Polytechnique 91128 Palaiseau Cedex. France Email: fmartin@poly.polytechnique.fr -------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11955; 15 Sep 93 16:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11948; 15 Sep 93 16:08 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa27493; 15 Sep 93 16:07 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10997; Wed, 15 Sep 93 12:56:19 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23424; Wed, 15 Sep 93 12:56:19 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23846; Wed, 15 Sep 93 12:55:02 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA23840; Wed, 15 Sep 93 12:55:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10636; Wed, 15 Sep 93 12:53:30 PDT Received: from shiva.trl.OZ.AU by Sun.COM (4.1/SMI-4.1) id AA24315; Wed, 15 Sep 93 00:16:54 PDT Received: from otcgpo.isg.otc.com.au ([134.159.16.100]) by shiva.trl.OZ.AU with SMTP id AA03818 (5.65c/IDA-1.4.4 for ); Wed, 15 Sep 1993 17:16:51 +1000 Received: from turin.research.otc.com.au (mailhost.research.otc.com.au) by otcgpo.isg.otc.com.au (4.1/OTC_GPO.2.1) id AA26043; Wed, 15 Sep 93 07:14:08 GMT Received: from otc.research.otc.com.au by turin.research.otc.com.au with SMTP id AA00451 (5.65c/IDA-1.4.4 for ); Wed, 15 Sep 1993 17:16:25 +1000 Received: from oddie.research.otc.com.au by otc.research.otc.com.au with SMTP id AA26542 (5.65c/IDA-1.4.4); Wed, 15 Sep 1993 17:16:26 +1000 Message-Id: <199309150716.AA26542@otc.research.otc.com.au> To: atm@sun.com Cc: henryw@research.otc.com.au Subject: ATM UNI V3.0 and B-ICI specifications Date: Wed, 15 Sep 93 17:15:37 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: henryw@research.otc.com.au X-Orig-Sender: atm-request@atm.eng.sun.com Could anyone tell me whether the ATM UNI V3.0 is ready for distribution? And whether there is an ftp site for it? Were there many changes between V3.0 and V2.4[clean]? Also is there a ftp site for the BISDN Inter Carrier Interface (B-ICI) Specifications? And what is the current version for it? The one I have here is Version 1 dated June 21-23, 1993. Henry Wong ACSnet: henryw@research.otc.com.au Technical Development Group UUCP: {uunet,mcvax}!munnari!otc!henryw Telstra Corporation Box 7000 Sydney NSW 2001 Voice: +61 2 287 3177 Australia Fax: +61 2 287 3299   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08704; 16 Sep 93 12:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08699; 16 Sep 93 12:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08153; 16 Sep 93 12:36 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12392; Thu, 16 Sep 93 07:53:44 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12384; Thu, 16 Sep 93 07:53:44 -0700 Message-Id: <9309161453.AA12384@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: test message - please delete Date: Thu, 16 Sep 1993 07:53:43 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach I'm testing the distribution list from hpl.hp.com. Please continue to send to atm@sun.com until we see if this is successful. Please delete this message. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15339; 19 Sep 93 13:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15335; 19 Sep 93 13:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01604; 19 Sep 93 13:14 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25584; Sun, 19 Sep 93 09:01:14 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA25577; Sun, 19 Sep 93 09:01:14 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06782; Sun, 19 Sep 93 09:01:29 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA27290; Sun, 19 Sep 93 09:01:48 -0700 Received: by inet-gw-2.pa.dec.com; id AA20189; Sun, 19 Sep 93 09:00:10 -0700 Received: by us1rmc.bb.dec.com; id AA20198; Sun, 19 Sep 93 11:59:03 -0400 Message-Id: <9309191559.AA20198@us1rmc.bb.dec.com> Received: from manage.enet; by us1rmc.enet; Sun, 19 Sep 93 11:59:04 EDT Date: Sun, 19 Sep 93 11:59:04 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mail Delivery Subsystem <"manage::dsap01::mailer-daemon"@manage.enet.dec.com> To: us1rmc: "atm@hpl.hp.com"@manage.enet.dec.com; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Apparently-To: atm@hplms2.hpl.hp.com, atm@hplms2.hpl.hp.com, atm@hplms2.hpl.hp.com, atm@hplms2.hpl.hp.com Subject: Returned mail: Deferred ----- Transcript of session follows ----- ----- Unsent message follows ----- Received: by dsap01.lkg.dec.com (5.57/cgg-100491); id AA23582; Thu, 16 Sep 93 11:07:17 -0400 Date: Thu, 16 Sep 93 11:07:17 -0400 From: manage::US1RMC::"atm@hpl.hp.com" (MAIL-11 Daemon 16-Sep-1993 1116 -0400) To: atm@matmos.hpl.hp.com Subject: test message - please delete I'm testing the distribution list from hpl.hp.com. Please continue to send to atm@sun.com until we see if this is successful. Please delete this message. Thanks, Mark % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us1rmc.bb.dec.com; id AA00490; Thu, 16 Sep 93 11:12:12 -0400 % Received: by inet-gw-1.pa.dec.com; id AA04947; Thu, 16 Sep 93 08:12:51 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12392; Thu, 16 Sep 93 07:53:44 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12384; Thu, 16 Sep 93 07:53:44 -0700 % Message-Id: <9309161453.AA12384@matmos.hpl.hp.com> % To: atm@matmos.hpl.hp.com % Subject: test message - please delete % Date: Thu, 16 Sep 1993 07:53:43 -0700 % From: Mark Laubach   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16034; 19 Sep 93 15:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16030; 19 Sep 93 15:42 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07140; 19 Sep 93 15:42 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA29194; Sun, 19 Sep 93 11:40:03 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA29185; Sun, 19 Sep 93 11:40:03 -0700 Message-Id: <9309191840.AA29185@matmos.hpl.hp.com> To: cbasso@vnet.ibm.com Cc: atm@matmos.hpl.hp.com Subject: Re: Classical IP and ARP over ATM In-Reply-To: Your message of Fri, 17 Sep 1993 11:59:22 +0700 Date: Sun, 19 Sep 1993 11:40:02 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach From: cbasso@vnet.IBM.COM Subject: Classical IP and ARP over ATM ... Just a couple of remarks on two things that seem to be missing in the draft 1)There is no discussions about the timers to cancel an ATM connection when no traffic during a while (equivalent to RFC 877 for X25) Refer also to the paper "An empirical evaluation of virtual circuits Holding time in IP over ATM network" by H. Saran and S. Keshav The opinions I viewed on this is that timers for IP over X.25 were needed when someone was paying for an X.25 connection. I know there is research being done now on timers for IP over ATM and we don't have experience with public ATM network taraffing. What I'd like to do is make this a discussion item at the Houston meeting. 2) How to select the IP/ARP stack when receiving an incoming call in host/router supporting multiple stack ? Do you plan to use the BHLI (Broadband High Layer I.E.) and ask the ATM forum / CCITT for a code point to identify IP stack. The other opinions I've received on this so far, is that the ATM-FORUM has not "grown up enough" yet for this. I'd like to have this as a discussion item on the Houston agenda also. Regards, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16134; 19 Sep 93 16:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16130; 19 Sep 93 16:06 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07996; 19 Sep 93 16:06 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28471; Sun, 19 Sep 93 11:33:23 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28464; Sun, 19 Sep 93 11:33:22 -0700 Date: Sun, 19 Sep 93 11:33:22 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309191833.AA28464@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: Classical Draft Status ATM-er's: After consulting with a number of people, I've updated the ARP packet format (and its use) to include support for the ATM-FORUM UNI 3.0 address structures. At least so far as supporting E.164 or NSAP address formats for the called/calling address number information element. I've defined support for the called/calling subaddress information element within the ARP packet, but have ducked the use/definition of it for a future document. I've made numerous typo and suggested rewording changes - thanks to everyone who made suggestions. Please review this document asap. I think we're very close to kicking this out. Mark ---------------------------- cut here --------------------------- Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires March 19, 1994 September 19, 1993 Classical IP and ARP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo defines an initial application of classical IP, ARP, and Inverse ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This memo does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM-FORUM and ITU-TS (CCITT) references for more detailed information about ATM implementation standards. Laubach [Page 1] DRAFT Classical IP and ARP over ATM September 1993 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF and the ad hoc PVC committee at the Amsterdam IETF meeting. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Note: this memo is not meant to a reference with regard to the operation of ATM, only to the way it defines the IP layer. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TS and ANSI standards for addressing in ATM. The characteristics and features of ATM networks are different than those found in LAN's: Laubach [Page 2] DRAFT Classical IP and ARP over ATM September 1993 o ATM provides a Virtual Channel (VC) switched environment. VC setup may be done on either a Permanent Virtual Channel (PVC) or dynamic Switched Virtual Channel (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. Note: in commonplace use, the term "virtual circuit" is synonymous with "virtual channel". o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). o The function of mapping user PDU's (Protocol Data Unit) into the information field of the ATM cell and vice versa is performed in the ATM Adaptation Layer (AAL). When a VC is created a specific AAL type is associated with the VC. There are four different AAL types, which are referred to individually as "AAL1", "AAL2", "AAL3/4", and "AAL5". (Note: this memo concerns itself with the mapping of IP and ARP over AAL5 only. The other AAL types are mentioned for introductory purposes only.) There is no field in an ATM cell header which carries the AAL type value, rather it is known by the VC end points via the call setup mechanism. For PVC's the AAL type is administratively configured at the end points when the channel (circuit) is set up. For SVC's, the AAL type is communicated along the VC path via Q.93B as part of call setup establishment and the end points use the signaled information for configuration. ATM switches generally do not care about the AAL type of VC's. The AAL5 format specifies a packet format with a maximum size of 64K - 8 user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating the end of the PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. NOTE: AAL5 provides a non-assured data transfer service - it is up to higher-level protocols to provide retransmission. o ATM-FORUM signalling defines point-to-point and point-to- multipoint channel setup [9]. Multipoint-to-multipoint VC's are not yet a conformance requirement of the ATM-FORUM. o An ATM-FORUM local LAN hardware address (hereafter "ATM address"), in the address resolution protocol context, may be either an individual E.164 address, or an individual ATM-FORUM NSAP, or an E.164 address and an ATM-FORUM NSAP [9]. ATM-FORUM NSAP'S use the same basic format as U.S. GOSIP NSAP's [11]. Note: ATM-FORUM addresses should not be construed as being U.S. GOSIP NSAP's, they are not, the administration is different, which fields get filled out are different, etc. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks Laubach [Page 3] DRAFT Classical IP and ARP over ATM September 1993 (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets. o End-to-end IP routing architecture stays the same. o IP addresses are resolved to ATM addresses by use of an ARP service within the LIS - ARP'S stay within the LIS. ARP architecture stays essentially the same, consistent with current model. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for all these VC's. The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VC's (e.g., TCP and UDP ports map directly onto VC's) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Applications map directly to VC's, requiring changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's are global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per Laubach [Page 4] DRAFT Classical IP and ARP over ATM September 1993 application and per VC basis. The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. o Standards for global IP over ATM will take some time to complete and deploy. This memo details the treatment of the classical model of IP and ARP over ATM. There are those who would like to have IP-over-ATM begin by breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is a station attached to the ATM network that is configured as a member of two or more LIS's. This configuration may result in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets must communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP stations over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: Laubach [Page 5] DRAFT Classical IP and ARP over ATM September 1993 o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [3] and vice versa via InARP[12] when using SVC's. o All members of an LIS must have a mechanism for resolving VC's to IP addresses via InARP [12] when using PVC's. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the virtual channel topology underlying the intercommunication among the members is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pairs of stations. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM address of the individual IP station. Each host must be configured to accept connection requests for this address. o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target ATM addresses for SVC connections. That server must have authoritative responsibility for resolving ARP requests of all IP stations within the LIS. Note: if the LIS is operating with PVC's only, then this parameter may be set to null and the IP station is not required to send ARP requests to the ARP server. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. Laubach [Page 6] DRAFT Classical IP and ARP over ATM September 1993 7. Packet Format Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams. This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the default ATM AAL5 protocol data unit size is 9188 octets. In classical IP subnets, values other than the default can only be used if and only if all stations in the LIS have been configured to use the non- default value. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. ADDRESS RESOLUTION Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12] and all IP stations are required to support these protocols as updated and extended in this memo. Use of these protocols differ depending on whether PVC's or SVC's are used. Permanent Virtual Channels An IP station must have a mechanism for determining what PVC's it has, and in particular which PVC's are being used for LLC/SNAP encapsulated protocols. The details of the mechanism are beyond the scope of this memo. All IP stations supporting PVC's are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those VC's using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant VC from the VC on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When Laubach [Page 7] DRAFT Classical IP and ARP over ATM September 1993 the ATM source and/or target address is unknown, the corresponding ATM address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. Directly from [12]: "When the requesting station receives the InARP reply, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances." It is the responsibility of each IP station supporting PVC's to re-validate ARP table entries as part of the aging process. See the section below on "ARP Table Aging - All Stations". Switched Virtual Channels SVC's require support for ARP in the non-broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for resolving the ARP requests of all IP stations within the LIS. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point VC. The server, upon the completion of an ATM-level call/connection setu-up of a new VC specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. The ARP server mechanism requires that each client be administratively configured with the ATM address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. It is recommended that the ARP server also be an IP station. This station must be administratively configured to operate and recognize itself as the ARP server for a LIS. The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. This memo recognizes that a single ARP Server is not as robust as multiple servers which synchronize their databases correctly. This document is defining the client-server interaction by using a simple, single server approach as a reference model, and does not prohibit more robust approaches which use the same client-server interface. Laubach [Page 8] DRAFT Classical IP and ARP over ATM September 1993 ARP Server Operational Requirements The ARP server accepts ATM-level connections (requests) from other ATM stations. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM address. The server will add (or update) the map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP ATM address does not match the table entry ATM address and there is an open VC associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table or a negative ARP reply (ARP_NAK). The ARP_NAK response is an extension to the ARP protocol and is used to improve the robustness of the ARP server mechanism. With ARP_NAK, a client can determine the difference between a catastrophic server failure and an ARP table lookup failure. The ARP_NAK packet format is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for transmission with the ARP_REQUEST operation code reset to ARP_NAK. Updating the ARP table information timeout, the short form: when the server receives an ARP request over a VC, and the source IP and ATM address match the association already in the ARP table, and the ATM address matches that associated with the VC (in the SVC environment), then the server may update the timeout on the ARP table entry: i.e., if the client is sending ARP requests to the server over the same VC that was used to "install" the ARP entry for the client, the server should examine the ARP requests and note that the client is still "alive" and update the timeout on the clients ARP table entry. ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh its own ARP entry/information about other IP stations. ARP clients must: 1. Initiate the VC connection to the ARP server for transmitting and receiving ARP and InARP packets. Laubach [Page 9] DRAFT Classical IP and ARP over ATM September 1993 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh its own client ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP its own client table entries. 5. Provide an ARP table aging function to remove is own old client ARP tables entries after a convenient period of time. Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. ARP Table Aging An ARP client or server must have knowledge of any open VC's it has (permanent or switched), their association with an ARP table entry, and in particular, which VC's support LLC/SNAP encapsulation. Client ARP table entries are valid for a maximum time of 15 minutes. Server ARP table entries are valid for a minimum time of 20 minutes. Prior to aging (removing) an ARP table entry, all stations must generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the entry is deleted. ARP and InARP Packet Format Internet addresses are assigned independent of ATM addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. IPI stations MUST also use ARP and InARP to resolve IP addresses to ATM addresses when needed and vice versa. The ARP and InARP protocol has several fields that have the following format and values: Laubach [Page 10] DRAFT Classical IP and ARP over ATM September 1993 Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length of source ATM address (q) ar$sstl 8 bits Type & length of source ATM subaddress (r) ar$op 16 bits Operation code (request or reply) ar$spln 8 bits Length of source protocol address (s) ar$thtl 8 bits Type & length of target ATM address (x) ar$tstl 8 bits Type & length of target ATM subaddress (y) ar$tpln 8 bits Length of target protocol address (z) ar$sha qoctets source ATM address ar$ssa roctets source ATM subaddress ar$spa soctets source protocol address ar$tha xoctets target ATM address ar$tsa yoctets target ATM subaddress ar$tpa zoctets target protocol address Where: ar$hrd - assigned to ATM-FORUM address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$op - The operation type value (decimal): ARP_REQUEST = 1 ARP_REPLY = 2 InARP_REQUEST = 8 InARP_REPLY = 9 ARP_NAK = ?? ar$spln - length in octets of the source protocol address. For IP ar$spln is 4. ar$tpln - length in octets of the target protocol address. For IP ar$tpln is 4. ar$sha - source ATM address number (E.164 or ATM-FORUM NSAP) ar$ssa - source ATM subaddress (ATM-FORUM NSAP) ar$spa - source protocol address ar$tha - target ATM address number (E.164 or ATM-FORUM NSAP) ar$tha - target ATM subaddress (ATM-FORUM NSAP) ar$tpa - target protocol address Laubach [Page 11] DRAFT Classical IP and ARP over ATM September 1993 The encoding of the 8-bit type and length value for ar$shtl, ar$sstl, ar$thtl, and ar$tstl is as follows: MSB 8 7 6 5 4 3 2 1 LSB +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1/0 | Octet length of address | +-----+-----+-----+-----+-----+-----+-----+-----+ Where: bit.8 (reserved) = 0 (for future use) bit.7 (type) = 0 ATM-FORUM NSAP address number = 1 E.164 address number bit.6-1 (length) = 6 bit unsigned octet length of address (MSB = bit.6, LSB = bit.1) ATM addresses in Q.93B (as defined by the ATM-FORUM [9]) include a "Calling Party Number Information Element" and a "Calling Party Subaddress Information Element". These Information Elements (IE's) map to ARP/InARP source ATM address number and source ATM subaddress respectively. Furthermore, ATM-FORUM defines a "Called Party Number Information Element" and a "Called Party Subaddress Information Element". These IE's map to ARP/InARP target ATM address number and source ATM subaddress respectively. Furthermore, the ATM-FORUM defines three cases for the combined use of address numbers and subaddresses: ATM Address Number ATM Subaddress ------------------ --------------- Case 1 ATM-FORUM NSAP null Case 2 E.164 null Case 3 E.164 ATM-FORUM NSAP ARP use of ATM Address Numbers for Case 1 and Case 2 The ATM address numbers in ARP packets (ar$sha, ar$tha) SHALL be E.164 or ATM-FORUM NSAP [9]. Within the LIS, either E.164 or ATM- FORUM NSAP address numbers may be used but both. If ATM-FORUM NSAP address numbers are used, then the same NSAP encoding MUST be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 ATM addresses may be used but not both. Laubach [Page 12] DRAFT Classical IP and ARP over ATM September 1993 ARP use of ATM Subaddress for Case 1, Case 2, and Case 3 This memo has defined the ATM subaddress type/length and fields as part of the ARP packet format. Use of the ATM subaddress is beyond the scope of this memo. Implementations based on this memo, must set ar$sstl.type = 1 and ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0 when generating ARP and InARP requests and replies. Furthermore, implementations upon receiving ARP or InARP requests and replies, must tolerate non-zero subaddress lengths and ignore the subaddress field values. The definition of ARP and InARP for ATM subaddresses will be defined in a future document. ARP/InARP Packet Encapsulation ARP and InARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP/InARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 octets) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 CPCS-SDU. The LLC/SNAP encapsulation for ARP/InARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks Laubach [Page 13] DRAFT Classical IP and ARP over ATM September 1993 as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ARP'ing outside the LIS or by a global ARP mechanism are beyond the scope of this memo. 10. IP Broadcast Address ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict stations from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Stations, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. This memo recognizes the future development of ATM multicast service addressing by the ATM-FORUM. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward. 12. Security Security issues are not discussed in this memo. This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this memo. 13. Open Issues o The ARP hardware address type value for ATM-FORUM and the ARP_NAK operation type value need yet to be assigned by the Internet Assigned Numbers Authority (IANA) Laubach [Page 14] DRAFT Classical IP and ARP over ATM September 1993 o Well known ATM address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", ATM-FORUM, 480 San Antonio Road, Suite 100, Mountain View, CA 94040, June 1993. [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, USC/Information Sciences Institute, August 1989. Laubach [Page 15] DRAFT Classical IP and ARP over ATM September 1993 [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, USC/Information Sciences Institute, July 1991. [12] Bradely, T., and Brown, C., "Inverse Address Resolution Protocol", RFC1293, USC/Information Sciences Institute, January 1992. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 16]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16525; 19 Sep 93 17:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16521; 19 Sep 93 17:47 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11726; 19 Sep 93 17:47 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04380; Sun, 19 Sep 93 13:59:52 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA04373; Sun, 19 Sep 93 13:59:52 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07279; Sun, 19 Sep 93 14:00:08 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA27658; Sun, 19 Sep 93 14:00:28 -0700 Received: by inet-gw-2.pa.dec.com; id AA00650; Sun, 19 Sep 93 13:59:23 -0700 Received: by us3rmc.bb.dec.com; id AA26104; Sun, 19 Sep 93 13:59:15 -0700 Message-Id: <9309192059.AA26104@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Sun, 19 Sep 93 13:59:17 PDT Date: Sun, 19 Sep 93 13:59:17 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mail Delivery Subsystem <"manage::dsap01::mailer-daemon"@manage.enet.dec.com> To: us3rmc: "atm@hpl.hp.com"@manage.enet.dec.com; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Apparently-To: atm@hplms2.hpl.hp.com Subject: Returned mail: Deferred ----- Transcript of session follows ----- ----- Unsent message follows ----- Received: by dsap01.lkg.dec.com (5.57/cgg-100491); id AA29890; Thu, 16 Sep 93 16:05:52 -0400 Date: Thu, 16 Sep 93 16:05:51 -0400 From: manage::US3RMC::"atm@hpl.hp.com" (MAIL-11 Daemon 16-Sep-1993 1616 -0400) To: atm@hplms2.hpl.hp.com Subject: Auto Reply from Watch_Mail for 20-AUG-1993 17:15 to 31-DEC-1993 00:00 August 20th was my last day at Digital. I will not receive the mail message you sent. If you need to get in touch with me, I'll be working at Chipcom starting Monday, August 23. The phone number there is 508-460-8900. Thanks, Miles % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA04028; Thu, 16 Sep 93 12:12:52 -0700 % Received: by inet-gw-1.pa.dec.com; id AA26864; Thu, 16 Sep 93 12:12:55 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18423; Thu, 16 Sep 93 11:56:52 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18416; Thu, 16 Sep 93 11:56:51 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA23767; Thu, 16 Sep 93 12:00:57 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA15626; Thu, 16 Sep 93 12:01:14 -070 % Received: by inet-gw-2.pa.dec.com; id AA07633; Thu, 16 Sep 93 11:59:39 -0700 % Received: by us3rmc.bb.dec.com; id AA01569; Thu, 16 Sep 93 11:59:35 -0700 % Message-Id: <9309161859.AA01569@us3rmc.bb.dec.com> % Received: from levers.enet; by us3rmc.enet; Thu, 16 Sep 93 11:59:35 PDT % Date: Thu, 16 Sep 93 11:59:35 PDT % From: Miles Benson * MS:LKG1-2/W06 * DTN:226-7271 * LOC:LKG1-2/C7 16-Sep-1993 1458 % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Auto Reply from Watch_Mail for 20-AUG-1993 17:15 to 31-DEC-1993 00:00   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04567; 20 Sep 93 12:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04563; 20 Sep 93 12:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa29141; 20 Sep 93 12:52 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19579; Mon, 20 Sep 93 08:15:43 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19572; Mon, 20 Sep 93 08:15:42 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA01031; Mon, 20 Sep 93 08:16:05 -0700 Received: from LOBSTER.WELLFLEET.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA00540; Mon, 20 Sep 93 08:16:25 -0700 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22387; Mon, 20 Sep 93 11:04:54 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA06419; Mon, 20 Sep 93 11:15:21 EDT Date: Mon, 20 Sep 93 11:15:21 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9309201515.AA06419@cabernet.wellfleet> To: laubach@matmos.hpl.hp.com Subject: Re: Classical Draft Status Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com Mark; I apologize for not bringing this up sooner, but.... I have a concern about publishing the Classical IP over ATM document as an RFC before we understand the complete overall picture of how to run IP over ATM. As long at the document is only an Internet Draft, I think that most folks will understand that it is intended only as an input (and an important input) to the process of coming to consensus. However, if it get published as an RFC, then I think that we are likely to start seeing actual host products based on this model. If we subsequently come up with a more complete model of how to run IP over ATM, it will be stuck being backward-compatible with hosts which *only* implement the classical model. Thus, I would be more comfortable publishing it (again) as an Internet Draft, and continuing our efforts to try to figure out an overall model of IP over ATM. This should result in a complete set of requirements for hosts and routers which need to operate over ATM. It would then make sense to publish (as RFCs) how a host is required to operate, plus the classical model, at the same time. Presumeably how the hosts operates to allow the classical model would be a subset of the overall requirements of what a host needs to be able to do. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08760; 20 Sep 93 15:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08756; 20 Sep 93 15:56 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10422; 20 Sep 93 15:56 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23774; Mon, 20 Sep 93 11:15:53 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA23767; Mon, 20 Sep 93 11:15:51 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA22500; Mon, 20 Sep 93 11:15:55 PDT Received: by msgate.hls.com with Microsoft Mail id <2C9DF656@msgate.hls.com>; Mon, 20 Sep 93 11:28:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: ip_over_atm , 'ip over atm_old' Subject: Re: ARP and E.164 Address Formats Date: Mon, 20 Sep 93 11:14:00 PDT Message-Id: <2C9DF656@msgate.hls.com> Encoding: 67 TEXT X-Mailer: Microsoft Mail V3.0 This doesn't seem to have got out at all - has someone fixed the alias by just turning it off??? ---------- From: Mailer-Daemon To: anthony Subject: Returned mail: User unknown Date: Wednesday, 15 September 1993 2:39PM >Well it certainly appears to me that we've got some concepts confused! >And perhaps were justly reaping the consequences of defining address >formats without figuring out routing. I don't agree with Brian that >we should have stopped at E.164, but we should have gotten clear all >the issues before putting pen to paper. ...but then I just voted yes >on the UNI 3.0 doc, so count me among the guilty. I think that there has been some confusion about the subnetwork issue in the ARP discussion, but I thought that the implications were fairly clear at the Forum. Maybe that was wishful thinking... >The issue of whether the E.164 address is peer, subserviant to, or >superior to the NSAP is clearly confused. In P-NNI discussions we're >calling an E.164 cloud a subnet, but in our address format to cross >this cloud we call the E.164 address the address and the NSAP the >sub-address. I'm of the opinion that the second usage here is the one >that's in error. The NSAP is by def a globally unique address and not >a subaddress of anything. Yes, as I mentioned yesterday, its really the E.164 address that is the subnetwork address, but that's not the way signaling treats it of course, since that is public network centric. I don't think it makes too much difference either way, as long as we all remember what we are talking about. >What I think folks were mostly conceiving >of was a two stage address with the E.164 address indicating the >egress from the public network and the NSAP indicating the final >destination. In fact one might reach this destination through several >different E.164 egresses from the public network, or a route may >exist that doesn't involve the public netowrk at all. In this sense, >at the P-NNI, the E.164 address is not part of resolving the IP >address at all, but part of a loose source route. Yes, I agree, this is certainly true from a strict layering viewpoint, though, as Dan and Subbu pointed out, maybe there are efficiencies to be gained from a less strict interpretation. >For the purposes of a P-NNI style network I therefore think it makes >sense that ARP resolve the IP address to an NSAP and let VC-routing >figure out if an E.164 address is needed some where along the way to >navigate across a public cloud used as a subnet. right way to solve this problem - I do worry about embedding knowledge of the subnetwork structure(s) in a protocol (i.e. ARP) that should only care about end to end connectivity. Most people, thus far, however, seem to favor a combined approach - any comments from anyone about why this may or may not be a good thing? >...George Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10790; 20 Sep 93 17:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10786; 20 Sep 93 17:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15748; 20 Sep 93 17:15 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25930; Mon, 20 Sep 93 11:53:19 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA25920; Mon, 20 Sep 93 11:53:16 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA24878; Mon, 20 Sep 93 11:53:28 PDT Received: by msgate.hls.com with Microsoft Mail id <2C9DFF24@msgate.hls.com>; Mon, 20 Sep 93 12:06:12 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , 'ip over atm_old' , Mark Laubach Subject: RE: Classical Draft Status Date: Mon, 20 Sep 93 11:52:00 PDT Message-Id: <2C9DFF24@msgate.hls.com> Encoding: 119 TEXT X-Mailer: Microsoft Mail V3.0 Mark, I'm not sure that this latest version captures all the discussion that went on last week on use of the E.164 addresses, and what that implies for the use of ARP (I think most of the emails did not get to the group, since the list was down). In any case, while I agree that it is prudent at this stage for the draft not to get into the thorny issues about where and how the E.164 address is applicable, I think the proposal you have in the latest draft is not the best way of ducking the issue. On the contrary, your proposal that LISs will use _either_ NSAP encoded addresses _or_ E.164 addresses, but _not_ both, is misleading, since it seems to exclude interworking between private, NSAP based, ATM hosts, and hosts _directly_ attached to E.164 based public ATM networks (surely an important case!), and it also suggests (whether or not you meant it to), that the use of such addresses is somehow equivalent, particularly in private networks. On the contrary, as the emails last week discussed, this will almost never be the case - rather, private ATM networks (my operational definition of which is any ATM network that interacts with the P-NNI protocol) will use NSAP addresses; any network that _only_ supports E.164 addresses will probably never be able to communicate with such a private ATM network - surely something to be avoided, and certainly not something to be encouraged by the IETF, through the draft RFC. Communication between NSAP based private ATM networks, and an _end station_ attached to a public E.164 based network, will, I maintain, require the _end station_ to support _both_ an NSAP address and an E.164 address, with some kind of resolution, algorithmic or otherwise, between them. This last case, however, appears to be the case that is specifically excluded from the draft, viz: "Within the LIS, either E.164 or ATM-FORUM NSAP address numbers may be used, but [not] both". < the draft ommits the word 'not', but I presume that was what was meant!> I say appears, because I presume (hope!) that you did not actually mean to suggest that it was excluded, but rather that the ARP protocol will support resolution to NSAP addresses only (for the case of private ATM networks), and leave the further resolution to an E.164 address, when traversing an ATM subnetwork, such as public network, to a local mechanism. This is, I think, where the group more or less came down to last week, with a feeling that the latter resolution is best defined at the ATM Forum, perhaps as part of the P-NNI work. I would propose that this is what the draft should also say, and say explicitly, both to clarify the matter for those readers who, in the future, may not be aware of some of the background, and, more importantly, so as to encourage implementers to support NSAP based addresses. I am very concerned, and I know others are also, that the political compromise at the Forum, necessary as it was, to support two address types, for private and public networks, will lead to all sorts of confusion in the market, with some people building terminals that support E.164 only, which will then not be able to communicate with private terminals. We should try, whenever possible, to avoid this, by requiring, as the protocol models do, that _all_ terminals that wish to interoperate with private ATM terminals, support NSAP based addresses. Whether or not these then also support E.164 addresses, so as to permit direct connection to public ATM networks, then becomes implementation/marketing issues, but at least interoperability will be possible from a technical perspective. For this reason, I would also propose that the draft preclude the case of E.164 address only based networks; I can't see much utility in terminals that can talk IP only to other public terminals, and not to any private terminals. Finally, a comment on your discussion of subaddressing. While your discussion is accurate WRT the usage of these fields within _signaling_ PDUs, I think it is misleading from the perspective of a higher layer protocol like ARP. Again, as discussed last week, from the perspective of such a protocol, the NSAP address is always the main address, with the E.164 address, if present, being a subnetwork address. If the draft is to talk about these at all (and I'm not sure what is gained since it later says that subaddresses will be ignored!), then, consistent with the discussion above, I would suggest that it should say the the ATM hardware address will _always_ be a NSAP encoded address, with, possibly, an E.164 address being present as a _subaddress_ (though this is a slippery slope - what if there is more than one level of hierarchy in the network?). Personally, I would avoid the discussion of subaddresses altogether, and let ARP worry only about NSAP addresses; the Forum should then worry about a mechanism for NSAP to E.164 resolution. Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11849; 20 Sep 93 18:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11845; 20 Sep 93 18:08 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19687; 20 Sep 93 18:08 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00399; Mon, 20 Sep 93 13:53:54 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00392; Mon, 20 Sep 93 13:53:52 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA03015; Mon, 20 Sep 93 13:54:16 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA12393; Mon, 20 Sep 93 21:52:50 +0100 Received: from motgate.mot.com by hplb.hpl.hp.com; Mon, 20 Sep 93 21:43:27 +0100 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA00287; Mon, 20 Sep 1993 15:54:08 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA26505; Mon, 20 Sep 1993 15:54:05 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA26527 (5.65a+/IDA-1.4.2 for atm@hpl.hp.com); Mon, 20 Sep 93 16:54:00 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA08115 (5.65a+/IDA-1.4.2 for dan@merlin.dev.cdx.mot.com); Mon, 20 Sep 93 16:53:58 -0400 Message-Id: <9309202053.AA08115@dbg.dev.cdx.mot.com> To: atm@hplms2.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com Subject: Re: Classical IP and ARP over ATM In-Reply-To: Your message of "Sun, 19 Sep 93 11:40:02 PDT." <9309191840.AA29185@matmos.hpl.hp.com> Date: Mon, 20 Sep 93 16:53:57 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > 2) How to select the IP/ARP stack when receiving an incoming call in > host/router supporting multiple stack ? > Do you plan to use the BHLI (Broadband High Layer I.E.) and ask the > ATM forum / CCITT for a code point to identify IP stack. > > The other opinions I've received on this so far, is that the ATM-FORUM > has not "grown up enough" yet for this. I'd like to have this as > a discussion item on the Houston agenda also. The IP stack is identified in the B-LLI IE. Specifically, when the LLC encapsulation is used as in RFC 1483, the user information layer 2 protocol is codes s "LAN logical link control". When the null encapsulation is used, User Information Layer 3 is coded to indicate that ISO/IEC TE 9577 NLPID follows* in the B-LLI; the NLPID is coded as the NLPID codepoint for IP. See appendix T of the ATM forum spec for details. * Please do NOT confuse the use of NLPID encodings in the B-LLI information element with NLPID encapsulation in the AAL5 CPCS-SDU. The RFC 1483 encapsulations are fully accomodated. Use of the NLPID encoding in the B-LLI was done for convenience of standardization. It does not imply that the NLPID encoding convention applies in the user plane. Flames to /dev/null. B-HLI is emphatically NOT the right place for this information. I can envision that future work in multimedia (not over VAT), video, etc. will need B-HLI. So will TULIP/TUNIC, when we get to that point. For the purposes of classical IP/ATM, let's forget that B-HLI exists. Rgds Dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13010; 20 Sep 93 19:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13006; 20 Sep 93 19:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26606; 20 Sep 93 19:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03849; Mon, 20 Sep 93 15:41:30 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03842; Mon, 20 Sep 93 15:41:29 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA03540; Mon, 20 Sep 93 15:41:54 -0700 Received: from netcom.netcom.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA03648; Mon, 20 Sep 93 15:42:11 -0700 Received: from [132.240.18.75] by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA24010; Mon, 20 Sep 93 15:40:56 -0700 Message-Id: <9309202240.AA24010@netcom.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Sep 1993 15:44:20 -0800 To: atm@hplms2.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sam Ghandchi Subject: OSPF FORUM Would anybody here know the address where I can contact the OSPF forum? I just read in an industry paper that some bug fixes have been made to the OSPF rfc and I would like to find out where to get the latest OSPF stuff. TIA - Sam =============================================================== Sam Ghandchi samg@netcom.com Cupertino, CA =============================================================== =============================================================== Sam Ghandchi samg@netcom.com Cupertino, CA ===============================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13934; 20 Sep 93 20:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13930; 20 Sep 93 20:34 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa29797; 20 Sep 93 20:34 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05932; Mon, 20 Sep 93 16:18:45 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05883; Mon, 20 Sep 93 16:18:40 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA03765; Mon, 20 Sep 93 16:19:02 -0700 Received: from norman.nwnet.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA03930; Mon, 20 Sep 93 16:19:22 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA01728; Mon, 20 Sep 93 16:17:42 -0700 Date: Mon, 20 Sep 1993 16:15:52 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Robel Subject: Re: OSPF FORUM To: atm@hplms2.hpl.hp.com Cc: atm@hplms2.hpl.hp.com In-Reply-To: <9309202240.AA24010@netcom.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Sep 1993, Sam Ghandchi wrote: > Would anybody here know the address where I can contact the OSPF forum? I > just read in an industry paper that some bug fixes have been made to the OSPF > rfc and I would like to find out where to get the latest OSPF stuff. You can subscribe to the OSPF working group by sending a note to: ospf-request@trantor.umd.edu They'd know the answer to you question... regards, Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15262; 20 Sep 93 22:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15258; 20 Sep 93 22:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05541; 20 Sep 93 22:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12447; Mon, 20 Sep 93 17:49:28 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12440; Mon, 20 Sep 93 17:49:27 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04326; Mon, 20 Sep 93 17:49:53 -0700 Received: from netcom.netcom.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA04473; Mon, 20 Sep 93 17:50:14 -0700 Received: from [132.240.18.75] by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA15829; Mon, 20 Sep 93 17:48:50 -0700 Message-Id: <9309210048.AA15829@netcom.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Sep 1993 17:52:15 -0800 To: allen@nwnet.net Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sam Ghandchi Subject: Re: OSPF FORUM Cc: atm@hplms2.hpl.hp.com Thank you very much for the feedback =============================================================== Sam Ghandchi samg@netcom.com Cupertino, CA ===============================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15517; 20 Sep 93 22:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15509; 20 Sep 93 22:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06234; 20 Sep 93 22:24 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10248; Mon, 20 Sep 93 17:27:38 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10238; Mon, 20 Sep 93 17:27:36 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA10354; Mon, 20 Sep 93 17:27:51 PDT Received: by msgate.hls.com with Microsoft Mail id <2C9E4D89@msgate.hls.com>; Mon, 20 Sep 93 17:40:41 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: ip_over_atm , HP - Mark Laubach Subject: Repost: RE: Classical Draft Status Date: Mon, 20 Sep 93 17:27:00 PDT Message-Id: <2C9E4D89@msgate.hls.com> Encoding: 110 TEXT X-Mailer: Microsoft Mail V3.0 This is a repost of my earlier posting - hopefully without the line wraps! Anthony. ps. Blame Bill Gates for the line wraps! Microsoft Mail for Windows sucks!! ----------------------- Mark, I'm not sure that this latest version captures all the discussion that went on last week on use of the E.164 addresses, and what that implies for the use of ARP (I think most of the emails did not get to the group, since the list was down). In any case, while I agree that it is prudent at this stage for the draft not to get into the thorny issues about where and how the E.164 address is applicable, I think the proposal you have in the latest draft is not the best way of ducking the issue. On the contrary, your proposal that LISs will use _either_ NSAP encoded addresses _or_ E.164 addresses, but _not_ both, is misleading, since it seems to exclude interworking between private, NSAP based, ATM hosts, and hosts _directly_ attached to E.164 based public ATM networks (surely an important case!), and it also suggests (whether or not you meant it to), that the use of such addresses is somehow equivalent, particularly in private networks. On the contrary, as the emails last week discussed, this will almost never be the case - rather, private ATM networks (my operational definition of which is any ATM network that interacts with the P-NNI protocol) will use NSAP addresses; any network that _only_ supports E.164 addresses will probably never be able to communicate with such a private ATM network - surely something to be avoided, and certainly not something to be encouraged by the IETF, through the draft RFC. Communication between NSAP based private ATM networks, and an _end station_ attached to a public E.164 based network, will, I maintain, require the _end station_ to support _both_ an NSAP address and an E.164 address, with some kind of resolution, algorithmic or otherwise, between them. This last case, however, appears to be the case that is specifically excluded from the draft, viz: "Within the LIS, either E.164 or ATM-FORUM NSAP address numbers may be used, but [not] both". < the draft ommits the word 'not', but I presume that was what was meant!> I say appears, because I presume (hope!) that you did not actually mean to suggest that it was excluded, but rather that the ARP protocol will support resolution to NSAP addresses only (for the case of private ATM networks), and leave the further resolution to an E.164 address, when traversing an ATM subnetwork, such as public network, to a local mechanism. This is, I think, where the group more or less came down to last week, with a feeling that the latter resolution is best defined at the ATM Forum, perhaps as part of the P-NNI work. I would propose that this is what the draft should also say, and say explicitly, both to clarify the matter for those readers who, in the future, may not be aware of some of the background, and, more importantly, so as to encourage implementers to support NSAP based addresses. I am very concerned, and I know others are also, that the political compromise at the Forum, necessary as it was, to support two address types, for private and public networks, will lead to all sorts of confusion in the market, with some people building terminals that support E.164 only, which will then not be able to communicate with private terminals. We should try, whenever possible, to avoid this, by requiring, as the protocol models do, that _all_ terminals that wish to interoperate with private ATM terminals, support NSAP based addresses. Whether or not these then also support E.164 addresses, so as to permit direct connection to public ATM networks, then becomes implementation/marketing issues, but at least interoperability will be possible from a technical perspective. For this reason, I would also propose that the draft preclude the case of E.164 address only based networks; I can't see much utility in terminals that can talk IP only to other public terminals, and not to any private terminals. Finally, a comment on your discussion of subaddressing. While your discussion is accurate WRT the usage of these fields within _signaling_ PDUs, I think it is misleading from the perspective of a higher layer protocol like ARP. Again, as discussed last week, from the perspective of such a protocol, the NSAP address is always the main address, with the E.164 address, if present, being a subnetwork address. If the draft is to talk about these at all (and I'm not sure what is gained since it later says that subaddresses will be ignored!), then, consistent with the discussion above, I would suggest that it should say the the ATM hardware address will _always_ be a NSAP encoded address, with, possibly, an E.164 address being present as a _subaddress_ (though this is a slippery slope - what if there is more than one level of hierarchy in the network?). Personally, I would avoid the discussion of subaddresses altogether, and let ARP worry only about NSAP addresses; the Forum should then worry about a mechanism for NSAP to E.164 resolution. Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23390; 21 Sep 93 1:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23386; 21 Sep 93 1:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17512; 21 Sep 93 1:40 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA17841; Mon, 20 Sep 93 21:27:15 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17824; Mon, 20 Sep 93 21:27:14 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04888; Mon, 20 Sep 93 21:27:36 -0700 Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05596; Mon, 20 Sep 93 21:27:55 -0700 Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -0700 Date: Mon, 20 Sep 1993 21:25:57 -0700 Message-Id: <199309210425.AA09395@lager.cisco.com> X-Sender: forster@lager.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Forster Subject: Re: Classical Draft Status Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01317; 21 Sep 93 6:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ag01280; 21 Sep 93 6:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02071; 21 Sep 93 5:07 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA26751; Mon, 20 Sep 93 23:47:38 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26744; Mon, 20 Sep 93 23:47:36 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA05344; Mon, 20 Sep 93 23:48:03 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA00249; Tue, 21 Sep 93 07:46:37 +0100 Received: from dxmint.cern.ch by hplb.hpl.hp.com; Tue, 21 Sep 93 07:37:13 +0100 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11333; Tue, 21 Sep 1993 08:47:54 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA00589; Tue, 21 Sep 1993 08:47:52 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309210647.AA00589@dxcern.cern.ch> Subject: Re: Classical Draft Status To: atm@hplms2.hpl.hp.com Date: Tue, 21 Sep 1993 08:47:50 +0200 (MET DST) In-Reply-To: <199309210425.AA09395@lager.cisco.com> from "Jim Forster" at Sep 20, 93 09:25:57 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1340 Hooray! A Reply-to field. Now if everybody could please remember to type R instead of r we will only get one copy of each message... Jim is right and Ross is wrong. I need a stable RFC now because I need compatible code from several vendors in 3 months. The Framework document will show how the classical model clips onto the general model. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by Jim Forster follows: > > At 11:15 AM 9/20/93 -0400, Ross Callon wrote: > >Mark; > > > >I apologize for not bringing this up sooner, but.... I have a concern > >about publishing the Classical IP over ATM document as an RFC before > >we understand the complete overall picture of how to run IP over ATM. > > Ross, > > It's going to take years before we understand this complete picture. There > is value in getting a document out on how to do the simple stuff we pretty > much do understand. Prompt publication of this document is the only hope > to get the host implementations that are underway to implement the same > scheme. I'm not saying we should rush it out with sloppy work, but I am > arguing that we don't > need to re-examine the scope of this work.Meanwhile, there's certainly > plenty of work that can go into followup work. > > > > -- Jim > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02364; 21 Sep 93 7:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02360; 21 Sep 93 7:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08878; 21 Sep 93 7:38 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27802; Mon, 20 Sep 93 23:51:30 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27795; Mon, 20 Sep 93 23:51:28 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA05350; Mon, 20 Sep 93 23:51:56 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA00287; Tue, 21 Sep 93 07:50:30 +0100 Received: from dxmint.cern.ch by hplb.hpl.hp.com; Tue, 21 Sep 93 07:41:07 +0100 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11628; Tue, 21 Sep 1993 08:51:49 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA02078; Tue, 21 Sep 1993 08:51:38 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309210651.AA02078@dxcern.cern.ch> Subject: Re: Classical Draft Status To: atm@hplms2.hpl.hp.com Date: Tue, 21 Sep 1993 08:51:37 +0200 (MET DST) In-Reply-To: <9309191833.AA28464@matmos.hpl.hp.com> from "Mark Laubach" at Sep 19, 93 11:33:22 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: 238 Let's go with this draft. I think the E.164 issue is handled very well this time. Nits on page 12: the 2nd ocurrence of "source ATM subaddress" should be "target ATM subaddress" "but both" should be "but not both" -- Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04630; 21 Sep 93 9:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04626; 21 Sep 93 9:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14448; 21 Sep 93 9:17 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10075; Tue, 21 Sep 93 04:58:28 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10068; Tue, 21 Sep 93 04:58:27 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06561; Tue, 21 Sep 93 04:58:58 -0700 Received: from sun4.iol.unh.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06576; Tue, 21 Sep 93 04:59:18 -0700 Received: by sun4.iol.unh.edu (4.1/SMI-4.1) id AA11444; Tue, 21 Sep 93 07:58:13 EDT Date: Tue, 21 Sep 93 07:58:13 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ronald W. Pashby" Message-Id: <9309211158.AA11444@sun4.iol.unh.edu> To: atm@hplms2.hpl.hp.com Subject: UNH/IOL ATM Interoperability Lab The University of New Hampshire's Interoperability Lab is announcing the formation of the ATM Consortium. The initial meeting will be held on October 8, at the Ilumni Center of UNH. This is an informational meeting, as well as a charter membership meeting. Attendance does not obligate individuals or organizations in any way. All interested parties should contact Ron Pashby by calling (603)862-0204 or via email to pashby@unh.edu. If you are interested, but are not available to attend, we would be happy to provide you with further information and results of the meeting. Please feel free to forward this message to anyone that you think might be interested in this information and CC to pashby@unh.edu.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07382; 21 Sep 93 10:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07369; 21 Sep 93 10:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19495; 21 Sep 93 10:43 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16756; Tue, 21 Sep 93 06:37:26 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16749; Tue, 21 Sep 93 06:37:25 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06811; Tue, 21 Sep 93 06:37:56 -0700 Received: from dnlts0.research.ptt.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06835; Tue, 21 Sep 93 06:38:16 -0700 Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H37RBAF4M88Y7L3A@research.ptt.nl>; Tue, 21 Sep 1993 15:35:37 +0200 Date: Tue, 21 Sep 1993 15:35:37 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37RBAIM0I8Y7L3A@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: atm@hpl.hp.com X-Vms-To: IN%"atm@hpl.hp.com" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Please remove me from this alias. Kees Hol HOL@research.ptt.nl   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07463; 21 Sep 93 10:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07458; 21 Sep 93 10:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19647; 21 Sep 93 10:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15698; Tue, 21 Sep 93 06:32:52 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15691; Tue, 21 Sep 93 06:32:52 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06805; Tue, 21 Sep 93 06:33:23 -0700 Received: from zeus.cs.kun.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06809; Tue, 21 Sep 93 06:33:41 -0700 Received: from zeus.cs.kun.nl by zeus.cs.kun.nl with SMTP id AA17277 (5.65c8/1.0 for atm@hpl.hp.com); Tue, 21 Sep 1993 15:31:59 +0200 Message-Id: <199309211331.AA17277@zeus.cs.kun.nl> To: atm@hplms2.hpl.hp.com Subject: Re: UNH/IOL ATM Interoperability Lab In-Reply-To: Your message of "Tue, 21 Sep 93 07:58:13 EDT." <9309211158.AA11444@sun4.iol.unh.edu> Date: Tue, 21 Sep 93 15:31:57 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: johnk@cs.kun.nl Dear Ron, I'm interested in the ATM Consortium as announced by your message, but I'm afraid I can not attend. Please provide me with further info and results. Thanks a lot in advance, -------------------------------------------------------------------------------- John Kroeze Internet: johnk@cs.kun.nl __ University of Nijmegen, UUCP:uunet!cs.kun.nl!johnk / \ Faculty of Computer Science, ----+----k P.O. 9010 Phone: +31 80 65 24 50 |O |\ 6500 GL Nijmegen, Room: A4010 /| | the Netherlands Fax: +31 80 55 34 50 |_| | --------------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07902; 21 Sep 93 11:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07898; 21 Sep 93 11:04 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20548; 21 Sep 93 11:04 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13025; Tue, 21 Sep 93 05:35:50 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13014; Tue, 21 Sep 93 05:35:49 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06704; Tue, 21 Sep 93 05:36:19 -0700 Received: from cheetah.vlsi.uwaterloo.ca by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06642; Tue, 21 Sep 93 05:36:39 -0700 Received: by cheetah.vlsi.uwaterloo.ca id ; Tue, 21 Sep 93 08:34:59 -0400 Date: Tue, 21 Sep 93 08:34:59 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Kesidis Message-Id: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca> To: atm@hplms2.hpl.hp.com Subject: please remove me from this alias Please remove me from this alias. George Kesidis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08002; 21 Sep 93 11:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07996; 21 Sep 93 11:07 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20638; 21 Sep 93 11:07 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18594; Tue, 21 Sep 93 06:55:16 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18581; Tue, 21 Sep 93 06:55:15 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06895; Tue, 21 Sep 93 06:55:46 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06921; Tue, 21 Sep 93 06:56:06 -0700 Received: by interlock.ans.net id AA11051 (InterLock SMTP Gateway 1.1 for atm@hplms2.hpl.hp.com); Tue, 21 Sep 1993 09:48:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 09:48:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 09:48:12 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309211352.AA52084@foo.ans.net> To: atm@hplms2.hpl.hp.com Cc: atm@hplms2.hpl.hp.com, curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Tue, 21 Sep 93 08:47:50 O.) <9309210647.AA00589@dxcern.cern.ch> Date: Tue, 21 Sep 93 09:52:26 -0500 > Ross Callon wrote: > >I apologize for not bringing this up sooner, but.... I have a concern > >about publishing the Classical IP over ATM document as an RFC before > >we understand the complete overall picture of how to run IP over ATM. Ross, Do you see any places where we might be painting ourselves into a corner? Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00922; 21 Sep 93 12:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ag00857; 21 Sep 93 12:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01380; 21 Sep 93 12:34 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA29984; Tue, 21 Sep 93 08:07:06 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA29977; Tue, 21 Sep 93 08:07:05 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07301; Tue, 21 Sep 93 08:07:37 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07392; Tue, 21 Sep 93 08:07:54 -0700 Received: by inet-gw-2.pa.dec.com; id AA19910; Tue, 21 Sep 93 08:07:30 -0700 Received: by us3rmc.bb.dec.com; id AA24501; Tue, 21 Sep 93 08:06:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211506.AA24501@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:06:48 PDT Date: Tue, 21 Sep 93 08:06:48 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:06 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com CC: atm@hplms2.hpl.hp.com,curtis@ans.net,mathis@pele.psc.edu Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: >Do you see any places where we might be painting ourselves into a >corner? I sure see some dangers. Given that ATM switches do congestion and error control on the cell level, and TCP senses path state at the packet (frame) level, the current architecture has changed the gain of the TCP window servo by more than three orders of magnitude. I suspect that we will discover that TCP over ATM on big pipes is unstable (In a control theory sense), and we will have to make some changes. One of the "easy" fixes would be to add forward error correction at the AAL layer..... Another would be to convince the switch vendors to do frame dropping.... (If you drop a low priority cell, drop all until the next high priority cell). On the other hand, until we have some field experience all arguments are pointless. --MM-- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA24348; Tue, 21 Sep 93 08:06:05 -0700 % Received: by inet-gw-1.pa.dec.com; id AA23614; Tue, 21 Sep 93 08:05:53 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24208; Tue, 21 Sep 93 07:50:24 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24201; Tue, 21 Sep 93 07:50:23 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07148; Tue, 21 Sep 93 07:50:23 -070 % Received: from pele.psc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07236; Tue, 21 Sep 93 07:49:09 -070 % Received: by pele.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA25006; Tue, 21 Sep 93 10:47:15 -040 % Message-Id: <9309211447.AA25006@pele.psc.edu> % To: atm@hplms2.hpl.hp.com % Cc: atm@hplms2.hpl.hp.com, curtis@ans.net, mathis@pele.psc.edu % Subject: Re: Classical Draft Status % In-Reply-To: Your message of "Tue, 21 Sep 93 09:52:26 CDT." <199309211352.AA52084@foo.ans.net> % Date: Tue, 21 Sep 93 10:47:14 -0400 % From: mathis@pele.psc.edu % X-Mts: smtp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00930; 21 Sep 93 12:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ah00857; 21 Sep 93 12:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01381; 21 Sep 93 12:34 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00652; Tue, 21 Sep 93 08:09:02 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00634; Tue, 21 Sep 93 08:08:57 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07307; Tue, 21 Sep 93 08:09:28 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07400; Tue, 21 Sep 93 08:09:46 -0700 Received: by inet-gw-2.pa.dec.com; id AA20040; Tue, 21 Sep 93 08:09:16 -0700 Received: by us3rmc.bb.dec.com; id AA24798; Tue, 21 Sep 93 08:07:49 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211507.AA24798@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:08:09 PDT Date: Tue, 21 Sep 93 08:08:09 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:07 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 10:52 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: UNH/IOL ATM Interoperability Lab ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: The University of New Hampshire's Interoperability Lab is announcing the formation of the ATM Consortium. The initial meeting will be held on October 8, at the Ilumni Center of UNH. This is an informational meeting, as well as a charter membership meeting. Attendance does not obligate individuals or organizations in any way. All interested parties should contact Ron Pashby by calling (603)862-0204 or via email to pashby@unh.edu. If you are interested, but are not available to attend, we would be happy to provide you with further information and results of the meeting. Please feel free to forward this message to anyone that you think might be interested in this information and CC to pashby@unh.edu. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA20680; Tue, 21 Sep 93 07:51:51 -0700 % Received: by inet-gw-1.pa.dec.com; id AA11726; Tue, 21 Sep 93 05:21:54 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10075; Tue, 21 Sep 93 04:58:28 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10068; Tue, 21 Sep 93 04:58:27 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06561; Tue, 21 Sep 93 04:58:58 -070 % Received: from sun4.iol.unh.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06576; Tue, 21 Sep 93 04:59:18 -070 % Received: by sun4.iol.unh.edu (4.1/SMI-4.1) id AA11444; Tue, 21 Sep 93 07:58:13 ED % Date: Tue, 21 Sep 93 07:58:13 EDT % From: rwp@iol.unh.edu (Ronald W. Pashby) % Message-Id: <9309211158.AA11444@sun4.iol.unh.edu> % To: atm@hplms2.hpl.hp.com % Subject: UNH/IOL ATM Interoperability Lab % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA24675; Tue, 21 Sep 93 08:07:21 -0700 % Received: by inet-gw-1.pa.dec.com; id AA23670; Tue, 21 Sep 93 08:06:32 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24420; Tue, 21 Sep 93 07:52:59 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24404; Tue, 21 Sep 93 07:52:57 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07155; Tue, 21 Sep 93 07:53:28 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07272; Tue, 21 Sep 93 07:53:29 -070 % Received: by inet-gw-2.pa.dec.com; id AA18907; Tue, 21 Sep 93 07:52:57 -0700 % Received: by us3rmc.bb.dec.com; id AA20921; Tue, 21 Sep 93 07:52:50 -0700 % From: manage::nmail-daemon % Message-Id: <9309211452.AA20921@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 07:52:50 PDT % Date: Tue, 21 Sep 93 07:52:50 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00954; 21 Sep 93 12:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aj00857; 21 Sep 93 12:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01427; 21 Sep 93 12:34 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05490; Tue, 21 Sep 93 08:15:47 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05468; Tue, 21 Sep 93 08:15:46 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07395; Tue, 21 Sep 93 08:16:17 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07471; Tue, 21 Sep 93 08:16:38 -0700 Received: by inet-gw-2.pa.dec.com; id AA20576; Tue, 21 Sep 93 08:16:14 -0700 Received: by us3rmc.bb.dec.com; id AA26841; Tue, 21 Sep 93 08:15:31 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211515.AA26841@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:15:42 PDT Date: Tue, 21 Sep 93 08:15:42 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:15 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com,laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com,rcallon@wellfleet.com Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA26751; Tue, 21 Sep 93 08:15:12 -0700 % Received: by inet-gw-1.pa.dec.com; id AA22374; Mon, 20 Sep 93 22:38:51 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA22107; Mon, 20 Sep 93 22:30:01 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17702; Mon, 20 Sep 93 21:27:00 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04885; Mon, 20 Sep 93 21:27:27 -070 % Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05592; Mon, 20 Sep 93 21:27:48 -070 % Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -070 % Date: Mon, 20 Sep 1993 21:25:57 -0700 % Message-Id: <199309210425.AA09395@lager.cisco.com> % X-Sender: forster@lager.cisco.com % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com % From: forster@cisco.com (Jim Forster) % Subject: Re: Classical Draft Status % Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab01008; 21 Sep 93 12:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab01004; 21 Sep 93 12:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01738; 21 Sep 93 12:36 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA09172; Tue, 21 Sep 93 08:28:54 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA09165; Tue, 21 Sep 93 08:28:53 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07562; Tue, 21 Sep 93 08:29:24 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07623; Tue, 21 Sep 93 08:29:45 -0700 Received: by inet-gw-2.pa.dec.com; id AA21389; Tue, 21 Sep 93 08:28:07 -0700 Received: by us3rmc.bb.dec.com; id AA27558; Tue, 21 Sep 93 08:28:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211528.AA27558@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:28:01 PDT Date: Tue, 21 Sep 93 08:28:01 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 10:56 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Re: UNH/IOL ATM Interoperability Lab ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Dear Ron, I'm interested in the ATM Consortium as announced by your message, but I'm afraid I can not attend. Please provide me with further info and results. Thanks a lot in advance, -------------------------------------------------------------------------------- John Kroeze Internet: johnk@cs.kun.nl __ University of Nijmegen, UUCP:uunet!cs.kun.nl!johnk / \ Faculty of Computer Science, ----+----k P.O. 9010 Phone: +31 80 65 24 50 |O |\ 6500 GL Nijmegen, Room: A4010 /| | the Netherlands Fax: +31 80 55 34 50 |_| | -------------------------------------------------------------------------------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA21798; Tue, 21 Sep 93 07:56:32 -0700 % Received: by inet-gw-1.pa.dec.com; id AA16972; Tue, 21 Sep 93 06:44:38 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15698; Tue, 21 Sep 93 06:32:52 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15691; Tue, 21 Sep 93 06:32:52 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06805; Tue, 21 Sep 93 06:33:23 -070 % Received: from zeus.cs.kun.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06809; Tue, 21 Sep 93 06:33:41 -070 % Received: from zeus.cs.kun.nl by zeus.cs.kun.nl with SMTP id AA17277 (5.65c8/1.0 for atm@hpl.hp.com); Tue, 21 Sep 1993 15:31:59 +020 % Message-Id: <199309211331.AA17277@zeus.cs.kun.nl> % To: atm@hplms2.hpl.hp.com % Subject: Re: UNH/IOL ATM Interoperability Lab % In-Reply-To: Your message of "Tue, 21 Sep 93 07:58:13 EDT." <9309211158.AA11444@sun4.iol.unh.edu> % Date: Tue, 21 Sep 93 15:31:57 +0200 % From: johnk@cs.kun.nl   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01111; 21 Sep 93 12:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01107; 21 Sep 93 12:42 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02187; 21 Sep 93 12:42 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02510; Tue, 21 Sep 93 08:12:11 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA02485; Tue, 21 Sep 93 08:12:10 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07360; Tue, 21 Sep 93 08:12:39 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07446; Tue, 21 Sep 93 08:12:53 -0700 Received: by inet-gw-2.pa.dec.com; id AA20328; Tue, 21 Sep 93 08:12:29 -0700 Received: by us3rmc.bb.dec.com; id AA25967; Tue, 21 Sep 93 08:12:22 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211512.AA25967@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:12:23 PDT Date: Tue, 21 Sep 93 08:12:23 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:12 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:00 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: please remove me from this alias ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Please remove me from this alias. George Kesidis % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA22664; Tue, 21 Sep 93 08:00:04 -0700 % Received: by inet-gw-1.pa.dec.com; id AA13236; Tue, 21 Sep 93 05:47:21 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13025; Tue, 21 Sep 93 05:35:50 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13014; Tue, 21 Sep 93 05:35:49 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06704; Tue, 21 Sep 93 05:36:19 -070 % Received: from cheetah.vlsi.uwaterloo.ca by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06642; Tue, 21 Sep 93 05:36:39 -070 % Received: by cheetah.vlsi.uwaterloo.ca id ; Tue, 21 Sep 93 08:34:59 -040 % Date: Tue, 21 Sep 93 08:34:59 -0400 % From: George Kesidis % Message-Id: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca> % To: atm@hplms2.hpl.hp.com % Subject: please remove me from this alias % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA25873; Tue, 21 Sep 93 08:12:02 -0700 % Received: by inet-gw-1.pa.dec.com; id AA24187; Tue, 21 Sep 93 08:11:38 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28001; Tue, 21 Sep 93 08:00:46 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27994; Tue, 21 Sep 93 08:00:45 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07241; Tue, 21 Sep 93 08:01:17 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07328; Tue, 21 Sep 93 08:01:38 -070 % Received: by inet-gw-2.pa.dec.com; id AA19446; Tue, 21 Sep 93 08:01:12 -0700 % Received: by us3rmc.bb.dec.com; id AA22990; Tue, 21 Sep 93 08:00:56 -0700 % From: manage::nmail-daemon % Message-Id: <9309211500.AA22990@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:00:57 PDT % Date: Tue, 21 Sep 93 08:00:57 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01259; 21 Sep 93 12:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01255; 21 Sep 93 12:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02640; 21 Sep 93 12:46 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01894; Tue, 21 Sep 93 08:11:15 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01877; Tue, 21 Sep 93 08:11:14 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07339; Tue, 21 Sep 93 08:11:45 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07433; Tue, 21 Sep 93 08:12:05 -0700 Received: by inet-gw-2.pa.dec.com; id AA20196; Tue, 21 Sep 93 08:11:41 -0700 Received: by us3rmc.bb.dec.com; id AA25703; Tue, 21 Sep 93 08:11:11 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211511.AA25703@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:11:12 PDT Date: Tue, 21 Sep 93 08:11:12 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:10 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com,laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com,rcallon@wellfleet.com Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA25432; Tue, 21 Sep 93 08:10:09 -0700 % Received: by inet-gw-1.pa.dec.com; id AA22750; Mon, 20 Sep 93 22:43:58 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23222; Mon, 20 Sep 93 22:32:31 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17824; Mon, 20 Sep 93 21:27:14 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04888; Mon, 20 Sep 93 21:27:36 -070 % Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05596; Mon, 20 Sep 93 21:27:55 -070 % Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -070 % Date: Mon, 20 Sep 1993 21:25:57 -0700 % Message-Id: <199309210425.AA09395@lager.cisco.com> % X-Sender: forster@lager.cisco.com % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com % From: forster@cisco.com (Jim Forster) % Subject: Re: Classical Draft Status % Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01812; 21 Sep 93 13:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01808; 21 Sep 93 13:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04909; 21 Sep 93 13:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28001; Tue, 21 Sep 93 08:00:46 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27994; Tue, 21 Sep 93 08:00:45 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07241; Tue, 21 Sep 93 08:01:17 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07328; Tue, 21 Sep 93 08:01:38 -0700 Received: by inet-gw-2.pa.dec.com; id AA19446; Tue, 21 Sep 93 08:01:12 -0700 Received: by us3rmc.bb.dec.com; id AA22990; Tue, 21 Sep 93 08:00:56 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211500.AA22990@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:00:57 PDT Date: Tue, 21 Sep 93 08:00:57 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:00 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: please remove me from this alias ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Please remove me from this alias. George Kesidis % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA22664; Tue, 21 Sep 93 08:00:04 -0700 % Received: by inet-gw-1.pa.dec.com; id AA13236; Tue, 21 Sep 93 05:47:21 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13025; Tue, 21 Sep 93 05:35:50 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13014; Tue, 21 Sep 93 05:35:49 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06704; Tue, 21 Sep 93 05:36:19 -070 % Received: from cheetah.vlsi.uwaterloo.ca by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06642; Tue, 21 Sep 93 05:36:39 -070 % Received: by cheetah.vlsi.uwaterloo.ca id ; Tue, 21 Sep 93 08:34:59 -040 % Date: Tue, 21 Sep 93 08:34:59 -0400 % From: George Kesidis % Message-Id: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca> % To: atm@hplms2.hpl.hp.com % Subject: please remove me from this alias   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01866; 21 Sep 93 13:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01862; 21 Sep 93 13:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05039; 21 Sep 93 13:13 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11294; Tue, 21 Sep 93 08:38:15 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11287; Tue, 21 Sep 93 08:38:14 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07658; Tue, 21 Sep 93 08:38:45 -0700 Received: from LANSLIDE.HLS.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07708; Tue, 21 Sep 93 08:39:04 -0700 Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA28662; Tue, 21 Sep 93 08:37:08 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA12146; Tue, 21 Sep 93 08:22:59 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9309211522.AA12146@nms.hls.com> Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Date: Tue, 21 Sep 93 8:22:58 PDT In-Reply-To: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca>; from "George Kesidis" at Sep 21, 93 8:34 am Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Hi, I just received the message below which you sent to the mailing-list. For your information, the Internet convention and ettiquette is that requests to subscribe, change address, and unsubscribe to a mailing-list should be sent the mailing-list's administrative address, which is obtained by appending "-request" to the username at the relevant address, e.g., to subscribe/change-address/unsubscribe from the snmp@psi.com list send to snmp-request@psi.com , or for the atm@hpl.hp.com list to atm-request@hpl.hp.com. Please remember this for the future to avoid bothering the whole list's readership with your administrative requests. Thanks, Keith. PS. I also append below the text of RFC 1463, just in case you a new user to the Internet. ------------ Date: Tue, 21 Sep 93 08:34:59 -0400 From: George Kesidis Message-Id: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca> To: atm@hplms2.hpl.hp.com Subject: please remove me from this alias Status: OR Please remove me from this alias. George Kesidis ------------ Network Working Group E. Hoffman Request for Comments: 1463 Merit Network, Inc. FYI: 19 L. Jackson NASA May 1993 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings for the Network Novice Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. Acknowledgments This document is based upon the work of the User Documents Working Group in the User Services Area of the Internet Engineering Task Force (IETF). Bibliography of Introductory Readings The following list includes a number of sources for learning about the Internet. If you have more questions about the Internet, the best source of information is your network service provider. For those interested in finding out about getting Internet connectivity, the books listed will help you locate a network service provider. * Items with an asterisk are available at no charge on-line on the Internet--see the final section for information on how to obtain these. Hoffman & Jackson [Page 1] RFC 1463 FYI--Short Bibliography May 1993 1a. Introductory Papers * Kehoe, Brendan P. (1992) "Zen and the Art of the Internet: A Beginner's Guide to the Internet," (first edition) 95 p. * Krol, E. and E. Hoffman. (1993) "What is the Internet?" 11 p. (FYI 20, RFC 1462). * Malkin, G. and A. Marine. (1992) "FYI on Questions and Answers: Answers to Commonly Asked 'New Internet User' Questions," 32 p. (FYI 4, RFC 1325). * LaQuey, Tracy with Jeanne C. Ryer. (1992) "The.Internet. Companion," 30 p. (on-line chapters from book published by Addison-Wesley) 1b. Introductory Books: Basic User Guides Kehoe, Brendan P. (1993) Zen and the Art of the Internet: A Beginner's Guide, (second edition) 112 p. Prentice Hall, Englewood Cliffs, NJ. Krol, Ed. (1992) The Whole Internet User's Guide and Catalog, 400 p. O'Reilly & Assoc., Inc. Sebastopol, CA. LaQuey, Tracy with Jeanne C. Ryer. (1992) The Internet Companion: A Beginner's Guide to Global Networking, 208 p. Addison-Wesley, Reading, MA. 1c. Introductory Books: Connection Starters SRI International. (1992) Internet: Getting Started, 318 p. SRI International, 333 Ravenswood Ave., Rm. EJ291, Menlo Park, CA 94025. 2. Internet services and resources * Martin, J. (1993) "There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places," 39 p. (RFC 1402/FYI 10). * Merit Network, Inc. (1992) "Cruise of the Internet," Merit Network Inc., Ann Arbor, MI. (Disk based tutorial available for Macintosh or Windows). Metz, Ray (1992) Directory of Directories on the Internet, 175 p. Meckler, Westport, CT. Hoffman & Jackson [Page 2] RFC 1463 FYI--Short Bibliography May 1993 * NSF Network Service Center. (nd) "Internet Resource Guide," NSF Network Service Center, Cambridge, MA. 3. Internet networks Frey, Donnalyn and Rick Adams. (1991) !%@:: A Directory of Electronic Mail Addressing and Networks, (second edition) 436 p. O'Reilly & Assoc. Inc. Sebastopol, CA. LaQuey, Tracy L. (1990) User's Directory of Computer Networks, 653 p. Digital Press, Bedford, MA. Quarterman, John S. (1990) The Matrix: Computer Networks and Conferencing Systems Worldwide, 746 p. Digital Press, Bedford, MA. 4. Introducing the Internet Protocols Comer, Douglas E. (1991) Internetworking With TCP/IP: Volume I, Principles, Protocols, and Architecture, (second edition). 547 p. Prentice Hall, Englewood Cliffs, NJ * Hedrick, Charles L. (1987) "Introduction to the Internet Protocols," 34 p. Rutgers University Computer Science Facilities Group, Piscataway, NJ. Lynch, Daniel C. & Marshall T. Rose (eds). (1993) The Internet System Handbook, 822 p. Addison-Wesley, Reading, MA. 6. Further Reading * Bowers, K. L. et al. (1990) "FYI on Where to Start: A Bibliography of Internetworking Information," 42 p. (RFC 1175/FYI 3). * Malkin, G. & T. LaQuey Parker. (1993) "Internet Users' Glossary," 53 p. (RFC 1392/FYI 18). Getting Articles On-Line All the documents marked with an asterisk (*) in this bibliography are available on-line at no charge if you have access to the Internet. To find out more about accessing documents in introducing.the.internet, send electronic mail to: nis-info@nic.merit.edu, with the text: send access.guide. If you know how to use Anonymous FTP, you can get the Access Guide from one of several sites, including nic.merit.edu, nic.mr.net, ftp.nisc.sri.com, or ftp.hawaii.edu. Check the directory introducing.the.internet for the file titled access.guide. The Access Hoffman & Jackson [Page 3] RFC 1463 FYI--Short Bibliography May 1993 Guide includes information about obtaining documents through dial-up service using a modem for those who do not have direct Internet access. In addition to the listed publications, many network providers publish excellent user guides and newsletters which cover Internet topics. Contact your Internet network service provider for more information. A longer bibliography with more comprehensive references and abstracts, FYI 3, RFC 1175 is listed above for those who may need more detailed materials. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Ellen S. Hoffman Merit Network, Inc. 2901 Hubbard, Pod G Ann Arbor, MI 48109 Phone: (313) 936-3000 E-mail: ellen@merit.edu Lenore Jackson NASA Ames Research Center m/s 233-8 T-1191 Moffett Field, CA 94035 Phone: (415) 604-0455 E-mail: jackson@nsipo.arc.nasa.gov Hoffman & Jackson [Page 4]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab02014; 21 Sep 93 13:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02010; 21 Sep 93 13:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05450; 21 Sep 93 13:17 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12768; Tue, 21 Sep 93 08:42:25 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12761; Tue, 21 Sep 93 08:42:23 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07721; Tue, 21 Sep 93 08:42:54 -0700 Received: from LANSLIDE.HLS.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07756; Tue, 21 Sep 93 08:43:14 -0700 Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA28701; Tue, 21 Sep 93 08:41:24 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA12208; Tue, 21 Sep 93 08:27:15 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9309211527.AA12208@nms.hls.com> Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Date: Tue, 21 Sep 93 8:27:14 PDT In-Reply-To: <01H37RBAIM0I8Y7L3A@research.ptt.nl>; from "C.Hol@research.ptt.nl" at Sep 21, 93 3:35 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Hi, I just received the message below which you sent to the mailing-list. For your information, the Internet convention and ettiquette is that requests to subscribe, change address, and unsubscribe to a mailing-list should be sent the mailing-list's administrative address, which is obtained by appending "-request" to the username at the relevant address, e.g., to subscribe/change-address/unsubscribe from the snmp@psi.com list send to snmp-request@psi.com , or for the atm@hpl.hp.com list to atm-request@hpl.hp.com. Please remember this for the future to avoid bothering the whole list's readership with your administrative requests. Thanks, Keith. PS. I also append below the text of RFC 1463, just in case you a new user to the Internet. ------------ Date: Tue, 21 Sep 1993 15:35:37 +0200 From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37RBAIM0I8Y7L3A@research.ptt.nl> Organization: PTT Research, the Netherlands Please remove me from this alias. Kees Hol HOL@research.ptt.nl ------------ Network Working Group E. Hoffman Request for Comments: 1463 Merit Network, Inc. FYI: 19 L. Jackson NASA May 1993 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings for the Network Novice Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. Acknowledgments This document is based upon the work of the User Documents Working Group in the User Services Area of the Internet Engineering Task Force (IETF). Bibliography of Introductory Readings The following list includes a number of sources for learning about the Internet. If you have more questions about the Internet, the best source of information is your network service provider. For those interested in finding out about getting Internet connectivity, the books listed will help you locate a network service provider. * Items with an asterisk are available at no charge on-line on the Internet--see the final section for information on how to obtain these. Hoffman & Jackson [Page 1] RFC 1463 FYI--Short Bibliography May 1993 1a. Introductory Papers * Kehoe, Brendan P. (1992) "Zen and the Art of the Internet: A Beginner's Guide to the Internet," (first edition) 95 p. * Krol, E. and E. Hoffman. (1993) "What is the Internet?" 11 p. (FYI 20, RFC 1462). * Malkin, G. and A. Marine. (1992) "FYI on Questions and Answers: Answers to Commonly Asked 'New Internet User' Questions," 32 p. (FYI 4, RFC 1325). * LaQuey, Tracy with Jeanne C. Ryer. (1992) "The.Internet. Companion," 30 p. (on-line chapters from book published by Addison-Wesley) 1b. Introductory Books: Basic User Guides Kehoe, Brendan P. (1993) Zen and the Art of the Internet: A Beginner's Guide, (second edition) 112 p. Prentice Hall, Englewood Cliffs, NJ. Krol, Ed. (1992) The Whole Internet User's Guide and Catalog, 400 p. O'Reilly & Assoc., Inc. Sebastopol, CA. LaQuey, Tracy with Jeanne C. Ryer. (1992) The Internet Companion: A Beginner's Guide to Global Networking, 208 p. Addison-Wesley, Reading, MA. 1c. Introductory Books: Connection Starters SRI International. (1992) Internet: Getting Started, 318 p. SRI International, 333 Ravenswood Ave., Rm. EJ291, Menlo Park, CA 94025. 2. Internet services and resources * Martin, J. (1993) "There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places," 39 p. (RFC 1402/FYI 10). * Merit Network, Inc. (1992) "Cruise of the Internet," Merit Network Inc., Ann Arbor, MI. (Disk based tutorial available for Macintosh or Windows). Metz, Ray (1992) Directory of Directories on the Internet, 175 p. Meckler, Westport, CT. Hoffman & Jackson [Page 2] RFC 1463 FYI--Short Bibliography May 1993 * NSF Network Service Center. (nd) "Internet Resource Guide," NSF Network Service Center, Cambridge, MA. 3. Internet networks Frey, Donnalyn and Rick Adams. (1991) !%@:: A Directory of Electronic Mail Addressing and Networks, (second edition) 436 p. O'Reilly & Assoc. Inc. Sebastopol, CA. LaQuey, Tracy L. (1990) User's Directory of Computer Networks, 653 p. Digital Press, Bedford, MA. Quarterman, John S. (1990) The Matrix: Computer Networks and Conferencing Systems Worldwide, 746 p. Digital Press, Bedford, MA. 4. Introducing the Internet Protocols Comer, Douglas E. (1991) Internetworking With TCP/IP: Volume I, Principles, Protocols, and Architecture, (second edition). 547 p. Prentice Hall, Englewood Cliffs, NJ * Hedrick, Charles L. (1987) "Introduction to the Internet Protocols," 34 p. Rutgers University Computer Science Facilities Group, Piscataway, NJ. Lynch, Daniel C. & Marshall T. Rose (eds). (1993) The Internet System Handbook, 822 p. Addison-Wesley, Reading, MA. 6. Further Reading * Bowers, K. L. et al. (1990) "FYI on Where to Start: A Bibliography of Internetworking Information," 42 p. (RFC 1175/FYI 3). * Malkin, G. & T. LaQuey Parker. (1993) "Internet Users' Glossary," 53 p. (RFC 1392/FYI 18). Getting Articles On-Line All the documents marked with an asterisk (*) in this bibliography are available on-line at no charge if you have access to the Internet. To find out more about accessing documents in introducing.the.internet, send electronic mail to: nis-info@nic.merit.edu, with the text: send access.guide. If you know how to use Anonymous FTP, you can get the Access Guide from one of several sites, including nic.merit.edu, nic.mr.net, ftp.nisc.sri.com, or ftp.hawaii.edu. Check the directory introducing.the.internet for the file titled access.guide. The Access Hoffman & Jackson [Page 3] RFC 1463 FYI--Short Bibliography May 1993 Guide includes information about obtaining documents through dial-up service using a modem for those who do not have direct Internet access. In addition to the listed publications, many network providers publish excellent user guides and newsletters which cover Internet topics. Contact your Internet network service provider for more information. A longer bibliography with more comprehensive references and abstracts, FYI 3, RFC 1175 is listed above for those who may need more detailed materials. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Ellen S. Hoffman Merit Network, Inc. 2901 Hubbard, Pod G Ann Arbor, MI 48109 Phone: (313) 936-3000 E-mail: ellen@merit.edu Lenore Jackson NASA Ames Research Center m/s 233-8 T-1191 Moffett Field, CA 94035 Phone: (415) 604-0455 E-mail: jackson@nsipo.arc.nasa.gov Hoffman & Jackson [Page 4]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab02304; 21 Sep 93 13:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab02297; 21 Sep 93 13:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06185; 21 Sep 93 13:26 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07233; Tue, 21 Sep 93 10:06:13 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA07221; Tue, 21 Sep 93 10:06:09 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08514; Tue, 21 Sep 93 09:43:53 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08538; Tue, 21 Sep 93 09:44:12 -0700 Received: by inet-gw-2.pa.dec.com; id AA26260; Tue, 21 Sep 93 09:43:47 -0700 Received: by us3rmc.bb.dec.com; id AA06220; Tue, 21 Sep 93 09:43:27 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211643.AA06220@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:43:27 PDT Date: Tue, 21 Sep 93 09:43:27 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:43 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:54 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Re: please remove me from this alias ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Hi, I just received the message below which you sent to the mailing-list. For your information, the Internet convention and ettiquette is that requests to subscribe, change address, and unsubscribe to a mailing-list should be sent the mailing-list's administrative address, which is obtained by appending "-request" to the username at the relevant address, e.g., to subscribe/change-address/unsubscribe from the snmp@psi.com list send to snmp-request@psi.com , or for the atm@hpl.hp.com list to atm-request@hpl.hp.com. Please remember this for the future to avoid bothering the whole list's readership with your administrative requests. Thanks, Keith. PS. I also append below the text of RFC 1463, just in case you a new user to the Internet. ------------ Date: Tue, 21 Sep 1993 15:35:37 +0200 From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37RBAIM0I8Y7L3A@research.ptt.nl> Organization: PTT Research, the Netherlands Please remove me from this alias. Kees Hol HOL@research.ptt.nl ------------ Network Working Group E. Hoffman Request for Comments: 1463 Merit Network, Inc. FYI: 19 L. Jackson NASA May 1993 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings for the Network Novice Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. Acknowledgments This document is based upon the work of the User Documents Working Group in the User Services Area of the Internet Engineering Task Force (IETF). Bibliography of Introductory Readings The following list includes a number of sources for learning about the Internet. If you have more questions about the Internet, the best source of information is your network service provider. For those interested in finding out about getting Internet connectivity, the books listed will help you locate a network service provider. * Items with an asterisk are available at no charge on-line on the Internet--see the final section for information on how to obtain these. Hoffman & Jackson [Page 1] RFC 1463 FYI--Short Bibliography May 1993 1a. Introductory Papers * Kehoe, Brendan P. (1992) "Zen and the Art of the Internet: A Beginner's Guide to the Internet," (first edition) 95 p. * Krol, E. and E. Hoffman. (1993) "What is the Internet?" 11 p. (FYI 20, RFC 1462). * Malkin, G. and A. Marine. (1992) "FYI on Questions and Answers: Answers to Commonly Asked 'New Internet User' Questions," 32 p. (FYI 4, RFC 1325). * LaQuey, Tracy with Jeanne C. Ryer. (1992) "The.Internet. Companion," 30 p. (on-line chapters from book published by Addison-Wesley) 1b. Introductory Books: Basic User Guides Kehoe, Brendan P. (1993) Zen and the Art of the Internet: A Beginner's Guide, (second edition) 112 p. Prentice Hall, Englewood Cliffs, NJ. Krol, Ed. (1992) The Whole Internet User's Guide and Catalog, 400 p. O'Reilly & Assoc., Inc. Sebastopol, CA. LaQuey, Tracy with Jeanne C. Ryer. (1992) The Internet Companion: A Beginner's Guide to Global Networking, 208 p. Addison-Wesley, Reading, MA. 1c. Introductory Books: Connection Starters SRI International. (1992) Internet: Getting Started, 318 p. SRI International, 333 Ravenswood Ave., Rm. EJ291, Menlo Park, CA 94025. 2. Internet services and resources * Martin, J. (1993) "There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places," 39 p. (RFC 1402/FYI 10). * Merit Network, Inc. (1992) "Cruise of the Internet," Merit Network Inc., Ann Arbor, MI. (Disk based tutorial available for Macintosh or Windows). Metz, Ray (1992) Directory of Directories on the Internet, 175 p. Meckler, Westport, CT. Hoffman & Jackson [Page 2] RFC 1463 FYI--Short Bibliography May 1993 * NSF Network Service Center. (nd) "Internet Resource Guide," NSF Network Service Center, Cambridge, MA. 3. Internet networks Frey, Donnalyn and Rick Adams. (1991) !%@:: A Directory of Electronic Mail Addressing and Networks, (second edition) 436 p. O'Reilly & Assoc. Inc. Sebastopol, CA. LaQuey, Tracy L. (1990) User's Directory of Computer Networks, 653 p. Digital Press, Bedford, MA. Quarterman, John S. (1990) The Matrix: Computer Networks and Conferencing Systems Worldwide, 746 p. Digital Press, Bedford, MA. 4. Introducing the Internet Protocols Comer, Douglas E. (1991) Internetworking With TCP/IP: Volume I, Principles, Protocols, and Architecture, (second edition). 547 p. Prentice Hall, Englewood Cliffs, NJ * Hedrick, Charles L. (1987) "Introduction to the Internet Protocols," 34 p. Rutgers University Computer Science Facilities Group, Piscataway, NJ. Lynch, Daniel C. & Marshall T. Rose (eds). (1993) The Internet System Handbook, 822 p. Addison-Wesley, Reading, MA. 6. Further Reading * Bowers, K. L. et al. (1990) "FYI on Where to Start: A Bibliography of Internetworking Information," 42 p. (RFC 1175/FYI 3). * Malkin, G. & T. LaQuey Parker. (1993) "Internet Users' Glossary," 53 p. (RFC 1392/FYI 18). Getting Articles On-Line All the documents marked with an asterisk (*) in this bibliography are available on-line at no charge if you have access to the Internet. To find out more about accessing documents in introducing.the.internet, send electronic mail to: nis-info@nic.merit.edu, with the text: send access.guide. If you know how to use Anonymous FTP, you can get the Access Guide from one of several sites, including nic.merit.edu, nic.mr.net, ftp.nisc.sri.com, or ftp.hawaii.edu. Check the directory introducing.the.internet for the file titled access.guide. The Access Hoffman & Jackson [Page 3] RFC 1463 FYI--Short Bibliography May 1993 Guide includes information about obtaining documents through dial-up service using a modem for those who do not have direct Internet access. In addition to the listed publications, many network providers publish excellent user guides and newsletters which cover Internet topics. Contact your Internet network service provider for more information. A longer bibliography with more comprehensive references and abstracts, FYI 3, RFC 1175 is listed above for those who may need more detailed materials. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Ellen S. Hoffman Merit Network, Inc. 2901 Hubbard, Pod G Ann Arbor, MI 48109 Phone: (313) 936-3000 E-mail: ellen@merit.edu Lenore Jackson NASA Ames Research Center m/s 233-8 T-1191 Moffett Field, CA 94035 Phone: (415) 604-0455 E-mail: jackson@nsipo.arc.nasa.gov Hoffman & Jackson [Page 4] % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA29954; Tue, 21 Sep 93 08:53:58 -0700 % Received: by inet-gw-1.pa.dec.com; id AA28162; Tue, 21 Sep 93 08:53:52 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12768; Tue, 21 Sep 93 08:42:25 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12761; Tue, 21 Sep 93 08:42:23 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07721; Tue, 21 Sep 93 08:42:54 -070 % Received: from LANSLIDE.HLS.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07756; Tue, 21 Sep 93 08:43:14 -070 % Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA28701; Tue, 21 Sep 93 08:41:24 PD % Received: by nms.hls.com (4.1/SMI-4.1) id AA12208; Tue, 21 Sep 93 08:27:15 PD % From: kzm@hls.com (Keith McCloghrie) % Message-Id: <9309211527.AA12208@nms.hls.com> % Subject: Re: please remove me from this alias % To: atm@hplms2.hpl.hp.com % Date: Tue, 21 Sep 93 8:27:14 PDT % In-Reply-To: <01H37RBAIM0I8Y7L3A@research.ptt.nl>; from "C.Hol@research.ptt.nl" at Sep 21, 93 3:35 pm % Organization: Hughes LAN Systems % X-Mailer: ELM [version 2.2 PL0] % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA06145; Tue, 21 Sep 93 09:43:09 -0700 % Received: by inet-gw-1.pa.dec.com; id AA02061; Tue, 21 Sep 93 09:42:56 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27286; Tue, 21 Sep 93 09:29:15 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16337; Tue, 21 Sep 93 08:57:53 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07984; Tue, 21 Sep 93 08:58:24 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07908; Tue, 21 Sep 93 08:58:45 -070 % Received: by inet-gw-2.pa.dec.com; id AA23145; Tue, 21 Sep 93 08:58:21 -0700 % Received: by us3rmc.bb.dec.com; id AA00401; Tue, 21 Sep 93 08:55:16 -0700 % From: manage::nmail-daemon % Message-Id: <9309211555.AA00401@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:55:17 PDT % Date: Tue, 21 Sep 93 08:55:17 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab03314; 21 Sep 93 13:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab03310; 21 Sep 93 13:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07748; 21 Sep 93 13:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA22464; Tue, 21 Sep 93 09:19:27 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18064; Tue, 21 Sep 93 09:05:54 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08047; Tue, 21 Sep 93 09:06:21 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08000; Tue, 21 Sep 93 09:06:12 -0700 Received: by inet-gw-2.pa.dec.com; id AA23533; Tue, 21 Sep 93 09:05:48 -0700 Received: by us3rmc.bb.dec.com; id AA02423; Tue, 21 Sep 93 09:03:27 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211603.AA02423@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:04:18 PDT Date: Tue, 21 Sep 93 09:05:06 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:02 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:10 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com,laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com,rcallon@wellfleet.com Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA25432; Tue, 21 Sep 93 08:10:09 -0700 % Received: by inet-gw-1.pa.dec.com; id AA22750; Mon, 20 Sep 93 22:43:58 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23222; Mon, 20 Sep 93 22:32:31 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17824; Mon, 20 Sep 93 21:27:14 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04888; Mon, 20 Sep 93 21:27:36 -070 % Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05596; Mon, 20 Sep 93 21:27:55 -070 % Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -070 % Date: Mon, 20 Sep 1993 21:25:57 -0700 % Message-Id: <199309210425.AA09395@lager.cisco.com> % X-Sender: forster@lager.cisco.com % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com % From: forster@cisco.com (Jim Forster) % Subject: Re: Classical Draft Status % Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA02190; Tue, 21 Sep 93 09:02:29 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25486; Tue, 21 Sep 93 08:25:22 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01894; Tue, 21 Sep 93 08:11:15 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01877; Tue, 21 Sep 93 08:11:14 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07339; Tue, 21 Sep 93 08:11:45 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07433; Tue, 21 Sep 93 08:12:05 -070 % Received: by inet-gw-2.pa.dec.com; id AA20196; Tue, 21 Sep 93 08:11:41 -0700 % Received: by us3rmc.bb.dec.com; id AA25703; Tue, 21 Sep 93 08:11:11 -0700 % From: manage::nmail-daemon % Message-Id: <9309211511.AA25703@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:11:12 PDT % Date: Tue, 21 Sep 93 08:11:12 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04369; 21 Sep 93 14:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04365; 21 Sep 93 14:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10226; 21 Sep 93 14:12 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27286; Tue, 21 Sep 93 09:29:15 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16337; Tue, 21 Sep 93 08:57:53 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07984; Tue, 21 Sep 93 08:58:24 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07908; Tue, 21 Sep 93 08:58:45 -0700 Received: by inet-gw-2.pa.dec.com; id AA23145; Tue, 21 Sep 93 08:58:21 -0700 Received: by us3rmc.bb.dec.com; id AA00401; Tue, 21 Sep 93 08:55:16 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211555.AA00401@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:55:17 PDT Date: Tue, 21 Sep 93 08:55:17 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:54 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Re: please remove me from this alias ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Hi, I just received the message below which you sent to the mailing-list. For your information, the Internet convention and ettiquette is that requests to subscribe, change address, and unsubscribe to a mailing-list should be sent the mailing-list's administrative address, which is obtained by appending "-request" to the username at the relevant address, e.g., to subscribe/change-address/unsubscribe from the snmp@psi.com list send to snmp-request@psi.com , or for the atm@hpl.hp.com list to atm-request@hpl.hp.com. Please remember this for the future to avoid bothering the whole list's readership with your administrative requests. Thanks, Keith. PS. I also append below the text of RFC 1463, just in case you a new user to the Internet. ------------ Date: Tue, 21 Sep 1993 15:35:37 +0200 From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37RBAIM0I8Y7L3A@research.ptt.nl> Organization: PTT Research, the Netherlands Please remove me from this alias. Kees Hol HOL@research.ptt.nl ------------ Network Working Group E. Hoffman Request for Comments: 1463 Merit Network, Inc. FYI: 19 L. Jackson NASA May 1993 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings for the Network Novice Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. Acknowledgments This document is based upon the work of the User Documents Working Group in the User Services Area of the Internet Engineering Task Force (IETF). Bibliography of Introductory Readings The following list includes a number of sources for learning about the Internet. If you have more questions about the Internet, the best source of information is your network service provider. For those interested in finding out about getting Internet connectivity, the books listed will help you locate a network service provider. * Items with an asterisk are available at no charge on-line on the Internet--see the final section for information on how to obtain these. Hoffman & Jackson [Page 1] RFC 1463 FYI--Short Bibliography May 1993 1a. Introductory Papers * Kehoe, Brendan P. (1992) "Zen and the Art of the Internet: A Beginner's Guide to the Internet," (first edition) 95 p. * Krol, E. and E. Hoffman. (1993) "What is the Internet?" 11 p. (FYI 20, RFC 1462). * Malkin, G. and A. Marine. (1992) "FYI on Questions and Answers: Answers to Commonly Asked 'New Internet User' Questions," 32 p. (FYI 4, RFC 1325). * LaQuey, Tracy with Jeanne C. Ryer. (1992) "The.Internet. Companion," 30 p. (on-line chapters from book published by Addison-Wesley) 1b. Introductory Books: Basic User Guides Kehoe, Brendan P. (1993) Zen and the Art of the Internet: A Beginner's Guide, (second edition) 112 p. Prentice Hall, Englewood Cliffs, NJ. Krol, Ed. (1992) The Whole Internet User's Guide and Catalog, 400 p. O'Reilly & Assoc., Inc. Sebastopol, CA. LaQuey, Tracy with Jeanne C. Ryer. (1992) The Internet Companion: A Beginner's Guide to Global Networking, 208 p. Addison-Wesley, Reading, MA. 1c. Introductory Books: Connection Starters SRI International. (1992) Internet: Getting Started, 318 p. SRI International, 333 Ravenswood Ave., Rm. EJ291, Menlo Park, CA 94025. 2. Internet services and resources * Martin, J. (1993) "There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places," 39 p. (RFC 1402/FYI 10). * Merit Network, Inc. (1992) "Cruise of the Internet," Merit Network Inc., Ann Arbor, MI. (Disk based tutorial available for Macintosh or Windows). Metz, Ray (1992) Directory of Directories on the Internet, 175 p. Meckler, Westport, CT. Hoffman & Jackson [Page 2] RFC 1463 FYI--Short Bibliography May 1993 * NSF Network Service Center. (nd) "Internet Resource Guide," NSF Network Service Center, Cambridge, MA. 3. Internet networks Frey, Donnalyn and Rick Adams. (1991) !%@:: A Directory of Electronic Mail Addressing and Networks, (second edition) 436 p. O'Reilly & Assoc. Inc. Sebastopol, CA. LaQuey, Tracy L. (1990) User's Directory of Computer Networks, 653 p. Digital Press, Bedford, MA. Quarterman, John S. (1990) The Matrix: Computer Networks and Conferencing Systems Worldwide, 746 p. Digital Press, Bedford, MA. 4. Introducing the Internet Protocols Comer, Douglas E. (1991) Internetworking With TCP/IP: Volume I, Principles, Protocols, and Architecture, (second edition). 547 p. Prentice Hall, Englewood Cliffs, NJ * Hedrick, Charles L. (1987) "Introduction to the Internet Protocols," 34 p. Rutgers University Computer Science Facilities Group, Piscataway, NJ. Lynch, Daniel C. & Marshall T. Rose (eds). (1993) The Internet System Handbook, 822 p. Addison-Wesley, Reading, MA. 6. Further Reading * Bowers, K. L. et al. (1990) "FYI on Where to Start: A Bibliography of Internetworking Information," 42 p. (RFC 1175/FYI 3). * Malkin, G. & T. LaQuey Parker. (1993) "Internet Users' Glossary," 53 p. (RFC 1392/FYI 18). Getting Articles On-Line All the documents marked with an asterisk (*) in this bibliography are available on-line at no charge if you have access to the Internet. To find out more about accessing documents in introducing.the.internet, send electronic mail to: nis-info@nic.merit.edu, with the text: send access.guide. If you know how to use Anonymous FTP, you can get the Access Guide from one of several sites, including nic.merit.edu, nic.mr.net, ftp.nisc.sri.com, or ftp.hawaii.edu. Check the directory introducing.the.internet for the file titled access.guide. The Access Hoffman & Jackson [Page 3] RFC 1463 FYI--Short Bibliography May 1993 Guide includes information about obtaining documents through dial-up service using a modem for those who do not have direct Internet access. In addition to the listed publications, many network providers publish excellent user guides and newsletters which cover Internet topics. Contact your Internet network service provider for more information. A longer bibliography with more comprehensive references and abstracts, FYI 3, RFC 1175 is listed above for those who may need more detailed materials. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Ellen S. Hoffman Merit Network, Inc. 2901 Hubbard, Pod G Ann Arbor, MI 48109 Phone: (313) 936-3000 E-mail: ellen@merit.edu Lenore Jackson NASA Ames Research Center m/s 233-8 T-1191 Moffett Field, CA 94035 Phone: (415) 604-0455 E-mail: jackson@nsipo.arc.nasa.gov Hoffman & Jackson [Page 4] % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA29954; Tue, 21 Sep 93 08:53:58 -0700 % Received: by inet-gw-1.pa.dec.com; id AA28162; Tue, 21 Sep 93 08:53:52 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12768; Tue, 21 Sep 93 08:42:25 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12761; Tue, 21 Sep 93 08:42:23 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07721; Tue, 21 Sep 93 08:42:54 -070 % Received: from LANSLIDE.HLS.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07756; Tue, 21 Sep 93 08:43:14 -070 % Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA28701; Tue, 21 Sep 93 08:41:24 PD % Received: by nms.hls.com (4.1/SMI-4.1) id AA12208; Tue, 21 Sep 93 08:27:15 PD % From: kzm@hls.com (Keith McCloghrie) % Message-Id: <9309211527.AA12208@nms.hls.com> % Subject: Re: please remove me from this alias % To: atm@hplms2.hpl.hp.com % Date: Tue, 21 Sep 93 8:27:14 PDT % In-Reply-To: <01H37RBAIM0I8Y7L3A@research.ptt.nl>; from "C.Hol@research.ptt.nl" at Sep 21, 93 3:35 pm % Organization: Hughes LAN Systems % X-Mailer: ELM [version 2.2 PL0]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04549; 21 Sep 93 14:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04545; 21 Sep 93 14:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11025; 21 Sep 93 14:20 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA20082; Tue, 21 Sep 93 09:16:12 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20060; Tue, 21 Sep 93 09:16:09 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08140; Tue, 21 Sep 93 09:16:40 -0700 Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08115; Tue, 21 Sep 93 09:17:00 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA00984; Tue, 21 Sep 93 11:15:04 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA25526; Tue, 21 Sep 93 11:15:12 -0500 Date: Tue, 21 Sep 93 11:15:12 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309211615.AA25526@uh.msc.edu> To: laubach@matmos.hpl.hp.com Subject: More VC Management Cc: atm@hplms2.hpl.hp.com In a PVC-only environment, does each host require n**2/2 VCs? Likewise, does every host need to be reconfigured (with an additional VC) when a new host is added to the network? Or, perhaps, should a router transport packets between hosts within an LIS which do not have a PVC between them? -tjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04847; 21 Sep 93 14:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04843; 21 Sep 93 14:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14238; 21 Sep 93 14:37 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10815; Tue, 21 Sep 93 10:21:32 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00566; Tue, 21 Sep 93 09:35:59 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08337; Tue, 21 Sep 93 09:36:30 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08367; Tue, 21 Sep 93 09:36:52 -0700 Received: by inet-gw-2.pa.dec.com; id AA25769; Tue, 21 Sep 93 09:36:28 -0700 Received: by us3rmc.bb.dec.com; id AA04298; Tue, 21 Sep 93 09:36:18 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211636.AA04298@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:36:20 PDT Date: Tue, 21 Sep 93 09:36:20 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:36 From: US3RMC::"atm@hpl.hp.com" To: laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com Subj: More VC Management ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: In a PVC-only environment, does each host require n**2/2 VCs? Likewise, does every host need to be reconfigured (with an additional VC) when a new host is added to the network? Or, perhaps, should a router transport packets between hosts within an LIS which do not have a PVC between them? -tjs % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA04226; Tue, 21 Sep 93 09:36:01 -0700 % Received: by inet-gw-1.pa.dec.com; id AA00595; Tue, 21 Sep 93 09:25:43 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA20082; Tue, 21 Sep 93 09:16:12 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20060; Tue, 21 Sep 93 09:16:09 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08140; Tue, 21 Sep 93 09:16:40 -070 % Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08115; Tue, 21 Sep 93 09:17:00 -070 % Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA00984; Tue, 21 Sep 93 11:15:04 -050 % Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA25526; Tue, 21 Sep 93 11:15:12 -050 % Date: Tue, 21 Sep 93 11:15:12 -0500 % From: tjs@msc.edu (Tim Salo) % Message-Id: <9309211615.AA25526@uh.msc.edu> % To: laubach@matmos.hpl.hp.com % Subject: More VC Management % Cc: atm@hplms2.hpl.hp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05070; 21 Sep 93 14:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05064; 21 Sep 93 14:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14721; 21 Sep 93 14:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14386; Tue, 21 Sep 93 10:31:06 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14372; Tue, 21 Sep 93 10:31:05 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08381; Tue, 21 Sep 93 09:37:37 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08413; Tue, 21 Sep 93 09:37:58 -0700 Received: by inet-gw-2.pa.dec.com; id AA25867; Tue, 21 Sep 93 09:37:34 -0700 Received: by us3rmc.bb.dec.com; id AA04607; Tue, 21 Sep 93 09:37:24 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211637.AA04607@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:37:25 PDT Date: Tue, 21 Sep 93 09:37:25 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:37 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:15 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com,laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com,rcallon@wellfleet.com Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA26751; Tue, 21 Sep 93 08:15:12 -0700 % Received: by inet-gw-1.pa.dec.com; id AA22374; Mon, 20 Sep 93 22:38:51 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA22107; Mon, 20 Sep 93 22:30:01 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17702; Mon, 20 Sep 93 21:27:00 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04885; Mon, 20 Sep 93 21:27:27 -070 % Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05592; Mon, 20 Sep 93 21:27:48 -070 % Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -070 % Date: Mon, 20 Sep 1993 21:25:57 -0700 % Message-Id: <199309210425.AA09395@lager.cisco.com> % X-Sender: forster@lager.cisco.com % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com % From: forster@cisco.com (Jim Forster) % Subject: Re: Classical Draft Status % Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA04562; Tue, 21 Sep 93 09:37:14 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25649; Tue, 21 Sep 93 08:27:22 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05490; Tue, 21 Sep 93 08:15:47 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05468; Tue, 21 Sep 93 08:15:46 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07395; Tue, 21 Sep 93 08:16:17 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07471; Tue, 21 Sep 93 08:16:38 -070 % Received: by inet-gw-2.pa.dec.com; id AA20576; Tue, 21 Sep 93 08:16:14 -0700 % Received: by us3rmc.bb.dec.com; id AA26841; Tue, 21 Sep 93 08:15:31 -0700 % From: manage::nmail-daemon % Message-Id: <9309211515.AA26841@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:15:42 PDT % Date: Tue, 21 Sep 93 08:15:42 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05370; 21 Sep 93 14:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05366; 21 Sep 93 14:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15618; 21 Sep 93 14:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11839; Tue, 21 Sep 93 10:25:07 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA04639; Tue, 21 Sep 93 09:58:59 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08387; Tue, 21 Sep 93 09:38:27 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08420; Tue, 21 Sep 93 09:38:48 -0700 Received: by inet-gw-2.pa.dec.com; id AA25920; Tue, 21 Sep 93 09:38:24 -0700 Received: by us3rmc.bb.dec.com; id AA04826; Tue, 21 Sep 93 09:38:15 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211638.AA04826@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:38:16 PDT Date: Tue, 21 Sep 93 09:38:16 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:38 From: US3RMC::"atm@hpl.hp.com" To: laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com Subj: Re: Classical IP and ARP over ATM ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: > To: cbasso@vnet.IBM.COM > Subject: Re: Classical IP and ARP over ATM > Date: Sun, 19 Sep 1993 11:40:02 -0700 > From: Mark Laubach > > From: cbasso@vnet.IBM.COM > Subject: Classical IP and ARP over ATM > [...] > 1)There is no discussions about the timers to cancel an ATM connection > when no traffic during a while (equivalent to RFC 877 for X25) > [...] > > The opinions I viewed on this is that timers for IP over X.25 were > needed when someone was paying for an X.25 connection. I know there is > research being done now on timers for IP over ATM and we don't have > experience with public ATM network taraffing. What I'd like to do is > make this a discussion item at the Houston meeting. I believe there was a fair amount of VC management code in the DDN IP/X.25 implementations. There were, as I recall, several reasons for this, (some of which might be true): o Virtual circuits ocassionally went away (from the host perspective). The network could support only a certain number of virtual circuits, and so dropped virtual circuits when it needed more. o The hosts were limited to a certain number of virtual circuits, and so sometimes needed to drop one virtual circuit to establish another. There may be a need for similar virtual channel management code in an ATM environment. For example, hosts implementations might support only a certain number of simultaneous virtual channels or some links may have only a certain number of VCs. -tjs % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA04779; Tue, 21 Sep 93 09:38:02 -0700 % Received: by inet-gw-1.pa.dec.com; id AA00605; Tue, 21 Sep 93 09:25:54 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19440; Tue, 21 Sep 93 09:13:46 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19433; Tue, 21 Sep 93 09:13:46 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08112; Tue, 21 Sep 93 09:14:18 -070 % Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08093; Tue, 21 Sep 93 09:14:39 -070 % Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA00831; Tue, 21 Sep 93 11:12:43 -050 % Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA25428; Tue, 21 Sep 93 11:12:47 -050 % Date: Tue, 21 Sep 93 11:12:47 -0500 % From: tjs@msc.edu (Tim Salo) % Message-Id: <9309211612.AA25428@uh.msc.edu> % To: laubach@matmos.hpl.hp.com % Subject: Re: Classical IP and ARP over ATM % Cc: atm@hplms2.hpl.hp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06070; 21 Sep 93 15:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06063; 21 Sep 93 15:16 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19393; 21 Sep 93 15:16 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19194; Tue, 21 Sep 93 10:55:25 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19187; Tue, 21 Sep 93 10:55:24 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA09178; Tue, 21 Sep 93 10:33:34 -0700 Received: from alpha.Xerox.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA09195; Tue, 21 Sep 93 10:33:56 -0700 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <11954(10)>; Tue, 21 Sep 1993 10:31:17 PDT Received: by reynaldo.parc.xerox.com id <25545>; Tue, 21 Sep 1993 10:31:14 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Berry Kercheval To: atm@hplms2.hpl.hp.com Subject: More VC Management In-Reply-To: <9309211615.AA25526@uh.msc.edu> References: <9309211615.AA25526@uh.msc.edu> Message-Id: <93Sep21.103114pdt.25545@reynaldo.parc.xerox.com> Date: Tue, 21 Sep 1993 10:30:59 PDT Where do you get n**2/2? Each host only needs N-1 PVCs -- N if you want a loopback.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06667; 21 Sep 93 15:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06663; 21 Sep 93 15:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20989; 21 Sep 93 15:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24071; Tue, 21 Sep 93 11:22:22 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13498; Tue, 21 Sep 93 10:28:54 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08355; Tue, 21 Sep 93 09:37:18 -0700 Received: from dnlts0.research.ptt.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08394; Tue, 21 Sep 93 09:37:36 -0700 Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H37XLBD4NO8Y7HVO@research.ptt.nl>; Tue, 21 Sep 1993 18:34:51 +0200 Date: Tue, 21 Sep 1993 18:34:51 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37XLBD4NQ8Y7HVO@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: atm@hpl.hp.com X-Vms-To: IN%"atm@hpl.hp.com" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab06718; 21 Sep 93 15:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab06714; 21 Sep 93 15:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21103; 21 Sep 93 15:31 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA22829; Tue, 21 Sep 93 11:20:03 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13436; Tue, 21 Sep 93 10:28:52 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08351; Tue, 21 Sep 93 09:37:17 -0700 Received: from dnlts0.research.ptt.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08391; Tue, 21 Sep 93 09:37:36 -0700 Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H37XLH1JU88Y7HVO@research.ptt.nl>; Tue, 21 Sep 1993 18:34:58 +0200 Date: Tue, 21 Sep 1993 18:34:58 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: C.Hol@research.ptt.nl Subject: Re: please remove me from this alias To: atm@hplms2.hpl.hp.com Message-Id: <01H37XLH1JUA8Y7HVO@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: atm@hpl.hp.com X-Vms-To: IN%"atm@hpl.hp.com" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06854; 21 Sep 93 15:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06849; 21 Sep 93 15:33 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21201; 21 Sep 93 15:33 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA26470; Tue, 21 Sep 93 11:26:28 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26432; Tue, 21 Sep 93 11:26:27 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08794; Tue, 21 Sep 93 10:09:51 -0700 Received: from auspex-gw.auspex.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08832; Tue, 21 Sep 93 10:10:06 -0700 Received: from auspex.com (auspex.auspex.com) by auspex-gw.Auspex.COM (4.1/SMI-4.1) id AA03745; Tue, 21 Sep 93 10:08:22 PDT Received: from kiwi.auspex.com by auspex.com (4.1/SMI-4.1) id AA23384; Tue, 21 Sep 93 10:08:20 PDT Date: Tue, 21 Sep 93 10:08:20 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Janna Chang Message-Id: <9309211708.AA23384@auspex.com> To: atm@hplms2.hpl.hp.com Subject: Re: UNH/IOL ATM Interoperability Lab > > The University of New Hampshire's Interoperability Lab is announcing the > formation of the ATM Consortium. The initial meeting will be held on October 8, > at the Ilumni Center of UNH. This is an informational meeting, as well as a > charter membership meeting. Attendance does not obligate individuals or > organizations in any way. All interested parties should contact Ron Pashby > by calling (603)862-0204 or via email to pashby@unh.edu. If you are > interested, but are not available to attend, we would be happy to provide > you with further information and results of the meeting. Won't be able to attend the meeting. Would like to get a copy of info. thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07183; 21 Sep 93 15:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07178; 21 Sep 93 15:39 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21427; 21 Sep 93 15:39 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04751; Tue, 21 Sep 93 11:35:36 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03656; Tue, 21 Sep 93 09:54:28 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08629; Tue, 21 Sep 93 09:55:00 -0700 Received: from cannondale.arc.nasa.gov by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08675; Tue, 21 Sep 93 09:55:21 -0700 Received: Tue, 21 Sep 93 09:53:42 PDT by cannondale.arc.nasa.gov (4.1/1.2) Date: Tue, 21 Sep 93 09:53:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vishy Narayan Message-Id: <9309211653.AA02793@cannondale.arc.nasa.gov> To: atm@hplms2.hpl.hp.com, atm@hplms2.hpl.hp.com Subject: Re: Classical Draft Status Cc: curtis@ans.net Now if I could get only one copy of every msg rather than 3 or 4, that would be nice............... Vishy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07665; 21 Sep 93 15:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07661; 21 Sep 93 15:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21870; 21 Sep 93 15:46 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA29593; Tue, 21 Sep 93 11:29:49 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA29540; Tue, 21 Sep 93 11:29:48 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08011; Tue, 21 Sep 93 09:01:33 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07955; Tue, 21 Sep 93 09:01:53 -0700 Received: by inet-gw-2.pa.dec.com; id AA23300; Tue, 21 Sep 93 09:01:30 -0700 Received: by us3rmc.bb.dec.com; id AA01496; Tue, 21 Sep 93 09:00:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211600.AA01496@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:00:04 PDT Date: Tue, 21 Sep 93 09:00:04 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:59 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:07 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 10:52 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: UNH/IOL ATM Interoperability Lab ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: The University of New Hampshire's Interoperability Lab is announcing the formation of the ATM Consortium. The initial meeting will be held on October 8, at the Ilumni Center of UNH. This is an informational meeting, as well as a charter membership meeting. Attendance does not obligate individuals or organizations in any way. All interested parties should contact Ron Pashby by calling (603)862-0204 or via email to pashby@unh.edu. If you are interested, but are not available to attend, we would be happy to provide you with further information and results of the meeting. Please feel free to forward this message to anyone that you think might be interested in this information and CC to pashby@unh.edu. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA20680; Tue, 21 Sep 93 07:51:51 -0700 % Received: by inet-gw-1.pa.dec.com; id AA11726; Tue, 21 Sep 93 05:21:54 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10075; Tue, 21 Sep 93 04:58:28 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10068; Tue, 21 Sep 93 04:58:27 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06561; Tue, 21 Sep 93 04:58:58 -070 % Received: from sun4.iol.unh.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06576; Tue, 21 Sep 93 04:59:18 -070 % Received: by sun4.iol.unh.edu (4.1/SMI-4.1) id AA11444; Tue, 21 Sep 93 07:58:13 ED % Date: Tue, 21 Sep 93 07:58:13 EDT % From: rwp@iol.unh.edu (Ronald W. Pashby) % Message-Id: <9309211158.AA11444@sun4.iol.unh.edu> % To: atm@hplms2.hpl.hp.com % Subject: UNH/IOL ATM Interoperability Lab % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA24675; Tue, 21 Sep 93 08:07:21 -0700 % Received: by inet-gw-1.pa.dec.com; id AA23670; Tue, 21 Sep 93 08:06:32 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24420; Tue, 21 Sep 93 07:52:59 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24404; Tue, 21 Sep 93 07:52:57 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07155; Tue, 21 Sep 93 07:53:28 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07272; Tue, 21 Sep 93 07:53:29 -070 % Received: by inet-gw-2.pa.dec.com; id AA18907; Tue, 21 Sep 93 07:52:57 -0700 % Received: by us3rmc.bb.dec.com; id AA20921; Tue, 21 Sep 93 07:52:50 -0700 % From: manage::nmail-daemon % Message-Id: <9309211452.AA20921@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 07:52:50 PDT % Date: Tue, 21 Sep 93 07:52:50 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA01352; Tue, 21 Sep 93 08:59:33 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25204; Tue, 21 Sep 93 08:22:29 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00652; Tue, 21 Sep 93 08:09:02 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00634; Tue, 21 Sep 93 08:08:57 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07307; Tue, 21 Sep 93 08:09:28 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07400; Tue, 21 Sep 93 08:09:46 -070 % Received: by inet-gw-2.pa.dec.com; id AA20040; Tue, 21 Sep 93 08:09:16 -0700 % Received: by us3rmc.bb.dec.com; id AA24798; Tue, 21 Sep 93 08:07:49 -0700 % From: manage::nmail-daemon % Message-Id: <9309211507.AA24798@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:08:09 PDT % Date: Tue, 21 Sep 93 08:08:09 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07923; 21 Sep 93 15:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07919; 21 Sep 93 15:56 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22238; 21 Sep 93 15:56 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03125; Tue, 21 Sep 93 11:33:46 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14902; Tue, 21 Sep 93 10:31:29 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08393; Tue, 21 Sep 93 09:39:03 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08431; Tue, 21 Sep 93 09:39:23 -0700 Received: by inet-gw-2.pa.dec.com; id AA25962; Tue, 21 Sep 93 09:39:00 -0700 Received: by us3rmc.bb.dec.com; id AA05007; Tue, 21 Sep 93 09:38:51 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211638.AA05007@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:38:52 PDT Date: Tue, 21 Sep 93 09:38:52 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:38 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:12 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:00 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: please remove me from this alias ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Please remove me from this alias. George Kesidis % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA22664; Tue, 21 Sep 93 08:00:04 -0700 % Received: by inet-gw-1.pa.dec.com; id AA13236; Tue, 21 Sep 93 05:47:21 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13025; Tue, 21 Sep 93 05:35:50 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13014; Tue, 21 Sep 93 05:35:49 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06704; Tue, 21 Sep 93 05:36:19 -070 % Received: from cheetah.vlsi.uwaterloo.ca by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06642; Tue, 21 Sep 93 05:36:39 -070 % Received: by cheetah.vlsi.uwaterloo.ca id ; Tue, 21 Sep 93 08:34:59 -040 % Date: Tue, 21 Sep 93 08:34:59 -0400 % From: George Kesidis % Message-Id: <9309211234.AA25557@cheetah.vlsi.uwaterloo.ca> % To: atm@hplms2.hpl.hp.com % Subject: please remove me from this alias % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA25873; Tue, 21 Sep 93 08:12:02 -0700 % Received: by inet-gw-1.pa.dec.com; id AA24187; Tue, 21 Sep 93 08:11:38 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28001; Tue, 21 Sep 93 08:00:46 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27994; Tue, 21 Sep 93 08:00:45 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07241; Tue, 21 Sep 93 08:01:17 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07328; Tue, 21 Sep 93 08:01:38 -070 % Received: by inet-gw-2.pa.dec.com; id AA19446; Tue, 21 Sep 93 08:01:12 -0700 % Received: by us3rmc.bb.dec.com; id AA22990; Tue, 21 Sep 93 08:00:56 -0700 % From: manage::nmail-daemon % Message-Id: <9309211500.AA22990@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:00:57 PDT % Date: Tue, 21 Sep 93 08:00:57 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA04948; Tue, 21 Sep 93 09:38:40 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25492; Tue, 21 Sep 93 08:25:25 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02510; Tue, 21 Sep 93 08:12:11 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA02485; Tue, 21 Sep 93 08:12:10 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07360; Tue, 21 Sep 93 08:12:39 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07446; Tue, 21 Sep 93 08:12:53 -070 % Received: by inet-gw-2.pa.dec.com; id AA20328; Tue, 21 Sep 93 08:12:29 -0700 % Received: by us3rmc.bb.dec.com; id AA25967; Tue, 21 Sep 93 08:12:22 -0700 % From: manage::nmail-daemon % Message-Id: <9309211512.AA25967@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:12:23 PDT % Date: Tue, 21 Sep 93 08:12:23 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08295; 21 Sep 93 16:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08291; 21 Sep 93 16:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22800; 21 Sep 93 16:13 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07649; Tue, 21 Sep 93 11:41:51 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27009; Tue, 21 Sep 93 09:27:44 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07998; Tue, 21 Sep 93 09:00:34 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07935; Tue, 21 Sep 93 09:00:53 -0700 Received: by inet-gw-2.pa.dec.com; id AA23261; Tue, 21 Sep 93 09:00:28 -0700 Received: by us3rmc.bb.dec.com; id AA01366; Tue, 21 Sep 93 08:59:36 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211559.AA01366@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:59:49 PDT Date: Tue, 21 Sep 93 08:59:49 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:58 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:08 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com CC: atm@hplms2.hpl.hp.com,curtis@ans.net,mathis@pele.psc.edu Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: >Do you see any places where we might be painting ourselves into a >corner? I sure see some dangers. Given that ATM switches do congestion and error control on the cell level, and TCP senses path state at the packet (frame) level, the current architecture has changed the gain of the TCP window servo by more than three orders of magnitude. I suspect that we will discover that TCP over ATM on big pipes is unstable (In a control theory sense), and we will have to make some changes. One of the "easy" fixes would be to add forward error correction at the AAL layer..... Another would be to convince the switch vendors to do frame dropping.... (If you drop a low priority cell, drop all until the next high priority cell). On the other hand, until we have some field experience all arguments are pointless. --MM-- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA24932; Tue, 21 Sep 93 08:08:16 -0700 % Received: by inet-gw-1.pa.dec.com; id AA23806; Tue, 21 Sep 93 08:07:50 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24222; Tue, 21 Sep 93 07:50:58 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24213; Tue, 21 Sep 93 07:50:42 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07145; Tue, 21 Sep 93 07:49:38 -070 % Received: from pele.psc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07231; Tue, 21 Sep 93 07:48:55 -070 % Received: by pele.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA25006; Tue, 21 Sep 93 10:47:15 -040 % Message-Id: <9309211447.AA25006@pele.psc.edu> % To: atm@hplms2.hpl.hp.com % Cc: atm@hplms2.hpl.hp.com, curtis@ans.net, mathis@pele.psc.edu % Subject: Re: Classical Draft Status % In-Reply-To: Your message of "Tue, 21 Sep 93 09:52:26 CDT." <199309211352.AA52084@foo.ans.net> % Date: Tue, 21 Sep 93 10:47:14 -0400 % From: mathis@pele.psc.edu % X-Mts: smtp % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA01100; Tue, 21 Sep 93 08:58:26 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25335; Tue, 21 Sep 93 08:23:51 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01586; Tue, 21 Sep 93 08:10:49 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01570; Tue, 21 Sep 93 08:10:46 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07321; Tue, 21 Sep 93 08:11:17 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07415; Tue, 21 Sep 93 08:11:37 -070 % Received: by inet-gw-2.pa.dec.com; id AA20162; Tue, 21 Sep 93 08:11:02 -0700 % Received: by us3rmc.bb.dec.com; id AA25198; Tue, 21 Sep 93 08:09:19 -0700 % From: manage::nmail-daemon % Message-Id: <9309211509.AA25198@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:09:19 PDT % Date: Tue, 21 Sep 93 08:09:20 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08424; 21 Sep 93 16:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08420; 21 Sep 93 16:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22936; 21 Sep 93 16:18 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15661; Tue, 21 Sep 93 12:16:03 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15647; Tue, 21 Sep 93 12:16:01 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA10550; Tue, 21 Sep 93 12:16:34 -0700 Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA10660; Tue, 21 Sep 93 12:16:52 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA10347; Tue, 21 Sep 93 14:15:05 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA02995; Tue, 21 Sep 93 14:15:11 -0500 Date: Tue, 21 Sep 93 14:15:11 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309211915.AA02995@uh.msc.edu> To: atm@hplms2.hpl.hp.com Subject: Re: please remove me from this alias So, why send *your* message to the whole list... (See, you try to help a guy out and the rest of the list flames you...) Have fun, -tjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab09070; 21 Sep 93 16:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09066; 21 Sep 93 16:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24124; 21 Sep 93 16:43 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18919; Tue, 21 Sep 93 12:21:50 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01543; Tue, 21 Sep 93 09:40:09 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08426; Tue, 21 Sep 93 09:40:41 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08473; Tue, 21 Sep 93 09:41:02 -0700 Received: by inet-gw-2.pa.dec.com; id AA26069; Tue, 21 Sep 93 09:40:32 -0700 Received: by us3rmc.bb.dec.com; id AA05445; Tue, 21 Sep 93 09:40:23 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211640.AA05445@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:40:24 PDT Date: Tue, 21 Sep 93 09:40:24 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:40 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:02 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 11:10 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com,laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com,rcallon@wellfleet.com Subj: Re: Classical Draft Status ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: At 11:15 AM 9/20/93 -0400, Ross Callon wrote: >Mark; > >I apologize for not bringing this up sooner, but.... I have a concern >about publishing the Classical IP over ATM document as an RFC before >we understand the complete overall picture of how to run IP over ATM. Ross, It's going to take years before we understand this complete picture. There is value in getting a document out on how to do the simple stuff we pretty much do understand. Prompt publication of this document is the only hope to get the host implementations that are underway to implement the same scheme. I'm not saying we should rush it out with sloppy work, but I am arguing that we don't need to re-examine the scope of this work.Meanwhile, there's certainly plenty of work that can go into followup work. -- Jim % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA25432; Tue, 21 Sep 93 08:10:09 -0700 % Received: by inet-gw-1.pa.dec.com; id AA22750; Mon, 20 Sep 93 22:43:58 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23222; Mon, 20 Sep 93 22:32:31 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17824; Mon, 20 Sep 93 21:27:14 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA04888; Mon, 20 Sep 93 21:27:36 -070 % Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05596; Mon, 20 Sep 93 21:27:55 -070 % Received: from [198.92.30.175] (sl-chasm-01.cisco.com) by lager.cisco.com with SMTP id AA09395 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 21:25:57 -070 % Date: Mon, 20 Sep 1993 21:25:57 -0700 % Message-Id: <199309210425.AA09395@lager.cisco.com> % X-Sender: forster@lager.cisco.com % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % To: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com % From: forster@cisco.com (Jim Forster) % Subject: Re: Classical Draft Status % Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA02190; Tue, 21 Sep 93 09:02:29 -0700 % Received: by inet-gw-1.pa.dec.com; id AA25486; Tue, 21 Sep 93 08:25:22 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01894; Tue, 21 Sep 93 08:11:15 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01877; Tue, 21 Sep 93 08:11:14 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07339; Tue, 21 Sep 93 08:11:45 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07433; Tue, 21 Sep 93 08:12:05 -070 % Received: by inet-gw-2.pa.dec.com; id AA20196; Tue, 21 Sep 93 08:11:41 -0700 % Received: by us3rmc.bb.dec.com; id AA25703; Tue, 21 Sep 93 08:11:11 -0700 % From: manage::nmail-daemon % Message-Id: <9309211511.AA25703@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:11:12 PDT % Date: Tue, 21 Sep 93 08:11:12 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA05386; Tue, 21 Sep 93 09:40:12 -0700 % Received: by inet-gw-1.pa.dec.com; id AA00697; Tue, 21 Sep 93 09:27:08 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18071; Tue, 21 Sep 93 09:05:55 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18064; Tue, 21 Sep 93 09:05:54 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08047; Tue, 21 Sep 93 09:06:21 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08000; Tue, 21 Sep 93 09:06:12 -070 % Received: by inet-gw-2.pa.dec.com; id AA23533; Tue, 21 Sep 93 09:05:48 -0700 % Received: by us3rmc.bb.dec.com; id AA02423; Tue, 21 Sep 93 09:03:27 -0700 % From: manage::nmail-daemon % Message-Id: <9309211603.AA02423@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:04:18 PDT % Date: Tue, 21 Sep 93 09:05:06 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09101; 21 Sep 93 16:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09096; 21 Sep 93 16:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24154; 21 Sep 93 16:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24222; Tue, 21 Sep 93 07:50:58 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24213; Tue, 21 Sep 93 07:50:42 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07145; Tue, 21 Sep 93 07:49:38 -0700 Received: from pele.psc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07231; Tue, 21 Sep 93 07:48:55 -0700 Received: by pele.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA25006; Tue, 21 Sep 93 10:47:15 -0400 Message-Id: <9309211447.AA25006@pele.psc.edu> To: atm@hplms2.hpl.hp.com Cc: atm@hplms2.hpl.hp.com, curtis@ans.net, mathis@pele.psc.edu Subject: Re: Classical Draft Status In-Reply-To: Your message of "Tue, 21 Sep 93 09:52:26 CDT." <199309211352.AA52084@foo.ans.net> Date: Tue, 21 Sep 93 10:47:14 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mathis@pele.psc.edu X-Mts: smtp >Do you see any places where we might be painting ourselves into a >corner? I sure see some dangers. Given that ATM switches do congestion and error control on the cell level, and TCP senses path state at the packet (frame) level, the current architecture has changed the gain of the TCP window servo by more than three orders of magnitude. I suspect that we will discover that TCP over ATM on big pipes is unstable (In a control theory sense), and we will have to make some changes. One of the "easy" fixes would be to add forward error correction at the AAL layer..... Another would be to convince the switch vendors to do frame dropping.... (If you drop a low priority cell, drop all until the next high priority cell). On the other hand, until we have some field experience all arguments are pointless. --MM--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09119; 21 Sep 93 16:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09115; 21 Sep 93 16:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24205; 21 Sep 93 16:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA17557; Tue, 21 Sep 93 12:19:28 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05194; Tue, 21 Sep 93 09:59:53 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08397; Tue, 21 Sep 93 09:39:38 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08441; Tue, 21 Sep 93 09:39:59 -0700 Received: by inet-gw-2.pa.dec.com; id AA26013; Tue, 21 Sep 93 09:39:35 -0700 Received: by us3rmc.bb.dec.com; id AA05165; Tue, 21 Sep 93 09:39:24 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nmail-daemon@manage.enet.dec.com Message-Id: <9309211639.AA05165@us3rmc.bb.dec.com> Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 09:39:25 PDT Date: Tue, 21 Sep 93 09:39:25 PDT To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Report on failed mail Errors were detected when processing your mail message which was entered at 21-SEP-1993 12:39 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Report on failed mail ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Errors were detected when processing your mail message which was entered at 21-SEP-1993 10:56 From: US3RMC::"atm@hpl.hp.com" To: atm@hplms2.hpl.hp.com Subj: Re: UNH/IOL ATM Interoperability Lab ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: Dear Ron, I'm interested in the ATM Consortium as announced by your message, but I'm afraid I can not attend. Please provide me with further info and results. Thanks a lot in advance, -------------------------------------------------------------------------------- John Kroeze Internet: johnk@cs.kun.nl __ University of Nijmegen, UUCP:uunet!cs.kun.nl!johnk / \ Faculty of Computer Science, ----+----k P.O. 9010 Phone: +31 80 65 24 50 |O |\ 6500 GL Nijmegen, Room: A4010 /| | the Netherlands Fax: +31 80 55 34 50 |_| | -------------------------------------------------------------------------------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA21798; Tue, 21 Sep 93 07:56:32 -0700 % Received: by inet-gw-1.pa.dec.com; id AA16972; Tue, 21 Sep 93 06:44:38 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15698; Tue, 21 Sep 93 06:32:52 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15691; Tue, 21 Sep 93 06:32:52 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA06805; Tue, 21 Sep 93 06:33:23 -070 % Received: from zeus.cs.kun.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA06809; Tue, 21 Sep 93 06:33:41 -070 % Received: from zeus.cs.kun.nl by zeus.cs.kun.nl with SMTP id AA17277 (5.65c8/1.0 for atm@hpl.hp.com); Tue, 21 Sep 1993 15:31:59 +020 % Message-Id: <199309211331.AA17277@zeus.cs.kun.nl> % To: atm@hplms2.hpl.hp.com % Subject: Re: UNH/IOL ATM Interoperability Lab % In-Reply-To: Your message of "Tue, 21 Sep 93 07:58:13 EDT." <9309211158.AA11444@sun4.iol.unh.edu> % Date: Tue, 21 Sep 93 15:31:57 +0200 % From: johnk@cs.kun.nl % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us3rmc.bb.dec.com; id AA05092; Tue, 21 Sep 93 09:39:11 -0700 % Received: by inet-gw-1.pa.dec.com; id AA26628; Tue, 21 Sep 93 08:37:56 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA09172; Tue, 21 Sep 93 08:28:54 -0700 % Reply-To: atm@hpl.hp.com % Errors-To: atm-request@hpl.hp.com % Sender: atm-request@hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA09165; Tue, 21 Sep 93 08:28:53 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA07562; Tue, 21 Sep 93 08:29:24 -070 % Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA07623; Tue, 21 Sep 93 08:29:45 -070 % Received: by inet-gw-2.pa.dec.com; id AA21389; Tue, 21 Sep 93 08:28:07 -0700 % Received: by us3rmc.bb.dec.com; id AA27558; Tue, 21 Sep 93 08:28:01 -0700 % From: manage::nmail-daemon % Message-Id: <9309211528.AA27558@us3rmc.bb.dec.com> % Received: from manage.enet; by us3rmc.enet; Tue, 21 Sep 93 08:28:01 PDT % Date: Tue, 21 Sep 93 08:28:01 PDT % To: atm@hplms2.hpl.hp.com % Apparently-To: atm@hplms2.hpl.hp.com % Subject: Report on failed mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11265; 21 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11261; 21 Sep 93 18:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06145; 21 Sep 93 18:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19440; Tue, 21 Sep 93 09:13:46 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19433; Tue, 21 Sep 93 09:13:46 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08112; Tue, 21 Sep 93 09:14:18 -0700 Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08093; Tue, 21 Sep 93 09:14:39 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA00831; Tue, 21 Sep 93 11:12:43 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA25428; Tue, 21 Sep 93 11:12:47 -0500 Date: Tue, 21 Sep 93 11:12:47 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309211612.AA25428@uh.msc.edu> To: laubach@matmos.hpl.hp.com Subject: Re: Classical IP and ARP over ATM Cc: atm@hplms2.hpl.hp.com > To: cbasso@vnet.IBM.COM > Subject: Re: Classical IP and ARP over ATM > Date: Sun, 19 Sep 1993 11:40:02 -0700 > From: Mark Laubach > > From: cbasso@vnet.IBM.COM > Subject: Classical IP and ARP over ATM > [...] > 1)There is no discussions about the timers to cancel an ATM connection > when no traffic during a while (equivalent to RFC 877 for X25) > [...] > > The opinions I viewed on this is that timers for IP over X.25 were > needed when someone was paying for an X.25 connection. I know there is > research being done now on timers for IP over ATM and we don't have > experience with public ATM network taraffing. What I'd like to do is > make this a discussion item at the Houston meeting. I believe there was a fair amount of VC management code in the DDN IP/X.25 implementations. There were, as I recall, several reasons for this, (some of which might be true): o Virtual circuits ocassionally went away (from the host perspective). The network could support only a certain number of virtual circuits, and so dropped virtual circuits when it needed more. o The hosts were limited to a certain number of virtual circuits, and so sometimes needed to drop one virtual circuit to establish another. There may be a need for similar virtual channel management code in an ATM environment. For example, hosts implementations might support only a certain number of simultaneous virtual channels or some links may have only a certain number of VCs. -tjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11364; 21 Sep 93 18:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11359; 21 Sep 93 18:55 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06259; 21 Sep 93 18:55 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00225; Tue, 21 Sep 93 14:45:35 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05203; Tue, 21 Sep 93 13:26:30 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11190; Tue, 21 Sep 93 13:11:44 -0700 Received: from noc.msc.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA11440; Tue, 21 Sep 93 13:12:02 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA13091; Tue, 21 Sep 93 15:11:20 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA05725; Tue, 21 Sep 93 15:11:24 -0500 Date: Tue, 21 Sep 93 15:11:24 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309212011.AA05725@uh.msc.edu> To: atm@hplms2.hpl.hp.com Subject: Re: More VC Management Cc: kerch@parc.xerox.com > From: Berry Kercheval > To: atm@hplms2.hpl.hp.com > Subject: More VC Management > Date: Tue, 21 Sep 1993 10:30:59 PDT > > Where do you get n**2/2? Each host only needs N-1 PVCs -- N if you > want a loopback. You are, of course, correct. On the other hand, the number of PVCs which needs to be [manually] configured in each LIS is O(n**2). Dare I suggest, in my not necessarily so humble opinion, that this won't work? By the way, I believe that PVC-only environments are important. I believe that all of the publically-announced wide-area ATM services will initially offer only PVCs. I suspect that some of these networks will be large [IP subnets]. For example, some carrier may want to offer Internet service over their ATM service. I suspect that the carrier will not want to configure O(n**2) PVCs in the network. I also suspect that some customers will want to talk to other customers without paying for a PVC to that customer. Perhaps, the classical model should allow a router to transport packets between hosts within a LIS when a VC isn't available or can't be established. Tim Salo tjs@msc.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11382; 21 Sep 93 18:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11378; 21 Sep 93 18:55 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06311; 21 Sep 93 18:55 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03099; Tue, 21 Sep 93 14:49:13 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA25081; Tue, 21 Sep 93 12:41:10 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA10842; Tue, 21 Sep 93 12:41:43 -0700 Received: from c00805-247dan.eos.ncsu.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA11037; Tue, 21 Sep 93 12:42:04 -0700 Received: by c00805-247dan.eos.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA11590; Tue, 21 Sep 1993 15:40:15 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: sdrampal@eos.ncsu.edu Message-Id: <9309211940.AA11590@c00805-247dan.eos.ncsu.edu> To: atm@hplms2.hpl.hp.com Subject: Remove! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Sep 93 15:40:12 EDT Please remove me from this list. Thanx   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11539; 21 Sep 93 19:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11535; 21 Sep 93 19:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07005; 21 Sep 93 19:15 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04739; Tue, 21 Sep 93 14:51:39 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA28258; Tue, 21 Sep 93 13:01:05 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11081; Tue, 21 Sep 93 13:01:36 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA02521; Tue, 21 Sep 93 21:00:09 +0100 Received: from motgate.mot.com by hplb.hpl.hp.com; Tue, 21 Sep 93 20:50:45 +0100 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA29755; Tue, 21 Sep 1993 15:01:17 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA00678; Tue, 21 Sep 1993 15:01:06 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA27806 (5.65a+/IDA-1.4.2 for atm@hpl.hp.com); Tue, 21 Sep 93 16:00:58 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA08840 (5.65a+/IDA-1.4.2 for dan@merlin.dev.cdx.mot.com); Tue, 21 Sep 93 16:00:56 -0400 Message-Id: <9309212000.AA08840@dbg.dev.cdx.mot.com> To: atm@hplms2.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com Subject: Re: Classical Draft Status (long) In-Reply-To: Your message of "Sun, 19 Sep 93 11:33:22 PDT." <9309191833.AA28464@matmos.hpl.hp.com> Date: Tue, 21 Sep 93 16:00:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp The document has finally bubbled to the top of my 'to do' list (hey, I've got a full time job, too.... :-)) Major technical issues (probably require discussion, flames to /dev/null) - I hate to bring up ***anything*** that has to do with MTU or encapsulation (these discussions generate more heat than light) but: o AAL Parameters Negotiation (aka MTU negotiation) is part of the Q.93b and ATM Forum Signalling Protocol. I see no reason why two hosts should not be able to negotiate use of an MTU of other than the default. It is fair to say that if AAL Parameters Negotiation is used, the range between the requested maximum forward and backward CPCS-SDU size and the minimum acceptable maximum forward and backward CPCS-SDU size must include the default value. Thus, a host that wishes to negotiate and a host that always uses the default can communicate. Also, it needs to be specified that if this rule is not followed, the called host may clear the call. While we're on the subject, we should specify that for classical IP/AAL5, the forward and backward CPCS-SDU size are the same (or if people disagree, can be different; I don't care which) o B-LLI negotiation is part of Q.93b and the ATM Forum Signalling Spec. Again, if two hosts want to use the Null encapsulation (or, a bit later on, when we apply this material to Frame Relay SVCs) there is no technical reason why they should not be able to negotiate an encapsulation other than the default. It should be a requirement that when B-LLI negotiation is used, the LLC/SNAP encapsulation MUST be an alternative offered by the calling host. - The ATM address fields in the ARP packet should be decoupled from the structure of ATM addressing information elements in the Q.93b SETUP message. This is more than semantic nitpicking; what's happened is that the present structure requires the ARP server to know more than it should about ATM network logical topology and administrivia. For example, if an LIS includes a bunch of hosts connected to a private ATM network, which is connected to a public ATM network, to which additional hosts in the LIS are connected, the ARP server has to figure out based on the ATM address of the host making the ARP request which of Case 1, Case 2 or Case 3 apply. However, since hosts know by prior configuration whether the are connected to a Private UNI or a Public UNI, if the address fields in the ARP Reply are simply labelled as "Private ATM Endpoint Address (ATM-Forum NSAP encoded)" or "Public Network Interface Address (E.164-encoded)" the hosts could figure out which IEs to use in the SETUP message and what fields in the ARP Reply to populate them from. - The last paragraph on Page 12 is not accurate. FIrst, I see no reason for the limitation; it shouldn't matter to either the ARP server or the calling host what the ATM address of the called host is, as long as that host is reachable through a single ATM VC. Second, it's not the encoding that this paragraph seems to be concerned with at all, and there is relationship between MAC addresses and E.164 addresses in an ATM Endpoint address; they are orthogonal and used in different parts of the address structure. Is it intended that: the IDP be the same? the OUI? the RD? Area? Enforcing common values of these fields on the hosts in an LIS has different implications on the scope of an LIS, and should be done carefully. - Do we know that IP multicast over ATM multicast will be straightforward? - Well-know ATM addresses for ARP servers should NOT be done. However, we can ask the ATM Forum or TSS for a reserved VCI for the ARP server. ------------------- Wording changes: Global: Apostrophes are used to indicate the possessive, not the plural. This includes acronyms. Thus, proper usage is "PVCs", not "PVC's" > Readers are encouraged to review the ATM-FORUM and ITU-TS (CCITT) ^ Formerly CCITT > standards. ^ agreements and standards > Note: this memo is not meant to a reference with regard to the > operation of ATM, only to the way it defines the IP layer. I don't quite understand this sentence. Do you mean "this memo defines only the operation of IP over ATM, and is not meant to describe the operation of ATM networks"? > Initial deployment of ATM provides a LAN segment replacement for > ethernet networks and as wire-replacement for dedicated public > telecommunication lines between IP routers. In the former model, > local IP routers with one or more ATM interfaces will connect islands > of local ATM networks. ATM-FORUM compliant addressing will be used > within these local ATM networks. In the latter model, public ATM > networks will be used to connect IP routers, which in turn may or may > not connect to local ATM networks. Public networks will use ITU-TS > and ANSI standards for addressing in ATM. This text makes unnecessary and inaccurate judgements about regulatory matters. WAN connections are often made through private networks using either leased or private facilities. Since my employer is in the private WAN business, I have great concern with this. It also contains a number of other inaccuracies.Suggested replacement text: Initial deployment of ATM provides a LAN segment replacement for local area networks (e.g., Ethernets, Token Rings and FDDI) and as replacement for dedicated circuits or frame relay PVCs between IP routers. In the former case, local IP routers with one or more ATM interfaces will connect islands of ATM networks. In the latter case, public or private ATM Wide Area networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. ATM WANs and LANs may be interconnected. Private ATM networks (local or wide area) will use the private ATM address structure specified in section 5.3.1 of the ATM Forum UNI specification. This structure is modelled after the format of an OSI Network Service Access Point Address. A private ATM address uniquely identifies an ATM endpoint. Public networks will use either the address structure specified in ITU-T (formerly CCITT) Recommendation E.164 or the private network ATM address structure. An E.164 address uniquely identifies an interface to a public network. > signalling is performed via Q.93B implementations [7,9]. Note: > in commonplace use, the term "virtual circuit" is synonymous with > "virtual channel". I suggest deleting the last sentence. > an ATM cell header which carries the AAL type value, rather it is ^--------- > known by the VC end points via the call setup mechanism. For -------------------------------------------------------^ This is contradictory to the following sentence and redundant with the one afer. I suggest removing this clause. > packet format with a maximum size of 64K - 8 user data octets ^ (64k -1) eight-bit user data octets. > not yet a conformance requirement of the ATM-FORUM. ^--------------------------^ specified by ITU-TS or > o An ATM-FORUM local LAN hardware address (hereafter "ATM > address"), in the address resolution protocol context, may be > either an individual E.164 address, or an individual ATM-FORUM > NSAP, or an E.164 address and an ATM-FORUM NSAP [9]. ATM-FORUM > NSAP'S use the same basic format as U.S. GOSIP NSAP's [11]. > Note: ATM-FORUM addresses should not be construed as being U.S. > GOSIP NSAP's, they are not, the administration is different, > which fields get filled out are different, etc. Replacement text o An ATM address may comprise an ATM Forum ATM endpoint address, or an E.164 Public UNI address. In some cases, both an ATM endpoint address and an E.164 Public UNI address are needed by an ARP client to reach another host or router. Since the use of ATM endpoint addresses and E.164 public UNI addresses by ARP are analogous to the use of Ethernet addresses, the notion of 'hardware address' is extended to encompass ATM addresses in the context of ARP, even though ATM addresses need not have hardware significance. local LIS is provided via an IP router. This router is a station ^ is an ATM Endpoint o All stations within an LIS are accessed directly over the ATM o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP Can we use the term 'members' consistently instead of stations (or speak of hosts and routers?) 'stations' seems to be an IEEE 802 concept. > o ATM Hardware Address (atm$ha). The ATM address of the individual > IP station. Each host must be configured to accept connection > requests for this address. The last sentence is not necessary. Calls will not be delivered except to the called party. Also, if the ILMI is implemented, this need not be user configurable. > The ARP server accepts ATM-level connections (requests) from other ^------------------------------^ ATM calls/connections > At call setup and if the VC supports LLC/SNAP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > encapsulation, the ARP server will transmit to the originating ATM ^^^^^^^^^^^^^^ remove the underlined clause; it is unnecessary and confusing. > in its ARP table or a negative ARP reply (ARP_NAK). The ARP_NAK ^---^ . Otherwise, it will generate > entry/information about other IP stations. ARP clients must: ^ This means, as noted above, that ARP clients must be configured with the ATM address of the ARP server. > bit.7 (type) = 0 ATM-FORUM NSAP address number > = 1 E.164 address number (and other appearances in this section) remove all appearances of 'number' after 'address'. ----------------- Mark, sorry about the last minute laundry list, and even more sorry about the following request: can you revise the document again before kicking it out? Rgds, Dan Grossman   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12081; 21 Sep 93 20:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12077; 21 Sep 93 20:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09244; 21 Sep 93 20:17 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08366; Tue, 21 Sep 93 16:02:18 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08356; Tue, 21 Sep 93 16:02:17 -0700 Subject: re: atm mail loop To: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Tue, 21 Sep 93 16:02:15 -0700 Message-Id: <930921160215.6529@matmos.hpl.hp.com> My my, how embarassing. There are 1023 addresses on the atm working group list. The daemon at nmail-daemon@manage.enet.dec.com decided to send error messages back to atm@hpl.hp.com causing a cascading mail loop. My machine ran out of swap space last night. My machine ran out of file table space this morning. Tim Salo gave me a call to say "did you know that..." while I was in the middle of cycling power on the machine..... I've added 128Mbytes more swap to the system. I've doubled the file table size in the kernal. I've added 32 Mbytes more RAM to help the performance just a little bit. I've added mail loop detection into the list processing and I am explicitly catching mail from our friendly nmail-daemon above. I hope the list settles down. I am terribly sorry for the inconvenience this has cause. Gigabit rate errors will be no fun! Mark ps. there have been about 8 requests for removal and 2 for subscription.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12212; 21 Sep 93 20:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12208; 21 Sep 93 20:28 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09592; 21 Sep 93 20:28 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA20106; Tue, 21 Sep 93 10:59:33 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20099; Tue, 21 Sep 93 10:59:33 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA08348; Tue, 21 Sep 93 09:37:14 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA08379; Tue, 21 Sep 93 09:37:32 -0700 Received: by interlock.ans.net id AA10934 (InterLock SMTP Gateway 1.1 for atm@hplms2.hpl.hp.com); Tue, 21 Sep 1993 12:29:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Sep 1993 12:29:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Sep 1993 12:29:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309211633.AA51684@foo.ans.net> To: atm@hplms2.hpl.hp.com Cc: atm@hplms2.hpl.hp.com, curtis@ans.net, mathis@pele.psc.edu, curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Tue, 21 Sep 93 10:47:14 D.) <9309211447.AA25006@pele.psc.edu> Date: Tue, 21 Sep 93 12:33:43 -0500 Matt, You're bringing up a valid point about ATM, but I don't think it impacts this particular document. > >Do you see any places where we might be painting ourselves into a > >corner? > I sure see some dangers. > > Given that ATM switches do congestion and error control on the cell > level, and TCP senses path state at the packet (frame) level, the current > architecture has changed the gain of the TCP window servo by more than three > orders of magnitude. We all know about that. I missed the statement "from this time forward thou shalt ignore any ATM congestion indication" :-). Please strike it from the document. > I suspect that we will discover that TCP over ATM on big pipes is unstable > (In a control theory sense), and we will have to make some changes. One of the > "easy" fixes would be to add forward error correction at the AAL layer..... > Another would be to convince the switch vendors to do frame dropping.... > (If you drop a low priority cell, drop all until the next high priority cell). Either that or set up ATM CBR paths between routers and make ATM the next generation of leased line technology. But no one wants to see that happen. > On the other hand, until we have some field experience all arguments are > pointless. > > --MM-- Actually, if you look at the anemic cell buffers on most ATM switches intended for carrier use (not the smaller ATM LAN switches), ATM itself may be pointless (except as replacements for leased lines or until the switch vendors correct this). I think the issue of TCP congestion control effectiveness over ATM (or some workable ATM congestion control solution) is critical to ATM being successful, but the Classical ATM draft doesn't address this or prevent it from being addressed in the future. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13115; 21 Sep 93 21:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13106; 21 Sep 93 21:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12997; 21 Sep 93 21:58 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA20353; Tue, 21 Sep 93 12:23:41 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA20334; Tue, 21 Sep 93 12:23:40 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA10617; Tue, 21 Sep 93 12:24:13 -0700 Received: from relay2.UU.NET by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA10771; Tue, 21 Sep 93 12:24:28 -0700 Received: from samosa.agile.com (via [198.3.104.127]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03022; Tue, 21 Sep 93 15:22:43 -0400 Message-Id: <9309211922.AA03022@relay2.UU.NET> Received: by samosa.agile.com (1.37.109.4/16.2) id AA01847; Tue, 21 Sep 93 15:22:21 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Parker Subject: Re: Classical Draft Status To: atm@hplms2.hpl.hp.com Date: Tue, 21 Sep 93 15:22:21 EDT In-Reply-To: <9309211653.AA02793@cannondale.arc.nasa.gov>; from "Vishy Narayan" at Sep 21, 93 9:53 am Mailer: Elm [revision: 70.85] > > Now if I could get only one copy of every msg rather than > 3 or 4, that would be nice............... > > Vishy > Luddite! I see ATM as an enabeling technology for gigabyte mail loops. -- - jeff parker - Agile Networks   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01487; 22 Sep 93 5:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01482; 22 Sep 93 5:03 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04542; 22 Sep 93 5:03 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16186; Tue, 21 Sep 93 23:38:58 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16168; Tue, 21 Sep 93 23:38:57 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA12983; Tue, 21 Sep 93 15:35:13 -0700 Received: from lager.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA13162; Tue, 21 Sep 93 15:35:34 -0700 Received: from [131.108.61.60] (forster-mac.cisco.com) by lager.cisco.com with SMTP id AA16458 (5.67a/IDA-1.5 for ); Tue, 21 Sep 1993 15:33:50 -0700 Date: Tue, 21 Sep 1993 15:33:50 -0700 Message-Id: <199309212233.AA16458@lager.cisco.com> X-Sender: forster@lager.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tim Salo Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Forster Subject: Re: More VC Management Cc: atm@hplms2.hpl.hp.com, laubach@matmos.hpl.hp.com At 11:15 AM 9/21/93 -0500, Tim Salo wrote: >In a PVC-only environment, does each host require n**2/2 VCs? As previously mentioned, each host needs only N-1 VC's, but that does mean that there are N*(N-1) VC's in the net. >Likewise, does every host need to be reconfigured (with an additional VC) >when a new host is added to the network? Unfortunately, yes. The "Classical IP over ATM" deals only with the case that all host/routers can communicate directly with each other. > Or, perhaps, should a router transport packets between hosts within an > LIS which do not have a PVC between them? If you want to segement things like this, then you have multiple LIS's. Yes, PVC's are ugly. -- Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01737; 22 Sep 93 5:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01733; 22 Sep 93 5:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05708; 22 Sep 93 5:58 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11253; Wed, 22 Sep 93 00:11:19 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11243; Wed, 22 Sep 93 00:11:18 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA16309; Wed, 22 Sep 93 00:11:20 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA16695; Wed, 22 Sep 93 00:11:42 -0700 Received: by inet-gw-2.pa.dec.com; id AA16361; Wed, 22 Sep 93 00:11:11 -0700 Received: by vbormc.vbo.dec.com; id AB12809; Wed, 22 Sep 93 09:10:09 +0200 Message-Id: <9309220710.AB12809@vbormc.vbo.dec.com> Received: from rom01.enet; by vbormc.enet; Wed, 22 Sep 93 09:10:39 MET DST Date: Wed, 22 Sep 93 09:10:39 MET DST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nomina sunt omina To: atm@hplms2.hpl.hp.com Cc: cenci@rom01.enet.dec.com Apparently-To: atm@hplms2.hpl.hp.com Subject: I'm deluged with mails! Please stop broadcasting them.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02317; 22 Sep 93 6:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02313; 22 Sep 93 6:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06889; 22 Sep 93 6:35 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16658; Tue, 21 Sep 93 23:39:12 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16600; Tue, 21 Sep 93 23:39:10 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA13025; Tue, 21 Sep 93 15:41:20 -0700 Received: from cantva.canterbury.ac.nz by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA13201; Tue, 21 Sep 93 15:41:37 -0700 Received: from elec.canterbury.ac.nz by csc.canterbury.ac.nz (PMDF V4.2-13 #2553) id <01H38VBT42K0AZ1585@csc.canterbury.ac.nz>; Wed, 22 Sep 1993 10:40:42 +1200 Received: from antares.elec.canterbury.ac.nz by elec.canterbury.ac.nz (4.1/SMI-4.0) id AA11299; Wed, 22 Sep 93 10:39:11 NZS Date: Wed, 22 Sep 93 10:39:11 NZS Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: nelsonrr@elec.canterbury.ac.nz Subject: Re: Classical Draft Status To: atm@hplms2.hpl.hp.com Message-Id: <9309212239.AA11299@elec.canterbury.ac.nz> X-Envelope-To: atm@hpl.hp.com Content-Transfer-Encoding: 7BIT > >Do you see any places where we might be painting ourselves into a > >corner? > I sure see some dangers. > > Given that ATM switches do congestion and error control on the cell > level, and TCP senses path state at the packet (frame) level, the current > architecture has changed the gain of the TCP window servo by more than three > orders of magnitude. > > I suspect that we will discover that TCP over ATM on big pipes is unstable > (In a control theory sense), and we will have to make some changes. One of the > "easy" fixes would be to add forward error correction at the AAL layer..... > Another would be to convince the switch vendors to do frame dropping.... > (If you drop a low priority cell, drop all until the next high priority cell). > This is a potentially big problem. Gary Anido at the University of Wollongong has done some work which suggests that bursty data traffic (i.e. TCP) can only achieve low utilisations (maybe 30%, from memory) on ATM before cell dropping due to switch congestion becomes significant. I know he's been working on the design of a device to plug in upstream of switch queues and control admission of frames. I'm just guessing, but might another solution not be a new set of congestion control algorithms ;-). Just getting my 2c worth in. Richard Nelson.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02350; 22 Sep 93 6:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02346; 22 Sep 93 6:39 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06988; 22 Sep 93 6:39 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23416; Wed, 22 Sep 93 01:49:23 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA23403; Wed, 22 Sep 93 01:49:22 -0700 Message-Id: <9309220849.AA23403@matmos.hpl.hp.com> To: dan@merlin.dev.cdx.mot.com Cc: atm@matmos.hpl.hp.com Subject: Re: Classical Draft Status (long) In-Reply-To: Your message of Tue, 21 Sep 93 16:00:54 -0400 Date: Wed, 22 Sep 93 01:49:22 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Mark, sorry about the last minute laundry list, and even more sorry about the following request: can you revise the document again before kicking it out? Well, you are down to the 11th+ hour... I appreciate some of the clarifications you've made and the wording suggestions. I've just parsed through 3000+ messages to atm-request from the 30 or so bad mail addresses on the list. (Amazing what 30 bad mail addresses will return properly to atm-request from the couple bad mail addresses that returned to atm. *sigh*) It's 1:50 AM and I'll need another day to digest all your comments due to lack of energy at this moment. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02520; 22 Sep 93 6:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02516; 22 Sep 93 6:50 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07354; 22 Sep 93 6:50 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19979; Tue, 21 Sep 93 23:41:31 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19943; Tue, 21 Sep 93 23:41:30 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA12660; Tue, 21 Sep 93 15:10:42 -0700 Received: from nsco.network.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12924; Tue, 21 Sep 93 15:11:02 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA08161; Tue, 21 Sep 93 17:14:02 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA09445; Tue, 21 Sep 93 17:09:22 CDT Date: Tue, 21 Sep 93 17:09:22 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309212209.AA09445@anubis.network.com> To: atm@hplms2.hpl.hp.com Subject: Re: More VC Management Tim Salo is raising a valid concern that one will not be able to build a full mesh of PVCs in a PVC only enrionment. While this is true, and a problem, I do not think it is a problem which the Classical draft can solve. For IP qua IP to run, it needs to see either a set of single point-to-point links, or a fully connected "LAN" (NBMA in this case). We want to be able to support multi-connection since otherwise we are largely wasting our time. As such, a LIS is a connected mesh of entities. If not all entities need to talk to each other, in a PVC only situation, then you need separate IP subnets (and seapartes LISs). No, this is not ideal, but then neither is a PVC only environment. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03290; 22 Sep 93 7:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03286; 22 Sep 93 7:14 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08060; 22 Sep 93 7:14 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23318; Tue, 21 Sep 93 23:43:05 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA23285; Tue, 21 Sep 93 23:43:04 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA12219; Tue, 21 Sep 93 14:34:49 -0700 Received: from uu3.psi.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12575; Tue, 21 Sep 93 14:35:10 -0700 Received: from inssys3.hns.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23651 for atm@hpl.hp.com; Tue, 21 Sep 93 17:33:27 -0400 Received: by inssys3.hns.com (1.37.109.4/2.1-Hughes Network Systems) id AA27208; Tue, 21 Sep 93 17:31:41 -0400 Message-Id: <9309212131.AA27208@inssys3.hns.com> To: atm@hplms2.hpl.hp.com Subject: Re: Classical Draft Status In-Reply-To: Your message of "Tue, 21 Sep 93 09:53:42 EDT." <9309211653.AA02793@cannondale.arc.nasa.gov> Date: Tue, 21 Sep 93 17:31:36 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Pierre Lin You're not alone. Just today, I've received probably over 10 copies of the same message. Only wish if their could be marked with CLP-bit on.. Cheers, PL   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03844; 22 Sep 93 7:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03836; 22 Sep 93 7:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08467; 22 Sep 93 7:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA29141; Tue, 21 Sep 93 23:46:46 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA29089; Tue, 21 Sep 93 23:46:44 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA12126; Tue, 21 Sep 93 14:20:03 -0700 Received: from uu3.psi.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12440; Tue, 21 Sep 93 14:20:24 -0700 Received: from inssys3.hns.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA21881 for atm@hplms2.hpl.hp.com; Tue, 21 Sep 93 17:18:40 -0400 Received: by inssys3.hns.com (1.37.109.4/2.1-Hughes Network Systems) id AA27194; Tue, 21 Sep 93 17:16:57 -0400 Message-Id: <9309212116.AA27194@inssys3.hns.com> To: atm@hplms2.hpl.hp.com Subject: Please Remove me From This Looped/Flooded Message Queue Date: Tue, 21 Sep 93 17:16:55 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Pierre Lin I've flooded with the same message, as the attached, at least 12 or 13 times just today. Please releave me from this problemed mail-list. Thanks!! PL ================================================================= >From: US3RMC::"atm@hpl.hp.com" To: laubach@matmos.hpl.hp.com CC: atm@hplms2.hpl.hp.com Subj: More VC Management ---------------- The following error message was returned whilst sending to address DSAP01::HAWE %NMAIL-E-LOGLINK, error creating network link to node DSAP01 -SYSTEM-F-NOSUCHNODE, remote node is unknown This is a hard error. No more attempts to send to this address will be made. ---------------- The text of your failed mail message follows: In a PVC-only environment, does each host require n**2/2 VCs? Likewise, does every host need to be reconfigured (with an additional VC) when a new host is added to the network? Or, perhaps, should a router transport packets between hosts within an LIS which do not have a PVC between them?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05209; 22 Sep 93 8:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05205; 22 Sep 93 8:28 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10551; 22 Sep 93 8:28 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07134; Tue, 21 Sep 93 23:32:51 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA07084; Tue, 21 Sep 93 23:32:50 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA14128; Tue, 21 Sep 93 18:02:39 -0700 Received: from dreggs.cisco.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA14351; Tue, 21 Sep 93 18:03:01 -0700 Received: by dreggs.cisco.com; Tue, 21 Sep 93 18:01:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lawrence Lang Message-Id: <9309220101.AA18105@dreggs.cisco.com> Subject: re: atm mail loop To: atm@matmos.hpl.hp.com Date: Tue, 21 Sep 93 18:01:21 MDT In-Reply-To: <930921160215.6529@matmos.hpl.hp.com>; from "Mark Laubach" at Sep 21, 93 4:02 pm X-Mailer: ELM [version 2.3 PL11] Think of how fast we can get these mail loops cooking once we have ATM! ;-) Larry > > My my, how embarassing. > > There are 1023 addresses on the atm working group list. > > The daemon at nmail-daemon@manage.enet.dec.com decided to send error > messages back to atm@hpl.hp.com causing a cascading mail loop. > > My machine ran out of swap space last night. My machine ran out of file > table space this morning. Tim Salo gave me a call to say "did you know > that..." while I was in the middle of cycling power on the machine..... > > I've added 128Mbytes more swap to the system. I've doubled the file table > size in the kernal. I've added 32 Mbytes more RAM to help the performance > just a little bit. > > I've added mail loop detection into the list processing and I am explicitly > catching mail from our friendly nmail-daemon above. > > I hope the list settles down. I am terribly sorry for the inconvenience this > has cause. > > Gigabit rate errors will be no fun! > > Mark > > ps. there have been about 8 requests for removal and 2 for subscription. > -- ______________________________________________ Lawrence J. Lang Cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, California 94025 USA + 1 415 688 4638 Phone + 1 415 326 1989 Fax llang@cisco.com Email ______________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06290; 22 Sep 93 9:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06281; 22 Sep 93 9:03 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12499; 22 Sep 93 9:03 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08655; Tue, 21 Sep 93 23:33:31 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08624; Tue, 21 Sep 93 23:33:30 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA13957; Tue, 21 Sep 93 17:33:04 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA05483; Wed, 22 Sep 93 01:31:37 +0100 Received: from itd.nrl.navy.mil by hplb.hpl.hp.com; Wed, 22 Sep 93 01:22:14 +0100 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA00507; Tue, 21 Sep 93 20:32:48 EDT Date: Tue, 21 Sep 93 20:32:48 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ran Atkinson Message-Id: <9309220032.AA00507@itd.nrl.navy.mil> To: atm@hplms2.hpl.hp.com Subject: confusing terminology Reading Dan Grossman's email makes me think that perhaps a brief terminology note would be helpful to this list since not all have been subjected to the ATM Forum's word wizards. :-) Many people see the word "public ATM network" as implying "Telephone Company operated ATM network", most likely with E.164 addressing. Mostly the same set of people see "private ATM network" as being everything else. In the ATM Forum, phone company types object to any non-ITU-like items in anything that claims to be "public ATM", which is why we have a "Private NNI" signalling group there rather than just an "NNI" signalling group. Commercial service providers that aren't phone companies seem much less uptight about this, probably because they understand that firms meeting customer needs are more successful. [NB: I'm not lumping Telecom Finland in with the other phone companies :-] I think it is much clearer if we talk about "commercial ATM networks" (NB: doesn't imply address flavour or nature of the firm providing service) and "internal ATM networks" (where "internal" means those ATM LANs and MANs and WANs that are within one's own organisation and are not a commercial service offered to others). Avoiding use of the terms "public ATM" and "private ATM" will help us evade much grief amongst readers of the draft both now and after it appears in RFC form, IMHO. Ran atkinson@itd.nrl.navy.mil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06935; 22 Sep 93 9:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06931; 22 Sep 93 9:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13444; 22 Sep 93 9:23 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01127; Tue, 21 Sep 93 23:47:33 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01007; Tue, 21 Sep 93 23:47:29 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA12044; Tue, 21 Sep 93 14:11:43 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12332; Tue, 21 Sep 93 14:12:05 -0700 Received: by inet-gw-2.pa.dec.com; id AA16729; Tue, 21 Sep 93 14:11:33 -0700 Received: by us1rmc.bb.dec.com; id AA09109; Tue, 21 Sep 93 17:10:25 -0400 Message-Id: <9309212110.AA09109@us1rmc.bb.dec.com> Received: from carafe.enet; by us1rmc.enet; Tue, 21 Sep 93 17:10:25 EDT Date: Tue, 21 Sep 93 17:10:25 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk 20-Sep-1993 2352" To: atm@hplms2.hpl.hp.com Apparently-To: atm@hplms2.hpl.hp.com Subject: Re: ARP and E.164 Address Formats Following up on George and Anthony, The prefix "sub" has two different implications here, hence a bit of confustion: >>The issue of whether the E.164 address is peer, subserviant to, or >>superior to the NSAP is clearly confused. In P-NNI discussions we're >>calling an E.164 cloud a subnet, but in our address format to cross >>this cloud we call the E.164 address the address and the NSAP the >>sub-address. I'm of the opinion that the second usage here is the one >>that's in error. The NSAP is by def a globally unique address and not >>a subaddress of anything. > >Yes, as I mentioned yesterday, its really the E.164 address that is the >subnetwork address, but that's not the way signaling treats it of course, >since that is public network centric. I don't think it makes too much >difference either way, as long as we all remember what we are talking >about. "Subnetwork" in the OSI world means a network that delivers a service part way; a "network" is composed of subnetworks. An address in a subnetwork is NOT called a subaddress, but in OSI is a Subnetwork Point of Attachment Address. If you follow the ITU model of ATM, then E.164 may well be the ATM address, where a public ATM is a subnetwork of a private network. The private network address, in OSI, would be an NSAP if this were the network layer (which it isn't, but we're pretending it is for the moment). Thus "sub" means "of a lower position in the stack". I don't mean "lower layer" since that would imply strict layering, which is not necessary. "Subaddress" in the ITU world means a value that is passed end to end by the network without the network peeking. Since the public network is by definition a subnetwork, the subaddress is the HIGHER position-in-the-stack address. Public networks do tend to take an inverted view here, with the public network on top and the users somewhere beneath the pond's surface tension. But that's always what "subaddress" means. In a newer SI terminology, it might more likely be a "superaddress" since it means a higher position in the stack (again not a strict layering required). IP's use of "subnetwork" is different from OSI's, but the meaning of "sub" is the same. Remember "subaddress" as an olde X.25 concept which was named way back when. >>What I think folks were mostly conceiving >>of was a two stage address with the E.164 address indicating the >>egress from the public network and the NSAP indicating the final >>destination. In fact one might reach this destination through several >>different E.164 egresses from the public network, or a route may >>exist that doesn't involve the public netowrk at all. In this sense, >>at the P-NNI, the E.164 address is not part of resolving the IP >>address at all, but part of a loose source route. > >Yes, I agree, this is certainly true from a strict layering viewpoint, >though, >as Dan and Subbu pointed out, maybe there are efficiencies to be gained >from a less strict interpretation. It is possible, of course, for an ATM endpoint to have JUST an E.164 address, or have an E.164 subnetwork point of attachment address in which case the ATM-like subaddress can carry the final destination. Again just note the inverted use of "sub" in the term "subaddress". >>For the purposes of a P-NNI style network I therefore think it makes >>sense that ARP resolve the IP address to an NSAP and let VC-routing >>figure out if an E.164 address is needed some where along the way to >>navigate across a public cloud used as a subnet. >right way to solve this problem - I do worry about embedding knowledge of >the subnetwork structure(s) in a protocol (i.e. ARP) that should only care >about end to end connectivity. Most people, thus far, however, seem to >favor a combined approach - any comments from anyone about why this >may or may not be a good thing? The two-part ARP address may not be embedding subnetwork structure. There is no guarantee (in ITU) that subaddress IS a globally unique value (NSAP-like). Of course it would not be an unreasonable assumption to make of IP-over-ATM, since the public network has no say over the subaddress. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12232; 22 Sep 93 13:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12220; 22 Sep 93 13:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23735; 22 Sep 93 13:13 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14785; Wed, 22 Sep 93 08:56:44 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14739; Wed, 22 Sep 93 08:56:43 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA17758; Wed, 22 Sep 93 08:09:59 -0700 Received: from Sun.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA17883; Wed, 22 Sep 93 08:10:21 -0700 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02541; Wed, 22 Sep 93 08:07:27 PDT Received: from tadioto.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA17804; Wed, 22 Sep 93 08:07:28 PDT Received: by tadioto.Eng.Sun.COM (4.1/SMI-4.1) id AA11201; Wed, 22 Sep 93 08:07:24 PDT Date: Wed, 22 Sep 93 08:07:24 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Binh Pham Message-Id: <9309221507.AA11201@tadioto.Eng.Sun.COM> To: atm@hplms2.hpl.hp.com Subject: Remove! Please remove me from this list. Thanx   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12314; 22 Sep 93 13:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12310; 22 Sep 93 13:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23904; 22 Sep 93 13:15 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14973; Wed, 22 Sep 93 08:56:52 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14923; Wed, 22 Sep 93 08:56:50 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA17842; Wed, 22 Sep 93 08:21:17 -0700 Received: from motgate.mot.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA17967; Wed, 22 Sep 93 08:21:35 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA02206; Wed, 22 Sep 1993 10:19:49 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA27795; Wed, 22 Sep 1993 10:19:39 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA09341 (5.65a+/IDA-1.4.2 for atm@matmos.hpl.hp.com); Wed, 22 Sep 93 11:18:52 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA09412 (5.65a+/IDA-1.4.2 for dan@merlin.dev.cdx.mot.com); Wed, 22 Sep 93 11:18:50 -0400 Message-Id: <9309221518.AA09412@dbg.dev.cdx.mot.com> To: atm@matmos.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com Subject: Re: confusing terminology In-Reply-To: Your message of "Tue, 21 Sep 93 20:32:48 EDT." <9309220032.AA00507@itd.nrl.navy.mil> Date: Wed, 22 Sep 93 11:18:48 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp I agree that we should avoid using the terms 'public' and 'private' where possible (and I have been trying, without much success thus far, to get the ATM Forum to do the same). The regulatory environment (including the notion of what is and is not a public network) is changing - not just here in the US, where we have taken the lead in developing a pro-competitive communications environment, but also in much of the rest of the world. I believe it is possible to defocus technology standards and implementation agreements from questions of ownership, common (or contract) carriage, regulatory status and similar business/public policy questions. There are too many cases where we write these kinds of relationships into standards/IAs for no good technical reason, to the overall detriment of everybody except keepers of the status quo. That said, I also accept that there is an embedded base of hardware, software, administrative systems, vendor relationships, and institutional culture in the incumbent public networks which still needs to be taken into account. The dependency of most incumbent public networks on the E.164 numbering plan is an example of this. This should be treated as an exception condition that applies only to public networks; therefore, it is proper to speak of public networks in this context. I don't believe that creating new terms like "commercial ATM networks" and "internal ATM networks" will add anything of value to this document or any other that I'm aware of, and would only serve to create confusion. However, we should speak of public and private only where we absolutely need to to deal with exception conditions surrounding the incumbent public networks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12617; 22 Sep 93 13:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12607; 22 Sep 93 13:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24912; 22 Sep 93 13:35 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23449; Wed, 22 Sep 93 09:22:55 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA23438; Wed, 22 Sep 93 09:22:54 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA18239; Wed, 22 Sep 93 09:22:59 -0700 Received: from cannondale.arc.nasa.gov by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA18378; Wed, 22 Sep 93 09:23:21 -0700 Received: Wed, 22 Sep 93 09:21:41 PDT by cannondale.arc.nasa.gov (4.1/1.2) Date: Wed, 22 Sep 93 09:21:41 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vishy Narayan Message-Id: <9309221621.AA03241@cannondale.arc.nasa.gov> To: atm@hplms2.hpl.hp.com, atm@matmos.hpl.hp.com Subject: Re: Classical Draft Status Its getting a bit tougher to read my email. This morning I had 157 messages, about 5-6 copies of each. I did the next best thing I could. Deleted all of them :-( Help !!!!!!!! Vishy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12698; 22 Sep 93 13:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12694; 22 Sep 93 13:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25042; 22 Sep 93 13:38 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24292; Wed, 22 Sep 93 09:24:17 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from x400gate.bnr.ca by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24246; Wed, 22 Sep 93 09:24:14 -0700 X400-Received: by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Sep 1993 12:24:01 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Sep 1993 12:23:37 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 22 Sep 1993 08:23:00 -0400 Date: Wed, 22 Sep 1993 12:23:00 +0000 X400-Originator: /DD.ID=1508101/G=Ken/I=KG/S=Hayward/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.258:22.08.93.16.23.37] X400-Content-Type: P2-1984 (2) Content-Identifier: re:confusing ... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ken (K.G.) Hayward" Message-Id: <"19296 Wed Sep 22 12:23:54 1993"@bnr.ca> To: atm@matmos.hpl.hp.com Subject: re:confusing terminology >I think it is much clearer if we talk about "commercial ATM networks" >(NB: doesn't imply address flavour or nature of the firm providing >service) and "internal ATM networks" (where "internal" means those ATM >LANs and MANs and WANs that are within one's own organisation and are >not a commercial service offered to others). I certainly agree that the current wording is becoming more confusing and less accurate. What I tend to use is 'carrier' and 'non-carrier' network. 'Intra-' and 'Inter-domain' ports can be on either type of network.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12838; 22 Sep 93 13:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12834; 22 Sep 93 13:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25487; 22 Sep 93 13:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16461; Wed, 22 Sep 93 08:58:29 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16384; Wed, 22 Sep 93 08:58:27 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA17585; Wed, 22 Sep 93 07:13:19 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA29551; Wed, 22 Sep 93 15:11:51 +0100 Received: from interlock.ans.net by hplb.hpl.hp.com; Wed, 22 Sep 93 15:02:26 +0100 Received: by interlock.ans.net id AA08308 (InterLock SMTP Gateway 1.1 for atm@hpl.hp.com); Wed, 22 Sep 1993 10:06:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Sep 1993 10:06:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Sep 1993 10:06:23 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309221410.AA22173@foo.ans.net> To: atm@hplms2.hpl.hp.com Cc: rolc@nsco.network.com, kerch@parc.xerox.com, curtis@ans.net Subject: Re: More VC Management In-Reply-To: (Your message of Tue, 21 Sep 93 15:11:24 EST.) <9309212011.AA05725@uh.msc.edu> Date: Wed, 22 Sep 93 10:10:36 -0500 > By the way, I believe that PVC-only environments are important. I believe that > all of the publically-announced wide-area ATM services will initially > offer only PVCs. I suspect that some of these networks will be large > [IP subnets]. For example, some carrier may want to offer Internet > service over their ATM service. I suspect that the carrier will not want > to configure O(n**2) PVCs in the network. I also suspect that some > customers will want to talk to other customers without paying for a > PVC to that customer. Since we are publicly speculating, I'd like to add to this. I hope the list won't mind if I add my $.02. I suspect that the PVC only ATM networks will initially be individual IXE provider islands. Either the provider themselves or a third party will operate IP routers and provide an IP service. The cost of an ATM hookup to this net will require fiber to the site plus ATM capable tail circuit equipment. The cost will probably be higher than the current cost of a T3 connection for ATM at T3 speed. Most attachments will continue to be IP attachments to the ATM border router, some because their 56kb, T1, or whatever (FR, SMDS,...) won't support ATM and others because ATM PVCs won't scale (so they simply have an ATM point to point connection to the border router). > Perhaps, the classical model should allow a router to transport > packets between hosts within a LIS when a VC isn't available or can't > be established. This touches on the ROLC (routing over large clouds) turf. Not that the ROLC group has much consensus on anything. If the scenario above comes about (local ATM attachment to a border router of a IP over ATM carrier WAN) and routing is set up sanely, the address of the border router will be given as the IP next hop. The ATM attached host (Cray front end?) or router (I'll call this the site router), should try to ARP resolve the address of the next hop, not the address of the destination. That's how routing and ARP currently work. At some point, the border router may have ATM PVCs to the IXE WAN (because the IXE switches don't support SVC) and may use SVCs and ARP for local attachement. And then magic happens. Eventually everyone implements compatible SVCs, somehow the NNI issues are resolved, and we emerge with NBMA ARP. At that point, most destinations (but never all) are reachable by ATM SVC. Of course there will be some transition period during which the site router has to decide whether to ARP for the destination of the next hop (by magic?). One brand of magic prescribes that the routing protocol will have to provide some hint telling it to ARP for destination, not next hop (aggregating many routes and providing some new routing protocol attribute) to prevent the site router from needing to get one route per SVC reachable destination. Both BGP and IDRP (inter-domain routing protocols) are extensible through definition of new attributes as long as they can be defined such that older implementations can either ignore them or pass them on (in BGP this is an optional attribute that can be transitive or non-trasitive - passed on or ignored if not understood). I'll admit that if you understand that it isn't really magic. There is another brand of magic involving query response protocols. I don't fully understand how it is going to work, but perhaps I'll better understand after the IETF meeting. I copied the ROLC mailing list. Perhaps someone can better explain how the transition works. BTW - (No flames please, I'm just trying to get a discussion going that results in a statement of a workable routing transition. I don't think I'm the only person that doesn't understand how this is supposed to work. No flame intended either. Do I really need the smileys?). In any case, I don't think this should be addressed by the Classical IP over ATM draft/RFC. It is beyond the scope of that document. I also don't see any way in which we have constrained our options in the Classical IP over ATM draft. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12964; 22 Sep 93 13:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12960; 22 Sep 93 13:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25803; 22 Sep 93 13:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27398; Wed, 22 Sep 93 09:54:33 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27387; Wed, 22 Sep 93 09:54:32 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA18476; Wed, 22 Sep 93 09:54:38 -0700 Received: from casbah.acns.nwu.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA18686; Wed, 22 Sep 93 09:55:00 -0700 Received: from [129.105.153.4] (mac004.ntg.nwu.edu) by casbah.acns.nwu.edu (4.1/SMI-DSS-1.04) id AA20679; Wed, 22 Sep 93 11:52:04 CDT Date: Wed, 22 Sep 93 11:52:04 CDT Message-Id: <9309221652.AA20679@casbah.acns.nwu.edu> To: atm@hplms2.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: j_shah@casbah.acns.nwu.edu Subject: ATM trial etc. I will not be able to attend. can you pl. send me the report. j_shah@nwu.edu joe shah Northwestern University   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13239; 22 Sep 93 14:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13233; 22 Sep 93 14:01 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26300; 22 Sep 93 14:01 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19880; Wed, 22 Sep 93 09:00:51 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: atm@matmos.hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19847; Wed, 22 Sep 93 09:00:50 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA17245; Wed, 22 Sep 93 05:50:03 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA26460; Wed, 22 Sep 93 13:48:31 +0100 Received: from tumlis.lis.e-technik.tu-muenchen.de by hplb.hpl.hp.com; Wed, 22 Sep 93 13:38:51 +0100 Received: from loki.lis.e-technik.tu-muenchen.de by tumlis.lis.e-technik.tu-muenchen.de with SMTP id AA26051 (5.65c/IDA-1.4.4 for ); Wed, 22 Sep 1993 14:48:16 +0200 Received: by loki.lis.e-technik.tu-muenchen.de id AA00903 (5.65c/IDA-1.4.4 for atm@hpl.hp.com); Wed, 22 Sep 1993 14:50:23 +0200 Date: Wed, 22 Sep 1993 14:50:23 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Hansson Message-Id: <199309221250.AA00903@loki.lis.e-technik.tu-muenchen.de> To: atm@hplms2.hpl.hp.com Subject: Re: UNH/IOL ATM Interoperability Lab Is it my matter? Why do I have to get this mail?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14046; 22 Sep 93 14:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14042; 22 Sep 93 14:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa27535; 22 Sep 93 14:27 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04309; Wed, 22 Sep 93 10:18:59 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ADAPTIVE.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA04296; Wed, 22 Sep 93 10:18:35 -0700 Received: from luna-stm ([147.3.10.2]) by adaptive.adaptive.COM (4.1/SMI-4.1) id AA16236; Wed, 22 Sep 93 10:15:47 PDT Received: from newman.adaptive.com by luna-stm (4.1/SMI-4.1) id AA07715; Wed, 22 Sep 93 10:15:38 PDT Date: Wed, 22 Sep 93 10:15:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Newman Message-Id: <9309221715.AA07715@luna-stm> To: atm@matmos.hpl.hp.com Subject: Re: Classical Draft Status Richard, I am working on congestion control algorithms for best effort service over ATM and would be very interested in the work of Gary Anido at the University of Wollongong on TCP over ATM. Can you send me anything or point me toward a publication. Also have you seen John Daigle's work or Allyn Romanow's work on the same subject. -- Peter Newman   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14399; 22 Sep 93 14:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14395; 22 Sep 93 14:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa27951; 22 Sep 93 14:35 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03008; Wed, 22 Sep 93 10:16:11 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02995; Wed, 22 Sep 93 10:16:08 -0700 Date: Wed, 22 Sep 93 10:16:08 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309221716.AA02995@matmos.hpl.hp.com> To: "Alles, Anthony" Subject: Re: Repost: RE: Classical Draft Status In-Reply-To: <2C9E4D89@msgate.hls.com> References: <2C9E4D89@msgate.hls.com> Cc: atm@matmos.hpl.hp.com [Sorry for the delayed response back on this] Thanks for your comments, a few of my own. Thanks for the missing "not". To consider anything from the ATM-FORUM P-NNI is premature at this point for the classical draft. I consulted with a current implementer of the UNI 3.0 Q.93B (NRL) and they advised that the classical draft should not specify subaddresses for ARP. I would very much like to hear from other Q.93B UNI implementers at this time. In your last paragraph, you recommend that we should always use NSAP's and the E.164 should be a subadress. This is syntactically not possible, Q.93B sub-addresses are always NSAP's. The IETF should not dictate how addresses are to be done in ATM, we have to cope with the unfortunate world they have thrown up at us. >From an ATM-FORUM perspective the quote from the UNI 3.0 spec with respect to subaddresses is (thanks to Bob Cole): "The purpose of the Called party subaddress IE is to identify the subaddress of the called party of a call. It is used in this Implementation Agreement only to convey an ATM address in the OSI NSAP format across a public network which supports only E.164 addresses." I see this as more of ATM issue at this time. The classical model would treat each NSAP lan as an LIS and the E.164 network as another LIS. What you are talking about gets into ARP'ing outside the normal LIS, which is in our beyond-classical future. Comments? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14569; 22 Sep 93 14:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14565; 22 Sep 93 14:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28098; 22 Sep 93 14:40 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08233; Wed, 22 Sep 93 10:47:13 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from netcom5.netcom.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08216; Wed, 22 Sep 93 10:47:12 -0700 Received: by netcom5.netcom.com (5.65/SMI-4.1/Netcom) id AA27946; Wed, 22 Sep 93 10:47:45 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sanjeev Newarikar Message-Id: <9309221747.AA27946@netcom5.netcom.com> Subject: Re: Classical Draft Status To: atm@matmos.hpl.hp.com Date: Wed, 22 Sep 93 10:47:44 PDT In-Reply-To: <9309221621.AA03241@cannondale.arc.nasa.gov>; from "Vishy Narayan" at Sep 22, 93 9:21 am X-Mailer: ELM [version 2.3 PL11] Firstly, don't send your message twice ( look at your headers :-) Secondly, be patient, the problem has been fixed. --sanjeev > > Its getting a bit tougher to read my email. This morning > I had 157 messages, about 5-6 copies of each. I did the > next best thing I could. > > Deleted all of them :-( > > Help !!!!!!!! > > > Vishy > --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14758; 22 Sep 93 14:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14754; 22 Sep 93 14:52 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28570; 22 Sep 93 14:52 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA06623; Wed, 22 Sep 93 10:32:29 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA06609; Wed, 22 Sep 93 10:32:29 -0700 Message-Id: <9309221732.AA06609@matmos.hpl.hp.com> To: dan@merlin.dev.cdx.mot.com Cc: atm@matmos.hpl.hp.com Subject: Re: confusing terminology In-Reply-To: Your message of Wed, 22 Sep 93 11:18:48 -0400 Date: Wed, 22 Sep 93 10:32:29 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach From: dan@merlin.dev.cdx.mot.com Subject: Re: confusing terminology ... I don't believe that creating new terms like "commercial ATM networks" and "internal ATM networks" will add anything of value to this document or any other that I'm aware of, and would only serve to create confusion. However, we should speak of public and private only where we absolutely need to to deal with exception conditions surrounding the incumbent public networks. Ran, thanks for your earlier note. I also believe that "commercial" and "internal" do not really clear up the confusion for all viewers. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14783; 22 Sep 93 14:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14779; 22 Sep 93 14:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28647; 22 Sep 93 14:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08937; Wed, 22 Sep 93 10:49:45 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08913; Wed, 22 Sep 93 10:49:44 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA18790; Wed, 22 Sep 93 10:49:50 -0700 Received: from att-out.att.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA19135; Wed, 22 Sep 93 10:50:11 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mario Santoro To: atm@hplms2.hpl.hp.com Received: by boole.att.com (bind.93018) id AA24714; Tue, 21 Sep 93 18:07:40 EDT Received: from boole.att.com by att.att.com; Wed, 22 Sep 93 13:44 EDT Date: Tue, 21 Sep 93 18:07:40 EDT Content-Length: 110 Content-Type: text Original-From: boole.att.com!mario (Mario Santoro) Message-Id: <9309212207.AA24714@boole.att.com> Original-To: hpl.hp.com!atm Subject: Re: Report on failed mail Why do Iget so many copies of the same message? Please, correct the problem. Thank you. mario@boole.att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15128; 22 Sep 93 15:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15124; 22 Sep 93 15:04 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa29273; 22 Sep 93 15:04 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28451; Wed, 22 Sep 93 09:56:54 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA28439; Wed, 22 Sep 93 09:56:54 -0700 Received: from matmos.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA18489; Wed, 22 Sep 93 09:56:59 -0700 Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA28400; Wed, 22 Sep 93 09:56:36 -0700 Message-Id: <9309221656.AA28400@matmos.hpl.hp.com> To: Pierre Lin Cc: atm@hplms2.hpl.hp.com Subject: Re: Classical Draft Status In-Reply-To: Your message of Tue, 21 Sep 93 17:31:36 -0400 Date: Wed, 22 Sep 93 09:56:35 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach From: Pierre Lin Subject: Re: Classical Draft Status You're not alone. Just today, I've received probably over 10 copies of the same message. Only wish if their could be marked with CLP-bit on.. Cheers, PL The loop detection header is now "X-Loop: ATM CLP.bit ON".... I think the problems are settling down a whole bunch now. Please let atm-request@matmos.hpl.hp.com know if anyone is seeing this message more than one time. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15437; 22 Sep 93 15:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15433; 22 Sep 93 15:21 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00682; 22 Sep 93 15:20 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12315; Wed, 22 Sep 93 11:13:59 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12302; Wed, 22 Sep 93 11:13:58 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA18935; Wed, 22 Sep 93 11:13:59 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA19354; Wed, 22 Sep 93 11:14:11 -0700 Received: by interlock.ans.net id AA04493 (InterLock SMTP Gateway 1.1 for atm@hplms2.hpl.hp.com); Wed, 22 Sep 1993 14:06:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Sep 1993 14:06:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Sep 1993 14:06:15 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309221810.AA73997@foo.ans.net> To: atm@matmos.hpl.hp.com Cc: atm@hplms2.hpl.hp.com, curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Wed, 22 Sep 93 09:21:41 PDT.) <9309221621.AA03241@cannondale.arc.nasa.gov> Date: Wed, 22 Sep 93 14:10:28 -0500 > Its getting a bit tougher to read my email. This morning > I had 157 messages, about 5-6 copies of each. I did the > next best thing I could. > > Deleted all of them :-( I've already sorted through my mail but I think the bounced messages all had "% Message-ID: " in them. Using the mh mailer try: list=`pick -search ' Message-ID: '` list=`show $list | grep ' Message-ID: ' | sed 's,.* Message-ID: ,,' | sort -u` for id in $list do if [ ! -z "`pick --Message-ID $id`" ] ; then rmm `pick -search " Message-ID: $id"` fi done This uses the Bourne shell and mh. I haven't tried this since I already deleted all of my duplicate messages. Milage may vary. Hope this helps. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15738; 22 Sep 93 15:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15734; 22 Sep 93 15:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01182; 22 Sep 93 15:31 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA12581; Wed, 22 Sep 93 11:14:40 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from interlock.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12554; Wed, 22 Sep 93 11:14:37 -0700 Received: by interlock.ans.net id AA19361 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Wed, 22 Sep 1993 14:08:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Sep 1993 14:08:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Sep 1993 14:08:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309221812.AA34857@foo.ans.net> To: atm@matmos.hpl.hp.com Cc: curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Wed, 22 Sep 93 10:39:11 N.) <9309212239.AA11299@elec.canterbury.ac.nz> Date: Wed, 22 Sep 93 14:12:42 -0500 > > I suspect that we will discover that TCP over ATM on big pipes is unstable > > (In a control theory sense), and we will have to make some changes. One of the > > "easy" fixes would be to add forward error correction at the AAL layer..... > > Another would be to convince the switch vendors to do frame dropping.... > > (If you drop a low priority cell, drop all until the next high priority cell). > > This is a potentially big problem. Gary Anido at the University of > Wollongong has done some work which suggests that bursty data traffic > (i.e. TCP) can only achieve low utilisations (maybe 30%, from memory) > on ATM before cell dropping due to switch congestion becomes significant. > I know he's been working on the design of a device to plug in upstream > of switch queues and control admission of frames. I'm just guessing, > but might another solution not be a new set of congestion control > algorithms ;-). > > Just getting my 2c worth in. > Richard Nelson. Richard, Statements like "some work which suggests that bursty data traffic (i.e. TCP) can only achieve low utilisations (maybe 30%, from memory) on ATM before ..." can be misleading. You can get the utilizations up much higher if you provide adequate queueing. The problem is that the queueing in current IP routers strives to reach 1-2 times the delay bandwidth product while some telephone switch vendors who are now making ATM switches think 256 cells is more buffering than anyone would ever need. Others have conceeded and put in 4K to 16K cells, still not enough. At OC3 speed (155 mbps - the switches have to forward the overhead) and US coast to coast 70 msec RTT, this yields 1.3 MB. Add Hawaii or Alaska and get 2.3 MB. Two times the D-BW product would be preferred. 256 cells is 12KB, less than 2 full MTU IP packets. 16,000 is 768 KB which is at least getting close. At this point, all you have to worry about is the magnification of cell drop into packet drop if you don't drop full AAL frames. I've seen simulations and actual test results that suggest that with adequate queueing and no other change, you can get over 90% utilization, but not the near 100% utilization that you could get at a bottleneck with multiple TCP over packet IP with adequate queueing. Of course, if you do more, like drop complete AAL frames, you'll do a little better. If you don't provide enough queueing, you'll do worse, much worse if you try hard enough. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16147; 22 Sep 93 15:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16143; 22 Sep 93 15:42 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01667; 22 Sep 93 15:42 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13434; Wed, 22 Sep 93 11:16:13 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [134.207.7.68] by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13396; Wed, 22 Sep 93 11:16:10 -0700 Received: from tesuji.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA04794; Wed, 22 Sep 93 14:16:14 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: hoffman@cmf.nrl.navy.mil Received: by tesuji.cmf.nrl.navy.mil (4.1/client-1.3) id AA03651; Wed, 22 Sep 93 14:16:13 EDT Date: Wed, 22 Sep 93 14:16:13 EDT Message-Id: <9309221816.AA03651@tesuji.cmf.nrl.navy.mil> To: atm@matmos.hpl.hp.com Subject: Re: Repost: RE: Classical Draft Status > I consulted with a current implementer of the UNI 3.0 Q.93B (NRL) and > they advised that the classical draft should not specify subaddresses > for ARP. I would very much like to hear from other Q.93B UNI > implementers at this time. to clarify this, the supposition was that an end node would recieve a single address, either E.164 or NSAP (potentially only NSAP, using the E164 encapsulation), and generate a call request with that address. At the boundry of a network which only supported E164, the vc routing/call setup mechansism would put the 'address' field in the 'subaddress' field, and specify the E164 of the exit switch from that public cloud in the 'address' (or 'number') field. This exit switch would then replace the place the subaddress in the address again. As far as I can tell, this most closely models the use of the subadress field as recommended in the UNI document. The only glitch in the above approach (as mentioned earlier on this list) is a host directly attached to a network which supports only E164. In this case, the result of the NSAP only ARP (if only NSAPs were supported), would have to be unwrapped before the call could be placed. The real argument is that subaddress/address really only belongs in issues of vc routing and call setup, not as part of the specification of an endpoint in the network.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16711; 22 Sep 93 16:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16707; 22 Sep 93 16:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03228; 22 Sep 93 16:13 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18341; Wed, 22 Sep 93 12:01:11 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nsco.network.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18320; Wed, 22 Sep 93 12:01:09 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA14785; Wed, 22 Sep 93 14:04:43 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA17081; Wed, 22 Sep 93 14:00:01 CDT Date: Wed, 22 Sep 93 14:00:01 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309221900.AA17081@anubis.network.com> To: atm@matmos.hpl.hp.com Subject: Re: Repost: RE: Classical Draft Status Hoffman@nrl descirbes how NRL expects to use the ATM NSAP address form, and its interaction with E.164 addresses. Specifically, he/they expect the border switch to generate the correct E.164 address to reach the Private address supplied in the call. I find this unlikely as a gneral model. In the near term, it is likely that domains which wish to communicate will form private adjacencies over any "public" cloud, and exchange/configure prefix information. However, in the long run: 1) I do not expect the "public" services to assist us by propogating prefix reachability information for private prefixes in their "routing" technology. 2) It is impossible for "everyone" to have private NNI adjacencies with every other private party. Hence, in the longer run, the "NRL" approach is not practical. Now, obviously the proposed approach is a good one for now. My concern is that we have an obvious area here where good design will allow the mechanisms to last much longer than otherwise. True, within a single LIS there is no problem. But can we/should we design teh ARP mechanism to be more flexible? Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17099; 22 Sep 93 16:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17095; 22 Sep 93 16:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04056; 22 Sep 93 16:26 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16962; Wed, 22 Sep 93 11:38:50 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16948; Wed, 22 Sep 93 11:38:34 -0700 To: dan@merlin.dev.cdx.mot.com Subject: Re: Classical Draft Status (long) In-Reply-To: <9309212000.AA08840@dbg.dev.cdx.mot.com> References: <9309212000.AA08840@dbg.dev.cdx.mot.com> Cc: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 22 Sep 93 11:38:33 -0700 Message-Id: <930922113833.6529@matmos.hpl.hp.com> Encoding: 92 TEXT, 2 TEXT SIGNATURE Ok, here are some comments. > o AAL Parameters Negotiation (aka MTU negotiation) is part of the Q.93b and > o B-LLI negotiation is part of Q.93b and the ATM Forum Signalling Spec. We'll do these is the next document, not the classical. Did you go over the minutes from the last WG meeting? > The ATM address fields in the ARP packet should be decoupled from the > structure of ATM addressing information elements in the Q.93b SETUP message. This is not consistent with other opinions we've received. > ARP server has > to figure out based on the ATM address of the host making the ARP request which > of Case 1, Case 2 or Case 3 apply. However, since hosts know by prior The ARP server is a client host also, so it already has that information as part of its ATM network interface initialization. > The last paragraph on Page 12 is not accurate. FIrst, I see no reason for the > limitation; it shouldn't matter to either the ARP server or the calling host > what the ATM address of the called host is, as long as that host is reachable > through a single ATM VC. Second, it's not the encoding that this paragraph > seems to be concerned with at all, and there is relationship between MAC > addresses and E.164 addresses in an ATM Endpoint address; they are orthogonal > and used in different parts of the address structure. Is it intended that: the > IDP be the same? the OUI? the RD? Area? Enforcing common values of these > fields on the hosts in an LIS has different implications on the scope of an LIS, > and should be done carefully. > Do we know that IP multicast over ATM multicast will be straightforward? Steve Deering seems to think so. > Well-know ATM addresses for ARP servers should NOT be done. However, we can > ask the ATM Forum or TSS for a reserved VCI for the ARP server. It is an open issue. The current chat I had with Glenn Estes is that it should be available via ILMI. > Wording changes: > Global: Apostrophes are used to indicate the possessive, not the plural. This > includes acronyms. Thus, proper usage is "PVCs", not "PVC's" Hmm, I've consulted my Strunk and White and it agrees with you. At least I've been consistent. Thanks for this nit. > > Note: this memo is not meant to a reference with regard to the > > operation of ATM, only to the way it defines the IP layer. > I don't quite understand this sentence. Do you mean "this memo defines only the > operation of IP over ATM, and is not meant to describe the operation of ATM > networks"? I like your wording better than the prior submission. Re: initial deployment text, thanks. > > signalling is performed via Q.93B implementations [7,9]. Note: > > in commonplace use, the term "virtual circuit" is synonymous with > > "virtual channel". > I suggest deleting the last sentence. Author's choice, I'll keep it. > > an ATM cell header which carries the AAL type value, rather it is > ^--------- > > known by the VC end points via the call setup mechanism. For > -------------------------------------------------------^ > This is contradictory to the following sentence and redundant with the one afer. > I suggest removing this clause. I've changed the wording slightly. > > packet format with a maximum size of 64K - 8 user data octets > ^ > (64k -1) eight-bit user data octets. Actually, 64K - 1 - 8 then, as I was removing the CRC, LEN, and reserved octets from the count to get actual user data length. > > not yet a conformance requirement of the ATM-FORUM. > ^--------------------------^ > specified by ITU-TS or good nit, thanks. re: atm address paragraph, some good nits, thanks. re: stations > members nit, thanks. re: other nits, thanks! Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18518; 22 Sep 93 17:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18514; 22 Sep 93 17:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07440; 22 Sep 93 17:26 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA21575; Wed, 22 Sep 93 13:04:05 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hpindlm.cup.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA21562; Wed, 22 Sep 93 13:04:04 -0700 Received: by hpindlm.cup.hp.com (16.6/15.5+IOS 3.20+cup+OMrelay) id AA23945; Wed, 22 Sep 93 13:04:04 -0700 Date: Wed, 22 Sep 93 13:04:04 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Subbu Subramaniam Message-Id: <9309222004.AA23945@hpindlm.cup.hp.com> To: atm@matmos.hpl.hp.com Subject: Re: Repost: RE: Classical Draft Status > > >> I consulted with a current implementer of the UNI 3.0 Q.93B (NRL) and >> they advised that the classical draft should not specify subaddresses >> for ARP. I would very much like to hear from other Q.93B UNI >> implementers at this time. > >to clarify this, the supposition was that an end node would recieve >a single address, either E.164 or NSAP (potentially only NSAP, using >the E164 encapsulation), and generate a call request with that >address. > >At the boundry of a network which only supported E164, the vc >routing/call setup mechansism would put the 'address' field in >the 'subaddress' field, and specify the E164 of the exit switch >from that public cloud in the 'address' (or 'number') field. > >This exit switch would then replace the place the subaddress in >the address again. > >As far as I can tell, this most closely models the use of the >subadress field as recommended in the UNI document. > Agree. >The only glitch in the above approach (as mentioned earlier on this >list) is a host directly attached to a network which supports >only E164. In this case, the result of the NSAP only ARP (if >only NSAPs were supported), would have to be unwrapped before the >call could be placed. Why not we indicate in the ARP response whether the hardware address is in E.164 format or NSAP format? The call initiator can then unwrap accordingly. > >The real argument is that subaddress/address really only belongs >in issues of vc routing and call setup, not as part of the >specification of an endpoint in the network. > -Subbu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19437; 22 Sep 93 18:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19433; 22 Sep 93 18:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10232; 22 Sep 93 18:20 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA26102; Wed, 22 Sep 93 14:03:08 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from noc.msc.edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26089; Wed, 22 Sep 93 14:03:06 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA23542; Wed, 22 Sep 93 16:03:07 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA27678; Wed, 22 Sep 93 16:03:12 -0500 Date: Wed, 22 Sep 93 16:03:12 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309222103.AA27678@uh.msc.edu> To: atm@matmos.hpl.hp.com Subject: Security Considerations Am I correct in assuming that nothing in the model prevents me, in a public network environment, from establishing a VC to your network, claiming to be part of your subnet, and establishing communications with your hosts? We may or may not want to make some observations in the security section of the draft. For example, o The model may want to simply rely upon the public network administrator to provide security in a PVC environment, (e.g., we hope they don't configure a PVC between us and our competitor). o The model might want to comment on security in an SVC, public network environment. - Perhaps, the model provides no security, and hopes that ATM facilities are available and used to prevent someone from calling our network claiming to be us. - Perhaps, the model wants to admit we haven't thought about security and that this is an area for future research; or - Perhaps, we don't really know how to do this, and hope that customers will demand that their vendors and service providers provide something. More free advice from, Tim Salo tjs@msc.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20012; 22 Sep 93 18:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20008; 22 Sep 93 18:56 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12131; 22 Sep 93 18:56 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28391; Wed, 22 Sep 93 14:31:43 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28377; Wed, 22 Sep 93 14:31:34 -0700 To: Joel Halpern Subject: Re: Repost: RE: Classical Draft Status In-Reply-To: <9309221900.AA17081@anubis.network.com> References: <9309221900.AA17081@anubis.network.com> Cc: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 22 Sep 93 14:31:33 -0700 Message-Id: <930922143133.6529@matmos.hpl.hp.com> Encoding: 14 TEXT, 2 TEXT SIGNATURE Joel writes: > Now, obviously the proposed approach is a good one for now. My concern is > that we have an obvious area here where good design will allow the mechanisms > to last much longer than otherwise. True, within a single LIS there is no > problem. But can we/should we design teh ARP mechanism to be more flexible? So you feel the current classical writeup is good for now - good. Can you say a little more on the idea in your last question? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20080; 22 Sep 93 19:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20076; 22 Sep 93 19:07 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12672; 22 Sep 93 19:07 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01253; Wed, 22 Sep 93 15:05:04 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01239; Wed, 22 Sep 93 15:05:03 -0700 Received: from nsco.network.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA21043; Wed, 22 Sep 93 15:05:31 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA16695; Wed, 22 Sep 93 17:08:02 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA19348; Wed, 22 Sep 93 17:03:21 CDT Date: Wed, 22 Sep 93 17:03:21 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309222203.AA19348@anubis.network.com> To: atm@matmos.hpl.hp.com Subject: Re: Repost: RE: Classical Draft Status Did you comment to me/the list about LIS/ARP get reposted for a reason? If you wish, you may post my response. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20116; 22 Sep 93 19:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20112; 22 Sep 93 19:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12845; 22 Sep 93 19:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA29791; Wed, 22 Sep 93 14:53:02 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from corp.timeplex.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA29775; Wed, 22 Sep 93 14:53:00 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id <01H39AKMWHAO8WWC4X@sys30.timeplex.com>; Wed, 22 Sep 1993 17:56:56 EDT Received: from localhost by maelstrom.timeplex.com (4.1/SMI-4.1) id AA20825; Wed, 22 Sep 93 17:55:05 EDT Date: 22 Sep 1993 17:55:03 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: Classical Draft Status (long) In-Reply-To: Your message of "Wed, 22 Sep 1993 11:38:33 PDT." <930922113833.6529@matmos.hpl.hp.com> To: Mark Laubach , atm@matmos.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com, malis@maelstrom.timeplex.com Message-Id: <9309222155.AA20825@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Mark, I would like to reiterate Dan's request that the draft be reissued before being "kicked out". In fact, do we really have enough consensus to send it out for Proposed? Perhaps we should discuss it more in Houston before putting the wraps on it. Cheers, Andy ____________________________________________________________________________ Andrew G. Malis malis_a@timeplex.com -or- malis@maelstrom.timeplex.com Ascom Timeplex 289 Great Rd., Acton MA 01720 USA +1 508 266-4522   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20149; 22 Sep 93 19:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20145; 22 Sep 93 19:14 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12967; 22 Sep 93 19:14 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27269; Wed, 22 Sep 93 14:15:46 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from picard.cmf.nrl.navy.mil by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27256; Wed, 22 Sep 93 14:15:45 -0700 Received: from tesuji.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA06528; Wed, 22 Sep 93 17:15:51 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: hoffman@cmf.nrl.navy.mil Received: by tesuji.cmf.nrl.navy.mil (4.1/client-1.3) id AA11038; Wed, 22 Sep 93 17:15:50 EDT Date: Wed, 22 Sep 93 17:15:50 EDT Message-Id: <9309222115.AA11038@tesuji.cmf.nrl.navy.mil> To: atm@matmos.hpl.hp.com Subject: public network vc routing (was Re: Repost: RE: Classical Draft Status) to respond to Joel Halpern who says: > 1) I do not expect the "public" services to assist us by propogating > prefix reachability information for private prefixes in their > "routing" technology. > 2) It is impossible for "everyone" to have private NNI adjacencies with > every other private party. based on past experience, it seems unlikely that the carriers will support some kind of unified inter-domain routing which interoperates with a large number private ATM networks. Perhaps we can agree then that given the state of indecision in the general model, a proposal which is consistent with the classic's status as an interim solution would be best. > True, within a single LIS there is no problem. But can we/should we > design teh ARP mechanism to be more flexible? There have been perfectly valid proposals which say that both addresses should be included in the ARP message, in the event that some future model will require them. I'm not sure if it was that, or something even more flexible that you intended (one way of viewing the address/subaddress in the q93b call mechansim is as a two-stage loose source route.) Just wanted to make clear from what arose our comments to Mark. In general, it's hard to come up with something lovely given the dichotomy of addressing.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20188; 22 Sep 93 19:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20184; 22 Sep 93 19:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13392; 22 Sep 93 19:20 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24272; Wed, 22 Sep 93 13:51:13 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from noc.msc.edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24259; Wed, 22 Sep 93 13:51:12 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA22861; Wed, 22 Sep 93 15:51:07 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA27506; Wed, 22 Sep 93 15:51:16 -0500 Date: Wed, 22 Sep 93 15:51:16 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309222051.AA27506@uh.msc.edu> To: atm@matmos.hpl.hp.com Subject: Re: confusing terminology > Date: Tue, 21 Sep 93 20:32:48 EDT > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > To: atm@hplms2.hpl.hp.com > Subject: confusing terminology > [...] > Avoiding use of the terms "public ATM" and "private ATM" will help us > evade much grief amongst readers of the draft both now and after it > appears in RFC form, IMHO. Whatever we do, we might want to define the terms we use. I think the distinction is important, even ignoring issues of UNIs and NNIs. I typically use "public" to desribe a network that is shared by several unrelated organizations and administered by some third party. An important attribute of public networks (in addition to third-pardy administration and cost sharing) is that security considerations become important. Tim Salo tjs@msc.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20486; 22 Sep 93 20:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20482; 22 Sep 93 20:05 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15900; 22 Sep 93 20:05 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04707; Wed, 22 Sep 93 15:37:33 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA04632; Wed, 22 Sep 93 15:37:26 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA07768; Wed, 22 Sep 93 15:37:13 PDT Received: by msgate.hls.com with Microsoft Mail id <2CA0D630@msgate.hls.com>; Wed, 22 Sep 93 15:48:16 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: Mark Laubach Cc: atm , Dan Grossman Subject: Re: Repost: RE: Classical Draft Status (absurdly long!!) Date: Wed, 22 Sep 93 15:36:00 PDT Message-Id: <2CA0D630@msgate.hls.com> Encoding: 241 TEXT X-Mailer: Microsoft Mail V3.0 Mark, >Thanks for your comments, a few of my own. Some (final!) comments on your comments. >To consider anything from the ATM-FORUM P-NNI is >premature at this point for the classical draft. The point, I think, is not to assume what the P-NNI protocol might or might not end up being, but to incorporate the architectural models underlying the current and prospective ATM Forum standards. The Classical ARP model, after all, needs to work in this context. >I consulted with a current implementer of the UNI 3.0 >Q.93B (NRL) and they advised that the classical draft >should not specify subaddresses for ARP. I agree, though the reasons, I think (see below), have nothing to do with how Q.93b might be implemented. >In your last paragraph, you recommend that we should >always use NSAP's and the E.164 should be a subadress. >This is syntactically not possible, Q.93B sub-addresses >are always NSAP's. The IETF should not dictate how >addresses are to be done in ATM, we have to cope with the >unfortunate world they have thrown up at us. I think we are in danger of confusing (and I agree with Dan's comments here), the syntax and use of the various address formats within an ATM network with what ARP should return. I don't think the two should be related, which is what your comments above imply. Whether or not Q.93b treats NSAP addresses as subaddresses or not (though this is the choice we made, which implies that the public network is a subnetwork of the private network, we could just as easily have done the opposite - we just didn't), the real issue for ARP is whether or not it should, or needs to, return either or both address formats. I still maintain that returning the NSAP address format alone is adequate (as I explain below). *If*, for whatever reason ARP decides to return both, then I think that it is more consistent with protocol layering, to treat the NSAP address as the main address, and the native E.164 address as the subnetwork address, regardless of how Q.93b might use the addresses. Given my first statement, however, I don't really care which way we go on this minor semantic issue, since I don't want to return subaddresses at all. >From an ATM-FORUM perspective the quote from the UNI 3.0 >spec with respect to subaddresses is (thanks to Bob >Cole): >> "The purpose of the Called party subaddress IE >> is to identify the subaddress of the called party of a >> call. It is used in this Implementation Agreement only >> to convey an ATM address in the OSI NSAP format across >> a public network which supports only E.164 addresses." True, but irrelevant to ARP - the purpose of ARP is to return adequate *addressing* information to allow connections to be set up between two (or more) IP end stations, which happen to sit on ATM networks. What the ATM network might choose to do with those addresses, or how the ATM network might be structured, is, and should be, irrelevant to the ARP mechanism. >I see this as more of ATM issue at this time. The >classical model would treat each NSAP lan as an LIS and >the E.164 network as another LIS. What you are talking >about gets into ARP'ing outside the normal LIS, which is >in our beyond-classical future. I'm afraid that I have to diasgree completely with this statment, which gets to the heart of the matter. Going top down, the goal of the ARP mechanism is to return adequate ATM addressing information to allow connections to be set up between two IP end stations, each of which is attached to an ATM network. ATM networks, as we have discussed at length on this group, can be of two types: those that participate in the P-NNI protocols, and use NSAP based addresses (I call these private networks, for short, noting all the usual caveats about Finnish Telecom, etc), and those that do not and will typically use native E.164 addresses (ditto, public networks, ditto). Note also that one of the three formats for the NSAP based addresses is NSAP encoded E.164 addresses; these are logically different from what we have been calling native E.164 addresses, and fall within the former, not the latter category. If nodes are attached to a private network, they will use one of the NSAP address formats; if the node is directly attached to a public network, then a connection request to that node must use the native E.164 format. The goal of the P-NNI protocols, and the ATM Forum UNI signaling specification, is to allow ATM connectivity between two or more nodes, *regardless* of which form of addressing is used by those nodes, and where they may be located. The issue for ARP, then is to know what information must be returned to allow such connectivity. Consider the following scenarios: a. Private host to Private Host, no intervening public transit network(s): Clearly requires that ARP return only the NSAP address format of the end host. b. Private host to Private host, through intervening public networks: In this case, the connection setup from host A to host B must transit the public network(s). This requires that at each ingress point to the public network that a routing decision be made as to which is the correct egress point from that public network to the next hop private ATM switch, and that the native E.164 address of that egress point be found (finding this is a VC routing problem, probably requiring configuration of the public network links and connectivity information). Then the well know mapping of the NSAP addresses to the sudaddress of the Q.93b request, etc, can be made. Does it make sense for the ARP mechanism to return the native E.164 addresses of these ingress and egress points? Clearly not, since it is, firstly, a routing and not an addressing issue, and secondly, because even if it did, there is no means currently defined in Q.93b to carry such (source routing) information. Hence ARP should return only the NSAP address of the endpoint, and let VC routing worry about the various address resolutions and subnetwork routing. c. Private Network Host to Public Network Host: This is the case that seems to have caused all the problems. First of all, I would say that it is clearly necessary to allow such a mixture of nodes to be in the same LIS (contrary to your asserstion above). After all, why not? If there can be ATM connectivity between such nodes, why should the IP layer and ARP care what format of addresses the nodes use, or what the structure of the ATM network is? This would be akin to saying that LAN nodes with different OUI values in their MAC addresses could not be in the same IP subnet! To get connectivity between the public node and the private nodes requires the same kind of routing information discussed above - namely, the directly attached public network needs to know the (NSAP format) ATM address of the private station, and the native E.164 address of the egress point from the public network to that private network (or to that of an intervening transit private network etc). There might be some argument (as I think Dan has advocated), that the ARP mechanism could return this egress point native E.164 address, but it is inconsistent for ARP to return what is clearly routing information, even if the ARP mechanism knew about it, which is unlikely. In the opposite direction, for the reasons mentioned in case (b) above, the private network node only can use, and should only get, the E.164 address of the directly attached public node. The question is, what format should this information be carried in? This question is clearly answered, I think, by Note 9 of Annex A of the ATM Forum UNI specification, Version 2.4 (passed by ballot recently to become Version 3.0), viz: "A call originated on a Private UNI destined for an end system which only has a native (non-NSAP) E.164 address (i.e. a system directly attached to a public network supporting the native E.164 format) will code the Called Party number information element in the (NSAP) E.164 private ATM Address Format, with the RD, AREA, and ESI fields set to zero. The Called Party Subaddress information element is not used." [Note that this is not implying that the P-NNI protocol will necessarily discover routes to/from E.164 addresses, regardless of their format, but that signaling requests with NSAP encoded E.164 addresses will probably be routed to some default egress point from the private to the public network]. Hence, even in this case, ARP should return the E.164 address of the public ATM station in NSAP format. This is essentially implying, as I've noted before, an algorithmic resolution between the native E.164 and NSAP addresses of _directly_ attached public stations. d. Public network host to Public network host, no intervening private network: In this case, clearly the Q.93b requests would use native E.164 address formats. This is the only case, it seems to me, where it might make sense for the ARP mechanism to return native E.164 formats only. I would suggest, however, that even in this case it is much more consistent to return these addresses also in the NSAP format, and allow the stations to map them into native E.164 format. The stations know, after all, that they are attached to a public network, and it is a trivial translation from the NSAP format to the native E.164 format. e. Public network host to Public network host, intervening private network: same as case (d) above, since getting to and through the private network is a VC routing, not an addressing issue. In summary, therefore, I still maintain that it is entirely possible, and more consistent, for the ARP mechanism to return only NSAP encoded addresses, and let the VC routing mechanisms worry about such ATM routing issues as getting to and from ATM subnetworks, such as public networks. Scenario (d) above does suggest that there are some (limited?) cases where returning native E.164 addresses is adequate - but it is not necessary, and it would, I think, be a lot less confusing to stick to one format. More importantly, I would strongly oppose the notion in the current draft that a LIS must use one and only one of the types of encoding; this restriction is both unnecessary and unduly restrictive. It may well be the case the *VC Routing* protocol may treat each of the address formats as belonging to different logical hierarchies, but as long as it guaranties (as it must) *connectivity* between nodes using different formats, the ARP mechanism should not care. Anthony. ps. We've probably had too much discussion on this issue - no more missives from me - back to my real job!! (many sighs of relief from everyone having to read this stuff...) :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21363; 22 Sep 93 22:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21359; 22 Sep 93 22:07 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21717; 22 Sep 93 22:07 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02855; Wed, 22 Sep 93 15:21:34 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02842; Wed, 22 Sep 93 15:21:33 -0700 Date: Wed, 22 Sep 93 15:21:33 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309222221.AA02842@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: The nit'ted Classical Draft ATM'ers: Well, the mail loops have been fixed - so this is the only copy you should receive. Again, many applogies..... The editorial nit's are now exchanging better phrases so that means we're very close, in fact I believe this is now our starting point. There has been sufficient talk about subaddresses, security, negotiations, et al. that we need to have our framework document completed so that we understand how we take the next step from the classical model. I'd like to encourage us now to discuss that framework now using the classical model as the starting point. The rough consensous I've seen and received to date, is that we move ahead with pushing this draft to proposed status. Mark ------------------------------------------------------------------------ Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires March 22, 1994 September 22, 1993 Classical IP and ARP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo defines an initial application of classical IP, ARP, and Inverse ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This memo does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards. Laubach [Page 1] DRAFT Classical IP and ARP over ATM September 1993 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF and the ad hoc PVC committee at the Amsterdam IETF meeting. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Note: this memo defines only the operation of IP and ARP over ATM, and is not meant to describe the operation of ATM networks Initial deployment of ATM provides a LAN segment replacement for local area networks (e.g., Ethernets, Token Rings and FDDI) and as replacement for dedicated circuits or frame relay PVCs between IP routers. In the former case, local IP routers with one or more ATM interfaces will connect islands of ATM networks. In the latter case, public or private ATM Wide Area networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. ATM WANs and LANs may be interconnected. Private ATM networks (local or wide area) will use the private ATM address structure specified in the ATM Forum UNI specification [9]. This structure is modeled after the format of an OSI Network Service Access Point Address. A private ATM address uniquely identifies an ATM endpoint. Public networks will use either the address structure Laubach [Page 2] DRAFT Classical IP and ARP over ATM September 1993 specified in ITU-TS recommendation E.164 or the private network ATM address structure. An E.164 address uniquely identifies an interface to a public network. The characteristics and features of ATM networks are different than those found in LANs: o ATM provides a Virtual Channel (VC) switched environment. VC setup may be done on either a Permanent Virtual Channel (PVC) or dynamic Switched Virtual Channel (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). o The function of mapping user PDUs (Protocol Data Unit) into the information field of the ATM cell and vice versa is performed in the ATM Adaptation Layer (AAL). When a VC is created a specific AAL type is associated with the VC. There are four different AAL types, which are referred to individually as "AAL1", "AAL2", "AAL3/4", and "AAL5". (Note: this memo concerns itself with the mapping of IP and ARP over AAL5 only. The other AAL types are mentioned for introductory purposes only.) The AAL type is known by the VC end points via the call setup mechanism and is not carried in the ATM cell header. For PVCs the AAL type is administratively configured at the end points when the channel (circuit) is set up. For SVCs, the AAL type is communicated along the VC path via Q.93B as part of call setup establishment and the end points use the signaled information for configuration. ATM switches generally do not care about the AAL type of VCs. The AAL5 format specifies a packet format with a maximum size of (64K -1 -8) octets of user data. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating the end of the PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. NOTE: AAL5 provides a non-assured data transfer service - it is up to higher-level protocols to provide retransmission. o ATM Forum signalling defines point-to-point and point-to- multipoint channel setup [9]. Multipoint-to-multipoint VCs are not yet specified by ITU-TS or ATM Forum. o An ATM address may comprise an ATM Forum ATM endpoint address (NSAP), or an E.164 Public UNI address [9]. In some cases, both an ATM endpoint address and an E.164 Public UNI address are needed by an ARP client to reach another host or router. Since the use of ATM endpoint addresses and E.164 public UNI addresses by ARP are analogous to the use of Ethernet addresses, the notion Laubach [Page 3] DRAFT Classical IP and ARP over ATM September 1993 of "hardware address" is extended to encompass ATM addresses in the context of ARP, even though ATM addresses need not have hardware significance. ATM Forum NSAPs use the same basic format as U.S. GOSIP NSAPs [11]. Note: ATM Forum addresses should not be construed as being U.S. GOSIP NSAPs, they are not, the administration is different, which fields get filled out are different, etc. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets. o End-to-end IP routing architecture stays the same. o IP addresses are resolved to ATM addresses by use of an ARP service within the LIS - ARPs stay within the LIS. ARP architecture stays essentially the same, consistent with current model. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for all these VCs. The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VCs (e.g., TCP and UDP ports map directly onto VCs) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. Laubach [Page 4] DRAFT Classical IP and ARP over ATM September 1993 o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Applications map directly to VCs, requiring changes to TCP/UDP/IP to allow ports to map directly on to VCs o ARPs are global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per application and per VC basis. The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. o Standards for global IP over ATM will take some time to complete and deploy. This memo details the treatment of the classical model of IP and ARP over ATM. There are those who would like to have IP-over-ATM begin by breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LISs over the same ATM network. Hosts connected to ATM communicate directly to other Laubach [Page 5] DRAFT Classical IP and ARP over ATM September 1993 hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM Endpoint attached to the ATM network that is configured as a member of two or more LISs. This configuration may result in a number of disjoint LISs operating over the same ATM network. Hosts of differing IP subnets must communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network. The requirements for IP members (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All members within an LIS are accessed directly over the ATM network. o All members outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [3] and vice versa via InARP[12] when using SVCs. o All members of an LIS must have a mechanism for resolving VCs to IP addresses via InARP [12] when using PVCs. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the virtual channel topology underlying the intercommunication among the members is fully meshed. There should be no administrative restrictions at the ATM level that prevent VCs from operating between all pairs of end points. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM address of the individual IP station. o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target ATM addresses for SVC connections. That server must have authoritative responsibility for resolving ARP requests of all IP members within the LIS. Note: if the LIS is operating with PVCs only, then this parameter may be set to null and the IP station is not required to send ARP requests to Laubach [Page 6] DRAFT Classical IP and ARP over ATM September 1993 the ARP server. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LISs. Routers that wish to provide interconnection of differing LISs MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams. This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. 8. MTU Size The default MTU size for IP members operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the default ATM AAL5 protocol data unit size is 9188 octets. In classical IP subnets, values other than the default can only be used if and only if all members in the LIS have been configured to use the non-default value. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. ADDRESS RESOLUTION Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12] and all IP members are required to support these protocols as updated and extended in this memo. Use of these protocols differ depending on whether PVCs or SVCs are used. Laubach [Page 7] DRAFT Classical IP and ARP over ATM September 1993 Permanent Virtual Channels An IP station must have a mechanism for determining what PVCs it has, and in particular which PVCs are being used for LLC/SNAP encapsulated protocols. The details of the mechanism are beyond the scope of this memo. All IP members supporting PVCs are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those VCs using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant VC from the VC on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM source and/or target address is unknown, the corresponding ATM address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. Directly from [12]: "When the requesting station receives the InARP reply, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances." It is the responsibility of each IP station supporting PVCs to re-validate ARP table entries as part of the aging process. See the section below on "ARP Table Aging". Switched Virtual Channels SVCs require support for ARP in the non-broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for resolving the ARP requests of all IP members within the LIS. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point VC. The server, upon the completion of an ATM call/connection of a new VC specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. The ARP server mechanism requires that each client be administratively configured with the ATM address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. It is Laubach [Page 8] DRAFT Classical IP and ARP over ATM September 1993 recommended that the ARP server also be an IP station. This station must be administratively configured to operate and recognize itself as the ARP server for a LIS. The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. This memo recognizes that a single ARP Server is not as robust as multiple servers which synchronize their databases correctly. This document is defining the client-server interaction by using a simple, single server approach as a reference model, and does not prohibit more robust approaches which use the same client-server interface. ARP Server Operational Requirements The ARP server accepts ATM calls/connections from other ATM end points. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM address. The server will add (or update) the map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP ATM address does not match the table entry ATM address and there is an open VC associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table otherwise a negative ARP reply (ARP_NAK). The ARP_NAK response is an extension to the ARP protocol and is used to improve the robustness of the ARP server mechanism. With ARP_NAK, a client can determine the difference between a catastrophic server failure and an ARP table lookup failure. The ARP_NAK packet format is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for transmission with the ARP_REQUEST operation code reset to ARP_NAK. Updating the ARP table information timeout, the short form: when the server receives an ARP request over a VC, and the source IP and ATM address match the association already in the ARP table, and the ATM address matches that associated with the VC (in the SVC environment), then the server may update the timeout on the ARP table entry: i.e., if the client is sending ARP requests to the server over the same VC that was used to "install" the ARP entry for the client, the server should examine the ARP requests and note that the client is still Laubach [Page 9] DRAFT Classical IP and ARP over ATM September 1993 "alive" and update the timeout on the clients ARP table entry. ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh its own ARP entry/information about other IP members. This means, as noted above, that ARP clients must be configured with the ATM address of the ARP server. ARP clients must: 1. Initiate the VC connection to the ARP server for transmitting and receiving ARP and InARP packets. 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh its own client ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP its own client table entries. 5. Provide an ARP table aging function to remove is own old client ARP tables entries after a convenient period of time. Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. ARP Table Aging An ARP client or server must have knowledge of any open VCs it has (permanent or switched), their association with an ARP table entry, and in particular, which VCs support LLC/SNAP encapsulation. Client ARP table entries are valid for a maximum time of 15 minutes. Server ARP table entries are valid for a minimum time of 20 minutes. Prior to aging (removing) an ARP table entry, all members must generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the entry is deleted. Laubach [Page 10] DRAFT Classical IP and ARP over ATM September 1993 ARP and InARP Packet Format Internet addresses are assigned independent of ATM addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. IP members MUST also use ARP and InARP to resolve IP addresses to ATM addresses when needed and vice versa. The ARP and InARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length of source ATM address (q) ar$sstl 8 bits Type & length of source ATM subaddress (r) ar$op 16 bits Operation code (request or reply) ar$spln 8 bits Length of source protocol address (s) ar$thtl 8 bits Type & length of target ATM address (x) ar$tstl 8 bits Type & length of target ATM subaddress (y) ar$tpln 8 bits Length of target protocol address (z) ar$sha qoctets source ATM address ar$ssa roctets source ATM subaddress ar$spa soctets source protocol address ar$tha xoctets target ATM address ar$tsa yoctets target ATM subaddress ar$tpa zoctets target protocol address Where: ar$hrd - assigned to ATM Forum address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$op - The operation type value (decimal): ARP_REQUEST = 1 ARP_REPLY = 2 InARP_REQUEST = 8 InARP_REPLY = 9 ARP_NAK = ?? ar$spln - length in octets of the source protocol address. For IP ar$spln is 4. ar$tpln - length in octets of the target protocol address. For IP ar$tpln is 4. Laubach [Page 11] DRAFT Classical IP and ARP over ATM September 1993 ar$sha - source ATM address (E.164 or ATM Forum NSAP) ar$ssa - source ATM subaddress (ATM Forum NSAP) ar$spa - source protocol address ar$tha - target ATM address (E.164 or ATM Forum NSAP) ar$tha - target ATM subaddress (ATM Forum NSAP) ar$tpa - target protocol address The encoding of the 8-bit type and length value for ar$shtl, ar$sstl, ar$thtl, and ar$tstl is as follows: MSB 8 7 6 5 4 3 2 1 LSB +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1/0 | Octet length of address | +-----+-----+-----+-----+-----+-----+-----+-----+ Where: bit.8 (reserved) = 0 (for future use) bit.7 (type) = 0 ATM Forum NSAP address = 1 E.164 address bit.6-1 (length) = 6 bit unsigned octet length of address (MSB = bit.6, LSB = bit.1) ATM addresses in Q.93B (as defined by the ATM Forum [9]) include a "Calling Party Number Information Element" and a "Calling Party Subaddress Information Element". These Information Elements (IEs) map to ARP/InARP source ATM address and source ATM subaddress respectively. Furthermore, ATM Forum defines a "Called Party Number Information Element" and a "Called Party Subaddress Information Element". These IEs map to ARP/InARP target ATM address and target ATM subaddress respectively. Furthermore, the ATM Forum defines three cases for the combined use of address and subaddresses: ATM Address ATM Subaddress ------------------ --------------- Case 1 ATM Forum NSAP null Case 2 E.164 null Case 3 E.164 ATM Forum NSAP Laubach [Page 12] DRAFT Classical IP and ARP over ATM September 1993 ARP use of ATM Address for Case 1 and Case 2 The ATM address in ARP packets (ar$sha, ar$tha) SHALL be E.164 or ATM Forum NSAP [9]. Within the LIS, either E.164 or ATM Forum NSAP address may be used but not both. If ATM Forum NSAP address are used, then the same NSAP encoding MUST be used within an LIS and replies will use the same encoding as queries. For example, NSAPs may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 ATM addresses may be used but not both. ARP use of ATM Subaddress for Case 1, Case 2, and Case 3 This memo has defined the ATM subaddress type/length and fields as part of the ARP packet format. Use of the ATM subaddress is beyond the scope of this memo. Implementations based on this memo, must set ar$sstl.type = 1 and ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0 when generating ARP and InARP requests and replies. Furthermore, implementations upon receiving ARP or InARP requests and replies, must tolerate non-zero subaddress lengths and ignore subaddress field values. The definition of ARP and InARP utilizing both ATM addresses and subaddresses will be defined in a future document. ARP/InARP Packet Encapsulation ARP and InARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDUs is: Payload Format for Routed non-ISO PDUs +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP/InARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header. Laubach [Page 13] DRAFT Classical IP and ARP over ATM September 1993 The OUI value of 0x00-00-00 (3 octets) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 CPCS-SDU. The LLC/SNAP encapsulation for ARP/InARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP members within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ARP'ing outside the LIS or by a global ARP mechanism are beyond the scope of this memo. 10. IP Broadcast Address ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict members from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Members, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. This memo recognizes the future development of ATM multicast service addressing by the ATM Forum. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward. 12. Security Security issues are not discussed in this memo. Laubach [Page 14] DRAFT Classical IP and ARP over ATM September 1993 This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this memo. 13. Open Issues o The ARP hardware address type value for ATM Forum and the ARP_NAK operation type value need yet to be assigned by the Internet Assigned Numbers Authority (IANA) o Well known ATM address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. Laubach [Page 15] DRAFT Classical IP and ARP over ATM September 1993 [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM Forum, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", ATM Forum, 480 San Antonio Road, Suite 100, Mountain View, CA 94040, June 1993. [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, USC/Information Sciences Institute, August 1989. [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, USC/Information Sciences Institute, July 1991. [12] Bradely, T., and Brown, C., "Inverse Address Resolution Protocol", RFC1293, USC/Information Sciences Institute, January 1992. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 16]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21447; 22 Sep 93 22:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21443; 22 Sep 93 22:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22135; 22 Sep 93 22:17 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11741; Wed, 22 Sep 93 18:14:28 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11726; Wed, 22 Sep 93 18:14:25 -0700 To: "Alles, Anthony" Cc: atm@matmos.hpl.hp.com, Dan Grossman Subject: Re: Repost: RE: Classical Draft Status (absurdly long!!) In-Reply-To: <0.2CA0D630@msgate.hls.com> References: <0.2CA0D630@msgate.hls.com> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 22 Sep 93 18:14:25 -0700 Message-Id: <930922181425.6529@matmos.hpl.hp.com> Encoding: 51 TEXT, 2 TEXT SIGNATURE Anthony, I really like the long response you put together and I think it will help us considerably in shaping the framework model. So the time spent away from work was worth it. Thanks! > ...The goal of > the P-NNI protocols, and the ATM Forum UNI signaling > specification, is to allow ATM connectivity between two or > more nodes, *regardless* of which form of addressing is > used by those nodes, and where they may be located. I completely agree. Again, that is beyond the scope of the classical model. > In summary, therefore, I still maintain that it is > entirely possible, and more consistent, for the ARP > mechanism to return only NSAP encoded addresses, and let > the VC routing mechanisms worry about such ATM routing > issues as getting to and from ATM subnetworks, such as > public networks. Scenario (d) above does suggest that > there are some (limited?) cases where returning native > E.164 addresses is adequate - but it is not necessary, and > it would, I think, be a lot less confusing to stick to > one format. Again, I completely agree with you but VC-routing mechanisms are not defined yet. From an implementation standpoint, they aren't here yet. > More importantly, I would strongly oppose the notion in > the current draft that a LIS must use one and only one > of the types of encoding; this restriction is both > unnecessary and unduly restrictive. It may well be the > case the *VC Routing* protocol may treat each of the > address formats as belonging to different logical > hierarchies, but as long as it guaranties (as it must) > *connectivity* between nodes using different formats, the > ARP mechanism should not care. Yes, but it is the consensous of the WG that we walk before we run and we've already made the decision about the nature of LISs and the scope/reach of ARP within an LIS. The models that you suggest come after the classical starting point. Bob Cole: can you incorporate treatment of Anthony's models in the framework document? You can shoot me down on this, but I really want to toe the line on the classical model for this draft. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21544; 22 Sep 93 22:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21540; 22 Sep 93 22:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22424; 22 Sep 93 22:23 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10350; Wed, 22 Sep 93 18:09:02 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10337; Wed, 22 Sep 93 18:09:01 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA21601; Wed, 22 Sep 1993 20:09:10 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA10401; Wed, 22 Sep 1993 20:09:07 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA00463 (5.65a+/IDA-1.4.2 for atm@matmos.hpl.hp.com); Wed, 22 Sep 93 21:09:03 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA09732 (5.65a+/IDA-1.4.2 for dan@merlin.dev.cdx.mot.com); Wed, 22 Sep 93 21:09:02 -0400 Message-Id: <9309230109.AA09732@dbg.dev.cdx.mot.com> To: atm@matmos.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com Subject: Re: Classical Draft Status (long) In-Reply-To: Your message of "22 Sep 93 17:55:03 EDT." <9309222155.AA20825@maelstrom.timeplex.com> Date: Wed, 22 Sep 93 21:09:01 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > Mark, > > I would like to reiterate Dan's request that the draft be reissued > before being "kicked out". In fact, do we really have enough > consensus to send it out for Proposed? Perhaps we should discuss it > more in Houston before putting the wraps on it. > > Cheers, > Andy >____________________________________________________________________________ > Andrew G. Malis malis_a@timeplex.com -or- malis@maelstrom.timeplex.com > Ascom Timeplex 289 Great Rd., Acton MA 01720 USA +1 508 266-4522 At risk of being accused yet again of standing in the way of progress, I agree with Andy. The present differences on ATM addressing issues (and the subtle architectural questions they imply) and some of the other items imply to me that there may be a problem.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22690; 22 Sep 93 22:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22686; 22 Sep 93 22:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22739; 22 Sep 93 22:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08284; Wed, 22 Sep 93 17:51:34 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08269; Wed, 22 Sep 93 17:51:32 -0700 To: Ran Atkinson Cc: atm@matmos.hpl.hp.com, mankin@itd.nrl.navy.mil Subject: Re: comment on Classical IP/ATM draft In-Reply-To: <9309230026.AA06951@itd.nrl.navy.mil> References: <9309230026.AA06951@itd.nrl.navy.mil> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 22 Sep 93 17:51:31 -0700 Message-Id: <930922175131.6529@matmos.hpl.hp.com> > I propose revising the security section slightly. The original is > presented first and then my proposed revision is presented for your > consideration. A shade under the wire, but I really like the revision. Consider it in. > Other than this I'm happy with the draft as it stands now. Great! ATM'ers, please logically replace section 12 with Ran's revision. This is the last wording change for the classical draft. Thanks Ran! Mark Ran's revision: > ---------------------------------------------------------------------- > 12. Security > > Not all of the security issues relating to IP over ATM are clearly > understood at this time, due to the fluid state of ATM specifications, > newness of the technology, and other factors. > > It is believed that ATM and IP facilities for authenticated call > management, authenticated end-to-end communications, and data encryption > will be needed in globally connected ATM networks. Such future > security facilities and their use by IP networks are beyond the scope > of this memo. > > There are known security issues relating to host impersonation via the > address resolution protocols used in the Internet. No special security > mechanisms have been added to the address resolution mechanism defined > here for use with networks using IP over ATM. [Insert reference to: > "Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", > ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989]. > ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24996; 22 Sep 93 23:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24992; 22 Sep 93 23:08 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24115; 22 Sep 93 23:08 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14429; Wed, 22 Sep 93 19:02:02 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14416; Wed, 22 Sep 93 19:02:01 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA21421; Wed, 22 Sep 93 19:02:05 -0700 Received: from genesis.iti.gov.sg by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA22288; Wed, 22 Sep 93 19:02:24 -0700 Received: from atlas.iti.gov.sg by iti.gov.sg (4.1/SMI-4.1) id AA02735; Thu, 23 Sep 93 10:01:23 SST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Sreedharan Bhaskaran (ATM" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9309230201.AA02735@iti.gov.sg> Subject: Re: UNH/IOL ATM Interoperability Lab To: atm@hplms2.hpl.hp.com Date: Thu, 23 Sep 93 10:02:24 WST Cc: "Sreedharan Bhaskaran (ATM" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US In-Reply-To: <9309211158.AA11444@sun4.iol.unh.edu>; from "Ronald W. Pashby" at Sep 21, 93 7:58 am X-Mailer: ELM [version 2.3 PL11] Hi Ron, Please provide me with more information on UNH-IOL and the results of the meeting. I will not be able to attend the meeting. best regards, Sree -------------------------------------------------------------------------- Sreedharan Bhaskaran | Tel: (65)-772-0409 Multimedia Communications | Fax: (65)-777-3043 Information Technology Institute | National Computer Board | email: sree@iti.gov.sg 71 Science Park Drive | NCB Building | Singapore 0511 | Republic Of Singapore | -------------------------------------------------------------------------- > > The University of New Hampshire's Interoperability Lab is announcing the > formation of the ATM Consortium. The initial meeting will be held on October 8, > at the Ilumni Center of UNH. This is an informational meeting, as well as a > charter membership meeting. Attendance does not obligate individuals or > organizations in any way. All interested parties should contact Ron Pashby > by calling (603)862-0204 or via email to pashby@unh.edu. If you are > interested, but are not available to attend, we would be happy to provide > you with further information and results of the meeting. > > Please feel free to forward this message to anyone that you think might be > interested in this information and CC to pashby@unh.edu. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28561; 22 Sep 93 23:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28557; 22 Sep 93 23:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26008; 22 Sep 93 23:58 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16648; Wed, 22 Sep 93 19:59:41 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16629; Wed, 22 Sep 93 19:59:40 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA21614; Wed, 22 Sep 93 19:59:49 -0700 Received: from nisc.jvnc.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA23026; Wed, 22 Sep 93 20:00:05 -0700 Received: from secureSUN250.timeplex.com by nisc.jvnc.net (5.65/1.34) id AA28631; Wed, 22 Sep 93 22:58:20 -0400 Received: from wwtc.timeplex.com by bigguy.timeplex.com (4.1/SMI-4.1) id AA05293; Wed, 22 Sep 93 22:56:52 EDT Received: from Sys100.westwood by wwtc.timeplex.com (4.1/SMI-4.1) id AA06205; Wed, 22 Sep 93 19:38:50 PDT Date: Wed, 22 Sep 93 19:38:50 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Andy Weingarten (ext 793" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9309230238.AA06205@wwtc.timeplex.com> To: atm@hplms2.hpl.hp.com Subject: Mailing List Please remove me from this list. Thanks   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29232; 23 Sep 93 0:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29228; 23 Sep 93 0:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa27630; 23 Sep 93 0:40 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18293; Wed, 22 Sep 93 20:36:17 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from noc.msc.edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18280; Wed, 22 Sep 93 20:36:16 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA11088; Wed, 22 Sep 93 22:36:19 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA00940; Wed, 22 Sep 93 22:36:24 -0500 Date: Wed, 22 Sep 93 22:36:24 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9309230336.AA00940@uh.msc.edu> To: atm@matmos.hpl.hp.com Subject: Classic Draft - Scope Neither the appropriate scope nor the indended scope of the classical draft is clear to me. I assume, not necessarily correctly, that the principal characteristic of the "classical" model is that the IP routing decision is unchanged; namely, that an IP host can forward an IP packet to only hosts which are on the same subnet. The "classical" draft seems to address only one specific instance of my broader understanding of the "classical" model, namely, the LIS model where IP hosts are connected by a full mesh of PVCs or potentially established SVCs. I suspect the draft, as it stands, does not adequately address my broader understanding of the "broad" model. It doesn't seem to work in PVC-only ATM networks (the only kind of public wide-area network we are likeky to have this year and perhaps next year). We might also recommend that this model not be used in a public ATM network until we have a better handle on security. -tjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01236; 23 Sep 93 3:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01232; 23 Sep 93 3:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02690; 23 Sep 93 3:43 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA26358; Wed, 22 Sep 93 23:40:33 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from dxmint.cern.ch by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26345; Wed, 22 Sep 93 23:40:31 -0700 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04828; Thu, 23 Sep 1993 08:40:40 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA12029; Thu, 23 Sep 1993 08:40:38 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309230640.AA12029@dxcern.cern.ch> Subject: Re: Classic Draft - Scope To: atm@matmos.hpl.hp.com Date: Thu, 23 Sep 1993 08:40:37 +0200 (MET DST) In-Reply-To: <9309230336.AA00940@uh.msc.edu> from "Tim Salo" at Sep 22, 93 10:36:24 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1656 >--------- Text sent by Tim Salo follows: > > Neither the appropriate scope nor the indended scope of the classical draft > is clear to me. > > I assume, not necessarily correctly, that the principal characteristic > of the "classical" model is that the IP routing decision is unchanged; > namely, that an IP host can forward an IP packet to only hosts which > are on the same subnet. > > The "classical" draft seems to address only one specific instance of > my broader understanding of the "classical" model, namely, the LIS model > where IP hosts are connected by a full mesh of PVCs or potentially > established SVCs. This is *all* it is intended to address, to my understanding. > > I suspect the draft, as it stands, does not adequately address my > broader understanding of the "broad" model. It isn't meant to. > It doesn't seem to work > in PVC-only ATM networks (the only kind of public wide-area network we > are likeky to have this year and perhaps next year). It will work in small private ATM LANs with PVCs or large ones with SVCs. That is its scope as I understand it. > We might also > recommend that this model not be used in a public ATM network until > we have a better handle on security. > This would be wise :-) Most of the mails of the last few days are as far as I'm concerned OUTSIDE THE SCOPE OF the classical draft, and should be held until we see the next draft of the framework document (RSN). Look, companies are shipping incompatible IP over ATM LAN products today! We need the classical document yesterday. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04774; 23 Sep 93 8:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04770; 23 Sep 93 8:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11145; 23 Sep 93 8:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28761; Thu, 23 Sep 93 00:46:49 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA28748; Thu, 23 Sep 93 00:46:44 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA22893; Thu, 23 Sep 93 00:46:54 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA06709; Thu, 23 Sep 93 08:45:26 +0100 Received: from ben.Britain.EU.net by hplb.hpl.hp.com; Thu, 23 Sep 93 08:36:00 +0100 Message-Id: <9309230736.AA00863@hplb.hpl.hp.com> Received: from cs.ucl.ac.uk by ben.britain.eu.net via JANET with NIFTP (PP) id ; Thu, 23 Sep 1993 08:46:28 +0100 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Sep 1993 08:46:11 +0100 To: atm@hpl.hp.co.uk Cc: curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: Your message of "Wed, 22 Sep 93 14:12:42 CDT." <199309221812.AA34857@foo.ans.net> Date: Thu, 23 Sep 93 08:46:07 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Crowcroft >> > I suspect that we will discover that TCP over ATM on big pipes is unstable >> > (In a control theory sense), and we will have to make some changes. One of the >> > "easy" fixes would be to add forward error correction at the AAL layer..... >> > Another would be to convince the switch vendors to do frame dropping.... >> > (If you drop a low priority cell, drop all until the next high priority cell). >> >> This is a potentially big problem. Gary Anido at the University of >> Wollongong has done some work which suggests that bursty data traffic >> (i.e. TCP) can only achieve low utilisations (maybe 30%, from memory) >> on ATM before cell dropping due to switch congestion becomes significant. >> I know he's been working on the design of a device to plug in upstream >> of switch queues and control admission of frames. I'm just guessing, >> but might another solution not be a new set of congestion control >> algorithms ;-). There are 2 seperate problems: 1. one is stability of the control algorithms in TCP over long fast pipes - if you havnt read any of the work on this by borman, jacobson & braden & partridge et al, then first go away and read it (e.g. RFCs on high perf tcp, rfc1323) - it is a solved problem 2. the second problem is cell loss versus frame loss versus TCP segment loss - you need two levels of analysis to cope with this - one is that cell loss must be scattered in bursts so it tends to hit single packets rather than one cell evenly per packet in a flow... the second is that we'd really like burst level buffering to cope with quite a few packets for the transients as tcp fills and empties pipes... any other mechanism is a waste of breath, except if you expect to police data traffic rates - now you could do this, but what is a senisble rate? - the only really sensible rate is determined by a true end system - e.g. in a file transfer, it is the receivers' disk speed - anything else is some bizarre function of the carriers inability to cope with bursts rates rather than the users actual abstract "load" (why charge differently that total packets txferred?, if i send faster, i send proportonally for less time...) >Statements like "some work which suggests that bursty data traffic >(i.e. TCP) can only achieve low utilisations (maybe 30%, from memory) >on ATM before ..." can be misleading. You can get the utilizations up >much higher if you provide adequate queueing. The problem is that the >queueing in current IP routers strives to reach 1-2 times the delay >bandwidth product while some telephone switch vendors who are now >making ATM switches think 256 cells is more buffering than anyone >would ever need. Others have conceeded and put in 4K to 16K cells, >still not enough. right - however, i have seen rumoured work items i nteh ATM drafts that accidently cross my desk that people are asking for 8k cell buffering, which would greatly ease the problem take a 70000 dollar 16 port switch - just how much extra would it cost to but 8Mbytes of buffering on every port? answer, not a lot. >At OC3 speed (155 mbps - the switches have to forward the overhead) >and US coast to coast 70 msec RTT, this yields 1.3 MB. Add Hawaii or >Alaska and get 2.3 MB. Two times the D-BW product would be preferred. >256 cells is 12KB, less than 2 full MTU IP packets. 16,000 is 768 KB >which is at least getting close. At this point, all you have to worry >about is the magnification of cell drop into packet drop if you don't >drop full AAL frames. yes - but if you hae a stupid switchdesigned for a lot of teleophone (or CBR video) calls it will always systematically drop cells and systematically do badly! >I've seen simulations and actual test results that suggest that with >adequate queueing and no other change, you can get over 90% >utilization, but not the near 100% utilization that you could get at a >bottleneck with multiple TCP over packet IP with adequate queueing. >Of course, if you do more, like drop complete AAL frames, you'll do a >little better. If you don't provide enough queueing, you'll do worse, >much worse if you try hard enough. thanks for the analysis - i thoroughly agree! jon   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08312; 23 Sep 93 9:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08308; 23 Sep 93 9:56 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16967; 23 Sep 93 9:56 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05144; Thu, 23 Sep 93 04:11:51 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05131; Thu, 23 Sep 93 04:11:50 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA23483; Thu, 23 Sep 93 04:12:00 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA12629; Thu, 23 Sep 93 12:10:27 +0100 Received: from eros.Britain.EU.net by hplb.hpl.hp.com; Thu, 23 Sep 93 12:01:04 +0100 Received: from ncp.gpt.co.uk by eros.britain.eu.net with UUCP id ; Thu, 23 Sep 1993 12:11:35 +0100 Received: from lepy08 by cyclops with SMTP (5.67/16.2) id AA28487; Thu, 23 Sep 93 11:59:43 +0100 Received: by lepy08 (5.65a/MAIL-09) id AA15384; Thu, 23 Sep 93 11:57:52 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Jeffrey Message-Id: <9309231057.AA15384@lepy08> Subject: Re: Classical Draft Status To: atm@hpl.hp.co.uk Date: Thu, 23 Sep 93 11:57:51 GMT-0:00 In-Reply-To: <9309230736.AA00863@hplb.hpl.hp.com>; from "Jon Crowcroft" at Sep 23, 93 8:46 am X-Mailer: ELM [version 2.3 PL11/DDS1.2a] Jon Crowcroft writes: > >right - however, i have seen rumoured work items i nteh ATM drafts >that accidently cross my desk that people are asking for 8k cell >buffering, which would greatly ease the problem > >take a 70000 dollar 16 port switch - just how much extra would it cost >to but 8Mbytes of buffering on every port? answer, not a lot. Depends on whether your switch design relies on on-chip RAM or can use commercial DRAMs. For the next generation of Vision O.N.E ATM switch, GPT and Siemens are now thinking in terms of 256k cells of output buffering, shared between 16 STM-1 ports, which should keep you all happy. Obviously, delay sensitive traffic cannot tolerate this, so we also have to be clever with buffering different traffic types. We now have a really neat algorithm for this, but no I'm not going to tell you about it. -- Mark Jeffrey, GPT ltd, mtj@ncp.gpt.co.uk   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11173; 23 Sep 93 11:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11169; 23 Sep 93 11:04 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20902; 23 Sep 93 11:04 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA09467; Thu, 23 Sep 93 06:38:10 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nsco.network.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA09454; Thu, 23 Sep 93 06:38:08 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA19481; Thu, 23 Sep 93 08:41:50 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA23129; Thu, 23 Sep 93 08:37:08 CDT Date: Thu, 23 Sep 93 08:37:08 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309231337.AA23129@anubis.network.com> To: atm@matmos.hpl.hp.com Subject: Re: public network vc routing (was Re: Repost: RE: Classical Draft Status) Given that there was apparently some room for mis-interpretting my comments, I just wish to issue a small clarification: The intend of my previous message (about boundary address translation) was to make a plea for retaining the dual address element support which Mark recently added to the Draft. I was afraid that without some counter comments, people would think we should remove that element, based on the comments from Hoffman and others (which realistically reflect what can and should be done now, in an operational sense). Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12952; 23 Sep 93 11:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12945; 23 Sep 93 11:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23508; 23 Sep 93 11:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11969; Thu, 23 Sep 93 07:51:58 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from dxmint.cern.ch by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11956; Thu, 23 Sep 93 07:51:55 -0700 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22608; Thu, 23 Sep 1993 16:52:07 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA29440; Thu, 23 Sep 1993 16:51:08 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9309231451.AA29440@dxcern.cern.ch> Subject: Re: public network vc routing (was Re: Repost: RE: Classical Draft Status) To: atm@matmos.hpl.hp.com Date: Thu, 23 Sep 1993 16:51:07 +0200 (MET DST) In-Reply-To: <9309231337.AA23129@anubis.network.com> from "Joel Halpern" at Sep 23, 93 08:37:08 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: 964 Thank YOU, Joel. The latest draft is the first one where I feel comfortable that all reasonable addressing scenarios are covered. Removing this would be a great step backwards. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by Joel Halpern follows: > > Given that there was apparently some room for mis-interpretting my comments, > I just wish to issue a small clarification: > > The intend of my previous message (about boundary address translation) was > to make a plea for retaining the dual address element support which Mark > recently added to the Draft. I was afraid that without some counter > comments, people would think we should remove that element, based on > the comments from Hoffman and others (which realistically reflect what can > and should be done now, in an operational sense). > > Thank you, > Joel M. Halpern jmh@network.com > Network Systems Corporation >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15194; 23 Sep 93 13:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15189; 23 Sep 93 13:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28252; 23 Sep 93 13:22 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14532; Thu, 23 Sep 93 08:51:21 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from DUNGEON.BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA14519; Thu, 23 Sep 93 08:51:20 -0700 Message-Id: <9309231551.AA14519@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: Re: The nit'ted Classical Draft In-Reply-To: Your message of Wed, 22 Sep 93 15:21:33 -0700. <9309222221.AA02842@matmos.hpl.hp.com> Date: Thu, 23 Sep 93 11:45:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow HI - Isn't editing fun? Those nits just love to hide. Two more nits: On page 3 you say that AAL5 format specifies a max size of (64k -1 -8). I'm not sure what you meant by the -8. In my view it should just be deleted. Perhaps it just didn't get deleted when you put in the -1. But, if you mean to account for the LLC/SNAP header you should say so, since this is not part of AAL5. If you meant it to account for the AAL5 trailer (8 bytes), this is *not* part of the AAL5-CPCS-SDU. The max length of the AAL5-CPCS-SDU is 64k-1. On page 10, point 4. The text reads "build/refresh ARP its own client table entries" I think you meant: "build/refresh its own client ARP table entries" ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15325; 23 Sep 93 13:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15321; 23 Sep 93 13:28 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28448; 23 Sep 93 13:28 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15731; Thu, 23 Sep 93 09:04:03 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from DUNGEON.BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15718; Thu, 23 Sep 93 09:04:03 -0700 Message-Id: <9309231604.AA15718@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: Re: The nit'ted Classical Draft In-Reply-To: Your message of Wed, 22 Sep 93 15:21:33 -0700. <9309222221.AA02842@matmos.hpl.hp.com> Date: Thu, 23 Sep 93 11:52:23 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow One further nit: Page 16 Ref [9] has been voted in so the (DRAFT) can be removed. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18171; 23 Sep 93 14:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18167; 23 Sep 93 14:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03028; 23 Sep 93 14:58 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19209; Thu, 23 Sep 93 10:20:36 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19196; Thu, 23 Sep 93 10:20:35 -0700 Message-Id: <9309231720.AA19196@matmos.hpl.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rgc@qsun.att.com Date: Thu, 23 Sep 93 13:17 EDT To: atm@matmos.hpl.hp.com Subject: re:classical >> Mark, >> >> I would like to reiterate Dan's request that the draft be reissued >> before being "kicked out". In fact, do we really have enough >> consensus to send it out for Proposed? Perhaps we should discuss it >> more in Houston before putting the wraps on it. >> >> Cheers, >> Andy >>____________________________________________________________________________ >> Andrew G. Malis malis_a@timeplex.com -or- malis@maelstrom.timeplex.com >> Ascom Timeplex 289 Great Rd., Acton MA 01720 USA +1 508 266-4522 > >At risk of being accused yet again of standing in the way of progress, I agree >with Andy. The present differences on ATM addressing issues (and the subtle >architectural questions they imply) and some of the other items imply to me thathere may be a problem. I seem to remember the meeting in March when Mark first presented the Classical IP model. I was under the impression at that time that the end-to-end architecture assumed was SVC private LANs and PVC public WANs. If we stick to this model there are no addressing issues (only NSAP-m addressing is to be supported in this first go around). Would this be too restrictive at this time? Bob AT&T InterSapn DCS rgc@qsun.att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24908; 23 Sep 93 18:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24904; 23 Sep 93 18:25 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15205; 23 Sep 93 18:25 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25011; Thu, 23 Sep 93 13:35:16 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from DUNGEON.BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24998; Thu, 23 Sep 93 13:34:45 -0700 Message-Id: <9309232034.AA24998@matmos.hpl.hp.com> Received: by DUNGEON.BBN.COM id aa06462; 23 Sep 93 16:22 EDT To: atm@matmos.hpl.hp.com Cc: gswallow@bbn.com Subject: Re: The nit'ted Classical Draft In-Reply-To: Your message of Wed, 22 Sep 93 15:21:33 -0700. <9309222221.AA02842@matmos.hpl.hp.com> Date: Thu, 23 Sep 93 16:11:04 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow > If ATM Forum NSAP address are used, then the same NSAP encoding MUST > be used within an LIS and replies will use the same encoding as > queries. For example, NSAPs may encode IEEE 48-bit MAC addresses or > may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 > ATM addresses may be used but not both. I'd like to add my voice to those who find this restriction unnecessary. I don't see that the address space below IP is of any concern to IP at all. It just needs to be consistently understood at the ATM layer. Its a concern that lies strictly within ATM and should not be addressed in this document. By analogy its like saying we'll only support ARP on an ehternet if all the stations have the same OUI in their MAC addresses. I also find the language here confusing. The UNI 3.0 doc defines three private address formats. All are NSAPs. They are the DCC (Data Country Code), ICD (International Code Designator), and NSAP encoded E.164. All of these formats have been further refined along the GOSIP lines. (Whether the FORUM had the authority to do this is a different discussion - the holder of the AFI is supposed define the format.) The first two have AA (Administrative Authority) and Reserved fields. *All* of them have RD, AREA, ESI (end station identifier) and selector fields. I assume the when the Classical doc talks about NSAPs encoding the IEEE MAC address it is refering to the entirely optional practice (mandatory implementation / optional operation) of address registration in which an end station registers the ESI (and SEL) portion of its address with the network. This can (and usually will but doesn't have to) be an IEEE MAC address. This can be done with any of the three formats including the E.164 address format. So the two formats cited in the above paragraph aren't even mutually exclusive. Can we fix this? I suggest we drop the paragraph. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26179; 23 Sep 93 20:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26175; 23 Sep 93 20:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22871; 23 Sep 93 20:37 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00645; Thu, 23 Sep 93 16:18:20 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00632; Thu, 23 Sep 93 16:18:18 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA10082; Thu, 23 Sep 1993 18:18:34 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA02010; Thu, 23 Sep 1993 18:18:29 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA21782 (5.65a+/IDA-1.4.2 for atm@matmos.hpl.hp.com); Thu, 23 Sep 93 19:18:25 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA10425 (5.65a+/IDA-1.4.2 for dan@merlin.dev.cdx.mot.com); Thu, 23 Sep 93 19:18:23 -0400 Message-Id: <9309232318.AA10425@dbg.dev.cdx.mot.com> To: atm@matmos.hpl.hp.com Cc: dan@merlin.dev.cdx.mot.com Subject: Re: Repost: RE: Classical Draft Status (absurdly long!!) In-Reply-To: Your message of "Wed, 22 Sep 93 15:36:00 PDT." <2CA0D630@msgate.hls.com> Date: Thu, 23 Sep 93 19:18:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp I've finally gotten back to Anthony's comments of yesterday. The frustrating thing is that we pretty much agree on all of the major principles, disagree on a few details, but as a result reach radically different conclusions. > I think we are in danger of confusing (and I agree with > Dan's comments here), the syntax and use of the various > address formats within an ATM network with what ARP should > return. I don't think the two should be related, which is > what your comments above imply. Whether or not Q.93b > treats NSAP addresses as subaddresses or not (though this > is the choice we made, which implies that the public > network is a subnetwork of the private network, we could > just as easily have done the opposite - we just didn't), > the real issue for ARP is whether or not it should, or > needs to, return either or both address formats. A little amplification on this: the notion of subaddress has a historical basis in a telco model of the universe where the global ISDN is the center of the universe, with private subnetworks (to be precise, degenerate private subnetworks with exactly one switch) hanging off the edge of the public network 'cloud'. Interfaces to the public network were identified by E.164 addresses, since that is/was the public network numbering plan. The option for OSI NSAP addresses in the subaddress was included because support of OSI was considered politically correct. NSAP addresses, of course, identify a Network Service Access Point in an OSI End System. In the ATM Forum, we took the very good work from OSI, changed the semantics to 'identify an ATM Endpoint' (i.e., the user of the service ATM service in some loose sense -- debates about the location of the ATM Endpoint seemed useless). At the same time, we accepted the notion that the public network folks needed to continue to do business in the old way, and identify interfaces with E.164 addresses. As we got further down the path with NSAP addresses, we agreed (a mistake, in retrospect) that one of acceptable formats for the Initial Domain Part (IDP) of the ATM address would be an E.164 number. This did not change the semantics of the private ATM address; it just used the E.164 number as a syntactic construct to ensure uniqueness. Later, over my objections, it was agreed that a binding would exist between the E.164 number used as an IDP and a public network interface identified by that E.164 number, although the strength and scope of the binding is not particularly clear. Now, given the model that created the concepts of "number" and "subaddress", has nothing to do with our present reality, I have requested that this terminology be dropped from the I-D, except as it applies to Q.93b protocol details. There are also some other, more specific problems, which I will get into later. > True, but irrelevant to ARP - the purpose of ARP is to > return adequate *addressing* information to allow > connections to be set up between two (or more) IP end > stations, which happen to sit on ATM networks. What the > ATM network might choose to do with those addresses, or > how the ATM network might be structured, is, and should be, > irrelevant to the ARP mechanism. Here, Anthony and I are in absolute agreement. > I'm afraid that I have to diasgree completely with this > statment, which gets to the heart of the matter... [several other paragraphs with which I am in fundamental agreement] Now, here comes the problem... > The issue for ARP, then is to know what information must > be returned to allow such connectivity. Consider the > following scenarios: > > a. Private host to Private Host, no intervening public > transit network(s): Clearly requires that ARP return only > the NSAP address format of the end host. Agreed. > b. Private host to Private host, through intervening > public networks: In this case, the connection setup from > host A to host B must transit the public network(s). This > requires that at each ingress point to the public network > that a routing decision be made as to which is the correct > egress point from that public network to the next hop > private ATM switch, and that the native E.164 address of that > egress point be found (finding this is a VC routing > problem, probably requiring configuration of the public > network links and connectivity information). Then the > well know mapping of the NSAP addresses to the sudaddress > of the Q.93b request, etc, can be made. [more omitted] Strongly agreed. > c. Private Network Host to Public Network Host: This is > the case that seems to have caused all the problems. Agreed. > First of all, I would say that it is clearly necessary to > allow such a mixture of nodes to be in the same LIS > (contrary to your asserstion above). After all, why not? > If there can be ATM connectivity between such nodes, why > should the IP layer and ARP care what format of addresses > the nodes use, or what the structure of the ATM network > is? This would be akin to saying that LAN nodes with > different OUI values in their MAC addresses could not be > in the same IP subnet! Agreed. I think George also made this point today. > To get connectivity between the public node and the > private nodes requires the same kind of routing > information discussed above - namely, the directly > attached public network needs to know the (NSAP format) > ATM address of the private station, and the native E.164 > address of the egress point from the public network to > that private network (or to that of an intervening transit > private network etc). This may be a nit or may be serious, but the public network does not need to know the (private, NSAP-formatted) ATM endpoint address; if it gets one, it will transport it. It only uses the (native E.164-formatted) address of the Public UNI between it and the next hop private network. > There might be some argument (as I > think Dan has advocated), that the ARP mechanism could > return this egress point native E.164 address, but it is > inconsistent for ARP to return what is clearly routing > information, even if the ARP mechanism knew about it, > which is unlikely. Here is our point of disagreement. You said earlier, and I agreed, that "the purpose of ARP is to return adequate *addressing* information to allow connections to be set up between two (or more) IP end stations, which happen to sit on ATM networks". We may be quibbling as to whether an interface address constitutes a partial source route. I will admit that this lies in a gray area. However, my sense of architectural purity stretches to fit around problems that I can't solve any other way, and if this requires putting a thing that has properties of both addresses and source routes into an ARP response to make the thing work, so be it. > In the opposite direction, for the reasons mentioned in > case (b) above, the private network node only can use, and > should only get, the E.164 address of the directly > attached public node. The question is, what format should > this information be carried in? This question is clearly > answered, I think, by Note 9 of Annex A of the ATM Forum > UNI specification, Version 2.4 (passed by ballot recently > to become Version 3.0), viz: > > "A call originated on a Private UNI destined for an end > system which only has a native (non-NSAP) E.164 address > (i.e. a system directly attached to a public network > supporting the native E.164 format) will code the Called > Party number information element in the (NSAP) E.164 > private ATM Address Format, with the RD, AREA, and ESI > fields set to zero. The Called Party Subaddress > information element is not used." Ok, although I had misgivings about that decision at the time. The problem is solved in the Private->Public direction; the ARP server should return an address in the NSAP format with the IDP coded as an E.164 number and zeroed-out RD, Area and ESI. What about in the Public->Private direction. Here, you need both the E.164 address of the interface, to be consumed by the public network, and the ATM Endpoint address. Note that the ATM Endpoint address can (and most likely will) have the DSP in either the ISO ICD or the DCC formats, so algorithmic mappings won't work. Alternatively, you can burden the hosts to be configured with a mapping from IDP/RD/Area (and possibly ESI) to E.164 number of the nearest interface to the private network; this wouldn't be fun, and if you did it, you might as well not bother to ARP. Bottom line is that you really do need two addresses to make this scenario work. > d. Public network host to Public network host, no > intervening private network: In this case, clearly the > Q.93b requests would use native E.164 address formats. > This is the only case, it seems to me, where it might make > sense for the ARP mechanism to return native E.164 formats > only. Agreed. > I would suggest, however, that even in this case it > is much more consistent to return these addresses also in > the NSAP format, and allow the stations to map them into > native E.164 format. The stations know, after all, that > they are attached to a public network, and it is a trivial > translation from the NSAP format to the native E.164 > format. Well, no. The problem is that the host can't tell the difference between a host attached to the public network and a host attached to a private network that administers its addressing space using an E.164 IDP. In the first case, you'd populate the called party number IE with a 'native' E.164 number, and include no subaddress. In the second, you'd again populate the called party number IE with a 'native' E.164 number (not necessarily the same as the one in the DSP of the endpoint address) and the called party subaddress IE with the ATM endpoint address which uses the E.164 DSP format. > e. Public network host to Public network host, intervening > private network: same as case (d) above, since getting > to and through the private network is a VC routing, not an > addressing issue. This scenario is not technically feasible (no incumbent public network that I'm aware of will treat a private network as a transit network) and illegal in most of the world. My summary is that there are a lot of issues that still need to be shaken out. I agree strongly with Anthony that LIS boundaries should not be constrained to be within the boundaries of a single ATM network. I am also concerned that, assuming this draft moves to proposed standard, we will create an embedded base of problems to resolve later. So, please, let's keep this going until we reach some conclusions that we can agree will work. Rgds, Dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05397; 24 Sep 93 0:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05393; 24 Sep 93 0:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02838; 24 Sep 93 0:51 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA09838; Thu, 23 Sep 93 19:58:41 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA09822; Thu, 23 Sep 93 19:58:38 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA27945; Thu, 23 Sep 93 19:58:42 PDT Received: by msgate.hls.com with Microsoft Mail id <2CA26516@msgate.hls.com>; Thu, 23 Sep 93 20:10:14 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , Dan Grossman , HP - Mark Laubach Subject: Re: Repost: RE: Classical Draft Status (absurdly long!!) Date: Thu, 23 Sep 93 19:56:00 PDT Message-Id: <2CA26516@msgate.hls.com> Encoding: 182 TEXT X-Mailer: Microsoft Mail V3.0 Dan, >I've finally gotten back to Anthony's comments of >yesterday. The frustrating thing is that we pretty much >agree on all of the major principles, disagree on a few >details, but as a result reach radically different >conclusions. You may be being unduly pessimistic here! :-) Actually I think we agree on almost everything, with virtually the sole exception being (and I figured we might disagree here), the case of the directly attached public node in my scenario (c), from my email yesterday. >>To get connectivity between the public node and the >>private nodes requires the same kind of routing >>information discussed above - namely, the directly >>attached public network needs to know the (NSAP format) >>ATM address of the private station, and the native E.164 >>address of the egress point from the public network to > >>that private network (or to that of an intervening >>transit private network etc). >This may be a nit or may be serious, but the public >network does not need to know the (private, >NSAP-formatted) ATM endpoint address; if it gets one, it >will transport it. It only uses the (native >E.164-formatted) address of the Public UNI between it and >the next hop private network. I disagree with this - the public _network_ only needs to know the native mode E.164 address of the next hop private network, but clearly the public _node_ needs to know the private NSAP address of the end private node (to carry in the subaddress of the Q.93b request), else the connection could not be routed across the private network, once it got to that network. >>There might be some argument (as I think Dan has >>advocated), that the ARP mechanism could return this >>egress point native E.164 address, but it is inconsistent >>for ARP to return what is clearly routing information, >>even if the ARP mechanism knew about it, which is >>unlikely. Here is our point of disagreement. >You said earlier, and I agreed, that "the purpose of ARP >is to return adequate *addressing* information to allow >connections to be set up between two (or more) IP end >stations, which happen to sit on ATM networks". We may be >quibbling as to whether an interface address constitutes a >partial source route. I will admit that this lies in a >gray area. Well, I don't think its very grey - clearly it is source routing information, not *addressing* information. >However, my sense of architectural purity stretches to fit >around problems that I can't solve any other way, and if >this requires putting a thing that has properties of both >addresses and source routes into an ARP response to make >the thing work, so be it. The problem with this is that this case - of a directly attached public node - is the *only* case where it is useful for ARP to return such partial source routing information. As I went through yesterday (and you agreed), in no other case is this information useful. Why do we want to confuse the matter (and ARP) by making an exception for this single case? After all, the routing problem does need to be solved independent of ARP for private node that needs to talk with that public node, so why should the latter be any different? >The problem is solved in the Private->Public >direction; the ARP server should return an address in the >NSAP format with the IDP coded as an E.164 number and >zeroed-out RD, Area and ESI. What about in the >Public->Private direction. Here, you need both the E.164 >address of the interface, to be consumed by the public >network, and the ATM Endpoint address. Note that the ATM >Endpoint address can (and most likely will) have the DSP >in either the ISO ICD or the DCC formats, so algorithmic >mappings won't work. Alternatively, you can burden the >hosts to be configured with a mapping from IDP/RD/Area >(and possibly ESI) to E.164 number of the nearest >interface to the private network; this wouldn't be fun, >and if you did it, you might as well not bother to ARP. >Bottom line is that you really do need two addresses to >make this scenario work. Yes, clearly you need two addresses, and you need _routing_ mechanisms to solve this problem. My comments above stand. Having to solve this routing problem, BTW, clearly does not obviate the need for ARP, since this maps IP addresses into ATM addresses, not NSAP addresses into E.164 addresses. In any case, just how do you propose the ARP server would actually find out the information - the E.164 address of the nearest public network access point - to return? What if there were multiple such ingress/egress points? What if the network administrator had different policies as to the use of each of these points? Trying to cheat and shortcut by such selective blending of routing and addressing information is the start of a slippery slope - there are some good things to be said for layering, on occasion... >>d. Public network host to Public network host, no >>intervening private network: In this case, clearly the >>Q.93b requests would use native E.164 address formats. >>This is the only case, it seems to me, where it might make >>sense for the ARP mechanism to return native E.164 formats >>only. > >Agreed. > >>I would suggest, however, that even in this case it is >>much more consistent to return these addresses also in the >>NSAP format, and allow the stations to map them into >>native E.164 format. The stations know, after all, that >>they are attached to a public network, and it is a trivial >>translation from the NSAP format to the native E.164 >>format. > >Well, no. The problem is that the host can't tell >the difference between a host attached to the public >network and a host attached to a private network that >administers its addressing space using an E.164 IDP. In >the first case, you'd populate the called party number IE >with a 'native' E.164 number, and include no subaddress. >In the second, you'd again populate the called party >number IE with a 'native' E.164 number (not necessarily >the same as the one in the DSP of the endpoint address) >and the called party subaddress IE with the ATM endpoint >address which uses the E.164 DSP format. I think you are right here - we probably do need to treat case (d) differently (though I find it hard to imagine that there really will be _private_ networks that use NSAP encoded E.164 addresses - I would have thought that these would only ever be used, in practice, for carrying native mode E.164 addresses across private networks, as in case (c)). Pity. >My summary is that there are a lot of issues that still >need to be shaken out. I agree strongly with Anthony that >LIS boundaries should not be constrained to be within the >boundaries of a single ATM network. I am also concerned >that, assuming this draft moves to proposed standard, we >will create an embedded base of problems to resolve >later. So, please, let's keep this going until we reach >some conclusions that we can agree will work. > >Rgds, >Dan Amen... I sympathize with the desire to get this out ASAP, but do we really want something that has so many onerous limitations? At the very least, I would like to have the document either include, or reference in the framework document, a thorough description of the various network models, assumptions and limitations of the classical ARP model. What I am most concerned about is that we will publish this draft, and the world will go implement it, but that people will forget all the limitations, compromises and architectural models underlying it. This will make it that much harder to solve the problems later, whereas if people were alerted to them right from the start, then they might ensure that their implementations make allowances for the likely future changes. Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09623; 24 Sep 93 11:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09618; 24 Sep 93 11:19 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19922; 24 Sep 93 11:19 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27316; Fri, 24 Sep 93 06:27:29 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay2.UU.NET by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27303; Fri, 24 Sep 93 06:27:27 -0700 Received: from hoho.agile.com (via [198.3.104.110]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20228; Fri, 24 Sep 93 09:27:47 -0400 Message-Id: <9309241327.AA20228@relay2.UU.NET> Received: by hoho.agile.com (1.37.109.4/16.2) id AA01843; Fri, 24 Sep 93 09:27:18 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nik Langrind Subject: Re: The nit'ted Classical Draft To: atm@matmos.hpl.hp.com Date: Fri, 24 Sep 93 9:27:17 EDT In-Reply-To: <9309232034.AA24998@matmos.hpl.hp.com>; from "George Swallow" at Sep 23, 93 4:11 pm Mailer: Elm [revision: 70.85] > > > > If ATM Forum NSAP address are used, then the same NSAP encoding MUST > > be used within an LIS and replies will use the same encoding as > > queries. For example, NSAPs may encode IEEE 48-bit MAC addresses or > > may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 > > ATM addresses may be used but not both. > > I'd like to add my voice to those who find this restriction > unnecessary. I don't see that the address space below IP is of any > concern to IP at all. It just needs to be consistently understood at > the ATM layer. Its a concern that lies strictly within ATM and should > not be addressed in this document. By analogy its like saying we'll > only support ARP on an ehternet if all the stations have the same OUI > in their MAC addresses. > I would amend the analogy. It seems more like saying that we'll only support ARP on an Ethernet if all the stations use the same encapsulation, either type II or 802/SNAP. It is true that IP is not technically concerned with the lower layer encapsulation, but the person who configures the network is concerned. It seems to me that the restriction is imposed to make interoperability more likely, because an implementation need not support both formats simultaneously. Perhaps an implementation need only support one type, if a vendor is willing to put out a limited product. I think the key phrase the makes the restriction reasonable is "within the LIS". -- Nik Langrind nlangrind@agile.com Agile Networks (508) 287-0700 x110   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15257; 24 Sep 93 13:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15252; 24 Sep 93 13:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26810; 24 Sep 93 13:22 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01420; Fri, 24 Sep 93 08:13:10 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01407; Fri, 24 Sep 93 08:13:09 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA29517; Fri, 24 Sep 93 08:13:30 -0700 Received: from lobster.wellfleet.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA01295; Fri, 24 Sep 93 08:13:53 -0700 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA15614; Fri, 24 Sep 93 11:02:14 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA08455; Fri, 24 Sep 93 11:12:59 EDT Date: Fri, 24 Sep 93 11:12:59 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9309241512.AA08455@cabernet.wellfleet> To: atm@hplms2.hpl.hp.com, curtis@ans.net Subject: Re: Classical Draft Status Cc: rcallon@wellfleet.com Do you see any places where we might be painting ourselves into a corner? (Curtis) Yes. My model is that most customer sites have a large number of hosts from many different vendors, a smaller number of routers from a smaller number of vendors (usually just one vendor), and will most likely have ATM switches also from a small number of vendors (usually just one). Thus, if a future transition requires changes to hosts the customer is going to have a difficult problem. On the other hand, if a transition requires changes to routers, or ATM switches, or the ARP server, then this will probably not be too hard to accomplish quickly. This implies that whatever model for host operation is implicit (or explicit) in the classical model will be with us for a long time to come (in the sense that hosts which conform to this model, and which have not been updated since late 1993, will be with us for a long time). Thus it would make sense to make sure that the classical model implies a rather general host implementation, even if the operation of the classical model does not require such general operation. I also think that it should not be too hard nor take too long to define a general host model, and that this will not significantly complicate the operation of the hosts. This implies that we should (at least in our heads) split the classical model into two parts: What the host is required to do, and how this fits with the classical model. The most obvious example that I can think of is ATM level addresses in ARP replies. I think that when a host makes an ARP request, it should assume as little as possible about the addresses that are provided in the reply. Thus I would propose that the ARP response contain an ATM address plus an ATM subaddress, with each being variable length from one to 20 bytes (and the subaddress obviously being optional). The host should not know nor care what the sub-structure of the address and sub- address are, but should just put them in the appropriate fields in the call setup. This implies that we need an explicit E.164 format (for hosts which are attached to ATM nets using E.164), and not just embed E.164 addresses in NSAPs and assume that the host is capable of extracting an E.164 addresss from an NSAP (since the host should not know anything about the subformat of the ATM addresses). Now, for initial operation this probably implies no change at all from the classical model. The host sends out an ARP request, and gets back an ARP reply. In the short run the replies might all contain a 20 byte ATM address plus no subaddress. But if sometime in the future we want to deploy a more general ("neo-classical") model, we can do this without host changes. I haven't had the time to re-read the classical model (for a third time) to see if there are other examples of ways that host behaviour can be generalized, in order to fit the classical model gracefully and yet be extensible to other models. I will try to find time today or over the weekend if I can. Also, we might also want to also split off what a router is required to do (in order to try to make this as extensible as possible). But I don't think that this is quite as critical. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15990; 24 Sep 93 13:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15986; 24 Sep 93 13:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28448; 24 Sep 93 13:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03590; Fri, 24 Sep 93 08:41:44 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03577; Fri, 24 Sep 93 08:41:43 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA29693; Fri, 24 Sep 93 08:42:05 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA01453; Fri, 24 Sep 93 08:42:28 -0700 Received: by interlock.ans.net id AA19434 (InterLock SMTP Gateway 1.1 for atm@hpl.hp.com); Fri, 24 Sep 1993 11:34:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Sep 1993 11:34:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Sep 1993 11:34:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309241538.AA28231@foo.ans.net> To: Ross Callon Cc: atm@hplms2.hpl.hp.com, curtis@ans.net, curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Fri, 24 Sep 93 11:12:59 EDT.) <9309241512.AA08455@cabernet.wellfleet> Date: Fri, 24 Sep 93 11:38:43 -0500 Ross, Thanks for the reply. As always, well thought out and worth waiting for. > Do you see any places where we might be painting ourselves into a > corner? > (Curtis) > > Yes. > [...] > This implies that we should (at least in our heads) split the > classical model into two parts: What the host is required to do, > and how this fits with the classical model. > > The most obvious example that I can think of is ATM level > addresses in ARP replies. I think that when a host makes an > ARP request, it should assume as little as possible about the > addresses that are provided in the reply. Thus I would propose > that the ARP response contain an ATM address plus an ATM > subaddress, with each being variable length from one to 20 bytes > (and the subaddress obviously being optional). The host should > not know nor care what the sub-structure of the address and sub- > address are, but should just put them in the appropriate fields > in the call setup. This implies that we need an explicit E.164 > format (for hosts which are attached to ATM nets using E.164), > and not just embed E.164 addresses in NSAPs and assume that the > host is capable of extracting an E.164 addresss from an NSAP > (since the host should not know anything about the subformat > of the ATM addresses). I agree with what you suggest. I suspect the problem is not as bad as you make it out to be. Consider what happens if we come up with some totally incompatible addressing scheme in the future (ie: one that for some reason uses neither NSAP or E164 - I know that is is unlikely, just consider it a worst case hypothetical example). This is not the end of the world for the old hosts. A router on the local LAN can be configured to recognize that some hosts on the LAN have this limitation and provide a next hop for the route that is that router. Presumably the host and router can exchange ARP and have compatible addressing on the local LAN. The host would resolve the physical address of the next hop and connectivity would be established. Similarly, the router would provide the outside world with a route with the next hop of itself. To the old host, the outside world looks no different than if it were routing to an ethernet on the other side of it's local router. To the outside world, the old host looks no different than if it were on an ethernet. Isn't interoperability among different media type how IP got started in the first place and it's most critical key to success? Keep in mind that this is the absolute worst case for a host which can't be changed if we totally blow the addressing decisions. > Also, we might also want to also split off what a router is > required to do (in order to try to make this as extensible as > possible). But I don't think that this is quite as critical. At least you recognize that we will still be using routers somewhere in the Internet. There seem to be some that assume the entire world will convert to a big ATM LAN so all we need is ARP servers. ;-) Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20775; 24 Sep 93 16:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20771; 24 Sep 93 16:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07921; 24 Sep 93 16:27 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10120; Fri, 24 Sep 93 12:13:39 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from DUNGEON.BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA10107; Fri, 24 Sep 93 12:13:38 -0700 Message-Id: <9309241913.AA10107@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Cc: gswallow@bbn.com Subject: Re: The nit'ted Classical Draft In-Reply-To: Your message of Fri, 24 Sep 93 09:27:17 -0400. <9309241327.AA20228@relay2.UU.NET> Date: Fri, 24 Sep 93 15:09:45 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow I can't agree with you here. yes, the ATM Forum has built an addressing scheme so flexible that you can shoot yourself in both feet. Yes, folks should be very careful about their addressing plans. The realities of mergers, acquisitions, and re-organizations is that the best of plans tend to get subverted and exceptions need to be made. The restrictions in *private* addresses is purely arbitrary on our part. I'd even support some form of warning in this document because the user comminity certainly needs to be aware that there are issues they need to deal with here. But correct addressing at the ATM layer is a matter for the ATM layer. Yes we need speed limits. But they should be set by the people who build the roads, no the people who build the cars. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22450; 24 Sep 93 17:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22446; 24 Sep 93 17:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12330; 24 Sep 93 17:43 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13966; Fri, 24 Sep 93 13:28:32 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA13953; Fri, 24 Sep 93 13:28:31 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA25401; Fri, 24 Sep 93 13:28:28 PDT Received: by msgate.hls.com with Microsoft Mail id <2CA35B30@msgate.hls.com>; Fri, 24 Sep 93 13:40:16 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm Cc: gswallow Subject: Re: The nit'ted Classical Draft Date: Fri, 24 Sep 93 13:26:00 PDT Message-Id: <2CA35B30@msgate.hls.com> Encoding: 36 TEXT X-Mailer: Microsoft Mail V3.0 I agree, the restriction on LISs having to have the same NSAP encoding, let alone NSAP and E1.64 is purely arbitrary, and it doesn't go away just because we say that 'that is how we defined a LIS'. At the least, we need to make sure that readers of the document, presumably far removed from all our learned (?) discussions, will understand what assumptions and limitations are truly fundamental and which are essentially arbitrary and made purely for the sake of getting the document out. Anthony. ---------- From: atm-request To: atm Cc: gswallow Subject: Re: The nit'ted Classical Draft Date: Friday, 24 September 1993 3:09PM I can't agree with you here. yes, the ATM Forum has built an addressing scheme so flexible that you can shoot yourself in both feet. Yes, folks should be very careful about their addressing plans. The realities of mergers, acquisitions, and re-organizations is that the best of plans tend to get subverted and exceptions need to be made. The restrictions in *private* addresses is purely arbitrary on our part. I'd even support some form of warning in this document because the user comminity certainly needs to be aware that there are issues they need to deal with here. But correct addressing at the ATM layer is a matter for the ATM layer. Yes we need speed limits. But they should be set by the people who build the roads, no the people who build the cars. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23026; 24 Sep 93 18:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23022; 24 Sep 93 18:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14171; 24 Sep 93 18:11 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11908; Fri, 24 Sep 93 13:00:59 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11895; Fri, 24 Sep 93 13:00:57 -0700 Message-Id: <9309242000.AA11895@matmos.hpl.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rgc@qsun.att.com Date: Fri, 24 Sep 93 15:57 EDT Original-From: qsun!rgc (Robert G Cole +1 908 949 1950) To: atm@matmos.hpl.hp.com Cc: laubach@matmos.hpl.hp.com Subject: framework doc Below is an updated draft of the framework document. Sorry for the delay in revising this. I tried to capture most of the comments from the group, at least most major comments, e.g. not representing the concensus opinion on the complexities of the peer models, requirement for ARP servers, etc. Brian Carpenter contributed sections on TULIP and TUNIC and I took a quick crack at representing some of the postings from Anthony Alles in the Appendix, I hope I did justice to it. Below is the ascii version. I have a postscript version which includes figures (Mark, how should I handle distributing the postscript version?). Bob Cole rgc@qsun.att.com AT&T InterSpan DCS 908-949-1950 ******************************** - 1 - IP over ATM Working Group R. G. Cole Request for Comments: DRAFT AT&T Bell Laboratories Expires: 21 December 1993 24 September 1993 IP over ATM: A Framework Document 1. Status of this Memo This document is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a working draft or work in progress. Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract This memo summarizes some of the discussions of the IP over ATM working group over the last year. This summary is provided in the form of a framework which categories the various ATM subnet models and End-to-End models identified by the working group. The intent of this framework is to help partition the efforts of the working group to focus on smaller, more manageable aspects of IP over ATM. The subnet models identified in this memo are: +o an SVC-based LAN ATM (LATM) subnet, +o a PVC-based WAN ATM (WATM) subnet, and +o an SVC-based WATM subnet. The End-to-End models identified in this memo are: +o End-to-End Subnet Models, including - the Classical IP model, - 2 - - an SVC-based WATM subnet model, - lightweight subnet models, i.e. TUNIC and TULIP, and +o Peer Models. 3. Introduction The IP over ATM Working Group of the Internet Engineering Task Force (IETF) is chartered to develop standards for routing and forwarding IP packets over ATM subnets. There are several difficulties with this charter, as witnessed in the discussions of this group over the last year. First, asynchronous transfer mode (ATM) technology is still in its development state. Second, the flexibility of the technology, allows and in fact encourages, viewing ATM as different subnet technologies, e.g., a LAN, a WAN, an Internet, etc. Therefore, much of the discussions of the IP over ATM WG have centered around not only how to carry IP traffic over ATM but what is ATM. This memorandum attempts to highlight some of these discussions and tries to categorize the various ATM subnet architectures and End-to- End architectures that have been proposed. It is felt that to promote progress in the IP over ATM working group, it is first necessary to come to some consensus on the types of ATM subnets to be addressed. Then it will be possible to focus attention of several subgroups to work the issues of routing IP packets over these different ATM subnets. As this work is proceeding, parallel efforts in identifying issues to work in the eventual end- to-end ATM models can be preformed. It is expected that defining IP routing over some ATM subnet types and simpler end-to-end models can proceed at a quicker pace, while there exist many fundamental architectural issues in defining peer end-to-end models. Therefore, it is hoped that this document, in classifying the subnet and end-to-end models, will help in focusing the IP over ATM working groupUs direction over the next several IETF meetings. The remainder of this memorandum is organized as follows: +o Section4 presents several definitions of use in the later sections, +o Section 5 discusses/identifies the various subnet models proposed to date by the IP over ATM working group, - 3 - +o Section 6 identifies several promising end-to- end networking configurations, and +o Section 7 contains conclusions. 4. PARAMETERS DEFINING SUBNET TECHNOLOGIES Following ISO we define several terms [ISO 8473]: +o A Subnet is a connected communication network consisting of a single networking technology. Subnets are further categorized into broadcast and general topology subnetworks. +o A Broadcast Subnet Rsupports an arbitrary number of end systems and intermediate systems and additionally is capable of transmitting a single Subnetwork NPDU (SNPDU) to a subset of these systems in response to a single send_unitdata requestS. +o A General Topology Subnet Rsupports an arbitrary number of end systems and intermediate systems but does not support a convenient multi- destination connectionless transmission facility, as does a broadcast subnetworkS. We will hereafter interchangeably use the terms general topology subnet and Non-Broadcast Multiple Access (NBMA) subnet. +o An End System Rdelivers Network Level Protocol Data Units (NPDUs) to other systems and receives NPDUs from other systems, but do not relay NPDUs.S +o An Intermediate System Rdelivers and receives NPDUs from other systems, and relays NPDUs from other systems to other destination systems.S They route to end systems within their own area and to other intermediate systems when the destination is within another area. +o An End-to-End path consists of two end systems which can communicate with one another over an arbitrary number of intermediate systems and subnets connecting the end and intermediate systems. From the perspective of the subnet, it sees no difference between the end systems and intermediate systems. Therefore, we will define a Subnet End Systems (Sub-ES) as a network level routing entity connected to the subnet, whether it is actually an end or intermediate system. Figure 1 shows two subnet end systems connected over a single subnet. An end- to-end path can be considered as a concatenation of multiple - 4 - single hop configurations. Each subnet technology is characterized in terms of several parameters. We have defined two subnet types, i.e. a broadcast and a general topology, or NBMA, subnet. However, it is possible to further specify subnet types within these broad categories. Towards this end, we list here a few of the more relevant parameters for the discussions to follow; this list is by no means exhaustive. They are: +o Routing and Addressing Capabilities, +o Topology and Geographic Support, e.g., - LAN versus WAN, and - the number of stations supported, +o Transport Services, e.g., - Connection-Oriented Network Service (CONS) versus Connectionless Network Service (CLNS), and - Variable Bit Rate (VBR) versus Constant Bit Rate (CBR) Services, +o Connection Functions, e.g., - PVC or SVC, and - point-to-point, multipoint (multicast), or broadcast, +o Transmission Characteristics, e.g., - reliable versus unreliable (e.g., guaranteed delivery as in X.25 or best effort as in Frame Relay), and - priorities, +o Security Features, and +o Packet Parameters (e.g., max MTU size, etc.). 5. CLASSIFICATION OF ATM SUBNETS - 5 - Several ATM subnets have been discussed by the IP over ATM working group. These range from the Broadband-Integrated Services Digital Network (B-ISDN) subnet originally proposed and being defined by inter-exchange carriers to Local ATM (LATM) subnets, currently being defined by computer and LAN networking vendors. Further, other subnets are defined on ATM as overlay subnets, e.g. Frame Relay on ATM. We identify and discuss here three possible ATM subnets; a LAN-ATM (LATM) subnet, a PVC-based WAN-ATM (WATM) subnet, and a SVC-based WATM subnet. 5.1 The LATM Subnet Model The LAN-ATM (LATM) subnet is characterized as having a small number of end systems, e.g. hundreds to thousands, which: +o are directly connected, +o share a common network prefix, +o support switched virtual connections, +o support an efficient broadcast/multicast/connectionless server for address resolution, and +o are part of a single working group, e.g. security is not an issue. For end systems to forward packets over this subnet, many of the mechanisms for forwarding IP packets over ethernet subnets apply and are presented in [LAU 93]. Issues to be worked in defining IP over the LATM subnet are: +o Defining the VPI/VCIs for address resolution, (Many internal architectures are possible ranging from, possibly, a broadcast capability to the existence of an ARP server reachable on the identified VPI/VCI. It is the belief of the IP over ATM group that the architecture of address resolution needs to be specified and that the ARP server architecture is the desired option.) +o Defining the maximum MTU size, (This has been the subject of considerable debate over the Internet this spring. This issue is addressed in [ATK 93].) +o Methods of encapsulation and multiplexing, (This issue is addressed in [HEI 93a].) and - 6 - +o Others. The majority of the work here is in defining the interface between the Sub-ESs and the LATM, e.g., what VPI/VCIs to be used to access the ARP server [LAU 93], the method of encapsulation, the maximum MTU sizes, signalling capabilities, etc. However, other work items involve more internal architectural issues such as the architectures for ARP services. 5.2 The PVC WATM Subnet Model The PVC-based WATM is a general topology, or NBMA, subnet which is further characterized as having a large number of end systems, e.g. tens of thousands, which: +o are not all directly connected, +o do not share a common network prefix, +o support permanent or semi-permanent virtual connections, +o do not support an efficient broadcast/multicast/connectionless server for address resolution, and +o are not part of a single working group, however security is not an issue due to the permanent nature of the virtual connections. For end systems to forward packets over this subnet, many of the mechanisms defined for forwarding IP packets over Frame Relay subnets apply. Issues to be worked in defining IP over the LATM subnet are: +o Defining the details for an Inv-ARP like address resolution, (Strictly, Inv-ARP is defined for general PVC-based NBMA subnets, see [RFC 1293] and [LAU 93].) +o Methods of encapsulation and multiplexing, (This issue is addressed in [HEI 93a].) +o Defining the maximum MTU size, (This issue is addressed in [ATK 93].) and +o Others. The majority of the work here is in specifying the Inv-ARP details and in defining the MTU sizes supported. - 7 - 5.3 The SVC WATM Subnet Model The SVC-based WATM is a general topology, or NBMA, subnet which is further characterized as having a large number of end systems, e.g. hundreds of thousands, which: +o Support switched virtual connections, +o Maybe directly connected, due to the existence of SVCs, +o Do not share a common network prefix, +o Do not support an efficient broadcast/multicast mechanism for address resolution, and +o Are not part of a single working group and hence security is an issue. For end systems to forward packets over this subnet, many of the problems which were being addressed in the IETFUs IPLPDN working group, the IP over ATM working group, and are now to be addressed in the Routing over Large Clouds [HAL 93], are applicable. Examples of work performed in the IPLPDN working group include short-cut routing [TSU 93] and directed ARP [GAR 93] over SMDS subnets, and in the IP over ATM working group include distributed ARP server architectures in [HEI 93b]. Issues to be worked for the SVC WATM subnet include: +o Defining the details for an efficient address resolution architecture, (Work in this area has been started, see [GAR 93], and [HEI 93b].) +o Methods of encapsulation and multiplexing, (This issue is addressed in [HEI 93a].) +o Defining the maximum MTU size, (This issue is addressed in [ATK 93].) +o Defining security procedures, +o Routing between end systems not sharing a common network level address prefix, but attached to the same subnet, and +o Others. Whereas the first two subnets presented above, i.e. the LATM and PVC-Based WATM, are more straight forward in defining routing of IP packets over these subnets, the SVC-Based WATM presents several hard problems to be resolved prior to - 8 - specifying IP routing over it. Many of this issues are the focus of the new Routing over Large Clouds working group formed in July 1993. 6. END-TO-END NETWORKING CONFIGURATIONS Several end-to-end ATM configurations have been proposed; most constructed by cascading gateways and different ATM subnet models. Other, more radical models have been proposed which cast out the traditional subnet architectures in favor of ATM Internet models. We categorize these different models in terms of whether the ATM network and router gateways are considered as peers, i.e. they exchange routing information, or not, i.e. the routers treat the ATM network as a lower- level subnet. We will refer to these as Peer Models and Subnet Models, respectively, and discuss each separately below. Clearly the Subnet Models follow the traditional IP networking architectures, where as the Peer Models propose a new way of IP networking. Due to this, the consensus of the group was that the problems with the end-to-end peer models were much harder than any of the other models, and had more unresolved technical issues. While encouraging interested individuals/companies to research this area, it was not the priority of the IP over ATM working group to address these difficulties. 6.1 Subnet Models Three end-to-end subnet models were identified at the Columbus meeting of the IP over ATM working group at the March and July 1993 IETF meetings. These three models are: +o The Classical IP Model, +o The SVC-based WATM subnet model, and +o Lightweight subnet models. 6.1.1 The Classical IP Model The Classical IP Model was suggested at the Spring 1993 IETF meeting [LAU 93]. This model simply consists of cascading subnet models discussed above with gateways or routers. A realization of this model consists of a concatenation of two LATMs and a PVC-based WATM subnet. This is shown in Figure 2 below. Here the entities identified as ESs could strictly be either ISs or ESs depending on the actual end-to-end path, which may include subnets other than ATM subnets. Once the details of specifying routing and forwarding IP packets over - 9 - the component subnets are complete, routing IP packets over this Classical IP model is straight forward. For more information see [LAU 93]. 6.1.2 The SVC-based WATM subnet The SVC-based WATM subnet was discussed in the previous section. Here the subnet supports a huge number of ESs in a dynamic SVC environment. There are several problems to address to bring this end-to-end subnet model to fruition. These include, but are not limited to, the following: +o What are the appropriate architectures for address resolution, +o How can routing be optimized across multiple logical IP subnets on a common ATM infrastructure, e.g. the short-cut routing problem, and +o Others. The work on these problems may be worked separately from the near term work on bringing the Classical IP model to fruition. Figure 3 shows an example of an SVC-based WATM subnet consisting of three components, two private ATM networks connected by a single public ATM network. More complex ATM internets are envisioned and solutions to networking over SVC-based WATM subnets must be able to support these complex internets and their attending problems. Many of the higher level issues associated with this model are now to be addressed in the newly formed Routing over Large Clouds working group. An additional complexity in supporting IP routing over these ATM internets lies in the multiplicity of subnetwork points of attachment address formats in [ATM 93]. NSAP modeled address formats only are supported on Rprivate ATMS networks, while either 1) E.164 only, 2) NSAP modeled formats only, or 3) both are supported on Rpublic ATMS networks. Further, while both the E.164 and NSAP modeled address formats are to be considered as subnetwork points of attachment, it seems that E.164 only networks are to be considered as subnetworks to Rprivate networksS. This leads to some confusion in defining an ARP mechanism in supporting all combinations of end-to-end scenarios (refer to the discussion in Appendix A on the possible scenarios to be supported by ARP). 6.1.3 Lightweight subnet models - 10 - Two further models can be identified which have the characteristic of largely or totally eliminating IP header overheads. These models were discussed in the July IETF meeting in Amsterdam. They both assume that following name resolution, address resolution, and SVC signaling, an implicit binding is established between entities in the two subnet ESs. In this case full IP headers (and in particular source and destination addresses) are not required in each data packet. % The first model is TCP and UDP over Lightweight IP (TULIP) in which only the IP protocol field is carried in each packet, everything else being bound at call set-up time. In this case the implicit binding is between the IP entities in each subnet ES. Since there is no further routing problem once the binding is established, since AAL5 can indicate packet size, since fragmentation cannot occur, and since ATM signaling will handle exception conditions, the lack of all other IP header fields and of ICMP should not be an issue. TULIP changes nothing in the abstract architecture of the IP model, since each subnet ES still has an IP address which is resolved to an ATM address. It simply uses the point-to- point property of VCs to allow the elimination of some per- packet overhead. Use of TULIP could in principle be negotiated on a per-SVC basis or configured on a per-PVC basis. % The second model is TCP and UDP over a Nonexistent IP Connection (TUNIC). In this case no network-layer information is carried in each packet, everything being bound at virtual circuit set-up time. The implicit binding is between two applications using either TCP or UDP directly over AAL5 on a dedicated VC. If this can be achieved, the IP protocol field has no useful dynamic function. However, in order to achieve binding between two applications, the use of a well-known port number in classical IP or in TULIP mode may be necessary during call set-up. This is a subject for further study. 6.2 Peer Models Peer Models are fundamentally characterized in that they place routers/gateways and the ATM network on a peer basis. That is, the ATM network and the attached ESs or ISs exchange routing information on a peer basis, network level addressing is used across the ES or IS and ATM interface. Discussions on peer models can be found in [LYO 92], [HEI 1992] and [LIA 93]. A rationale for this model is that due to the envisioned complexity of future ATM networks, the - 11 - routing complexities will be similar to routing over complex internets. Rather than building in redundancy in routing complexities at the network and subnetwork levels, perhaps it is possible to imbed within the ATM network fabric IS functionality. This is illustrated in Figure 4 below. There are issues to be worked for this Peer Model (see, e.g., [HEI 1992] and [LIA 93]), including: +o Defining a routing architecture which - scales to the large size expected of the eventual ATM network, and - supports TOS routing. +o Defining a functional architecture which - scales to the large size expected of the eventual ATM network, - supports the current status of the ATM ForumUs standards in signalling, routing, etc., - allows a transition from subnet models to peer models, and - others. +o Others During the discussions of the IP over ATM working group, it was felt that the problems with the end-to-end peer model were much harder than any other model, and had more unresolved technical issues. While encouraging interested individuals/companies to research this area, it was not a priority of the working group to address these issues. 6.3 Transition Models Finally, it is useful to consider transition models, lying somewhere between the Classical IP Models and the Peer Models. Some possible architectures for transition models are presented in [LIA 93]. Others are possible, for example Figure 5 showing a Classical IP transition model which assumes the presence of gateways between ATM subnets and ATM Peer networks. Other transition options are discussed in [LIA 93]. 7. CONCLUSIONS - 12 - This document identifies several of the possible ATM subnet technologies that have been bantered about at the meetings of the IP over ATM working group at the IETF. In particular, an LAN-ATM (LATM), a PVC-based WAN ATM (PVC-based WATM), and an SVC-based WAN ATM (SVC-based WATM) are presented. Further, this document lists several of the end-to-end IP over ATM architectures which have been discussed and the distinguishing characteristics of each. End-to-end models discussed include SVC-based WATM, light weight IP models, e.g., TULIP and TUNIC models, and Peer models. It is proposed that the issues of routing IP over ATM be broken out into issues relating separately to the subnet and end-to-end models discussed in this document. Due to the complexity of ATM technologies, in that they present multiple faces, it is felt that the best way to make progress is to simplify the work into more manageable steps. 8. Acknowledgments: This draft is the direct result of the numerous discussions of the IP over ATM Working Group of the Internet Engineering Task Force. The author also had the benefit of several private discussions with H. Nguyen of AT&T Bell Laboratories. Further, Brian Carpenter of CERN was kind enough to contribute the TULIP and TUNIC sections to this draft. Also, the text of Appendix A was pirated liberally from Anthony Alles of HLSU posting on the IP over ATM discussion list (and modified at the authorUs discretion). 9. Author's Address: Robert G. Cole AT&T Bell Laboratories 101 Crawfords Corner Road, Rm. 1E-401 Holmdel, NJ 07733 Phone: (908) 949-1950 Fax: (908) 949-1726 Email: rgc@qsun.att.com 10. References: [ATM 1993] ATM Forum, ATM User-to-Network Interface (UNI) Specification: Version 3.0, Sept. 1993. [ATK 1993] R. Atkinson, Default IP MTU for use over ATM Adaptation Layer 5 (AAL 5), IETF Network Working Group Request for Comments-DRAFT, 11 June 1993. - 13 - [GAR 1993] J. Garrett, Directed ARP, IETF Network Working Group INTERNET- DRAFT, January 1993. [HAL 1993] J. Halpern, postings to the IP over ATM and Routing over Large Clouds discussion lists. [HEI 1993a] J. Heinanen, NBMA Address Resolution Protocol (NBMA ARP), Request for Comments: DRAFT, 1993. [HEI 1993b] J. Heinanen, Multiprotocol over Adaptation Type 5 on ATM, INTERNET-DRAFT, November 1992. [HEI 1992] J. Heinanen, Routing and Addressing in ATM Networks, private memorandum, 27 November, 1992. [ISO 8473] Information technology - Telecommunications and Information exchange between systems - Intermediate system to Intermediate system Intra-Domain routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473), International Organization for Standardization, 1992. [LAU 1993] M. Laubach, Classical IP and ARP over ATM, Network Working Group Request for Comments - Draft, 7 June 1993. [LIA 1993] F. Liaw, RIP over ATM: architecture, address translation, and call control, IP over ATM Working Group INTERNET DRAFT, 21 March, 1993. [LYO 1992] T. Lyon, F. Liaw, and A. Romanow, Network Layer Architecture for ATM Networks, private memorandum, 1992. [RFC 1293] T. Bradley and C. Brown, Inverse Address Resolution Protocol, IETF Networking Working Group RFC 1293, January 1992. [TSU 1993] P. Tsuchiya, Shortcut Routing: Discovery and Routing over Large Public Data Networks, IETF Network Working Group INTERNET- DRAFT, January 1993. 11. Appendix A: Potential Interworking Scenarios to be Supported by ARP In the eyes of the Private Network-to-Network Interface (P- NNI) working group of the ATM Forum, ATM networks can be of two types: those that participate in the P-NNI protocols and use NSAP modeled addresses (referred to as private networks, for short), and those that do not and only use native E.164 addresses. If nodes are attached to a private network, they - 14 - will use one of the NSAP modeled address formats in [ATM 93]; if the node is directly attached to a public network, then a connection request to that node must use the native E.164 format. The goal of the P-NNI protocols, and the ATM Forum UNI signaling specification [ATM 93], is to allow ATM connectivity between two or more nodes, regardless of which form of addressing is used by those nodes, and where they may be located. The issue for ARP, then is to know what information must be returned to allow such connectivity. Consider the following scenarios: +o Private host to Private Host, no intervening public transit network(s): Clearly requires that ARP return only the NSAP modeled address format of the end host. +o Private host to Private host, through intervening public networks: In this case, the connection setup from host A to host B must transit the public network(s). This requires that at each ingress point to the public network that a routing decision be made as to which is the correct egress point from that public network to the next hop private ATM switch, and that the native E.164 address of that egress point be found (finding this is a VC routing problem, probably requiring configuration of the public network links and connectivity information). ARP should return only the NSAP address of the endpoint. Then the well know mapping of the NSAP addresses to the subaddress of the Q.93b request, as specified in [ATM 93], can be made. +o Private Network Host to Public Network Host: To get connectivity between the public node and the private nodes requires the same kind of routing information discussed above - namely, the directly attached public network needs to know the (NSAP format) ATM address of the private station, and the native E.164 address of the egress point from the public network to that private network (or to that of an intervening transit private network etc.). There is some argument, that the ARP mechanism could return this egress point native E.164 address, but this may be considered inconsistent for ARP to return what to some is clearly routing information, and to others is required signaling information. In the opposite direction, the private network node can use, and should only get, the E.164 address of the directly attached public node. What format should this - 15 - information be carried in? This question is clearly answered, by Note 9 of Annex A of [ATM 93], Version 2.4 (passed by ballot recently to become Version 3.0), vis: A call originated on a Private UNI destined for an end system which only has a native (non-NSAP) E.164 address (i.e. a system directly attached to a public network supporting the native E.164 format) will code the Called Party number information element in the (NSAP) E.164 private ATM Address Format, with the RD, AREA, and ESI fields set to zero. The Called Party Subaddress information element is not used.S Hence, in this case, ARP should return the E.164 address of the public ATM station in NSAP format. This is essentially implying an algorithmic resolution between the native E.164 and NSAP addresses of _directly_ attached public stations. +o Public network host to Public network host, no intervening private network: In this case, clearly the Q.93b requests would use native E.164 address formats. +o Public network host to Public network host, intervening private network: same as the case immediately above, since getting to and through the private network is a VC routing, not an addressing issue. So several issues arise for ARP in supporting arbitrary connections between hosts on private and public network. One is how to distinguish between E.164 address and E.164 encoded NSAP modeled address. Another is what is the information to be supplied by ARP, e.g., in the public to private scenario should ARP return only the private NSAP modeled address or both an E.164 address, for a point of attachment between the public and private networks, along with the private NSAP modeled address. Figure 1: A Single Hop configuration between Subnet End Systems (Sub-ES) attached to the same subnet Figure 2: The Classical IP model as a concatenation of three separate ATM subnets; two SVC LATM subnets and a single PVC WATM subnet. Figure 3: An SVC-based WATM configuration between End Systems which in fact could be ESs or ISs. - 16 - Figure 4: The ATM Internet model imbeds within the ATM cloud network level routing features which in essence peers with traditional gateways or routers. Figure 5: The ATM transition model assuming the presence of gateways or routers between the ATM subnets and the ATM peer networks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25138; 24 Sep 93 21:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25134; 24 Sep 93 21:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18601; 24 Sep 93 21:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19573; Fri, 24 Sep 93 16:15:18 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19560; Fri, 24 Sep 93 16:15:17 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA02411; Fri, 24 Sep 93 16:15:41 -0700 Received: from mason1.gmu.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA05065; Fri, 24 Sep 93 16:16:04 -0700 Received: by mason1.gmu.edu (5.65/DEC-Ultrix/4.3/GMUv3) id AA05023; Fri, 24 Sep 1993 19:10:25 -0400 Received: from gershwin.cs by cs.gmu.edu (4.1/SMI-4.1) id AA17949; Fri, 24 Sep 93 19:10:54 EDT Date: Fri, 24 Sep 93 19:10:54 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Pullen Message-Id: <9309242310.AA17949@cs.gmu.edu> To: atm@hplms2.hpl.hp.com Subject: ATM Consortium Cc: mpullen@cs.gmu.edu, pashby@unh.edu Please add me to the list of folks who can't come to the meeting but would like information. Contact info: Dr. Mark Pullen Computer Science Dept George Mason University Fairfax, VA 22030 phone: 703-993-1538 fax: 703-993-3729 internet: mpullen@cs.gmu.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27807; 24 Sep 93 22:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27803; 24 Sep 93 22:47 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21715; 24 Sep 93 22:47 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA24899; Fri, 24 Sep 93 18:55:20 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from dns1.NMSU.Edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA24886; Fri, 24 Sep 93 18:55:19 -0700 Received: from wilma (wilma.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA00458; Fri, 24 Sep 93 19:55:44 MDT Received: by wilma (4.1/NMSU) id AA16320; Fri, 24 Sep 93 19:55:43 MDT Date: Fri, 24 Sep 1993 19:52:18 -0600 (MDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ravi Subbarao Subject: Re: ATM Consortium To: atm@matmos.hpl.hp.com In-Reply-To: <9309242310.AA17949@cs.gmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I would also like to get information about the ATM consortium in NH. Thanks, Ravi Subbarao CANTO, Networking New Mexico State University Las Cruces NM 88003 Voice: 505-646-5779   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05260; 25 Sep 93 1:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05256; 25 Sep 93 1:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25270; 25 Sep 93 1:10 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA28401; Fri, 24 Sep 93 21:20:31 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from netcom5.netcom.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA28388; Fri, 24 Sep 93 21:20:29 -0700 Received: from netcom6.netcom.com by netcom5.netcom.com (5.65/SMI-4.1/Netcom) id AA14180; Fri, 24 Sep 93 21:21:18 -0700 Date: Fri, 24 Sep 93 21:21:18 -0700 Message-Id: <9309250421.AA14180@netcom5.netcom.com> To: atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Earl Ferguson Subject: Re: The nit'ted Classical Draft I am relatively new to following the Classical IP and ARP over ATM. However, I have a few more nits: 1) The use of MUST, SHALL, or MANDATORY; SHOULD or RECOMMEND; and MAY or OPTIONAL; is inconsistent. Sometimes used with all caps, other times without. I suggest a consistent approach (I prefer all caps, since it brings attention to the point). [see page 6 items under "The requirements for IP members ... LIS configuration are:", items 3 & 4 are "must", item 5 is "MUST" - is there a difference? I assume not.] 2) I suggest the note in section 5 page 2 could be extended: Note: this memo defines only the operation of IP and ARP over ATM, and is not meant to describe the operation of ATM networks. Any reference to VC, PVC or SVC applies only to virtual channels used to support IP and ARP over ATM, and thus are assumed to be using AAL-5 and LLC/SNAP encapsulation. This memo places no restrictions or requirements on VCs used for other purposes (e.g. signalling, ILMI, bridging, other protocols, CBR traffic using other AALs, etc.). Otherwise, there may be the implication, at various places in the document, that all ATM VCs are for the purpose of IP. This will not likely be the case, especially for servers (ARP and otherwise). SVCs or PVCs with/without LLC SNAP may be used for non-IP purposes (signalling, bridging, other protocols, etc.). For example, the statement "All IP members supporting PVCs are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those VCs using LLC/SNAP encapsulation." (Page 8, 2nd par. 1st sentence) implies that all PVCs using LLC/SNAP encapsulation are used for IP and ARP over ATM. 3) There are two (or more) statements that a single ARP server is to be used within an LIS, but I saw no statement of this being mandatory, recommended, or optional; yet "This server must have authoritative responsibility for resolving the ARP requests of all IP members within the LIS." I assume that there MUST be an ARP server in the LIS when SVCs are used. And further, according to this model, there MUST be only one per LIS. 4) Page 9, last par. 4th line remove "(in the SVC environment)". The ARP server is only used in the SVC environment (at least I did not find a use for it in the PVC environment). 5) Page 10 item 3, 1st line. (editorial) remove the last word, "to". 6) Page 15, "Open Issues" second item. It is not clear to me how "well-known PVC numbers" would be used. In the PVC environment, each PVC is assumed to be a channel to another LIS host. I saw no other use of PVCs in the document that would allow for use of "well-known" PVCs. I hope this doesn't open up a "can of worms". Feel free to tell me to "get lost" if my comments are off base or out of order. Earl Ferguson LANSPeed, Inc. _________________________________________________________________________ | Earl Ferguson | The Highest Performance Enterprise | | V.P. Engineering | Internetworking Solutions | | LANSpeed, Inc. |=======================================| | 7175 Brisbane Ct. | Off: 408.446.0942 Fax: 408.746.0328 | | San Jose, CA 95129 | Home: 408.736.2776 earlf@netcom.com |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02167; 26 Sep 93 22:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02163; 26 Sep 93 22:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28372; 26 Sep 93 22:37 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA23657; Sun, 26 Sep 93 18:26:57 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA23644; Sun, 26 Sep 93 18:26:55 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA09692; Sun, 26 Sep 93 18:27:37 -0700 Received: from oskgate0.mei.co.jp by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA09584; Sun, 26 Sep 93 18:27:57 -0700 Received: by oskgate0.mei.co.jp (5.65mei1.1/5.2:4.3:oskgate:930808) id AA07067; Mon, 27 Sep 93 10:26:10 +0900 Received: by chorus.isl.mei.co.jp (5.65mei1.1/5.2:4.3:chorus:930808) id AA28850; Mon, 27 Sep 93 10:26:05 +0900 Received: by solbol.icrl.mew.mei.co.jp (5.65/4.2:2.0:master:920522) id AA27063; Mon, 27 Sep 93 10:06:45 +0900 Date: Mon, 27 Sep 93 10:06:45 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Spencer Jackson Message-Id: <9309270106.AA27063@solbol.icrl.mew.mei.co.jp> To: atm@hplms2.hpl.hp.com Subject: Please remove me. Please remove me from the atm mailing list. Thanks, Spence Jackson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08970; 27 Sep 93 1:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab08966; 27 Sep 93 1:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03798; 27 Sep 93 1:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01162; Sun, 26 Sep 93 22:03:20 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01147; Sun, 26 Sep 93 22:03:19 -0700 Message-Id: <9309270503.AA01147@matmos.hpl.hp.com> To: Earl Ferguson Cc: atm@matmos.hpl.hp.com Subject: Re: The nit'ted Classical Draft In-Reply-To: Your message of Fri, 24 Sep 93 21:21:18 -0700 Date: Sun, 26 Sep 93 22:03:19 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Thanks for your comments Earl. The latest version of the classical draft is available via ftp anonymous from matmos.hpl.hp.com as: pub/ip-atm/classic-ip-03.txt It is cheaper to send to ftp notice than to send out the 38K bytes to all recipients. Changes to this version: 1. Many grammar and wording nits, thanks to all! 2. The MAC vs E.164 paragraph under packet format has been moved from MUST to strongly RECOMMENDED. I would like to submit this upwards (to the IESG) on Wednesday. I'd like to get this now so that we can deal with any feedback from them at the Houston meeting. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10454; 27 Sep 93 4:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10450; 27 Sep 93 4:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06214; 27 Sep 93 4:37 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03979; Mon, 27 Sep 93 00:34:56 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from solomon.technet.sg by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03966; Mon, 27 Sep 93 00:34:52 -0700 Received: from localhost by solomon.technet.sg (8.3/1.34) id PAA27125; Mon, 27 Sep 1993 15:35:25 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ng Wee Teck Message-Id: <199309270735.PAA27125@solomon.technet.sg> Subject: Re: Please remove me. To: atm@matmos.hpl.hp.com Date: Mon, 27 Sep 1993 15:35:24 -0800 (PST) In-Reply-To: <9309270106.AA27063@solbol.icrl.mew.mei.co.jp> from "Spencer Jackson" at Sep 27, 93 10:06:45 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 69 > > > Please remove me from the atm mailing list. > > Thanks, >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12006; 27 Sep 93 7:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12002; 27 Sep 93 7:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08798; 27 Sep 93 7:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08986; Mon, 27 Sep 93 03:11:51 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08973; Mon, 27 Sep 93 03:11:51 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11403; Mon, 27 Sep 93 03:12:35 -0700 Received: from utrhcs.cs.utwente.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA10738; Mon, 27 Sep 93 03:12:57 -0700 Received: from utis157.cs.utwente.nl by utrhcs.cs.utwente.nl (4.1/RBCS-2.5mx) id AA02954; Mon, 27 Sep 93 11:11:05 +0100 Received: by utis157.cs.utwente.nl (4.1/RBCS-1.0.1) id AA12609; Mon, 27 Sep 93 11:10:58 +0100 Message-Id: <9309271010.AA12609@utis157.cs.utwente.nl> To: atm@hplms2.hpl.hp.com Subject: ATM Consortium Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hans van der Veen Date: Mon, 27 Sep 93 11:10:58 +0100 I can't come to the meeting, but would appreciate to receive information Thanks in advance, Hans. ___ __/ \__________ Hans van der Veen | \___/ | University of Twente tfx. +31 53 333815 |___ __ ___ | Tele-Informatics & Open Systems tel. +31 53 893747 | | | / \ (__ | P.O. Box 217 NL-7500 AE Enschede The Netherlands | | | \__/ ___) | |_________________|   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13301; 27 Sep 93 8:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13297; 27 Sep 93 8:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10442; 27 Sep 93 8:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11680; Mon, 27 Sep 93 04:40:36 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from inet-gw-2.pa.dec.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11667; Mon, 27 Sep 93 04:40:35 -0700 Received: by inet-gw-2.pa.dec.com; id AA13073; Mon, 27 Sep 93 04:41:20 -0700 Received: by us1rmc.bb.dec.com; id AA21527; Mon, 27 Sep 93 07:40:15 -0400 Message-Id: <9309271140.AA21527@us1rmc.bb.dec.com> Received: from quiver.enet; by us1rmc.enet; Mon, 27 Sep 93 07:40:15 EDT Date: Mon, 27 Sep 93 07:40:15 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mail Delivery Subsystem <"abasin::mailer-daemon"@quiver.enet.dec.com> To: us1rmc: "atm@matmos.hpl.hp.com"@quiver.enet.dec.com; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Apparently-To: atm@matmos.hpl.hp.com Subject: Returned mail: Deferred ----- Transcript of session follows ----- <<< RCPT To: <<< DATA 554 mailer mail died with signal 11 ----- Unsent message follows ----- Received: from QUIVER.DECnet MAIL11D_V3 by abasin.lkg.dec.com (5.57/Ultrix3.0-C) id AA11450; Mon, 27 Sep 93 07:42:33 -0400 Date: Mon, 27 Sep 93 07:42:32 -0400 From: quiver::US1RMC::"atm@matmos.hpl.hp.com" (MAIL-11 Daemon) To: atm@hplms2.hpl.hp.com Subject: ATM Consortium I can't come to the meeting, but would appreciate to receive information Thanks in advance, Hans. ___ __/ \__________ Hans van der Veen | \___/ | University of Twente tfx. +31 53 333815 |___ __ ___ | Tele-Informatics & Open Systems tel. +31 53 893747 | | | / \ (__ | P.O. Box 217 NL-7500 AE Enschede The Netherlands | | | \__/ ___) | |_________________| % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us1rmc.bb.dec.com; id AA21494; Mon, 27 Sep 93 07:39:31 -0400 % Received: by inet-gw-1.pa.dec.com; id AA25994; Mon, 27 Sep 93 04:40:28 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08986; Mon, 27 Sep 93 03:11:51 -0700 % Reply-To: atm@matmos.hpl.hp.com % Errors-To: atm-request@matmos.hpl.hp.com % Sender: atm-request@matmos.hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % X-Loop: ATM CLP.bit ON % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08973; Mon, 27 Sep 93 03:11:51 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11403; Mon, 27 Sep 93 03:12:35 -070 % Received: from utrhcs.cs.utwente.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA10738; Mon, 27 Sep 93 03:12:57 -070 % Received: from utis157.cs.utwente.nl by utrhcs.cs.utwente.nl (4.1/RBCS-2.5mx) id AA02954; Mon, 27 Sep 93 11:11:05 +010 % Received: by utis157.cs.utwente.nl (4.1/RBCS-1.0.1) id AA12609; Mon, 27 Sep 93 11:10:58 +010 % Message-Id: <9309271010.AA12609@utis157.cs.utwente.nl> % To: atm@hplms2.hpl.hp.com % Subject: ATM Consortium % From: Hans van der Veen % Date: Mon, 27 Sep 93 11:10:58 +0100   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20029; 27 Sep 93 12:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20025; 27 Sep 93 12:19 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16915; 27 Sep 93 12:19 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15699; Mon, 27 Sep 93 06:35:46 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from inet-gw-2.pa.dec.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA15686; Mon, 27 Sep 93 06:35:45 -0700 Received: by inet-gw-2.pa.dec.com; id AA19039; Mon, 27 Sep 93 06:36:30 -0700 Received: by us1rmc.bb.dec.com; id AA26800; Mon, 27 Sep 93 09:35:25 -0400 Message-Id: <9309271335.AA26800@us1rmc.bb.dec.com> Received: from quiver.enet; by us1rmc.enet; Mon, 27 Sep 93 09:35:26 EDT Date: Mon, 27 Sep 93 09:35:26 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mail Delivery Subsystem <"abasin::mailer-daemon"@quiver.enet.dec.com> To: us1rmc: "atm@matmos.hpl.hp.com"@quiver.enet.dec.com; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Apparently-To: atm@matmos.hpl.hp.com Subject: Returned mail: unknown mailer error 1 ----- Transcript of session follows ----- <<< RCPT To: <<< DATA libmld: Error: st_malloc: cannot allocate item 554 ... unknown mailer error 1 ----- Unsent message follows ----- Received: from QUIVER.DECnet MAIL11D_V3 by abasin.lkg.dec.com (5.57/Ultrix3.0-C) id AA11479; Mon, 27 Sep 93 08:49:22 -0400 Date: Mon, 27 Sep 93 08:49:22 -0400 From: quiver::US1RMC::"atm@matmos.hpl.hp.com" (MAIL-11 Daemon) To: Subject: Returned mail: Deferred ----- Transcript of session follows ----- <<< RCPT To: <<< DATA 554 mailer mail died with signal 11 ----- Unsent message follows ----- Received: from QUIVER.DECnet MAIL11D_V3 by abasin.lkg.dec.com (5.57/Ultrix3.0-C) id AA11450; Mon, 27 Sep 93 07:42:33 -0400 Date: Mon, 27 Sep 93 07:42:32 -0400 From: quiver::US1RMC::"atm@matmos.hpl.hp.com" (MAIL-11 Daemon) To: atm@hplms2.hpl.hp.com Subject: ATM Consortium I can't come to the meeting, but would appreciate to receive information Thanks in advance, Hans. ___ __/ \__________ Hans van der Veen | \___/ | University of Twente tfx. +31 53 333815 |___ __ ___ | Tele-Informatics & Open Systems tel. +31 53 893747 | | | / \ (__ | P.O. Box 217 NL-7500 AE Enschede The Netherlands | | | \__/ ___) | |_________________| % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us1rmc.bb.dec.com; id AA21494; Mon, 27 Sep 93 07:39:31 -0400 % Received: by inet-gw-1.pa.dec.com; id AA25994; Mon, 27 Sep 93 04:40:28 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08986; Mon, 27 Sep 93 03:11:51 -0700 % Reply-To: atm@matmos.hpl.hp.com % Errors-To: atm-request@matmos.hpl.hp.com % Sender: atm-request@matmos.hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % X-Loop: ATM CLP.bit ON % Precedence: bulk % Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08973; Mon, 27 Sep 93 03:11:51 -0700 % Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11403; Mon, 27 Sep 93 03:12:35 -070 % Received: from utrhcs.cs.utwente.nl by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA10738; Mon, 27 Sep 93 03:12:57 -070 % Received: from utis157.cs.utwente.nl by utrhcs.cs.utwente.nl (4.1/RBCS-2.5mx) id AA02954; Mon, 27 Sep 93 11:11:05 +010 % Received: by utis157.cs.utwente.nl (4.1/RBCS-1.0.1) id AA12609; Mon, 27 Sep 93 11:10:58 +010 % Message-Id: <9309271010.AA12609@utis157.cs.utwente.nl> % To: atm@hplms2.hpl.hp.com % Subject: ATM Consortium % From: Hans van der Veen % Date: Mon, 27 Sep 93 11:10:58 +0100 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us1rmc.bb.dec.com; id AA23736; Mon, 27 Sep 93 08:46:42 -0400 % Received: by inet-gw-1.pa.dec.com; id AA28724; Mon, 27 Sep 93 05:47:31 -0700 % Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11680; Mon, 27 Sep 93 04:40:36 -0700 % Reply-To: atm@matmos.hpl.hp.com % Errors-To: atm-request@matmos.hpl.hp.com % Sender: atm-request@matmos.hpl.hp.com % X-Info: Submissions to atm@hpl.hp.com % X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com % X-Loop: ATM CLP.bit ON % Precedence: bulk % Received: from inet-gw-2.pa.dec.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11667; Mon, 27 Sep 93 04:40:35 -0700 % Received: by inet-gw-2.pa.dec.com; id AA13073; Mon, 27 Sep 93 04:41:20 -0700 % Received: by us1rmc.bb.dec.com; id AA21527; Mon, 27 Sep 93 07:40:15 -0400 % Message-Id: <9309271140.AA21527@us1rmc.bb.dec.com> % Received: from quiver.enet; by us1rmc.enet; Mon, 27 Sep 93 07:40:15 EDT % Date: Mon, 27 Sep 93 07:40:15 EDT % From: Mail Delivery Subsystem % To: % Apparently-To: atm@matmos.hpl.hp.com % Subject: Returned mail: Deferred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21287; 27 Sep 93 13:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21283; 27 Sep 93 13:33 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19339; 27 Sep 93 13:33 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19205; Mon, 27 Sep 93 08:03:02 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19192; Mon, 27 Sep 93 08:03:02 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA11998; Mon, 27 Sep 93 08:03:48 -0700 Received: from LOBSTER.WELLFLEET.COM by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA11225; Mon, 27 Sep 93 08:04:13 -0700 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04148; Mon, 27 Sep 93 10:53:29 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA08883; Mon, 27 Sep 93 11:04:26 EDT Date: Mon, 27 Sep 93 11:04:26 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9309271504.AA08883@cabernet.wellfleet> To: curtis@ans.net Subject: Re: Classical Draft Status Cc: atm@hplms2.hpl.hp.com, rcallon@wellfleet.com I agree with what you suggest. I suspect the problem is not as bad as you make it out to be. Consider what happens if we come up with some totally incompatible addressing scheme in the future (ie: one that for some reason uses neither NSAP or E164 - I know that is is unlikely, just consider it a worst case hypothetical example). This is not the end of the world for the old hosts. A router on the local LAN can be configured to recognize that some hosts on the LAN have this limitation and provide a next hop for the route that is that router. Presumably the host and router can exchange ARP and have compatible addressing on the local LAN. The host would resolve the physical address of the next hop and connectivity would be established. Similarly, the router would provide the outside world with a route with the next hop of itself. To the old host, the outside world looks no different than if it were routing to an ethernet on the other side of it's local router. To the outside world, the old host looks no different than if it were on an ethernet. Isn't interoperability among different media type how IP got started in the first place and it's most critical key to success? Curtis; Yes, you have a good point. If we mess up the initial host behavior, then the worst case is that we end up supporting two types of LIS's in the future, one for old hosts only, and one for new updated hosts only. Each host, as it is updated, is moved from one LIS to the other LIS (and since both *logical* subnets are on the same *physical* subnet, the host does not need to be physically moved at all). However, this leads to another issue, if the old hosts understand which subnet another host is on based on IP addresss plus subnet mask, then all of the old hosts on one "old-style" LIS will need to have IP addresses selected from the same IP subnet. All of the new hosts on different "new-style" LIS's will need to have IP addresses selected from a different IP subnet (so that the old IP hosts know to go through a router to reach them). Thus when one single host is updated (assuming a "one host at a time" migration technique) it`s IP address will need to be changed. [Alternatively the router could proxy ARP for all other hosts which are in the same IP subnet, but not on the old- style LIS; However, this seems to lead to an issue when the source hosts thinks that it has opened an ATM SVC to the destination host, but really has only opened an SVC to the router]. An more efficient approach (from the point of view of the humans having to manage the network) would be to have a mechanism that all hosts operating IP over ATM can understand which tells the host that a particular destination host is "off subnet". This would allow the ARP server, when responding to an ARP request, to say "use a router to get to this host". Now, this does imply somewhat of a change from the classical IP model, in the sense that ARP servers and routers would need to know which subnet each host is on. This becomes very similar to the CLNP/IS-IS routing model. This will work fine, but only if there is some way for the ARP server to say "go to a router". Perhaps we could fit this into the existing model either by having the ARP server return the ATM address of the router, or by having the hosts know that if ARP fails, then they should try a router next (rather than just give up). All of this implies to me that there is some value in trying to avoid this type of migration, by making the host operation slightly more general to begin with. I think that this would require that the paragraph and table on the bottom of page 12 (of the September 22nd version of the draft, which Mark sent to the mailing list) be changed to say "For informational purposes, this is the way that the ATM forum currently specify operation of the ATM address and subaddress, but we are going to be more general by requiring that hosts running IP over ATM ...." Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24142; 27 Sep 93 15:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24138; 27 Sep 93 15:52 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24697; 27 Sep 93 15:52 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA27186; Mon, 27 Sep 93 10:59:06 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA27173; Mon, 27 Sep 93 10:59:05 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA13156; Mon, 27 Sep 93 10:59:53 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12658; Mon, 27 Sep 93 11:00:18 -0700 Received: by interlock.ans.net id AA15993 (InterLock SMTP Gateway 1.1 for atm@hpl.hp.com); Mon, 27 Sep 1993 13:53:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Sep 1993 13:53:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Sep 1993 13:53:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309271757.AA83107@foo.ans.net> To: Ross Callon Cc: curtis@ans.net, atm@hplms2.hpl.hp.com, curtis@ans.net Subject: Re: Classical Draft Status In-Reply-To: (Your message of Mon, 27 Sep 93 11:04:26 EDT.) <9309271504.AA08883@cabernet.wellfleet> Date: Mon, 27 Sep 93 13:57:40 -0500 Ross, Still no need to change the classical model or ARP. > However, this leads to another issue, if the old hosts understand > which subnet another host is on based on IP addresss plus subnet mask, > then all of the old hosts on one "old-style" LIS will need to have IP > addresses selected from the same IP subnet. All of the new hosts on > different "new-style" LIS's will need to have IP addresses selected > from a different IP subnet (so that the old IP hosts know to go > through a router to reach them). Thus when one single host is updated > (assuming a "one host at a time" migration technique) it`s IP address > will need to be changed. [Alternatively the router could proxy ARP for > all other hosts which are in the same IP subnet, but not on the old- > style LIS; However, this seems to lead to an issue when the source > hosts thinks that it has opened an ATM SVC to the destination host, > but really has only opened an SVC to the router]. I'd prefer to use routing rather than proxy ARP. > An more efficient approach (from the point of view of the humans > having to manage the network) would be to have a mechanism that all > hosts operating IP over ATM can understand which tells the host that > a particular destination host is "off subnet". This would allow the > ARP server, when responding to an ARP request, to say "use a router > to get to this host". I've suggested we define a new BGP or IDRP attribute so you ARP for the right thing in the first place. I'd prefer to let routing protocols do routing and let ARP do address resolution. > Now, this does imply somewhat of a change from the classical IP > model, in the sense that ARP servers and routers would need to know > which subnet each host is on. This becomes very similar to the > CLNP/IS-IS routing model. This will work fine, but only if there > is some way for the ARP server to say "go to a router". Perhaps we > could fit this into the existing model either by having the ARP > server return the ATM address of the router, or by having the hosts > know that if ARP fails, then they should try a router next (rather > than just give up). If the routing protocol gives a special attribute to indicate whether you are to ARP for the next hop or ARP for the destination. This way in the best case the old host could get two routes, one for the old host compatible LIS for which it ARPs for the destination, the other for the new incompatible LIS in which it ARPs for the next hop and passes all data to the router. No change to the classical model and very little change to BGP or IDRP (a new attribute) accomplish this. This has been discussed in ROLC. The outside LIS could even follow the default route to the border router (yielding one route for the local LIS and one for default). Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24358; 27 Sep 93 15:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24350; 27 Sep 93 15:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25048; 27 Sep 93 15:59 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25179; Mon, 27 Sep 93 10:36:29 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA25166; Mon, 27 Sep 93 10:36:28 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA13008; Mon, 27 Sep 93 10:37:13 -0700 Received: from reggae.concert.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA12472; Mon, 27 Sep 93 10:37:36 -0700 Received: from chaos.wg.com by reggae.concert.net (5.65/tas-reggae/8-15-92) id AA28555; Mon, 27 Sep 93 13:35:09 -0400 Received: from wgt-dev2.wg by wg.com (4.1/SMI-4.1) id AA01603; Mon, 27 Sep 93 13:37:35 EDT Date: Mon, 27 Sep 93 13:37:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Richard W. Cornetti" Message-Id: <9309271737.AA01603@wg.com> To: atm@hplms2.hpl.hp.com Subject: Re: UNH/IOL ATM Interoperability Lab I cannot attend this meeting, but am interested in the lab. Please keep me informed. ============================================================================= Richard W. Cornetti | cornetti@wg.com | It is better to know Senior Marketing Engineer | TEL: (919) 941-5730 | useless things than Wandel & Goltermann Technologies | FAX: (919) 941-5751 | to know nothing.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26832; 27 Sep 93 17:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26828; 27 Sep 93 17:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00322; 27 Sep 93 17:57 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01264; Mon, 27 Sep 93 13:33:36 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from clavin.cs.tamu.edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA01251; Mon, 27 Sep 93 13:33:28 -0700 Received: from cs.tamu.edu (solar.cs.tamu.edu) by clavin (AA22804); Mon, 27 Sep 93 15:31:56 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Amitava Raha Message-Id: <9309272031.AA22804@clavin> Subject: ATM Consortium To: atm@matmos.hpl.hp.com Date: Mon, 27 Sep 1993 15:31:49 -0500 (CDT) Priority: 1 Precedence: 1 X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 364 Please add me to the list of folks who can't come to the meeting but would like information. Contact info: Amitava Raha Computer Science Department Texas A&M University College Station, TX 77843-3112 phone: 409-847-8772 fax: 409-847-8578 internet : amitava@cs.tamu.edu thanks amitava email: amitava@cs.tamu.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27336; 27 Sep 93 19:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27332; 27 Sep 93 19:04 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01768; 27 Sep 93 19:04 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03064; Mon, 27 Sep 93 14:28:41 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03051; Mon, 27 Sep 93 14:28:40 -0700 Date: Mon, 27 Sep 93 14:28:40 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309272128.AA03051@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: amended ARP section for consideration ATM'ers, Just to stir the pot a bit... As I've been watching the debates come and go on some of the specific text in the ARP section, I've created the following amended wording of some of the more controversial paragraphs which I've attached to the end of this message. Please comment. Mark ------------------------------------------------------------------- [please cut and paste mentally] ATM addresses in Q.93B (as defined by the ATM Forum [9]) include a "Calling Party Number Information Element" and a "Calling Party Subaddress Information Element". These Information Elements (IEs) map to ARP/InARP source ATM number and source ATM subaddress respectively. Furthermore, ATM Forum defines a "Called Party Number Information Element" and a "Called Party Subaddress Information Element". These IEs map to ARP/InARP target ATM number and target ATM subaddress respectively. The ATM Forum defines three structures for the combined use of number and subaddress [9]: ATM Number ATM Subaddress -------------- -------------- Structure 1 ATM Forum NSAP null Structure 2 E.164 null Structure 3 E.164 ATM Forum NSAP Implementations based on this memo MUST support all three ATM address structures. ARP and InARP requests and replies for ATM address structures 1 and 2 MUST indicate a null ATM subaddress; i.e. ar$sstl.type = 1 and ar$sstl.length = 0 and ar$tstl.type = 1 and ar$tstl.length = 0. Background information: the ARP packet format presented in this memo is general in nature in that the ATM number and ATM subaddress fields map directly to the corresponding Q.93B fields used for ATM call/connection setup signalling messages. The IP over ATM Working Group expects ATM Forum NSAPs numbers (Structure 1) to predominate over E.164 numbers (Structure 2) as ATM endpoint identifiers within ATM LANs. The ATM Forum's operational use of ATM Address Structure 3 is not completely defined at this time however, this structure will be used in the future. It is for this reason that IP stations need to support all three ATM address structures. Furthermore, the classic model in this memo presumes that the administrative boundaries of LISs will roughly correspond with those of ATM LANs for the next few years. The implication of this is that the same ATM address structure will most likely be used across the ATM LAN. Administrators of these networks MAY want to achieve some consistency in addressing to promote ease of management if the ATM configuration allows such flexibility. Therefore, administrators are encouraged to implement the following guidelines: o All members of an LIS MAY use the same ATM address structure. o If ATM Forum NSAPs are used, then that same encoding MAY be used within an LIS and replies will use the same encoding as queries. For example, NSAPs may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 ATM addresses may be used but not both. -end-   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27796; 27 Sep 93 20:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27792; 27 Sep 93 20:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04472; 27 Sep 93 20:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA06805; Mon, 27 Sep 93 16:40:01 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA06789; Mon, 27 Sep 93 16:39:58 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA21423; Mon, 27 Sep 93 16:40:35 PDT Received: by msgate.hls.com with Microsoft Mail id <2CA77D02@msgate.hls.com>; Mon, 27 Sep 93 16:53:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , Mark Laubach Subject: RE: amended ARP section for consideration Date: Mon, 27 Sep 93 16:36:00 PDT Message-Id: <2CA77D02@msgate.hls.com> Encoding: 109 TEXT X-Mailer: Microsoft Mail V3.0 Mark, Some comments: > ATM addresses in Q.93B (as defined by the ATM Forum [9]) include a > "Calling Party Number Information Element" and a "Calling Party > Subaddress Information Element". These Information Elements (IEs) > map to ARP/InARP source ATM number and source ATM subaddress > respectively. Furthermore, ATM Forum defines a "Called Party Number > Information Element" and a "Called Party Subaddress Information > Element". These IEs map to ARP/InARP target ATM number and target ATM > subaddress respectively. These IEs *could* map to the ARP/inARP address/subaddress fields, assuming we want ARP to start supplying source routing information. Perhaps, given the controversy, you should add phrases like 'may map' or 'could map', since we are still debating this issue. > The ATM Forum defines three structures for the combined use of number > and subaddress [9]: > > ATM Number ATM Subaddress > -------------- -------------- > Structure 1 ATM Forum NSAP null > Structure 2 E.164 null > Structure 3 E.164 ATM Forum NSAP > > Implementations based on this memo MUST support all three ATM address > structures. So I can't build an ARP server or host that I only want to deploy in a private network (or public network) and that will only support private (or public) ATM addressing? Just wondering... > Background information: the ARP packet format presented in this memo > is general in nature in that the ATM number and ATM subaddress fields > map directly to the corresponding Q.93B fields used for ATM > call/connection setup signalling messages. The IP over ATM Working > Group expects ATM Forum NSAPs numbers (Structure 1) to predominate > over E.164 numbers (Structure 2) as ATM endpoint identifiers within > ATM LANs. The ATM Forum's operational use of ATM Address Structure 3 > is not completely defined at this time however, this structure will > be used in the future. Just to be pedantic: I think the *use* of the structure 3 ATM *addressing* is very well understood, (i.e. how to shift them around between the address and subaddress etc) - what is not well understood are the *routing* issues within ATM networks, that might lead to the use of such addresses. >It is for this reason that IP stations need to support all three ATM address >structures. What is an 'IP station' ? The only cases in which my *host* might need to support structure 3 are (1.) it is a gateway between a public and private ATM network, or (2.) it is _directly_ attached to a public network. If I don't want to do either of these, what do I care whether it supports structure 3 (or structure 2 for that matter)? Perhaps you meant ARP server rather than host?? > Furthermore, the classic model in this memo presumes that the > administrative boundaries of LISs will roughly correspond with those > of ATM LANs for the next few years. The implication of this is that > the same ATM address structure will most likely be used across the > ATM LAN. Administrators of these networks MAY want to achieve some > consistency in addressing to promote ease of management if the ATM > configuration allows such flexibility. Therefore, administrators are > encouraged to implement the following guidelines: > > o All members of an LIS MAY use the same ATM address structure. In this context, would it not be better to say 'SHOULD' rather than 'MAY'? > o If ATM Forum NSAPs are used, then that same encoding MAY be used > within an LIS and replies will use the same encoding as queries. > For example, NSAPs may encode IEEE 48-bit MAC addresses or may > encode E.164 addresses. Within the LIS either IEEE MAC or E.164 > ATM addresses may be used but not both. Ditto - MAY --> SHOULD. Also, it would be clearer to say NSAP encoded E.164 rather than E.164, since this can be confused with native E.164 addresses (which I presume is not what you meant). This paragraph also needs to be clarified - you may want to assign nodes with the same type of NSPA address, but you will still need to 'use' different types of addresses within the LIS - e.g. even if the type of private NSAP addressing used is consistent, nodes will still need to be able to send requests with NSAP encoded E.164 numbers, if they want to talk to a public node. Perhaps in the last sentence 'use' should be changed to 'assigned'. Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28066; 27 Sep 93 21:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28062; 27 Sep 93 21:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06728; 27 Sep 93 21:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA08723; Mon, 27 Sep 93 17:29:03 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08707; Mon, 27 Sep 93 17:29:01 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA22828; Mon, 27 Sep 93 17:29:40 PDT Received: by msgate.hls.com with Microsoft Mail id <2CA78882@msgate.hls.com>; Mon, 27 Sep 93 17:42:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , Mark Laubach Subject: RE: amended ARP section for consideration Date: Mon, 27 Sep 93 16:36:00 PDT Message-Id: <2CA78882@msgate.hls.com> Encoding: 109 TEXT X-Mailer: Microsoft Mail V3.0 Mark, Some comments: > ATM addresses in Q.93B (as defined by the ATM Forum [9]) include a > "Calling Party Number Information Element" and a "Calling Party > Subaddress Information Element". These Information Elements (IEs) > map to ARP/InARP source ATM number and source ATM subaddress > respectively. Furthermore, ATM Forum defines a "Called Party Number > Information Element" and a "Called Party Subaddress Information > Element". These IEs map to ARP/InARP target ATM number and target ATM > subaddress respectively. These IEs *could* map to the ARP/inARP address/subaddress fields, assuming we want ARP to start supplying source routing information. Perhaps, given the controversy, you should add phrases like 'may map' or 'could map', since we are still debating this issue. > The ATM Forum defines three structures for the combined use of number > and subaddress [9]: > > ATM Number ATM Subaddress > -------------- -------------- > Structure 1 ATM Forum NSAP null > Structure 2 E.164 null > Structure 3 E.164 ATM Forum NSAP > > Implementations based on this memo MUST support all three ATM address > structures. So I can't build an ARP server or host that I only want to deploy in a private network (or public network) and that will only support private (or public) ATM addressing? Just wondering... > Background information: the ARP packet format presented in this memo > is general in nature in that the ATM number and ATM subaddress fields > map directly to the corresponding Q.93B fields used for ATM > call/connection setup signalling messages. The IP over ATM Working > Group expects ATM Forum NSAPs numbers (Structure 1) to predominate > over E.164 numbers (Structure 2) as ATM endpoint identifiers within > ATM LANs. The ATM Forum's operational use of ATM Address Structure 3 > is not completely defined at this time however, this structure will > be used in the future. Just to be pedantic: I think the *use* of the structure 3 ATM *addressing* is very well understood, (i.e. how to shift them around between the address and subaddress etc) - what is not well understood are the *routing* issues within ATM networks, that might lead to the use of such addresses. >It is for this reason that IP stations need to support all three ATM address >structures. What is an 'IP station' ? The only cases in which my *host* might need to support structure 3 are (1.) it is a gateway between a public and private ATM network, or (2.) it is _directly_ attached to a public network. If I don't want to do either of these, what do I care whether it supports structure 3 (or structure 2 for that matter)? Perhaps you meant ARP server rather than host?? > Furthermore, the classic model in this memo presumes that the > administrative boundaries of LISs will roughly correspond with those > of ATM LANs for the next few years. The implication of this is that > the same ATM address structure will most likely be used across the > ATM LAN. Administrators of these networks MAY want to achieve some > consistency in addressing to promote ease of management if the ATM > configuration allows such flexibility. Therefore, administrators are > encouraged to implement the following guidelines: > > o All members of an LIS MAY use the same ATM address structure. In this context, would it not be better to say 'SHOULD' rather than 'MAY'? > o If ATM Forum NSAPs are used, then that same encoding MAY be used > within an LIS and replies will use the same encoding as queries. > For example, NSAPs may encode IEEE 48-bit MAC addresses or may > encode E.164 addresses. Within the LIS either IEEE MAC or E.164 > ATM addresses may be used but not both. Ditto - MAY --> SHOULD. Also, it would be clearer to say NSAP encoded E.164 rather than E.164, since this can be confused with native E.164 addresses (which I presume is not what you meant). This paragraph also needs to be clarified - you may want to assign nodes with the same type of NSPA address, but you will still need to 'use' different types of addresses within the LIS - e.g. even if the type of private NSAP addressing used is consistent, nodes will still need to be able to send requests with NSAP encoded E.164 numbers, if they want to talk to a public node. Perhaps in the last sentence 'use' should be changed to 'assigned'. Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01948; 27 Sep 93 23:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01944; 27 Sep 93 23:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09854; 27 Sep 93 23:24 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10988; Mon, 27 Sep 93 18:28:20 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA10974; Mon, 27 Sep 93 18:28:16 -0700 To: "Alles, Anthony" Subject: RE: amended ARP section for consideration In-Reply-To: <2CA77D02@msgate.hls.com> References: <2CA77D02@msgate.hls.com> Cc: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Mon, 27 Sep 93 18:28:16 -0700 Message-Id: <930927182816.6529@matmos.hpl.hp.com> Encoding: 53 TEXT, 2 TEXT SIGNATURE > These IEs *could* map to the ARP/inARP address/subaddress fields, > assuming we want ARP to start supplying source routing information. > Perhaps, given the controversy, you should add phrases like 'may map' > or 'could map', since we are still debating this issue. Ok, I would prefer "should map" rather than the implied "must map". > So I can't build an ARP server or host that I only want to deploy in a > private > network (or public network) and that will only support private (or public) > ATM addressing? Just wondering... Correct. IP gets into everything, doesn't it?.. > Just to be pedantic: > I think the *use* of the structure 3 ATM *addressing* is very well > understood, > (i.e. how to shift them around between the address and subaddress etc) - > what is not well understood are the *routing* issues within ATM networks, > that > might lead to the use of such addresses. Thanks. I reworded to suit. > What is an 'IP station' ? The only cases in which my *host* might need to > support > structure 3 are (1.) it is a gateway between a public and private ATM > network, or (2.) > it is _directly_ attached to a public network. If I don't want to do either > of these, > what do I care whether it supports structure 3 (or structure 2 for that > matter)? Perhaps > you meant ARP server rather than host?? Yes, the generality of the model catches all the above and does require implementation of all three; and yes, it may be viewed by some as excess baggage. > > o All members of an LIS MAY use the same ATM address structure. > > In this context, would it not be better to say 'SHOULD' rather than 'MAY'? > Ditto - MAY --> SHOULD. Also, it would be clearer to say NSAP encoded > E.164 rather than E.164, since this can be confused with native E.164 > addresses > (which I presume is not what you meant). Thanks, and yes, thanks. > This paragraph also needs to be clarified - you may want > to assign nodes with the same type of NSPA address, but you will still need > to 'use' different types of addresses within the LIS Ok, reworded slightly to make clearer. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04791; 28 Sep 93 11:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04787; 28 Sep 93 11:14 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11002; 28 Sep 93 11:14 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA26877; Tue, 28 Sep 93 06:38:31 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Loop: ATM CLP.bit ON Precedence: bulk Received: from crs4gw.crs4.it by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26864; Tue, 28 Sep 93 06:38:29 -0700 Received: from vivaldi.crs4.it by crs4gw.crs4.it with SMTP id AA21222 (5.65c8/IDA-1.4.4 for ); Tue, 28 Sep 1993 14:40:06 +0100 Date: Tue, 28 September 1993 14:40:51 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Roman Tirler To: atm@matmos.hpl.hp.com Subject: ATM Consortium Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Please add me to the mailing list. Roman Tirler Centro di Ricerca Sviluppo Studi Superiori in Sardegna (CRS4) Head of Computers & Networks Via Nazario Sauro 10 I-09123 Cagliari Sardinia / Italy Phone: + 39 70 2796 246 Fax : + 39 70 2796 245 E-mail: tirler@CRS4.IT Thanks, Roman Tirler   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10727; 28 Sep 93 14:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10722; 28 Sep 93 14:49 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18990; 28 Sep 93 14:49 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03609; Tue, 28 Sep 93 10:32:18 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay2.UU.NET by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03596; Tue, 28 Sep 93 10:32:16 -0700 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00272; Tue, 28 Sep 93 13:33:12 -0400 Received: from melpar.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 133133.4753; Tue, 28 Sep 1993 13:31:33 EDT Received: from coolpro.advt.melpar.esys.com (coolpro) by melpar.esys.com with SMTP (5.59/25-eef) id AA08182; Tue, 28 Sep 93 13:28:58 EDT Received: from stpc65. (stpc65) by coolpro.advt.melpar.esys.com with SMTP (5.59/25-eef) id AA17930; Tue, 28 Sep 93 13:28:54 EDT Date: Tue, 28 Sep 1993 13:28:36 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Tofigh To: atm@matmos.hpl.hp.com Subject: Re: ATM Consortium Message-Id: Subject: ATM Consortium Please add me to the mailing list. Tom Tofigh 2310 Fairland Rd SilverSpring, MD, 20904 Phone: + 703 560 5000 Fax : + 301 762 8537 E-mail: ttofigh@melpar.esys.com Thanks, Tom Tofigh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11276; 28 Sep 93 15:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11271; 28 Sep 93 15:29 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20484; 28 Sep 93 15:29 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA06959; Tue, 28 Sep 93 11:34:11 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from datanet.tele.fi by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA06946; Tue, 28 Sep 93 11:34:07 -0700 Message-Id: <9309281834.AA06946@matmos.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <00656-0@datanet.tele.fi>; Tue, 28 Sep 1993 20:35:13 +0200 To: atm@matmos.hpl.hp.com In-Reply-To: <930927182816.6529@matmos.hpl.hp.com> "laubach@matmos.hpl.hp.com" Subject: RE: amended ARP section for consideration Date: Tue, 28 Sep 1993 20:35:13 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen sorry to jump in directly to mark's latest text regarding the addressing issue without even having read any previous messages. my oppinion is that IP terminals should register with their ARP servers their ATM address without any routing information. in case of a terminal attached to an ATM LAN, that address would be the NSAP address of the terminal. in case of a terminal only attached to an E.164 addressed public ATM network, the address would be the E.164 address of the terminal. it is then ATM internet's task to route the call and, if necassary, map the NSAP to a proper E.164 address and place the NSAP in the subaddress field. further, i don't see any reason to place restrictions on addressing within a LIS. one terminal may very well be an E.164 only terminal whereas others can be NSAP terminals. as said previously, the ATM internet network must know how to reach terminal in the same LIS. we should not mix addressing and routing here or try to solve both problems at once. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11385; 28 Sep 93 15:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11380; 28 Sep 93 15:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20747; 28 Sep 93 15:35 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05846; Tue, 28 Sep 93 11:25:55 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05833; Tue, 28 Sep 93 11:25:55 -0700 Subject: framework doc postscript and list etiquette To: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Tue, 28 Sep 93 11:25:54 -0700 Message-Id: <930928112554.6529@matmos.hpl.hp.com> Encoding: 28 TEXT, 2 TEXT SIGNATURE A couple of things: 1) The postscript version of Bob Cole's framework document is available via ftp anonymous from: matmos.hpl.hp.com:pub/ip-atm/framework-00.ps 2) I should have gotten after this earlier, but I expected the number of replies to drop off. They haven't. This is a note to the people on this distribution list who do not as of yet have experience in internet email-based discussion etiquette. In specific, if you are interested in the ATM Consortium work going on at the University of New Hampshire, then please contact Ron Pashby directly at pashby@unh.edu. Do not send your replies back to the ATM list! There are over 1000 people on the distribution list who DO NOT NEED TO SEE YOUR PERSONAL RESPONSE! In general, if you are replying with specific information of importance only to the originator of the request, then reply directly to that originator or to the address they specify in their posting. Responses of this kind, sent back to the main distribution list, generate mail that the majority of the list does not need to see. Please do not respond to this note on the main atm list either. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16402; 28 Sep 93 18:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16398; 28 Sep 93 18:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28297; 28 Sep 93 18:22 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11813; Tue, 28 Sep 93 14:03:17 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from DUNGEON.BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11793; Tue, 28 Sep 93 14:03:09 -0700 Message-Id: <9309282103.AA11793@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Cc: gswallow@bbn.com Subject: Re: amended ARP section for consideration In-Reply-To: Your message of Mon, 27 Sep 93 14:28:40 -0700. <9309272128.AA03051@matmos.hpl.hp.com> Date: Tue, 28 Sep 93 16:53:52 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow A couple of comments: > The ATM Forum defines three structures for the combined use of number > and subaddress [9]: I'm concerned that your quoting of structures from the ATM Forum's UNI *Signalling* (based on Q.93B) may be confused with the ATM Forum's *addressing* structure. The structure in the signalling protocol is merely one of sequential processing and *not* one of hierarchy. That is if I want to a call from a public UNI across the public cloud to a final destination on a private net then I signal the egress public UNI in the ATM Number field because that is the field relavent within *this* (i.e. the public) signalling domain. At the egress the entity on the far side (private side) of the Public UNI will reformat the signalling message using what was carried in the subaddress field to reach the final destination. Now this address in only *sub* in the sense of signalling. It is an NSAP and has its own global significance. As far as *addressing* structure goes it is equal to the ATM number. In fact there may be a way to reach this private ATM network through multiple egresses from the public network each with its own E.164 address. Thus what one needs to return in an ARP message that attemps to deal with this *signalling* structure may vary with the location of the source. > For example, NSAPs may encode IEEE 48-bit MAC addresses or may > encode E.164 addresses. Within the LIS either IEEE MAC or E.164 > ATM addresses may be used but not both. I think this is a very poor example. As I wrote earlier, the Private ATM address formats defines three formats. All three formats are NSAPs. All three formats have a 6 byte ESI field. This field can be used to carry a MAC address. One of these three formats encodes an E.164 address, but *can* carry an ESI field as well and *can* have a MAC address in that field. So the or the the first sentence is not an exclusive or. The second sentence seems to be trying to make it exclusive. Or are you talking about the pure (non NSAP encoded) E.164 address used at the public UNI cannot carry an ESI (nor is there any other place to put a MAC address). At best the example is confused. Or its just wrong. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16547; 28 Sep 93 18:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16543; 28 Sep 93 18:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa29045; 28 Sep 93 18:37 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA11750; Tue, 28 Sep 93 14:02:39 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from interlock.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA11737; Tue, 28 Sep 93 14:02:32 -0700 Received: by interlock.ans.net id AA10706 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Tue, 28 Sep 1993 16:57:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Sep 1993 16:57:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Sep 1993 16:57:17 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309282101.AA26088@foo.ans.net> To: atm@matmos.hpl.hp.com Cc: rolc@nsco.network.com Subject: Re: amended ARP section for consideration In-Reply-To: (Your message of Tue, 28 Sep 93 20:35:13 O.) <9309281834.AA06946@matmos.hpl.hp.com> Date: Tue, 28 Sep 93 17:01:27 -0500 ---> From: Juha Heinanen Juha, Lets see if I understand what you are suggesting. > sorry to jump in directly to mark's latest text regarding the addressing > issue without even having read any previous messages. > > my oppinion is that IP terminals should register with their ARP servers > their ATM address without any routing information. in case of a > terminal attached to an ATM LAN, that address would be the NSAP address > of the terminal. in case of a terminal only attached to an E.164 > addressed public ATM network, the address would be the E.164 address of > the terminal. > > it is then ATM internet's task to route the call and, if necassary, map > the NSAP to a proper E.164 address and place the NSAP in the subaddress > field. Don't we have the cart before the horse here. Routing traditionally provides a next hop. Some of the discussions on the ROLC list have routing aggregating lots of nets and providing indication that it is possible to ARP (or NBMA Next Hop Resolve) the destination directly rather than forwarding to the next hop. No consensus, just discussions here. If the above is true, then ARP must return an ATM address that is fully resolved. There is no further address resolution step. Do you disagree? Is there a step after ARP? I don't understand the statement "it is then ATM internet's task to route the call". What exactly does this and is it available in the time frame of Classical IP over ATM (now!). > further, i don't see any reason to place restrictions on addressing > within a LIS. one terminal may very well be an E.164 only terminal > whereas others can be NSAP terminals. as said previously, the ATM > internet network must know how to reach terminal in the same LIS. we > should not mix addressing and routing here or try to solve both problems > at once. > > -- juha This I don't understand at all. I thought some hosts (terminals or end systems are better terma since hosts excludes ATM capable toasters) might understand only E.164 and some hosts might understand NSAPs and E.164. How do you mix these on an LIS? Or am I missing something? I don't see that we are making progress on subaddresses and the E.164 vs NSAP vs. both issue. I have a suggestion. The way I read the framework document, we are not attempting to address the problems of private ATMs adjoining public ATMs without an intermediate router (see section 6.1.1 and figure 2). So this whole discussion of how to handle subaddresses is a moot point. If we stick to the framework document, this case is simply not covered by Classic ATM over IP. The error in the classical draft is then that the introductory paragraphs do not clearly spell out this intentional limitation. It is elluded to by: This memo describes an initial application of classical IP and ARP in an ATM network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. The reference [1] is RFC 1209, "IP and ARP over the SMDS Service" which spells out the limitation nicely. I think we may wnat to borrow at least the following text from that (and substitute ATM for SMDS): The following is a list of the requirements for a LIS configuration: o All members have the same IP network/subnet number. o All stations within a LIS are accessed directly over SMDS. o All stations outside of the LIS are accessed via a router. Using intermediate routers between LIS is what is so "classic" about "Classic IP over ATM". The idea is to get something interoperable and something that can be integrated into the Internet. Walk then run. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16667; 28 Sep 93 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16663; 28 Sep 93 19:00 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00124; 28 Sep 93 19:00 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14664; Tue, 28 Sep 93 14:28:41 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA14649; Tue, 28 Sep 93 14:28:34 -0700 To: Juha Heinanen Subject: RE: amended ARP section for consideration In-Reply-To: <9309281834.AA06946@matmos.hpl.hp.com> References: <9309281834.AA06946@matmos.hpl.hp.com> Cc: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Tue, 28 Sep 93 14:28:33 -0700 Message-Id: <930928142833.6529@matmos.hpl.hp.com> Encoding: 36 TEXT, 2 TEXT SIGNATURE Juha writes: > my oppinion is that IP terminals should register with their ARP servers > their ATM address without any routing information. in case of a > terminal attached to an ATM LAN, that address would be the NSAP address > of the terminal. in case of a terminal only attached to an E.164 > addressed public ATM network, the address would be the E.164 address of > the terminal. > > it is then ATM internet's task to route the call and, if necassary, map > the NSAP to a proper E.164 address and place the NSAP in the subaddress > field. So the summary of this is to do away with (?) or not use (?) the subaddress field in the arp packet format and to use either E.164 or NSAP format endpoint addresses as required by the ATM network to which the terminal is connected. I think I prefer to be more restrictive on registration, i.e. as you've said above, and to be permissive on reception of subaddresses at the client/server; i.e. leave the subaddress field in the arp packet, reserved for future use. The cost then is 2 octets of overhead per arp and some additional code in each implementation. Comments? > further, i don't see any reason to place restrictions on addressing > within a LIS. one terminal may very well be an E.164 only terminal > whereas others can be NSAP terminals. as said previously, the ATM > internet network must know how to reach terminal in the same LIS. we > should not mix addressing and routing here or try to solve both problems > at once. As the statement says, it is more a matter of suggested convenience if possible, and is not meant to be a restriction. I debated with myself putting in those last couple of "suggestion" paragraphs at all and can easily prune it with no real loss to the content of the memo. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16930; 28 Sep 93 19:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16926; 28 Sep 93 19:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01768; 28 Sep 93 19:38 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA15994; Tue, 28 Sep 93 14:47:04 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA15962; Tue, 28 Sep 93 14:47:01 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA20333; Tue, 28 Sep 93 14:47:52 -0700 Received: from relay.fore.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA21270; Tue, 28 Sep 93 14:47:45 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA04435; Tue, 28 Sep 93 17:46:06 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA28306; Tue, 28 Sep 93 17:45:55 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA29441; Tue, 28 Sep 93 17:45:53 EDT Date: Tue, 28 Sep 93 17:45:53 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309282145.AA29441@marlin.fore.com> To: atm@hplms2.hpl.hp.com Subject: classic-ip-03.txt comments Sorry for the long delay in getting my comments out. Overall, the document is looking great. It's come a long way in the last couple of months. I've divided my comments into two sections. The first section, this message, contains comments which should generate discussion. The second section, the next message, contains minor wordsmithing. These comments ended up longer than I expected. Hopefully I've edited them into a coherent whole... from releasing this as an RFC at least until the November meeting. Section 1. Major comments Characteristics of the classical model are: o The same maximum tranmission unit (MTU) size is used for all VCs on an ATM interface, consistent with current network interface implementations. This is really all VCs in an LIS, not on an ATM interface. First because if every station had a VC to every other, then it is necessary in order for your rule to apply, and second because routers should be able to have different MTUs on different LISs. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the virtual Connection topology underlying the intercommunication among the members is fully meshed. There should be no administrative restrictions at the ATM level that prevent VCs from operating between all pairs of end points. I disagree, administrative restrictions on VC establishment by filtering on ATM addresses MUST be allowed. Not allowing such restrictions would be highly undesirable and unenforceable... I will certainly agree that there should be no technical reasons, aside from administrative policy reasons, which prevent this. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect multiple LISs. Routers that wish to provide interconnection of differing LISs MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. You are saying here that if a router connects two LISs with the same ATM interface, that it must have two ATM addresses on that interface; one for each LIS/IP address. Further, I suspect that you have in mind different IEEE MAC addresses. I do not believe that this is at all desirable. I have mixed feelings about whether or not it is necessary. People don't want to have to type in extra IEEE MAC addresses. Where do they even get them, local administration? The only reason I know that it is necessary is because when we receive a datagram on LIS-1 which has to be routed to LIS-2 on the same interface, we have to tag the datagram with an interface different than the one IP will send it to so that IP doesn't send ICMP Redirects. Using different ATM addresses when connections are established is the only way I can think of of achieving this. However, this does not necessarily mean different ESIs (IEEE MAC addresses) when NSAPS are used. The last octet of the NSAP is the "Selector" field. It should be perfectly acceptable to use this field to differentiate up to 256 different LISs automatically. How we handle straight E.164 addresses is another question. Perhaps using the SEL in the NSAP of a subaddress. 7. Packet Format This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. There is a problem that "future development" has already occurred. This signalling is available now. There is only one valid reason I know of not to allow VC based multiplexing now; it does not allow multiplexing of IP and InARP PDUs over the same VC. 8. MTU Size This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. Same comment. Already developed... All IP members supporting PVCs are required to use the Inverse Address Resolution Protocol (InARP) as defined in [12] on those VCs using LLC/SNAP encapsulation. All IP stations supporting SVCs are also required to use InARP. ARP Server Operational Requirements the ARP server accepts ATM calls/connections from other ATM end points. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. ARP servers should use different ATM addresses (selectors, see above) for different LISs just like routers. Then they would require transmission of only a single InARP_REQUEST because incoming VCs would be demultiplexed by NSAP (selector). Also, capitalize "the ARP server". ... If the InARP IP address duplicates a table entry IP address and the InARP ATM address does not match the table entry ATM address and there is an open VC associated with that table entry, the InARP information is discarded and no modifications to the table are made. If this error ever occurs for some valid reason, it will be hard to debug. It would be nice to have another ARP message (InARP_DUPLICATE) to alert the client of this error. The alternative (which is probably a good idea) is for the client to validate its own entry. It can do this by transmitting an ARP_REQUEST (after the InARP_REPLY) to make sure its entry is correctly installed. If it gets an ARP_REPLY with an incorrect ATM address or an ARP_NAK, it knows something is amiss and it can try reconnecting (ARP_NAK) or warn the user (incorrect ARP_REPLY). ARP Client Operational Requirements 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. There should be a comment here about only responding to InARP_REQUESTS matching the clients own LIS. This matches the comments about the server side transmitting InARP_REQUESTS for all LISs (discussed above) and is in conformance with RFC 1293. Better yet, there should be an InARP_NAK message (why wasn't this done in RFC 1293?). Hmm, I just realized that Inverse ARP is not very robust (I'm probably not the first :-) ). There is quite a hole here. If the InARP_REQUEST sent by the server gets lost (CRC error, congestion, etc.), there is currently absolutely NO way for the server to know that it should retransmit the request other than on timeout basis (15 minutes!). Clients are allowed to simply drop requests. I definitely believe we should extend InARP to have more positive feedback make it more robust. Have the frame relay people had any problems with this? 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh its own client ARP table entries. This point is potentially confusing. When does a client need to generate InARP_REQUESTs? I believe the current draft would have a client do this only for PVCs. If so, it should be mentioned here more explicitly. However, I believe there is a missing discussion. When client A connects to client B, how does client B know the IP address associated with the incoming VC from client A? I believe that a ARP client should send an InARP_REQUEST on all incoming VCs, just like an ARP server does, and all ARP clients must be required to respond to InARP_REQUESTS on SVCs to other clients. This generalizes the handling of PVCs a bit. Another question which hasn't been addressed is multi-homed hosts. I believe these should be handled the same way as routers which are part of multiple LISs, i.e. they should have different ATM addresses (selectors). There is another potential problem which I think we should nip in the bud in this document. Two hosts may just happen to establish simultaneous connections to each other. There is nothing currently which will prevent both from succeeding. Implementors may realize this and try to be smart by tearing one of them down. Unless we have a well specified method of choosing which VC to release, a serious thrashing problem can result. I don't believe there is a simple algorithm that each end can run independently by only examining the two connections. You can't choose either VCI Number or Call Reference Number because both are local quantities. The VC with the lowest number on one side may have the highest on the other side. Thus each side may pick the opposite VC of the other side, and both VCs will be released. The next time packets fly, both could be reestablished, etc. A potential solution is to allow only the entity with the higher (or lower) IP address to make the decision about which to drop. The other side should just leave both VCs established. Of course, this only works if both sides absolutely agree on the VC to IP address mapping. Multi-homed hosts could potentially screw this up depending on how we handle them. ARP/InARP Packet Encapsulation ARP and InARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDUs is: This section is an unnecessary duplication of RFC 1483. Lets just refer to it. It is also inconsistent. You are referring to the format of routed non-ISO PDUs, but your picture shows ARP/InARP packets. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. What does the WAN configuration refer to? I guess you mean the WAN configuration of the MBONE, i.e. IP tunneling. Please rephrase: IP multicast may still be achieved using IP tunneling over the unicast communication supported by this specification. 13. Open Issues o Well known ATM address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC port numbers for a non-SVC environment also. The last sentence makes little sense to me. First, it should be "well-known VCI numbers" rather than "PVC port numbers". In either case, I don't really know what I would do with well-known VCIs. Are these connecting me to ARP servers? Why, if the ARP server is going to return ATM addresses which I can't use because I don't have signalling? Or are these connecting me to clients? How many well-known VCIs would I have then? This info I should be able to get from the ILMI (yes there are problems here now). o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. Huh? ILMI is the only way currently for the network and user to exchange the ATM address network prefix and ESI, other than hand configuration. I expect every vendor to do it (if they want to sell their product). How about dropping this issue... Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16959; 28 Sep 93 19:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16955; 28 Sep 93 19:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01977; 28 Sep 93 19:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16512; Tue, 28 Sep 93 14:48:19 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA16499; Tue, 28 Sep 93 14:48:17 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA20342; Tue, 28 Sep 93 14:49:13 -0700 Received: from relay.fore.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA21283; Tue, 28 Sep 93 14:49:17 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA04441; Tue, 28 Sep 93 17:47:27 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA28382; Tue, 28 Sep 93 17:47:14 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA29490; Tue, 28 Sep 93 17:47:12 EDT Date: Tue, 28 Sep 93 17:47:12 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309282147.AA29490@marlin.fore.com> To: atm@hplms2.hpl.hp.com Subject: classic-ip-03.txt wordsmithing Section 2. Minor comments (wordsmithing) 1. Abstract ... specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. We really mean globally connected at the ATM layer, not for example at the IP layer. How about: specifically, as individual ATM LANs grow and become interconnected, a single global homogeneous ATM network is expected to emerge. In this environment, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers and configured as a single IP subnet. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. This goal is too close to RFC 1483. The goal of this spec is to figure out which VCs should be used for transmitting datagrams, not to specify how to transmit them. How about: The goal of this specification is to allow compatible and interoperable implementations for resolving ATM addresses and managing virtual connections over which IP datagrams may be transmitted. Once a virtual connection is selected or established, IP datagrams are transmitted over ATM Adaptation Layer 5 (AAL5) in conformance with [6]. Note: this memo defines only the operation of IP and ARP over ATM, and is not meant to describe the operation of ATM networks. Any reference to virtual connections, permanent virtual connections, or switched virtual connections applies only to virtual connections used to support IP and ARP over ATM, and thus are assumed to be using AAL5. This memo places no restrictions or requirements on virtual connections used for other purposes. The first three "connections" are fine. The fourth is trying to be more explicit and should be "applies only to virtual channel connections". The characteristics and features of ATM networks are different than those found in LANs: o ATM provides a Virtual Connection (VC) switched environment. VC setup may be done on either a Permanent Virtual Connection (PVC) or dynamic Switched Virtual Connection (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. I find this somewhat awkward. How about: SVC call management signalling is performed via implementations of the Q.93B protocol [7,9]. o An ATM Forum ATM endpoint address is either encoded as an NSAP, or is an E.164 Public-UNI address [9]. In some cases, both an ATM endpoint address and an E.164 Public UNI address are needed by an ARP client to reach another host or router. Since the use of ATM endpoint addresses and E.164 public UNI addresses by ARP are analogous to the use of Ethernet addresses, the notion of "hardware address" is extended to encompass ATM addresses in the context of ARP, even though ATM addresses need not have hardware significance. ATM Forum NSAPs use the same basic format as U.S. GOSIP NSAPs [11]. Note: ATM Forum addresses should not be construed as being U.S. GOSIP NSAPs, they are not, the administration is different, which fields get filled out are different, etc. The last sentence is a run-on sentence. How about: Note: ATM Forum addresses should not be construed as being U.S. GOSIP NSAPs, they are not. The administration of these addresses is different, which fields get filled out are different, etc. BTW: does anyone understand who will allocate these numbers? I haven't really heard this discussed... o IP addresses are resolved to ATM addresses by use of an ARP service within the LIS - ARPs stay within the LIS. From a client's perspective, ARP architecture stays essentially the same, consistent with current model. How about: o IP addresses are resolved to ATM addresses by use of an ARP service within the LIS - ARP PDUs stay within the LIS. From a client's perspective, the ARP architecture stays essentially the same, consistent with current model. o One IP subnet is used for many hosts and routers. Each VC directly connects two IP addresses within the same LIS. VCs don't connection IP addresses, they connect IP stations. How about: o One IP subnet is used for many hosts and routers. Each VC directly connects two IP stations within the same LIS. The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VCs (e.g., TCP and UDP ports map directly onto VCs) and address resolution mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Run-on sentence. How about: Future memos will describe the deployment of ATM on a global scale. The "global" ATM model will be an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly onto VCs (e.g., TCP and UDP ports map directly onto VCs). Address resolution PDUs are no longer bound to LIS boundaries; queries and replies may traverse the globe. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling. o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented. o Applications may map directly to VCs, requiring changes to TCP/UDP/IP to allow ports to map directly on to VCs o ARPs may be global, ARP architecture needs to change to support a robust global client/server model. How about (note punctuation): o IP encapsulation is negotiated per VC via ATM signalling; this requires common signalling to be implemented. o Applications may map directly to VCs, requiring changes to TCP/UDP/IP implementations to allow ports to map directly onto VCs o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. How about: o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to provide "back-doors" around these mechanisms until ATM provides better management capability than the existing services and practices. 6. IP Subnetwork Configuration ... Each LIS operates and communicates independently of other LISs over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM Endpoint attached to the ATM network that is configured as a member of two or more LISs. Routers may be attached to other network media in addition to the LIS. How about: Each LIS operates and communicates independently of other LISs on the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM Endpoint attached to the ATM network that is configured as a member of one or more LISs. o All members have the same IP network/subnet number and network mask. RFC 950 defines "address mask", not "network mask". How about: o All members have the same IP network/subnet number and address mask. o All members within an LIS are directly connected to the ATM network. This point is redundant with point six and should be removed. o All members of an LIS MUST have a mechanism for resolving IP addresses to ATM addresses via ARP [3] and vice versa via InARP[12] when using SVCs. This seems redundant with point five and is otherwise awkward. How about: o All members of an LIS MUST be able to resolve IP addresses to ATM addresses via ARP [3] when using SVCs. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the virtual Connection topology underlying the intercommunication among the members is fully meshed. How about: o All members within a LIS MUST be able to communicate via ATM with all other members in the same LIS; i.e., the virtual Connection topology underlying the intercommunication among the members is fully meshed. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network: o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target ATM addresses for SVC connections. Run-on sentence. How about: o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM address of an individual ARP server located within the LIS. In an SVC environment, ARP requests are sent to this address for the resolution of target protocol addresses to target ATM addresses. 9. ADDRESS RESOLUTION Address resolution within an ATM logical IP subnet SHALL make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12] and all IP members are required to support these protocols as updated and extended in this memo. Use of these protocols differ depending on whether PVCs or SVCs are used. Run-on sentence. How about: Address resolution within an ATM logical IP subnet SHALL make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [12]. All IP stations are required to support these protocols as updated and extended in this memo. Use of these protocols differ depending on whether PVCs or SVCs are used. Permanent Virtual Connections An IP station MUST have a mechanism for determining what PVCs it has, and in particular which PVCs are being used with LLC/SNAP encapsulation. The details of the mechanism are beyond the scope of this memo. An example would help. How about: An IP station MUST have a mechanism (eg. manual configuration) for determining what PVCs it has, and in particular which PVCs are being used with LLC/SNAP encapsulation. The details of the mechanism are beyond the scope of this memo. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point VC. The server, upon the completion of an ATM call/connection of a new VC specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. A bit confusing. Is the server passive or does it initiate requests? How about: The server itself does not actively establish connections. It depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point VC. The server, upon the completion of an ATM call/connection of a new VC specifying LLC/SNAP encapsulation, will transmit an InARP request to determine the IP address of the client. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table otherwise a negative ARP reply (ARP_NAK). Run-on sentence. How about: The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table. Otherwise it will generate a negative ARP reply (ARP_NAK). Updating the ARP table information timeout, the short form: when the server receives an ARP request over a VC, and the source IP and ATM address match the association already in the ARP table, and the ATM address matches that associated with the VC, then the server may update the timeout on the ARP table entry: i.e., if the client is sending ARP requests to the server over the same VC that was used to "install" the ARP entry for the client, the server should examine the ARP requests and note that the client is still "alive" and update the timeout on the client's ARP table entry. Incomplete section/run-on sentences. How about: When the server receives an ARP request over a VC, where the source IP and ATM address match the association already in the ARP table and the ATM address matches that associated with the VC, the server may update the timeout on the source ARP table entry. I.e., if the client is sending ARP requests to the server over the same VC that it used to register its ARP entry, the server should examine the ARP requests and note that the client is still "alive" by updating the timeout on the client's ARP table entry. The ARP client is responsible forc ontacting the ARP server to register its own ARP information and to gain and refresh its own ARP entry/information about other IP members. This means, as noted Transposed characters: "forc ontacting". 5. Provide an ARP table aging function to remove is own old client ARP tables entries after a convenient period of time. "is" -> "its". ARP and InARP Packet Format Internet addresses are assigned independent of ATM addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. IP members MUST also use ARP and InARP to resolve IP addresses to ATM addresses when needed and vice versa. Wordsmithing. How about: Internet addresses are assigned independently of ATM addresses. Each host implementation MUST know its own IP and ATM address(es) and MUST respond to address resolution requests appropriately. IP members MUST also use ARP and InARP to resolve IP addresses to ATM addresses when needed. bit.6-1 (length) = 6 bit unsigned octet length of address (MSB = bit.6, LSB = bit.1) NSAPs MUST be 20 octets. Straight E.164 MUST be 8 octets. How about stating this. ... For example, NSAPs may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 ATM addresses may be used but not both. This is not accurate. NSAPs encode a lot more than IEEE 48-bit MAC addresses (DCC/ICD, AA, RD, AREA, SEL). When they encode E.164 addresses, they ALSO encode IEEE 48-bit MAC addresses (and RD, AREA, SEL). Furthermore, there is no need for this restriction. Once the address is in NSAP format, there is no need to look inside it. UNI/PNI signalling will do the right thing with it. Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17325; 28 Sep 93 20:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17321; 28 Sep 93 20:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03569; 28 Sep 93 20:20 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA20568; Tue, 28 Sep 93 15:56:41 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA20555; Tue, 28 Sep 93 15:56:40 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA20754; Tue, 28 Sep 93 15:57:38 -0700 Received: from paris.ics.uci.edu by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA21873; Tue, 28 Sep 93 15:58:05 -0700 Received: from valentine.ics.uci.edu by Paris.ics.uci.edu id aa09296; 28 Sep 93 15:56 PDT To: atm@hplms2.hpl.hp.com Subject: Remove me Date: Tue, 28 Sep 1993 15:56:40 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Atsushi Kimoto Message-Id: <9309281556.aa09296@Paris.ics.uci.edu> I don't know why I've subscribed here. Please remove me from this alias. Thanks, Atsushsi Kimoto akimoto@ics.uci.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01335; 29 Sep 93 6:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01331; 29 Sep 93 6:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05366; 29 Sep 93 6:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03103; Wed, 29 Sep 93 00:19:11 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from datanet.tele.fi by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03090; Wed, 29 Sep 93 00:19:09 -0700 Message-Id: <9309290719.AA03090@matmos.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <02293-0@datanet.tele.fi>; Wed, 29 Sep 1993 09:20:20 +0200 To: atm@matmos.hpl.hp.com Cc: atm@matmos.hpl.hp.com In-Reply-To: <930928142833.6529@matmos.hpl.hp.com> "laubach@matmos.hpl.hp.com" Subject: RE: amended ARP section for consideration Date: Wed, 29 Sep 1993 09:20:20 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen So the summary of this is to do away with (?) or not use (?) the subaddress field in the arp packet format and to use either E.164 or NSAP format endpoint addresses as required by the ATM network to which the terminal is connected. yes, this definitely is my suggestion. it is the ATM internet's task to play (if needed) with the subaddresses. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01346; 29 Sep 93 6:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01342; 29 Sep 93 6:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05373; 29 Sep 93 6:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA04939; Wed, 29 Sep 93 00:38:23 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from vm.cnuce.cnr.it by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA04926; Wed, 29 Sep 93 00:38:17 -0700 Message-Id: <9309290738.AA04926@matmos.hpl.hp.com> Received: from ITCASPUR.CASPUR.IT by vm.cnuce.cnr.it (IBM VM SMTP V2R2) with BSMTP id 2162; Wed, 29 Sep 93 08:38:12 MET Received: by ITCASPUR (Mailer R2.08 R208004) id 1060; Wed, 29 Sep 93 08:40:19 SET Date: Wed, 29 Sep 93 08:38:58 SET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "R. Winkler" Subject: Re: Remove me To: atm@matmos.hpl.hp.com In-Reply-To: Message of Tue, 28 Sep 1993 15:56:40 -0700 from Please, remove me from this list. Thank you. Regards Roberto Winkler   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01380; 29 Sep 93 6:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01376; 29 Sep 93 6:42 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05517; 29 Sep 93 6:42 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02839; Wed, 29 Sep 93 00:17:37 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from datanet.tele.fi by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA02826; Wed, 29 Sep 93 00:17:34 -0700 Message-Id: <9309290717.AA02826@matmos.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <02281-0@datanet.tele.fi>; Wed, 29 Sep 1993 09:18:39 +0200 To: curtis@ans.net Cc: atm@matmos.hpl.hp.com, rolc@nsco.network.com In-Reply-To: <199309282101.AA26088@foo.ans.net> "curtis@ans.net" Subject: amended ARP section for consideration Date: Wed, 29 Sep 1993 09:18:39 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen Don't we have the cart before the horse here. Routing traditionally provides a next hop. Some of the discussions on the ROLC list have routing aggregating lots of nets and providing indication that it is possible to ARP (or NBMA Next Hop Resolve) the destination directly rather than forwarding to the next hop. No consensus, just discussions here. address resolution in the classical model does a very simple thing, namely provides the ATM address that an IP terminal has registered with an ARP server known to the requestor. if the ATM network itself has more levels of hierarchy, then it is the ATM network's task to do further address resolution and to find a route to the destination. in rolc we try to solve another problem that is finding the best next hop within an NBMA corresponding to a given IP address and we should not mix that to the current discussion. If the above is true, then ARP must return an ATM address that is fully resolved. There is no further address resolution step. Do you disagree? Is there a step after ARP? yes, ARP return an address that is fully resolved from IP's point of view. if that is not the case of the ATM network's point of view, then it is its task to do further ATM level addresses resolution. this is, of course, needed only in case someone is so cracy that he/she subscribes to an ATM WAN that doesn't support NSAP addressing. I don't understand the statement "it is then ATM internet's task to route the call". What exactly does this and is it available in the time frame of Classical IP over ATM (now!). what i mean with the above is that if you really have subscribed to an E.164 only ATM WAN then it is the task of your ATM switch that connects your ATM LAN to the ATM WAN to resolve the NSAP address of the destination terminal to an E.164 egress point of the ATM WAN, place that address in the called party number IE, and place the original NSAP in the subaddress IE. of course you don't want to have anything to do with this mess in which case you are wiser and subscribe to a more friendly ATM WAN. This I don't understand at all. I thought some hosts (terminals or end systems are better terma since hosts excludes ATM capable toasters) might understand only E.164 and some hosts might understand NSAPs and E.164. How do you mix these on an LIS? Or am I missing something? hosts don't need to understand anything about destination ATM addresses. for them a destination ATM address is just a string of bytes and they don't have to care a bit what kind of address it is. they simply put this address (got from the ARP server) to the called party information element and fire the call. the ATM network takes care of the rest. The way I read the framework document, we are not attempting to address the problems of private ATMs adjoining public ATMs without an intermediate router (see section 6.1.1 and figure 2). So this whole discussion of how to handle subaddresses is a moot point. If we stick to the framework document, this case is simply not covered by Classic ATM over IP. this is one possible solution. we could simply forget the E.164 public nets at this point and assume that everything is NSAP addressed. but as i have said above, it is not our problem to handle the hassle with NSAP to E.164 mapping. so it really doesn't give us much headache to allow either E.164 or an NSAP address, but we definitely should not mess arround with the subaddress business. that is an internal matter of the ATM internet. The following is a list of the requirements for a LIS configuration: o All members have the same IP network/subnet number. o All stations within a LIS are accessed directly over SMDS. o All stations outside of the LIS are accessed via a router. the above suits well for the classical case. the last requirement is then later lifted by rolc. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08354; 29 Sep 93 13:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08350; 29 Sep 93 13:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19751; 29 Sep 93 13:31 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA21210; Wed, 29 Sep 93 08:59:49 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lobster.wellfleet.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA21197; Wed, 29 Sep 93 08:59:46 -0700 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16056; Wed, 29 Sep 93 11:51:58 EDT Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA11741; Wed, 29 Sep 93 11:58:31 EDT Date: Wed, 29 Sep 93 11:58:31 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9309291558.AA11741@pobox.wellfleet> To: atm@matmos.hpl.hp.com Subject: Re: classic-ip-03.txt comments >>There should be a comment here about only responding to InARP_REQUESTS >matching the clients own LIS. This matches the comments about the >server side transmitting InARP_REQUESTS for all LISs (discussed above) >and is in conformance with RFC 1293. Better yet, there should be an >InARP_NAK message (why wasn't this done in RFC 1293?). Just a word of explanation, if I may. InARP was simply an expansion of ARP itself. It fails in the same way ARP does because it is really not a new protocol. It is simply new types of an existing protocol. That's why there was no InARP_NAK message included in 1293. This is not to say that we might not want to add it now, however. >Hmm, I just realized that Inverse ARP is not very robust (I'm probably >not the first :-) ). There is quite a hole here. If the >InARP_REQUEST sent by the server gets lost (CRC error, congestion, >etc.), there is currently absolutely NO way for the server to know >that it should retransmit the request other than on timeout basis (15 >minutes!). Clients are allowed to simply drop requests. I definitely >believe we should extend InARP to have more positive feedback make it >more robust. Have the frame relay people had any problems with this? Again, ARP suffers from the same problems. In the InARP case, it's just a little easier to know who didn't answer. The problem here is, did you not get an answer because the InARP message itself didn't arrive, or was it because the other side does not support InARP. Frame Relay does not require the use of InARP so it is entirely possible that you will never get any information using InARP over Frame Relay. I think that some InARP stations have a timer set and if they get no response within that time, they try again. Some number of failures later, the station will give up. So, I guess the question is, exactly how should we change InARP?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13697; 29 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13693; 29 Sep 93 18:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04751; 29 Sep 93 18:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02911; Wed, 29 Sep 93 13:31:05 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA02827; Wed, 29 Sep 93 13:30:49 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA24813; Wed, 29 Sep 93 10:58:28 -0700 Received: from nsco.network.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA26021; Wed, 29 Sep 93 10:58:55 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA28751; Wed, 29 Sep 93 13:01:57 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA05514; Wed, 29 Sep 93 12:57:03 CDT Date: Wed, 29 Sep 93 12:57:03 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309291757.AA05514@anubis.network.com> To: atm@matmos.hpl.hp.com Subject: RE: amended ARP section for consideration Quoting Anthony Alles, so my comments have a little context: > So I can't build an ARP server or host that I only want to deploy in a > private > network (or public network) and that will only support private (or public) > ATM addressing? Just wondering... You can build anything you want. However, we should not standardize things which will not interoperate with other cases we KNOW are important. Therefore, we call for support of all 3 cases. > What is an 'IP station' ? The only cases in which my *host* might need to > support > structure 3 are (1.) it is a gateway between a public and private ATM > network, or (2.) > it is _directly_ attached to a public network. If I don't want to do either > of these, > what do I care whether it supports structure 3 (or structure 2 for that > matter)? Perhaps you meant ARP server rather than host?? I strongly disagree with this comment. While it is true in the short term that it is practical to use only one form of address, and map at borders, that does not scale or extend into the future. Therefore, as a group defining a packet format which is loikely to be used and deployed both in the short term and the long term (this stuff does not go away), it is very important for us to plan for usage "3", as well as for the uses we see in the short term. We can not solve all of the routing related issues now, but we can provide useful tools. There are lots of ways that the routing and the address resolution, working together, can provide the end station with the relevant information. If the packet format can not represent it, then we have needlessly forced a re-deployment of software on HOSTS! Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13707; 29 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13703; 29 Sep 93 18:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04758; 29 Sep 93 18:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA01701; Wed, 29 Sep 93 13:16:38 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA01534; Wed, 29 Sep 93 13:13:15 -0700 Received: from datanet.tele.fi by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA26728; Wed, 29 Sep 93 13:12:28 -0700 Message-Id: <9309292012.AA26728@hplms26.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <04825-0@datanet.tele.fi>; Wed, 29 Sep 1993 22:10:28 +0200 To: curtis@ans.net Cc: curtis@ans.net, atm@matmos.hpl.hp.com, rolc@nsco.network.com, curtis@ans.net In-Reply-To: <199309291950.AA41936@foo.ans.net> "curtis@ans.net" Subject: amended ARP section for consideration Date: Wed, 29 Sep 1993 22:10:28 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen If the ATM WAN only understands E.164, you give it an NSAP and hope for the best. and Again, just give them the NSAP and hope for the best. If the WAN only supports E.164, I don't think you'll get connected. curtis, you clearly didn't read my message carefully enough. if the ATM network you have subscribed to only supports E.164, then i said that it is YOUR switch at the boarder of such a beast that has to do the mapping of the NSAP to E.164 and place the NSAP in the subaddress field. good luck with such a provider. This simply means that over a E.164 WAN, the "classical" model requires you to put a router on each side. Then on each router the LAN can use NSAPs. Two separate LIS each with one addressing scheme involving either an NSAP or E.164 but not both (yet). no it doesn't. it just requires a cleaver ATM LAN switch that can do NSAP to E.164 mapping. if such switches are not available, you are out of luck and need a router or, preferably, need to find a more civilized ATM provider. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13717; 29 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13713; 29 Sep 93 18:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04765; 29 Sep 93 18:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA09024; Wed, 29 Sep 93 14:29:58 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hpindlm.cup.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08982; Wed, 29 Sep 93 14:29:35 -0700 Received: by hpindlm.cup.hp.com (16.6/15.5+IOS 3.20+cup+OMrelay) id AA04349; Wed, 29 Sep 93 14:29:24 -0700 Date: Wed, 29 Sep 93 14:29:24 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Subbu Subramaniam Message-Id: <9309292129.AA04349@hpindlm.cup.hp.com> To: atm@matmos.hpl.hp.com, rolc@nsco.network.com Subject: Re: amended ARP section for consideration Cc: Juha.Heinanen@datanet.tele.fi, curtis@ans.net Someone correct me if I am wrong, but... > >Juha, > > Host A --- ATM LAN SW A --- ATM WAN --- ATM LAN SW B -- Host B > >Host A ARPs for an address for Host B. Host A gets back an NSAP. >Host A attempts to connect to Host B by requesting a connect for that >NSAP (and hopes for the best - smileys were inadvertently omitted in >my last message :-):-). I don't know of any proposed protocol by >which LAN SW A can map that NSAP into an E.164 address. If LAN SW B >is made by someone else, then LAN SW A must be very smart to be able >to perform the mapping. > >In that case, we are both right. You are right in the your switch had >better be very smart and your ATM WAN provider is not helping matters. >But I think I'm right as well in that this is outside the scope of the >classical IP over ATM model. Do you still disagree that it is outside >the scope or do you think the classical IP over ATM draft addresses >this case sufficiently? > >Others have suggested that Host B provide both the E.164 and the NSAP >to avoid having to do the mapping. So if it is not outside the scope, >you have to argue with them next. The case for which some are suggesting that we need NSAP as well as E.164 addresses is in the following scenario: Host A ----- ATM WAN ------- ATM LAN SW-X -- Host B. where the ATM WAN provides only (native) E.164 addresses. How will Host A establish a connection to Host B without knowing both NSAP as well as E.164 of the ingress switch to reach B? As an aside, I think this situation was not quite in the scope of the Classical IP over ATM that Mark was referring to at Columbus. (I was not present at Amsterdam) > >I think that if something is outside the scope of a document, the >document shouldn't try to explain how to do that something. If we >restrict ourselves to the classical model as stated in the framework >draft, we don't have to decide if the ARP should return an NSAP only >and require a mapping or do the mapping and include an E.164 and NSAP >subaddress. Mark, did you try to restrict the scope of the document by mentioning that all the hosts in the LIS shall use only one type of address (which is perhaps what triggered this discussion)? If so, then we can still stick to that. -Subbu subbu@cup.hp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13729; 29 Sep 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13725; 29 Sep 93 18:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04774; 29 Sep 93 18:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03420; Wed, 29 Sep 93 13:33:36 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA03386; Wed, 29 Sep 93 13:33:35 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA24754; Wed, 29 Sep 93 10:50:59 -0700 Received: from nsco.network.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA25971; Wed, 29 Sep 93 10:51:27 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA28582; Wed, 29 Sep 93 12:54:17 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA05378; Wed, 29 Sep 93 12:49:23 CDT Date: Wed, 29 Sep 93 12:49:23 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9309291749.AA05378@anubis.network.com> To: atm@matmos.hpl.hp.com Subject: Re: amended ARP section for consideration Your refined text looks good. Thanks for creating it. Joel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13741; 29 Sep 93 18:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13737; 29 Sep 93 18:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04788; 29 Sep 93 18:54 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02283; Wed, 29 Sep 93 13:28:33 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA02229; Wed, 29 Sep 93 13:28:27 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA25314; Wed, 29 Sep 93 12:54:37 -0700 Received: from interlock.ans.net by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA26617; Wed, 29 Sep 93 12:55:04 -0700 Received: by interlock.ans.net id AA23721 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Wed, 29 Sep 1993 15:46:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Sep 1993 15:46:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Sep 1993 15:46:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309291950.AA41936@foo.ans.net> To: Juha Heinanen Cc: curtis@ans.net, atm@matmos.hpl.hp.com, rolc@nsco.network.com, curtis@ans.net Subject: Re: amended ARP section for consideration In-Reply-To: (Your message of Wed, 29 Sep 93 09:18:39 O.) <199309290712.AA12782@interlock.ans.net> Date: Wed, 29 Sep 93 15:50:38 -0500 Juha, Thanks for the clarification. > If the above is true, then ARP must return an ATM address that is > fully resolved. There is no further address resolution step. > Do you disagree? Is there a step after ARP? > > yes, ARP return an address that is fully resolved from IP's point of > view. if that is not the case of the ATM network's point of view, then > it is its task to do further ATM level addresses resolution. this is, > of course, needed only in case someone is so cracy that he/she > subscribes to an ATM WAN that doesn't support NSAP addressing. Let's imagine such a WAN does exist. Some people likely to provide the only ATM WAN around in some areas are in love with E.164. > I don't understand the statement "it is then ATM internet's task to > route the call". What exactly does this and is it available in the > time frame of Classical IP over ATM (now!). > > what i mean with the above is that if you really have subscribed to an > E.164 only ATM WAN then it is the task of your ATM switch that connects > your ATM LAN to the ATM WAN to resolve the NSAP address of the > destination terminal to an E.164 egress point of the ATM WAN, place that > address in the called party number IE, and place the original NSAP in > the subaddress IE. of course you don't want to have anything to do with > this mess in which case you are wiser and subscribe to a more friendly > ATM WAN. If the ATM WAN only understands E.164, you give it an NSAP and hope for the best. > This I don't understand at all. I thought some hosts (terminals or > end systems are better terma since hosts excludes ATM capable > toasters) might understand only E.164 and some hosts might understand > NSAPs and E.164. How do you mix these on an LIS? Or am I missing > something? > > hosts don't need to understand anything about destination ATM addresses. > for them a destination ATM address is just a string of bytes and they > don't have to care a bit what kind of address it is. they simply put > this address (got from the ARP server) to the called party information > element and fire the call. the ATM network takes care of the rest. Again, just give them the NSAP and hope for the best. If the WAN only supports E.164, I don't think you'll get connected. > The way I read the framework document, we are not attempting to > address the problems of private ATMs adjoining public ATMs without an > intermediate router (see section 6.1.1 and figure 2). So this whole > discussion of how to handle subaddresses is a moot point. If we stick > to the framework document, this case is simply not covered by Classic > ATM over IP. > > this is one possible solution. we could simply forget the E.164 public > nets at this point and assume that everything is NSAP addressed. but as > i have said above, it is not our problem to handle the hassle with NSAP > to E.164 mapping. so it really doesn't give us much headache to allow > either E.164 or an NSAP address, but we definitely should not mess > arround with the subaddress business. that is an internal matter of the > ATM internet. This simply means that over a E.164 WAN, the "classical" model requires you to put a router on each side. Then on each router the LAN can use NSAPs. Two separate LIS each with one addressing scheme involving either an NSAP or E.164 but not both (yet). > The following is a list of the requirements for a LIS configuration: > o All members have the same IP network/subnet number. > o All stations within a LIS are accessed directly over SMDS. > o All stations outside of the LIS are accessed via a router. > > the above suits well for the classical case. the last requirement is > then later lifted by rolc. It sounds like we in agreement, that classical should stick with these limitations. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13772; 29 Sep 93 18:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13768; 29 Sep 93 18:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04883; 29 Sep 93 18:58 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05206; Wed, 29 Sep 93 13:41:32 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA05120; Wed, 29 Sep 93 13:41:16 -0700 Message-Id: <9309292041.AA05120@matmos.hpl.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jen@lydian.att.com Date: Wed, 29 Sep 93 16:40 EDT To: atm@matmos.hpl.hp.com Subject: Re: Remove me Please remove me from this alias as well. thanks, Jen Ouyang attmail!granjon!jen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13985; 29 Sep 93 19:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13981; 29 Sep 93 19:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05367; 29 Sep 93 19:24 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA03645; Wed, 29 Sep 93 13:35:06 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from interlock.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA03565; Wed, 29 Sep 93 13:34:48 -0700 Received: by interlock.ans.net id AA19216 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Wed, 29 Sep 1993 16:27:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Sep 1993 16:27:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Sep 1993 16:27:23 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309292031.AA91953@foo.ans.net> To: Juha Heinanen Cc: curtis@ans.net, atm@matmos.hpl.hp.com, rolc@nsco.network.com, curtis@ans.net Subject: Re: amended ARP section for consideration In-Reply-To: (Your message of Wed, 29 Sep 93 22:10:28 O.) <199309292004.AA23584@interlock.ans.net> Date: Wed, 29 Sep 93 16:31:30 -0500 > If the ATM WAN only understands E.164, you give it an NSAP and hope > for the best. > > and > > Again, just give them the NSAP and hope for the best. If the WAN only > supports E.164, I don't think you'll get connected. > > curtis, > > you clearly didn't read my message carefully enough. if the ATM network > you have subscribed to only supports E.164, then i said that it is YOUR > switch at the boarder of such a beast that has to do the mapping of the > NSAP to E.164 and place the NSAP in the subaddress field. good luck > with such a provider. > > This simply means that over a E.164 WAN, the "classical" model > requires you to put a router on each side. Then on each router the > LAN can use NSAPs. Two separate LIS each with one addressing scheme > involving either an NSAP or E.164 but not both (yet). > > no it doesn't. it just requires a cleaver ATM LAN switch that can do > NSAP to E.164 mapping. if such switches are not available, you are out > of luck and need a router or, preferably, need to find a more civilized > ATM provider. > > -- juha Juha, Host A --- ATM LAN SW A --- ATM WAN --- ATM LAN SW B -- Host B Host A ARPs for an address for Host B. Host A gets back an NSAP. Host A attempts to connect to Host B by requesting a connect for that NSAP (and hopes for the best - smileys were inadvertently omitted in my last message :-):-). I don't know of any proposed protocol by which LAN SW A can map that NSAP into an E.164 address. If LAN SW B is made by someone else, then LAN SW A must be very smart to be able to perform the mapping. In that case, we are both right. You are right in the your switch had better be very smart and your ATM WAN provider is not helping matters. But I think I'm right as well in that this is outside the scope of the classical IP over ATM model. Do you still disagree that it is outside the scope or do you think the classical IP over ATM draft addresses this case sufficiently? Others have suggested that Host B provide both the E.164 and the NSAP to avoid having to do the mapping. So if it is not outside the scope, you have to argue with them next. I think that if something is outside the scope of a document, the document shouldn't try to explain how to do that something. If we restrict ourselves to the classical model as stated in the framework draft, we don't have to decide if the ARP should return an NSAP only and require a mapping or do the mapping and include an E.164 and NSAP subaddress. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13998; 29 Sep 93 19:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13994; 29 Sep 93 19:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05414; 29 Sep 93 19:26 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16086; Wed, 29 Sep 93 15:19:28 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16070; Wed, 29 Sep 93 15:19:25 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA07526; Wed, 29 Sep 93 15:19:10 PDT Received: by msgate.hls.com with Microsoft Mail id <2CAA0BE5@msgate.hls.com>; Wed, 29 Sep 93 15:27:49 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , Mark Laubach , SUN - Bob Cole Subject: RE: framework doc Date: Wed, 29 Sep 93 15:22:00 PDT Message-Id: <2CAA0BE5@msgate.hls.com> Encoding: 63 TEXT X-Mailer: Microsoft Mail V3.0 Mark, Bob, Just as a point on Appendix A of the framework document, I'd suggest deleting the final bullet point, discussing what I described as 'case (e)', of two public networks interconnected by a private network. As Dan correctly pointed out, this is almost certainly an infeasible - indeed, possibly illegal - configuration. Presumably one can assume that the public network will provide direct universal connectivity to all public network attached nodes, without requiring (or allowing) private network transits. I was also uncertain by what was meant by the second line of the final paragraph: "...several issues arise...one is how to distinguish between E.164 addresses and E.164 encoded NSAP modeled addresses". Why is this a problem? The encoding rules for ATM addressing make this distinction very clear, through the use of the AFI field. The only case in which *nodes* might have got confused between these two cases is if, as Dan pointed out, we had followed my original proposal of always encoding all E.164 addresses - whether or not the nodes were directly attached to a public network - in the NSAP encoding. In this case, such a directly attached node would not be able to tell, from the ARP response, whether or not the destination node was attached to the public network, in which case it would have to map the NSAP E.164 into a native mode format, or whether the node was attached to a private ATM network which happened to use NSAP encoded E.164 addresses (whether or not this is likely is another issue!), in which case the NSAP encoded address would be placed in the suabaddress field of the Q.93b request, and the node would have to perform a routing function to determine the native mode E.164 address of the ingress point leading to that network. Note that a private network node would only ever use the NSAP encoded E.164 address. In this case, it doesn't matter whether the destination node is attached to a public or private node, since the VC routing protocol will have to route the request over a configured path or link regardless (since it does not have any routing hierarchy fields). There is a question whether in such a case the ARP server should respond with the E.164 address already encoded in NSAP format or not - probably not, since it would be hard for it know whether the node making the request was on a private or public network. Did I misunderstand the intent behind your statement? I should also congratulate Bob on converting my original argument into a fairly dispassionate statement. Of course I would have been happier if you had accepted my proposal!! :-) Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14096; 29 Sep 93 19:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14092; 29 Sep 93 19:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05638; 29 Sep 93 19:38 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA17259; Wed, 29 Sep 93 15:26:58 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from interlock.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA17246; Wed, 29 Sep 93 15:26:56 -0700 Received: by interlock.ans.net id AA11592 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Wed, 29 Sep 1993 18:15:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Sep 1993 18:15:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Sep 1993 18:15:39 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309292219.AA71546@foo.ans.net> To: Subbu Subramaniam Cc: atm@matmos.hpl.hp.com, rolc@nsco.network.com, Juha.Heinanen@datanet.tele.fi, curtis@ans.net, curtis@ans.net Subject: Re: amended ARP section for consideration In-Reply-To: (Your message of Wed, 29 Sep 93 14:29:24 MST.) <9309292129.AA04349@hpindlm.cup.hp.com> Date: Wed, 29 Sep 93 18:19:46 -0500 > As an aside, I think this situation was not quite in the scope of the > Classical IP over ATM that Mark was referring to at Columbus. > (I was not present at Amsterdam) I wasn't at either one. I was reading the drafts. Sections 6.1.1 of "IP over ATM: A Framework Document" says: 6.1.1 The Classical IP Model The Classical IP Model was suggested at the Spring 1993 IETF meeting [LAU 93]. This model simply consists of cascading subnet models discussed above with gateways or routers. The diagram in the postscript version has: ES IS IS ES \--- SVC LATM --/\-- PVC WATM --/\-- SVC LATM ---/ Where IS is intermediate system which translates from OSI into IP as "router" unless I'm mistaken. In the classical draft, in the abstract we have: Characteristics of the classical model are: [ ... ] o End-to-end IP routing architecture stays the same. o IP addresses are resolved to ATM addresses by use of an ARP service within the LIS - ARPs stay within the LIS. ARP architecture stays essentially the same, consistent with current model. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for all these VCs. [ ... ] Later we have: 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LISs over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM Endpoint attached to the ATM network that is configured as a member of two or more LISs. This configuration may result in a number of disjoint LISs operating over the same ATM network. Hosts of differing IP subnets must communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network. The requirements for IP members (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All members within an LIS are accessed directly over the ATM network. o All members outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [3] and vice versa via InARP[12] when using SVCs. o All members of an LIS must have a mechanism for resolving VCs to IP addresses via InARP [12] when using PVCs. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the virtual channel topology underlying the intercommunication among the members is fully meshed. There should be no administrative restrictions at the ATM level that prevent VCs from operating between all pairs of end points. If this doesn't limit the scope to exclude the case we are taking about, then I think the wording needs to be clear enough that it does. I don't think we can realisticly expect to assign the ATM WAN a class A network and assign the ATM LAN subnets of the class A and set the subnet mask to cover the whole class A and then expect the NSAP to E.164 mapping to just somehow happen. I think more thought needs to go into how to do that, therefore it is beyond the scope of what we now have. I've said too much on this already. My appologies for burdenning the list. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14146; 29 Sep 93 19:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14142; 29 Sep 93 19:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05758; 29 Sep 93 19:44 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19031; Wed, 29 Sep 93 15:37:48 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from LANSLIDE.HLS.COM by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18996; Wed, 29 Sep 93 15:37:46 -0700 Received: from msgate.hls.com ([129.47.30.66]) by lanslide.hls.com (4.1/SMI-4.0) id AA07924; Wed, 29 Sep 93 15:32:14 PDT Received: by msgate.hls.com with Microsoft Mail id <2CAA0EF5@msgate.hls.com>; Wed, 29 Sep 93 15:40:53 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alles, Anthony" To: atm , rolc , HP - Subbu Subject: Re: amended ARP section for consideration Date: Wed, 29 Sep 93 15:35:00 PDT Message-Id: <2CAA0EF5@msgate.hls.com> Encoding: 63 TEXT X-Mailer: Microsoft Mail V3.0 Subbu, >> Host A --- ATM LAN SW A --- ATM WAN --- ATM LAN SW B -- Host B >> >>Host A ARPs for an address for Host B. Host A gets back an NSAP. >>Host A attempts to connect to Host B by requesting a connect for that >>NSAP (and hopes for the best - smileys were inadvertently omitted in >>my last message :-):-). I don't know of any proposed protocol by >>which LAN SW A can map that NSAP into an E.164 address. The protocol is (will be) the VC routing protocol being developed by the P-NNI group, and it will run in the ATM LAN switches. Most likely this information will need to be configured, much as WAN information is configured into routers today. In any case, IP ARP certainly cannot and should not solve an ATM level routing problem. >>In that case, we are both right. You are right in the your switch had >>better be very smart and your ATM WAN provider is not helping matters. >>But I think I'm right as well in that this is outside the scope of the >>classical IP over ATM model. Do you still disagree that it is outside >>the scope or do you think the classical IP over ATM draft addresses >>this case sufficiently? Yes, it is outside the scope of the IP over ATM group, as we have discussed at length on this group over the last couple of weeks. >>Others have suggested that Host B provide both the E.164 and the NSAP >>to avoid having to do the mapping. So if it is not outside the scope, >>you have to argue with them next. I hope not!! :-) We have spent more than enough BW on this group arguing about this topic. >The case for which some are suggesting that we need NSAP as well >as E.164 addresses is in the following scenario: > > Host A ----- ATM WAN ------- ATM LAN SW-X -- Host B. > > where the ATM WAN provides only (native) E.164 addresses. > >How will Host A establish a connection to Host B without knowing both >NSAP as well as E.164 of the ingress switch to reach B? Configuration, or support of VC routing. How will the ARP server know the E.164 address of the ingress point into ATM LAN SW-X, if that switch has multiple such public UNI? >As an aside, I think this situation was not quite in the scope of the >Classical IP over ATM that Mark was referring to at Columbus. >(I was not present at Amsterdam) Clearly it is not in the scope, since it is an ATM not IP routing problem. > >-Subbu >subbu@cup.hp.com Anthony.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14177; 29 Sep 93 19:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14173; 29 Sep 93 19:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05806; 29 Sep 93 19:45 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18563; Wed, 29 Sep 93 15:36:32 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18550; Wed, 29 Sep 93 15:36:25 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA06197; Wed, 29 Sep 93 18:36:13 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA03569; Wed, 29 Sep 93 18:35:56 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA05839; Wed, 29 Sep 93 18:35:55 EDT Date: Wed, 29 Sep 93 18:35:55 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309292235.AA05839@marlin.fore.com> To: Juha.Heinanen@datanet.tele.fi, curtis@ans.net Subject: Re: amended ARP section for consideration Cc: atm@matmos.hpl.hp.com, rolc@nsco.network.com > Host A --- ATM LAN SW A --- ATM WAN --- ATM LAN SW B -- Host B > > Host A ARPs for an address for Host B. Host A gets back an NSAP. > Host A attempts to connect to Host B by requesting a connect for that > NSAP (and hopes for the best - smileys were inadvertently omitted in > my last message :-):-). I don't know of any proposed protocol by > which LAN SW A can map that NSAP into an E.164 address. If LAN SW B > is made by someone else, then LAN SW A must be very smart to be able > to perform the mapping. We don't yet know what capabilities the P-NNI will provide. I believe many people propose that P-NNI will do exactly what you described, namely ATM LAN SW A will map Host B's NSAP into the necessary E.164 address and NSAP subaddress. Some people explain this by saying that the ATM WAN is a subnet of the overall ATM network (my rendition of the argument could be refined :-)). Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14194; 29 Sep 93 19:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14190; 29 Sep 93 19:49 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05842; 29 Sep 93 19:49 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA19922; Wed, 29 Sep 93 15:39:31 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA19870; Wed, 29 Sep 93 15:39:28 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA06206; Wed, 29 Sep 93 18:39:35 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA03843; Wed, 29 Sep 93 18:39:20 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA05968; Wed, 29 Sep 93 18:39:19 EDT Date: Wed, 29 Sep 93 18:39:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9309292239.AA05968@marlin.fore.com> To: atm@matmos.hpl.hp.com, rolc@nsco.network.com, subbu@hpindlm.cup.hp.com Subject: Re: amended ARP section for consideration Cc: Juha.Heinanen@datanet.tele.fi, curtis@ans.net > Someone correct me if I am wrong, but... > > > > >Juha, > > > > Host A --- ATM LAN SW A --- ATM WAN --- ATM LAN SW B -- Host B > > > >Host A ARPs for an address for Host B. Host A gets back an NSAP. > >Host A attempts to connect to Host B by requesting a connect for that > >NSAP (and hopes for the best - smileys were inadvertently omitted in > >my last message :-):-). I don't know of any proposed protocol by > >which LAN SW A can map that NSAP into an E.164 address. If LAN SW B > >is made by someone else, then LAN SW A must be very smart to be able > >to perform the mapping. > > > >In that case, we are both right. You are right in the your switch had > >better be very smart and your ATM WAN provider is not helping matters. > >But I think I'm right as well in that this is outside the scope of the > >classical IP over ATM model. Do you still disagree that it is outside > >the scope or do you think the classical IP over ATM draft addresses > >this case sufficiently? > > > >Others have suggested that Host B provide both the E.164 and the NSAP > >to avoid having to do the mapping. So if it is not outside the scope, > >you have to argue with them next. > > The case for which some are suggesting that we need NSAP as well > as E.164 addresses is in the following scenario: > > Host A ----- ATM WAN ------- ATM LAN SW-X -- Host B. > > where the ATM WAN provides only (native) E.164 addresses. > > How will Host A establish a connection to Host B without knowing both > NSAP as well as E.164 of the ingress switch to reach B? > > As an aside, I think this situation was not quite in the scope of the > Classical IP over ATM that Mark was referring to at Columbus. > (I was not present at Amsterdam) > > > > >I think that if something is outside the scope of a document, the > >document shouldn't try to explain how to do that something. If we > >restrict ourselves to the classical model as stated in the framework > >draft, we don't have to decide if the ARP should return an NSAP only > >and require a mapping or do the mapping and include an E.164 and NSAP > >subaddress. > > Mark, did you try to restrict the scope of the document by mentioning > that all the hosts in the LIS shall use only one type of address > (which is perhaps what triggered this discussion)? If so, then we > can still stick to that. One way to model this is that Host A should have a virtual (logical) UNI interface to ATM LAN SW-X. We are already talking about logical NNIs in the P-NNI group. We should probably have logical UNIs as well. The problem would then disappear as far as IP is concerned. Drew   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14760; 29 Sep 93 21:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14756; 29 Sep 93 21:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07574; 29 Sep 93 21:27 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25516; Wed, 29 Sep 93 17:22:11 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25499; Wed, 29 Sep 93 17:22:05 -0700 To: Subbu Subramaniam Cc: atm@matmos.hpl.hp.com, rolc@nsco.network.com, Juha.Heinanen@datanet.tele.fi, curtis@ans.net Subject: Re: amended ARP section for consideration In-Reply-To: <9309292129.AA04349@hpindlm.cup.hp.com> References: <9309292129.AA04349@hpindlm.cup.hp.com> X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Wed, 29 Sep 93 17:22:05 -0700 Message-Id: <930929172205.24415@matmos.hpl.hp.com> Encoding: 14 TEXT, 2 TEXT SIGNATURE Subbu writes: > Mark, did you try to restrict the scope of the document by mentioning > that all the hosts in the LIS shall use only one type of address > (which is perhaps what triggered this discussion)? If so, then we > can still stick to that. Yes, but the original motivation for it came from us wanting to restrict how ATM-addresses are used on the ATM LAN. It is really not the place of an IP&ARP document saying how ATM should do it's local addressing, rather I think it up to us to have a mechanism by which ARP can cope with the various hoops that ATM has caste. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18306; 29 Sep 93 22:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18301; 29 Sep 93 22:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09188; 29 Sep 93 22:59 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02494; Wed, 29 Sep 93 19:12:15 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA02480; Wed, 29 Sep 93 19:12:14 -0700 Date: Wed, 29 Sep 93 19:12:14 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <9309300212.AA02480@matmos.hpl.hp.com> To: atm@matmos.hpl.hp.com Subject: classic version to submit ATMers: We've beaten it up quite a bit. I know I feel beat. I've wordsmithed it (thanks for all submissions!), chopped a little bit out of it, and have put it up for ftp as: matmos.hpl.hp.com:~ftp/pub/ip-atm/classic-ip-03.1.txt I know the discussions about ARP, ATM addressing, VC-routing, P-NNI, and the like will still continue. This is good. Let's direct our energies to the framework document. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01523; 30 Sep 93 7:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01519; 30 Sep 93 7:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07547; 30 Sep 93 7:24 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16589; Thu, 30 Sep 93 01:49:38 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from datanet.tele.fi by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA16576; Thu, 30 Sep 93 01:49:29 -0700 Message-Id: <9309300849.AA16576@matmos.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <07914-0@datanet.tele.fi>; Thu, 30 Sep 1993 10:49:33 +0200 To: curtis@ans.net Cc: curtis@ans.net, atm@matmos.hpl.hp.com, rolc@nsco.network.com, curtis@ans.net In-Reply-To: <199309292031.AA91953@foo.ans.net> "curtis@ans.net" Subject: amended ARP section for consideration Date: Thu, 30 Sep 1993 10:49:33 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen In that case, we are both right. You are right in the your switch had better be very smart and your ATM WAN provider is not helping matters. But I think I'm right as well in that this is outside the scope of the classical IP over ATM model. Do you still disagree that it is outside the scope or do you think the classical IP over ATM draft addresses this case sufficiently? it is enough for the classical document to tell how ATM addresses (without subaddresses) are registered with ARP servers and how the queries/replies are handled. all the rest is an internal matter of the ATM networks. by the way, i just checked from UNI 3.0 spec and the addresses registration precess described in section 5.8 doesn't allow subaddresses either. Others have suggested that Host B provide both the E.164 and the NSAP to avoid having to do the mapping. So if it is not outside the scope, you have to argue with them next. returning both would get us into a very complex situation. for example, if the ATM LAN is connected to several E.164 WANs, how would it know, which E.164 address to use as the primary address? -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01533; 30 Sep 93 7:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01529; 30 Sep 93 7:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07552; 30 Sep 93 7:24 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18083; Thu, 30 Sep 93 02:02:53 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA18070; Thu, 30 Sep 93 02:02:52 -0700 Received: from otter.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA28959; Thu, 30 Sep 93 02:02:54 -0700 Received: from hplb.hpl.hp.com by otter.hpl.hp.com with SMTP (16.6/15.6+ISC) id AA02882; Thu, 30 Sep 93 10:01:19 +0100 Received: from datanet.tele.fi by hplb.hpl.hp.com; Thu, 30 Sep 93 09:51:48 +0100 Message-Id: <9309300851.AA08945@hplb.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <07940-0@datanet.tele.fi>; Thu, 30 Sep 1993 10:55:07 +0200 To: subbu@hpindlm.cup.hp.com Cc: atm@hplb.hpl.hp.com, rolc@nsco.network.com, curtis@ans.net In-Reply-To: <9309292129.AA04349@hpindlm.cup.hp.com> "subbu@hpindlm.cup.hp.com" Subject: amended ARP section for consideration Date: Thu, 30 Sep 1993 10:55:07 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen The case for which some are suggesting that we need NSAP as well as E.164 addresses is in the following scenario: Host A ----- ATM WAN ------- ATM LAN SW-X -- Host B. where the ATM WAN provides only (native) E.164 addresses. lets suppose that ATM LAN SW-X is connected to two E.164 ATM WANs. how would the ARP server of B know which E.164 address to return? if we go this route all the way, then we have to modify ARP to return a variable number of harware addresses. so personally i would just leave the mixed case out as "not supported". -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02822; 30 Sep 93 8:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02818; 30 Sep 93 8:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10270; 30 Sep 93 8:38 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18431; Thu, 30 Sep 93 02:13:51 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from datanet.tele.fi by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18416; Thu, 30 Sep 93 02:13:39 -0700 Message-Id: <9309300913.AA18416@matmos.hpl.hp.com> Received: from datanet.tele.fi by datanet.tele.fi id <07986-0@datanet.tele.fi>; Thu, 30 Sep 1993 11:13:50 +0200 To: atm@matmos.hpl.hp.com Cc: atm@matmos.hpl.hp.com In-Reply-To: <9309291757.AA05514@anubis.network.com> "jmh@anubis.network.com" Subject: RE: amended ARP section for consideration Date: Thu, 30 Sep 1993 11:13:50 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen While it is true in the short term that it is practical to use only one form of address, and map at borders, that does not scale or extend into the future. i have an oppisite view of this. the simpler and cleaner model we adopt, the better is scales in the future. supporting all kinds of messy cases now would more or less guarantee that those will be with us for ever. by making certain selections, gives a clear message on what we think is reasonably implementable. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07736; 30 Sep 93 11:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab07732; 30 Sep 93 11:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16625; 30 Sep 93 11:46 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA00911; Thu, 30 Sep 93 07:14:44 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from enet-gw.pa.dec.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA00898; Thu, 30 Sep 93 07:14:43 -0700 Received: by enet-gw.pa.dec.com; id AA18644; Thu, 30 Sep 93 07:14:42 -0700 Message-Id: <9309301414.AA18644@enet-gw.pa.dec.com> Received: from kranz.enet; by decwrl.enet; Thu, 30 Sep 93 07:14:42 PDT Date: Thu, 30 Sep 93 07:14:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Rosenkranz To: atm@matmos.hpl.hp.com Apparently-To: atm@matmos.hpl.hp.com Subject: Please remove me from mailing list +---------------+ | d i g i t a l | I N T E R O F F I C E M E M O R A N D U M +---------------+ Jim Rosenkranz Consultant, Telecom DCC ALF2-3/H11 5555 Windward Parkway West Alpharetta, Ga. 30201-7407 (404)-772-2218 DTN 385-2218 Please remove me (rosen@kranz.enet.dec.com) for this mailing list. thanks,   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09192; 30 Sep 93 13:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09188; 30 Sep 93 13:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18792; 30 Sep 93 13:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA05231; Thu, 30 Sep 93 09:02:16 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay1.UU.NET by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA05218; Thu, 30 Sep 93 09:02:11 -0700 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25261; Thu, 30 Sep 93 12:02:13 -0400 Received: from melpar.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 120011.25970; Thu, 30 Sep 1993 12:00:11 EDT Received: from coolpro.advt.melpar.esys.com (coolpro) by melpar.esys.com with SMTP (5.59/25-eef) id AA20459; Thu, 30 Sep 93 11:53:29 EDT Received: from stpc65. (stpc65) by coolpro.advt.melpar.esys.com with SMTP (5.59/25-eef) id AA24881; Thu, 30 Sep 93 11:53:25 EDT Date: Thu, 30 Sep 1993 11:53:25 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Tofigh To: uunet!matmos.hpl.hp.com!atm@uunet.uu.net Subject: Re: classic version to submit Message-Id: In-Reply-To: <9309300212.AA02480@matmos.hpl.hp.com> Mark; How can I get a copy of the document "classic-ip over ATM". Is there a mail server that I can request this document. Thanks in advance Tom tofigh ttofigh@melpar.esys.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10273; 30 Sep 93 14:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10269; 30 Sep 93 14:02 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19605; 30 Sep 93 14:02 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AB08723; Thu, 30 Sep 93 09:48:18 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ucsd.edu by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA08710; Thu, 30 Sep 93 09:48:16 -0700 Received: by ucsd.edu; id AA00405 sendmail 5.67/UCSD-2.2-sun via CCMail Thu, 30 Sep 93 09:46:42 -0700 for atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Roland_Hansen@som-lrc.ucsd.edu Received: by ucsd.edu from SOM-LRC.UCSD.EDU id with CCTORFC Thu Sep 30 16:46:41 1993 Message-Id: Date: 30 Sep 93 09:35:00 -0800 To: Juha.Heinanen@datanet.tele.fi, atm@matmos.hpl.hp.com MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re[2]: amended ARP section for consideration please remove me from mailing list..   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10321; 30 Sep 93 14:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10315; 30 Sep 93 14:05 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19690; 30 Sep 93 14:05 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA07612; Thu, 30 Sep 93 09:43:17 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from interlock.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA07599; Thu, 30 Sep 93 09:43:15 -0700 Received: by interlock.ans.net id AA19357 (InterLock SMTP Gateway 1.1 for atm@matmos.hpl.hp.com); Thu, 30 Sep 1993 12:37:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 30 Sep 1993 12:37:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 30 Sep 1993 12:37:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <199309301641.AA70842@foo.ans.net> To: atm@matmos.hpl.hp.com Cc: rolc@nsco.network.com, curtis@ans.net Subject: Re: ATM routing (was Re: amended ARP section for consideration) In-Reply-To: (Your message of Thu, 30 Sep 93 10:49:33 O.) <9309300849.AA16576@matmos.hpl.hp.com> Date: Thu, 30 Sep 93 12:41:18 -0500 > Others have suggested that Host B provide both the E.164 and the NSAP > to avoid having to do the mapping. So if it is not outside the scope, > you have to argue with them next. > > returning both would get us into a very complex situation. for example, > if the ATM LAN is connected to several E.164 WANs, how would it know, > which E.164 address to use as the primary address? > > -- juha Juha, I changed the subject, since we are not discussing changes to the classical draft or ammended ARP section, rather discussing routing implications. I've left the copy list intact. I think we should move further discussion on this to rolc only. The example that you give is precisely why I think you need a router. The answer is the routing protocols advertise a route at both borders. Based on a metric or a policy decision routers at the other end of the LIS or "large cloud" decides which next hop to pick. They then ARP for the preferred next hop. If the primary goes down, they get a new next hop and ARP for that. If the primary comes back, they don't have to ARP again unless their ARP entry expired. The route changed but the IP to physical address mapping didn't change. Query response protocols such as ARP or NBMA Next Hop Resolution don't behave this way (quick convergence to the best route) and therefore are not suitable as a means to make the routing decision. This is really an issue for ROLC, but it is important that the ATM WG recognize that a routing protocol and an address resolution protocol are designed to do different things. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02552; 30 Sep 93 15:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02548; 30 Sep 93 15:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22418; 30 Sep 93 15:53 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA13640; Thu, 30 Sep 93 11:47:38 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA13627; Thu, 30 Sep 93 11:47:36 -0700 Received: by xap.xyplex.com id ; Thu, 30 Sep 93 14:43:17 -0500 Date: Thu, 30 Sep 93 14:43:17 -0500 Message-Id: <9309301943.AA15462@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: atm@matmos.hpl.hp.com In-Reply-To: Roland_Hansen@SOM-LRC.UCSD.EDU's message of 30 Sep 93 09:35:00 -0800 Subject: Re[2]: amended ARP section for consideration You do not get off mailing lists by sending messages to people on the list. The mail headers for the ATM Mailing list tell you where to send the request: X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm People who send such requests to the list are generously considered as ignorant, and less generously considered as rude and obnoxious. You probably will believe I'm over reacting, but just today I've seen at least a dozen such messages, at least four of them from this mailing list which posts the instructions in its header lines. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05094; 30 Sep 93 17:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05090; 30 Sep 93 17:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24825; 30 Sep 93 17:36 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA16324; Thu, 30 Sep 93 13:22:10 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.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.4/HPL42.42) id AA16311; Thu, 30 Sep 93 13:21:54 -0700 Received: by xap.xyplex.com id ; Thu, 30 Sep 93 16:14:54 -0500 Date: Thu, 30 Sep 93 16:14:54 -0500 Message-Id: <9309302114.AA18440@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: atm@matmos.hpl.hp.com In-Reply-To: Bob Stewart's message of Thu, 30 Sep 93 14:43:17 -0500 <9309301943.AA15462@xap.xyplex.com> Subject: Fumble Fingers My apologies to the mailing list. My flame was intended for the individual, not the public. I mis-edited my mailer's idea of reply destinations. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10444; 30 Sep 93 19:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10440; 30 Sep 93 19:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa26804; 30 Sep 93 19:30 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA21085; Thu, 30 Sep 93 15:22:27 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA21072; Thu, 30 Sep 93 15:22:26 -0700 Subject: classic draft submitted To: atm@matmos.hpl.hp.com X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Date: Thu, 30 Sep 93 15:22:26 -0700 Message-Id: <930930152226.24415@matmos.hpl.hp.com> Encoding: 13 TEXT, 2 TEXT SIGNATURE ATM'ers: I've just submitted the last version of the classic draft to internet-drafts. It should be appearing shortly as draft-ietf-atm-classic-ip-03.txt I have just recommended to Stev Knowles and Dave Piscitello, our area directors, that the classic draft be considered for elevation to proposed standard. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11148; 30 Sep 93 22:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11144; 30 Sep 93 22:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa29475; 30 Sep 93 22:12 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA25424; Thu, 30 Sep 93 18:04:02 -0700 Reply-To: atm@matmos.hpl.hp.com Errors-To: atm-request@matmos.hpl.hp.com X-Orig-Sender: atm-request@matmos.hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com X-Info: Archives via nic.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA25411; Thu, 30 Sep 93 18:03:59 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA07943; Thu, 30 Sep 93 21:04:20 EDT Received: from marlin.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA06624; Thu, 30 Sep 93 21:03:57 EDT Received: by marlin.fore.com (4.1/SMI-4.1) id AA06462; Thu, 30 Sep 93 21:03:56 EDT Date: Thu, 30 Sep 93 21:03:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9310010103.AA06462@marlin.fore.com> To: atm@matmos.hpl.hp.com Subject: Re: classic draft submitted > I have just recommended to Stev Knowles and Dave Piscitello, our area directors, > that the classic draft be considered for elevation to proposed standard. Mark, What's the hurry? We are meeting in only one month. Can't we wait until the meeting to finish things up and get concensus that the document is ready? I believe there are serious issues to address yet. A number of important comments from my last message went unacknowledged and haven't made their way into the document. I am resending these to provoke conversation (argument :-) ). > o All members within a LIS MUST be able to communicate via ATM with > all other members in the same LIS; i.e., the virtual Connection > topology underlying the intercommunication among the members is > fully meshed. There SHOULD be no administrative restrictions at > the ATM level that prevent VCs from operating between all pairs > of end points. Administrative restrictions on VC establishment by filtering on ATM addresses MUST be allowed. Not allowing such restrictions would be highly undesirable and unenforceable. I will certainly agree that there should be no technical reasons, aside from administrative policy reasons, which prevent this. > ARP Server Operational Requirements > > The ARP server accepts ATM calls/connections from other ATM end > points. At call setup and if the VC supports LLC/SNAP encapsulation, > the ARP server will transmit to the originating ATM station an InARP > request (InARP_REQUEST) for each logical IP subnet the server is > configured to serve. After receiving an InARP reply (InARP_REPLY), > the server will examine the IP address and the ATM address. The > server will add (or update) the map entry > and timestamp into its ARP table. If the InARP IP address duplicates > a table entry IP address and the InARP ATM address does not match the > table entry ATM address and there is an open VC associated with that > table entry, the InARP information is discarded and no modifications > to the table are made. ARP table entries persist until aged or > invalidated. VC call tear down does not remove ARP table entries. ARP servers should use different ATM addresses (selectors) for different LISs just like routers. Then they would require transmission of only a single InARP_REQUEST because incoming VCs would be demultiplexed by NSAP (selector). Silently tossing duplicate registrations is bad practice. If this error ever occurs for some valid reason, it will be difficult to debug. We need to extend InARP with an InARP_DUPLICATE message to alert the client of this error. The alternative (which is probably a good idea) is for the client to validate its own entry. It can do this by transmitting an ARP_REQUEST (after the InARP_REPLY) to make sure its entry is correctly installed. If it gets an ARP_REPLY with an incorrect ATM address or an ARP_NAK, it knows something is amiss and it can try reconnecting (ARP_NAK) or warn the user (incorrect ARP_REPLY). > ARP Client Operational Requirements > > The ARP client is responsible for contacting the ARP server to > register its own ARP information and to gain and refresh its own ARP > entry/information about other IP members. This means, as noted > above, that ARP clients MUST be configured with the ATM address of > the ARP server. ARP clients MUST: > > 1. Initiate the VC connection to the ARP server for transmitting and > receiving ARP and InARP packets. > > 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any > VC appropriately. InARP allows the client to respond only to requests matching its IP subnet. This creates a large hole. Therefore the server can't differentiate between ignored requests and lost ones and doesn't know whether to retransmit on a timeout or not. The client MUST be required to acknowledge all received requests either positively with an InARP_REPLY or negatively with a new InARP_NAK message. When client A connects to client B, client B has no way of knowing the IP address associated with the incoming VC from client A. An ARP client should send an InARP_REQUEST on all incoming VCs, just like an ARP server does, and all ARP clients must be required to respond to InARP_REQUESTS on SVCs to other clients. Multi-homed hosts have not been addressed. These should be handled the same way as routers which are part of multiple LISs, i.e. they should have different ATM addresses (selectors). There is another potential problem which I think we should nip in the bud in this document. Two hosts may just happen to establish simultaneous connections to each other. There is nothing currently which will prevent both from succeeding. Implementors may realize this and try to be smart by tearing one of them down. Unless we have a well specified method of choosing which VC to release, a serious thrashing problem can result. I don't believe there is a simple algorithm that each end can run independently by only examining the two connections. You can't choose either VCI Number or Call Reference Number because both are local quantities. The VC with the lowest number on one side may have the highest on the other side. Thus each side may pick the opposite VC of the other side, and both VCs will be released. The next time packets fly, both could be reestablished, etc. A potential solution is to allow only the entity with the higher (or lower) IP address to make the decision about which to drop. The other side should just leave both VCs established. Of course, this only works if both sides absolutely agree on the VC to IP address mapping. Multi-homed hosts could potentially screw this up depending on how we handle them. > ARP/InARP Packet Encapsulation > > ARP and InARP packets are to be encoded in AAL5 PDUs using LLC/SNAP > encapsulation. The format of the AAL5 CPCS-SDU payload field for > routed non-ISO PDUs is: > > Payload Format for Routed non-ISO PDUs > +------------------------------+ > | LLC 0xAA-AA-03 | > +------------------------------+ > | OUI 0x00-00-00 | > +------------------------------+ > | Ethertype 0x08-06 | > +------------------------------+ > | | > | ARP/InARP Packet | > | | > +------------------------------+ This is inconsistent. You are referring to the format of routed non-ISO PDUs, but your picture shows ARP/InARP packets. Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15000; 16 Sep 93 17:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14996; 16 Sep 93 17:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11724; 16 Sep 93 17:13 EDT Received: by matmos.hpl.hp.com (1.37.109.4/HPL42.42) id AA18423; Thu, 16 Sep 93 11:56:52 -0700 Reply-To: atm@hpl.hp.com Errors-To: atm-request@hpl.hp.com X-Orig-Sender: atm-request@hpl.hp.com X-Info: Submissions to atm@hpl.hp.com X-Info: [Un]Subscribe requests to atm-request@hpl.hp.com Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA18416; Thu, 16 Sep 93 11:56:51 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1I) id AA23767; Thu, 16 Sep 93 12:00:57 -0700 Received: from inet-gw-2.pa.dec.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA15626; Thu, 16 Sep 93 12:01:14 -0700 Received: by inet-gw-2.pa.dec.com; id AA07633; Thu, 16 Sep 93 11:59:39 -0700 Received: by us3rmc.bb.dec.com; id AA01569; Thu, 16 Sep 93 11:59:35 -0700 Message-Id: <9309161859.AA01569@us3rmc.bb.dec.com> Received: from levers.enet; by us3rmc.enet; Thu, 16 Sep 93 11:59:35 PDT Date: Thu, 16 Sep 93 11:59:35 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Miles Benson * MSLKG1-2/W06 * DTN226-7271 * LOC: LKG1-2/C7 16-Sep-1993 1458 ;, To: atm@hplms2.hpl.hp.com; MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Apparently-To: atm@hplms2.hpl.hp.com Subject: Auto Reply from Watch_Mail for 20-AUG-1993 17:15 to 31-DEC-1993 00:00 August 20th was my last day at Digital. I will not receive the mail message you sent. If you need to get in touch with me, I'll be working at Chipcom starting Monday, August 23. The phone number there is 508-460-8900. Thanks, Miles