home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / smds / smds-minutes-90feb.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  174 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by George Clapp/Ameritech and
  6. Mike Fidler/Ohio State University
  7.  
  8. MINUTES
  9.  
  10. The Switched Multi-megabit Data Service (SMDS) Working Group met for the
  11. first time for a single half-day session on Thursday morning, February
  12. 8.  Co-chair Mike Fidler opened discussion by stating the purpose of the
  13. group, which is to clarify the manner in which IP may operate over SMDS,
  14. and then asked George Clapp to present a tutorial discussion of SMDS (a
  15. copy of the viewgraphs is enclosed with the minutes).
  16.  
  17. SMDS is a switched, connectionless, high-speed data service which will
  18. be offered on a nationwide basis by the public carriers.  The service is
  19. intended to be the equivalent of an IEEE 802 LAN in functionality and
  20. performance and is designed to fit within the internet protocol stack as
  21. a transit network to IP. First trials may occur in late 1990; the first
  22. tariffed service may occur in 1991; and the service may be widely
  23. tariffed and deployed in 1992.
  24.  
  25. A number of questions arose as George progressed through the SMDS
  26. tutorial.  The first was cost.  Members of the group felt that they
  27. could not evaluate the service until they had an idea of the cost and of
  28. how that cost compared with the cost of a leased private line.  George
  29. responded that the tariff structure was not yet determined but that the
  30. public carriers recognized that SMDS must be cost competitive with a
  31. leased private line.  He then queried the group whether they would
  32. prefer flat or usage-based billing.  Members answered that the essential
  33. feature to billing was predictability and that a flat fee was preferred
  34. since network administrators had little knowledge or control over the
  35. traffic generated by their network.
  36.  
  37. George ended the tutorial by presenting the following list of potential
  38. topics to be discussed by the working group.
  39.  
  40.    o Addressing and Address Resolution
  41.    o Routing
  42.    o Network Management
  43.  
  44. With respect to addressing, SMDS uses a 60 bit address similar in format
  45. to a telephone number.  It may be possible to extend ARP to handle the
  46. 60 bit SMDS address in response to a query for an internet address.  The
  47. notion of ARP itself, however, may be extended to that of a "directory
  48. service," in which SMDS returns a 60 bit SMDS address in response to a
  49. network address as well as to an internet address.
  50.  
  51. With respect to routing, this function may be done in a number of ways
  52. over SMDS. The routers of an organization may operate as before by
  53. exchanging link state packets via SMDS to build and maintain routing
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. tables.  The issue which arises in this approach is the cost of the
  63. multicast packets, which depends upon the number of routers and upon the
  64. frequency of the generation of the link state packets.  If the cost
  65. grows too large, alternative approaches may be desirable.  One
  66. alternative may be to use the previously mentioned directory service to
  67. build the routing table.  Rather than exchange link state packets, a
  68. router may query the directory service for the SMDS address of an
  69. internet network.  The approach, however, would require an extension to
  70. existing routing protocols.
  71.  
  72. The discussion of routing brought out two models in which SMDS may
  73. operate.  One is a Private Virtual Network (PVN) in which SMDS
  74. interconnects a set of routers belonging to an existing organization.
  75. In this model, communication among devices is restricted to those
  76. devices which belong to the PVN and communication with devices external
  77. to the PVN would be carefully controlled.  The issues which arise in
  78. this model are how it would be done and what SMDS features would enhance
  79. the service.  The second model is that of a public network, analogous to
  80. the existing telephone network, in which an SMDS device may communicate
  81. with any other SMDS device.  The issues which arise here are security
  82. concerns, such as restricted access and authentication, and the issue of
  83. scale, since existing algorithms may not operate in an environment with
  84. large numbers of devices.  A third model was suggested in which existing
  85. leased lines of a private virtual network are kept and SMDS is accessed
  86. to provide additional capacity.
  87.  
  88. A number of other questions were raised.
  89.  
  90.    o What will be the performance of SMDS and what are the kinds of
  91.      services that SMDS may adequately support?
  92.    o What kind of network management features will SMDS support?  Will
  93.      SMDS "speak SNMP?"
  94.    o How would internet access the proposed directory service?
  95.    o To what extent will SMDS support multicast and how should multicast
  96.      be used?  For example, it would be necessary to limit the extent of
  97.      an ARP multicast in the public network model for SMDS, in which
  98.      there is universal connectivity among SMDS devices.
  99.  
  100. At the end of the meeting, the group tentatively scheduled a video
  101. conference for either March 27 or 28.  (Note:  we have subsequently
  102. learned that these dates are unavailable; new dates are not yet
  103. determined.)
  104.  
  105. Mike Fidler had asked those present to indicate on the sign up sheet
  106. whether they wished to participate in the SMDS mail list.  This mail
  107. list will be built and communication established after the IETF meeting.
  108.  
  109.  
  110. ATTENDEES
  111.  
  112.     Chet Birger              cbirger@bbn.com
  113.     Scott Bradner            sob@harvard.harvard.edu
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Mats Brunell             mats.brunell@sics.se
  123. Ted Brunner              tob@thumper.bellcore.com
  124. Steve Casner             casner@isi.edu
  125. Samir Chatterjee         samir@nynexst.com
  126. Steve Crocker            crocker@tis.com
  127. Tom Easterday            tom@nisca.ircc.ohio-state.edu
  128. Kent England             kwe@bu.edu
  129. Dino Farinacci           dino@bridge2.3com.com
  130. Dennis Ferguson          dennis@gw.ccie.utoronto.ca
  131. Dale Finkelson           dmf@westie.unl.edu
  132. Der-Hwa Gan              dhg@bridge2.3com.com
  133. Ella Gardner             epg@gateway.mitre.org
  134. Herve Goguely            rvg@bridge2.3com.com
  135. Steve Goldstein          goldstein@note.nsf.gov
  136. Jack Hahn                hahn@umd5.umd.edu
  137. Gene Hastings            hastings@psc.edu
  138. Juha Heinanen            jh@funet.fi
  139. Chris Hemrick            cfh@sabre.bellcore.com
  140. Bob Hinden               hinden@bbn.com
  141. Steven Hunter            hunter@ccc.nmfecc.gov
  142. Tom Hytry                tlh@iwlcs.att.com
  143. Dan Jordt                danj@cac.washington.edu
  144. Peter Kirstein           kirstein@cs.ucl.ac.uk
  145. Walt Lazear              lazear@gateway.mitre.org
  146. Dan Long                 long@bbn.com
  147. Charles Lynn             clynn@bbn.com
  148. Milo Medin               medin@nsipo.nasa.gov
  149. Berlin Moore             prepnet@andrew.cmu.edu
  150. Dennis Morris            morrisd@imo-uvax.dca.mil
  151. Don Morris               morris@ucar.edu
  152. John Moy                 jmoy@proteon.com
  153. Dave O'Leary             oleary@umd5.umd.edu
  154. Donald Pace              pace@fsu1.cc.fsu.edu
  155. Guru Parulkar            guru@flora.wustl.edu
  156. Dave Piscitello          dave@sabre.bellcore.com
  157. Dave Pokorney            poke@nervm.nerdc.ufl.edu
  158. Ira Richer               richer@vax.darpa.mil
  159. Jim Showalter            gamma@mintaka.dca.mil
  160. Martha Steenstrup        msteenst@bbn.com
  161. Zaw-Sing Su              zsu@tsca.istc.sri.com
  162. Claudio Topolcic         topolcic@bbn.com
  163. Greg Vaudreuil           gvaudre@nri.reston.va.us
  164. Ross Veach               rrv@uiuc.edu
  165. Steven Willis            swillis@wellfleet.com
  166. Linda Winkler            b32357@anlvm.ctd.anl.gov
  167. Dan Wintringham          danw@igloo.osc.edu
  168. Raj Yavatkar             raj@ms.uky.edu
  169. David Zimmerman          dpz@convex.com
  170.  
  171.  
  172.  
  173.                                3
  174.