CURRENT_MEETING_REPORT_ Reported by George Clapp/Ameritech and Mike Fidler/Ohio State University MINUTES The Switched Multi-megabit Data Service (SMDS) Working Group met for the first time for a single half-day session on Thursday morning, February 8. Co-chair Mike Fidler opened discussion by stating the purpose of the group, which is to clarify the manner in which IP may operate over SMDS, and then asked George Clapp to present a tutorial discussion of SMDS (a copy of the viewgraphs is enclosed with the minutes). SMDS is a switched, connectionless, high-speed data service which will be offered on a nationwide basis by the public carriers. The service is intended to be the equivalent of an IEEE 802 LAN in functionality and performance and is designed to fit within the internet protocol stack as a transit network to IP. First trials may occur in late 1990; the first tariffed service may occur in 1991; and the service may be widely tariffed and deployed in 1992. A number of questions arose as George progressed through the SMDS tutorial. The first was cost. Members of the group felt that they could not evaluate the service until they had an idea of the cost and of how that cost compared with the cost of a leased private line. George responded that the tariff structure was not yet determined but that the public carriers recognized that SMDS must be cost competitive with a leased private line. He then queried the group whether they would prefer flat or usage-based billing. Members answered that the essential feature to billing was predictability and that a flat fee was preferred since network administrators had little knowledge or control over the traffic generated by their network. George ended the tutorial by presenting the following list of potential topics to be discussed by the working group. o Addressing and Address Resolution o Routing o Network Management With respect to addressing, SMDS uses a 60 bit address similar in format to a telephone number. It may be possible to extend ARP to handle the 60 bit SMDS address in response to a query for an internet address. The notion of ARP itself, however, may be extended to that of a "directory service," in which SMDS returns a 60 bit SMDS address in response to a network address as well as to an internet address. With respect to routing, this function may be done in a number of ways over SMDS. The routers of an organization may operate as before by exchanging link state packets via SMDS to build and maintain routing 1 tables. The issue which arises in this approach is the cost of the multicast packets, which depends upon the number of routers and upon the frequency of the generation of the link state packets. If the cost grows too large, alternative approaches may be desirable. One alternative may be to use the previously mentioned directory service to build the routing table. Rather than exchange link state packets, a router may query the directory service for the SMDS address of an internet network. The approach, however, would require an extension to existing routing protocols. The discussion of routing brought out two models in which SMDS may operate. One is a Private Virtual Network (PVN) in which SMDS interconnects a set of routers belonging to an existing organization. In this model, communication among devices is restricted to those devices which belong to the PVN and communication with devices external to the PVN would be carefully controlled. The issues which arise in this model are how it would be done and what SMDS features would enhance the service. The second model is that of a public network, analogous to the existing telephone network, in which an SMDS device may communicate with any other SMDS device. The issues which arise here are security concerns, such as restricted access and authentication, and the issue of scale, since existing algorithms may not operate in an environment with large numbers of devices. A third model was suggested in which existing leased lines of a private virtual network are kept and SMDS is accessed to provide additional capacity. A number of other questions were raised. o What will be the performance of SMDS and what are the kinds of services that SMDS may adequately support? o What kind of network management features will SMDS support? Will SMDS "speak SNMP?" o How would internet access the proposed directory service? o To what extent will SMDS support multicast and how should multicast be used? For example, it would be necessary to limit the extent of an ARP multicast in the public network model for SMDS, in which there is universal connectivity among SMDS devices. At the end of the meeting, the group tentatively scheduled a video conference for either March 27 or 28. (Note: we have subsequently learned that these dates are unavailable; new dates are not yet determined.) Mike Fidler had asked those present to indicate on the sign up sheet whether they wished to participate in the SMDS mail list. This mail list will be built and communication established after the IETF meeting. ATTENDEES Chet Birger cbirger@bbn.com Scott Bradner sob@harvard.harvard.edu 2 Mats Brunell mats.brunell@sics.se Ted Brunner tob@thumper.bellcore.com Steve Casner casner@isi.edu Samir Chatterjee samir@nynexst.com Steve Crocker crocker@tis.com Tom Easterday tom@nisca.ircc.ohio-state.edu Kent England kwe@bu.edu Dino Farinacci dino@bridge2.3com.com Dennis Ferguson dennis@gw.ccie.utoronto.ca Dale Finkelson dmf@westie.unl.edu Der-Hwa Gan dhg@bridge2.3com.com Ella Gardner epg@gateway.mitre.org Herve Goguely rvg@bridge2.3com.com Steve Goldstein goldstein@note.nsf.gov Jack Hahn hahn@umd5.umd.edu Gene Hastings hastings@psc.edu Juha Heinanen jh@funet.fi Chris Hemrick cfh@sabre.bellcore.com Bob Hinden hinden@bbn.com Steven Hunter hunter@ccc.nmfecc.gov Tom Hytry tlh@iwlcs.att.com Dan Jordt danj@cac.washington.edu Peter Kirstein kirstein@cs.ucl.ac.uk Walt Lazear lazear@gateway.mitre.org Dan Long long@bbn.com Charles Lynn clynn@bbn.com Milo Medin medin@nsipo.nasa.gov Berlin Moore prepnet@andrew.cmu.edu Dennis Morris morrisd@imo-uvax.dca.mil Don Morris morris@ucar.edu John Moy jmoy@proteon.com Dave O'Leary oleary@umd5.umd.edu Donald Pace pace@fsu1.cc.fsu.edu Guru Parulkar guru@flora.wustl.edu Dave Piscitello dave@sabre.bellcore.com Dave Pokorney poke@nervm.nerdc.ufl.edu Ira Richer richer@vax.darpa.mil Jim Showalter gamma@mintaka.dca.mil Martha Steenstrup msteenst@bbn.com Zaw-Sing Su zsu@tsca.istc.sri.com Claudio Topolcic topolcic@bbn.com Greg Vaudreuil gvaudre@nri.reston.va.us Ross Veach rrv@uiuc.edu Steven Willis swillis@wellfleet.com Linda Winkler b32357@anlvm.ctd.anl.gov Dan Wintringham danw@igloo.osc.edu Raj Yavatkar raj@ms.uky.edu David Zimmerman dpz@convex.com 3