of the ER PDU determines that the size of the ER PDU exceeds the max-
imum service data unit size of the underlying service, the ER PDU
shall be truncated to the maximum service data unit size (see Clause
5.5.3) and forwarded with no other change. Error Report PDUs are
routed and forwarded by intermediate-system network-entities in the
same way as Data PDUs.
Note:
The requirement that the underlying service assumed by the CLNP
must be capable of supporting a service data unit size of at least
512 octets guarantees that the entire header of the discarded Data
PDU can be conveyed in the data field of any ER PDU.
When an ER PDU is decomposed upon reaching its destination, informa-
tion that may be used to interpret and act upon the Error Report is
obtained as follows. The network-entity title recovered from the NPAI
in the Source Address field of the ER PDU header is used to identify
the network-entity which generated the Error Report. The reason for
generating the Error Report is extracted from the Options Part of the
PDU header. The entire header of the discarded Data PDU (and part or
all of the original user data) is extracted from the data field of
the ER PDU to assist in determining the nature of the error.
6.10.4 Relationship of Data PDU Options to Error Reports
The generation of an Error Report is affected by options that are
present in the corresponding Data PDU. The presence of options in the
original Data PDU that are not supported by the system which has dis-
carded that PDU may cause the suppression of an Error Report even if
the original Data PDU indicated that an Error Report should be gen-
erated in the event of a discard.
The processing of an Error Report is also affected by options which
are present in the corresponding Data PDU. In particular, options
selected for the original Data PDU affect which options are included
in the corresponding Error Report PDU. The selection of options for
an Error Report PDU is governed by the following requirements:
(a) If the Priority Option or the QoS Maintenance Option is selected
in the original Data PDU, and the system generating the Error
Report PDU supports the option, then the Error Report PDU shall
specify the option.
(b) If the Security Option is selected in the Data PDU, and the system
generating the Error Report supports this option, then the Error
Report PDU shall specify the option using the value that was
specified in the original Data PDU. If the system does not support
the Security Option, an Error Report must not be generated for
a Data PDU that selects the Security Option.
(c) If the Complete Source Route Option is selected in the original
Data PDU, and the system generating the Error Report PDU supports
this option, then the error Report shall specify the Complete Source
Route option. The Source Route parameter value is obtained by
extracting from the original Data PDU that portion of the complete
source route that has already been traversed, and reversing the
order of network-entity titles which comprise the list.
If the system does not support the Complete Source Route Option,
an Error Report must not be generated for a Data PDU that selects
the Complete Source Route option.
(d) The Padding, Partial Source Routing, and Record Route Options,
if supported, may be specified in the Error Report PDU.
Note:
The values of the optional parameters in (d) above may be
derived as a local matter, or they may be based upon the
corresponding values in the original Data PDU.
6.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 veri-
fied at each point at which the PDU header is processed. If the
checksum calculation fails, the PDU must be discarded. If PDU header
fields are modified (for example, due to operation of the lifetime
function), then the checksum is modified so that the checksum remains
valid.
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 formulae to be sa-
tisfied:
(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.
Note:
1. To ensure that inadvertent modification of a header while a
PDU is being processed by an intermediate system (for
example, due to a memory fault) may still be detected by the
PDU Header Error function, an intermediate system network-
entity must not recompute the checksum for the entire header,
even if fields are modified.
2. Annex C contains descriptions of algorithms which may be
used to calculate the correct value of the checksum field
when the PDU is created, and to update the value of the
checksum field when the header is modified.
6.12 Padding Function
The padding function is provided to allow space to be reserved in the
PDU header which is not used to support any other function. Octet
alignment must be maintained.
Note:
An example of the use of this function is to cause the data field
of a PDU to begin on a convenient boundary for the originating
network-entity, such as a computer word boundary.
6.13 Security
The provision of protection services (e.g., data origin authentica-
tion, data confidentiality, and data integrity of a single
connectionless-mode NSDU) is performed by the Security Function.
The Security Function is related to the Protection from Unauthorized
Access Quality of Service parameter described in ISO 8348/AD1, Adden-
dum to the Network Service Definition Covering Connectionless-mode
Transmission. The function is realized through selection of the secu-
rity parameter in the options part of the PDU header.
This Standard does not specify the way in which protection services
are to be provided; it only provides for the encoding of security in-
formation in the PDU header. To facilitate interoperation between
end-systems and network relay-systems by avoiding different interpre-
tations of the same encoding, a means to distinguish user-defined
security encodings from standardized security encodings is described
in Clause 7.5.3.
Note:
As an implementation consideration, data origin authentication
may be provided through the use of a cryptographically generated
or enciphered checksum (unique from the PDU Header Error Detection
mechanism); data confidentiality and data integrity may be
provided via route control mechanisms.
6.14 Source Routing Function
The Source Routing function allows the originator to specify the path
a generated PDU must take. Source routing may only be selected by the
originator of a PDU. Source Routing is accomplished using a list of
network-entity titles held in a parameter within the options part of
the PDU header. The length of this parameter is determined by the
originating network-entity, and does not change as the PDU traverses
the network.
The Source Route parameter includes information used by the originat-
ing end-system when determining the initial route of the PDU. Only
the titles of intermediate system network-entities are included in
the list; the network-entity title of the destination of the PDU is
not included in the list.
Associated with the list of network-entity titles is an indicator
which identifies the next entry in the list to be used; this indica-
tor is advanced by the receiver of the PDU when the next title in the
list matches its own. The indicator is updated as the PDU is forward-
ed so as to identify the appropriate entry at each stage of relaying.
Two forms of the Source Routing function are provided. The first
form, referred to as Complete Source Routing, requires that the
specified path must be taken; that is, only those systems identified
in the list may be visited by the PDU while en route to the destina-
tion, and each system must be visited in the order specified. If the
specified path cannot be taken, the PDU must be discarded. Clause
6.10 describes the circumstances in which an attempt shall be made to
inform the originator of the discard using the Error Reporting func-
tion.
The second form is referred to as Partial Source Routing. Again, each
system identified in the list must be visited in the order specified
while en route to the destination. However, with this form of source
routing the PDU may take any path necessary to arrive at the next in-
termediate system in the list, which may include visiting intermedi-
ate systems that are not identified in the list. The PDU will not be
discarded (for source routing related reasons) unless one of the sys-
tems specified cannot be reached by any available route.
6.15 Record Route Function
The Record Route function records the path(s) taken by a PDU as it
traverses a series of intermediate systems. A recorded route consists
of a list of network-entity titles held in a parameter within the op-
tions part of the PDU header. The length of this parameter is deter-
mined by the originating network-entity, and does not change as the
PDU traverses the network.
The list is constructed as the PDU is forwarded along a path towards
its destination. Only the titles of intermediate system network-
entities are included in the recorded route. The network-entity title
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 adds its own networkentity ti-
tle at the end of the list of recorded network-entity titles. An in-
dicator is maintained to identify the next available octet to be used
for recording of route. This indicator is updated as entries are ad-
ded to the list as follows. The length of the entry to be added to
the list is added to the value of the next available octet indicator,
and this sum is compared with the length of the Record Route parame-
ter. If the addition of the entry to the list would exceed the size
of the parameter, the next available octet indicator is set to indi-
cate that route recording has been terminated. The network-entity ti-
tle is not added to the list. The PDU may still be forwarded to its
final destination, without further addition of network-entity titles.
If the addition of the entry would not exceed the size of the Record
Route parameter, the next available octet indicator is updated with
the new value, and the network-entity title is added to the head of
the list after the other entries have been moved.
Two forms of the Record Route function are provided. The first form
is referred to as Complete Route Recording. It requires that the
list of network-entity titles be a complete and accurate record of
all intermediate systems visited by a PDU (including Derived PDUs),
except when a shortage of space in the record route option field
causes termination of recording of route, as described above. When
Complete Route Recording is selected, PDU reassembly at intermediate
systems is performed only when the Derived PDUs that are reassembled
all took the same route; otherwise, the PDU is discarded, and if
selected, an Error Report is generated (see Clause 6.10).
The second form is referred to as Partial Route Recording. It also
requires a record of intermediate systems visited by a PDU. When Par-
tial Route Recording is selected, PDU reassembly at intermediate sys-
tems is always permitted. When reassembly is performed at an inter-
mediate system, the route recorded in any of the Derived PDUs may be
placed in the PDU resulting from the reassembly.
Note:
The Record Route function is intended to be used in the diagnosis
of subnetwork problems and/or to provide a return path that could
be used as a source route in a subsequent PDU.
6.16 Quality of Service Maintenance Function
The Quality of Service Maintenance function provides information to
network-entities in intermediate systems which may be used to make
routing decisions where such decisions affect the overall QoS provid-
ed to NS users. This information is conveyed to intermediate system
network- entities in a parameter in the options part of the PDU
header.
In those instances where the QoS requested cannot be maintained, in-
termediate system network-entities shall attempt to deliver the PDU
at a QoS different from the QoS requested. Intermediate system
network-entities do not necessarily provide a notification of failure
to meet the requested Quality of Service.
6.17 Priority Function
The Priority function allows a PDU with a numerically higher priority
value to be processed preferentially with respect to other PDUs with
numerically lower priority values. The function is realized through
selection of a parameter in the options part of the PDU header.
The lowest priority value is zero; a source network-entity that does
not support the Priority function must set the Priority value to
zero. The Priority function provides a means whereby the resources
of end and intermediate system network-entities, such as outgoing
transmission queues and buffers, can be used preferentially to pro-
cess higher-priority PDUs ahead of lower-priority PDUs. The specific
action taken by an individual network-entity to support the Priority
function is a local matter.
6.18 Congestion Notification Function
To allow NS Users to take appropriate action when congestion is ex-
perienced within the NS provider, intermediate systems may inform the
destination network-entity of congestion through the use of a flag in
the QoS Maintenance parameter in the options part of the PDU header.
The value of this flag is initially set to zero (0) by the originator
of the PDU and may be set to one (1) by any intermediate system which
processes the PDU to indicate that it is experiencing congestion. The
criteria for determining when this action is to be taken are a local
matter.
Note:
Congestion typically corresponds to inavailability of buffer space
to maintain output queues. An appropriate policy for indicating
congestion may be based upon the depth of the output queue selected
for a PDU (according to its destination address or other routing
information). When the depth of a particular output queue exceeds
a certain proportion of the depth of that queue, an intermediate
system will start to discard PDUs. The intermediate system will set
the Congestion Experienced flag in the next PDU to be forwarded
and may continue to do so until the condition is alleviated.
6.19 Classification of Functions
Implementations are not required to support all of the functions
described in Clauses 6.1 through 6.18. 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 in a PDU, then that PDU must be discarded,
and an Error Report PDU must be generated and forwarded to the
originating network-entity, providing that the Error Report flag is
set and the conditions of Clause 6.10.4 are satisfied.
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 in a PDU, then the function is not performed,
and the PDU is processed exactly as though the function had not
been selected. The protocol data unit shall not be discarded for
this reason.
Table 4 shows how the functions are divided into these three categories:
_____________________________________________________________________________
| | FULL | NON | INACTIVE |
| FUNCTION | PROTOCOL | SEGMENTING | SUBSET |
| | | SUBSET | |
|________________________________|_____________|_________________|____________|
|PDU Composition | 1 | 1 | 1 |
|PDU Composition | 1 | 1 | 1 |
|Header Format Analysis | 1 | 1 | 1 |
|PDU Lifetime Control | 1 | 1 | N/A |
|Route PDU | 1 | 1 | N/A |
|Forward PDU | 1 | 1 | N/A |
|Segment PDU | 1 | N/A | N/A |
|Reassemble PDU | 1 | N/A | N/A |
|Discard PDU | 1 | 1 | N/A |
|Error Reporting (Note 1) | 1 | 1 | N/A |
|Header Error Detection (Note 1) | 1 | 1 | N/A |
|Security | 1 | 2 | N/A |
|Complete Source Routing | 1 | 2 | N/A |
|Complete Route Recording | 2 | 2 | N/A |
|Partial Source Routing | 3 | 3 | N/A |
|Partial Route Recording | 3 | 3 | N/A |
|Priority | 3 | 3 | N/A |
|QoS Maintenance | 3 | 3 | N/A |
|Congestion Notification | 3 | 3 | N/A |
|Padding | 3 | 3 | N/A |
|________________________________|_____________|_________________|____________|
Table 4: Categorization of Protocol Functions
Note:
1. While the Error Reporting and Header Error Detection functions
must be provided, they are provided only when selected
by the sending Network Service user.
2. 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; they cannot cause a PDU to be discarded
when they are not supported.
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 submitted to the underlying service.
The bits in an octet are numbered from one (1) to eight (8), where
bit one (1) is the low-order (least significant) bit.
When consecutive octets are used to represent a binary number, the
lower octet number has the most significant value.
Any implementation supporting this protocol is required to state in
its specification the way in which 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
Clause 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 address part;
3. the segmentation part, if present;
4. the Options part, if present;
and the data field, if present. This structure is illustrated in Figure 2:
7.2 Fixed Part
7.2.1 General
The fixed part of the PDU header contains frequently occurring param-
eters 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:
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 2: PDU Structure
Octet
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| Lifetime | 4
|______________________________________|
| SP vline M S vline e/R | Type | 5
|______________________________________|
| Segment Length | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
Figure 3: PDU Header -- Fixed Part
7.2.2 Network Layer Protocol Identifier
The value of this field is set to binary 1000 0001 to identify this
Network Layer protocol as ISO 8473, Protocol for Providing the
Connectionless- mode Network Service. The value of this field is set
to binary 0000 0000 to identify the Inactive Network Layer protocol
subset.
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 Clause 7.1. The value 255 (1111 1111) is
reserved for possible future extensions.
Note:
The rules for forwarding and segmentation guarantee 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.
The size of a PDU header will not change due to operation of any
protocol function.
7.2.4 Version/Protocol Identifier Extension
The value of this field is binary 0000 0001, which identifies the
standard Version 1 of ISO 8473, Protocol for Providing the
Connectionless-mode Network Service.
7.2.5 PDU Lifetime
The PDU Lifetime field is encoded as a binary number representing the
remaining lifetime of the PDU, in units of 500 milliseconds.
7.2.6 Flags
7.2.6.1 Segmentation Permitted
The Segmentation Permitted flag indicates whether segmentation is
permitted. Its value is determined by the originator of the PDU and
cannot be changed by any other network-entity for the lifetime of the
Initial PDU and any Derived PDUs.
A value of one (1) indicates that segmentation is permitted. A value
of zero (0) indicates that the non-segmenting protocol subset is em-
ployed. When the value of zero is selected, the segmentation part of
the PDU header is not present, and the Segment Length field serves as
the Total Length field (see Clause 7.2.8).
7.2.6.2 More Segments
The More Segments flag indicates whether the data segment in this PDU
contains (as its last octet) the last octet of the User Data in the
NSDU. When the More Segments flag is set to one (1), segmentation
has taken place and the last octet of the NSDU is not contained in
this PDU. The More Segments flag cannot be set to one (1) if the Seg-
mentation Permitted flag is not set to one (1).
When the More Segments flag is set to zero (0), the last octet of the
Data Part of the PDU is the last octet of the NSDU.
7.2.6.3 Error Report
When the Error Report flag is set to one, the rules in Clause 6.10
are used to determine whether to generate an Error Report PDU if it
is necessary to discard this Data PDU.
When the Error Report flag is set to zero, discard of the Data PDU
will not cause the generation of an Error Report PDU.
7.2.7 Type Code
The Type code field identifies the type of the protocol data unit.
Allowed values are given in Table 5:
__________________________________________________
| | Bits 5 4 3 2 1 |
|_________|______________________________________|
| DT PDU | 1 1 1 0 0 |
|_________|______________________________________|
| ER PDU | 0 0 0 0 1 |
|_________|______________________________________|
Table 5: Valid PDU Types
7.2.8 PDU Segment Length
The Segment Length field specifies the entire length, in octets, of
the Derived PDU, including both header and data (if present). When
the full protocol is employed and a PDU is not segmented, the value
of this field is identical to the value of the Total Length field lo-
cated in the Segmentation Part of the header.
When the non-segmenting protocol subset is employed, no segmentation
part is present in the header. In this subset, the Segment Length
field specifies the entire length of the Initial PDU, including both
header and data (if present). The Segment Length field is not changed
for the lifetime of the PDU.
7.2.9 PDU Checksum
The checksum is computed on the entire PDU header. For the Data PDU,
this includes the segmentation and options parts (if present). For
the Error Report PDU, this includes the reason for discard field as
well.
A checksum value of zero is reserved to indicate that the checksum is
to be ignored. The operation of the PDU Header Error Detection func-
tion (Clause 6.11) ensures that the value zero does not represent a
valid checksum. A non-zero value indicates that the checksum must be
processed. If the checksum calculation fails, the PDU must be dis-
carded.
7.3 Address Part
7.3.1 General
Address parameters are distinguished by their location, immediately
following the fixed part of the PDU header. The address part is il-
lustrated Figure 4:
Octet
____________________________________________
| Destination Address Length Indicator | 10
|___________________________________________|
| | 11
: Destination Address :
| | m - 1
|___________________________________________|
| Source Address Length Indicator | m
|___________________________________________|
| | m + 1
: Source Address :
| | n - 1
|___________________________________________|
Figure 4: PDU Header -- Address Part
7.3.1.1 Destination and Source Addresses
The Destination and Source addresses used by this protocol are Net-
work Service Access Point addresses as defined in ISO 8348/AD2, Ad-
dendum to the Network Service Definition Covering Network Layer Ad-
dressing.
The Destination and Source Addresses are variable length. The Desti-
nation and Source Address fields are encoded as Network Protocol Ad-
dress Information using the Preferred Binary Encoding defined in
Clause 8.3.1 of ISO 8348/AD2.
The Destination Address Length Indicator field specifies the length
of the Destination Address in octets. The Destination Address field
follows the Destination Address Length Indicator field.
The Source Address Length Indicator field specifies the length of the
Source Address in octets. The Source Address Length Indicator field
follows the Destination Address field. The Source Address field fol-
lows the Source Address Length Indicator field.
Each address parameter is encoded as illustrated in Table 5:
______________________________________________
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|________|____________________________________|
| Octets | |
| n + 1 | Address Parameter Value |
| thru | |
| n + m | |
|________|____________________________________|
Figure 5: Address Parameters
7.4 Segmentation Part
If the Segmentation Permitted Flag in the Fixed Part of the PDU
Header (Octet 4, Bit 8) is set to one, the segmentation part of the
header, illustrated in Figure 6, must be present:
If the Segmentation Permitted flag is set to zero, the non-segmenting
protocol subset is in use.
Octet
________________________
| Data Unit Identifier | n, n + 1
|______________________|
| Segment Offset | n + 2, n + 3
|______________________|
| Total Length | n + 4, n + 5
|______________________|
Figure 6: PDU Header -- Segmentation Part
7.4.1 Data Unit Identifier
The Data Unit Identifier identifies an Initial PDU (and hence, its
Derived PDUs) so that a segmented data unit may be correctly reassem-
bled. The Data Unit Identifier size is two octets.
7.4.2 Segment Offset
For each Derived PDU, the Segment Offset field specifies the relative
position of the segment contained in the data field of the Derived
PDU with respect to the start of the data field of the Initial PDU.
The offset is measured in units of octets. The offset of the first
segment (and hence, the Initial PDU) is zero; an unsegmented (Initial
PDU) has a segment offset value of zero (0). The value of this field
shall be a multiple of eight 8).
7.4.3 PDU Total Length
The Total Length field specifies the entire length of the Initial
PDU, including both the header and data. This field is not changed
for the lifetime of the Initial PDU (and hence, its Derived PDUs).
7.5 Options Part
7.5.1 General
The options part is used to convey optional parameters. The options
part of the PDU header is illustrated below:
Octet
___________________________________________________
| | n + 6
: Options :
| | p
|__________________________________________________|
Figure 7: PDU Header -- 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 Protocol Data
Unit with an option duplicated should be treated as a protocol error.
The rules governing the treatment of protocol errors are described in
Clause 6.10, Error Reporting Function.
The encoding of parameters contained within the options part of the
PDU header is illustrated in Table 6:
Octets
___________________________________________
| n | Parameter Code |
|____________|____________________________|
| n + 1 | Parameter Length (e.g.m) |
|____________|____________________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|____________________________|
Table 6: Encoding of 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 seg-
mentation 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.
7.5.2 Padding
The padding parameter is used to lengthen the PDU header to a con-
venient size (See Clause 6.12).
Parameter Code: 1100 1100
Parameter Length: variable
Parameter Value: any value is allowed
7.5.3 Security
This parameter allows a unique and unambiguous security level to be
assigned to a protocol data unit.
Parameter Code: 1100 0101
Parameter Length: variable
Parameter Value: The high order two bits of the first octet
specify the Security Format Code, where:
Security Type of Security Field:
Format Code
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally Unique
The rest of the first octet is reserved and must be zero. The
remainder of the Parameter Value field specifies the security
level as described in the following Clauses.
7.5.3.1 Source Address Specific
The Security Format Code value of binary "01" indicates that the
remaining octets of the parameter value field specify a security lev-
el which is unique and unambiguous in the context of the security
classification system employed by the authority responsible for as-
signing the source NSAP Address.
7.5.3.2 Destination Address Specific
The Security Format Code value of binary "10" indicates that the
remaining octets of the parameter value field specify a security lev-
el which is unique and unambiguous in the context of the security
classification system employed by the authority responsible for as-
signing the destination NSAP Address.
7.5.3.3 Globally Unique Security
The Security Format Code value of binary "11" indicates that the
remaining octets of the parameter value field specify a globally
unique and unambiguous security level. This security classification
system is not specified in this Standard.
7.5.4 Source Routing
The source routing parameter specifies, either completely or partial-
ly, the route to be taken from Source Network Address to Destination
Network Address.
Parameter Code: 1100 0101
Parameter Length: variable
Parameter Value: 2 octets of control information succeeded by a
concatenation of ordered network-entity title entries (ordered
from source to destination)
The first octet of the parameter value is the type code, and has the
following significance:
0000 0000 partial source routing
0000 0001 complete source routing
<all other values reserved>
The second octet indicates the octet offset of the next network-
entity title entry to be processed in the list. It is relative to
the start of the parameter, such that a value of three (3) indicates
that the next network-entity title entry begins immediately after
this control octet. Successive octets are indicated by corresponding-
ly larger values of this indicator.
The third octet begins the network-entity title list. The list con-
sists of variable length network-entity title entries. The first oc-
tet of entry identifies the length of the network-entity title which
comprises the re- mainder of the entry.
7.5.5 Recording of Route
The recording of route parameter identifies the route of intermediate
systems traversed by the PDU.
Parameter Code: 1100 1011
Parameter Length: variable
Parameter Value: 2 octets of control information succeeded by a
con catenation of ordered network-entity title entries (ordered
from destination to source)
The first octet of the parameter value is the type code, and has the
following significance:
0000 0000 Partial Recording of Route in progress
0000 0001 Complete Recording of Route in progress
<all other values reserved>
The second octet identifies the first octet not currently used for a
recorded network-entity title, and therefore also the end of the
list. It is encoded relative to the start of the parameter value,
such that a value of three (3) indicates that no network-entity ti-
tles have yet been recorded. A value of all ones is used to indicate
that route recording has been terminated.
The third octet begins the network-entity title list. The list con-
sists of variable length network-entity title entries. The first oc-
tet of each entry specifies the length of the network-entity title
comprising the remainder of the entry. Network-entity title entries
are always added to the beginning of the list; that is, the most re-
cently added entry will begin in the third octet of the parameter
value.
Note:
The length of the Record Route parameter is determined by the
originator of the PDU and is not changed during the lifetime of
the PDU; hence, the operation of the Record Route function does
not affect the length of the header.
7.5.6 Quality of Service Maintenance
The Quality of Service parameter conveys information about the quali-
ty of service requested by the originating Network Service user.
Network-entities in intermediate systems may (but are not required
to) make use of this information as an aid in selecting a route when
more than one route satisfying other routing criteria is available
and the available routes are known to differ with respect to Quality
of Service see Clause 6.16).
Parameter Code: 1100 0011
Parameter Length: variable
Parameter Value: The high order two bits of the first octet
specify the QoS Format Code, where:
QoS Format Type of QoS
Code Field
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally Unique
The rest of the first octet is reserved and must be zero. The
remainder of the Parameter Value field specifies the QoS as described
in the following Clauses.
7.5.6.1 Source Address Specific
The QoS Format Code value of binary "01" indicates that the remaining
octets of the parameter value field specify a QoS which is unique and
unambiguous in the context of the QoS Maintenance system employed by
the authority responsible for assigning the source NSAP Address.
7.5.6.2 Destination Address Specific
The QoS Format Code value of binary "10" indicates that the remaining
octets of the parameter value field specify a QoS which is unique and
unambiguous in the context of the QoS Maintenance system employed by
the authority responsible for assigning the destination NSAP Address.
7.5.6.3 Globally Unique QoS
The QoS Format Code value of binary "11" indicates that the remainder
of the parameter value field specifies a globally unique QoS Mainte-
nance field. When the globally unique QoS Maintenance function is em-
ployed, the parameter value field must have a total length of one oc-
tet, which is assigned the following values:
Bits 8 and 7: QoS Format Code of binary "11"
Bit 6: Reserved
Bit 5: sequencing vs. transit delay
Bit 4: congestion experienced
Bit 3: transit delay vs. cost
Bit 2: residual error probability vs. transit delay
Bit 1: residual error probability vs. cost
Bit 5 is set to one to indicate that, where possible, routing deci-
sions should favor sending all PDUs to the specified destination NSAP
address over a single path (in order to maintain sequence) over
minimizing transit delay. A value of zero (0) indicates that, where
possible, routing decisions should favor low transit delay over se-
quence preservation.
Bit 4 is set to zero by the network-entity which originates the pro-
tocol data unit. It is set to one by an intermiediate system to indi-
cate that this PDU has visited a congested intermediate system, and
appropriate action should be taken by the destination network-entity.
Once the congestion experienced bit is set by an intermediate system,
it may not be reset by any intermediate system traversed by the PDU
further along the path towards the destination.
Bit 3 is set to one to indicate that, where possible, routing deci-
sions should favor low transit delay over low cost. A value of 0 in-
dicates that routing decisions should favor low cost over low transit
delay.
Bit 2 set to one to indicate that, where possible, routing decisions
should favor low residual error probability over low transit delay.
A value of zero indicates that routing decisions should favor low
transit delay over low residual error probability.
Bit 1 is set to one to indicate that, where possible, routing deci-
sions should favor low residual error probability over low cost. A
value of 0 indicates that routing decisions should favor low cost
over low residual error probability.
7.5.7 Priority
The value of the Priority parameter indicates the relative priority
of the protocol data unit. Intermediate systems that support this
option shall make use of this information in routing and in ordering
PDUs for transmission.
Parameter Code: 1100 1101
Parameter Length: one octet
Parameter Value: 0000 0000 - Normal (Default) through
0000 1110 - Highest
<all other values reserved>
The values 0000 0001 through 0000 1110 are to be used for higher
priority protocol data units. If an intermediate system does not sup-
port this option, all PDUs shall be treated as if the field had the
value 0000 0000.
7.6 Data Part
The Data part of the PDU is structured as an ordered multiple of oc-
tets, which is identical to the same ordered multiple of octets
specified for the NS-Userdata parameter of the N-UNITDATA Request and
Indication primitives. The data field is illustrated in Figure 8:
Octet
___________________________________________________
| | p + 1
: Data :
| | z
|__________________________________________________|
Figure 8: PDU Header -- Data Field
7.7 Data (DT) PDU
7.7.1 Structure
The DT PDU has the following format:
__________________________________________
| Network Layer Protocol Identifier | 1
|________________________________________|
| Length Indicator | 2
|________________________________________|
| Version/Protocol Id Extension | 3
|________________________________________|
| Lifetime | 4
|________________________________________|
| S P vline M S vline e/R | Type | 5
|____________________________|___________|
| Segment Length | 6,7
|________________________________________|
| Checksum | 8,9
|________________________________________|
| Destination Address Length Indicator | 10
|________________________________________|
| | 11
: Destination Address :
|________________________________________| m - 1
| Source Address Length Indicator | m
|________________________________________|
| | m + 1
: Source Address :
| | n - 1
|________________________________________|
| Data Unit Identifier | n, n + 1
|________________________________________|
| Segment Offset | n + 2, n + 3
|________________________________________|
| Total Length | n + 4, n + 5
|________________________________________|
| | n + 6
| Options |
| | p
|________________________________________|
| | p + 1
| Data |
| | z
|________________________________________|
Figure 9: DT PDU
7.7.1.1 Fixed Part
1) Network Layer Protocol Identifier See Clause 7.2.2
2) Length Indicator See Clause 7.2.3
3) Version/Protocol Id Extension See Clause 7.2.4
4) Lifetime See Clause 7.2.5
5) SP, MS, E/R See Clause 7.2.6
6) Type Code See Clause 7.2.7
7) Segment Length See Clause 7.2.8
8) Checksum See Clause 7.2.9
7.7.1.2 Addresses
See Clause 7.3.
7.7.1.3 Segmentation
See Clause 7.4.
7.7.1.4 Options
See Clause 7.5.
7.7.1.5 Data
See Clause 7.7.
7.8 Inactive Network Layer Protocol
Octet
____________________________________
|Network Layer Protocol Identifier | 1
|__________________________________|
| | 2
| Data |
| | 2 - n
|__________________________________|
Figure 10: Inactive Network Layer Protocol
7.8.1 Network Layer Protocol Id
The value of the Network Layer Protocol Identifier field is binary
zero (0000 0000).
7.8.2 Data Field
The length of the NS-Userdata parameter is constrained to be less
than or equal to the value of the length of the SN-Userdata parameter
minus one (see Clause 7.7).
7.9 Error Report PDU (ER)
7.9.1 Structure
The ER PDU has the following format:
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|____________________________________________|
| Length Indicator | 2
|____________________________________________|
| Version/Protocol Id Extension | 3
|____________________________________________|
| Lifetime | 4
|____________________________________________|
| SP= 0 vline MS= 0 vline Reserved | Type | 5
|_____________________________________|______|
| Segment Length | 6,7
|____________________________________________|
| Checksum | 8,9
|____________________________________________|
| Destination Address Length Indicator | 10
|____________________________________________|
| | 11
: Destination Address :
| | m - 1
|____________________________________________|
| Source Address Length Indicator | m
|____________________________________________|
| | m + 1
: Source Address :
| | n - 1
|____________________________________________|
| | n
| Options |
| | p - 1
|____________________________________________|
| | p
| Reason for Discard |
| | q - 1
|____________________________________________|
| | q
| Error Report Data Field |
| | z
|____________________________________________|
Figure 11: Error Report PDU
7.9.1.1 Fixed Part
The fixed part of the Error Report Protocol Data Unit is composed in
the same way as a new (Initial) Data PDU. References are provided to
previous Clauses describing the encoding of the fields comprising the
fixed part:
1) Network Layer Protocol Identifier See Clause 7.2.2
2) Length Indicator See Clause 7.2.3
3) Version/Protocol Id Extension See Clause 7.2.4
4) Lifetime See Clause 7.2.5
5) SP, MS, E/R Always set to zero,
(See Clause 6.10)
6) Type Code See Clause 7.2.7
7) Segment Length See Clause 7.2.8
8) Checksum See Clause 7.2.9
7.9.1.2 Addresses
See Clause 7.3.
The Destination Address specifies the network-entity title of the origi-
nator of the discarded PDU. The Source Address specifies the title of the
intermediate-system or end-system network-entity initiating the Error
Report PDU.
7.9.1.3 Options
See Clause 7.5.
7.9.1.4 Reason for Discard
This parameter is valid only for the Error Report PDU.
Parameter Code: 1100 0001
Parameter Length: two octets
Parameter Value: type of error encoded in binary. Values are listed
in Table 7:
_______________________________________________________________________________
| Parameter Value | Class of | Meaning |
| Octet 1 Octet 2| Error | |
|__________________|_____________|_____________________________________________|
| 0000 0000 | | Reason not specified |
| 0001 | | Protocol Procedure Error |
| 0010 | | Incorrect Checksum |
| 0011 | General | PDU Discarded due to Congestion |
| 0100 | | Header Syntax Error (cannot be parsed) |
| 0101 | | Segmentation needed but not permitted |
| 0110 | | Incomplete PDU Received |
| 0111 | | Duplicate Option |
|__________________|_____________|_____________________________________________|
| 1000 0000 | Address | Destination Address Unreachable |
| 0001 | | Destination Address Unknown |
|__________________|_____________|_____________________________________________|
| 1001 0000 | | Unspecified Source Routing Error |
| 0001 | Source | Syntax Error in Source Routing Field |
| 0010 | Routing | Unknown Address in Source Routing Field |
| 0011 | | Path not Acceptable |
|__________________|_____________|_____________________________________________|
| 1010 0000 | Lifetime | Lifetime Expired while Data Unit in Transit |
| 0001 | | Lifetime Expired during Reassembly |
|__________________|_____________|_____________________________________________|
| 1011 0000 | | Unsupported Option not Specified |
| 0001 | PDU | Unsupported Protocol Version |
| 0010 | Discarded | Unsupported Security Option |
| 0011 | | Unsupported Source Routing Option |
| 0100 | | Unsupported Recording of Route Option |
|__________________|_____________|_____________________________________________|
| 1100 0000 | Reassembly | Reassembly interference |
|__________________|_____________|_____________________________________________|
Table 7: Reasons for Discard
The first octet of the parameter value contains an error type code.
If the error in the discarded Data PDU can be localized to a particu-
lar field, the number of the first octet of that field is stored in
the second octet of the reason for discard parameter field. If the
error cannot be localized to a particular field, or if the error is a
checksum error, then the value zero is stored in the second octet of