📄 rfc926.txt
字号:
ISO DIS 8473 (May 1984) [Page 27]
RFC 926 December 1984
6.15 Record Route Function
The Record Route function permits the exact recording of the paths
taken by a PDU as it traverses a series of interconnected subnetworks.
A recorded route is composed of a list of intermediate system
addresses held in a parameter within the options part of the PDU
header. The size of the option field is determined by the originating
network-entity. The length of this option does not change as the PDU
traverses the network.
The list is constructed as the PDU traverses a set of interconnected
subnetworks. Only intermediate system addresses are included in the
recorded route. The address of the originator of the PDU is not
recorded in the list. When an intermediate system network-entity
processes a PDU containing the record route parameter, the system
inserts its own address (or titles, see Sections 5.3 or 5.5.1) into
the list of recorded addresses.
The record route option contains an indicator which identifies the
next available octet to be used for recording of route. This
identifier is updated as entries are added to the list. If the
addition of the current address to the list would exceed the size of
the option field, the indicator is set to show that recording of route
has terminated. The PDU may still be forwarded to its final
destination, without further addition of intermediate system
addresses.
Note:
The Record Route function is principally intended to be used in the
diagnosis of network problems. Its mechanism has been designed on
this basis, and may provide a return path.
ISO DIS 8473 (May 1984) [Page 28]
RFC 926 December 1984
6.16 Quality of Service Maintenance Function
In order to support the Quality of Service requested by Network
Service users, the Protocol may need to make QOS information available
at intermediate systems. This information may be used by network
entities in intermediate systems to make routing decisions where such
decisions affect the overall QOS provided to NS users.
In those instances where the QOS indicated cannot be maintained, the
NS provider will attempt to deliver the PDU at a QOS less than that
indicated. The NS provider will not necessarily provide a notification
of failure to meet the indicated quality of service.
6.17 Classification of Functions
Implementations do not have to support all of the functions described
in Section 6. Functions are divided into three categories:
Type 1: These functions must be supported.
Type 2: These functions may or may not be supported. If an
implementation does not support a Type 2 function, and the
function is selected by a PDU, then the PDU shall be
discarded, and an Error Report PDU shall be generated and
forwarded to the originating network-entity, providing that
the Error Report flag is set.
Type 3: These functions may or may not be supported. If an
implementation does not support a Type 3 function, and the
function is selected by a PDU, then the function is not
performed and the PDU is processed exactly as though the
function was not selected. The protocol data unit shall not
be discarded.
Table 6-1 shows how the functions are divided into these three
categories:
ISO DIS 8473 (May 1984) [Page 29]
RFC 926 December 1984
+---------------------------------------------------+
| Function | Type |
|--------------------------------|------------------|
| | |
| PDU Composition | 1 |
| PDU Decomposition | 1 |
| Header Format Analysis | 1 |
| PDU Lifetime Control | 1 |
| Route PDU | 1 |
| Forward PDU | 1 |
| Segment PDU | 1 |
| Reassemble PDU | 1 |
| Discard PDU | 1 |
| Error Reporting | 1 (note 1) |
| PDU Header Error Detection | 1 (note 1) |
| Padding | 1 (notes 1 2) |
| Security | 2 |
| Complete Source Routing | 2 |
| Partial Source Routing | 3 |
| Priority | 3 |
| Record Route | 3 |
| Quality of Service Maintenance | 3 |
+---------------------------------------------------+
Table 6-1. Categorization of Protocol Functions
ISO DIS 8473 (May 1984) [Page 30]
RFC 926 December 1984
Notes:
1) While the Padding, Error Reporting, and Header Error Detection
functions must be provided, they are provided only when selected
by the sending Network Service user.
2) The correct treatment of the Padding function involves no
processing. Therefore, this could equally be described as a Type
3 function.
3) The rationale for the inclusion of type 3 functions is that in
the case of some functions it is more important to forward the
PDUs between intermediate systems or deliver them to an
end-system than it is to support the functions. Type 3 functions
should be used in those cases where they are of an advisory
nature and should not be the cause of the discarding of a PDU
when not supported.
ISO DIS 8473 (May 1984) [Page 31]
RFC 926 December 1984
7 STRUCTURE AND ENCODING OF PDUS
7.1 Structure
All Protocol Data Units shall contain an integral number of octets.
The octets in a PDU are numbered starting from one (1) and increasing
in the order in which they are put into an SNSDU. The bits in an octet
are numbered from one (1) to eight (8), where bit one (1) is the
low-order bit.
When consecutive octets are used to represent a binary number, the
lower octet number has the most significant value.
Any subnetwork supporting this protocol is required to state in its
specification the way octets are transferred, using the terms "most
significant bit" and "least significant bit." The PDUs of this
protocol are defined using the terms "most significant bit" and "least
significant bit."
Note:
When the encoding of a PDU is represented using a diagram in this
section, the following representation is used:
a) octets are shown with the lowest numbered octet to the left,
higher number octets being further to the right;
b) within an octet, bits are shown with bit eight (8) to the left
and bit one (1) to the right.
PDUs shall contain, in the following order:
1) the header, comprising:
a) the fixed part;
b) the address part;
c) the segmentation part, if present;
d) the options part, if present
and
ISO DIS 8473 (May 1984) [Page 32]
RFC 926 December 1984
2) the data field, if present.
This structure is illustrated below:
Part: Described in:
+-------------------+
| Fixed Part | Section 7.2
+-------------------+
+-------------------+
| Address Part | Section 7.3
+-------------------+
+-------------------+
| Segmentation Part | Section 7.4
+-------------------+
+-------------------+
| Options Part | Section 7.5
+-------------------+
+-------------------+
| Data | Section 7.6
+-------------------+
Figure 7-1. PDU Structure
ISO DIS 8473 (May 1984) [Page 33]
RFC 926 December 1984
7.2 Fixed Part
7.2.1 General
The fixed part contains frequently occuring parameters including the
type code (DT or ER) of the protocol data unit. The length and the
structure of the fixed part are defined by the PDU code.
The fixed part has the following format:
Octet
+------------------------------------+
| Network Layer Protocol Identifier | 1
|------------------------------------|
| Length Indicator | 2
|------------------------------------|
| Version/Protocol Id Extension | 3
|------------------------------------|
| Lifetime | 4
|------------------------------------|
|S |M |E/R| Type | 5
| P| S| | |
|------------------------------------|
| Segment Length | 6,7
|------------------------------------|
| Checksum | 8,9
+------------------------------------+
Figure 7-2. PDU Header--Fixed Part
7.2.2 Network Layer Protocol Identifier
The value of this field shall be binary 1000 0001. This field
identifies this Network Layer Protocol as ISO 8473, Protocol for
Providing the Connectionless-mode Network Service.
ISO DIS 8473 (May 1984) [Page 34]
RFC 926 December 1984
7.2.3 Length Indicator
The length is indicated by a binary number, with a maximum value of
254 (1111 1110). The length indicated is the length in octets of the
header, as described in Section 7.1, Structure. The value 255 (1111
1111) is reserved for possible future extensions.
Note:
The rules for forwarding and segmentation ensure that the header
length is the same for all segments (Derived PDUs) of the Initial
PDU, and is the same as the header length of the Initial PDU.
7.2.4 Version/Protocol Identifier Extension
The value of this field is binary 0000 0001. This Identifies a
standard version of ISO 8473, Protocol for Providing the
Connectionless-mode Network Service.
7.2.5 PDU Lifetime
The Lifetime field is encoded as a binary number representing the
remaining lifetime of the PDU, in u⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -