As per Relevance of the word subnetwork, we have this rfc below:
Network Working Group
Request for Comments: 926 December 1984
Protocol for Providing the Connectionless-Mode Network
(Informally - ISO IP
ISO DIS 8473
Status of this Memo
This document is distributed as an RFC for information only. It
not specify a standard for the ARPA-Internet. Distribution of
memo is unlimited
Note
This document has been prepared by retyping the text of ISO DIS 8473
May 1984, which is currently undergoing voting within ISO as a
International Standard (DIS). Although this RFC has been
after typing, and is believed to be substantially correct, it
possible that typographic errors not present in the ISO document
been overlooked
Alex
RFC 926 December 1984
RFC 926 December 1984
TABLE OF
1 SCOPE AND FIELD OF APPLICATION........................ 2
2 REFERENCES............................................ 3
3 DEFINITIONS........................................... 4
3.1 Reference Model Definitions......................... 4
3.2 Service Conventions Definitions..................... 4
3.3 Network Layer Architecture Definitions.............. 4
3.4 Network Layer Addressing Definitions................ 5
3.5 Additional Definitions.............................. 5
4 SYMBOLS AND ABBREVIATIONS............................. 7
4.1 Data Units.......................................... 7
4.2 Protocol Data Units................................. 7
4.3 Protocol Data Unit Fields........................... 7
4.4 Parameters.......................................... 8
4.5 Miscellaneous....................................... 8
5 OVERVIEW OF THE PROTOCOL.............................. 9
5.1 Internal Organization of the Network Layer.......... 9
5.2 Subsets of the Protocol............................. 9
5.3 Addressing......................................... 10
5.4 Service Provided by the Network Layer.............. 10
5.5 Service Assumed from the Subnetwork
Provider.............................................. 11
5.5.1 Subnetwork Addresses............................. 12
5.5.2 Subnetwork Quality of Service.................... 12
5.5.3 Subnetwork User Data............................. 13
5.5.4 Subnetwork Dependent Convergence Functions....... 13
5.6 Service Assumed from Local Evironment.............. 14
6 PROTOCOL FUNCTIONS................................... 16
6.1 PDU Composition Function........................... 16
6.2 PDU Decomposition Function......................... 17
6.3 Header Format Analysis Function.................... 17
6.4 PDU Lifetime Control Function...................... 18
6.5 Route PDU Function................................. 18
6.6 Forward PDU Function............................... 19
6.7 Segmentation Function.............................. 19
6.8 Reassembly Function................................ 20
6.9 Discard PDU Function............................... 21
ISO DIS 8473 (May 1984) [Page i
RFC 926 December 1984
6.10 Error Reporting Function.......................... 22
6.10.1 Overview........................................ 22
6.10.2 Requirements.................................... 23
6.10.3 Processing of Error Reports..................... 24
6.11 PDU Header Error Detection........................ 25
6.12 Padding Function.................................. 26
6.13 Security.......................................... 26
6.14 Source Routing Function........................... 27
6.15 Record Route Function............................. 28
6.16 Quality of Service Maintenance Function........... 29
6.17 Classification of Functions....................... 29
7 STRUCTURE AND ENCODING OF PDUS....................... 32
7.1 Structure.......................................... 32
7.2 Fixed Part......................................... 34
7.2.1 General.......................................... 34
7.2.2 Network Layer Protocol Identifier................ 34
7.2.3 Length Indicator................................. 35
7.2.4 Version/Protocol Identifier Extension............ 35
7.2.5 PDU Lifetime..................................... 35
7.2.6 Flags............................................ 36
7.2.6.1 Segmentation Permitted and More Segments Flags. 36
7.2.6.2 Error Report Flag.............................. 37
7.2.7 Type Code........................................ 37
7.2.8 PDU Segment Length............................... 37
7.2.9 PDUChecksum...................................... 38
7.3 Address Part....................................... 38
7.3.1 General.......................................... 38
7.3.1.1 Destination and Source Address Information... 39
7.4 Segmentation Part.................................. 40
7.4.1 Data Unit Identifier............................. 41
7.4.2 Segment Offset................................... 41
7.4.3 PDU Total Length................................. 41
7.5 Options Part....................................... 41
7.5.1 General.......................................... 41
7.5.2 Padding.......................................... 43
7.5.3 Security......................................... 43
7.5.4 Source Routing................................... 44
7.5.5 Recording of Route............................... 45
7.5.6 Quality of Service Maintenance................... 46
7.6 Priority........................................... 47
ISO DIS 8473 (May 1984) [Page ii
RFC 926 December 1984
7.7 Data Part.......................................... 47
7.8 Data (DT) PDU...................................... 49
7.8.1 Structure........................................ 49
7.8.1.1 Fixed Part..................................... 50
7.8.1.2 Addresses...................................... 50
7.8.1.3 Segmentation................................... 50
7.8.1.4 Options........................................ 50
7.8.1.5 Data........................................... 50
7.9 Inactive Network Layer Protocol.................... 51
7.9.1 Network Layer Protocol Id........................ 51
7.9.2 Data Field....................................... 51
7.10 Error Report PDU (ER)............................. 52
7.10.1 Structure....................................... 52
7.10.1.1 Fixed Part.................................... 53
7.10.1.2 Addresses..................................... 53
7.10.1.3 Segmentation.................................. 53
7.10.1.4 Options....................................... 54
7.10.1.5 Reason for Discard............................ 54
7.10.1.6 Error Report Data Field....................... 55
8 FORMAL DESCRIPTION................................... 56
8.1 Values of the State Variable....................... 57
8.2 Atomic Events...................................... 57
8.2.1 N.UNITDATA_request and N.UNITDATA_indication..... 57
8.2.2 SN.UNITDATA_request and SN.UNITDATA_indication... 58
8.2.3 TIMER Atomic Events.............................. 59
8.3 Operation of the Finite State Automation........... 59
8.3.1 Type and Constant Definitions.................... 61
8.3.2 Interface Definitions............................ 65
8.3.3 Formal Machine Definition........................ 67
9 CONFORMANCE.......................................... 84
9.1 Provision of Functions for Conformance............. 84
ISO DIS 8473 (May 1984) [Page iii
RFC 926 December 1984
ISO DIS 8473 (May 1984) [Page iv
RFC 926 December 1984
This Protocol is one of a set of International Standards produced
facilitate the interconnection of open systems. The set of
covers the services and protocols required to achieve
interconnection
This Protocol Standard is positioned with respect to other
standards by the layers defined in the Reference Model for Open
Interconnection (ISO 7498). In particular, it is a protocol of
Network Layer. The Protocol herein described is a
Independent Convergence Protocol combined with relay and
functions as described in the Internal Organization of the
Layer (ISO iiii). This Protocol provides the connectionless-
Network Service as defined in ISO 8348/DAD1, Addendum to the
Service Definition Covering Connectionless-mode Transmission,
Network Service users and/or Network Layer relay systems
The interrelationship of these standards is illustrated in Figure 0-1
below
______________OSI Network Service Definition______________
| ^
|
| |
Protocol Reference to aims __________|
|
Specification | Reference to assumptions ___
|
| |
|
| |
|
| v
______________Subnetwork Service Definition(s) ___________
Figure 0-1. Interrelationship of
ISO DIS 8473 (May 1984) [Page 1]
RFC 926 December 1984
1 SCOPE AND FIELD OF
This International Standard specifies a protocol which is used
provide the Connectionless-mode Network Service as described in
8348/DAD1, Addendum to the Network Service Definition
Connectionless-mode Transmission. The protocol herein described
upon the provision of a connectionless-mode subnetwork service
This Standard specifies
a) procedures for the connectionless transmission of data and
information from one network-entity to a peer network-entity
b) the encoding of the protocol data units used for the
of data and control information, comprising a variable-
protocol header format
c) procedures for the correct interpretation of protocol
information;
d) the functional requirements for implementations
conformance to the Standard
The procedures are defined in terms of
a) the interactions among peer network-entities through the
of protocol data units
b) the interactions between a network-entity and a Network
user through the exchange of Network Service primitives;
c) the interactions between a network-entity and a subnetwork
provider through the exchange of subnetwork service primitives
ISO DIS 8473 (May 1984) [Page 2]
RFC 926 December 1984
2
ISO 7498 Information Processing Systems - Open
Interconnection - Basic Reference
DP 8524 Information Processing Systems - Open
Interconnection - Addendum to ISO 7498
Connectionless-Mode
DIS 8348 Information Processing Systems - Data Communications -
Network Service
ISO 8348/DAD1 Information Processing Systems - Data Communications -
Addendum to the Network Service Definition
Connectionless-Mode
ISO 8348/DAD2 Information Processing Systems - Data Communications -
Addendum to the Network Service Definition
Network Layer
DP iiii Information Processing Systems - Data Communications -
Internal Organization of the Network
DP 8509 Information Processing Systems - Open
Interconnection - Service
ISO TC97/SC16 A Formal Description Technique based on an N1825
Extended State Transition
ISO DIS 8473 (May 1984) [Page 3]
RFC 926 December 1984
SECTION ONE.
3
3.1 Reference Model
This document makes use of the following concepts defined in ISO 7498:
a) Network
b) Network
c) Network service access
d) network service access point
e) Network
f)
f)
h) Network
i) Network
j) Network protocol data
k) End
3.2 Service Conventions
This document makes use of the following concepts from the OSI
Conventions (ISO 8509):
l) Service
m) Service
3.3 Network Layer Architecture
This document makes use of the following concepts from the
Organization of the Network Layer (ISO iiii):
n)
ISO DIS 8473 (May 1984) [Page 4]
RFC 926 December 1984
o) Relay
p) Intermediate
q) Subnetwork
3.4 Network Layer Addressing
This document makes use of the following concepts from DIS 8348/DAD2,
Addendum to the Network Service Definition Covering Network
addressing
r) Network entity
s) Network protocol address
t) Subnetwork
u)
3.5 Additional
For the purposes of this document, the following definitions apply
a) automaton - a machine designed to follow automatically
predetermined sequence of operations or to
to encoded instructions
b) local matter - a decision made by a system concerning
behavior in the Network Layer that is not
to the requirements of this Protocol
c) segment - part of the user data provided in the N_
request and delivered in the N_
indication
d) initial PDU - a protocol data unit carrying the whole of
user data from an N_UNITDATA request
e) derived PDU - a protocol data unit whose fields are
to those of an initial PDU, except that it
only a segment of the user data from an N_
request
ISO DIS 8473 (May 1984) [Page 5]
RFC 926 December 1984
f) segmentation - the act of generating two or more derived
from an initial or derived PDU. The derived
together carry the entire user data of the
or derived PDU from which they were generated
[Note: it is possible that such an initial
will never actually be generated for a
N_UNITDATA request, owing to the
application of segmentation.]
g) reassembly - the act of regenerating an initial PDU (in
to issue an N_UNITDATA indication) from two
more derived PDUs produced by segmentation
ISO DIS 8473 (May 1984) [Page 6]
RFC 926 December 1984
4 SYMBOLS AND
4.1 Data
PDU Protocol Data
NSDU Network Service Data
SNSDU Subnetwork Service Data
4.2 Protocol Data
DT PDU Data Protocol Data
ER PDU Error Report Protocol Data
4.3 Protocol Data Unit
NPID Network Layer Protocol
LI Length
V/P Version/protocol Identifier
LT
SP Segmentation Permitted
MS More Segments
E/R Error Report
TP
SL Segment
CS
DAL Destination Address
DA Destination
SAL Source Address
SA Source
DUID Data Unit
SO Segment
TL Total
ISO DIS 8473 (May 1984) [Page 7]
RFC 926 December 1984
4.4
DA Destination
SA Source
QOS Quality of
4.5
SNICP Subnetwork Independent Convergence
SNDCP Subnetwork Dependent Convergence
SNAcP Subnetwork Access
SN
P
NSAP Network Service Access
SNSAP Subnetwork Service Access
NPAI Network Protocol Address
NS Network
ISO DIS 8473 (May 1984) [Page 8]
RFC 926 December 1984
5 OVERVIEW OF THE
5.1 Internal Organization of the Network
The architecture of the Network Layer is described in a
document, Internal Organization of the Network Layer (ISO iiii),
which an OSI Network Layer structure is defined, and a structure
classify protocols as an aid to the progression toward that
is presented. This protocol is designed to be used in the context
the internetworking protocol approach defined in that document
between Network Service users and/or Network Layer relay systems.
described in the Internal Organization of the Network Layer,
protocol herein described is a Subnetwork Independent
Protocol combined with relay and routing functions designed to
the incorporation of existing network standards within the
framework
A Subnetwork Independent Convergence Protocol is one which can
defined on a subnetwork independent basis and which is necessary
support the uniform appearance of the OSI Connectionless-mode
Service between Network Service users and/or Network Layer
systems over a set of interconnected homogeneous or
subnetworks. This protocol is defined in just such a
independent way so as to minimize variability where
dependent and/or subnetwork access protocols do not provide the
Network Service
The subnetwork service required from the lower sublayers by
protocol described herein is identified in Section 5.5.
5.2 Subsets of the
Two proper subsets of the full protocol are also defined which
the use of known subnetwork characteristics, and are therefore
subnetwork independent
One protocol subset is for use where it is known that the source
destination end-systems are connected by a single subnetwork. This
known as the "Inactive Network Layer Protocol" subset. A second
permits simplification of the header where it is known that the
and destination end-systems are connected by subnetworks
subnetwork service data unit (SNSDU) sizes are greater than or
to a known bound large enough for segmentation not to be required
This subset, selected by setting the "segmentation permitted" flag
zero, is known as the "non-segmenting" protocol subset
ISO DIS 8473 (May 1984) [Page 9]
RFC 926 December 1984
5.3
The Source Address and Destination Address parameters referred to
Section 7.3 of this International Standard are OSI Network
Access Point Addresses. The syntax and semantics of an OSI
Service Access Point Address, the syntax and encoding of the
Protocol Address Information employed by this Protocol, and
relationship between the NSAP and the NPAI is described in a
document, ISO 8348/DAD2, Addendum to the Network Service
covering Network Layer Addressing
The syntax and semantics of the titles and addresses used for
and routing are also described in ISO 8348/DAD2.
5.4 Service Provided by the Network
The service provided by the protocol herein described is
connectionless-mode Network Service. The connectionless-mode
Service is described in document ISO 8348/DAD1, Addendum to
Network Service Definition Covering Connectionless-mode Transmission
The Network Service primitives provided are summarized below
ISO DIS 8473 (May 1984) [Page 10]
RFC 926 December 1984
Primitives Parameters
+--------------------------------------------------------+
| | |
| N_UNITDATA Request | NS_Destination_Address, |
| Indication | NS_Source_Address, |
| | NS_Quality_of_Service, |
| | NS_Userdata |
+--------------------------------------------------------+
Table 5-1. Network Service
The Addendum to the Network Service Definition
Connectionless-mode Transmission (ISO 8348/DAD1) states that
maximum size of a connectionless-mode Network-service-data-unit
limited to 64512 octets
5.5 Service Assumed from the Subnetwork Service
The subnetwork service required to support this protocol is defined
comprising the following primitives
Primitives Parameters
+--------------------------------------------------------+
| | |
| SN_UNITDATA Request | SN_Destination_Address, |
| Indication | SN_Source_Address, |
| | SN_Quality_of_Service, |
| | SN_Userdata |
+--------------------------------------------------------+
Table 5-2. Subnetwork Service
ISO DIS 8473 (May 1984) [Page 11]
RFC 926 December 1984
5.5.1 Subnetwork
The source and destination addresses specify the points of
to a public or private subnetwork(s) involved in the transmission
Subnetwork addresses are defined in the Service Definition of
individual subnetwork
The syntax and semantics of subnetwork addresses are not defined
this Protocol Standard
5.5.2 Subnetwork Quality of
Subnetwork Quality of Service describes aspects of a
connectionless-mode service which are attributable solely to
subnetwork service provider
Associated with each subnetwork connectionless-mode transmission
certain measures of quality of service are requested when
primitive action is initiated. These requested measures (or
values and options) are based on a priori knowledge by the
Service provider of the service(s) made available to it by
subnetwork. Knowledge of the nature and type of service available
typically obtained prior to an invocation of the
connectionless-mode service
Note
The quality of service parameters identified for the
connectionless-mode service may in some circumstances be
derivable from or mappable onto those identified in
connectionless-mode Network Service; e.g., the
a) transit delay
b) protection against unauthorized access
c) cost determinants
d) priority;
e) residual error
as defined in ISO 8348/DAD1, Addendum to the Network
Definition Covering Connectionless-mode Transmission, may
employed
ISO DIS 8473 (May 1984) [Page 12]
RFC 926 December 1984
For those subnetworks which do not inherently provide Quality
Service as a parameter when the primitive action is initiated,
is a local matter as to how the semantics of the service
might be preserved. In particular, there may be instances in
the Quality of Service requested cannot be maintained. In
circumstances, the subnetwork service provider shall attempt
deliver the protocol data unit at whatever Quality of Service
available
5.5.3 Subnetwork User
The SN_Userdata is an ordered multiple of octets, and is
transparently between the specified subnetwork service access points
The subnetwork service is required to support a subnetwork
data unit size of at least the maximum size of the Data PDU
plus one octet of NS-Userdata. This requires a minimum
service data unit size of 256 octets
Where the subnetwork service can support a subnetwork service
unit (SNSDU) size greater than the size of the Data PDU header
one octet of NS_Userdata, the protocol may take advantage of this.
particular, if all SNSDU sizes of the subnetworks involved are
to be large enough that segmentation is not required, then
"non-segmenting" protocol subset may be used
5.5.4 Subnetwork Dependent Convergence
Subnetwork Dependent Convergence Functions may be performed
provide a connectionless-mode subnetwork service in the case
subnetworks also provide a connection-oriented subnetwork service.
a subnetwork provides a connection-oriented service, some
dependent function is assumed to provide a mapping into the
subnetwork service described in the preceding text
A Subnetwork Dependent Convergence Protocol may also be employed
those cases where functions assumed from the subnetwork
provider are not performed
ISO DIS 8473 (May 1984) [Page 13]
RFC 926 December 1984
5.6 Service Assumed from Local
A timer service is provided to allow the protocol entity to
events
There are three primitives associated with the S_TIMER service
1) the S-TIMER request
2) the S_TIMER response;
3) the S_TIMER cancel
The S_TIMER request primitive indicates to the local environment
it should initiate a timer of the specified name and subscript
maintain it for the duration specified by the time parameter
The S_TIMER response primitive is initiated by the local
to indicate that the delay requested by the corresponding S_
request primitive has elapsed
The S_TIMER cancel primitive is an indication to the local
that the specified timer(s) should be cancelled. If the
parameter is not specified, then all timers with the specified
are cancelled; otherwise, the timer of the given name and subscript
cancelled. If no timers correspond to the parameters specified,
local environment takes no action
The parameters of the S_TIMER service primitives are
ISO DIS 8473 (May 1984) [Page 14]
RFC 926 December 1984
Primitives Parameters
+--------------------------------------------------------+
| | |
| S_TIMER Request | S_Time |
| | S_Name |
| | S_Subscript |
| | |
| S_TIMER Response | S_Name |
| Cancel | S_Subscript |
+--------------------------------------------------------+
Table 5-3. Timer
The time parameter indicates the time duration of the specified timer
An identifying label is associated with a timer by means of the
parameter. The subscript parameter specifies a value to
timers with the same name. The name and subscript taken
constitute a unique reference to the timer
ISO DIS 8473 (May 1984) [Page 15]
RFC 926 December 1984
SECTION TWO. SPECIFICATION OF THE
6 PROTOCOL
This section describes the functions performed as part of the Protocol
Not all of the functions must be performed by every implementation
Section 6.17 specifies which functions may be omitted and the
behavior where requested functions are not implemented
6.1 PDU Composition
This function is responsible for the construction of a protocol
unit according to the rules of protocol given in Section 7.
Control Information required for delivering the data unit to
destination is determined from current state information and from
parameters provided with the N_UNITDATA Request; e.g., source
destination addresses, QOS, etc. User data passed from the
Service user in the N_UNITDATA Request forms the Data field of
protocol data unit
During the composition of the protocol data unit, a Data
Identifier is assigned to identify uniquely all segments of
corresponding NS_Userdata. The "Reassemble PDU" function
PDUs to correspond to the same Initial PDU, and hence N_
request, if they have the same Source and Destination Addresses
Data Unit Identifier
The Data Unit Identifier is available for ancillary functions such
error reporting. The originator of the PDU must choose the Data
Identifier so that it remains unique (for this Source and
Address pair) for the maximum lifetime of the PDU (or any
PDUs) in the network
ISO DIS 8473 (May 1984) [Page 16]
RFC 926 December 1984
During the composition of the PDU, a value of the total length of
PDU is determined by the originator and placed in the Total
field of the PDU header. This field is not changed in any Derived
for the lifetime of the protocol data unit
Where the non-segmenting subset is employed, neither the Total
field nor the Data Unit Identifier field is present. During
composition of the protocol data unit, a value of the total length
the PDU is determined by the originator and placed in the
Length field of the PDU header. This field is not changed for
lifetime of the PDU
6.2 PDU Decomposition
This function is responsible for removing the Protocol
Information from the protocol data unit. During this process
information pertinent to the generation of the N_UNITDATA
is retained. The data field of the PDU received is reserved until
segments of the original service data unit have been received; this
the NS_Userdata parameter of the N_UNITDATA Indication
6.3 Header Format Analysis
This function determines whether the full Protocol described in
Standard is employed, or one of the defined proper subsets thereof.
the protocol data unit has a Network Layer Protocol
indicating that this is a standard version of the Protocol,
function determines whether a PDU received has reached its
using the destination address provided in the PDU is the same as
one which addresses an NSAP served by this network-entity, then
PDU has reached its destination; if not, it must be forwarded
If the protocol data unit has a Network Layer Protocol
indicating that the Inactive Network Layer Protocol subset is in use
then no further analysis of the PDU header is required.
ISO DIS 8473 (May 1984) [Page 17]
RFC 926 December 1984
network-entity in this case determines that either the network
encoded in the network protocol address information of a
subnetwork protocol corresponds to a network Service Access
address served by this network-entity, or that an error has occurred
If the subnetwork PDU has been delivered correctly, then the
data unit may be decomposed according to the procedure described
that particular subnetwork protocol
6.4 PDU Lifetime Control
This function is used to enforce the maximum PDU lifetime. It
closely associated with the "Header Format Analysis" function.
function determines whether a PDU received may be forwarded or
its assigned lifetime has expired, in which case it must be discarded
The operation of the Lifetime Control function depends upon
Lifetime field in the PDU header. This field contains, at any time
the remaining lifetime of the PDU (represented in units of 500
Milliseconds). The Lifetime of the Initial PDU is determined by
originating network-entity, and placed in the Lifetime field of
PDU
6.5 Route PDU
This function determines the network-entity to which a protocol
unit should be forwarded, using the destination NSAP
parameters, Quality of Service parameter, and/or other parameters.
determines the subnetwork which must be transited to reach
network-entity. Where segmentation occurs, it further determines
subnetwork(s) the segments may transit to reach that network-entity
ISO DIS 8473 (May 1984) [Page 18]
RFC 926 December 1984
6.6 Forward PDU
This function issues a subnetwork service primitive (see Section 5.5)
supplying the subnetwork identified by the "Route PDU" function
the protocol data unit as an SNSDU, and the address
required by that subnetwork to identify the "next" intermediate-
within the subnetwork-specific address domain
When an Error Report PDU is to be forwarded, and is longer than
maximum user data acceptable by the subnetwork, it shall be
to the maximum acceptable length ad forwarded with no other change
When a Data PDU is to be forwarded ad is longer than the maximum
data acceptable by the subnetwork, the Segmentation function
applied (See Section 6.7, which follows).
6.7 Segmentation
Segmentation is performed when the size of the protocol data unit
greater than the maximum size of the user data parameter field of
subnetwork service primitive
Segmentation consists of composing two or more new PDUs (Derived PDUs
from the PDU received. The PDU received may be the Initial PDU, or
may be a Derived PDU. The Protocol Control Information required
identify, route, and forward a PDU is duplicated in each PDU
from the Initial PDU. The user data encapsulated within the
received is divided such that the Derived PDUs satisfy the
requirements of the user data parameter field of the
service primitive
Derived PDUs are identified as being from the same Initial PDU
means
a) the source address
b) the destination address,
c) the data unit identifier
ISO DIS 8473 (May 1984) [Page 19]
RFC 926 December 1984
The following fields of the PDU header are used in conjunction
the Segmentation function
a) Segment Offset - identifies at which octet in the data field
the Initial PDU the segment begins
b) Segment Length - specifies the number of octets in the
PDU, including both header and data
c) More Segments Flag - set to one if this Derived PDU does
contain, as its final octet of user data, the final octet of
Initial PDU;
d) Total Length - specifies the entire length of the Initial PDU
including both header and data
Derived PDUs may be further segmented without constraining the
of the individual Derived PDUs
A Segmentation Permitted flag is set to one to indicate
segmentation is permitted. If the Initial PDU is not to be
at any point during its lifetime in the network, the flag is set
zero
When the "Segmentation Permitted" flag is set to zero, the non
segmenting protocol subset is in use
6.8 Reassembly
The Reassembly Function reconstructs the Initial PDU transmitted
the destination network-entity from the Derived PDUs generated
the lifetime of the Initial PDU
A bound on the time during which segments (Derived PDUs) of an
PDU will be held at a reassembly point is provided so that
may be released when it is no longer expected that any
segments of the Initial PDU will arrive at the reassembly point.
such an event occurs, segments (Derived PDUs) of the Initial PDU
at the reassembly point are discarded, the resources allocated
those segments are freed
ISO DIS 8473 (May 1984) [Page 20]
RFC 926 December 1984
and if selected, an Error Report is generated
Note
The design of the Segmentation and Reassembly functions is
principally to be used such that reassembly takes place at
destination. However, other schemes
a) interact with the routing algorithm to favor paths on
fewer segments are generated
b) generate more segments than absolutely required in order
avoid additional segmentation at some subsequent point,
c) allow partial/full reassembly at some point along the
where it is known that the subnetwork with the smallest
size has been
are not precluded. The information necessary to enable the use
one of these alternative strategies may be made available
the operation of a Network Layer Management function
While the exact relationship between reassembly lifetime and
lifetime is a local matter, the reassembly algorithm must
the intent of the PDU lifetime. Consequently, the
function must discard PDUs whose lifetime would otherwise
expired had they not been under the control of the
function
6.9 Discard PDU
This function performs all of the actions necessary to free
resources reserved by the network-entity in any of the
situations (Note: the list is not exhaustive):
a) A violation of protocol procedure has occurred
b) A PDU is received whose checksum is inconsistent with
contents
ISO DIS 8473 (May 1984) [Page 21]
RFC 926 December 1984
c) A PDU is received, but due to congestion, it cannot be processed
d) A PDU is received whose header cannot be analyzed
e) A PDU is received which cannot be segmented and cannot
forwarded because its length exceeds the maximum
service data unit size
f) A PDU is received whose destination address is unreachable
unknown
g) Incorrect or invalid source routing was specified. This
include a syntax error in the source routing field, and
or unreachable address in the source routing field, or a
which is not acceptable for other reasons
h) A PDU is received whose PDU lifetime has expired or the
expires during reassembly
i) A PDU is received which contains an unsupported option
6.10 Error Reporting
6.10.1
This function causes the return of an Error Report PDU to the
network-entity when a protocol data unit is discarded. An "
report flag" in the original PDU is set by the source network-
to indicate whether or not Error Report PDUs are to be returned
The Error Report PDU identifies the discarded PDU, specifies the
of error detected, and identifies the location at which the error
detected. Part or all of the discarded PDU is included in the
field of the Error Report PDU
The address of the originator of the Data Protocol Data Unit
ISO DIS 8473 (May 1984) [Page 22]
RFC 926 December 1984
conveyed as both the destination address of the Error Report PDU
well as the source address of the original Data PDU; the latter
contained in the Data field of the Error Report PDU. The address
the originator of the Error Report PDU is contained in the
address field of the header of the Error Report PDU
Note
Non-receipt of an Error Report PDU does not imply correct
of a PDU issued by a source network-entity
6.10.2
An Error Report PDU shall not be generated to report the
of a PDU that itself contains an Error Report
An Error Report PDU shall not be generated upon discarding of a
unless that PDU has the Error Report flag set to allow Error Reports
If a Data PDU is discarded, and has the Error Report flag set
allow Error Reports, an Error Report PDU shall be generated if
reason for discard (See Section 6.9)
a) destination address unreachable
b) source routing failure
c) unsupported options,
d) protocol violation
ISO DIS 8473 (May 1984) [Page 23]
RFC 926 December 1984
Note
It is intended that this list shall include all
reasons for discard; the list may therefore need to be amended
extended in the light of any changes made in the definitions
such reasons
If a Data PDU with the Error Report flag set to allow Error
is discarded for any other reason, an Error Report PDU may
generated (as an implementation option).
6.10.3 Processing of Error
Error Report PDUs are forwarded by intermediate network-entities
the same way as Data PDUs. It is possible that an Error Report
may be longer than the maximum user data size of a subnetwork
must be traversed to reach the origin of the discarded PDU. In
case, the Forward PDU function shall truncate the PDU to the
size acceptable
The entire header of the discarded data unit shall be included in
data field of the Error Report PDU. Some or all of the data field
the discarded data unit may also be included
Note
Since the suppression of Error Report PDUs is controlled by
originating network-entity and not by the NS User, care should
exercised by the originator with regard to suppressing ER PDUs
that error reporting is not suppressed for every PDU generated
ISO DIS 8473 (May 1984) [Page 24]
RFC 926 December 1984
6.11 PDU Header Error
The PDU Header Error Detection function protects against failure
intermediate or end-system network-entities due to the processing
erroneous information in the PDU header. The function is realized by
checksum computed on the PDU header. The checksum is verified at
point at which the PDU header is processed. If PDU header fields
modified (for example, due to lifetime function), then the checksum
modified so that the checksum remains valid
An intermediate system network-entity must not recompute the
for the entire header, even if fields are modified
Note
This is to ensure that inadvertent modification of a header while
PDU is being processed by an intermediate system (for example,
to a memory fault) may still be detected by the PDU Header
function
The use of this function is optional, and is selected by
originating network-entity. If the function is not used, the
field of the PDU header is set to zero
If the function is selected by the originating network-entity,
value of the checksum field causes the following formulae to
satisfied
(SUM) a = 0 (modulo 255)
i=1
(SUM) (L-i+1) a = 0 (modulo 255)
i=1
Where L = the number of octets in the PDU header,
a = value of octet at position i
ISO DIS 8473 (May 1984) [Page 25]
RFC 926 December 1984
When the function is in use, neither octet of the checksum field
be set to zero
Annex C contains descriptions of algorithms which may be used
calculate the correct value of the checksum field when the PDU
created, and to update the checksum field when the header is modified
6.12 Padding
The padding function is provided to allow space to be reserved in
PDU header which is not used to support any other function.
alignment must be maintained
Note
An example of the use of this function is to cause the data field
a PDU to begin on a convenient boundary for the
network-entity, such as a computer word boundary
6.13
An issue related to the quality of the network service is
protection of information flowing between transport-entities. A
may wish to control the distribution of secure data by
levels of security to PDUs. As a local consideration, the
Service user could be authenticated to ascertain whether the user
permission to engage in communication at a particular security
before sending the PDU. While no protocol exchange is required in
authentication process, the optional security parameter in the
part of the PDU header may be employed to convey the
security level between peer network-entities
The syntax and semantics of the security parameter are not
by this Standard. The security parameter is related to the "
from unauthorized access" Quality of service parameter described
ISO 8348/DAD1, Addendum to the Network Service Definition
Connectionless-mode Transmission. However, to
interoperation between end-systems and relay-systems by
different interpretations of the same encoding, a mechanism
provided to distinguish user-defined security encoding
standardized security encoding
ISO DIS 8473 (May 1984) [Page 26]
RFC 926 December 1984
6.14 Source Routing
The Source Routing function allows the originator to specify the
a generated PDU must take. Source routing can only be selected by
originator of a PDU. Source Routing is accomplished using a list
intermediate system addresses (or titles, see Section 5.3 and 5.5.1)
held in a parameter within the options part of the PDU Header.
size of the option field is determined by the
network-entity. The length of this option does not change as the
traverses the network. Associated with this list is an indicator
identifies the next entry in the list to be used; this indicator
advanced by the receiver of the PDU when the next address matches
own address. The indicator is updated as the PDU is forwarded so as
identify the appropriate entry at each stage of relaying
Two forms of the source routing option are provided. The first form
referred to as complete source routing, requires that the
path must be taken; if the specified path cannot be taken, the
must be discarded. The source may be informed of the discard using
Error Reporting function described in Section 6.10.
The second form is referred to as partial source routing. Again,
address in the list must be visited in the order specified while
route to the destination. However, with this form of source
the PDU may take any path necessary to arrive at the next address
the list. The PDU will not be discarded (for source routing
causes) unless one of the addresses specified cannot be reached by
available route
ISO DIS 8473 (May 1984) [Page 27]
RFC 926 December 1984
6.15 Record Route
The Record Route function permits the exact recording of the
taken by a PDU as it traverses a series of interconnected subnetworks
A recorded route is composed of a list of intermediate
addresses held in a parameter within the options part of the
header. The size of the option field is determined by the
network-entity. The length of this option does not change as the
traverses the network
The list is constructed as the PDU traverses a set of
subnetworks. Only intermediate system addresses are included in
recorded route. The address of the originator of the PDU is
recorded in the list. When an intermediate system network-
processes a PDU containing the record route parameter, the
inserts its own address (or titles, see Sections 5.3 or 5.5.1)
the list of recorded addresses
The record route option contains an indicator which identifies
next available octet to be used for recording of route.
identifier is updated as entries are added to the list. If
addition of the current address to the list would exceed the size
the option field, the indicator is set to show that recording of
has terminated. The PDU may still be forwarded to its
destination, without further addition of intermediate
addresses
Note
The Record Route function is principally intended to be used in
diagnosis of network problems. Its mechanism has been designed
this basis, and may provide a return path
ISO DIS 8473 (May 1984) [Page 28]
RFC 926 December 1984
6.16 Quality of Service Maintenance
In order to support the Quality of Service requested by
Service users, the Protocol may need to make QOS information
at intermediate systems. This information may be used by
entities in intermediate systems to make routing decisions where
decisions affect the overall QOS provided to NS users
In those instances where the QOS indicated cannot be maintained,
NS provider will attempt to deliver the PDU at a QOS less than
indicated. The NS provider will not necessarily provide a
of failure to meet the indicated quality of service
6.17 Classification of
Implementations do not have to support all of the functions
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
implementation does not support a Type 2 function, and
function is selected by a PDU, then the PDU shall
discarded, and an Error Report PDU shall be generated
forwarded to the originating network-entity, providing
the Error Report flag is set
Type 3: These functions may or may not be supported. If
implementation does not support a Type 3 function, and
function is selected by a PDU, then the function is
performed and the PDU is processed exactly as though
function was not selected. The protocol data unit shall
be discarded
Table 6-1 shows how the functions are divided into these
categories
ISO DIS 8473 (May 1984) [Page 29]
RFC 926 December 1984
+---------------------------------------------------+
| Function | Type |
|--------------------------------|------------------|
| | |
| PDU Composition | 1 |
| PDU Decomposition | 1 |
| Header Format Analysis | 1 |
| PDU Lifetime Control | 1 |
| Route PDU | 1 |
| Forward PDU | 1 |
| Segment PDU | 1 |
| Reassemble PDU | 1 |
| Discard PDU | 1 |
| Error Reporting | 1 (note 1) |
| PDU Header Error Detection | 1 (note 1) |
| Padding | 1 (notes 1 2) |
| Security | 2 |
| Complete Source Routing | 2 |
| Partial Source Routing | 3 |
| Priority | 3 |
| Record Route | 3 |
| Quality of Service Maintenance | 3 |
+---------------------------------------------------+
Table 6-1. Categorization of Protocol
ISO DIS 8473 (May 1984) [Page 30]
RFC 926 December 1984
Notes
1) While the Padding, Error Reporting, and Header Error
functions must be provided, they are provided only when
by the sending Network Service user
2) The correct treatment of the Padding function involves
processing. Therefore, this could equally be described as a
3 function
3) The rationale for the inclusion of type 3 functions is that
the case of some functions it is more important to forward
PDUs between intermediate systems or deliver them to
end-system than it is to support the functions. Type 3
should be used in those cases where they are of an
nature and should not be the cause of the discarding of a
when not supported
ISO DIS 8473 (May 1984) [Page 31]
RFC 926 December 1984
7 STRUCTURE AND ENCODING OF
7.1
All Protocol Data Units shall contain an integral number of octets
The octets in a PDU are numbered starting from one (1) and
in the order in which they are put into an SNSDU. The bits in an
are numbered from one (1) to eight (8), where bit one (1) is
low-order bit
When consecutive octets are used to represent a binary number,
lower octet number has the most significant value
Any subnetwork supporting this protocol is required to state in
specification the way octets are transferred, using the terms "
significant bit" and "least significant bit." The PDUs of
protocol are defined using the terms "most significant bit" and "
significant bit."
Note
When the encoding of a PDU is represented using a diagram in
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
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
ISO DIS 8473 (May 1984) [Page 32]
RFC 926 December 1984
2) the data field, if present
This structure is illustrated below
Part: Described in:
+-------------------+
| Fixed Part | Section 7.2
+-------------------+
+-------------------+
| Address Part | Section 7.3
+-------------------+
+-------------------+
| Segmentation Part | Section 7.4
+-------------------+
+-------------------+
| Options Part | Section 7.5
+-------------------+
+-------------------+
| Data | Section 7.6
+-------------------+
Figure 7-1. PDU
ISO DIS 8473 (May 1984) [Page 33]
RFC 926 December 1984
7.2 Fixed
7.2.1
The fixed part contains frequently occuring parameters including
type code (DT or ER) of the protocol data unit. The length and
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
7.2.2 Network Layer Protocol
The value of this field shall be binary 1000 0001. This
identifies this Network Layer Protocol as ISO 8473, Protocol
Providing the Connectionless-mode Network Service
ISO DIS 8473 (May 1984) [Page 34]
RFC 926 December 1984
7.2.3 Length
The length is indicated by a binary number, with a maximum value
254 (1111 1110). The length indicated is the length in octets of
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
length is the same for all segments (Derived PDUs) of the
PDU, and is the same as the header length of the Initial PDU
7.2.4 Version/Protocol Identifier
The value of this field is binary 0000 0001. This Identifies
standard version of ISO 8473, Protocol for Providing
Connectionless-mode Network Service
7.2.5 PDU
The Lifetime field is encoded as a binary number representing
remaining lifetime of the PDU, in units of 500 milliseconds
The Lifetime field is set by the originating network-entity, and
decremented by every network-entity which processes the PDU. The
shall be discarded if the value of the field reaches zero
When a network-entity processes a PDU, it decrements the Lifetime
at least one. The Lifetime shall be decremented by more than one
the sum of
1) the transit delay in the subnetwork from which the PDU
received;
ISO DIS 8473 (May 1984) [Page 35]
RFC 926 December 1984
2) the delay within the system processing the
exceeds or is estimated to exceed 500 milliseconds. In this case,
lifetime field should be decremented by one for each additional 500
milliseconds of delay. The determination of delay need not
precise, but where error exists the value used shall be
overestimate, not an underestimate
If the Lifetime reaches a value of zero before the PDU is
to the destination, the PDU shall be discarded. The Error
function shall be invoked, as described in Section 6.10,
Reporting Function, and may result in the generation of an ER PDU.
is a local matter whether the destination network-entity performs
Lifetime Control function
When the Segmentation function is applied to a PDU, the
field is copied into all of the Derived PDUs
7.2.6
7.2.6.1 Segmentation Permitted and More Segments
The Segmentation Permitted flag determines whether segmentation
permitted. A value of one indicates that segmentation is permitted
A value of zero indicates that the non-segmenting protocol subset
employed. Where this is the case, the segmentation part of the
header is not present, and the Segment Length field serves as
Total Length field
The More Segments flag indicates whether the data segment in
PDU contains (as its last octet) the last octet of the User Data
the NSDU. When the More Segments flag is set to one (1)
segmentation has taken place and the last octet of the NSDU is
contained in this PDU. The More 