home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / iplpdn / iplpdn-minutes-90dec.txt < prev    next >
Text File  |  1993-02-17  |  10KB  |  260 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by George Clapp/Ameritech
  7.  
  8. IPLPDN Minutes
  9.  
  10. Opening Remarks
  11.  
  12. This was the first meeting of the IP over Large Public Data Networks
  13. Working Group, and the meeting began with some introductory remarks
  14. describing the reasons for the formation of the group.
  15.  
  16. SMDS is a new data service which may be tariffed by public carriers in
  17. the United States beginning in 1991.  A Working Group within the IETF,
  18. IP over SMDS, has drafted a document specifying the operation of IP over
  19. SMDS, in which they assumed that relatively small logical IP subnetworks
  20. would be supported by SMDS. This document meets what is perceived to be
  21. a near-term need for the industry.  The group, however, felt that it
  22. would be desirable to support public IP connectivity over SMDS, in which
  23. any IP device may communicate directly with any other IP device attached
  24. to the SMDS network.  Three problems were identified which required
  25. solutions before this goal could be reached:
  26.  
  27.  
  28.   1. A scheme to encapsulate IP datagrams and to identify the higher
  29.      layer protocol.
  30.   2. Routing in very large networks.
  31.   3. Address resolution in very large networks (mapping the protocol
  32.      address to the corresponding hardware address).
  33.  
  34.  
  35. The concern with the latter two issues was that existing solutions to
  36. routing and address resolution may generate excessive overhead when used
  37. in very large networks.  Bob Hinden and Noel Chiappa wished to form a
  38. new Working Group to address these issues but felt that the problems
  39. were common to all public data networks.  Therefore, Frame Relay, ISDN,
  40. and the work of the PDN Routing Working Group, which dealt with X.25
  41. networks, were folded into this group as well.
  42.  
  43. Tasks and Work Done
  44.  
  45. Discussion of the anticipated usage of these different public data
  46. networks led to a clarification of the tasks at hand and of the current
  47. state of approaches to those tasks, as depicted below:
  48.  
  49.  
  50.  
  51.                                    1
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. The figure depicts the three issues of encapsulation, address
  59. resolution, and routing, and the environment in which a proposed
  60. solution is to be used.  ``Private'' denotes a Virtual Private Network
  61. implemented over a Public Data Network (PDN); ``public'' denotes global
  62. IP connectivity across a PDN. This graph was applied to the different
  63. PDNs.
  64.  
  65.  
  66.                                       SMDS
  67.                            Private           Public
  68.                      --------------------------------------
  69.      encapsulation   |                  |                 |
  70.      & protocol      |   SMDS PDU,      |   SMDS PDU,     |
  71.      identification  |   802.2, & SNAP  |   802.2, & SNAP |
  72.                      |                  |                 |
  73.                      --------------------------------------
  74.                      |                  |                 |
  75.      address         |       ARP        |        ?        |
  76.      resolution      |                  |                 |
  77.                      |                  |                 |
  78.                      --------------------------------------
  79.                      |                  |                 |
  80.      routing         |    existing      |        ?        |
  81.                      |    solutions     |                 |
  82.                      |                  |                 |
  83.                      --------------------------------------
  84.  
  85.  
  86.                                   Frame Relay
  87.                            Private           Public
  88.                      --------------------------------------
  89.      encapsulation   |                  |                 |
  90.      & protocol      |        ?         |        ?        |
  91.      identification  |                  |                 |
  92.                      |                  |                 |
  93.                      --------------------------------------
  94.                      |                  |                 |
  95.      address         |      static      |        ?        |
  96.      resolution      |      table       |                 |
  97.                      |                  |                 |
  98.                      --------------------------------------
  99.                      |                  |                 |
  100.      routing         |    existing      |        ?        |
  101.                      |    solutions     |                 |
  102.                      |                  |                 |
  103.                      --------------------------------------
  104.  
  105.  
  106.  
  107.                              X.25 Packet Switching
  108.                            Private           Public
  109.                      --------------------------------------
  110.      encapsulation   |                  |                 |
  111.  
  112.                                    2
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.      & protocol      |      RFC 877     |     RFC 877     |
  120.      identification  |                  |                 |
  121.                      |                  |                 |
  122.                      --------------------------------------
  123.                      |                  |                 |
  124.      address         |      static      |        ?        |
  125.      resolution      |      table       |                 |
  126.                      |                  |                 |
  127.                      --------------------------------------
  128.                      |                  |                 |
  129.      routing         |    existing      |        ?        |
  130.                      |    solutions     |                 |
  131.                      |                  |                 |
  132.                      --------------------------------------
  133.  
  134.  
  135.  
  136.                                  ISDN Circuits
  137.                            Private           Public
  138.                      --------------------------------------
  139.      encapsulation   |                  |                 |
  140.      & protocol      |        ?         |        ?        |
  141.      identification  |                  |                 |
  142.                      |                  |                 |
  143.                      --------------------------------------
  144.                      |                  |                 |
  145.      address         |      static      |        ?        |
  146.      resolution      |      table       |                 |
  147.                      |                  |                 |
  148.                      --------------------------------------
  149.                      |                  |                 |
  150.      routing         |    existing      |        ?        |
  151.                      |    solutions     |                 |
  152.                      |                  |                 |
  153.                      --------------------------------------
  154.  
  155.  
  156.  
  157. Encapsulation and Higher Layer Protocol Identification
  158.  
  159. There is no commonly agreed upon scheme for the encapsulation of IP
  160. datagrams and for the identification of higher layer protocols for frame
  161. relay or for circuit ISDN. The group discussed the possibility of using
  162. PPP or 802.2 LLC/SNAP for this purpose.  There was some question whether
  163. this work should be done within the IPLPDN Working Group or within a new
  164. Working Group created expressly for this purpose.  The opinion was
  165. expressed that people interested in this topic are encouraged to
  166. investigate the issues and to draft documents.
  167.  
  168. Routing and Address Resolution
  169.  
  170.  
  171.                                    3
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178. A server model is a possible solution to the issues of scaling for
  179. routing and address resolution.  It was pointed out that the functions
  180. of both address resolution and routing may be performed by a single
  181. server, and that the server may respond to a routing query for an IP
  182. address with the PDN address corresponding to that IP address, or to the
  183. next hop for that IP address.  Noel Chiappa pointed out that the current
  184. approach uses a two step process:
  185.  
  186.  
  187.   1. Translate destination IP address to next hop IP address.
  188.   2. Translate next hop IP address to hardware (or PDN) address.
  189.  
  190.  
  191. 32 Bit CRC for IP Over SMDS
  192.  
  193. Rick Szmauz asked that the ``IP over SMDS'' document specify that the
  194. optional 32 bit CRC of SMDS be used for all IP transmissions over SMDS.
  195. He felt that the use of the CRC would more nearly meet the common
  196. expectations of a MAC service.  The group decided not to adopt this
  197. change for both technical and procedural reasons.  Technically, the
  198. group felt that the 10 bit ``per cell CRC'' provided adequate error
  199. control and, procedurally, it was felt that this issue should have been
  200. discussed the previous day by the IP over SMDS Working Group.
  201.  
  202. Possible use of BGP as a Solution to Large Scale Routing
  203.  
  204. There was an extended discussion of the use of BGP (RFCs 1163 and 1164)
  205. as a solution to the problem of large scale routing.  The approach
  206. appeared promising to those familiar with the routing protocol, and Paul
  207. Tsuchiya, Russ Hobby, and George Clapp volunteered to draft something
  208. before the next IETF meeting in March, 1991.
  209.  
  210. Attendees
  211.  
  212. Anne Ambler              anne@spider.co.uk
  213. Karl Auerbach            karl@eng.sun.com
  214. Terry Bradley            tbradley@wellfleet.com
  215. Caralyn Brown            cbrown@ENR.Prime.com
  216. Alan Bryenton
  217. Duane Butler             dmb@network.com
  218. George Clapp             meritec!clapp@uunet.uu.net
  219. Tracy Cox                tacox@sabre.bellcore.com
  220. Caroline Cranfill        rcc@bss.com
  221. Avri Doria               avri@clearpoint.com
  222. Dino Farinacci           dino@esd.3com.com
  223. Peter Ford               peter@lanl.gov
  224. Vince Fresquez           vince@druhi.att.com
  225. Robert Gilligan          gilligan@eng.sun.com
  226.  
  227.                                    4
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. Juha Heinanen            jh@funet.fi
  235. Christine Hemrick        cfh@thumper.bellcore.com
  236. Robert Hinden            hinden@bbn.com
  237. Russell Hobby            rdhobby@ucdavis.edu
  238. Gary Kunis               gkunis@cisco.com
  239. Richard Libby            libby@c10sd6.stpaul.ncr.com
  240. Andrew Malis             malis@bbn.com
  241. Robert Meierhofer        meierhofer@stpaul.ncr.com
  242. Brad Parker              brad@cayman.com
  243. Yakov Rekhter            yakov@ibm.com
  244. Ray Samora               rvs@proteon.com
  245. Marc Sheldon             ms@uni-dortmund.de
  246. Daisy Shen               daisy@ibm.com
  247. Emil Sturniolo
  248. Laszlo Szerenyi
  249. Rick Szmauz              szmauz@hifi.enet.dec.com
  250. Sally Tarquinio          sally@gateway@mitre.org
  251. William Townsend         townsend@xylogics.com
  252. Paul Tsuchiya            tsuchiya@thumper.bellcore.com
  253. Gregory Vaudreuil        gvaudre@nri.reston.va.us
  254. Richard Woundy           rwoundy@ibm.com
  255. David Zimmerman          dpz@dimacs.rutgers.edu
  256.  
  257.  
  258.  
  259.                                    5
  260.