summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1973.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1973.txt')
-rw-r--r--doc/rfc/rfc1973.txt578
1 files changed, 578 insertions, 0 deletions
diff --git a/doc/rfc/rfc1973.txt b/doc/rfc/rfc1973.txt
new file mode 100644
index 0000000..d1299c3
--- /dev/null
+++ b/doc/rfc/rfc1973.txt
@@ -0,0 +1,578 @@
+
+
+Network Working Group W. Simpson
+Request for Comments: 1973 Daydreamer
+Category: Standards Track June 1996
+
+
+ PPP in Frame Relay
+
+
+
+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 Frame Relay for framing PPP
+ encapsulated packets.
+
+
+Applicability
+
+ This specification is intended for those implementations which desire
+ to use facilities which are defined for PPP, such as the Link Control
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Standards Track [Page i]
+
+RFC 1973 PPP in Frame Relay June 1996
+
+
+ Protocol, Network-layer Control Protocols, authentication, and
+ compression. These capabilities require a point-to-point
+ relationship between peers, and are not designed for multi-point or
+ multi-access environments.
+
+
+Table of Contents
+
+
+ 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. Introduction
+
+ Frame Relay [2] is a relative newcomer to the serial link community.
+ Like X.25, the protocol was designed to provide virtual circuits 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 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 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 [4].
+
+ At one time, it had been hoped that PPP in HDLC-like frames and Frame
+ 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 not
+ indistinguishable from the ISO 3309 method, due to the structure of
+ its Data Link Connection Identifier (DLCI) subfields. Co-existance
+ is precluded.
+
+
+
+2. Physical Layer Requirements
+
+ PPP treats Frame Relay framing as a bit-synchronous link. The link
+ MUST be full-duplex, but MAY be either dedicated (permanent) or
+ switched.
+
+ 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, which indicate when the link has become connected or
+ disconnected. These in turn provide the Up and Down events to the
+ 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 of
+ PPP. Implications are discussed in [2].
+
+ Encoding
+
+ The definition of various encodings 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, Frame Relay requires NRZ
+ encoding.
+
+
+
+3. The Data Link Layer
+
+ This specification uses the principles, terminology, and frame
+ structure described in "Multiprotocol Interconnect over Frame Relay"
+ [4].
+
+ The purpose of this specification is not to document what is already
+ standardized in [4]. Instead, this document attempts to give a
+ concise summary and point out specific options and features used by
+ PPP.
+
+
+
+3.1. Frame Format
+
+ As described in [4], Q.922 header address and control fields are
+ combined with the Network Layer Protocol Identifier (NLPID), which
+ identifies the encapsulation which follows. 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
+ +-+-+-+-+-+-+-+-+
+ | 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
+
+
+
+Simpson Standards Track [Page 2]
+
+RFC 1973 PPP in Frame Relay June 1996
+
+
+ [1].
+
+
+
+3.2. Modification of the Basic Frame
+
+ The Link Control Protocol can negotiate modifications to the basic
+ frame structure. However, modified frames will always be clearly
+ distinguishable from standard frames.
+
+ Address-and-Control-Field-Compression
+
+ Because the Address and Control field values are not constant, and
+ are modified as the frame is transported by the network switching
+ fabric, Address-and-Control-Field-Compression MUST NOT be
+ negotiated.
+
+ Protocol-Field-Compression
+
+ Note that unlike PPP in HDLC-like framing, the Frame Relay framing
+ does not align the Information field on a 32-bit boundary.
+ Alignment to a 32-bit boundary occurs when the NLPID is removed
+ and the Protocol field is compressed to a single octet. When this
+ improves throughput, Protocol-Field-Compression SHOULD be
+ negotiated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Standards Track [Page 3]
+
+RFC 1973 PPP in Frame Relay June 1996
+
+
+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
+ [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 that
+ are not recognized. This can eliminate "black-holes" that occur when
+ traffic is not supported.
+
+ For those network-layer protocols which have no PPP Protocol
+ assignment, or which have not yet been implemented under the PPP
+ encapsulation, or which have not been successfully negotiated by a
+ PPP NCP, another method of encapsulation defined under [4] SHOULD be
+ used.
+
+ Currently, there are no conflicts between NLPID and PPP Protocol
+ values. 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 header is examined. If
+ the octet is zero, it MUST be assumed that the packet is formatted
+ according to [4].
+
+ PPP encapsulated packets always have a non-zero octet following the
+ header. If the octet is not the PPP NLPID value (CF hex), and
+ Protocol-Field-Compression is enabled, and the associated NCP has
+ been negotiated, then it is expected to be a compressed PPP Protocol
+ value. Otherwise, it MUST be assumed that the packet is formatted
+ according to [4].
+
+ The Protocol field value 0x00cf is not allowed (reserved) to avoid
+ ambiguity when Protocol-Field-Compression is enabled. The value MAY
+ be treated as a PPP Protocol that indicates that another PPP Protocol
+ packet follows.
+
+ Initial LCP packets contain the sequence cf-c0-21 following the
+ header. When a LCP Configure-Request packet is received and
+ recognized, the PPP link enters Link Establishment phase.
+
+ The accidental connection of a link to feed a multipoint network (or
+ 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 framing
+ addresses. Some implementations might be physically unable to either
+ 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 other
+ NLPID values MUST NOT be sent, and on receipt such packets MUST be
+ silently discarded, until the PPP link enters the Network-Layer
+ Protocol phase.
+
+ Once PPP has entered the Network-Layer Protocol phase, and
+ successfully negotiated a particular NCP for a PPP Protocol, if a
+ frame arrives using another equivalent data encapsulation defined in
+ [4], 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 which 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 [4].
+
+
+
+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
+ Virtual Circuits.
+
+
+
+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 [4]. 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
+ Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
+ exceed 1500, unless a peer MRU of 2048 or greater is specifically
+
+
+
+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. It
+ is not recommended that anyone deploy or use a switch which is
+ capable of less than 1600 octet frames. However, PPP implementations
+ MUST be configurable to limit the size of LCP packets which are sent
+ 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 are
+ capable of PPP negotiation.
+
+ Inverse ARP is not required to be supported for PPP links. That
+ function is provided by PPP NCP negotiation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Standards Track [Page 6]
+
+RFC 1973 PPP in Frame Relay June 1996
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [2] CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
+ for Frame Mode Bearer Services", International Telegraph and
+ 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, "Multiprotocol
+ 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.
+
+
+
+Acknowledgments
+
+ This design was inspired by the paper "Parameter Negotiation for the
+ 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 Address
+
+ The working group can be contacted via the current chair:
+
+ Karl Fox
+ Ascend Communications
+ 3518 Riverside Drive, Suite 101
+ Columbus, Ohio 43221
+
+ EMail: karl@ascend.com
+
+
+
+Author'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
+
+ wsimpson@UMich.edu
+ wsimpson@GreenDragon.com (preferred)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Standards Track [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+