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