As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group W.
Request for Comments: 1973
Category: Standards Track June 1996
PPP in Frame
Status of this
This document specifies an Internet standards track protocol
the Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
This document describes the use of Frame Relay for framing
encapsulated packets
This specification is intended for those implementations which
to use facilities which are defined for PPP, such as the Link
Simpson Standards Track [Page i
RFC 1973 PPP in Frame Relay June 1996
Protocol, Network-layer Control Protocols, authentication,
compression. These capabilities require a point-to-
relationship between peers, and are not designed for multi-point
multi-access environments
Table of
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 1
3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 2
3.2 Modification of the Basic Frame ................. 3
4. In-Band Protocol Demultiplexing ....................... 4
5. Out-of-Band signaling ................................. 5
6. Configuration Details ................................. 5
SECURITY CONSIDERATIONS ...................................... 7
REFERENCES ................................................... 7
ACKNOWLEDGEMENTS ............................................. 7
CHAIR'S ADDRESS .............................................. 8
AUTHOR'S ADDRESS ............................................. 8
Simpson Standards Track [Page ii
RFC 1973 PPP in Frame Relay June 1996
1.
Frame Relay [2] is a relative newcomer to the serial link community
Like X.25, the protocol was designed to provide virtual circuits
connections between stations attached to the same Frame
network. The improvement over X.25 is that Q.922 is restricted
delivery of packets, and dispenses with sequencing and flow control
simplifying the service immensely
PPP uses ISO 3309 HDLC as a basis for its framing [3].
When Frame Relay is configured as a point-to-point circuit, PPP
use Frame Relay as a framing mechanism, ignoring its other features
This is equivalent to the technique used to carry SNAP headers
Frame Relay [4].
At one time, it had been hoped that PPP in HDLC-like frames and
Relay would co-exist on the same links. Unfortunately, the Q.922
method for expanding the address from 1 to 2 to 4 octets is
indistinguishable from the ISO 3309 method, due to the structure
its Data Link Connection Identifier (DLCI) subfields. Co-
is precluded
2. Physical Layer
PPP treats Frame Relay framing as a bit-synchronous link. The
MUST be full-duplex, but MAY be either dedicated (permanent)
switched
Interface
PPP presents an octet interface to the physical layer. There
no provision for sub-octets to be supplied or accepted
Transmission
PPP does not impose any restrictions regarding transmission rate
other than that of the particular Frame Relay interface
Control
Implementation of Frame Relay requires the provision of
signals, which indicate when the link has become connected
disconnected. These in turn provide the Up and Down events to
LCP state machine
Simpson Standards Track [Page 1]
RFC 1973 PPP in Frame Relay June 1996
Because PPP does not normally require the use of control signals
the failure of such signals MUST NOT affect correct operation
PPP. Implications are discussed in [2].
The definition of various encodings is the responsibility of
DTE/DCE equipment in use, and is outside the scope of
specification
While PPP will operate without regard to the
representation of the bit stream, Frame Relay requires
encoding
3. The Data Link
This specification uses the principles, terminology, and
structure described in "Multiprotocol Interconnect over Frame Relay
[4].
The purpose of this specification is not to document what is
standardized in [4]. Instead, this document attempts to give
concise summary and point out specific options and features used
PPP
3.1. Frame
As described in [4], Q.922 header address and control fields
combined with the Network Layer Protocol Identifier (NLPID),
identifies the encapsulation which follows. The fields
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
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address | Control | NLPID(0xcf) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and
fields are described in the Point-to-Point Protocol
Simpson Standards Track [Page 2]
RFC 1973 PPP in Frame Relay June 1996
[1].
3.2. Modification of the Basic
The Link Control Protocol can negotiate modifications to the
frame structure. However, modified frames will always be
distinguishable from standard frames
Address-and-Control-Field-
Because the Address and Control field values are not constant,
are modified as the frame is transported by the network
fabric, Address-and-Control-Field-Compression MUST NOT
negotiated
Protocol-Field-
Note that unlike PPP in HDLC-like framing, the Frame Relay
does not align the Information field on a 32-bit boundary
Alignment to a 32-bit boundary occurs when the NLPID is
and the Protocol field is compressed to a single octet. When
improves throughput, Protocol-Field-Compression SHOULD
negotiated
Simpson Standards Track [Page 3]
RFC 1973 PPP in Frame Relay June 1996
4. In-Band Protocol
The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish
PPP encapsulation from the other NLPID encapsulations described
[4].
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
are not recognized. This can eliminate "black-holes" that occur
traffic is not supported
For those network-layer protocols which have no PPP
assignment, or which have not yet been implemented under the
encapsulation, or which have not been successfully negotiated by
PPP NCP, another method of encapsulation defined under [4] SHOULD
used
Currently, there are no conflicts between NLPID and PPP
values. If a future implementation is configured to send a
value which is the same as a compressed Protocol field, that
field MUST NOT be sent compressed
On reception, the first octet following the header is examined.
the octet is zero, it MUST be assumed that the packet is
according to [4].
PPP encapsulated packets always have a non-zero octet following
header. If the octet is not the PPP NLPID value (CF hex),
Protocol-Field-Compression is enabled, and the associated NCP
been negotiated, then it is expected to be a compressed PPP
value. Otherwise, it MUST be assumed that the packet is
according to [4].
The Protocol field value 0x00cf is not allowed (reserved) to
ambiguity when Protocol-Field-Compression is enabled. The value
be treated as a PPP Protocol that indicates that another PPP
packet follows
Initial LCP packets contain the sequence cf-c0-21 following
header. When a LCP Configure-Request packet is received
recognized, the PPP link enters Link Establishment phase
The accidental connection of a link to feed a multipoint network (
multicast group) SHOULD result in a misconfiguration indication
This can be detected by multiple responses to the LCP Configure
Request with the same Identifier, coming from different
addresses. Some implementations might be physically unable to
log or report such information
Simpson Standards Track [Page 4]
RFC 1973 PPP in Frame Relay June 1996
Once PPP has entered the Link Establishment phase, packets with
NLPID values MUST NOT be sent, and on receipt such packets MUST
silently discarded, until the PPP link enters the Network-
Protocol phase
Once PPP has entered the Network-Layer Protocol phase,
successfully negotiated a particular NCP for a PPP Protocol, if
frame arrives using another equivalent data encapsulation defined
[4], the PPP Link MUST re-enter Link Establishment phase and send
new LCP Configure-Request. This prevents "black-holes" that
when the peer loses state
An implementation which requires PPP link configuration, and
PPP negotiated features (such as authentication), MAY
Termination phase when configuration fails. Otherwise, when
Configure-Request sender reaches the Max-Configure limit, it
fall back to send only frames encapsulated according to [4].
5. Out-of-Band
There is no generally agreed method of out-of-band signalling.
such a method is universally available, an implementation MUST
In-Band Protocol Demultiplexing for both Permanent and
Virtual Circuits
6. Configuration
The following Configuration Options are recommended
Magic
Protocol Field
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 [4]. This only affects the
required buffer space available for receiving packets, not the
of packets sent
The typical network feeding the link is likely to have a MRU
either 1500, or 2048 or greater. To avoid fragmentation,
Maximum-Transmission-Unit (MTU) at the network layer SHOULD
exceed 1500, unless a peer MRU of 2048 or greater is
Simpson Standards Track [Page 5]
RFC 1973 PPP in Frame Relay June 1996
negotiated
Some Frame Relay switches are only capable of 262 octet frames.
is not recommended that anyone deploy or use a switch which
capable of less than 1600 octet frames. However, PPP
MUST be configurable to limit the size of LCP packets which are
to 259 octets (which leaves room for the NLPID and Protocol fields),
until LCP negotiation is complete
XID negotiation is not required to be supported for links which
capable of PPP negotiation
Inverse ARP is not required to be supported for PPP links.
function is provided by PPP NCP negotiation
Simpson Standards Track [Page 6]
RFC 1973 PPP in Frame Relay June 1996
Security
Security issues are not discussed in this memo
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.
[2] CCITT Recommendation Q.922, "ISDN Data Link Layer
for Frame Mode Bearer Services", International Telegraph
Telephone Consultative Committee, 1992.
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[4] Bradley, T., Brown, C., and A. Malis, "
Interconnect over Frame Relay", RFC 1490, July 1993.
[5] ISO/IEC TR 9577:1990(E), "Information technology -
Telecommunications and Information exchange between systems -
Protocol Identification in the network layer", 1990-10-15.
This design was inspired by the paper "Parameter Negotiation for
Multiprotocol Interconnect", Keith Sklower and Clifford Frost
University of California, Berkeley, 1992, unpublished
Simpson Standards Track [Page 7]
RFC 1973 PPP in Frame Relay June 1996
Chair's
The working group can be contacted via the current chair
Karl
Ascend
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
wsimpson@UMich.
wsimpson@GreenDragon.com (preferred
Simpson Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
