As per Relevance of the word segmentation, 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