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:
RFC926 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
RFC926 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.
RFC926 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
RFC926 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
RFC926 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.
RFC926 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 units of 500 milliseconds.
The Lifetime field is set by the originating network-entity, and is
decremented by every network-entity which processes the PDU. The PDU
shall be discarded if the value of the field reaches zero.
When a network-entity processes a PDU, it decrements the Lifetime by
at least one. The Lifetime shall be decremented by more than one if
the sum of:
1) the transit delay in the subnetwork from which the PDU was
received; and
RFC926 December 1984
2) the delay within the system processing the PDU
exceeds or is estimated to exceed 500 milliseconds. In this case, the
lifetime field should be decremented by one for each additional 500
milliseconds of delay. The determination of delay need not be
precise, but where error exists the value used shall be an
overestimate, not an underestimate.
If the Lifetime reaches a value of zero before the PDU is delivered
to the destination, the PDU shall be discarded. The Error Reporting
function shall be invoked, as described in Section 6.10, Error
Reporting Function, and may result in the generation of an ER PDU. It
is a local matter whether the destination network-entity performs the
Lifetime Control function.
When the Segmentation function is applied to a PDU, the Lifetime
field is copied into all of the Derived PDUs.
7.2.6 Flags
7.2.6.1 Segmentation Permitted and More Segments Flags
The Segmentation Permitted flag determines whether segmentation is
permitted. A value of one indicates that segmentation is permitted.
A value of zero indicates that the non-segmenting protocol subset is
employed. Where this is the case, the segmentation part of the PDU
header is not present, and the Segment Length field serves as the
Total Length field.
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) then
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 Segmentation Permitted flag is not set to one (1).
RFC926 December 1984
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.2 Error Report Flag
When the Error Report flag is set to one, the rules in Section 6.10
are used to determine whether to generate an Error Report PDU upon
discard of the PDU.
When the Error Report flag is set to zero, discard of the 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 7-1:
Bits 5 4 3 2 1
+-----------------------------+
| DT PDU | 1 1 1 0 0 |
|-----------------------------|
| ER PDU | 0 0 0 0 1 |
+-----------------------------+
Table 7-1. Valid PDU Types
7.2.8 PDU Segment Length
The Segment Length field specifies the entire length of the PDU
segment including both header and data, if present. When the full
protocol is employed and a PDU is not segmented, then the value of
this field is identical to the value of the Total Length field
located in the Segmentation Part of the header.
RFC926 December 1984
When the Non-segmenting protocol subset is employed, no segmentation
part is present in the header. In this subset, the Segment Length
field serves as the Total Length field of the header (see Section
7.4.3).
7.2.9 PDU Checksum
The checksum is computed on the entire PDU header. This includes the
segmentation and options parts, if present. 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 ensures that the
value zero does not represent a valid checksum. A non-zero value
indicates that the checksum must be processed or the PDU must be
discarded.
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
illustrated below:
RFC926 December 1984
Octet
+--------------------------------------+
| |
| Destination Address Length Indicator | 10
| |
|--------------------------------------|
| | 11
| Destination Address |
| | m-1
|--------------------------------------|
| |
| Source Address Length Indicator | m
| |
|--------------------------------------|
| | m+1
| Source Address |
| | n-1
+--------------------------------------+
Figure 7-3. PDU header--Address Part
7.3.1.1 Destination and Source Address Information
The Destination and Source addresses are Network Service Access
Point addresses as defined in ISO 8348/DAD2, Addendum to the Network
Service Definition Covering Network Layer Addressing.
The Destination and Source Address information is of variable
length.
The Destination Address Length Indicator field specifies the length
of the Destination Address in number of 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 number of octets. The Source Address
Length Indicator field follows the Destination Address field. The
Source Address field follows the Source Address Length Indicator
field.
RFC926 December 1984
Each address parameter is encoded as follows:
Bits 8 7 6 5 4 3 2 1
+---------------------------------------------+
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|---------------------------------------------|
| Octets | |
| n+1 | Address Parameter Value |
| thru | |
| n+m | |
+---------------------------------------------+
Table 7-2. 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 below, must be present:
Octet
+------------------------+
| Data Unit Identifier | n,n+1
|------------------------|
| Segment Offset | n+2,n+3
|------------------------|
| Total Length | n+4,n+5
+------------------------+
Figure 7-4. PDU Header--Segmentation Part
Where the "Segmentation Permitted" flag is set to zero, the
nonsegmenting protocol subset is in use.
RFC926 December 1984
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
reassembled by the destination network-entity. The Data Unit
Identifier size is two octets.
7.4.2 Segment Offset
For each segment the Segment Offset field specifies the relative
position of the segment in the data part of the Initial PDU with
respect to the start of the data field. The offset is measured in
units of octets. The offset of the first segment is zero.
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 in
any segment (Derived PDU) for the lifetime of the PDU.
7.5 Options Part
7.5.1 General
The options part is used to convey optional parameters. If the
options part is present, it contains one or more parameters. The
number of parameters that may be contained in the options part is
indicated by the length of the options part which is:
PDU Header Length - (length of fixed part +
length of address part +
length of segmentation part).
RFC926 December 1984
The options part of the PDU header is illustrated below:
Octet
+--------------------+
| | n+6
| Options |
| | p
+--------------------+
Figure 7-5. PDU Header--Options Part
Each parameter contained within the options part of the PDU header is
encoded as follows:
BITS 8 7 6 5 4 3 2 1
+------------------------------------------+
| Octets | |
| n | Parameter Code |
|------------------------------------------|
| n+1 | Parameter Length (e.g., 'm') |
|------------------------------------------|
| n+2 | Parameter Value |
| n+m+1 | |
+------------------------------------------+
Table 7-3. Encoding of Parameters
The parameter code field is coded in binary and, without extensions,
provides a maximum number of 255 different parameters. However, as
noted below, bits 8 and 7 cannot take every possible value, so the
practical maximum number of different parameters is less. A parameter
code of 255 (binary 1111 1111) is reserved for possible extensions of
the parameter code.
The parameter length field indicates the length, in octets, of the
parameter value field. The length is indicated by a binary number,
'm', with a theoretical maximum value of 255. 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 indication itself. Thus, the
value of 'm' is limited to:
RFC926 December 1984
253 - (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.
No parameter codes use bits 8 and 7 with the value 00.
Implementations shall accept the parameters defined in the options
part in any order. Duplication of options (where detected) is not
permitted. Receipt of a PDU with an option duplicated should be
treated as a protocol error. The rules governing the treatment of
protocol errors are described in Section 6.10, Error Reporting
Function.
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
convenient size (See Section 6.12).
Parameter Code: 1100 1100
Parameter Length: variable
Parameter Value: any value is allowed
7.5.3 Security
This parameter is user defined.
Parameter Code: 1100 0101
Parameter Length: variable
Parameter Value:
High order bit of first octet is Security Domain bit, S, to be
interpreted as follows:
RFC926 December 1984
S=0
+---------------------------
| S | User Defined ----
+------------------------
S=1
+---------------------------
| S | CODE | ORGANIZATION ----
+------------------------
where
CODE = This field contains a geographic or non-geographic code to
which the option applies.
ORGANIZATION = This is a further subdivision of the CODE field
and is determined by an administrator of the
geographic or non-geographic domain identified by
the value of CODE.
7.5.4 Source Routing
The source routing parameter specifies, either completely or
partially, the route to be taken from Source Network Address to
Destination Network Address.
Parameter Code: 1100 1000
Parameter Length: variable
Parameter Value: 2 octet control information
succeeded by a concatenation
of ordered address fields
(ordered from source to destination)
RFC926 December 1984
The first octet of the parameter value is the type code. This has the
following significance.
0000 0001 complete source routing
0000 0000 partial source routing
<all other values reserved>
The second octet indicates the octet offset of the next address to be
processed in the list. A value of three (3) indicates that the next
address begins immediately after this control octet. Successive
octets are indicated by correspondingly larger values of this
indicator.
The third octet begins the intermediate-system address list. The
address list consists of variable length address fields. The first
octet of each address field identifies the length of the address
which comprises the remainder of the address field.
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: two octets control information
succeeded by a concatenation of
ordered addresses
The first octet is used to indicate that the recording of route has
been terminated owing to lack of space in the option. It has the
following significance:
0000 0000 Recording of Route still in progress
1111 1111 Recording of Route terminated
<all other values reserved>
RFC926 December 1984
The second octet identifies the next octet which may be used to
record an address. It is encoded relative to the start of the
parameter, such that a value of three (3) indicates that the octet
after this one is the next to be used.
The third octet begins the address list. The address list consists of
variable length address fields. The first octet of each address field
identifies the length of the address which comprises the remainder of
the field. Address fields are always added to the beginning of the
address list; i.e., the most recently added field will begin in the
third octet of the parameter value.
7.5.6 Quality of Service Maintenance
The Quality of Service parameter conveys information about the
quality of service requested by the originating Network Service user.
At intermediate systems, Network Layer relay entities 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 Section 6.16).
Parameter Code: 1100 0011
Parameter Length: one octet
Parameter Value: Bit 8: transit delay vs. cost
Bit 7: residual error probability vs.
transit delay
Bit 6: residual error probability vs.
cost
Bits 5 thru 0 are not specified.
Bit 8 is set to one indicates that where possible, routing decision
should favor low transit delay over low cost. A value of 0 indicates
that routing decisions should favor low cost over low transit delay.
RFC926 December 1984
Bit 7 set to one indicates 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 6 is set to one indicates that where possible, routing decisions
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.6 Priority
The priority parameter carries the relative priority of the protocol
data unit. Intermediate systems that support this option should make
use of this information in routing and in ordering PDUs for
transmission.
Parameter Code: 1100 1100
Parameter Length: one octet
Parameter Value: 0000 0000 - Normal (Default)
thru
0000 1111 - Highest
The values 0000 0001 through 0000 1111 are to be used for higher
priority protocol data units. If an intermediate system does not
support this option then all PDUs shall be treated as if the field had
the value 0000 0000.
7.7 Data Part
The Data part of the PDU is structured as an ordered multiple of
octets, 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 below:
RFC926 December 1984
Octet
+------------------+
| | p+1
| Data |
| | z
+------------------+
Figure 7-6. PDU header--Data Field
RFC926 December 1984
7.8 Data (DT) PDU
7.8.1 Structure
The DT PDU has the following format:
Octet
+--------------------------------------+
| Network Layer Protocol Identifier | 1
|--------------------------------------|
| Length Indicator | 2
|--------------------------------------|
| Version/Protocol Id Extension | 3
|--------------------------------------|
| Lifetime | 4
|--------------------------------------|
|SP|MS|E/R| Type | 5
|--------------------------------------|
| Segment Length | 6,7
|--------------------------------------|
| Checksum | 8,9
|--------------------------------------|
| Destination Address Length Indicator | 10
|--------------------------------------|
| Destination Address | 11 through m-1
|--------------------------------------|
| Source Address Length Indicator | m
|--------------------------------------|
| Source Address | m+1 through n-1
|--------------------------------------|
| Data Unit Identifier | n,n+1
|--------------------------------------|
| Segment Offset | n+2,n+3
|--------------------------------------|
| Total Length | n+4,n+5
|--------------------------------------|
| Options | n+6 through p
|--------------------------------------|
| Data | p+1 through z
+--------------------------------------+
Figure 7-7. PDU Header Format
RFC926 December 1984
7.8.1.1 Fixed Part
1) Network Layer Protocol Identifier See Section 7.2.2.
2) Length Indicator See Section 7.2.3.
3) Version/Protocol Id Extension See Section 7.2.4.
4) Lifetime See Section 7.2.5.
5) SP, MS, E/R See Section 7.2.6.
6) Type Code See Section 7.2.7.
7) Segment Length See Section 7.2.8.
8) Checksum See Section 7.2.9.
7.8.1.2 Addresses
See Section 7.3.
7.8.1.3 Segmentation
See Section 7.4.
7.8.1.4 Options
See Section 7.5.
7.8.1.5 Data
See Section 7.7.
RFC926 December 1984
7.9 Inactive Network Layer Protocol
Octet
+-----------------------------+
| Network Layer Protocol Id | 1
|-----------------------------|
| Data | 2 through n
+-----------------------------+
Figure 7-9. Inactive Network Layer Protocol
7.9.1 Network Layer Protocol Id
The value of the Network Layer Protocol Identifier field is binary
zero (0000 0000).
7.9.2 Data Field
See Section 7.7.
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.
RFC926 December 1984
7.10 Error Report PDU (ER)
7.10.1 Structure
Octet
+--------------------------------------+
| Network Layer Protocol Identifier | 1
|--------------------------------------|
| Length Indicator | 2
|--------------------------------------|
| Version/Protocol Id Extension | 3
|--------------------------------------|
| Lifetime | 4
|--------------------------------------|
|SP|MS|E/R| Type | 5
|--------------------------------------|
| Segment Length | 6,7
|--------------------------------------|
| Checksum | 8,9
|--------------------------------------|
| Destination Address Length Indicator | 10
|--------------------------------------|
| Destination Address | 10 through m-1
|--------------------------------------|
| Source Address Length Indicator | m
|--------------------------------------|
| Source Address | m+1 through n-1
|--------------------------------------|
| Data Unit Identifier | n,n+1
|--------------------------------------|
| Segment Offset | n+2,n+3
|--------------------------------------|
| Total Length | n+4,n+5
|--------------------------------------|
| Options | n+6 through p-1
|--------------------------------------|
| Reason for Discard | p through q-1
|--------------------------------------|
| Error Report Data Field | z
+--------------------------------------+
Figure 7-10. Error Report PDU
RFC926 December 1984
7.10.1.1 Fixed Part
The fixed part of the Error Report Protocol Data Unit is set as
though this is a new (Initial) PDU. Thus, references are provided to
precious sections describing the composition of the fields
comprising the fixed part:
1) Network Layer Protocol Identifier See Section 7.2.2.
2) Length Indicator See Section 7.2.3.
3) Version/Protocol Id Extension See Section 7.2.4.
4) Lifetime See Section 7.2.5.
5) SP, MS, E/R See Section 7.2.6.
6) Type Code See Section 7.2.7.
7) Segment Length See Section 7.2.8.
8) Checksum See Section 7.2.9.
7.10.1.2 Addresses
See Section 7.3.
The Destination Address specifies the original source of the
discarded PDU. The Source Address specifies the intermediate system
or end system network-entity initiating the Error Report PDU.
7.10.1.3 Segmentation
See Section 7.4.
RFC926 December 1984
7.10.1.4 Options
See Section 7.5.
7.10.1.5 Reason for Discard
This parameter is only valid for the Error Report PDU. It provides a
report on the discarded protocol data unit.
Parameter Code:
1100 0001
Parameter Length:
two octets
type of error encoded in binary:
0000 0000: Reason not specified.
0000 0001: Protocol Procedure Error.
other than below:
0000 0010: Incorrect checksum.
0000 0011: PDU discarded due to congestion.
0000 0100: Header syntax error (header cannot
be parsed).
0000 0101: Segmentation is needed but is not
permitted.
1000 xxxx: Addressing Error:
0000 0000: Destination Address
Unreachable.
1000 0001: Destination Address
Unknown.
1001 xxxx: Source Routing Error:
1001 0000: Unspecified Source
Routing error.
1001 0001: Syntax error in Source
Routing field.
1001 0010: Unknown Address in
Source Routing field.
1001 0011: Path not acceptable.
RFC926 December 1984
1010 xxxx: Lifetime Expiration:
1010 0000: Lifetime expired while
data unit in transit.
1010 0001: Lifetime expired
during reassembly.
1011 xxxx: PDU discarded due to unsupported
option:
1011 0000: unsupported option not
specified.
1011 0001: unsupported padding
option.
1011 0010: unsupported security
option.
1011 0011: unsupported source
routing option.
1011 0100: unsupported recording
of route option.
1011 0101: unsupported QoS
Maintenance option.
The second octet contains a pointer to the field in the associated
discarded PDU which caused the error. If no one particular field
can be associated with the error, then this field contains the
value of zero.
7.10.1.6 Error Report Data Field
This field provides all or a portion of the discarded PDU. The
octets comprising this field contain the rejected or discarded PDU
up to and including the octet which caused the rejection/discard.
RFC926 December 1984
8 FORMAL DESCRIPTION
The operation of the protocol is modelled as a finite state automaton
governed by a state variable with three values. The behavior of the
automaton is defined with respect to individual independent Protocol
Data Units. A transition of the automaton is prompted by the occurrence
of an atomic event at one of three interfaces:
1) an interface to the Transport Layer, defined by the service
primitives of the Addendum to the Network Service Definition
Covering Connectionless-mode Transmission;
2) an interface to the subnetwork service provider, defined by the
SN_UNITDATA primitive of Section 5.5 of this Standard;
3) an interface to an implementation-dependent timer function defined
by the TIMER primitives described in Section 5.6 of this Standard.
In addition, a transition of the automaton may be prompted by the
occurrence of a condition of the automaton.
The atomic events are defined in Section 8.2. The occurrence of an
atomic event is not in itself sufficient to cause a transition to take
place; other conditions, called "enabling conditions" may also have to
be met before a particular transition can take place. Enabling
conditions are boolean expressions that depend on the values of
parameters associated with the corresponding atomic event (that is, the
parameters of some primitive), and on the values of locally maintained
variables.
More than one enabling condition -- and therefore, more than one
possible transition -- may be associated with a single atomic event. In
every such case, the enabling conditions are mutually exclusive, so
that for any given combination of atomic event and parameter values,
only one state transition can take place.
Associated with each transition is an action, or "output." Actions
consist of changes to the values of local variables and the sequential
performance of zero or more functions. The operation of the finite
state automaton is completely specified in Section 8.3 by defining the
action associated with every possible transition.
RFC926 December 1984
8.1 Values of the State Variable
The protocol state variable has three values:
1) INITIAL The automaton is created in the INITIAL state. No
transition may carry the automaton into the INITIAL
state.
2) REASSEMBLING The automaton is in the REASSEMBLING state for the
period in which it is assembling PDU segments into a
complete PDU.
3) CLOSED The final state of the automaton is the CLOSED
state. When the automaton enters the CLOSED state
it ceases to exist.
8.2 Atomic Events
An atomic event is the transfer of a unit of information across an
interface. The description of an atomic event specifies a primitive
(such as an N_UNITDATA.Request), and the service boundary at which it
is invoked (such as the Network Service boundary). The direction of
information flow across the boundary is implied by the definition of
each of the primitives.
8.2.1 N.UNITDATA_request and N.UNITDATA_indication
The N.UNITDATA_request and N.UNITDATA_indication atomic events occur
at the Network Service boundary. They are defined by the Addendum to
the Network Service Definition Covering Connectionless Data
Transmission (ISO 8348/DAD1).
RFC926 December 1984
N.UNITDATA_request (NS Source_Address,
NS_Destination_Address,
NS_Quality_of_Service,
NS_Userdata)
N.UNITDATA_indication (NS_Source_Address,
NS_Destination_Address,
NS_Quality_of_Service, NS_Userdata)
The parameters of the N.UNITDATA_request and
N.UNITDATA_indication are collectively referred to as Network
Service Data Unit (NSDUs).
8.2.2 SN.UNITDATA_request and SN.UNITDATA_indication
The SN.UNITDATA_request and SN.UNITDATA_indication atomic events
occur at the interface between the Protocol described herein and a
subnetwork service provider. They are defined in Section 5.5 of this
Standard.
SN.UNITDATA_request (SN_Source_Address,
SN_Destination_Address,
SN_Quality_of_Service,
SN_Userdata)
SN.UNITDATA_indication (SN_Source_Address,
SN_Destination_Address,
SN_Quality_of_Service,
SN_Userdata)
The parameters of the SN_UNITDATA request and SN_UNITDATA Indication
are collectively referred to as Subnetwork Service Data Units
(SNSDUs).
The value of the SN_Userdata parameter may represent an Initial PDU
or a Derived PDU.
RFC926 December 1984
8.2.3 TIMER Atomic Events
The TIMER atomic events occur at the interface between the Protocol
described herein and its local environment. They are defined in
Section 5.6 of this Standard.
S.TIMER_request (Time,
Name,
Subscript)
S.TIMER_cancel (Name
Subscript)
S.TIMER_response (Name,
Subscript)
8.3 Operation of the Finite State Automation
The operation of the automaton is defined by use of the formal
description technique and notation specified in ISO/TC97/SC16 N1347.
This technique is based on an extended finite state transition model
and the Pascal programming language. The technique makes use of strong
variable typing to reduce ambiguity in interpretation of the
specification.
This specification formally specifies an abstract machine which
provides a single instance of the Connectionless-Mode Network Service
by use of the Protocol For Providing the Connectionless-Mode Network
Service. It should be emphasized that this formal specification does
not in any way constrain the internal operation or design of any
actual implementation. For example, it is not required that the
program segments contained in the state transitions will actually
appear as part of an actual implementation. A formal protocol
specification is useful in that it goes as far as possible to
eliminate any degree of ambiguity or vagueness in the specification of
a protocol standard.
The formal specification contained here specifies the behavior of a
single finite-state machine, which provides the protocol
RFC926 December 1984
behavior corresponding to a single independent service request. It is
expected that any actual implementation will be able to handle
behavior corresponding to many simultaneous finite state machines.
RFC926 December 1984
8.3.1 Type and Constant Definitions
const
ZERO = 0;
max_user_data = 64512;
type
NSAP_addr_type = ...;
{ NSAP_addr_type defines the data type for NSAP addresses, as
passed across the Network Service Boundary. }
NPAI_addr_type = ...;
{ NPAI_addr_type defines the data type for the addresses carried in
PDUs. }
SN_addr_type = ...;
{ SN_addr_type defines the data type for addresses in the
underlying service used by this protocol. }
quality_of_service_type = ...;
{ Quality_of_service_type defines the data type for the QOS
parameter passed across the Network Service boundary. }
SN_QOS_type = ...;
{ SN_QOS_type defines the data type for the QOS parameter, if any,
passed to the underlying service used by this protocol. }
data_type = ...;
{ Data_type defines the data type for user data. Conceptually this
is equivalent to a variable length binary string. }
buffer_type = ...;
{ Buffer_type defines the data type for the memory resources used
in sending and receiving of user data. This provides capabilities
required for segmentation and reassembly. }
RFC926 December 1984
timer_name_type = (lifetime_timer);
timer_data_type = ...;
network_layer_protocol_id_type = (ISO_8473_protocol_id);
version_id_type = (version1);
pdu_tp_type = (DT, ER);
options_type = ...;
{ Options_type defines the data type used to store the options part
of the PDU header. }
subnet_id_type = ...;
{ The subnet_id_type defines the data type used to locally identify
a particular underlying service used by this protocol. In general
there may be multiple underlying subnetwork (or data link)
services. }
error_type = (NO_ERROR,
TOO_MUCH_USER_DATA,
PROTOCOL_PROCEDURE_ERROR,
INCORRECT_CHECKSUM, CONGESTION,
SYNTAX_ERROR,
SEG_NEEDED_AND_NOT_PERMITTED,
DESTINATION_UNREACHABLE,
DESTINATION_UNKNOWN,
UNSPECIFIED_SRC_ROUTING_ERROR,
SYNTAX_ERROR_IN_SRC_ROUTING,
UNKNOWN_ADDRESS_IN_SRC_ROUTING,
PATH_NOT_ACCEPTABLE_IN_SRC_ROUTING,
LIFETIME_EXPIRED_IN_TRANSIT,
LIFETIME_EXPIRED_IN_REASSEMBLY,
UNSUPPORTED_OPTION_NOT_SPECIFIED,
UNSUPPORTED_PADDING_OPTION,
UNSUPPORTED_SECURITY_OPTION,
UNSUPPORTED_SRC_ROUTING_OPTION,
UNSUPPORTED_RECORDING_OF_ROUTE_OPTION,
UNSUPPORTED_QOS_MAINTENANCE_OPTION);
RFC926 December 1984
nsdu_type = record
da : NSAP_addr_type;
sa : NSAP_addr_type;
qos : quality_of_service_type;
data : data_type;
end;
pdu_type = record
nlp_id : network_layer_protocol_id_type;
hli : integer;
vp_id : version_id_type; lifetime : integer;
sp : boolean;
ms : boolean;
er_flag : boolean;
pdu_tp : pdu_tp_type;
seg_len : integer;
checksum : integer;
da_len : integer;
da : NPAI_addr_type;
sa_len : integer;
sa : NPAI_addr_type;
du_id : optional integer;
so : optional integer;
tot_len : optional integer;
{ du_id, so, and tot_len are present
only if sp has the value TRUE. }
options : options_type;
data : data_type;
end;
RFC926 December 1984
route_result_type =
record
subnet_id : subnet_id_type;
sn_da : SN_addr_type;
sn_sa : SN_addr_type;
segment_size : integer;
end;
RFC926 December 1984
8.3.2 Interface Definitions
channel Network_access_point (User, Provider);
by User:
UNITDATA_request
(NS_Destination_address : NSAP_addr_type;
NS_Source_address : NSAP_addr_type;
NS_Quality_of_Service : quality_of_service_type;
NS_Userdata : data_type);
by Provider:
UNITDATA_indication
(NS_Destination_address : NSAP_addr_type;
NS_Source_address : NSAP_addr_type;
NS_Quality_of_Service : quality_of_service_type;
NS_Userdata : data_type);
channel Subnetwork_access_point (User, Provider);
by User:
UNITDATA_request
(SN_Destination_address : SN_addr_type;
SN_Source_address : SN_addr_type;
SN_Quality_of_Service : SN_QOS_type;
SN_Userdata : pdu_type);
by Provider:
UNITDATA_indication
(SN_Destination_address : SN_addr_type;
SN_Source_address : SN_addr_type;
SN_Quality_of_Service : SN_QOS_type;
SN_Userdata : pdu_type);
channel System_access_point (User, Provider);
by User:
TIMER_request
(Time : integer;
Name : timer_name_type;
Subscript : integer);
RFC926 December 1984
TIMER_cancel
(Name : timer_name_type;
Subscript : integer);
by Provider:
TIMER_indication
(Name : timer_name_type;
Subscript : integer);
RFC926 December 1984
8.3.3 Formal Machine Definition
module Connectionless_Network_Protocol_Machine
(N: Network_access_point (Provider) common queue;
SN: array [subnet_id_type] of Subnetwork_access_point
(User) common queue;
S: System_access_point (User) individual queue );
var
nsdu : nsdu_type;
pdu : pdu_type;
rcv_buf : buffer_type;
state : (INITIAL, REASSEMBLING, CLOSED);
RFC926 December 1984
procedure send_error_report (error : error_type;
pdu : pdu_type);
var
er_pdu : pdu_type;
begin
if (pdu.er_flag) then
begin
er_pdu.nlp_id := ISO_8473_protocol_id;
er_pdu.vp_id := version1;
er_pdu.lifetime := get_er_lifetime(pdu.sa);
er_pdu.sp := get_er_seg_per(pdu);
er_pdu.ms := FALSE;
er_pdu.er_flag := FALSE;
er_pdu.pdu_tp := ER;
er_pdu.da_len := pdu.sa_len;
er_pdu.da := pdu.sa;
er_pdu.sa_len := get_local_NPAI_addr_len;
er_pdu.sa := get_local_NPAI_addr;
er_pdu.options := get_er_options
(error,
er_pdu.da,
pdu.options);
er_pdu.hli := get_header_length
(er_pdu.da_len, er_pdu.sa_len,
er_pdu.sp,
er_pdu.options);
er_pdu.data := get_er_data_field(error, pdu);
if (er_pdu.sp) then
begin
er_pdu.du_id :=
get_data_unit_id(er_pdu.da);
er_pdu.so := ZERO;
er_pdu.tot_len := er_pdu.hli +
size(er_pdu.data);
end;
RFC926 December 1984
if (NPAI_addr_local(er_pdu.da))
then
post_error_report(er_pdu)
else
send_pdu(er_pdu);
end;
end;
RFC926 December 1984
procedure send_pdu (pdu : pdu_type);
var
rte_result : route_result_type;
error_code : error_type;
send_buf : buffer_type;
data_maxsize : integer;
more_seg : boolean;
sn_qos : SN_QOS_type;
begin
send_buf := make_buffer(pdu.data);
more_seg := pdu.ms;
repeat
begin
error_code := check_parameters
(pdu.hli,
pdu.sp,
pdu.da,
pdu.options,
size(pdu.data));
if (error_code = NO_ERROR) then
begin
rte_result := route(pdu.hli,
pdu.sp,
pdu.da,
pdu.options,
size(pdu.data));
data_maxsize := rte_result.segment_size -
pdu.hli;
pdu.data := extract(send_buf,
data_maxsize);
pdu.seg_len := pdu.hli + size(pdu.data);
if (size(send_buf) = ZERO) then
pdu.ms := more_seg
else
pdu.ms := TRUE;
RFC926 December 1984
pdu.checksum := get_checksum(pdu);
sn_qos := get_sn_qos
(rte_result.subnet_id,
pdu.options);
out SN[rte_result.subnet_id].UNITDATA_request
(rte_result.sn_da,
rte_result.sn_sa,
sn_qos,
pdu);
pdu.so := pdu.so + data_maxsize;
end
else if (error_code = CONGESTION) then
begin
if (send_er_on_congestion (pdu)) then
send_error_report(CONGESTION, pdu);
end
else
send_error_report(error_code, pdu);
end;
until (size_buf(data_buf) = ZERO) or
(error_code <> NO_ERROR);
end;
RFC926 December 1984
procedure allocate_reassembly_resources
(pdu_tot_len : integer);
primitive;
{ This procedure allocates resources required for reassembly of a
PDU of the specified total length. If this requires discarding of a
PDU in which the ER flag is set, then an error report is returned to
the source of the discarded data unit. }
function check_parameters
(hli : integer;
sp : boolean;
da : NPAI_addr_type;
options : options_type;
datalen : integer) : error_type;
primitive;
{ This function examines various parameters associated with a PDU,
to determine whether forwarding of the PDU can continue. If a
result of NO_ERROR is returned, then the primitive route can be
called to specify the route and segment size. Otherwise this
function specifies the reason that an error has occurred. }
function data_unit_complete
(buf : buffer_type) : boolean;
primitive;
{ This function returns a boolean value specifying whether the PDU
stored in the specified buffer has been completely received. }
RFC926 December 1984
function elapsed_time : integer;
primitive;
{ This function returns an estimate of the time elapsed, in 500
microsecond increments, since the PDU was transmitted by the
previous peer network entity. This estimate includes both time
spent in transit, and any time to be spent in buffers within the
local system. Although this estimate need not be precise,
overestimates are preferable to underestimates, as underestimating
the time elapsed may defeat the intent of the lifetime function. }
procedure empty_buffer
(buf : buffer_type);
primitive;
{ This procedure empties the specified buffer. }
function extract
(buf : buffer_type;
amount : integer) : data_type;
primitive;
{ This function removes the specified amount of data from