CURRENT_MEETING_REPORT_ Reported by George Clapp/Ameritech IPLPDN Minutes Opening Remarks This was the first meeting of the IP over Large Public Data Networks Working Group, and the meeting began with some introductory remarks describing the reasons for the formation of the group. SMDS is a new data service which may be tariffed by public carriers in the United States beginning in 1991. A Working Group within the IETF, IP over SMDS, has drafted a document specifying the operation of IP over SMDS, in which they assumed that relatively small logical IP subnetworks would be supported by SMDS. This document meets what is perceived to be a near-term need for the industry. The group, however, felt that it would be desirable to support public IP connectivity over SMDS, in which any IP device may communicate directly with any other IP device attached to the SMDS network. Three problems were identified which required solutions before this goal could be reached: 1. A scheme to encapsulate IP datagrams and to identify the higher layer protocol. 2. Routing in very large networks. 3. Address resolution in very large networks (mapping the protocol address to the corresponding hardware address). The concern with the latter two issues was that existing solutions to routing and address resolution may generate excessive overhead when used in very large networks. Bob Hinden and Noel Chiappa wished to form a new Working Group to address these issues but felt that the problems were common to all public data networks. Therefore, Frame Relay, ISDN, and the work of the PDN Routing Working Group, which dealt with X.25 networks, were folded into this group as well. Tasks and Work Done Discussion of the anticipated usage of these different public data networks led to a clarification of the tasks at hand and of the current state of approaches to those tasks, as depicted below: 1 The figure depicts the three issues of encapsulation, address resolution, and routing, and the environment in which a proposed solution is to be used. ``Private'' denotes a Virtual Private Network implemented over a Public Data Network (PDN); ``public'' denotes global IP connectivity across a PDN. This graph was applied to the different PDNs. SMDS Private Public -------------------------------------- encapsulation | | | & protocol | SMDS PDU, | SMDS PDU, | identification | 802.2, & SNAP | 802.2, & SNAP | | | | -------------------------------------- | | | address | ARP | ? | resolution | | | | | | -------------------------------------- | | | routing | existing | ? | | solutions | | | | | -------------------------------------- Frame Relay Private Public -------------------------------------- encapsulation | | | & protocol | ? | ? | identification | | | | | | -------------------------------------- | | | address | static | ? | resolution | table | | | | | -------------------------------------- | | | routing | existing | ? | | solutions | | | | | -------------------------------------- X.25 Packet Switching Private Public -------------------------------------- encapsulation | | | 2 & protocol | RFC 877 | RFC 877 | identification | | | | | | -------------------------------------- | | | address | static | ? | resolution | table | | | | | -------------------------------------- | | | routing | existing | ? | | solutions | | | | | -------------------------------------- ISDN Circuits Private Public -------------------------------------- encapsulation | | | & protocol | ? | ? | identification | | | | | | -------------------------------------- | | | address | static | ? | resolution | table | | | | | -------------------------------------- | | | routing | existing | ? | | solutions | | | | | -------------------------------------- Encapsulation and Higher Layer Protocol Identification There is no commonly agreed upon scheme for the encapsulation of IP datagrams and for the identification of higher layer protocols for frame relay or for circuit ISDN. The group discussed the possibility of using PPP or 802.2 LLC/SNAP for this purpose. There was some question whether this work should be done within the IPLPDN Working Group or within a new Working Group created expressly for this purpose. The opinion was expressed that people interested in this topic are encouraged to investigate the issues and to draft documents. Routing and Address Resolution 3 A server model is a possible solution to the issues of scaling for routing and address resolution. It was pointed out that the functions of both address resolution and routing may be performed by a single server, and that the server may respond to a routing query for an IP address with the PDN address corresponding to that IP address, or to the next hop for that IP address. Noel Chiappa pointed out that the current approach uses a two step process: 1. Translate destination IP address to next hop IP address. 2. Translate next hop IP address to hardware (or PDN) address. 32 Bit CRC for IP Over SMDS Rick Szmauz asked that the ``IP over SMDS'' document specify that the optional 32 bit CRC of SMDS be used for all IP transmissions over SMDS. He felt that the use of the CRC would more nearly meet the common expectations of a MAC service. The group decided not to adopt this change for both technical and procedural reasons. Technically, the group felt that the 10 bit ``per cell CRC'' provided adequate error control and, procedurally, it was felt that this issue should have been discussed the previous day by the IP over SMDS Working Group. Possible use of BGP as a Solution to Large Scale Routing There was an extended discussion of the use of BGP (RFCs 1163 and 1164) as a solution to the problem of large scale routing. The approach appeared promising to those familiar with the routing protocol, and Paul Tsuchiya, Russ Hobby, and George Clapp volunteered to draft something before the next IETF meeting in March, 1991. Attendees Anne Ambler anne@spider.co.uk Karl Auerbach karl@eng.sun.com Terry Bradley tbradley@wellfleet.com Caralyn Brown cbrown@ENR.Prime.com Alan Bryenton Duane Butler dmb@network.com George Clapp meritec!clapp@uunet.uu.net Tracy Cox tacox@sabre.bellcore.com Caroline Cranfill rcc@bss.com Avri Doria avri@clearpoint.com Dino Farinacci dino@esd.3com.com Peter Ford peter@lanl.gov Vince Fresquez vince@druhi.att.com Robert Gilligan gilligan@eng.sun.com 4 Juha Heinanen jh@funet.fi Christine Hemrick cfh@thumper.bellcore.com Robert Hinden hinden@bbn.com Russell Hobby rdhobby@ucdavis.edu Gary Kunis gkunis@cisco.com Richard Libby libby@c10sd6.stpaul.ncr.com Andrew Malis malis@bbn.com Robert Meierhofer meierhofer@stpaul.ncr.com Brad Parker brad@cayman.com Yakov Rekhter yakov@ibm.com Ray Samora rvs@proteon.com Marc Sheldon ms@uni-dortmund.de Daisy Shen daisy@ibm.com Emil Sturniolo Laszlo Szerenyi Rick Szmauz szmauz@hifi.enet.dec.com Sally Tarquinio sally@gateway@mitre.org William Townsend townsend@xylogics.com Paul Tsuchiya tsuchiya@thumper.bellcore.com Gregory Vaudreuil gvaudre@nri.reston.va.us Richard Woundy rwoundy@ibm.com David Zimmerman dpz@dimacs.rutgers.edu 5