rfc1561.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,403 行 · 第 1/4 页
TXT
1,403 行
+---+---+---+
| F | M | E |
| P | F | R |
+---+---+---+
The Fragmentation Permitted (FP) flag, when set to a value of one
(1), is semantically equivalent to the "may fragment" value of the
Don't Fragment field of IP; similarly, when set to zero (0), the
Fragmentation Permitted flag is semantically equivalent to the "Don't
Fragment" value of the Don't Fragment Flag of IP.
[Note: If the Fragmentation Permitted field is set to the value 0,
then the Data Unit Identifier, Fragment Offset, and Total Length
fields are not present. This denotes a single fragment datagram. In
such datagrams, the Fragment Length field contains the total length
of the datagram.]
The More Fragments flag of CLNP is semantically and syntactically the
same as the More Fragments flag of IP; a value of one (1) indicates
that more segments/fragments are forthcoming; a value of zero (0)
indicates that the last octet of the original packet is present in
this segment.
The Error Report (ER) flag is used to suppress the generation of an
error message by a host/router that detects an error during the
processing of a CLNP datagram; a value of one (1) indicates that the
host that originated this datagram thinks error reports are useful,
and would dearly love to receive one if a host/router finds it
necessary to discard its datagram(s).
Piscitello [Page 7]
RFC 1561 CLNP in TUBA Environments December 1993
4.6 Type field
The type field distinguishes data CLNP packets from Error Reports
from Echo packets. The following values of the type field apply:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet
+---+---+---+---+---+---+---+---+
| flags | 0 | 0 | 0 | 0 | 1 | => Encoding of Type = error report
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply
+---+---+---+---+---+---+---+---+
Error Report packets are described in Section 5.
Echo packets and their use are described in RFC 1139 [9].
4.7 Fragment Length
Like the Total Length of the IP header, the Fragment length field
contains the length in octets of the fragment (i.e., this datagram)
including both header and data.
[Note: CLNP also may also have a Total Length field, that contains
the length of the original datagram; i.e., the sum of the length of
the CLNP header plus the length of the data submitted by the higher
level protocol, e.g., TCP or UDP. See Section 4.12.]
4.8 Checksum
A checksum is computed on the header only. It MUST be verified at
each host/router that processes the packet; if header fields are
changed during processing (e.g., the Lifetime), the checksum is
modified. If the checksum is not used, this field MUST be coded with
a value of zero (0). See Appendix A for algorithms used in the
computation and adjustment of the checksum. Readers are encouraged to
see [10] for a description of an efficient implementation of the
checksum algorithm.
4.9 Addressing
CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs
serve the same identification and location functions as an IP
address, plus the protocol selector value encoded in the IPv4
datagram header, and with additional hierarchy. General purpose
Piscitello [Page 8]
RFC 1561 CLNP in TUBA Environments December 1993
CLNP implementations MUST handle NSAP addresses of variable length up
to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations,
especially routers, MUST accommodate these as well. Thus, for
compatibility and interoperability with OSI use of CLNP, the initial
octet of the Destination Address is assumed to be an Authority and
Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be
between 8 and 20 octets long (inclusive).
TUBA implementations MUST support both ANSI and GOSIP style
addresses; these are described in RFC 1237 [12], and illustrated in
Figure 4-2. RFC 1237 describes the ANSI/GOSIP initial domain parts
as well as the format and composition of the domain specific part. It
is further recommended that TUBA implementations support the
assignment of system identifiers for TUBA/CLNP hosts defined in [13]
for the purposes of host address autoconfiguration as described in
[14]. Additional considerations specific to the interpretation and
encoding of the selector part are described in sections 4.9.2 and
4.9.4.
+-------------+
| <-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 47 | 0005 |DFI |AA |Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+
Figure 4-2 (a): GOSIP Version 2 NSAP structure.
+-------------+
|<-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 39 | 840 |DFI |ORG|Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+
Figure 4-2 (b): ANSI NSAP address format for DCC=840
Piscitello [Page 9]
RFC 1561 CLNP in TUBA Environments December 1993
Definitions:
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administration Authority
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
Sel NSAP Selector
4.9.1 Destination Address Length Indicator
This field indicates the length, in octets, of the Destination
Address.
4.9.2 Destination Address
This field contains an OSI NSAP address, as described in Section 4.9.
It MUST always contain the address of the final destination. (This is
true even for packets containing a source route option, see Section
4.13.4).
The final octet of the destination address MUST always contain the
value of the PROTO field, as defined in IP. The 8-bit PROTO field
indicates the next level protocol used in the data portion of the
CLNP datagram. The values for various protocols are specified in
"Assigned Numbers" [15]. For the PROTO field, the value of zero (0)
is reserved.
TUBA implementations that support TCP/UDP as well as OSI MUST use the
protocol value (1Dh, Internet decimal 29) reserved for ISO transport
protocol class 4.
4.9.3 Source Address Length Indicator
This field indicates the length, in octets, of the Source Address.
4.9.4 Source Address
This field contains an OSI NSAP address, as described in Section 4.9.
The final octet of the source address is reserved. It MAY be set to
the protocol field value on transmission, and shall be ignored on
reception (the value of zero MUST not be used).
Piscitello [Page 10]
RFC 1561 CLNP in TUBA Environments December 1993
4.10 Data Unit Identifier
Like the Identification field of IP, this 16-bit field is used to
distinguish segments of the same (original) packet for the purposes
of reassembly. This field is present when the fragmentation permitted
flag is set to one.
4.11 Fragment Offset
Like the Fragment Offset of IP, this 16-bit is used to identify the
relative octet position of the data in this fragment with respect to
the start of the data submitted to CLNP; i.e., it indicates where in
the original datagram this fragment belongs. The offset is measured
in octets; the value of this field shall always be a multiple of
eight (8). This field is present when the fragmentation permitted
flag is set to one.
4.12 Total Length
The total length of the CLNP packet in octets is determined by the
originator and placed in the Total Length field of the header. The
Total Length field specifies the entire length of the original
datagram, including both the header and data. This field MUST NOT be
changed in any fragment of the original packet for the duration of
the packet lifetime. This field is present when the fragmentation
permitted flag is set to one.
4.13 Options
All CLNP options are "triplets" of the form <parameter code>,
<parameter length>, and <parameter value>. Both the parameter code
and length fields are always one octet long; the length parameter
value, in octets, is indicated in the parameter length field. The
following options are defined for CLNP for TUBA.
4.13.1 Security
The value of the parameter code field is binary 1100 0101. The length
field MUST be set to the length of a Basic (and Extended) Security IP
option(s) as identified in RFC 1108 [16], plus 1. Octet 1 of the
security parameter value field -- the CLNP Security Format Code -- is
set to a binary value 0100 0000, indicating that the remaining octets
of the security field contain either the Basic or Basic and Extended
Security options as identified in RFC 1108. This encoding points to
the administration of the source address (e.g., ISOC) as the
administration of the security option; it is thus distinguished from
the globally unique format whose definition is reserved for OSI use.
Implementations wishing to use a security option MUST examine the
Piscitello [Page 11]
RFC 1561 CLNP in TUBA Environments December 1993
PROTO field in the source address; if the value of PROTO indicates
the CLNP client is TCP or UDP, the security option described in RFC
1108 is used.
[Note: If IP options change, TUBA implementations MUST follow the new
recommendations. This RFC, or revisions thereof, must document the
new recommendations to assure compatibility.]
The formats of the Security option, encoded as a CLNP option, is as
follows. The CLNP option will be used to convey the Basic and
Extended Security options as sub-options; i.e., the exact encoding of
the Basic/Extended Security IP Option is carried in a single CLNP
Security Option, with the length of the CLNP Security option
reflecting the sum of the lengths of the Basic and Extended Security
IP Option.
+--------+--------+--------+--------+--------+---//----+-
|11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ...
+--------+--------+--------+--------+--------+---//----+----
CLNP CLNP CLNP BASIC BASIC BASIC
OPTION OPTION FORMAT SECURITY OPTION OPTION
TYPE LENGTH CODE TYPE LENGTH VALUE
(197) (130)
---+------------+------------+----//-------+
... | 10000101 | 000LLLLL | |
-----+------------+------------+----//-------+
EXTENDED EXTENDED EXTENDED OPTION
OPTION OPTION VALUE
TYPE (133) LENGTH
The syntax, semantics and processing of the Basic and Extended IP
Security Options are defined in RFC 1108.
4.13.2 Type of Service
[Note: Early drafts recommended the use of IP Type of Service as
specified in RFC 1349. There now appears to be a broad consensus that
this encoding is insufficient, and there is renewed interest in
exploring the utility of the "congestion experienced" flag available
in the CLNP QOS Maintenance option. This RFC thus recommends the use
of the QOS Maintenance option native to CLNP.]
The Quality of Service Maintenance option allows the originator of a
CLNP datagram to convey information about the quality of service
requested by the originating upper layer process. Routers MAY use
this information as an aid in selecting a route when more than one
route satisfying other routing criteria is available and the
Piscitello [Page 12]
RFC 1561 CLNP in TUBA Environments December 1993
available routes are know to differ with respect to the following
qualities of service: ability to preserve sequence, transit delay,
cost, residual error probability. Through this option, a router may
also indicate that it is experiencing congestion.
The encoding of this option is as follows:
+-----------+-----------+----------+
| 1100 0011 | 0000 0001 | 110ABCDE |
+-----------+-----------+----------+
CLNP QOS OPTION QOS FLAGS
TYPE (195) LENGTH
The value of the parameter code field MUST be set to a value of
binary 1100 0011 (the CLNP Quality of Service Option Code point).
The length field MUST be set to one (1).
Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE"
are interpreted as follows:
A=1 choose path that maintains sequence over
one that minimizes transit delay
A=0 choose path that minimizes transit delay over
one that maintains sequence
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?