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