summaryrefslogtreecommitdiff
path: root/rfc/rfc1662.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc1662.txt')
-rw-r--r--rfc/rfc1662.txt1436
1 files changed, 1436 insertions, 0 deletions
diff --git a/rfc/rfc1662.txt b/rfc/rfc1662.txt
new file mode 100644
index 0000000..5a5b214
--- /dev/null
+++ b/rfc/rfc1662.txt
@@ -0,0 +1,1436 @@
+
+
+
+
+
+
+
+Network Working Group W. Simpson, Editor
+Request for Comments: 1662 Daydreamer
+STD: 51 July 1994
+Obsoletes: 1549
+Category: Standards Track
+
+
+ PPP in HDLC-like Framing
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ This document describes the use of HDLC-like framing for PPP
+ encapsulated packets.
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+ 1.1 Specification of Requirements ................... 2
+ 1.2 Terminology ..................................... 2
+
+ 2. Physical Layer Requirements ........................... 3
+
+ 3. The Data Link Layer ................................... 4
+ 3.1 Frame Format .................................... 5
+ 3.2 Modification of the Basic Frame ................. 7
+
+ 4. Octet-stuffed framing ................................. 8
+ 4.1 Flag Sequence ................................... 8
+ 4.2 Transparency .................................... 8
+ 4.3 Invalid Frames .................................. 9
+ 4.4 Time Fill ....................................... 9
+ 4.4.1 Octet-synchronous ............................... 9
+ 4.4.2 Asynchronous .................................... 9
+ 4.5 Transmission Considerations ..................... 10
+ 4.5.1 Octet-synchronous ............................... 10
+ 4.5.2 Asynchronous .................................... 10
+
+
+Simpson [Page i]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 5. Bit-stuffed framing ................................... 11
+ 5.1 Flag Sequence ................................... 11
+ 5.2 Transparency .................................... 11
+ 5.3 Invalid Frames .................................. 11
+ 5.4 Time Fill ....................................... 11
+ 5.5 Transmission Considerations ..................... 12
+
+ 6. Asynchronous to Synchronous Conversion ................ 13
+
+ 7. Additional LCP Configuration Options .................. 14
+ 7.1 Async-Control-Character-Map (ACCM) .............. 14
+
+ APPENDICES ................................................... 17
+ A. Recommended LCP Options ............................... 17
+ B. Automatic Recognition of PPP Frames ................... 17
+ C. Fast Frame Check Sequence (FCS) Implementation ........ 18
+ C.1 FCS table generator ............................. 18
+ C.2 16-bit FCS Computation Method ................... 19
+ C.3 32-bit FCS Computation Method ................... 21
+
+ SECURITY CONSIDERATIONS ...................................... 24
+ REFERENCES ................................................... 24
+ ACKNOWLEDGEMENTS ............................................. 25
+ CHAIR'S ADDRESS .............................................. 25
+ EDITOR'S ADDRESS ............................................. 25
+
+
+
+
+1. Introduction
+
+ This specification provides for framing over both bit-oriented and
+ octet-oriented synchronous links, and asynchronous links with 8 bits
+ of data and no parity. These links MUST be full-duplex, but MAY be
+ either dedicated or circuit-switched.
+
+ An escape mechanism is specified to allow control data such as
+ XON/XOFF to be transmitted transparently over the link, and to remove
+ spurious control data which may be injected into the link by
+ intervening hardware and software.
+
+ Some protocols expect error free transmission, and either provide
+ error detection only on a conditional basis, or do not provide it at
+ all. PPP uses the HDLC Frame Check Sequence for error detection.
+ This is commonly available in hardware implementations, and a
+ software implementation is provided.
+
+
+
+
+
+
+Simpson [Page 1]
+RFC 1662 HDLC-like Framing July 1994
+
+
+1.1. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized.
+
+ MUST This word, or the adjective "required", means that the
+ definition is an absolute requirement of the specification.
+
+ MUST NOT This phrase means that the definition is an absolute
+ prohibition of the specification.
+
+ SHOULD This word, or the adjective "recommended", means that there
+ may exist valid reasons in particular circumstances to
+ ignore this item, but the full implications must be
+ understood and carefully weighed before choosing a
+ different course.
+
+ MAY This word, or the adjective "optional", means that this
+ item is one of an allowed set of alternatives. An
+ implementation which does not include this option MUST be
+ prepared to interoperate with another implementation which
+ does include the option.
+
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+ datagram The unit of transmission in the network layer (such as IP).
+ A datagram may be encapsulated in one or more packets
+ passed to the data link layer.
+
+ frame The unit of transmission at the data link layer. A frame
+ may include a header and/or a trailer, along with some
+ number of units of data.
+
+ packet The basic unit of encapsulation, which is passed across the
+ interface between the network layer and the data link
+ layer. A packet is usually mapped to a frame; the
+ exceptions are when data link layer fragmentation is being
+ performed, or when multiple packets are incorporated into a
+ single frame.
+
+ peer The other end of the point-to-point link.
+
+ silently discard
+ The implementation discards the packet without further
+ processing. The implementation SHOULD provide the
+ capability of logging the error, including the contents of
+ the silently discarded packet, and SHOULD record the event
+ in a statistics counter.
+
+
+Simpson [Page 2]
+RFC 1662 HDLC-like Framing July 1994
+
+
+2. Physical Layer Requirements
+
+ PPP is capable of operating across most DTE/DCE interfaces (such as,
+ EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute
+ requirement imposed by PPP is the provision of a full-duplex circuit,
+ either dedicated or circuit-switched, which can operate in either an
+ asynchronous (start/stop), bit-synchronous, or octet-synchronous
+ mode, transparent to PPP Data Link Layer frames.
+
+ Interface Format
+
+ PPP presents an octet interface to the physical layer. There is
+ no provision for sub-octets to be supplied or accepted.
+
+ Transmission Rate
+
+ PPP does not impose any restrictions regarding transmission rate,
+ other than that of the particular DTE/DCE interface.
+
+ Control Signals
+
+ PPP does not require the use of control signals, such as Request
+ To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
+ Data Terminal Ready (DTR).
+
+ When available, using such signals can allow greater functionality
+ and performance. In particular, such signals SHOULD be used to
+ signal the Up and Down events in the LCP Option Negotiation
+ Automaton [1]. When such signals are not available, the
+ implementation MUST signal the Up event to LCP upon
+ initialization, and SHOULD NOT signal the Down event.
+
+ Because signalling is not required, the physical layer MAY be
+ decoupled from the data link layer, hiding the transient details
+ of the physical transport. This has implications for mobility in
+ cellular radio networks, and other rapidly switching links.
+
+ When moving from cell to cell within the same zone, an
+ implementation MAY choose to treat the entire zone as a single
+ link, even though transmission is switched among several
+ frequencies. The link is considered to be with the central
+ control unit for the zone, rather than the individual cell
+ transceivers. However, the link SHOULD re-establish its
+ configuration whenever the link is switched to a different
+ administration.
+
+ Due to the bursty nature of data traffic, some implementations
+ have choosen to disconnect the physical layer during periods of
+
+
+
+Simpson [Page 3]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ inactivity, and reconnect when traffic resumes, without informing
+ the data link layer. Robust implementations should avoid using
+ this trick over-zealously, since the price for decreased setup
+ latency is decreased security. Implementations SHOULD signal the
+ Down event whenever "significant time" has elapsed since the link
+ was disconnected. The value for "significant time" is a matter of
+ considerable debate, and is based on the tariffs, call setup
+ times, and security concerns of the installation.
+
+
+
+3. The Data Link Layer
+
+ PPP uses the principles described in ISO 3309-1979 HDLC frame
+ structure, most recently the fourth edition 3309:1991 [2], which
+ specifies modifications to allow HDLC use in asynchronous
+ environments.
+
+ The PPP control procedures use the Control field encodings described
+ in ISO 4335-1979 HDLC elements of procedures, most recently the
+ fourth edition 4335:1991 [4].
+
+ This should not be construed to indicate that every feature of the
+ above recommendations are included in PPP. Each feature included
+ is explicitly described in the following sections.
+
+ To remain consistent with standard Internet practice, and avoid
+ confusion for people used to reading RFCs, all binary numbers in the
+ following descriptions are in Most Significant Bit to Least
+ Significant Bit order, reading from left to right, unless otherwise
+ indicated. Note that this is contrary to standard ISO and CCITT
+ practice which orders bits as transmitted (network bit order). Keep
+ this in mind when comparing this document with the international
+ standards documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 4]
+RFC 1662 HDLC-like Framing July 1994
+
+
+3.1. Frame Format
+
+ A summary of the PPP HDLC-like frame structure is shown below. This
+ figure does not include bits inserted for synchronization (such as
+ start and stop bits for asynchronous links), nor any bits or octets
+ inserted for transparency. The fields are transmitted from left to
+ right.
+
+ +----------+----------+----------+
+ | Flag | Address | Control |
+ | 01111110 | 11111111 | 00000011 |
+ +----------+----------+----------+
+ +----------+-------------+---------+
+ | Protocol | Information | Padding |
+ | 8/16 bits| * | * |
+ +----------+-------------+---------+
+ +----------+----------+-----------------
+ | FCS | Flag | Inter-frame Fill
+ |16/32 bits| 01111110 | or next Address
+ +----------+----------+-----------------
+
+ The Protocol, Information and Padding fields are described in the
+ Point-to-Point Protocol Encapsulation [1].
+
+ Flag Sequence
+
+ Each frame begins and ends with a Flag Sequence, which is the
+ binary sequence 01111110 (hexadecimal 0x7e). All implementations
+ continuously check for this flag, which is used for frame
+ synchronization.
+
+ Only one Flag Sequence is required between two frames. Two
+ consecutive Flag Sequences constitute an empty frame, which is
+ silently discarded, and not counted as a FCS error.
+
+ Address Field
+
+ The Address field is a single octet, which contains the binary
+ sequence 11111111 (hexadecimal 0xff), the All-Stations address.
+ Individual station addresses are not assigned. The All-Stations
+ address MUST always be recognized and received.
+
+ The use of other address lengths and values may be defined at a
+ later time, or by prior agreement. Frames with unrecognized
+ Addresses SHOULD be silently discarded.
+
+
+
+
+
+
+Simpson [Page 5]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Control Field
+
+ The Control field is a single octet, which contains the binary
+ sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
+ (UI) command with the Poll/Final (P/F) bit set to zero.
+
+ The use of other Control field values may be defined at a later
+ time, or by prior agreement. Frames with unrecognized Control
+ field values SHOULD be silently discarded.
+
+ Frame Check Sequence (FCS) Field
+
+ The Frame Check Sequence field defaults to 16 bits (two octets).
+ The FCS is transmitted least significant octet first, which
+ contains the coefficient of the highest term.
+
+ A 32-bit (four octet) FCS is also defined. Its use may be
+ negotiated as described in "PPP LCP Extensions" [5].
+
+ The use of other FCS lengths may be defined at a later time, or by
+ prior agreement.
+
+ The FCS field is calculated over all bits of the Address, Control,
+ Protocol, Information and Padding fields, not including any start
+ and stop bits (asynchronous) nor any bits (synchronous) or octets
+ (asynchronous or synchronous) inserted for transparency. This
+ also does not include the Flag Sequences nor the FCS field itself.
+
+ When octets are received which are flagged in the Async-
+ Control-Character-Map, they are discarded before calculating
+ the FCS.
+
+ For more information on the specification of the FCS, see the
+ Appendices.
+
+ The end of the Information and Padding fields is found by locating
+ the closing Flag Sequence and removing the Frame Check Sequence
+ field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 6]
+RFC 1662 HDLC-like Framing July 1994
+
+
+3.2. Modification of the Basic Frame
+
+ The Link Control Protocol can negotiate modifications to the standard
+ HDLC-like frame structure. However, modified frames will always be
+ clearly distinguishable from standard frames.
+
+ Address-and-Control-Field-Compression
+
+ When using the standard HDLC-like framing, the Address and Control
+ fields contain the hexadecimal values 0xff and 0x03 respectively.
+ When other Address or Control field values are in use, Address-
+ and-Control-Field-Compression MUST NOT be negotiated.
+
+ On transmission, compressed Address and Control fields are simply
+ omitted.
+
+ On reception, the Address and Control fields are decompressed by
+ examining the first two octets. If they contain the values 0xff
+ and 0x03, they are assumed to be the Address and Control fields.
+ If not, it is assumed that the fields were compressed and were not
+ transmitted.
+
+ By definition, the first octet of a two octet Protocol field
+ will never be 0xff (since it is not even). The Protocol field
+ value 0x00ff is not allowed (reserved) to avoid ambiguity when
+ Protocol-Field-Compression is enabled and the first Information
+ field octet is 0x03.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 7]
+RFC 1662 HDLC-like Framing July 1994
+
+
+4. Octet-stuffed framing
+
+ This chapter summarizes the use of HDLC-like framing with 8-bit
+ asynchronous and octet-synchronous links.
+
+
+
+4.1. Flag Sequence
+
+ The Flag Sequence indicates the beginning or end of a frame. The
+ octet stream is examined on an octet-by-octet basis for the value
+ 01111110 (hexadecimal 0x7e).
+
+
+
+4.2. Transparency
+
+ An octet stuffing procedure is used. The Control Escape octet is
+ defined as binary 01111101 (hexadecimal 0x7d), most significant bit
+ first.
+
+ As a minimum, sending implementations MUST escape the Flag Sequence
+ and Control Escape octets.
+
+ After FCS computation, the transmitter examines the entire frame
+ between the two Flag Sequences. Each Flag Sequence, Control Escape
+ octet, and any octet which is flagged in the sending Async-Control-
+ Character-Map (ACCM), is replaced by a two octet sequence consisting
+ of the Control Escape octet followed by the original octet
+ exclusive-or'd with hexadecimal 0x20.
+
+ This is bit 5 complemented, where the bit positions are numbered
+ 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE
+ when comparing documents).
+
+ Receiving implementations MUST correctly process all Control Escape
+ sequences.
+
+ On reception, prior to FCS computation, each octet with value less
+ than hexadecimal 0x20 is checked. If it is flagged in the receiving
+ ACCM, it is simply removed (it may have been inserted by intervening
+ data communications equipment). Each Control Escape octet is also
+ removed, and the following octet is exclusive-or'd with hexadecimal
+ 0x20, unless it is the Flag Sequence (which aborts a frame).
+
+ A few examples may make this more clear. Escaped data is transmitted
+ on the link as follows:
+
+
+
+
+Simpson [Page 8]
+RFC 1662 HDLC-like Framing July 1994
+
+
+
+ 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence)
+ 0x7d is encoded as 0x7d, 0x5d. (Control Escape)
+ 0x03 is encoded as 0x7d, 0x23. (ETX)
+
+ Some modems with software flow control may intercept outgoing DC1 and
+ DC3 ignoring the 8th (parity) bit. This data would be transmitted on
+ the link as follows:
+
+ 0x11 is encoded as 0x7d, 0x31. (XON)
+ 0x13 is encoded as 0x7d, 0x33. (XOFF)
+ 0x91 is encoded as 0x7d, 0xb1. (XON with parity set)
+ 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set)
+
+
+
+
+4.3. Invalid Frames
+
+ Frames which are too short (less than 4 octets when using the 16-bit
+ FCS), or which end with a Control Escape octet followed immediately
+ by a closing Flag Sequence, or in which octet-framing is violated (by
+ transmitting a "0" stop bit where a "1" bit is expected), are
+ silently discarded, and not counted as a FCS error.
+
+
+
+4.4. Time Fill
+
+4.4.1. Octet-synchronous
+
+ There is no provision for inter-octet time fill.
+
+ The Flag Sequence MUST be transmitted during inter-frame time fill.
+
+
+4.4.2. Asynchronous
+
+ Inter-octet time fill MUST be accomplished by transmitting continuous
+ "1" bits (mark-hold state).
+
+ Inter-frame time fill can be viewed as extended inter-octet time
+ fill. Doing so can save one octet for every frame, decreasing delay
+ and increasing bandwidth. This is possible since a Flag Sequence may
+ serve as both a frame end and a frame begin. After having received
+ any frame, an idle receiver will always be in a frame begin state.
+
+
+
+
+Simpson [Page 9]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Robust transmitters should avoid using this trick over-zealously,
+ since the price for decreased delay is decreased reliability. Noisy
+ links may cause the receiver to receive garbage characters and
+ interpret them as part of an incoming frame. If the transmitter does
+ not send a new opening Flag Sequence before sending the next frame,
+ then that frame will be appended to the noise characters causing an
+ invalid frame (with high reliability).
+
+ It is suggested that implementations will achieve the best results by
+ always sending an opening Flag Sequence if the new frame is not
+ back-to-back with the last. Transmitters SHOULD send an open Flag
+ Sequence whenever "appreciable time" has elapsed after the prior
+ closing Flag Sequence. The maximum value for "appreciable time" is
+ likely to be no greater than the typing rate of a slow typist, about
+ 1 second.
+
+
+
+4.5. Transmission Considerations
+
+4.5.1. Octet-synchronous
+
+ The definition of various encodings and scrambling is the
+ responsibility of the DTE/DCE equipment in use, and is outside the
+ scope of this specification.
+
+
+4.5.2. Asynchronous
+
+ All octets are transmitted least significant bit first, with one
+ start bit, eight bits of data, and one stop bit. There is no
+ provision for seven bit asynchronous links.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 10]
+RFC 1662 HDLC-like Framing July 1994
+
+
+5. Bit-stuffed framing
+
+ This chapter summarizes the use of HDLC-like framing with bit-
+ synchronous links.
+
+
+
+5.1. Flag Sequence
+
+ The Flag Sequence indicates the beginning or end of a frame, and is
+ used for frame synchronization. The bit stream is examined on a
+ bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).
+
+ The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be
+ used. When not avoidable, such an implementation MUST ensure that
+ the first Flag Sequence detected (the end of the frame) is promptly
+ communicated to the link layer. Use of the shared zero mode hinders
+ interoperability with bit-synchronous to asynchronous and bit-
+ synchronous to octet-synchronous converters.
+
+
+
+5.2. Transparency
+
+ After FCS computation, the transmitter examines the entire frame
+ between the two Flag Sequences. A "0" bit is inserted after all
+ sequences of five contiguous "1" bits (including the last 5 bits of
+ the FCS) to ensure that a Flag Sequence is not simulated.
+
+ On reception, prior to FCS computation, any "0" bit that directly
+ follows five contiguous "1" bits is discarded.
+
+
+
+5.3. Invalid Frames
+
+ Frames which are too short (less than 4 octets when using the 16-bit
+ FCS), or which end with a sequence of more than six "1" bits, are
+ silently discarded, and not counted as a FCS error.
+
+
+
+5.4. Time Fill
+
+ There is no provision for inter-octet time fill.
+
+ The Flag Sequence SHOULD be transmitted during inter-frame time fill.
+ However, certain types of circuit-switched links require the use of
+
+
+
+Simpson [Page 11]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ mark idle (continuous ones), particularly those that calculate
+ accounting based on periods of bit activity. When mark idle is used
+ on a bit-synchronous link, the implementation MUST ensure at least 15
+ consecutive "1" bits between Flags during the idle period, and that
+ the Flag Sequence is always generated at the beginning of a frame
+ after an idle period.
+
+ This differs from practice in ISO 3309, which allows 7 to 14 bit
+ mark idle.
+
+
+
+5.5. Transmission Considerations
+
+ All octets are transmitted least significant bit first.
+
+ The definition of various encodings and scrambling is the
+ responsibility of the DTE/DCE equipment in use, and is outside the
+ scope of this specification.
+
+ While PPP will operate without regard to the underlying
+ representation of the bit stream, lack of standards for transmission
+ will hinder interoperability as surely as lack of data link
+ standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently
+ most widely available, and on that basis is recommended as a default.
+
+ When configuration of the encoding is allowed, NRZI is recommended as
+ an alternative, because of its relative immunity to signal inversion
+ configuration errors, and instances when it MAY allow connection
+ without an expensive DSU/CSU. Unfortunately, NRZI encoding
+ exacerbates the missing x1 factor of the 16-bit FCS, so that one
+ error in 2**15 goes undetected (instead of one in 2**16), and triple
+ errors are not detected. Therefore, when NRZI is in use, it is
+ recommended that the 32-bit FCS be negotiated, which includes the x1
+ factor.
+
+ At higher speeds of up to 45 Mbps, some implementors have chosen the
+ ANSI High Speed Synchronous Interface [HSSI]. While this experience
+ is currently limited, implementors are encouraged to cooperate in
+ choosing transmission encoding.
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 12]
+RFC 1662 HDLC-like Framing July 1994
+
+
+6. Asynchronous to Synchronous Conversion
+
+ There may be some use of asynchronous-to-synchronous converters (some
+ built into modems and cellular interfaces), resulting in an
+ asynchronous PPP implementation on one end of a link and a
+ synchronous implementation on the other. It is the responsibility of
+ the converter to do all stuffing conversions during operation.
+
+ To enable this functionality, synchronous PPP implementations MUST
+ always respond to the Async-Control-Character-Map Configuration
+ Option with the LCP Configure-Ack. However, acceptance of the
+ Configuration Option does not imply that the synchronous
+ implementation will do any ACCM mapping. Instead, all such octet
+ mapping will be performed by the asynchronous-to-synchronous
+ converter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 13]
+RFC 1662 HDLC-like Framing July 1994
+
+
+7. Additional LCP Configuration Options
+
+ The Configuration Option format and basic options are already defined
+ for LCP [1].
+
+ Up-to-date values of the LCP Option Type field are specified in the
+ most recent "Assigned Numbers" RFC [10]. This document concerns the
+ following values:
+
+ 2 Async-Control-Character-Map
+
+
+
+
+7.1. Async-Control-Character-Map (ACCM)
+
+ Description
+
+ This Configuration Option provides a method to negotiate the use
+ of control character transparency on asynchronous links.
+
+ Each end of the asynchronous link maintains two Async-Control-
+ Character-Maps. The receiving ACCM is 32 bits, but the sending
+ ACCM may be up to 256 bits. This results in four distinct ACCMs,
+ two in each direction of the link.
+
+ For asynchronous links, the default receiving ACCM is 0xffffffff.
+ The default sending ACCM is 0xffffffff, plus the Control Escape
+ and Flag Sequence characters themselves, plus whatever other
+ outgoing characters are flagged (by prior configuration) as likely
+ to be intercepted.
+
+ For other types of links, the default value is 0, since there is
+ no need for mapping.
+
+ The default inclusion of all octets less than hexadecimal 0x20
+ allows all ASCII control characters [6] excluding DEL (Delete)
+ to be transparently communicated through all known data
+ communications equipment.
+
+ The transmitter MAY also send octets with values in the range 0x40
+ through 0xff (except 0x5e) in Control Escape format. Since these
+ octet values are not negotiable, this does not solve the problem
+ of receivers which cannot handle all non-control characters.
+ Also, since the technique does not affect the 8th bit, this does
+ not solve problems for communications links that can send only 7-
+ bit characters.
+
+
+
+
+Simpson [Page 14]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ Note that this specification differs in detail from later
+ amendments, such as 3309:1991/Amendment 2 [3]. However, such
+ "extended transparency" is applied only by "prior agreement".
+ Use of the transparency methods in this specification
+ constitute a prior agreement with respect to PPP.
+
+ For compatibility with 3309:1991/Amendment 2, the transmitter
+ MAY escape DEL and ACCM equivalents with the 8th (most
+ significant) bit set. No change is required in the receiving
+ algorithm.
+
+ Following ACCM negotiation, the transmitter SHOULD cease
+ escaping DEL.
+
+ However, it is rarely necessary to map all control characters, and
+ often it is unnecessary to map any control characters. The
+ Configuration Option is used to inform the peer which control
+ characters MUST remain mapped when the peer sends them.
+
+ The peer MAY still send any other octets in mapped format, if it
+ is necessary because of constraints known to the peer. The peer
+ SHOULD Configure-Nak with the logical union of the sets of mapped
+ octets, so that when such octets are spuriously introduced they
+ can be ignored on receipt.
+
+ A summary of the Async-Control-Character-Map Configuration Option
+ format is shown below. The fields are transmitted from left to
+ right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | ACCM
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ACCM (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 2
+
+ Length
+
+ 6
+
+
+
+
+
+
+Simpson [Page 15]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ ACCM
+
+ The ACCM field is four octets, and indicates the set of control
+ characters to be mapped. The map is sent most significant octet
+ first.
+
+ Each numbered bit corresponds to the octet of the same value. If
+ the bit is cleared to zero, then that octet need not be mapped.
+ If the bit is set to one, then that octet MUST remain mapped. For
+ example, if bit 19 is set to zero, then the ASCII control
+ character 19 (DC3, Control-S) MAY be sent in the clear.
+
+ Note: The least significant bit of the least significant octet
+ (the final octet transmitted) is numbered bit 0, and would map
+ to the ASCII control character NUL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 16]
+RFC 1662 HDLC-like Framing July 1994
+
+
+A. Recommended LCP Options
+
+ The following Configurations Options are recommended:
+
+ High Speed links
+
+ Magic Number
+ Link Quality Monitoring
+ No Address and Control Field Compression
+ No Protocol Field Compression
+
+
+ Low Speed or Asynchronous links
+
+ Async Control Character Map
+ Magic Number
+ Address and Control Field Compression
+ Protocol Field Compression
+
+
+
+B. Automatic Recognition of PPP Frames
+
+ It is sometimes desirable to detect PPP frames, for example during a
+ login sequence. The following octet sequences all begin valid PPP
+ LCP frames:
+
+ 7e ff 03 c0 21
+ 7e ff 7d 23 c0 21
+ 7e 7d df 7d 23 c0 21
+
+ Note that the first two forms are not a valid username for Unix.
+ However, only the third form generates a correctly checksummed PPP
+ frame, whenever 03 and ff are taken as the control characters ETX and
+ DEL without regard to parity (they are correct for an even parity
+ link) and discarded.
+
+ Many implementations deal with this by putting the interface into
+ packet mode when one of the above username patterns are detected
+ during login, without examining the initial PPP checksum. The
+ initial incoming PPP frame is discarded, but a Configure-Request is
+ sent immediately.
+
+
+
+
+
+
+
+
+
+Simpson [Page 17]
+RFC 1662 HDLC-like Framing July 1994
+
+
+C. Fast Frame Check Sequence (FCS) Implementation
+
+ The FCS was originally designed with hardware implementations in
+ mind. A serial bit stream is transmitted on the wire, the FCS is
+ calculated over the serial data as it goes out, and the complement of
+ the resulting FCS is appended to the serial stream, followed by the
+ Flag Sequence.
+
+ The receiver has no way of determining that it has finished
+ calculating the received FCS until it detects the Flag Sequence.
+ Therefore, the FCS was designed so that a particular pattern results
+ when the FCS operation passes over the complemented FCS. A good
+ frame is indicated by this "good FCS" value.
+
+
+
+C.1. FCS table generator
+
+ The following code creates the lookup table used to calculate the
+ FCS-16.
+
+ /*
+ * Generate a FCS-16 table.
+ *
+ * Drew D. Perkins at Carnegie Mellon University.
+ *
+ * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
+ */
+
+ /*
+ * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16.
+ */
+ #define P 0x8408
+
+
+ main()
+ {
+ register unsigned int b, v;
+ register int i;
+
+ printf("typedef unsigned short u16;\n");
+ printf("static u16 fcstab[256] = {");
+ for (b = 0; ; ) {
+ if (b % 8 == 0)
+ printf("\n");
+
+ v = b;
+ for (i = 8; i--; )
+
+
+
+Simpson [Page 18]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ v = v & 1 ? (v >> 1) ^ P : v >> 1;
+
+ printf("\t0x%04x", v & 0xFFFF);
+ if (++b == 256)
+ break;
+ printf(",");
+ }
+ printf("\n};\n");
+ }
+
+
+
+C.2. 16-bit FCS Computation Method
+
+ The following code provides a table lookup computation for
+ calculating the Frame Check Sequence as data arrives at the
+ interface. This implementation is based on [7], [8], and [9].
+
+ /*
+ * u16 represents an unsigned 16-bit number. Adjust the typedef for
+ * your hardware.
+ */
+ typedef unsigned short u16;
+
+ /*
+ * FCS lookup table as calculated by the table generator.
+ */
+ static u16 fcstab[256] = {
+ 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
+ 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
+ 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
+ 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
+ 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
+ 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
+ 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
+ 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
+ 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
+ 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
+ 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
+ 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
+ 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
+ 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
+ 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
+ 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
+ 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
+ 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
+ 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
+ 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
+
+
+
+Simpson [Page 19]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
+ 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
+ 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
+ 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
+ 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
+ 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
+ 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
+ 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
+ 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
+ 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
+ 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
+ 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
+ };
+
+ #define PPPINITFCS16 0xffff /* Initial FCS value */
+ #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */
+
+ /*
+ * Calculate a new fcs given the current fcs and the new data.
+ */
+ u16 pppfcs16(fcs, cp, len)
+ register u16 fcs;
+ register unsigned char *cp;
+ register int len;
+ {
+ ASSERT(sizeof (u16) == 2);
+ ASSERT(((u16) -1) > 0);
+ while (len--)
+ fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
+
+ return (fcs);
+ }
+
+ /*
+ * How to use the fcs
+ */
+ tryfcs16(cp, len)
+ register unsigned char *cp;
+ register int len;
+ {
+ u16 trialfcs;
+
+ /* add on output */
+ trialfcs = pppfcs16( PPPINITFCS16, cp, len );
+ trialfcs ^= 0xffff; /* complement */
+ cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
+ cp[len+1] = ((trialfcs >> 8) & 0x00ff);
+
+
+
+
+Simpson [Page 20]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ /* check on input */
+ trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 );
+ if ( trialfcs == PPPGOODFCS16 )
+ printf("Good FCS\n");
+ }
+
+
+
+C.3. 32-bit FCS Computation Method
+
+ The following code provides a table lookup computation for
+ calculating the 32-bit Frame Check Sequence as data arrives at the
+ interface.
+
+ /*
+ * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5
+ * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16
+ * + x**22 + x**23 + x**26 + x**32.
+ */
+
+ /*
+ * u32 represents an unsigned 32-bit number. Adjust the typedef for
+ * your hardware.
+ */
+ typedef unsigned long u32;
+
+ static u32 fcstab_32[256] =
+ {
+ 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
+ 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
+ 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
+ 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
+ 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+ 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
+ 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
+ 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
+ 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
+ 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+ 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
+ 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
+ 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
+ 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
+ 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+ 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
+ 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
+ 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
+ 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
+ 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+
+
+
+Simpson [Page 21]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
+ 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
+ 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
+ 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
+ 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+ 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
+ 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
+ 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
+ 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
+ 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+ 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
+ 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
+ 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
+ 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
+ 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+ 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
+ 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
+ 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
+ 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
+ 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+ 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
+ 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
+ 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
+ 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
+ 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+ 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
+ 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
+ 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
+ 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
+ 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
+ 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
+ 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
+ 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
+ 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
+ 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
+ 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
+ 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
+ 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
+ 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
+ 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
+ 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
+ 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
+ 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
+ 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
+ };
+
+ #define PPPINITFCS32 0xffffffff /* Initial FCS value */
+ #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */
+
+
+
+Simpson [Page 22]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ /*
+ * Calculate a new FCS given the current FCS and the new data.
+ */
+ u32 pppfcs32(fcs, cp, len)
+ register u32 fcs;
+ register unsigned char *cp;
+ register int len;
+ {
+ ASSERT(sizeof (u32) == 4);
+ ASSERT(((u32) -1) > 0);
+ while (len--)
+ fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
+
+ return (fcs);
+ }
+
+ /*
+ * How to use the fcs
+ */
+ tryfcs32(cp, len)
+ register unsigned char *cp;
+ register int len;
+ {
+ u32 trialfcs;
+
+ /* add on output */
+ trialfcs = pppfcs32( PPPINITFCS32, cp, len );
+ trialfcs ^= 0xffffffff; /* complement */
+ cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
+ cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
+ cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
+ cp[len+3] = ((trialfcs >> 8) & 0x00ff);
+
+ /* check on input */
+ trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
+ if ( trialfcs == PPPGOODFCS32 )
+ printf("Good FCS\n");
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 23]
+RFC 1662 HDLC-like Framing July 1994
+
+
+Security Considerations
+
+ As noted in the Physical Layer Requirements section, the link layer
+ might not be informed when the connected state of the physical layer
+ has changed. This results in possible security lapses due to over-
+ reliance on the integrity and security of switching systems and
+ administrations. An insertion attack might be undetected. An
+ attacker which is able to spoof the same calling identity might be
+ able to avoid link authentication.
+
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
+ STD 50, RFC 1661, Daydreamer, July 1994.
+
+ [2] ISO/IEC 3309:1991(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Frame
+ structure", International Organization For Standardization,
+ Fourth edition 1991-06-01.
+
+ [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Frame
+ structure - Amendment 2: Extended transparency options for
+ start/stop transmission", International Organization For
+ Standardization, 1992-01-15.
+
+ [4] ISO/IEC 4335:1991(E), "Information Technology -
+ Telecommunications and information exchange between systems -
+ High-level data link control (HDLC) procedures - Elements of
+ procedures", International Organization For Standardization,
+ Fourth edition 1991-09-15.
+
+ [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
+ Daydreamer, January 1994.
+
+ [6] ANSI X3.4-1977, "American National Standard Code for
+ Information Interchange", American National Standards
+ Institute, 1977.
+
+ [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
+
+ [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
+ September 1986.
+
+
+
+
+Simpson [Page 24]
+RFC 1662 HDLC-like Framing July 1994
+
+
+ [9] LeVan, J., "A Fast CRC", Byte, November 1987.
+
+ [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+
+
+Acknowledgements
+
+ This document is the product of the Point-to-Point Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ietf-ppp@merit.edu mailing list.
+
+ This specification is based on previous RFCs, where many
+ contributions have been acknowleged.
+
+ The 32-bit FCS example code was provided by Karl Fox (Morning Star
+ Technologies).
+
+ Special thanks to Morning Star Technologies for providing computing
+ resources and network access support for writing this specification.
+
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Advanced Computer Communications
+ 315 Bollay Drive
+ Santa Barbara, California 93117
+
+ fbaker@acc.com
+
+
+Editor's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ Bill.Simpson@um.cc.umich.edu
+ bsimpson@MorningStar.com
+
+
+Simpson [Page 25]
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-17 04:25:22 +0000