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

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by George Clapp/Ameritech
  7.  
  8. SMDS Minutes
  9.  
  10. Review of Draft Document
  11.  
  12. The IP over Switched Multi-megabit Data Service (SMDS) Working Group met
  13. for three half-day sessions.  The majority of the time was spent
  14. reviewing the text of a draft document, A Proposed Standard for the
  15. Transmission of IP Datagrams over SMDS, written by Dave Piscitello and
  16. Joe Lawrence.  The configuration assumed in the document was that of a
  17. Logical IP Subnet (dubbed an LIS), in which a virtual private network
  18. supported by SMDS was treated as an IP network/subnet.  The following
  19. are the requirements for an LIS configuration:
  20.  
  21.  
  22.    o All members have the same IP network/subnetwork number.
  23.    o All stations within an LIS are accessed directly over SMDS.
  24.    o All stations outside of the LIS are accessed via a router.
  25.    o For each LIS, a single SMDS group address (smds$ip_ga) has been
  26.      configured that identifies all members of the LIS.
  27.  
  28.  
  29. The protocol stack is assumed to be that depicted below in figure 1.
  30.  
  31.  
  32.                ---------------------------------------------
  33.                |                   IP/ARP                  |
  34.                ---------------------------------------------
  35.                |      Subnetwork Access Protocol (SNAP)    |
  36.                ---------------------------------------------
  37.                |             IEEE 802.2 LLC Type 1         |
  38.                ---------------------------------------------
  39.                |SMDS Interface Protocol (SIP) Level 3 (MAC)|
  40.                ---------------------------------------------
  41.                |                 SIP Level 2               |
  42.                ---------------------------------------------
  43.                |                 SIP Level 1               |
  44.                ---------------------------------------------
  45.  
  46.                                   Figure 1
  47.  
  48.  
  49.  
  50. In addition to the SMDS individual address associated with the
  51. Subscriber Network Interface (SNI), and to the SMDS group address
  52. associated with the LIS, the document referred to a third SMDS group
  53. address, the SMDS ARP Request Address (smds$arp_req).  This group
  54. address is set to smds $ip_ga, but latter implementations may set the
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. address to a subset of the addresses in the LIS to deal with scaling
  64. issues.
  65.  
  66. The dynamic mapping of 32 bit Internet addresses to 60 bit SMDS
  67. addresses is done via Address Resolution Protocol (ARP). ARP requests
  68. will be multicast to the smds$arp_req address.  The ARP parameters which
  69. require specification are the following:
  70.  
  71.  
  72. ar$hrd  16 bits hardware type code           <to be determined>
  73. ar$pro  16 bits protocol type code           decimal 2048 for IP
  74. ar$hln  8 bits octets in hardware address    decimal 8 for 64 bits
  75. ar$pln  8 bits octets in protocol address    decimal 4 for 32 bits
  76. ar$op   16 bits operation code               1:  request
  77.                                             2:  reply
  78.  
  79.  
  80.  
  81. Dave Piscitello volunteered to contact Joyce Reynolds to obtain a value
  82. for the hardware type code.
  83.  
  84. An issue arose during the discussion of ARP over SMDS concerning the
  85. encoding of the SMDS address in the ARP reply message.  Following the
  86. precedence of the IP over FDDI Working Group, the document specified
  87. that the SMDS address will be carried in ``canonical'' format, which is
  88. the format specified in the IEEE P802.1A/D10 draft standard, in which
  89. the least significant bit of the most significant octet is transmitted
  90. first.  The encoding of the 60 bit address within the SIP L_3 PDU does
  91. not conform to the canonical format, and the bits of each octet would
  92. have to be reversed.  The use of the canonical format is important in
  93. transparent bridging, when LANs of a similar address space but of
  94. dissimilar address encoding schemes may be bridged.  However, the group
  95. questioned the utility of transparent bridging between 802 LANs with a
  96. 48 bit address space and SMDS with a 60 bit address space.  This
  97. questionable utility was compared with the potential for confusion
  98. caused by the reversal of bits in the SMDS address.  In the end, the
  99. group decided not to use the canonical format, but instead to use the
  100. format specified for the SMDS ``MAC'' header.
  101.  
  102. No unresolved issues remained with the document and the group asked Joe
  103. Lawrence to incorporate the suggested modifications and to release the
  104. document to the email group for confirmation.  Joe indicated that he
  105. might be able to release the document by mid-August.
  106.  
  107. Public Connectivity
  108.  
  109. It was felt that the draft document was adequate to define the operation
  110. of IP over small virtual private networks supported by SMDS. Discussion
  111. then turned to the issue of ``public connectivity,'' in which an SMDS
  112. device may communicate directly with any other SMDS device.  The
  113. question was asked of this model ``What breaks?'', and the following
  114. items were listed:
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.    o ARP
  124.    o Routing:  cost, traffic volume, table sizes
  125.    o Address management
  126.  
  127.  
  128. The group was then asked whether there was any interest in pursuing this
  129. problem, and discussion led to an offer by Manoel Rodrigues and George
  130. Clapp to draft an ``issues'' document to attempt to clarify the issues
  131. left unresolved by the draft document.
  132.  
  133. Support of Other Protocols
  134.  
  135. Vicki Ralls pointed out that other protocols such as DECNET and XNS also
  136. need a specification to operate over SMDS, and asked whether this was of
  137. interest to the group.  The group felt that IP was the appropriate topic
  138. for their work and suggested that Bellcore might be approached
  139. concerning these other protocols.
  140.  
  141. Network Management
  142.  
  143. Dave Piscitello distributed copies of three papers on network management
  144. relevant to SMDS.
  145.  
  146.  
  147.    o Experimental Definitions of Managed Objects for the SMDS Interface
  148.      Protocol (sip) Interface Type, Kaj Tesink
  149.    o Experimental Definitions of Managed Objects for the t3-carrier
  150.      Interface Type, Tracy Cox, Kaj Tesink
  151.    o Internet Draft of T1-Carrier objects, Kaj Tesink, Tracy Cox
  152.  
  153.  
  154. These documents were distributed to the Working Group on an
  155. informational basis to the.  The first two documents had been submitted
  156. for consideration by the TransMIB Working Group; the third had not been
  157. submitted since the points raised in the document had already been
  158. addressed by the TransMIB group.
  159.  
  160. Future Work
  161.  
  162. The work remaining for the group will be to review and possibly approve
  163. the draft document.  The group may be able to approve the document at
  164. the upcoming meeting in December and, if possible, begin the process of
  165. submitting the document to become an RFC. At the same meeting, the group
  166. may review the document to be written by Manoel Rodrigues and George
  167. Clapp.
  168.  
  169. During the IETF Plenary of Friday morning, August 3rd, Bob Hinden
  170. announced the formation of a new Working Group within the routing area,
  171. Address Resolution and Routing over SMDS and X.25 Public Data Networks.
  172. This group will be chaired by George Clapp and may investigate some of
  173. the issues left unresolved by the IP over SMDS Working Group.
  174.  
  175.  
  176.                                    3
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183. Attendees
  184.  
  185.  
  186. Douglas Bagnall          bagnall_d@apollo.hp.com
  187. Chet Birger              cbirger@bbn.com
  188. Roger Boehner            Roger.Boehner@StPaul.NCR.COM
  189. Caralyn Brown            cbrown@ENR.Prime.com
  190. Asheem Chandna           ac0@mtuxo.att.com
  191. George Clapp             meritec!clapp@bellcore.bellcore.com
  192. Tracy Cox                tacox@sabre.bellcore.com
  193. Caroline Cranfill        rcc@bss.com
  194. Kevin Fall               kfall@Berkeley.EDU
  195. Michael Fidler           ts0026@ohstvma.ircc.ohio-state.edu
  196. James Forster            forster@cisco.com
  197. Craig Fox                foxcj@nsco.network.com
  198. Eugene Geer              bcr!nvmxr!ewg
  199. Neil Haller              nmh@bellcore.com
  200. Dave Kaufman             dek@proteon.com
  201. Alex Koifman             akoifman@bbn.com
  202. Joseph Lawrence          jcl@sabre.bellcore.com
  203. Walter Lazear            lazear@gateway.mitre.org
  204. Alan Menezes             afm@cup.portal.com
  205. David Piscitello         dave@sabre.bellcore.com
  206. Vicki Ralls              ralls@cisco.com
  207. Michael Reilly           reilly@nsl.dec.com
  208. Ron Roberts              roberts@jessica.stanford.edu
  209. Manuel Rodrigues
  210. Jim Showalter            gamma@mintaka.dca.mil
  211. Frank Slaughter          fgs@shiva.com
  212. Zaw-Sing Su              zsu@tsca.istc.sri.com
  213. Gregory Vaudreuil        gvaudre@nri.reston.va.us
  214. Chris Weider             clw@merit.edu
  215. Steve Willis             swillis@wellfleet.com
  216.  
  217.  
  218.  
  219.                                    4
  220.