One document matched: draft-ietf-pppext-framerelay-ds-01.txt
Differences from draft-ietf-pppext-framerelay-ds-00.txt
Network Working Group W A Simpson [DayDreamer]
Internet Draft
expires in six months August 1998
PPP in Frame Relay
draft-ietf-pppext-framerelay-ds-01.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 (1993-1994, 1996-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 Frame Relay for framing
PPP encapsulated packets.
Simpson expires in six months [Page i]
DRAFT PPP in Frame Relay August 1998
Applicability
This specification is intended for those implementations that desire
to use facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and com-
pression. These capabilities require a point-to-point relationship
between peers, and are not designed for multi-point or multi-access
environments.
Simpson expires in six months [Page ii]
DRAFT PPP in Frame Relay August 1998
1. Introduction
Frame Relay [Q.922] is a relative newcomer to the serial link commu-
nity. Like X.25, the protocol was designed to provide virtual cir-
cuits for connections between stations attached to the same Frame
Relay network. The improvement over X.25 is that Q.922 is restricted
to delivery of packets, and dispenses with sequencing and flow con-
trol, simplifying the service immensely.
At one time, it had been hoped that "PPP in HDLC-like Framing"
[RFC-1662] would co-exist with other Frame Relay transmissions on the
same links. Unfortunately, the Q.922 method for expanding the
address from 1 to 2 to 4 octets is not reliably distinguishable from
the ISO 3309 HDLC method, due to the structure of its Data Link Con-
nection Identifier (DLCI) subfields. Co-existance is precluded.
When Frame Relay is configured as a point-to-point circuit, PPP can
use Frame Relay as a framing mechanism, ignoring its other features.
This is equivalent to the technique used to carry SNAP headers over
Frame Relay [RFC-1490].
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
PPP is capable of operating across most Frame Relay interfaces. 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.
Simpson expires in six months [Page 1]
DRAFT PPP in Frame Relay August 1998
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 Frame Relay interface.
Control Signals
Implementation of Frame Relay requires the provision of control
signals, that indicate when the link has become connected or dis-
connected. These in turn provide the Up and Down events to the
PPP LCP state machine.
Because PPP does not normally require the use of control signals,
the failure of such signals MUST NOT affect correct operation of
PPP. 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 specifica-
tion.
While PPP will operate without regard to the underlying representa-
tion of the octet stream, bit-synchronous Frame Relay requires NRZ
encoding.
In addition, this specification permits octet-synchronous Frame
Relay, with the same stuffing conventions as HDLC [RFC-1662].
3. The Data Link Layer
This specification uses the principles, terminology, and frame struc-
ture described in [RFC-1490].
The purpose of this specification is not to document what is already
standardized in [RFC-1490]. Instead, this document attempts to give
a concise summary and point out specific options and features used by
PPP.
Simpson expires in six months [Page 2]
DRAFT PPP in Frame Relay August 1998
3.1. Frame Header
As described in [RFC-1490], Q.922 header address and control fields
are followed by a Network Layer Protocol Identifier (NLPID) to iden-
tify the encapsulated packet. This specification describes the PPP
Protocol encapsulation. These fields are transmitted from left to
right.
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address | Control | NLPID(0xcf) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and Padding
fields are described in the Point-to-Point Protocol Encapsulation
[RFC-1661].
3.2. Modification of the Basic Frame
The Link Control Protocol can negotiate modifications to the basic
frame structure. This is not compatible with Frame Relay.
Address-and-Control-Field-Compression
Since Frame Relay Address and Control field values are not con-
stant, are variable size, and are modified as the frame is trans-
ported by the network switching fabric, Address-and-Control-Field-
Compression cannot affect the frame format.
FCS-Alternatives
Since Frame Relay requires a 16-bit FCS, which is modified as the
frame is transported by the network switching fabric, FCS-
Alternatives cannot affect the frame format.
In general, framing-related LCP Configuration Options are not recog-
nizable, and are not acceptable for negotiation. The implementation
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.
Simpson expires in six months [Page 3]
DRAFT PPP in Frame Relay August 1998
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 default Frame Relay header does not align the PPP Information
field on a 32-bit boundary. Alignment to a 32-bit boundary occurs
when the NLPID is removed and the PPP Protocol field is compressed
to a single octet. When this improves throughput, Protocol-Field-
Compression SHOULD be negotiated.
4. In-Band Protocol Demultiplexing
The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
PPP encapsulation from the other NLPID encapsulations described in
[RFC-1490].
The joining of the PPP and NLPID number space has an added advantage,
in that the LCP Protocol-Reject can be used to indicate NLPIDs that
are not recognized. This can eliminate "black-holes" that occur when
traffic is not supported.
For those network-layer protocols that have no PPP Protocol assign-
ment, or have not yet been implemented under the PPP encapsulation,
or have not been successfully negotiated by a PPP NCP, another method
of encapsulation defined under [RFC-1490] SHOULD be used.
Currently, there are no conflicts between NLPID and PPP Protocol val-
ues. If a future implementation is configured to send a NLPID value
which is the same as a compressed Protocol field, that Protocol field
MUST NOT be sent compressed.
On reception, the first octet following the Control field is exam-
ined:
- If the octet is zero, it MUST be assumed that the packet is for-
matted according to [RFC-1490].
- Initial LCP packets contain the sequence cf-c0-21 following the
Control field. When a LCP Configure-Request packet is received
and recognized, the PPP link enters Link Establishment phase.
- If the octet is not the PPP NLPID value, and Protocol-Field-
Compression is enabled, and the associated NCP has been negoti-
ated, then it is expected to be a compressed PPP Protocol value.
Simpson expires in six months [Page 4]
DRAFT PPP in Frame Relay August 1998
- Otherwise, it MUST be assumed that the packet is formatted accord-
ing to [RFC-1490].
Once PPP has entered the Link Establishment phase, packets with other
NLPID values MUST NOT be sent, and on receipt such packets MUST be
silently discarded, until the PPP link enters the Network-Layer Pro-
tocol phase.
Once PPP has entered the Network-Layer Protocol phase, and success-
fully negotiated a particular NCP for a PPP Protocol, if a frame
arrives using another equivalent data encapsulation defined in
[RFC-1490], the PPP Link MUST re-enter Link Establishment phase and
send a new LCP Configure-Request. This prevents "black-holes" that
occur when the peer loses state.
An implementation that requires PPP link configuration, and other PPP
negotiated features (such as authentication), MAY enter Termination
phase when configuration fails. Otherwise, when the Configure-
Request sender reaches the Max-Configure limit, it MUST fall back to
send only frames encapsulated according to [RFC-1490].
Implementation Notes
The PPP Protocol field value 0x00cf is not allowed (reserved) to
avoid ambiguity when Protocol-Field-Compression is enabled. For
consistency, the NLPID value 0xcf MAY be treated as a compressed
PPP Protocol which indicates that another PPP Protocol packet fol-
lows.
The accidental connection of a link to feed a multipoint network
(or multicast group) SHOULD result in a misconfiguration indica-
tion. This can be detected by multiple responses to the LCP Con-
figure-Request with the same Identifier, coming from different
framing addresses. Some implementations might be physically
unable to either log or report such information.
5. Out-of-Band signaling
There is no generally agreed method of out-of-band signalling. Until
such a method is universally available, an implementation MUST use
In-Band Protocol Demultiplexing for both Permanent and Switched Vir-
tual Circuits.
Simpson expires in six months [Page 5]
DRAFT PPP in Frame Relay August 1998
6. Configuration Details
The following Configuration Options are recommended:
Magic Number
Protocol Field Compression
The standard LCP configuration defaults apply to Frame Relay links,
except Maximum-Receive-Unit (MRU).
To ensure interoperability with existing Frame Relay implementations,
the initial MRU is 1600 octets [RFC-1490]. This only affects the
minimum required buffer space available for receiving packets, not
the size of packets sent.
The typical network feeding the link is likely to have a MRU of
either 1500, or 2048 or greater. To avoid fragmentation, the Maxi-
mum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed
1500, unless a peer MRU of 2048 or greater is specifically negoti-
ated.
Some Frame Relay switches are only capable of 262 octet frames. It
is not recommended that anyone deploy or use a switch that is capable
of less than 1600 octet frames. However, PPP implementations MUST be
configurable to limit the size of LCP packets that are sent to 259
octets (leaving room for the NLPID and PPP Protocol fields), until
LCP negotiation is complete.
XID negotiation is not required to be supported for links that are
capable of PPP negotiation.
Inverse ARP is not required to be supported for PPP links. That
function is provided by PPP NCP negotiation.
Security Considerations
This specification introduces no known security vulnerabilities.
Simpson expires in six months [Page 6]
DRAFT PPP in Frame Relay August 1998
Acknowledgements
This design was inspired by the paper "Parameter Negotiation for the
Multiprotocol Interconnect", Keith Sklower and Clifford Frost, Uni-
versity of California, Berkeley, 1992, unpublished.
Use of octet-synchronous interfaces, such as SONET/SDH, was first
proposed by John Bartell (BellSouth).
References
[Q.922] CCITT Recommendation Q.922, "ISDN Data Link Layer Speci-
fication for Frame Mode Bearer Services", International
Telegraph and Telephone Consultative Committee, 1992.
[RFC-1490] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", July 1993.
[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 7]
DRAFT PPP in Frame Relay 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)
Full Copyright Statement
Copyright (C) William Allen Simpson (1993-1994, 1996-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 doc-
ument 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 8]
| PAFTECH AB 2003-2026 | 2026-04-22 14:47:56 |