CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT) PPP Extensions for Bridging o New Features - Section 6.1, Canonical MAC Type for FDDI. This was added in response to requests from several vendors for it. There are significant compatibility concerns; for this reason, anyone implementing the canonical address MAC Type for FDDI MUST also implement the non- canonical format. - Section 6.2, Choice of Spanning Tree Protocol. The IBM Source Route Spanning Tree BPDU is defined, and an option will be implemented to negotiate the use of either *no* spanning tree, IEEE 802.1(d), IEEE 802.1(g), and/or IBM SR. Note that an 802 spanning tree and the IBM spanning tree can occur simultaneously on the line, and that 802.1(d) and 802.1(g) will use the same BPDU protocol identifier, as they are internally distinguishable. - Sections 6.4 and 6.5: additional language was added to help systems make an interoperable choice when differently configured. This does not resolve all configuration errors, so the existing behavior - Bridge Control Protocol closes on configuration failure - is still required in severe case. - Section 6.9 (New): MAC Address Specification. This allows the system to announce its own MAC Address or request the assignment of a MAC Address by its neighbor. o Advisory Information - Section 6.1 now recommends that the count field be zero and a self describing pad (defined in the PPP LCP Extensions) be used. - Section 6.6 will be updated to reflect that the use of multiple options of the same type did not work correctly in RFC 1171 but does in RFC 1331 and in the Draft Standard PPP LCP. The Draft Standard procedures should be used. - Section 6.8 currently specifies what is now essentially a proprietary protocol used by Network Systems. This fact will prevent the document from advancing to Draft Standard unless the feature is either better documented or marked historical. Fred Baker took the action to ask Network Systems for more documentation. o Miscellaneous Additional Edits The status as left by the Working Group is that Rich has additional updates to make, which will be discussed on the list. We believe at this point that the document will be able to advance to Draft Standard. PPP LCP RFC 1171 should be Historical. When updated, the current PPP LCP draft should go to Draft Standard. There were various minor edits, and the section on handling multiple instances of the same option in a configure NAK especially requires some word-smithing. PPP HDLC Framing The HDLC Framing draft is a direct extraction from the older PPP LCP document, and is ready for elevation to Draft Standard. PPP LCP Extensions The PPP LCP Extensions draft is recommended for consideration as a Proposed Standard. PPP Requirements This document will be reorganized and posted as an Informational RFC. PPP Compression A separate breakout meeting was held for the bulk of the work, and the slides from the two presentations that were given follow these minutes. They contain a lot of information. Algorithms Under Consideration Five candidate protocols are under active consideration: 1. Predictor -- Free, but poor compression ratio - implement with CRC 2. Gandalf FZA -- $20K without patent protection 3. V.42bis -- $20K one time 4. HP PPC -- About $20 one time with patent protection 5. STAC -- $5 per, royalty on software with patent protection, $40 on chip Although we wanted to, the PPPEXT Working Group does not recommend one of them for universal implementation. The reason is that the group cannot, under IETF rules and marketplace sense, require everyone to license code or silicon from a single vendor, and the one unencumbered algorithm we have found has significant (64K per link) memory requirements. We therefore only provide the means to negotiate them. Packet format for Predictor is: Address Control PPP Compression Data Protocol ID Original Frame Length (not compressed) Compressed Frame Frame CRC-16 (not compressed) The reason for the CRC-16 is to help detect frame loss (and resultant dictionary desynchronization) in the case where a reliable link is not in use. Reliable Link Negotiation How to implement without a reliable link: decompress. If a frame fails to correctly decompress, send a Compression Control Protocol Configure request on the link. o Reasons not to use a reliable link: - Would like to use the same algorithm on all WAN code - Links are generally reliable anyway - Unreliable links are perceived to be simpler o Reasons to use a reliable link: - Loss of buffers introduced problems - More graceful degradation in the presence of errors LAPB Negotiation Option LAPB will be negotiated, but the minimum configuration will not support LAPB. The LAPB LCP Negotiation Option will have the following format: LCP Option Length Window Compression Control Protocol Negotiation Option There will be one option number per compression algorithm, with a special one for proprietary algorithms. They will be listed in the order of preference, and the sender's preferences will be respected in each direction, as the most effort is in the compression of the frame. The general format of these is: COMPRESSION CONTROL PROTOCOL Option Length Parameters as required by the algorithm The proprietary protocol option will have the vendors IEEE 802 Organizational Unit Identifier as the first three octets of the parameter field. It is recommended that vendors use the fourth octet as a version number. This allows a vendor to use a proprietary algorithm among its own equipment without revealing its intellectual property to the IANA. Note that this option may occur more than once---a vendor may support multiple versions of its own algorithm, or may support several vendors algorithms. The procedures defined in the PPP LCP for handling multiple instances of the same option apply in this case. Attendees Steve Alexander stevea@lachman.com Arun Arunkumar nak@3com.com Fred Baker fbaker@acc.com Per Bilse bilse@ic.dk Carsten Bormann cabo@cs.tu-berlin.de Caralyn Brown cbrown@wellfleet.com Steve Buchko stevebu@newbridge.com George Clapp clapp@ameris.center.il.ameritech.com Thomas Cordetti tomc@digibd.com Bob Downs bdowns@combinet.com Ian Duncan id@cc.mcgill.ca Shoji Fukutomi fuku@furukawa.co.jp Jari Hamalainen jah@rctre.nokia.com Dave Langley davel@hprnd.hp.com Gerry Meyer gerry@spider.co.uk William Miskovetz misko@cisco.com Drew Perkins ddp@fore.com Lars Poulsen lars@cmc.com Dave Rand dave_rand@novell.com Benny Rodrig brodrig@rnd-gate.rad.co.il William Simpson Bill.Simpson@um.cc.umich.edu Keith Sklower sklower@cs.berkeley.edu Scott Wasson sgwasson@eng.xyplex.com James Watt james@newbridge.com