rfc1663.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 452 行 · 第 1/2 页
TXT
452 行
Network Working Group D. Rand
Request for Comments: 1663 Novell
Category: Standards Track July 1994
PPP Reliable Transmission
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 defines a method for negotiating and using Numbered-
Mode, as defined by ISO 7776 [2], to provide a reliable serial link.
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@ucdavis.edu mailing list.
Table of Contents
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 2
3. The Data Link Layer ................................... 2
3.1 Frame Format ....................................... 2
4. Configuration Option Format ........................... 4
5. Numbered-Mode Operation ............................... 5
5.1 Single Link ........................................ 6
5.2 Inverse Multiplexing ............................... 6
5.3 Using Multi-Link Procedure... ...................... 7
5.4 LAPB Parameter defaults ............................ 8
SECURITY CONSIDERATIONS ...................................... 9
REFERENCES ................................................... 9
ACKNOWLEDGEMENTS ............................................. 9
CHAIR'S ADDRESS .............................................. 10
AUTHOR'S ADDRESS ............................................. 10
Rand [Page 1]
RFC 1663 PPP Reliable Transmission July 1994
1. Introduction
By default, PPP packets over HDLC framed links consist of
"connectionless" datagrams. If reliable transmission over the HDLC
link is desired, the implementation MUST specify the Numbered-Mode
Configuration Option during Link Establishment phase.
Generally, serial link reliability is not a major issue. The
architecture of protocols used in datagram networking presume
best-effort non-sequential delivery. When errors are detected,
datagrams
are discarded.
However, in certain circumstances, it is advisable to provide a
reliable link, at least for a subset of the messages. The most
obvious case is when the link is compressed. Since the dictionary is
recovered from the compressed data stream, and a lost datagram
corrupts the dictionary, datagrams must not be lost. Not all
compression types will require a reliable data stream, since the cost
to detect and reset a corrupt dictionary is small.
The ISO 7776 LAPB can be used guarantee delivery. This is referred
to in this document as "Numbered Mode" to distinguish it from the use
of "Unnumbered Information", which is standard PPP framing practice.
Where multiple parallel links are used to emulate a single link of
higher speed, Bridged traffic, Source Routed traffic, and traffic
subjected to Van Jacobsen TCP/IP header compression must be delivered
to the higher layer in a certain sequence. However, the fact of the
links being relatively asynchronous makes traffic ordering uncertain.
The ISO 7776 Multi-Link Procedure MAY be used to restore order.
Implementation of the ISO Multi-Link Procedure is deprecated. It is
recommended that the PPP multilink procedure [4] be used instead.
2. Physical Layer Requirements
PPP Reliable Transmission imposes the same requirements that are
described in "PPP in HDLC Framing" [3], with the following
exceptions.
Control Signals
While PPP does not normally require the use of control signals,
implementation of Numbered-Mode LAPB or LAPD 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.
Rand [Page 2]
RFC 1663 PPP Reliable Transmission July 1994
3. The Data Link Layer
Numbered-Mode affects only the Address and Control fields. The
remainder of the frame conforms to the framing in use for PPP.
The Address Field of the frame MUST take the value announced in the
Numbered-Mode Configuration Option, and the Control Field MAY take
any value valid in ISO 7776.
Once the link enters Numbered-Mode, Numbered-Mode MUST be used on all
frames, as some implementations do not support the use of the
Unnumbered-Information control field or the use of the All-Stations
address intermixed with Numbered-Mode frames.
3.1. Frame Format
The following frame format is valid under Numbered-Mode. The fields
are transmitted from left to right.
Numbered Mode
+----------+----------+----------+
| Flag | Address | Control |
| 01111110 |1-2 octets|1-2 octets|
+----------+----------+----------+
+----------+-------------+---------+
| Protocol | Information | Padding |
|1-2 octets| * | * |
+----------+-------------+---------+
+----------+----------+-----------------
| FCS | Flag | Inter-frame Fill
| 16 bits | 01111110 | or next Address
+----------+----------+-----------------
The Protocol, Information and Padding fields are described in the
Point-to-Point Protocol Encapsulation [1]. The FCS and Flag Sequence
fields are described in "PPP in HDLC Framing" [3].
4. Configuration Option Format
Description
The LCP Numbered-Mode Configuration Option negotiates the use of
Numbered-Mode on the link. By default or ultimate disagreement,
Unnumbered-Mode is used.
A summary of the Numbered-Mode Configuration Option format is shown
below. The fields are transmitted from left to right.
Rand [Page 3]
RFC 1663 PPP Reliable Transmission July 1994
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 | Window | Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
11
Length
>= 4
Window
A value between 1 and 127. This indicates the number of frames
the receiver will buffer, which is the maximum number that the
sender should send without receiving an acknowledgement. If
window < 8, then modulo 8 sequencing is used on the link.
Otherwise, modulo 128 sequencing is used.
It is conceivable and legal that differing window values might be
announced. However, it is not permitted for one system to use
modulo 8 sequencing and the other to use modulo 128. Therefore,
the rule is: a Configure-Nak may reduce the window but may not
increase it.
Address
An HDLC Address as specified in ISO 3309. ISO 7776 specifies four
of the possible values: 1 and 3 for single link operation, 7 and
15 for the Multi-Link Procedure. Other values consistent with ISO
3309 are considered legal.
Implementation of the Multi-Link Procedure is optional; A
Configure-Nak may therefore force a change from MLP to single link
mode, but not the reverse.
Should the address be zero upon receipt, the receiver MUST
Configure-Nak with an appropriate address. If both peers send
address zero, the system advertising the numerically smaller
window will select the smaller address. If both windows are the
same size, a random choice MUST be made; when good sources of
randomness are used, the link will converge in a reasonable time.
Rand [Page 4]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?