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.
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.
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
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 NPAI using
the binary syntax defined in clause 8.3.1 of ISO 8348/AD2.
The address information is of variable length. Each address parameter
is encoded as follows:
_______________________________________________
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|________|____________________________________|
| Octets | |
| n + 1 | Address Parameter Value |
| thru | |
| n + m | |
|________|____________________________________|
Figure 2: Address Parameters
8.3.3 Source Address Parameter for ESH PDU
The Source Address is the NSAP address of an NSAP served by the Net-
work entity sending the ESH PDU. It is encoded in the ESH PDU as fol-
lows:
Octet
________________________________________
|Source Address Length Indicator (SAL) | 10
|______________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|______________________________________|
Figure 3: ESH PDU - Network Address Part
8.3.4 Network Entity Title Parameter for ISH PDU
The Network entity Title parameter is the Network Entity Title of the
Intermediate System sending the ISH PDU. It is encoded in the ISH PDU
as follows:
Octet
_______________________________________________
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
Figure 4: ISH PDU - Network Address Part
8.3.5 Destination Address Parameter for RD PDU
The Destination Address is the NSAP address of a destination associ-
ated with some NPDU being forwarded by the Intermediate System send-
ing the RD PDU. It is encoded in the RD PDU as follows:
Octet
_____________________________________________
|Destination Address Length Indicator (DAL) | 10
|___________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|___________________________________________|
Figure 5: RD PDU - Network Address Part
8.4 Subnetwork Address Part
The Subnetwork Address Part is present only in RD PDUs.It is used to
indicate the subnetwork address of another Network entity on the same
subnetwork as the End System (and Intermediate System) which may be a
better path to the destination specified in the Network Address Part.
The Subnetwork Address parameter is encoded in the same manner as the
Network Address parameters.
8.4.1 Subnetwork Address Parameter for RD PDU
The Subnetwork Address Parameter is encoded in the RD PDU as fol-
lows:
Octet
_______________________________________________
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (BSNPA) :
| | n - 1
|_____________________________________________|
Figure 6: ESH PDU - Address Part
8.5 Options Part
8.5.1 General
The options part is used to convey optional parameters. The options
part
of the PDU header is illustrated below:
Octet
___________________________________________________
| | p
: Options :
| | q
|__________________________________________________|
Figure 7: All PDUs - Options Part
If the options part is present, it may contain one or more parame-
ters. The number of parameters that may be contained in the options
part is constrained by the length of the options part, which is
determined by the following formula:
PDU Header Length - (length of fixed part + length of address
part + length of segmentation part),
and by the length of the individual optional parameters.
Parameters defined in the options part may appear in any order. Du-
plication of options is not permitted.Receipt of a PDU with an option
duplicated must be treated as a protocol error.
The encoding of parameters contained within the options part of the
PDU header is illustrated below in figure 8.
Octets
_________________________________
| n | Parameter Code |
|____________|__________________|
| n + 1 | Parameter Length |
|____________|__________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|__________________|
Figure 8: Encoding of Option Parameters
The parameter code field is coded in binary and, without extensions,
provides a maximum of 255 different parameters. No parameter codes
use bits 8 and 7 with the value 00, so the actual maximum number of
parameters is lower. A parameter code of 255 (binary 1111 1111) is
reserved for possible future extensions.
The parameter length field indicates the length, in octets, of the
parameter value field.The length is indicated by a positive binary
number, m, with a theoretical maximum value of 254. the practical
maximum value of m is lower. For example, in the case of a single
parameter contained within the options part, two octets are required
for the parameter code and the parameter length indicators. Thus, the
value of m is limited to:
m = 252-(length of fixed part +length of address part
+length of segmentation part )
For each succeeding parameter the maximum value of m decreases. The
parameter value field contains the value of the parameter identified
in the parameter code field.
The following parameters are permitted in the options part.
8.5.2 Security
The Security parameter conveys information about the security re-
quested in the Data PDU that caused the containing RD PDU to be gen-
erated. This parameter has the same encoding and semantics as the
Security parameter in ISO 8473.
Parameter Code: 1100 0101
Parameter Length: variable
Parameter Value: See Section 7.5.3 of ISO 8473
8.5.3 Quality of Service Maintenance
The Quality of Service parameter conveys information about the quali-
ty of service requested in the Data PDU that caused the containing RD
PDU to be generated.
This parameter has the same encoding and semantics as the QoS Mainte-
nance parameter in ISO 8473.
Parameter Code: 1100 0011
Parameter Length: variable
Parameter Value: See Section 7.5.6 of ISO 8473
8.5.4 Priority
The Priority parameter conveys information about the priority re-
quested in the Data PDU that caused the containing RD PDU to be gen-
erated.
This parameter has the same encoding and semantics as the Priority
parameter in ISO 8473.
Parameter Code: 1100 1101
Parameter Length: one octet
Parameter Value: See Section 7.5.7 of ISO 8473
8.6 End System Hello (ESH) PDU
8.6.1 Structure
The ESH PDU 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
|__________________________________________|
| Source Address Length Indicator (SAL) | 10
|__________________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|__________________________________________|
| | m
: Options :
| | p - 1
|__________________________________________|
Figure 9: ESH PDU Format
8.7 Intermediate System Hello (ISH) PDU
8.7.1 Structure
The ISH PDU 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
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
| | m
: Options :
| | p - 1
|_____________________________________________|
Figure 10: ISH PDU Format
8.8 Redirect (RD) PDU
8.8.1 Structure
The RD PDU 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
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | n
|_____________________________________________|
| | n + 1
: Network Entity Title (NET) :
| | p - 1
|_____________________________________________|
| | p
: Options :
| | q - 1
|_____________________________________________|
Figure 11: RD PDU Format when Redirect is to an IS
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
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
| NETL = 0 | n
|_____________________________________________|
| | n + 1
: Options :
| | p - 1
|_____________________________________________|
| Quality of Service | n + 1
|_____________________________________________|
Figure 12: RD PDU Format when Redirect is to an ES
9 Formal Description
{Maybe next pass...}
10 Conformance
See Clause 6.2.
ANNEX A. SUPPORTING TECHNICAL MATERIAL
A.1 Use of Timers
This protocol makes extensive use of timers to ensure the timeliness
and accuracy of information disseminated using the Configuration and
Route Redirection functions.This section discusses the rationale for
using these timers and provides some background for how they operate.
Systems using this protocol learn about other systems exclusively by
receiving PDUs sent by those systems. In a connectionless environ-
ment, a system must periodically receive updated information to en-
sure that the information it previously received is still correct.
For example, if a system on a subnetwork becomes unavailable (either
it has ceased operating, or its SNPA becomes inoperative) the only
way another system can detect this fact is by the absence of
transmissions from that system. If information were retained in the
absence of new PDUs being received, configuration and/or routing in-
formation would inevitably become incorrect. The Holding Timers
specified by this protocol guarantee that old information will not be
retained indefinitely.
A useful way of thinking of the configuration and route redirection
information is as a cache maintained by each system. The cache is
periodically flushed to ensure that only up-to-date information is
stored.Unlike most caches, however, the time to retain information is
not a purely local matter. Rather, information is held for a period
of time specified by the source of the information. Some examples
will help clarify this operation.
A.1.1 Example of Holding Time for Route Redirection
Route Redirection Information is obtained by an End System through
the Request Redirect function (see clause 7.7).It is quite possible
that a Intermediate System might redirect an End System to another IS
which has recently become unavailable (this might happen if the IS-
to-IS routing algorithm is still converging following a configuration
change). If the Holding Timer were not present, or was set very long
by the sending IS, an End System would have been redirected into a
Black Hole from which none of its Data PDUs would ever emerge. The
length of the Holding Timer on Redirects specifies, in essence, the
length of time black holes are permitted to exist.
On the other hand, setting the Holding Timer on Route Redirects very
short to minimize the effect of black holes has other undesirable
consequences.First, for each PDU that causes a redirect, an addition-
al PDU beside the original Data PDU must be composed and transmitted;
this increases overhead. Second, each time a "working" redirect's
Holding Timer expires, the redirected End System will revert to a
poorer route for at least one PDU.
A.1.2 Example of Holding Timer for Configuration Information
A similar type of problem can occur with respect to Configuration in-
formation. If the Holding Time of a ISH PDU (see clause 7.2.2) is set
very long, and the only Intermediate System (which has been sending
this Configuration Information) on the subnetwork becomes unavail-
able, a subnetwork-wide black hole can form. During this time, End
Systems on the subnetwork may not be able to communicate with each
other because they presume that a Intermediate System is operating
which will forward their Data PDUs to destination ESs on the local
subnetwork and return RD PDUs.Once the Holding Time expires, the ESs
will realize that no IS is available and will take their only
recourse, which is to send their traffic directly on the local sub-
network.
Given the types of problems that can occur, it is important that
responsibility for incorrect information can be unambiguously as-
signed to the source of the information. For this reason all Holding
Timers are calculated by the source of the Configuration or Route
Redirection information and communicated explicitly to each recipient
in the appropriate PDU.
A.2 Refresh and timeout of Redirection information
The protocol allows End Systems to refresh redirection information
without first allowing the holding time to expire and being redirect-
ed by a Intermediate System for a second (or subsequent) time. Such
schemes are prevalent in connectionless subnetworks and are often
called "reverse path information", "previous hop cache" or something
similar.
Refreshing the redirection information has obvious performance bene-
fits, but can be dangerous if not handled in a very conservative
fashion. In order for a redirection to be safely refreshed, all of
the following conditions must hold:
1. The source address of the received PDU must be exactly the same
as the destination address specified in a prior RD PDU (this
defines a "match" on the redirection information). Making
assumptions about the equivalence of abbreviated addresses,
group addresses, or similar "special" addresses is dangerous
since routing for these addresses cannot be assumed to be
the same.
2. The Quality of Service parameters of the received PDU must be
exactly the same as the QoS parameters specified in the matching
(by destination address) redirection entry.Again, there is no
guarantee that PDUs with different QoS parameters will be routed
the same way. It is quite possible that the redirected path is
even a black hole for certain values of the QoS parameters (the
security field is a good example).
3. The "previous hop" of the received Data PDU must match the "next
hop" stored in the redirection information. Specifically, the
SN_Source_Address of the SN_UNITDATA.Indication which received the
PDU must match exactly the SN_Destination_Address specified in the
redirect to be used for sending traffic via the SN_UNITDATA.Request
primitive. This comparison ensures that redirects are refreshed only
when the reverse traffic is being received from the same IS (or
destination ES) as the forward traffic is being sent through (or
to). This check make certain that redirects are not refreshed for
just on the basis of traffic being received from the destination.
It is quite possible that the traffic is simply indicating that the
forward path in use is not working!
Note that these conditions still allow refresh in the most useful and
common cases where either the destination is another ES on the same
subnetwork as the source ES, or the redirection is to a IS which is
passing traffic to/from the destination in both directions (i.e. the
path is symmetric).
A.3 System Initialization Considerations
This protocol is designed to make the exchange of information as free
as possible from dependencies between the two types of systems.
therefore, it is not possible for an End System to request all Inter-
mediate Systems on a subnetwork to report their configuration, nor is
it possible for an Intermediate System to request all End Systems on
a subnetwork to report their configuration.
In certain operating environments a constraint may be imposed than an
ES, upon becoming operational, must discover the existence of an IS
as soon as possible.The converse relationship also holds if it is
necessary for an IS to discover the existence of End Systems as soon
as possible. In both cases the availability of this information is
normally determined by the Configuration Timer of the system for
which the knowledge is desired. there is therefore a tradeoff between
the overhead associated with performing the Report and Record Confi-
guration functions and the timely availability of the configuration
information. Decreasing the Configuration Timer increases the availa-
bility at the expense of an increase in overhead.
The following solution is recommended for addressing the constraint
described above. When the Record Configuration function is invoked in
either an End System or an Intermediate System, the function will
determine if the received configuration information was previously
unknown.If this is the case, then the Report Configuration function
may be invoked before the expiration of the system's Configuration
Timer. The Hello PDU generated by the Report Configuration function
is then sent only to the Network Entity whose configuration was pre-
viously unknown. Thus when an ES or IS first becomes operational it
immediately reports its configuration. As soon as systems of the oth-
er type discover the new network entity, they will make their own
configuration known to this entity.
The additional overhead incurred by this solution is minimal. Also,
since the discovery of new configurations is made timely by this ap-
proach the Configuration Timer period can be increased in order to
decrease the overhead of the configuration functions, provided that
other factors not discussed here are accounted for by the longer time
period.One caveat is that the first Hello PDU generated by a system
may be lost during transmission. To solve this problem one or more
additional PDUs may be transmitted at short time intervals during
this initialization period.
Note that this solution may be implemented in ISs only, in ESs only,
or in both Intermediate and End Systems.This decision is purely a lo-
cal matter and may be alterable through System Management.
A.4 Optimizations for Flushing Redirects
An ES will attempt to forward NPDUs through an IS to which it has
been redirected until the Holding Timer specified in the RD PDU has
expired, even if that IS is no longer reachable. Under certain cir-
cumstances, it is possible to do better and recognize the existence
of a black hole sooner. In particular, if the ES expects to hear ISH
PDUs from the IS to which it has been redirected, and the Holding Ti-
mer for that IS expires, all knowledge of the IS may be forgotten by
the ES. This includes any redirects, which may be flushed (see the
Flush Old Redirect function) even though their timeouts have not ex-
pired.