Network Working Group W A Simpson [DayDreamer]
Internet Draft
expires in six months August 1998
PPP in Ether-like Framing
draft-ietf-pppext-ether-00.txt
Status of this Memo
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as refer-
ence material, or to cite them other than as a ``working draft'' or
``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Northern Europe)
ftp.nis.garr.it (Southern Europe)
ftp.ietf.org (Eastern USA)
ftp.isi.edu (Western USA)
munnari.oz.au (Pacific Rim)
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) William Allen Simpson (1998). All Rights Reserved.
Abstract
The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. This document describes the use of ethernet-like framing for
PPP encapsulated packets.
Simpson expires in six months [Page i]
DRAFT PPP in Ethernet-like Framing August 1998
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.
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 Ethernet 32-bit Frame Check Sequence for error
detection. This is commonly available in hardware implementations,
and a software implementation is provided in [RFC-1662].
1.1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC-2119].
To remain consistent with standard Internet practice, and avoid con-
fusion for people used to reading RFCs, all binary numbers in the
following descriptions are in Most Significant Bit to Least Signifi-
cant Bit order, from Most Significant Byte to Least Significant Byte,
reading from left to right, unless otherwise indicated. Note that
this is contrary to ISO and ITU practice, which orders bits as trans-
mitted (network bit order). Keep this in mind when comparing this
document with the other documents.
2. Physical Layer Requirements
The only absolute requirement imposed by PPP is the provision of a
bi-directional full-duplex circuit, either dedicated (permanent) or
frame-switched, that can operate in either a 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.
Simpson expires in six months [Page 1]
DRAFT PPP in Ethernet-like Framing August 1998
Control Signals
PPP does not require the use of control signals. When available,
using such signals can allow greater functionality and perfor-
mance. Implications are discussed in [RFC-1662].
2.1. Transmission Considerations
The definition of various encodings is the responsibility of the
DTE/DCE equipment in use, and is outside the scope of this speci-
fication.
3. The Data Link Layer
This specification uses the principles, terminology, and frame
structure described in [IEEE-802?].
The purpose of this specification is not to document what is
already standardized in [IEEE-802?]. Instead, this document
attempts to give a concise summary and point out specific options
and features used by PPP.
3.1. Frame Header
This specification describes the PPP Protocol encapsulation.
These fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information* | Padding* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and Padding
fields are described in the Point-to-Point Protocol Encapsulation
[RFC-1661].
Simpson expires in six months [Page 2]
DRAFT PPP in Ethernet-like Framing August 1998
3.2. Modification of the Basic Frame
The Link Control Protocol can negotiate modifications to the basic
frame structure. This is not compatible with ethernet-like fram-
ing.
Address-and-Control-Field-Compression
Since the Address and Control fields are not present, Address-
and-Control-Field-Compression cannot affect the frame format.
FCS-Alternatives
Since ethernet-like framing requires a 32-bit FCS, FCS-
Alternatives cannot affect the frame format.
In general, framing-related LCP Configuration Options are not rec-
ognizable, and are not acceptable for negotiation. The implemen-
tation MUST NOT send ineffectual options in a Configure-Request,
and SHOULD respond to such requested options with a Configure-
Reject. See [RFC-ffff] for details.
3.3. Modification of the Basic Packet
The Link Control Protocol can negotiate modifications to the basic
packet structure. These are transparent to Frame Relay.
Protocol-Field-Compression
The fixed header aligns the PPP Information field on a 32-bit
boundary. The implementation MUST respond with a Configure-
Reject.
Self-Describing-Padding
Negotiation of Self-Describing-Padding to a 4-byte multiple is
required.
4. Configuration Details
The standard LCP configuration defaults apply to ethernet-like
framing, except that 32-bit FCS is assumed (instead of 16-bit
FCS).
The following Configuration Options are recommended:
Simpson expires in six months [Page 3]
DRAFT PPP in Ethernet-like Framing August 1998
Magic Number
No Address and Control Field Compression
No Protocol Field Compression
Link Quality Monitoring
Self Describing Padding
Security Considerations
This specification introduces no known security vulnerabilities.
Acknowledgements
PPP using a simple non-HDLC framing was first proposed by Peter
Lothberg (Sprint).
References
[RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol
(PPP)", STD-51, DayDreamer, July 1994.
[RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing",
STD-51, DayDreamer, July 1994.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP-14, Harvard University, March
1997.
[RFC-ffff] Simpson, W., "PPP with Framing Conversion", work in
progress.
Simpson expires in six months [Page 4]
DRAFT PPP in Ethernet-like Framing August 1998
Contacts
Comments about this document should be discussed on the ietf-
ppp@merit.edu mailing list.
This document was reviewed by the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the current chair:
Karl Fox
Ascend Communications
655 Metro Place South, Suite 370
Dublin, Ohio 43017
karl@Ascend.com
Questions about this document can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Simpson expires in six months [Page 5]
DRAFT PPP in Ethernet-like Framing August 1998
Full Copyright Statement
Copyright (C) William Allen Simpson (1998). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, except as required to translate it into languages other than
English.
This document and the information contained herein is provided on
an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE.
Simpson expires in six months [Page 6]
