As per Relevance of the word protocol, we have this rfc below:
Network Working Group ANSI X3S3.3 86-80
Request for Comments: 994 ISO TC97/SC6/N 3998
March 1986
I S
INTERNATIONAL ORGANIZATION FOR
ORGANISATION INTERNATIONALE DE
______________________________________________________________________
| |
| ISO/TC 97/SC 6 |
| TELECOMMUNICATIONS AND INFORMATION |
| EXCHANGE BETWEEN SYSTEMS |
| Secretariat: USA (ANSI) |
| |
| |
|_____________________________________________________________________|
Title: Final Text of DIS 8473, Protocol for Providing the Connectionless
mode Network
Source: DIS 8473
ISO 8473 [Page 1]
RFC 994 December 1986
1 Scope and Field of Application 6
2 References 7
SECTION ONE. GENERAL 9
3 Definitions 9
3.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9
3.2 Service Conventions Definitions . . . . . . . . . . . . . . . 9
3.3 Network Layer Architecture Definitions . . . . . . . . . . . . 9
3.4 Network Layer Addressing Definitions . . . . . . . . . . . . . 10
3.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10
4 Symbols and Abbreviations 11
4.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 11
4.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 11
4.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11
5 Overview of the Protocol 12
5.1 Internal Organization of the Network Layer . . . . . . . . . . 12
5.2 Subsets of the Protocol . . . . . . . . . . . . . . . . . . . 12
5.3 Addresses and Titles . . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Addresses . . . . . . . . . . . . . . . . . . . . . . 13
5.3.2 Network-entity Titles . . . . . . . . . . . . . . . . 13
5.4 Service Provided by the Network Layer . . . . . . . . . . . . 14
5.5 Underlying Service Assumed by the Protocol . . . . . . . . . . 14
5.5.1 Subnetwork Points of Attachment . . . . . . . . . . . 15
5.5.2 Subnetwork Quality of Service . . . . . . . . . . . . 15
5.5.3 Subnetwork User Data . . . . . . . . . . . . . . . . 16
5.5.4 Subnetwork Dependent Convergence Functions . . . . . . 16
5.6 Service Assumed from Local Environment . . . . . . . . . . . . 16
SECTION TWO. SPECIFICATION OF THE PROTOCOL 18
6 Protocol Functions 18
6.1 PDU Composition Function . . . . . . . . . . . . . . . . . . . 18
6.2 PDU Decomposition Function . . . . . . . . . . . . . . . . . . 19
6.3 Header Format Analysis Function . . . . . . . . . . . . . . . 19
ISO 8473 [Page 2]
RFC 994 December 1986
6.4 PDU Lifetime Control Function . . . . . . . . . . . . . . . . 20
6.5 Route PDU Function . . . . . . . . . . . . . . . . . . . . . . 20
6.6 Forward PDU Function . . . . . . . . . . . . . . . . . . . . . 21
6.7 Segmentation Function . . . . . . . . . . . . . . . . . . . . 21
6.8 Reassembly Function . . . . . . . . . . . . . . . . . . . . . 22
6.9 Discard PDU Function . . . . . . . . . . . . . . . . . . . . . 23
6.10 Error Reporting Function . . . . . . . . . . . . . . . . . . . 24
6.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 24
6.10.2 Requirements . . . . . . . . . . . . . . . . . . . . . 25
6.10.3 Processing of Error Reports . . . . . . . . . . . . . 25
6.10.4 Relationship of Data PDU Options to Error Reports . . 26
6.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . . 27
6.12 Padding Function . . . . . . . . . . . . . . . . . . . . . . . 28
6.13 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.14 Source Routing Function . . . . . . . . . . . . . . . . . . . 28
6.15 Record Route Function . . . . . . . . . . . . . . . . . . . . 29
6.16 Quality of Service Maintenance Function . . . . . . . . . . . 30
6.17 Priority Function . . . . . . . . . . . . . . . . . . . . . . 31
6.18 Congestion Notification Function . . . . . . . . . . . . . . . 31
6.19 Classification of Functions . . . . . . . . . . . . . . . . . 31
7 Structure and Encoding of PDUs 33
7.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.6.1 Segmentation Permitted . . . . . . . . . . . 35
7.2.6.2 More Segments . . . . . . . . . . . . . . . 35
7.2.6.3 Error Report . . . . . . . . . . . . . . . 36
7.2.7 Type Code . . . . . . . . . . . . . . . . . . . . . . 36
7.2.8 PDU Segment Length . . . . . . . . . . . . . . . . . 36
7.2.9 PDU Checksum . . . . . . . . . . . . . . . . . . . . 36
7.3 Address Part . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1.1 Destination and Source Addresses . . . . . . 37
7.4 Segmentation Part . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1 Data Unit Identifier . . . . . . . . . . . . . . . . . 38
7.4.2 Segment Offset . . . . . . . . . . . . . . . . . . . . 38
7.4.3 PDU Total Length . . . . . . . . . . . . . . . . . . . 39
7.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . 39
7.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 39
7.5.2 Padding . . . . . . . . . . . . . . . . . . . . . . . 40
7.5.3 Security . . . . . . . . . . . . . . . . . . . . . . . 40
7.5.3.1 Source Address Specific . . . . . . . . . . 41
7.5.3.2 Destination Address Specific . . . . . . . . 41
7.5.3.3 Globally Unique Security . . . . . . . . . . 41
7.5.4 Source Routing . . . . . . . . . . . . . . . . . . . 41
ISO 8473 [Page 3]
RFC 994 December 1986
7.5.5 Recording of Route . . . . . . . . . . . . . . . . . . 42
7.5.6 Quality of Service Maintenance . . . . . . . . . . . . 43
7.5.6.1 Source Address Specific . . . . . . . . . . 43
7.5.6.2 Destination Address Specific . . . . . . . . 43
7.5.6.3 Globally Unique QoS . . . . . . . . . . . . 43
7.5.7 Priority . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Data Part . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.7 Data (DT) PDU . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 46
7.7.1.1 Fixed Part . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.2 Addresses . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . 47
7.7.1.4 Options . . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.5 Data . . . . . . . . . . . . . . . . . . . . . . . 47
7.8 Inactive Network Layer Protocol . . . . . . . . . . . . . . . 47
7.8.1 Network Layer Protocol Id . . . . . . . . . . . . . . 47
7.8.2 Data Field . . . . . . . . . . . . . . . . . . . . . 47
7.9 Error Report PDU (ER) . . . . . . . . . . . . . . . . . . . . 48
7.9.1 Structure . . . . . . . . . . . . . . . . . . . . . . 48
7.9.1.1 Fixed Part . . . . . . . . . . . . . . . . . 49
7.9.1.2 Addresses . . . . . . . . . . . . . . . . . 49
7.9.1.3 Options . . . . . . . . . . . . . . . . . . 49
7.9.1.4 Reason for Discard . . . . . . . . . . . . . 50
7.9.1.5 Error Report Data Field . . . . . . . . . . 51
8 Conformance 51
8.1 Provision of Functions for Conformance . . . . . . . . . . . . 51
List of
1 Service Primitives for Underlying Service . . . . . . . . . . . . 14
2 Service Primitives for Underlying Service . . . . . . . . . . . . 14
3 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Categorization of Protocol Functions . . . . . . . . . . . . . . . 32
5 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Encoding of Option Parameters . . . . . . . . . . . . . . . . . . 39
7 Reason for Discard . . . . . . . . . . . . . . . . . . . . . . . . 50
8 Categorization of Functions . . . . . . . . . . . . . . . . . . . 52
List of
1 Interrelationship of Standards . . . . . . . . . . . . . . . . . 6
2 PDU Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . . . 34
4 PDU Header -- Address Part . . . . . . . . . . . . . . . . . . . 37
5 Address Parameters . . . . . . . . . . . . . . . . . . . . . . . . 38
6 PDU Header -- Segmentation Part . . . . . . . . . . . . . . . . . 38
7 PDU Header -- Options Part . . . . . . . . . . . . . . . . . . . . 39
8 PDU Header -- Data Field . . . . . . . . . . . . . . . . . . . . 45
ISO 8473 [Page 4]
RFC 994 December 1986
9 DT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10 Inactive Network Layer Protocol . . . . . . . . . . . . . . . . . 47
11 Error Report PDU . . . . . . . . . . . . . . . . . . . . . . . . . 48
ISO 8473 [Page 5]
RFC 994 December 1986
0
This Protocol Standard is one of a set of International
produced to facilitate the interconnection of open systems. The
of standards covers the services and protocols required to
such interconnection
This Protocol Standard is positioned with respect to other
standards by the layers defined in the Reference Model for Open Sys
tems Interconnection (ISO 7498). In particular, it is a protocol
the Network Layer. This Protocol may be used between network-
in end systems or in Network Layer relay systems (or both). It pro
vides the Connectionless-mode Network Service as defined in
1 to the Network Service Definition Covering Connectionless-
Transmission (ISO 8348/AD1).
The interrelationship of these standards is illustrated in Figure 1
below
--------------------+--- ISO NETWORK SERVICE PROVIDER -----^-----------------
| |
| |
| |
PROTOCOL | REFERENCE TO AIMS -----------------+
|
SPECIFICATION | REFERENCE TO ASSUMPTIONS -----------+
| |
| |
| |
--------------------+---SUBNETWORK SERVICE DEFINITION(S)---v-----------------
Figure 1: Interrelationship of
1 Scope and Field of
This International Standard specifies a protocol which is used
provide the Connectionless-mode Network Service as described in Ad
dendum 1 to the Network Service Definition Covering Connectionless
mode Transmission. The protocol relies upon the provision of
underlying connectionless-mode service by real subnetworks and/
data links. The underlying connectionless-mode service assumed by
protocol may be obtained either directly, from a connectionless-
real subnetwork, or indirectly, through the operation of an appropri
ate Subnetwork Dependent Convergence Function (SNDCF) or
(SNDCP) over a connection-mode real subnetwork as described in
8648, Internal Organization of the Network Layer
ISO 8473 [Page 6]
RFC 994 December 1986
This Standard specifies
a) procedures for the connectionless transmission of data
control information from one network-entity to a
network-entity
b) the encoding of the protocol data units (PDUs) used for
transmission of data and control information, comprising
variable-length 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
exchange 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 an
service provider through the exchange of service primitives
2
ISO 7498, Information Processing Systems --- Open Systems Intercon
nection --- Basic Reference
DIS 7498/AD1, Information Processing Systems --- Open Systems In
terconnection --- Addendum to ISO 7498 Covering Connectionless-
ISO 8348, Information Processing Systems --- Telecommunications
Information Exchange between Systems --- Network Service
ISO 8348/AD1, Information Processing Systems ---
and Information Exchange between Systems --- Addendum to the Net
work Service Definition Covering Connectionless-mode
ISO 8348/AD2, Information Processing Systems ---
and Information Exchange between Systems --- Addendum to the Net
work Service Definition Covering Network Layer Addressing
DIS 8648, Information Processing Systems --- Telecommunications
Information Exchange between Systems --- Internal Organization of
Network
ISO 8473 [Page 7]
RFC 994 December 1986
ISO 8509, Technical Report --- OSI Service
ISO 9074, A Formal Description Technique based on an Extended
Transition
________________________________
*At present, at the stage of Draft; publication anticipated
due course
ISO 8473 [Page 8]
RFC 994 December 1986
SECTION ONE.
3
3.1 Reference Model
This document makes use of the following concepts defined in ISO 7498:
(a) End
(b) Network
(c) Network
(d) Network
(e) Network protocol data
(f) Network
(g) Network
(h) Network service access
(i) Network service access point
(j)
(k)
(l) Service data
3.2 Service Conventions
This Protocol Standard makes use of the following terms from the
Service Conventions Technical Report (ISO TR 8509):
(a) Service
(b) Service
3.3 Network Layer Architecture
This Protocol Standard makes use of the following terms from
Internal Organization of the Network Layer (ISO 8648):
(a) Intermediate
(b) Relay
(c)
ISO 8473 [Page 9]
RFC 994 December 1986
3.4 Network Layer Addressing
This Protocol Standard makes use of the following terms from ISO 8348/AD2,
Addendum to the Network Service Definition Covering Network
addressing
(a) Network addressing
(b) Network protocol address
(c) Subnetwork point of
3.5 Additional
For the purposes of this Protocol Standard, the following
apply
(a) derived PDU --- a protocol data unit whose fields are
to those of an initial PDU, except that it carries only a
of the user data from an N-UNITDATA request
(b) initial PDU --- a protocol data unit carrying the whole of
userq data from an N-UNITDATA request
(c) local matter --- a decision made by a system concerning
behavior in the Network Layer that is not prescribed
constrained by this Protocol Standard
(d) network-entity title --- an identifier for a network-
which has the same abstract syntax as an NSAP address, and
can be used to unambiguously identify a network-entity in an
or intermediate system
(e) reassembly --- the act of regenerating an initial PDU from
or more derived PDUs
(f) segment --- a distinct unit of data consisting of part or
of the user data provided in the N-UNITDATA request and
in the N-UNITDATA indication
(g) segmentation --- the act of generating two or more derived
from an initial or derived PDU. The derived PDUs together
the entire user data of the initial or derived PDU from which
were generated
Note
It is possible that such an initial PDU will never actually
generated for a particular N-UNITDATA request, owing to
immediate application of segmentation
ISO 8473 [Page 10]
RFC 994 December 1986
4 Symbols and
4.1 Data
NSDU Network Service Data
PDU Protocol 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
CS
DA Destination
DAL Destination Address
DUID Data Unit
E/R Error Report
LI Length
LT
MS More Segments
NLPID Network Layer Protocol
SA Source
SAL Source Address
SL Segment
SO Segment
SP Segmentation Permitted
TL Total
TP
V/P Version/Protocol Identifier
4.4
DA Destination
QOS Quality of
SA Source
4.5
CLNP Connectionless-mode Network
NS Network
NPAI Network Protocol Address
NSAP Network Service Access
SDU Service Data
SN
SNDCF Subnetwork Dependent Convergence
SNDCP Subnetwork Dependent Convergence
SNICP Subnetwork Independent Convergence
SNPA Subnetwork Point of
ISO 8473 [Page 11]
RFC 994 December 1986
5 Overview of the
5.1 Internal Organization of the Network
The architectural organization of the Network Layer is described in
separate document, Internal Organization of the Network Layer (
8648). ISO 8648 identifies and categorizes the way in which
can be performed within the Network Layer by Network Layer protocols
thus providing a uniform framework for describing how
operating either individually or cooperatively in the Network
can be used to provide the OSI Network Service. This protocol
designed to be used in the context of the internetworking
approach to the provision of the Connectionless-mode Network
defined in that Standard
This protocol is intended for use in the Subnetwork Independent Con
vergence Protocol (SNICP) role. A protocol which fulfills the
role operates to construct the OSI Network Service over a defined
of underlying services, performing functions which are necessary
support the uniform appearance of the OSI Connectionless-mode
Service over a homogeneous or heterogeneous set of
subnetworks. This protocol is defined to accommodate
where Subnetwork Dependent Convergence Protocols and/or
Access Protocols do not provide all of the functions necessary
support the Connectionless-mode Network Service over all or part
the path from one NSAP to another
As described in ISO 8648, a protocol at the Network Layer may
different roles in different configurations. Although this
is designed particularly to be suitable for a SNICP role in the con
text of the internetworking protocol approach to the provision of
Connectionless-mode Network Service, it may also be used to
other roles and may therefore be used in the context of other ap
proaches to subnetwork interconnection
The specification of this protocol begins with a definition of
underlying service which it assumes. This service is made
by the operation of other Network Layer protocols or through provi
sion of the Data Link Service. The underlying service assumed by
protocol is described in Clause 5.5.
5.2 Subsets of the
Two proper subsets of the full protocol are defined which permit
use of known subnetwork characteristics and are therefore not subnet
work independent
The Inactive Network Layer protocol subset is a null-function
which can be used when it is known that the source and
end-systems are connected by a single subnetwork, and when none
the functions performed by the full protocol is required to
ISO 8473 [Page 12]
RFC 994 December 1986
the Connectionless-mode Network Service between any pair of end
systems
The Non-segmenting protocol subset permits simplification of
header where it is known that the source and destination end-
are connected by subnetworks whose service data unit sizes
greater than or equal to a known bound which is large enough so
segmentation is not required. This subset is selected by setting
Segmentation Permitted flag to zero
5.3 Addresses and
The following Clauses describe the addresses and titles used by
Protocol
5.3.1
The Source Address and Destination Address parameters referred to
Clause 7.3 of this International Standard are OSI Network Service Ac
cess Point Addresses. The syntax and semantics of an OSI
Service Access Point Address are described in a separate document
ISO 8348/AD2, Addendum to the Network Service Definition
Network Layer Addressing
The encoding used by this protocol to convey NSAP Addresses shall
the preferred binary encoding specified in ISO 8348/AD2; the
NSAP address, taken as a whole, is represented explicitly as a
of binary octets. This string is conveyed in its entirety in the ad
dress fields described in Clause 7.3. The rules governing the genera
tion of the preferred binary encoding are described in ISO 8348/AD2.
5.3.2 Network-entity
A network-entity title is an identifier for a network-entity in
endsystem or intermediate-system. Network-entity titles are
from the same name space as NSAP addresses, and the determination
whether an address is an NSAP address or a network-entity
depends on the context in which the address is interpreted. The en
tries in the Source Routing and Recording of Route parameters
in Clauses 7.5.4 and 7.5.5 are network-entity titles. The Source Ad
dress and Destination Address parameters in the Error Report PDU de
fined in Clause 7.9.1.2 are also network-entity titles
The encoding used by this protocol to convey network-entity
shall also be the preferred binary encoding; again, the
network-entity title, taken as a whole, is represented explicitly
a string of binary octets. This string is conveyed in its
in the fields described in Clauses 7.5.4, 7.5.5, and 7.9.1.2.
ISO 8473 [Page 13]
RFC 994 December 1986
5.4 Service Provided by the Network
The service provided by this protocol is the Connectionless-mode Net
work Service described in ISO 8348/AD1, Addendum to the Network Ser
vice Definition Covering Connectionless-mode Transmission. The Net
work Service primitives provided are summarized in Table 1:
_____________________________________________________________
| PRIMITIVES PARAMETERS |
|____________________________________________________________ |
| N_UNITDATA .Request | N_Source_Address, |
| .Indication | N_Destination_Address, |
| | N_Quality_of_Service, |
| | N_Userdata |
|_________________________________|___________________________|
Table 1: Service Primitives for Underlying
The Addendum to the Network Service Definition
Connectionless-mode Transmission (ISO 8348/AD1) states that the max
imum size of a connectionless-mode Network-service-data-unit (NSDU
is limited to 64512 octets
5.5 Underlying Service Assumed by the
The underlying service required to support this protocol is
by the following primitives
_____________________________________________________________
| PRIMITIVES PARAMETERS |
|____________________________________________________________ |
| SN_UNITDATA .Request | SN_Source_Address, |
| .Indication | SN_Destination_Address, |
| | SN_Quality_of_Service, |
| | SN_Userdata |
|_________________________________|___________________________|
Table 2: Service Primitives for Underlying
Note
These service primitives are used to describe the abstract
which exists between the ISO 8473 protocol machine and an
real subnetwork or a Subnetwork Dependent Convergence Function
operates over a real subnetwork or real data link to provide
required underlying service
ISO 8473 [Page 14]
RFC 994 December 1986
5.5.1 Subnetwork Points of
The source and destination addresses specify the points of
to a public or private subnetwork(s) involved in the transmission
Subnetwork Point of Attachment addresses (SNPAs) are defined by
individual subnetwork authority
The syntax and semantics of SNPAs are not defined in this Standard
5.5.2 Subnetwork Quality of
Subnetwork Quality of Service describes aspects of an
connectionless-mode service which are attributable solely to
underlying service
Associated with each connectionless-mode transmission, certain meas
ures of Quality of Service are requested when the primitive action
initiated. These requested measures (or parameter values and op
tions) are based on a priori knowledge of the service(s) made avail
able to it by the subnetwork. Knowledge of the nature and type
service available is typically obtained prior to an invocation of
underlying connectionless-mode service
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. The following parameters as de
fined in ISO 8348/AD1, Addendum to the Network Service
Covering Connectionlessmode Transmission, may be employed
(a) transit delay
(b) protection against unauthorized access
(c) cost determinants
(d) priority;
(e) residual error probability
Note
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, an attempt shall be made to deliver the
data unit at whatever Quality of Service is available
ISO 8473 [Page 15]
RFC 994 December 1986
5.5.3 Subnetwork User
The SN-Userdata is an ordered multiple of octets, and is
transparently between the specified subnetwork points of attachment
The underlying service assumed by the CLNP is required to support
service data unit size of at least 512 octets
If the minimum service data unit sizes supported by all of the sub
networks involved in the transmission of a particular PDU are
to be large enough that segmentation is not required, then the Non
segmenting protocol subset may be used
5.5.4 Subnetwork Dependent Convergence
Subnetwork Dependent Convergence Functions may be performed to pro
vide an underlying connectionless-mode service in the case where
real subnetwork does not inherently provide the connectionless-
service assumed by the protocol. If a subnetwork inherently
a connection-mode service, a Subnetwork Dependent Convergence Func
tion provides a mapping into the required underlying service. Sub
network Dependent Convergence Functions may also be required in
cases where functions assumed from the underlying service are
performed. In some cases, this may require the operation of an ex
plicit protocol (i.e., a protocol involving explicit exchanges
protocol control information between peer network-entities) in
Subnetwork Dependent Convergence Protocol (SNDCP) role. However
there may also be cases where the functionality required to
the SNDCP role consists simply of a set of rules for manipulating
underlying service
5.6 Service Assumed from Local
A timer service must be provided to allow the protocol entity
schedule 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
that it should initiate a timer of the specified name and
and 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-TIMER Re
quest primitive has elapsed
ISO 8473 [Page 16]
RFC 994 December 1986
The S--TIMER Cancel primitive is an indication to the local environ
ment that the specified timer(s) should be canceled. If the
parameter is not specified, then all timers with the specified
are canceled; 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 specified
Table 3.
__________________________________________________
| PRIMITIVES PARAMETERS |
|_________________________________________________|
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|___________________________|_____________________|
Table 3: Timer
The time parameter indicates the time duration of the specified ti
mer. An identifiying label is associated with a timer by means
the name parameter. The subscript parameter specifies a value to dis
tinguish timers with the same name. The name and subscript taken to
gether constitute a unique reference to the timer
Timers used in association with a specific protocol funtion are de
fined under that protocol function
Note
This International Standard does not define specific values
the timers. Any derivations described in this Standard are
mandatory. Timer values should be chosen so that the
Quality of Service can be provided, given the known
of the underlying service
ISO 8473 [Page 17]
RFC 994 December 1986
SECTION TWO. SPECIFICATION OF THE
6 Protocol
This Clause describes the functions performed as part of the Proto
col
Not all of the functions must be performed by every implementation
Clause 6.17 specifies which functions may be omitted, and the
behavior when requested functions are not implemented
6.1 PDU Composition
This function is responsible for the construction of a protocol
unit according to the rules governing the encoding of PDUs given
Clause 7. Protocol Control Information required for delivering
data unit to its destination is determined from current state and lo
cal information and from the parameters associated with the N
UNITDATA Request
Network Protocol Address Information (NPAI) for the Source
and Destination Address fields of the PDU header is derived from
NS-Source-Address and NS-Destination-Address parameters. The NS
Destination-Address and NS-Quality-of-Service parameters,
with current state and local information, are used to determine
optional functions are to be selected. User data passed from the Net
work Service User (NS-Userdata) forms the Data field of the
data unit
During the composition of the protocol data unit, a Data Unit Iden
tifier is assigned to distinguish this request to transmit NS
Userdata to a particular destination NS User from other such re
quests. The originator of the PDU must choose the Data Unit Identif
ier so that it remains unique (for this Source and Destination ad
dress pair) for the maximum lifetime of the Initial PDU in the net
work; this rule applies for any PDUs derived from the Initial PDU
a result of the application of the Segmentation Function (see
6.7). Derived PDUs are considered to correspond to the same
PDU, and hence the same N-UNITDATA Request, if they have the
Source Address, Destination Address, and Data Unit Identifier
The Data Unit Identifier is also available for ancillary
such as error reporting (see Clause 6.10).
The total length of the PDU in octets is determined by the
and placed in the Total Length field of the PDU header. This field
not changed in any Derived PDU for the lifetime of the protocol
unit
ISO 8473 [Page 18]
RFC 994 December 1986
When the Non-segmenting protocol subset is employed, neither the To
tal Length field nor the Data Unit Identifier field is present.
rules governing the PDU composition function are modified in
case as follows. During the composition of the protocol data unit
the total length of the PDU in octets is determined by the
and placed in the Segment Length field of the PDU header. This
is not changed for the lifetime of the PDU. No Data Unit Identifica
tion is provided
6.2 PDU Decomposition
This function is responsible for removing the Protocol Control Infor
mation from the protocol data unit. During this process,
pertinent to the generation of the N-UNITDATA Indication is deter
mined as follows. The NS-Source-Address and NS-Destination-
parameters of the N-UNITDATA Indication are recovered from the
in the Source and Destination Address fields of the PDU header.
data field of the PDU received is reserved until all segments of
original service data unit have been received; collectively,
form the NS-Userdata parameter of the N-UNITDATA Indication. Infor
mation relating to the Quality of Service provided during
transmission of the PDU is determined from the Quality of Service
other information contained in the Options Part of the PDU header
This information constitutes the NS-Quality-of-Service parameter
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
If the protocol data unit has a Network Layer Protocol Identifier in
dicating that this is a standard version of the Protocol, this func
tion determines whether a received PDU has reached its destination
using the Destination Address provided in the PDU. If the
Address provided in the PDU identifies an NSAP served by
network-entity, then the PDU has reached its destination; if not,
must be forwarded
If the protocol data unit has a Network Layer Protocol Identifier in
dicating that the Inactive Network Layer Protocol subset is in use
then no further analysis of the PDU header is required. The network
entity in this case determines that either the Subnetwork Point
Attachment address encoded as network protocol address information
the supporting subnetwork protocol corresponds directly to an
address serviced by this network-entity or that an error has oc
curred. If the subnetwork protocol data unit has been
correctly, then the PDU may be decomposed according to the
described for that particular subnetwork protocol
ISO 8473 [Page 19]
RFC 994 December 1986
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 wheth
er its assigned lifetime has expired, in which case it must be dis
carded
The operation of the PDU 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 mil
liseconds). The Lifetime of the Initial PDU is determined by the ori
ginating network-entity, and placed in the Lifetime field of the PDU
When the Segmentation function is applied to a PDU, the value of
Lifetime field of the Initial PDU is copied into all of the
PDUs
The Lifetime of the PDU is decremented by every network-entity
processes the PDU. When a network-entity processes a PDU, it decre
ments the PDU Lifetime by at least one. The value of the PDU Life
time field shall be decremented by more than one if the sum of
1. the transit delay in the underlying service from which the
was received;
2. the delay within the system processing the
exceeds or is estimated to exceed 500 milliseconds. In this case
the lifetime field should be decremented by one for each
500 milliseconds of delay. The determination of delay need not
precise, but where a precise value cannot be ascertained, the
used shall be an overestimate, not an underestimate
If the Lifetime field reaches a value of zero before the PDU
delivered to the destination, the PDU must be discarded. The
Reporting function shall be invoked as described in Clause 6.10, Er
ror Reporting Function, and may result in the generation of an
Report PDU. It is a local matter whether the destination network
entity performs the Lifetime Control function
6.5 Route PDU
This function determines the network-entity to which a protocol
unit should be forwarded and the underlying service that must be
to reach that network-entity, using the Destination Address and
total length of the PDU. Where segmentation is required, the
PDU function further determines over which underlying service
PDUs/segments must be sent in order to reach that network-entity.
results of the Route PDU function are passed to the Forward PDU func
tion (along with the PDU itself) for further processing.
of the underlying service that must be used to reach the "next" sys
ISO 8473 [Page 20]
RFC 994 December 1986
tem in the route is initially influenced by the NS-Quality-of- Ser
vice parameter of the N-UNITDATA Request, which specifies the QoS re
quested by the sending NS User. Whether this QoS is to be
directly by the CLNP, through the selection of the Quality of
Maintenance parameter and other optional parameters, or through
QoS facilities offered by each of the underlying services is deter
mined prior to invocation of the Forward PDU function. Route selec
tion by intermediate systems may subsequently be influenced by
values of the Quality of Service Maintenance parameter (if present),
and other optional parameters (if present).
6.6 Forward PDU
This function issues an SN-UNITDATA Request primitive (see
5.5), supplying the subnetwork or SNDCF identified by the Route
function with the protocol data unit as user data to be transmitted
the address information required by that subnetwork or SNDCF to iden
tify the "next" system within the subnetwork-specific
domain (this may be an intermediate-system or the destination end
system), and Quality of Service constraints (if any) to be
in the processing of the user data
When the PDU to be forwarded is longer than the maximum service
user size provided by the underlying service, the Segmentation func
tion is applied (See Clause 6.7, which follows).
6.7 Segmentation
Segmentation is performed when the size of the protocol data unit
greater than the maximum service data unit size supported by
underlying service to be used to transmit the PDU
Segmentation consists of composing two or more new PDUs (
PDUs) from the PDU received. The PDU received may be the Initial PDU
or it may be a Derived PDU. All of the header information from
PDU to be segmented, with the exception of the segment length
checksum fields of the fixed part, and the segment offset of the seg
mentation part, is duplicated in each Derived PDU, including all
the address part, the data unit identifier and total length of
segmentation part, and the options part (if present).
Note
The rules for forwarding and segmentation guarantee that
header length is the same for all segments (Derived PDUs)
the Initial PDU, and is the same as the header length of
Initial PDU. The size of a PDU header will not change due
operation of any protocol function
The user data encapsulated within the PDU received are divided
that the Derived PDUs satisfy the size requirements of the user
parameter field of the primitive used to access the underlying ser
ISO 8473 [Page 21]
RFC 994 December 1986
vice
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
Segmentation shall not result in the generation of a Derived PDU con
taining less than eight (8) octets of user data
The following fields of the PDU header are used in conjunction
the Segmentation function
(a) Segment Offset --- identifies, with respect to the
of the Initial PDU, the octet at which the segment begins
(b) Segment Length --- specifies the number of octets in
Derived PDU, including both header and data
(c) More Segments Flag --- is set to one if this Derived
does not contain, as its final octet of user data, the
octet of the Initial PDU;
(d) Total Length --- specifies the entire length of the
PDU, including both header and data
Derived PDUs may be further segmented without constraining the rout
ing of the individual Derived PDUs. The Segmentation Permitted
is set to one to indicate that segmentation is permitted. If the Ini
tial PDU is not to be segmented at any point during its lifetime
the network, the flag is set to zero by the source network-entity
The setting of the Segmentation Permitted flag cannot be changed
any other network-entity for the lifetime of the Initial PDU and
Derived PDUs
6.8 Reassembly
The Reassembly function reconstructs the Initial PDU from the
PDUs generated by the operation of the Segmentation Function on
Initial PDU (and, recursively, on subsequent Derived PDUs). A
on the time during which segments (Derived PDUs) of an Initial
will be held at a reassembly point before being discarded is provid
ed, so that reassembly resources may be released when it is no
expected that any outstanding segments of the Initial PDU will
at the reassembly point. Upon reception of a Derived PDU, a reassem
bly timer is initiated with a value which indicates the amount
ISO 8473 [Page 22]
RFC 994 December 1986
time which must elapse before any outstanding segments of the
PDU shall be assumed to be lost. When this timer expires, all seg
ments (Derived PDUs) of the Initial PDU held at the reassembly
are discarded, the resources allocated for those segments are freed
and if selected, an Error Report is generated (see Clause 6.10).
While the exact relationship between reassembly lifetime and
lifetime is a local matter, the Reassembly Function must preserve
intent of the PDU lifetime. Consequently, the reassembly
must discard PDUs whose lifetime would otherwise have expired
they not been under the control of the reassembly function
Note
1. Methods of bounding reassembly lifetime are discussed
Annex B
2. The Segmentation and Reassembly functions are intended
be used in such a way that the fewest possible segments
generated at each segmentation point and reassembly
place at the final destination of a PDU. However,
schemes
(a) interact with the routing algorithm to favor paths
which fewer segments are generated
(b) generate more segments than absolutely required
order to avoid additional segmentation at some
point;
(c) allow partial or full reassembly at some
point along the
are not precluded. The information necessary to enable
use of one of these alternative strategies may be
available through the operation of a Network Layer
function or by other means
3. The originator of the Initial PDU determines the value of
Segmentation Permitted flag in the Initial PDU and all
PDUs (if any). Partial or full reassembly in an
system (Note 2 (c) above) cannot change this value in
Initial PDU or any PDU derived from it, and cannot
add or remove the segmentation part of the header
6.9 Discard PDU
This function performs all of the actions necessary to free
resources reserved by the network-entity when any of the
situations is encountered (Note: the list is not exhaustive):
(a) A violation of protocol procedure has occurred
ISO 8473 [Page 23]
RFC 994 December 1986
(b) A PDU is received whose checksum is inconsistent with
contents
(c) A PDU is received, but due to local congestion, it cannot
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
unit size supported by any underlying service available
transmission of the PDU to the next network-entity on
chosen route
(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, an
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
lifetime expires during reassembly
(i) A PDU is received which contains an unsupported option
6.10 Error Reporting
6.10.1
This function causes an attempt to return an Error Report PDU to
source network-entity when a protocol data unit is discarded in ac
cordance with Clause 6.9.
The Error Report PDU identifies the discarded PDU, specifies the
of error detected, and identifies the location in the header of
discarded PDU at which the error was detected. At least the
header of the Discarded PDU (and, at the discretion of the
of the Error Report PDU none, all, or part of the data field)
placed in the data field of the Error Report PDU
The originator of a Data PDU may control the generation of Error Re
port PDUs. An Error Report flag in the original PDU is set by
source network-entity to indicate that an Error Report PDU is to
returned if the Initial PDU or any PDUs derived from it are discard
ed; if the flag is not set, Error Reports are to be suppressed
Note
1. The suppression of Error Report PDUs is controlled by
ISO 8473 [Page 24]
RFC 994 December 1986
originating network-entity and not by the NS User.
should be exercised by the originator with regard
suppressing ER PDUs so that error reporting is not
for every PDU generated
2. Non-receipt of an Error Report PDU does not imply
delivery of a PDU issued by a source network-entity
6.10.2
An Error Report PDU shall not be generated to report the discard
an Error Report PDU
An Error Report PDU shall not be generated to report the discard of
Data PDU unless that PDU has the Error Report flag set to allow
Reports
If a Data PDU is discarded, and the Error Report flag has been set
allow Error Reports, an Error Report PDU shall be generated if
reason for discard is one of the reasons for discard enumerated
Clause 6.9, subject to the conditions described in Clause 6.10.4.
Note
If a Data PDU with the E/R flag set to allow Error Reports
discarded for any other reason, an ER PDU may be generated (
an implementation option).
6.10.3 Processing of Error
An Error Report PDU is composed from information contained in
header of the discarded Data PDU to which the Error Report refers
The contents of the Source Address field of the discarded Data
are used as the Destination Address of the Error Report PDU.
value, which in the context of the Data PDU was used as an NSAP Ad
dress, is used in the context of the Error Report PDU as
network-entity title of the network-entity that originated the
PDU. The network- entity title of the originator of the Error
PDU is conveyed in the Source Address field of the header of the Er
ror Report PDU. The value of the Lifetime field is determined in ac
cordance with Clause 6.4. Optional parameters are selected in accor
dance with Clause 6.10.4.
Segmentation of Error Report PDUs is not permitted; hence, no Segmen
tation Part is present. The total length of the ER PDU in octets
placed in the Segment Length field of the ER PDU header. This
is not changed during the lifetime of the ER PDU. If the
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
shall be truncated to the maximum service data unit size (see
5.5.3) and forwarded with no other change. Error Report PDUs
routed and forwarded by intermediate-system network-entities in
ISO 8473 [Page 25]
RFC 994 December 1986
same way as Data PDUs
Note
The requirement that the underlying service assumed by the
must be capable of supporting a service data unit size of at
512 octets guarantees that the entire header of the discarded
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
obtained as follows. The network-entity title recovered from the
in the Source Address field of the ER PDU header is used to
the network-entity which generated the Error Report. The reason
generating the Error Report is extracted from the Options Part of
PDU header. The entire header of the discarded Data PDU (and part
all of the original user data) is extracted from the data field
the ER PDU to assist in determining the nature of the error
6.10.4 Relationship of Data PDU Options to Error
The generation of an Error Report is affected by options that
present in the corresponding Data PDU. The presence of options in
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
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
are present in the corresponding Data PDU. In particular,
selected for the original Data PDU affect which options are
in the corresponding Error Report PDU. The selection of options
an Error Report PDU is governed by the following requirements
(a) If the Priority Option or the QoS Maintenance Option is
in the original Data PDU, and the system generating the
Report PDU supports the option, then the Error Report PDU
specify the option
(b) If the Security Option is selected in the Data PDU, and the
generating the Error Report supports this option, then the
Report PDU shall specify the option using the value that
specified in the original Data PDU. If the system does not
the Security Option, an Error Report must not be generated
a Data PDU that selects the Security Option
(c) If the Complete Source Route Option is selected in the
Data PDU, and the system generating the Error Report PDU
this option, then the error Report shall specify the Complete
Route option. The Source Route parameter value is obtained
extracting from the original Data PDU that portion of the
source route that has already been traversed, and reversing
ISO 8473 [Page 26]
RFC 994 December 1986
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
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
derived as a local matter, or they may be based upon
corresponding values in the original Data PDU
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
a checksum computed on the entire PDU header. The checksum is veri
fied at each point at which the PDU header is processed. If
checksum calculation fails, the PDU must be discarded. If PDU
fields are modified (for example, due to operation of the
function), then the checksum is modified so that the checksum
valid
The use of the Header Error Detection function is optional, and
selected by the originating network-entity. If the function is
used, the checksum 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 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) =
value of the octet at position i. The first octet in the PDU
is considered to occupy position i = 0.
When the function is in use, neither octet of the checksum field
be set to zero
Note
1. To ensure that inadvertent modification of a header while
PDU is being processed by an intermediate system (
example, due to a memory fault) may still be detected by
PDU Header Error function, an intermediate system network
ISO 8473 [Page 27]
RFC 994 December 1986
entity must not recompute the checksum for the entire header
even if fields are modified
2. Annex C contains descriptions of algorithms which may
used to calculate the correct value of the checksum
when the PDU is created, and to update the value of
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
of a PDU to begin on a convenient boundary for the
network-entity, such as a computer word boundary
6.13
The provision of protection services (e.g., data origin authentica
tion, data confidentiality, and data integrity of a
connectionless-mode NSDU) is performed by the Security Function
The Security Function is related to the Protection from
Access Quality of Service parameter described in ISO 8348/AD1, Adden
dum to the Network Service Definition Covering Connectionless-
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
are to be provided; it only provides for the encoding of security in
formation in the PDU header. To facilitate interoperation
end-systems and network relay-systems by avoiding different interpre
tations of the same encoding, a means to distinguish user-
security encodings from standardized security encodings is
in Clause 7.5.3.
Note
As an implementation consideration, data origin
may be provided through the use of a cryptographically
or enciphered checksum (unique from the PDU Header Error
mechanism); data confidentiality and data integrity may
provided via route control mechanisms
6.14 Source Routing
The Source Routing function allows the originator to specify the
a generated PDU must take. Source routing may only be selected by
ISO 8473 [Page 28]
RFC 994 December 1986
originator of a PDU. Source Routing is accomplished using a list
network-entity titles held in a parameter within the options part
the PDU header. The length of this parameter is determined by
originating network-entity, and does not change as the PDU
the network
The Source Route parameter includes information used by the originat
ing end-system when determining the initial route of the PDU.
the titles of intermediate system network-entities are included
the list; the network-entity title of the destination of the PDU
not included in the list
Associated with the list of network-entity titles is an
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
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
form, referred to as Complete Source Routing, requires that
specified path must be taken; that is, only those systems
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
specified path cannot be taken, the PDU must be discarded.
6.10 describes the circumstances in which an attempt shall be made
inform the originator of the discard using the Error Reporting func
tion
The second form is referred to as Partial Source Routing. Again,
system identified in the list must be visited in the order
while en route to the destination. However, with this form of
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
discarded (for source routing related reasons) unless one of the sys
tems specified cannot be reached by any available route
6.15 Record Route
The Record Route function records the path(s) taken by a PDU as
traverses a series of intermediate systems. A recorded route
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
PDU traverses the network
The list is constructed as the PDU is forwarded along a path
its destination. Only the titles of intermediate system network
entities are included in the recorded route. The network-entity
of the originator of the PDU is not recorded in the list
ISO 8473 [Page 29]
RFC 994 December 1986
When an intermediate system network-entity processes a PDU
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
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
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
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
final destination, without further addition of network-entity titles
If the addition of the entry would not exceed the size of the
Route parameter, the next available octet indicator is updated
the new value, and the network-entity title is added to the head
the list after the other entries have been moved
Two forms of the Record Route function are provided. The first
is referred to as Complete Route Recording. It requires that
list of network-entity titles be a complete and accurate record
all intermediate systems visited by a PDU (including Derived PDUs),
except when a shortage of space in the record route option
causes termination of recording of route, as described above.
Complete Route Recording is selected, PDU reassembly at
systems is performed only when the Derived PDUs that are
all took the same route; otherwise, the PDU is discarded, and
selected, an Error Report is generated (see Clause 6.10).
The second form is referred to as Partial Route Recording. It
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
placed in the PDU resulting from the reassembly
Note
The Record Route function is intended to be used in the
of subnetwork problems and/or to provide a return path that
be used as a source route in a subsequent PDU
6.16 Quality of Service Maintenance
The Quality of Service Maintenance function provides information
network-entities in intermediate systems which may be used to
routing decisions where such decisions affect the overall QoS provid
ed to NS users. This information is conveyed to intermediate
network- entities in a parameter in the options part of the
header
ISO 8473 [Page 30]
RFC 994 December 1986
In those instances where the QoS requested cannot be maintained, in
termediate system network-entities shall attempt to deliver the
at a QoS different from the QoS requested. Intermediate
network-entities do not necessarily provide a notification of
to meet the requested Quality of Service
6.17 Priority
The Priority function allows a PDU with a numerically higher
value to be processed preferentially with respect to other PDUs
numerically lower priority values. The function is realized
selection of a parameter in the options part of the PDU header
The lowest priority value is zero; a source network-entity that
not support the Priority function must set the Priority value
zero. The Priority function provides a means whereby the
of end and intermediate system network-entities, such as
transmission queues and buffers, can be used preferentially to pro
cess higher-priority PDUs ahead of lower-priority PDUs. The
action taken by an individual network-entity to support the
function is a local matter
6.18 Congestion Notification
To allow NS Users to take appropriate action when congestion is ex
perienced within the NS provider, intermediate systems may inform
destination network-entity of congestion through the use of a flag
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
of the PDU and may be set to one (1) by any intermediate system
processes the PDU to indicate that it is experiencing congestion.
criteria for determining when this action is to be taken are a
matter
Note
Congestion typically corresponds to inavailability of buffer
to maintain output queues. An appropriate policy for
congestion may be based upon the depth of the output queue
for a PDU (according to its destination address or other
information). When the depth of a particular output queue
a certain proportion of the depth of that queue, an
system will start to discard PDUs. The intermediate system will
the Congestion Experienced flag in the next PDU to be
and may continue to do so until the condition is alleviated
6.19 Classification of
Implementations are not required to support all of the
described in Clauses 6.1 through 6.18. Functions are divided
three categories
ISO 8473 [Page 31]
RFC 994 December 1986
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
function is selected in a PDU, then that PDU must be discarded
and an Error Report PDU must be generated and forwarded to
originating network-entity, providing that the Error Report flag
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
function is selected in a PDU, then the function is not performed
and the PDU is processed exactly as though the function had
been selected. The protocol data unit shall not be discarded
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
ISO 8473 [Page 32]
RFC 994 December 1986
Note
1. While the Error Reporting and Header Error Detection
must be provided, they are provided only when
by the sending Network Service user
2. The rationale for the inclusion of type 3 functions is that
the case of some functions it is more important to
the PDUs between intermediate systems or deliver them
an end-system than it is to support the functions. Type 3
functions should be used in those cases where they are of
advisory nature; they cannot cause a PDU to be
when they are not supported
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 submitted to the underlying service
The bits in an octet are numbered from one (1) to eight (8),
bit one (1) is the low-order (least significant) bit
When consecutive octets are used to represent a binary number,
lower octet number has the most significant value
Any implementation supporting this protocol is required to state
its specification the way in which octets are transferred, using
terms "most significant bit" and "least significant bit". The PDUs
this protocol are defined using the terms "most significant bit"
"least significant bit".
Note
When the encoding of a PDU is represented using a diagram in
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
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:
ISO 8473 [Page 33]
RFC 994 December 1986
7.2 Fixed
7.2.1
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
code
The fixed part has the following format
Part Described
___________________________________
| 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
________________________________________
| 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
7.2.2 Network Layer Protocol
The value of this field is set to binary 1000 0001 to identify
Network Layer protocol as ISO 8473, Protocol for Providing
Connectionless- mode Network Service. The value of this field is
ISO 8473 [Page 34]
RFC 994 December 1986
to binary 0000 0000 to identify the Inactive Network Layer
subset
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 Clause 7.1. The value 255 (1111 1111)
reserved for possible future extensions
Note
The rules for forwarding and segmentation guarantee 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
The size of a PDU header will not change due to operation of
protocol function
7.2.4 Version/Protocol Identifier
The value of this field is binary 0000 0001, which identifies
standard Version 1 of ISO 8473, Protocol for Providing
Connectionless-mode Network Service
7.2.5 PDU
The PDU Lifetime field is encoded as a binary number representing
remaining lifetime of the PDU, in units of 500 milliseconds
7.2.6
7.2.6.1 Segmentation
The Segmentation Permitted flag indicates whether segmentation
permitted. Its value is determined by the originator of the PDU
cannot be changed by any other network-entity for the lifetime of
Initial PDU and any Derived PDUs
A value of one (1) indicates that segmentation is permitted. A
of zero (0) indicates that the non-segmenting protocol subset is em
ployed. When the value of zero is selected, the segmentation part
the PDU header is not present, and the Segment Length field serves
the Total Length field (see Clause 7.2.8).
7.2.6.2 More
The More Segments flag indicates whether the data segment in this
contains (as its last octet) the last octet of the User Data in
NSDU. When the More Segments flag is set to one (1),
has taken place and the last octet of the NSDU is not contained
this PDU. The More Segments flag cannot be set to one (1) if the Seg
mentation Permitted flag is not set to one (1).
ISO 8473 [Page 35]
RFC 994 December 1986
When the More Segments flag is set to zero (0), the last octet of
Data Part of the PDU is the last octet of the NSDU
7.2.6.3 Error
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
is necessary to discard this Data PDU
When the Error Report flag is set to zero, discard of the Data
will not cause the generation of an Error Report PDU
7.2.7 Type
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
7.2.8 PDU Segment
The Segment Length field specifies the entire length, in octets,
the Derived PDU, including both header and data (if present).
the full protocol is employed and a PDU is not segmented, the
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
part is present in the header. In this subset, the Segment
field specifies the entire length of the Initial PDU, including
header and data (if present). The Segment Length field is not
for the lifetime of the PDU
7.2.9 PDU
The checksum is computed on the entire PDU header. For the Data PDU
this includes the segmentation and options parts (if present).
the Error Report PDU, this includes the reason for discard field
well
A checksum value of zero is reserved to indicate that the checksum
to be ignored. The operation of the PDU Header Error Detection func
tion (Clause 6.11) ensures that the value zero does not represent
ISO 8473 [Page 36]
RFC 994 December 1986
valid checksum. A non-zero value indicates that the checksum must
processed. If the checksum calculation fails, the PDU must be dis
carded
7.3 Address
7.3.1
Address parameters are distinguished by their location,
following the fixed part of the PDU header. The address part is il
lustrated Figure 4:
____________________________________________
| Destination Address Length Indicator | 10
|___________________________________________|
| | 11
: Destination Address :
| | m - 1
|___________________________________________|
| Source Address Length Indicator |
|___________________________________________|
| | m + 1
: Source Address :
| | n - 1
|___________________________________________|
Figure 4: PDU Header -- Address
7.3.1.1 Destination and Source
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
Clause 8.3.1 of ISO 8348/AD2.
The Destination Address Length Indicator field specifies the
of the Destination Address in octets. The Destination Address
follows the Destination Address Length Indicator field
The Source Address Length Indicator field specifies the length of
Source Address in octets. The Source Address Length Indicator
follows the Destination Address field. The Source Address field fol
lows the Source Address Length Indicator field
ISO 8473 [Page 37]
RFC 994 December 1986
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
7.4 Segmentation
If the Segmentation Permitted Flag in the Fixed Part of the
Header (Octet 4, Bit 8) is set to one, the segmentation part of
header, illustrated in Figure 6, must be present
If the Segmentation Permitted flag is set to zero, the non-
protocol subset is in use
________________________
| Data Unit Identifier | n, n + 1
|______________________|
| Segment Offset | n + 2, n + 3
|______________________|
| Total Length | n + 4, n + 5
|______________________|
Figure 6: PDU Header -- Segmentation
7.4.1 Data Unit
The Data Unit Identifier identifies an Initial PDU (and hence,
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
For each Derived PDU, the Segment Offset field specifies the
position of the segment contained in the data field of the
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
segment (and hence, the Initial PDU) is zero; an unsegmented (
PDU) has a segment offset value of zero (0). The value of this
shall be a multiple of eight 8).
ISO 8473 [Page 38]
RFC 994 December 1986
7.4.3 PDU Total
The Total Length field specifies the entire length of the
PDU, including both the header and data. This field is not
for the lifetime of the Initial PDU (and hence, its Derived PDUs).
7.5 Options
7.5.1
The options part is used to convey optional parameters. The
part of the PDU header is illustrated below
___________________________________________________
| | n + 6
: Options :
| |
|__________________________________________________|
Figure 7: PDU Header -- Options
If the options part is present, it may contain one or more parame
ters. The number of parameters that may be contained in the
part is constrained by the length of the options part, which
determined by the following formula
PDU Header Length -(length of fixed part+length of
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
Unit with an option duplicated should be treated as a protocol error
The rules governing the treatment of protocol errors are described
Clause 6.10, Error Reporting Function
The encoding of parameters contained within the options part of
PDU header is illustrated in Table 6:
___________________________________________
| n | Parameter Code |
|____________|____________________________|
| n + 1 | Parameter Length (e.g.m) |
|____________|____________________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|____________________________|
ISO 8473 [Page 39]
RFC 994 December 1986
Table 6: Encoding of
The parameter code field is coded in binary and, without extensions
provides a maximum of 255 different parameters. No parameter
use bits 8 and 7 with the value 00, so the actual maximum number
parameters is lower. A parameter code of 255 (binary 1111 1111)
reserved for possible future extensions
The parameter length field indicates the length, in octets, of
parameter value field. The length is indicated by a positive
number, m, with a theoretical maximum value of 254. The
maximum value of m is lower. For example, in the case of a
parameter contained within the options part, two octets are
for the parameter code and the parameter length indicators. Thus,
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.
parameter value field contains the value of the parameter
in the parameter code field
The following parameters are permitted in the options part
7.5.2
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:
Parameter Value: any value is
7.5.3
This parameter allows a unique and unambiguous security level to
assigned to a protocol data unit
Parameter Code: 1100 0101
Parameter Length:
Parameter Value: The high order two bits of the first
specify the Security Format Code, where
Security Type of Security Field
Format
ISO 8473 [Page 40]
RFC 994 December 1986
00
01 Source Address
10 Destination Address
11 Globally
The rest of the first octet is reserved and must be zero.
remainder of the Parameter Value field specifies the
level as described in the following Clauses
7.5.3.1 Source Address
The Security Format Code value of binary "01" indicates that
remaining octets of the parameter value field specify a security lev
el which is unique and unambiguous in the context of the
classification system employed by the authority responsible for as
signing the source NSAP Address
7.5.3.2 Destination Address
The Security Format Code value of binary "10" indicates that
remaining octets of the parameter value field specify a security lev
el which is unique and unambiguous in the context of the
classification system employed by the authority responsible for as
signing the destination NSAP Address
7.5.3.3 Globally Unique
The Security Format Code value of binary "11" indicates that
remaining octets of the parameter value field specify a
unique and unambiguous security level. This security
system is not specified in this Standard
7.5.4 Source
The source routing parameter specifies, either completely or partial
ly, the route to be taken from Source Network Address to
Network Address
Parameter Code: 1100 0101
Parameter Length:
Parameter Value: 2 octets of control information succeeded by
concatenation of ordered network-entity title entries (
from source to destination
The first octet of the parameter value is the type code, and has
following significance
0000 0000 partial source
0000 0001 complete source
reserved
ISO 8473 [Page 41]
RFC 994 December 1986
The second octet indicates the octet offset of the next network
entity title entry to be processed in the list. It is relative
the start of the parameter, such that a value of three (3)
that the next network-entity title entry begins immediately
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
comprises the re- mainder of the entry
7.5.5 Recording of
The recording of route parameter identifies the route of
systems traversed by the PDU
Parameter Code: 1100 1011
Parameter Length:
Parameter Value: 2 octets of control information succeeded by
con catenation of ordered network-entity title entries (
from destination to source
The first octet of the parameter value is the type code, and has
following significance
0000 0000 Partial Recording of Route in
0000 0001 Complete Recording of Route in
reserved
The second octet identifies the first octet not currently used for
recorded network-entity title, and therefore also the end of
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
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
comprising the remainder of the entry. Network-entity title
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
value
Note
The length of the Record Route parameter is determined by
originator of the PDU and is not changed during the lifetime
the PDU; hence, the operation of the Record Route function
ISO 8473 [Page 42]
RFC 994 December 1986
not affect the length of the header
7.5.6 Quality of Service
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
to) make use of this information as an aid in selecting a route
more than one route satisfying other routing criteria is
and the available routes are known to differ with respect to
of Service see Clause 6.16).
Parameter Code: 1100 0011
Parameter Length:
Parameter Value: The high order two bits of the first
specify the QoS Format Code, where
QoS Format Type of
Code
00
01 Source Address
10 Destination Address
11 Globally
The rest of the first octet is reserved and must be zero.
remainder of the Parameter Value field specifies the QoS as
in the following Clauses
7.5.6.1 Source Address
The QoS Format Code value of binary "01" indicates that the
octets of the parameter value field specify a QoS which is unique
unambiguous in the context of the QoS Maintenance system employed
the authority responsible for assigning the source NSAP Address
7.5.6.2 Destination Address
The QoS Format Code value of binary "10" indicates that the
octets of the parameter value field specify a QoS which is unique
unambiguous in the context of the QoS Maintenance system employed
the authority responsible for assigning the destination NSAP Address
7.5.6.3 Globally Unique
The QoS Format Code value of binary "11" indicates that the
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"
ISO 8473 [Page 43]
RFC 994 December 1986
Bit 6:
Bit 5: sequencing vs. transit
Bit 4: congestion
Bit 3: transit delay vs.
Bit 2: residual error probability vs. transit
Bit 1: residual error probability vs.
Bit 5 is set to one to indicate that, where possible, routing deci
sions should favor sending all PDUs to the specified destination
address over a single path (in order to maintain sequence)
minimizing transit delay. A value of zero (0) indicates that,
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,
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
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
delay
Bit 2 set to one to indicate that, where possible, routing
should favor low residual error probability over low transit delay
A value of zero indicates that routing decisions should favor
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.
value of 0 indicates that routing decisions should favor low
over low residual error probability
7.5.7
The value of the Priority parameter indicates the relative
of the protocol data unit. Intermediate systems that support
option shall make use of this information in routing and in
PDUs for transmission
Parameter Code: 1100 1101
Parameter Length: one
Parameter Value: 0000 0000 - Normal (Default)
0000 1110 -
reserved
ISO 8473 [Page 44]
RFC 994 December 1986
The values 0000 0001 through 0000 1110 are to be used for
priority protocol data units. If an intermediate system does not sup
port this option, all PDUs shall be treated as if the field had
value 0000 0000.
7.6 Data
The Data part of the PDU is structured as an ordered multiple of oc
tets, which is identical to the same ordered multiple of
specified for the NS-Userdata parameter of the N-UNITDATA Request
Indication primitives. The data field is illustrated in Figure 8:
___________________________________________________
| | p + 1
: Data :
| |
|__________________________________________________|
Figure 8: PDU Header -- Data
ISO 8473 [Page 45]
RFC 994 December 1986
7.7 Data (DT)
7.7.1
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 + 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 + 1
| Data |
| |
|________________________________________|
Figure 9: DT
ISO 8473 [Page 46]
RFC 994 December 1986
7.7.1.1 Fixed
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
See Clause 7.3.
7.7.1.3
See Clause 7.4.
7.7.1.4
See Clause 7.5.
7.7.1.5
See Clause 7.7.
7.8 Inactive Network Layer
____________________________________
|Network Layer Protocol Identifier | 1
|__________________________________|
| | 2
| Data |
| | 2 -
|__________________________________|
Figure 10: Inactive Network Layer
7.8.1 Network Layer Protocol
The value of the Network Layer Protocol Identifier field is
zero (0000 0000).
7.8.2 Data
The length of the NS-Userdata parameter is constrained to be
than or equal to the value of the length of the SN-Userdata
minus one (see Clause 7.7).
ISO 8473 [Page 47]
RFC 994 December 1986
7.9 Error Report PDU (ER
7.9.1
The ER PDU has the following format
______________________________________________
| 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 + 1
: Source Address :
| | n - 1
|____________________________________________|
| |
| Options |
| | p - 1
|____________________________________________|
| |
| Reason for Discard |
| | q - 1
|____________________________________________|
| |
| Error Report Data Field |
| |
|____________________________________________|
Figure 11: Error Report
ISO 8473 [Page 48]
RFC 994 December 1986
7.9.1.1 Fixed
The fixed part of the Error Report Protocol Data Unit is composed
the same way as a new (Initial) Data PDU. References are provided
previous Clauses describing the encoding of the fields comprising
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
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
intermediate-system or end-system network-entity initiating the
Report PDU
7.9.1.3
See Clause 7.5.
ISO 8473 [Page 49]
RFC 994 December 1986
7.9.1.4 Reason for
This parameter is valid only for the Error Report PDU
Parameter Code: 1100 0001
Parameter Length: two
Parameter Value: type of error encoded in binary. Values are
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
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
the second octet of the reason for discard parameter field. If
error cannot be localized to a particular field, or if the error is
checksum error, then the value zero is stored in the second octet
the reason for discard parameter field
ISO 8473 [Page 50]
RFC 994 December 1986
7.9.1.5 Error Report Data
This field contains the entire header of the discarded Data PDU,
may contain some or all of the data field of the discarded PDU
8
For conformance to this International Standard, the ability to ori
ginate, manipulate, and receive PDUs in accordance with the full pro
tocol (as opposed to the non-segmenting or Inactive Network
Protocol subsets) is required
Additionally, conformance to the Standard requires provision of
protocol functions described in Clause 6. Provision of the
functions described in Clause 6.18 and enumerated in Table 9-1
meet the requirements described therein. Exceptions to this require
ment are described in Clause 8.1 below
Additionally, conformance to the Standard requires adherence to
structure and encoding of PDUs of Clause 7.
If and only if the above requirements are met is there conformance
this International Standard
8.1 Provision of Functions for
The following table categorizes the functions in Clause 6
respect to the type of system providing the function
Note
1. The support of the PDU Composition and Forward PDU
is necessary for the generation of Error Report PDUs
2. The Segment PDU function is in general mandatory for
intermediate system. However, a system which is to
connected only to subnetworks all offering the same
SDU size (such as identical Local Area Networks) will
need to perform this function and therefore does not need
implement it
If this function is not implemented, this shall be
as part of the specification of the implementation
3. The correct treatment of the padding function requires
processing. A conforming implementation shall support
function, to the extent of ignoring this parameter
it may appear
4. This function may or may not be supported. If
implementation does not support this function, and
ISO 8473 [Page 51]
RFC 994 December 1986
function is selected in a PDU, then the PDU shall be discarded
and an ER PDU shall be generated and forwarded to
originating network-entity if the Error Report flag is
and the conditions of Clause 6.10.4 are satisfied
5. This function may or may not be supported. If an
does not support this function, and the function is
in a PDU, then the function is not performed and the PDU
processed exactly as though the function had not
selected. The PDU shall not be discarded for this reason
___________________________________________________________________
| Function | Send | Forward | Receive |
|____________________________|____________|___________|___________|
| PDU Composition | M | (Note 1) | (Note 1) |
| PDU Decomposition | M | - | M |
| Header Format Analysis | - | M | M |
| PDU Lifetime Control | | M | I |
| Route PDU | - | M | - |
| Forward PDU | M | M | (Note 1) |
| Segment PDU | M | (Note 2) | - |
| Reassemble PDU | - | I | M |
| Discard PDU | - | M | M |
| Error Reporting | M | M | M |
| Header Error Detection | (Note 3) | M | M |
| | | | |
| Security | - | (Note 3) | (Note 4) |
| Complete Source Routing | - | (Note 4) | - |
| Complete Route Recording | - | (Note 4) | - |
| Partial Source Routing | - | (Note 5) | - |
| Partial Route Recording | - | (Note 5) | - |
| Priority | - | (Note 5) | - |
| QoS Maintenance | - | (Note 5) | - |
| Congestion Notification | - | (Note 5) | - |
| Padding | - | (Note 5) | (Note 3) |
|____________________________|____________|___________|___________|
Table 8: Categorization of
Key
M: Mandatory Function; this function must be implemented
-: Not applicable
I: Implementation option, as described in the text
NOTE: See notes
ISO 8473 [Page 52]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
