home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-93jul.txt < prev    next >
Text File  |  1993-09-25  |  7KB  |  210 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Fred Baker/ACC
  5.  
  6. Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
  7.  
  8.  
  9. PPP Extensions for Bridging
  10.  
  11. o New Features
  12.  
  13.   - Section 6.1, Canonical MAC Type for FDDI. This was added in response to 
  14.     requests from several vendors for it. There are significant 
  15.     compatibility concerns; for this reason, anyone implementing the 
  16.     canonical address MAC Type for FDDI MUST also implement the non-
  17.     canonical format.
  18.  
  19.   - Section 6.2, Choice of Spanning Tree Protocol. The IBM Source Route 
  20.     Spanning Tree BPDU is defined, and an option will be implemented to 
  21.     negotiate the use of either *no* spanning tree, IEEE 802.1(d), IEEE 
  22.     802.1(g), and/or IBM SR. Note that an 802 spanning tree and the IBM 
  23.     spanning tree can occur simultaneously on the line, and that 802.1(d) 
  24.     and 802.1(g) will use the same BPDU protocol identifier, as they are 
  25.     internally distinguishable.
  26.  
  27.   - Sections 6.4 and 6.5: additional language was added to help systems make 
  28.     an interoperable choice when differently configured. This does not 
  29.     resolve all configuration errors, so the existing behavior - Bridge 
  30.     Control Protocol closes on configuration failure - is still required in 
  31.     severe case.
  32.  
  33.   - Section 6.9 (New): MAC Address Specification. This allows the system to 
  34.     announce its own MAC Address or request the assignment of a MAC Address 
  35.     by its neighbor.
  36.  
  37. o Advisory Information
  38.  
  39.   - Section 6.1 now recommends that the count field be zero and a self 
  40.     describing pad (defined in the PPP LCP Extensions) be used.
  41.  
  42.   - Section 6.6 will be updated to reflect that the use of multiple options 
  43.     of the same type did not work correctly in RFC 1171 but does in RFC 1331 
  44.     and in the Draft Standard PPP LCP. The Draft Standard procedures should 
  45.     be used.
  46.  
  47.   - Section 6.8 currently specifies what is now essentially a proprietary 
  48.     protocol used by Network Systems. This fact will prevent the document 
  49.     from advancing to Draft Standard unless the feature is either better 
  50.     documented or marked historical. Fred Baker took the action to ask 
  51.     Network Systems for more documentation.
  52.  
  53. o Miscellaneous Additional Edits
  54.  
  55.   The status as left by the Working Group is that Rich has additional 
  56.   updates to make, which will be discussed on the list. We believe at this 
  57.   point that the document will be able to advance to Draft Standard.
  58.  
  59.  
  60. PPP LCP
  61.  
  62. RFC 1171 should be Historical.  When updated, the current PPP LCP draft
  63. should go to Draft Standard.  There were various minor edits, and the
  64. section on handling multiple instances of the same option in a configure
  65. NAK especially requires some word-smithing.
  66.  
  67.  
  68. PPP HDLC Framing
  69.  
  70. The HDLC Framing draft is a direct extraction from the older PPP LCP
  71. document, and is ready for elevation to Draft Standard.
  72.  
  73.  
  74. PPP LCP Extensions
  75.  
  76. The PPP LCP Extensions draft is recommended for consideration as a
  77. Proposed Standard.
  78.  
  79.  
  80. PPP Requirements
  81.  
  82. This document will be reorganized and posted as an Informational RFC.
  83.  
  84.  
  85. PPP Compression
  86.  
  87. A separate breakout meeting was held for the bulk of the work, and the
  88. slides from the two presentations that were given follow these minutes.
  89. They contain a lot of information.
  90.  
  91. Algorithms Under Consideration
  92.  
  93. Five candidate protocols are under active consideration:
  94.  
  95.  
  96.   1. Predictor -- Free, but poor compression ratio - implement with CRC
  97.   2. Gandalf FZA -- $20K without patent protection
  98.   3. V.42bis -- $20K one time
  99.   4. HP PPC -- About $20 one time with patent protection
  100.   5. STAC -- $5 per, royalty on software with patent protection, $40 on
  101.      chip
  102.  
  103.  
  104. Although we wanted to, the PPPEXT Working Group does not recommend one
  105. of them for universal implementation.  The reason is that the group
  106. cannot, under IETF rules and marketplace sense, require everyone to
  107. license code or silicon from a single vendor, and the one unencumbered
  108. algorithm we have found has significant (64K per link) memory
  109. requirements.  We therefore only provide the means to negotiate them.
  110.  
  111. Packet format for Predictor is:
  112.  
  113.  
  114.      Address
  115.      Control
  116.      PPP Compression Data Protocol ID
  117.      Original Frame Length (not compressed)
  118.      Compressed Frame
  119.      Frame CRC-16 (not compressed)
  120.  
  121.  
  122.  
  123. The reason for the CRC-16 is to help detect frame loss (and resultant
  124. dictionary desynchronization) in the case where a reliable link is not
  125. in use.
  126.  
  127. Reliable Link Negotiation
  128.  
  129. How to implement without a reliable link:  decompress.  If a frame fails
  130. to correctly decompress, send a Compression Control Protocol Configure
  131. request on the link.
  132.  
  133.  
  134.    o Reasons not to use a reliable link:
  135.  
  136.       -  Would like to use the same algorithm on all WAN code
  137.       -  Links are generally reliable anyway
  138.       -  Unreliable links are perceived to be simpler
  139.  
  140.    o Reasons to use a reliable link:
  141.  
  142.       -  Loss of buffers introduced problems
  143.       -  More graceful degradation in the presence of errors
  144.  
  145.  
  146. LAPB Negotiation Option
  147.  
  148. LAPB will be negotiated, but the minimum configuration will not support
  149. LAPB. The LAPB LCP Negotiation Option will have the following format:
  150.  
  151.  
  152.      LCP Option
  153.      Length
  154.      Window
  155.  
  156.  
  157.  
  158. Compression Control Protocol Negotiation Option
  159.  
  160. There will be one option number per compression algorithm, with a
  161. special one for proprietary algorithms.  They will be listed in the
  162. order of preference, and the sender's preferences will be respected in
  163. each direction, as the most effort is in the compression of the frame.
  164. The general format of these is:
  165.  
  166.  
  167.      COMPRESSION CONTROL PROTOCOL Option
  168.      Length
  169.      Parameters as required by the algorithm
  170.  
  171.  
  172.  
  173. The proprietary protocol option will have the vendors IEEE 802
  174. Organizational Unit Identifier as the first three octets of the
  175. parameter field.  It is recommended that vendors use the fourth octet as
  176. a version number.  This allows a vendor to use a proprietary algorithm
  177. among its own equipment without revealing its intellectual property to
  178. the IANA. Note that this option may occur more than once---a vendor may
  179. support multiple versions of its own algorithm, or may support several
  180. vendors algorithms.  The procedures defined in the PPP LCP for handling
  181. multiple instances of the same option apply in this case.
  182.  
  183.  
  184. Attendees
  185.  
  186. Steve Alexander          stevea@lachman.com
  187. Arun Arunkumar           nak@3com.com
  188. Fred Baker               fbaker@acc.com
  189. Per Bilse                bilse@ic.dk
  190. Carsten Bormann          cabo@cs.tu-berlin.de
  191. Caralyn Brown            cbrown@wellfleet.com
  192. Steve Buchko             stevebu@newbridge.com
  193. George Clapp             clapp@ameris.center.il.ameritech.com
  194. Thomas Cordetti          tomc@digibd.com
  195. Bob Downs                bdowns@combinet.com
  196. Ian Duncan               id@cc.mcgill.ca
  197. Shoji Fukutomi           fuku@furukawa.co.jp
  198. Jari Hamalainen          jah@rctre.nokia.com
  199. Dave Langley             davel@hprnd.hp.com
  200. Gerry Meyer              gerry@spider.co.uk
  201. William Miskovetz        misko@cisco.com
  202. Drew Perkins             ddp@fore.com
  203. Lars Poulsen             lars@cmc.com
  204. Dave Rand                dave_rand@novell.com
  205. Benny Rodrig             brodrig@rnd-gate.rad.co.il
  206. William Simpson          Bill.Simpson@um.cc.umich.edu
  207. Keith Sklower            sklower@cs.berkeley.edu
  208. Scott Wasson             sgwasson@eng.xyplex.com
  209. James Watt               james@newbridge.com
  210.