📄 rfc995.txt
字号:
anyway.
7.9 Refresh Redirect Function
The Refresh Redirect Function is present only in End Systems. This
function is invoked whenever an NPDU is received by a destination ES.
It is closely coupled with the function that processes received NPDUs
at a destination Network Entity.This is the "PDU Decomposition" func-
tion in ISO 8473. The purpose of this function is to increase the
longevity of a redirection without allowing an incorrect route to
persist indefinitely. The Source Address (SA), Priority, Security,
and QoS options are extracted and compared to any Destination Address
and QoS parameters being maintained in the Routing Information base
(such information would have been stored by the Record Redirect Func-
tion). If a corresponding entry is found, the previous hop of the PDU
is obtained from the SN_Source_Address parameter of the
SN_Unitdata.Indication primitive by which it was received. If this
address matches the next hop address stored with the redirection in-
formation, the remaining holding time for the redirection is reset to
the original holding timer that was obtained from the RD PDU.
Note:
The purpose of this function is to avoid timing out redirection entries
when the Network entity is receiving return traffic from the destination
via the same path over which it is currently sending traffic.This is
ISO N4053 [Page 23]
RFC 995 December 1986
particularly useful when the destination system is on the same subnetwork
as the source, since after one redirect no IS need be involved in
the ES-to-ES traffic.
This function must operate in a very conservative fashion however,
to prevent the formation of black holes. The remaining holding time
should be refreshed only under the exact conditions specified above.
For a discussion of the issues surrounding the refresh of redirection
information, see Annex 10.
7.10 Flush Old Redirect Function
The Flush Old Redirect Function is executed to remove Configuration
entries in the routing information base whose Holding Timer has ex-
pired. When the Holding Time for an ES or IS expires, this function
removes the corresponding entry from the routing information base of
the local Network Entity.
7.11 PDU Header Error Detection
The PDU Header Error Detection function protects against failure of
Intermediate or End System Network entities due to the processing of
erroneous information in the PDU header.The function is realized by a
checksum computed on the entire PDU header. The checksum is verified
at each point at which the PDU is processed. If the checksum calcula-
tion fails, the PDU must be discarded.
The use of the Header Error Detection function is optional and is
selected by the originating Network Entity. If the function is not
used, the checksum field of the PDU header is set to zero.
If the function is selected by the originating Network Entity, the
value of the checksum field causes the following formulf to be satis-
fied:
(The Sum from i=1 to L of a(i)) (mod 255) = 0
(The Sum from i=1 to L of (L - i + 1) * a(i)) (mod 255) = 0
where L = the number of octets in the PDU header, and a(i) = the value of
the octet at position i. The first octet in the PDU header is considered to
occupy position i = 0.
When the function is in use, neither octet of the checksum field may be
set to zero.
ISO N4053 [Page 24]
RFC 995 December 1986
7.12 Classification of Functions
Implementations do not have to support all of the functions described
in clause 7. Functions are divided into four categories:
Type A: These functions must be supported in all cases.
Type B: These functions must be supported by Systems which implement
the Configuration Information.
Type C: These functions must be supported by Systems which implement
the Redirect Information.
Type D: These functions are optional.
If a PDU is received which invokes an optional function that is not
implemented, that PDU is discarded.
Table 3 shows how the functions are divided into these four
categories, and to which type of system (ES, IS, or both) they apply.
______________________________________________________________
| Function | Category | System Type |
|_______________________________|____________|_______________|
| Report Configuration | B | ES,IS |
| Record Configuration | B | ES,IS |
| Configuration Response | A | ES |
| Flush Old Configuration | B | ES,IS |
| Request Redirect | C | IS |
| Query Configuration | B | ES |
| Record Redirect | C | ES |
| Refresh Redirect | D | ES |
| Flush Old Redirect | C | ES |
| PDU Header Error Detection | A | ES,IS |
|_______________________________|____________|_______________|
Table 3: Categories of Protocol Functions
8 Structure and Encoding of PDUs
Note:
The encoding of the PDUs for this protocol is compatible with that
used in ISO 8473.
Temporary Note:
The method employed for describing the encoding of PDUs is provisional.
Member bodies are requested to comment on whether another
method (such as ASN.1 with an appropriate concrete syntax) would
be preferable.
ISO N4053 [Page 25]
RFC 995 December 1986
8.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 in-
creasing 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 proto-
col 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 fixed part;
2. the Network address part;
3. the Subnetwork address part, if present; and
4. the Options part, if present.
8.2 Fixed Part
8.2.1 General
The fixed part contains frequently occurring parameters including the
type code (ESH, ISH, or RD) of the protocol data unit.The length and
the structure of the fixed part are defined by the PDU code.
ISO N4053 [Page 26]
RFC 995 December 1986
The fixed part has the following format:
Octet
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| reserved (must be zero) | 4
|______________________________________|
| 0 |0 |0 | Type | 5
|___|__|__|____________________________|
| Holding Time | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
Figure 1: PDU Header -- Fixed Part
8.2.2 Network Layer Protocol Identifier
The value of this field shall be 1000 0010.
Temporary Note:
The value 1000 0010 is provisional, pending resolution of the NLPID
issue in SC6.
This field identifies this Network Layer Protocol as ISO SC6/N4053,
End System to Intermediate System Routing Exchange Protocol for use in
conjunction with ISO 8473.
8.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 of the entire PDU
(which consists entirely of header, since this protocol does not car-
ry user data) in octets, as described in clause 8.1. The value 255
(1111 1111) is reserved for possible future extensions.
8.2.4 Version/Protocol Identifier Extension
The value of this field is binary 0000 0001. This identifies a stan-
dard version of ISO xxxx, End System to Intermediate System Routing
Exchange Protocol for use in conjunction with ISO 8473.
ISO N4053 [Page 27]
RFC 995 December 1986
8.2.5 Type Code
The Type code field identifies the type of the protocol data unit.
Allowed values are given in table 4.
_____________________________________________________
| | Bits 5 4 3 2 1 |
|____________|______________________________________|
|____________|______________________________________|
|ESH PDU | 0 0 0 1 0 |
|____________|______________________________________|
|ISH PDU | 0 0 1 0 0 |
|____________|______________________________________|
|RD PDU | 0 0 1 1 0 |
|____________|______________________________________|
Table 4: Valid PDU Types
All other PDU type values are reserved.
8.2.6 Holding Time
The Holding Time field specifies for how long the receiving Network
entity should retain the configuration/routing information contained
in this PDU. The receiving Network entity should discard any infor-
mation obtained from this PDU from its internal state when the hold-
ing time expires. The Holding time field is encoded as an integral
number of micro-fortnights.
8.2.7 PDU Checksum
The checksum is computed on the entire PDU header. A checksum value
of zero is reserved to indicate that the checksum is to be ignored.
The operation of the PDU Header Error Detection function (Clause
7.11) ensures that the value zero does not represent a valid check-
sum. A non-zero value indicates that the checksum must be processed.
If the checksum calculation fails, the PDU must be discarded.
8.3 Network Address Part
8.3.1 General
Address parameters are distinguished by their location. The different
PDU types carry different address parameters however.The ESH PDU car-
ries a Source NSAP address (SA); the ISH PDU carries a Intermediate
System Network entity Title (NET); and the RD PDU carries a Destina-
tion NSAP address (DA), and possibly a Network Entity Title (NET).
8.3.2 NPAI (Network Protocol Address Information) Encoding
The Destination and Source Addresses are Network Service Access Point
ISO N4053 [Page 28]
RFC 995 December 1986
addresses as defined in ISO 8348/AD2, Addendum to the Network Service
Definition Covering Network Layer addressing.The Network Entity Title
address parameter is defined in clause 4.5. The Destination Address,
Source Address, and Network Entity Title are encoded as⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -