rfc1963.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页
TXT
1,124 行
The size of the Length field is negotiated via the Length-Size
parameter.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Length-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
3
Length-Size
0 No Length Field (default)
1 Length field of 1 octet
2 Length field of 2 octets
4.4. Multi-Port
By default, packets do not contain a port number and all packets are
sent to the default port, Port 0. The Successful negotiation of the
Multi-Port configuration option means that every packet will contain
a port number. The maximum port number, and hence the number of
ports, is negotiated by using the Max-Port-Num field. A value of 0
specifies that a single port is to be used and no port field will be
Schneider & Venters Informational [Page 14]
RFC 1963 PPP SDTP August 1996
present in an SDTP packet. (This is the same as not negotiating or
rejecting this option.) Port numbers begin with 0 and range to 254.
Port number 255 is reserved for control purposes (see section on flow
control).
Protocol Specific negotiations which are on a per port basis, require
the port number to be specified as part of the configuration
negotiation.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Max-Port-Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
4
Length
3
Max-Port-Num
The maximum port number that can be used. The number of ports
present is Max-Port-Num + 1. The value can range from 0 to 254.
4.5. Transport-Mode
This parameter selects the mode of transport for the specified port.
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 | Port | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5
Length
4
Schneider & Venters Informational [Page 15]
RFC 1963 PPP SDTP August 1996
Port
The port for which this option applies.
Mode
The transport mode to be used for this port.
0 HDLC Synchronous (default)
1 Asynchronous
4.6. Maximum-Frame-Size
This parameter specifies the maximum number of octets allowed in a
transported data frame.
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 | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum-Frame-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6
Length
7
Port
The port for which this option applies.
Maximum-Frame-Size
The maximum allowed length of a transported data frame in octets.
Default is 10,000. Negotiable range is 1 to 2**31 - 1. The value
0 is reserved to mean no limit. This field is transmitted most
significant octet first.
4.7. Allow-Odd-Frames
By default, only octet-aligned data frames are allowed for transport.
Successful negotiation of this option allows the transport of non-
octet aligned frames. The size of the padding required to align the
Schneider & Venters Informational [Page 16]
RFC 1963 PPP SDTP August 1996
frames is carried in the CS Header octet.
Use of Header-Type H-Only is not permitted in conjunction with this
option.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
3
Port
The port for which this option applies.
4.8. FCS-Type
By default, the transported data frame FCS is transported. This
option allows the FCS to be removed by the transmitter and
regenerated by the receiver.
It is important that implementations not use regeneration unless they
are using PPP Reliable Transmission [12] or operating over some other
layer that will provide reliable notification of a dropped packet.
Implementations are not permitted to send a incomplete or bad frame
to the user with a good (regenerated) FCS.
This option also selects the type of user FCS that will be
regenerated.
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 | Port | FCS-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Schneider & Venters Informational [Page 17]
RFC 1963 PPP SDTP August 1996
Length
4
Port
The port for which this option applies.
FCS-Type
0 Transparent-Transport (Default)
1 16-bit ITU-T CRC
2 32-bit ITU-T CRC
4.9. Flow-Expiration-Time
As described in section 2.2, Flow-Off messages expire after T1
seconds. By default, T1 is 10 seconds. This configuration option
allows the value of T1 to be changed.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-Expiration-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9
Length
5
Flow-Expiration-Time
The Flow-Expiration-Time field contains a 16 bit unsigned integer
which is used to specify the value to be assigned to T1 as
follows: T1 = Flow-Expiration-Time / 10 seconds. Therefore this
value is in units of 1/10 of a second, with allowable values from
1 to 2^16-1 (0.1 to 6553.5 seconds). It is transmitted most
significant octet first. The default value is 100 (10 seconds),
which all must support.
Schneider & Venters Informational [Page 18]
RFC 1963 PPP SDTP August 1996
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2] CCITT Recommendation V.120 (09/92), "Support by an ISDN of
Data Terminal Equipment with V-Series Type Interfaces with
Provision for Statistical Multiplexing", 1993.
[3] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
[4] Friend, R., and W. Simpson, "PPP Stac LZS Compression
Protocol", RFC 1974, August 1996.
[5] Rand, D., "PPP Predictor Compression Protocol", RFC 1978,
August 1996.
[6] Petty, J., "PPP Hewlett-Packard Packet-by-Packet Compression
(HP PPC) Protocol", Work in Progress.
[7] Carr, D., "PPP Gandalf FZA Compression Protocol", Work in
Progress.
[8] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
August 1996.
[9] Schremp, et. al., "PPP Magnalink Variable Resource
Compression", RFC 1975, August 1996.
[10] Schneider, K., "PPP Stacker LZS Compression Protocol using a
DCP Header (LZS-DCP)", RFC 1967, August 1996.
[11] Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994.
[12] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
Schneider & Venters Informational [Page 19]
RFC 1963 PPP SDTP August 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
Authors' Addresses
Questions about this memo should be directed to:
Kevin Schneider
Adtran, Inc.
901 Explorer Blvd.
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: kevin@adtran.com
Stuart Venters
Adtran, Inc.
901 Explorer Blvd.
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: sventers@adtran.com
Schneider & Venters Informational [Page 20]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?