Request for Comments: 994 ISO TC97/SC6/N 3998
March 1986
I S O
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE DE NORMALISATION
______________________________________________________________________
| |
| 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 Service
Source: DIS 8473 Editor
Contents
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
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
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 Tables
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 Figures
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
9 DT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10 Inactive Network Layer Protocol . . . . . . . . . . . . . . . . . 47
11 Error Report PDU . . . . . . . . . . . . . . . . . . . . . . . . . 48
0 Introduction
This Protocol Standard is one of a set of International Standards
produced to facilitate the interconnection of open systems. The set
of standards covers the services and protocols required to achieve
such interconnection.
This Protocol Standard is positioned with respect to other related
standards by the layers defined in the Reference Model for Open Sys-
tems Interconnection (ISO 7498). In particular, it is a protocol of
the Network Layer. This Protocol may be used between network-entities
in end systems or in Network Layer relay systems (or both). It pro-
vides the Connectionless-mode Network Service as defined in Addendum
1 to the Network Service Definition Covering Connectionless-mode
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 Standards
1 Scope and Field of Application
This International Standard specifies a protocol which is used to
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 an
underlying connectionless-mode service by real subnetworks and/or
data links. The underlying connectionless-mode service assumed by the
protocol may be obtained either directly, from a connectionless-mode
real subnetwork, or indirectly, through the operation of an appropri-
ate Subnetwork Dependent Convergence Function (SNDCF) or Protocol
(SNDCP) over a connection-mode real subnetwork as described in ISO
8648, Internal Organization of the Network Layer.
This Standard specifies:
a) procedures for the connectionless transmission of data and
control information from one network-entity to a peer
network-entity;
b) the encoding of the protocol data units (PDUs) used for the
transmission of data and control information, comprising a
variable-length protocol header format;
c) procedures for the correct interpretation of protocol control
information; and
d) the functional requirements for implementations claiming
conformance to the Standard.
The procedures are defined in terms of:
a) the interactions among peer network-entities through the
exchange of protocol data units;
b) the interactions between a network-entity and a Network Service
user through the exchange of Network Service primitives; and
c) the interactions between a network-entity and an underlying
service provider through the exchange of service primitives.
2 References
ISO 7498, Information Processing Systems --- Open Systems Intercon-
nection --- Basic Reference Model
DIS 7498/AD1, Information Processing Systems --- Open Systems In-
terconnection --- Addendum to ISO 7498 Covering Connectionless-mode
Transmission
ISO 8348, Information Processing Systems --- Telecommunications and
Information Exchange between Systems --- Network Service Definition
ISO 8348/AD1, Information Processing Systems --- Telecommunications
and Information Exchange between Systems --- Addendum to the Net-
work Service Definition Covering Connectionless-mode Transmission
ISO 8348/AD2, Information Processing Systems --- Telecommunications
and Information Exchange between Systems --- Addendum to the Net-
work Service Definition Covering Network Layer Addressing*
DIS 8648, Information Processing Systems --- Telecommunications and
Information Exchange between Systems --- Internal Organization of the
Network Layer
ISO 8509, Technical Report --- OSI Service Conventions
ISO 9074, A Formal Description Technique based on an Extended State
Transition Model
________________________________
*At present, at the stage of Draft; publication anticipated in
due course.
SECTION ONE. GENERAL
3 Definitions
3.1 Reference Model Definitions
This document makes use of the following concepts defined in ISO 7498:
(a) End system
(b) Network entity
(c) Network layer
(d) Network protocol
(e) Network protocol data unit
(f) Network relay
(g) Network service
(h) Network service access point
(i) Network service access point address
(j) Routing
(k) Service
(l) Service data unit
3.2 Service Conventions Definitions
This Protocol Standard makes use of the following terms from the OSI
Service Conventions Technical Report (ISO TR 8509):
(a) Service provider
(b) Service user
3.3 Network Layer Architecture Definitions
This Protocol Standard makes use of the following terms from the
Internal Organization of the Network Layer (ISO 8648):
(a) Intermediate system
(b) Relay system
(c) Subnetwork
3.4 Network Layer Addressing Definitions
This Protocol Standard makes use of the following terms from ISO 8348/AD2,
Addendum to the Network Service Definition Covering Network Layer
addressing:
(a) Network addressing domain
(b) Network protocol address information
(c) Subnetwork point of attachment
3.5 Additional Definitions
For the purposes of this Protocol Standard, the following definitions
apply:
(a) derived PDU --- a protocol data unit whose fields are identical
to those of an initial PDU, except that it carries only a segment
of the user data from an N-UNITDATA request.
(b) initial PDU --- a protocol data unit carrying the whole of the
userq data from an N-UNITDATA request.
(c) local matter --- a decision made by a system concerning its
behavior in the Network Layer that is not prescribed or
constrained by this Protocol Standard.
(d) network-entity title --- an identifier for a network-entity
which has the same abstract syntax as an NSAP address, and which
can be used to unambiguously identify a network-entity in an end
or intermediate system.
(e) reassembly --- the act of regenerating an initial PDU from two
or more derived PDUs.
(f) segment --- a distinct unit of data consisting of part or all
of the user data provided in the N-UNITDATA request and delivered
in the N-UNITDATA indication.
(g) segmentation --- the act of generating two or more derived PDUs
from an initial or derived PDU. The derived PDUs together carry
the entire user data of the initial or derived PDU from which they
were generated.
Note:
It is possible that such an initial PDU will never actually be
generated for a particular N-UNITDATA request, owing to the
immediate application of segmentation.
4 Symbols and Abbreviations
4.1 Data Units
NSDU Network Service Data Unit
PDU Protocol Data Unit
SNSDU Subnetwork Service Data Unit
4.2 Protocol Data Units
DT PDU Data Protocol Data Unit
ER PDU Error Report Protocol Data Unit
4.3 Protocol Data Unit Fields
CS Checksum
DA Destination Address
DAL Destination Address Length
DUID Data Unit Identifier
E/R Error Report Flag
LI Length Indicator
LT Lifetime
MS More Segments Flag
NLPID Network Layer Protocol Identifier
SA Source Address
SAL Source Address Length
SL Segment Length
SO Segment Offset
SP Segmentation Permitted Flag
TL Total Lengt
TP Type
V/P Version/Protocol Identifier Extension
4.4 Parameters
DA Destination Address
QOS Quality of Service
SA Source Address
4.5 Miscellaneous
CLNP Connectionless-mode Network Protocol
NS Network Service
NPAI Network Protocol Address Information
NSAP Network Service Access Point
SDU Service Data Uni
SN Subnetwork
SNDCF Subnetwork Dependent Convergence Function
SNDCP Subnetwork Dependent Convergence Protocol
SNICP Subnetwork Independent Convergence Protocol
SNPA Subnetwork Point of Attachment
5 Overview of the Protocol
5.1 Internal Organization of the Network Layer
The architectural organization of the Network Layer is described in a
separate document, Internal Organization of the Network Layer (ISO
8648). ISO 8648 identifies and categorizes the way in which functions
can be performed within the Network Layer by Network Layer protocols,
thus providing a uniform framework for describing how protocols
operating either individually or cooperatively in the Network Layer
can be used to provide the OSI Network Service. This protocol is
designed to be used in the context of the internetworking protocol
approach to the provision of the Connectionless-mode Network Service
defined in that Standard.
This protocol is intended for use in the Subnetwork Independent Con-
vergence Protocol (SNICP) role. A protocol which fulfills the SNICP
role operates to construct the OSI Network Service over a defined set
of underlying services, performing functions which are necessary to
support the uniform appearance of the OSI Connectionless-mode Network
Service over a homogeneous or heterogeneous set of interconnected
subnetworks. This protocol is defined to accommodate variability
where Subnetwork Dependent Convergence Protocols and/or Subnetwork
Access Protocols do not provide all of the functions necessary to
support the Connectionless-mode Network Service over all or part of
the path from one NSAP to another.
As described in ISO 8648, a protocol at the Network Layer may fulfill
different roles in different configurations. Although this protocol
is designed particularly to be suitable for a SNICP role in the con-
text of the internetworking protocol approach to the provision of the
Connectionless-mode Network Service, it may also be used to fulfill
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 the
underlying service which it assumes. This service is made available
by the operation of other Network Layer protocols or through provi-
sion of the Data Link Service. The underlying service assumed by this
protocol is described in Clause 5.5.
5.2 Subsets of the Protocol
Two proper subsets of the full protocol are defined which permit the
use of known subnetwork characteristics and are therefore not subnet-
work independent.
The Inactive Network Layer protocol subset is a null-function subset
which can be used when it is known that the source and destination
end-systems are connected by a single subnetwork, and when none of
the functions performed by the full protocol is required to provide
the Connectionless-mode Network Service between any pair of end-
systems.
The Non-segmenting protocol subset permits simplification of the
header where it is known that the source and destination end-systems
are connected by subnetworks whose service data unit sizes are
greater than or equal to a known bound which is large enough so that
segmentation is not required. This subset is selected by setting the
Segmentation Permitted flag to zero.
5.3 Addresses and Titles
The following Clauses describe the addresses and titles used by this
Protocol.
5.3.1 Addresses
The Source Address and Destination Address parameters referred to in
Clause 7.3 of this International Standard are OSI Network Service Ac-
cess Point Addresses. The syntax and semantics of an OSI Network
Service Access Point Address are described in a separate document,
ISO 8348/AD2, Addendum to the Network Service Definition Covering
Network Layer Addressing.
The encoding used by this protocol to convey NSAP Addresses shall be
the preferred binary encoding specified in ISO 8348/AD2; the entire
NSAP address, taken as a whole, is represented explicitly as a string
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 Titles
A network-entity title is an identifier for a network-entity in an
endsystem or intermediate-system. Network-entity titles are allocated
from the same name space as NSAP addresses, and the determination of
whether an address is an NSAP address or a network-entity title
depends on the context in which the address is interpreted. The en-
tries in the Source Routing and Recording of Route parameters defined
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 titles
shall also be the preferred binary encoding; again, the entire
network-entity title, taken as a whole, is represented explicitly as
a string of binary octets. This string is conveyed in its entirety
in the fields described in Clauses 7.5.4, 7.5.5, and 7.9.1.2.
5.4 Service Provided by the Network Layer
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 Service
The Addendum to the Network Service Definition Covering
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 Protocol
The underlying service required to support this protocol is defined
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 Service
Note:
These service primitives are used to describe the abstract interface
which exists between the ISO 8473 protocol machine and an underlying
real subnetwork or a Subnetwork Dependent Convergence Function which
operates over a real subnetwork or real data link to provide the
required underlying service.
5.5.1 Subnetwork Points of Attachment
The source and destination addresses specify the points of attachment
to a public or private subnetwork(s) involved in the transmission.
Subnetwork Point of Attachment addresses (SNPAs) are defined by each
individual subnetwork authority.
The syntax and semantics of SNPAs are not defined in this Standard.
5.5.2 Subnetwork Quality of Service
Subnetwork Quality of Service describes aspects of an underlying
connectionless-mode service which are attributable solely to the
underlying service.
Associated with each connectionless-mode transmission, certain meas-
ures of Quality of Service are requested when the primitive action is
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 of
service available is typically obtained prior to an invocation of the
underlying connectionless-mode service.
The Quality of Service parameters identified for the underlying
connectionless-mode service may in some circumstances be directly
derivable from or mappable onto those identified in the
Connectionless-mode Network Service. The following parameters as de-
fined in ISO 8348/AD1, Addendum to the Network Service Definition
Covering Connectionlessmode Transmission, may be employed:
(a) transit delay;
(b) protection against unauthorized access;
(c) cost determinants;
(d) priority; and
(e) residual error probability.
Note:
For those subnetworks which do not inherently provide Quality of
Service as a parameter when the primitive action is initiated, it
is a local matter as to how the semantics of the service requested
might be preserved. In particular, there may be instances in which
the Quality of Service requested cannot be maintained. In such
circumstances, an attempt shall be made to deliver the protocol
data unit at whatever Quality of Service is available.
5.5.3 Subnetwork User Data
The SN-Userdata is an ordered multiple of octets, and is transferred
transparently between the specified subnetwork points of attachment.
The underlying service assumed by the CLNP is required to support a
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 known
to be large enough that segmentation is not required, then the Non-
segmenting protocol subset may be used.
5.5.4 Subnetwork Dependent Convergence Functions
Subnetwork Dependent Convergence Functions may be performed to pro-
vide an underlying connectionless-mode service in the case where a
real subnetwork does not inherently provide the connectionless-mode
service assumed by the protocol. If a subnetwork inherently provides
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 those
cases where functions assumed from the underlying service are not
performed. In some cases, this may require the operation of an ex-
plicit protocol (i.e., a protocol involving explicit exchanges of
protocol control information between peer network-entities) in the
Subnetwork Dependent Convergence Protocol (SNDCP) role. However,
there may also be cases where the functionality required to fulfill
the SNDCP role consists simply of a set of rules for manipulating the
underlying service.
5.6 Service Assumed from Local Environment
A timer service must be provided to allow the protocol entity to
schedule events.
There are three primitives associated with the S-TIMER service:
1. the S--TIMER Request,
2. the S--TIMER Response, and
3. the S--TIMER Cancel.
The S--TIMER Request primitive indicates to the local environment
that it should initiate a timer of the specified name and subscript
and maintain it for the duration specified by the time parameter.
The S--TIMER Response primitive is initiated by the local environment
to indicate that the delay requested by the corresponding S-TIMER Re-
quest primitive has elapsed.
The S--TIMER Cancel primitive is an indication to the local environ-
ment that the specified timer(s) should be canceled. If the subscript
parameter is not specified, then all timers with the specified name
are canceled; otherwise, the timer of the given name and subscript is
cancelled. If no timers correspond to the parameters specified, the
local environment takes no action.
The parameters of the S--TIMER service primitives are specified in
Table 3.
__________________________________________________
| PRIMITIVES PARAMETERS |
|_________________________________________________|
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|___________________________|_____________________|
Table 3: Timer Primitives
The time parameter indicates the time duration of the specified ti-
mer. An identifiying label is associated with a timer by means of
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 for
the timers. Any derivations described in this Standard are not
mandatory. Timer values should be chosen so that the requested
Quality of Service can be provided, given the known characteristics
of the underlying service.
SECTION TWO. SPECIFICATION OF THE PROTOCOL
6 Protocol Functions
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 correct
behavior when requested functions are not implemented.
6.1 PDU Composition Function
This function is responsible for the construction of a protocol data
unit according to the rules governing the encoding of PDUs given in
Clause 7. Protocol Control Information required for delivering the
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 Address
and Destination Address fields of the PDU header is derived from the
NS-Source-Address and NS-Destination-Address parameters. The NS-
Destination-Address and NS-Quality-of-Service parameters, together
with current state and local information, are used to determine which
optional functions are to be selected. User data passed from the Net-
work Service User (NS-Userdata) forms the Data field of the protocol
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 as
a result of the application of the Segmentation Function (see Clause
6.7). Derived PDUs are considered to correspond to the same Initial
PDU, and hence the same N-UNITDATA Request, if they have the same
Source Address, Destination Address, and Data Unit Identifier.
The Data Unit Identifier is also available for ancillary functions
such as error reporting (see Clause 6.10).
The total length of the PDU in octets is determined by the originator
and placed in the Total Length field of the PDU header. This field is
not changed in any Derived PDU for the lifetime of the protocol data
unit.
When the Non-segmenting protocol subset is employed, neither the To-
tal Length field nor the Data Unit Identifier field is present. The
rules governing the PDU composition function are modified in this
case as follows. During the composition of the protocol data unit,
the total length of the PDU in octets is determined by the originator
and placed in the Segment Length field of the PDU header. This field
is not changed for the lifetime of the PDU. No Data Unit Identifica-
tion is provided.
6.2 PDU Decomposition Function
This function is responsible for removing the Protocol Control Infor-
mation from the protocol data unit. During this process, information
pertinent to the generation of the N-UNITDATA Indication is deter-
mined as follows. The NS-Source-Address and NS-Destination-Address
parameters of the N-UNITDATA Indication are recovered from the NPAI
in the Source and Destination Address fields of the PDU header. The
data field of the PDU received is reserved until all segments of the
original service data unit have been received; collectively, these
form the NS-Userdata parameter of the N-UNITDATA Indication. Infor-
mation relating to the Quality of Service provided during the
transmission of the PDU is determined from the Quality of Service and
other information contained in the Options Part of the PDU header.
This information constitutes the NS-Quality-of-Service parameter of
the N-UNITDATA Indication.
6.3 Header Format Analysis Function
This function determines whether the full protocol described in this
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 Destination
Address provided in the PDU identifies an NSAP served by this
network-entity, then the PDU has reached its destination; if not, it
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 of
Attachment address encoded as network protocol address information in
the supporting subnetwork protocol corresponds directly to an NSAP
address serviced by this network-entity or that an error has oc-
curred. If the subnetwork protocol data unit has been delivered
correctly, then the PDU may be decomposed according to the procedures
described for that particular subnetwork protocol.
6.4 PDU Lifetime Control Function
This function is used to enforce the maximum PDU lifetime. It is
closely associated with the Header Format Analysis function. This
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 the
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 the
Lifetime field of the Initial PDU is copied into all of the Derived
PDUs.
The Lifetime of the PDU is decremented by every network-entity which
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 PDU
was received; and
2. the delay within the system processing the PDU
exceeds or is estimated to exceed 500 milliseconds. In this case,
the lifetime field should be decremented by one for each additional
500 milliseconds of delay. The determination of delay need not be
precise, but where a precise value cannot be ascertained, the value
used shall be an overestimate, not an underestimate.
If the Lifetime field reaches a value of zero before the PDU is
delivered to the destination, the PDU must be discarded. The Error
Reporting function shall be invoked as described in Clause 6.10, Er-
ror Reporting Function, and may result in the generation of an Error
Report PDU. It is a local matter whether the destination network-
entity performs the Lifetime Control function.
6.5 Route PDU Function
This function determines the network-entity to which a protocol data
unit should be forwarded and the underlying service that must be used
to reach that network-entity, using the Destination Address and the
total length of the PDU. Where segmentation is required, the Route
PDU function further determines over which underlying service Derived
PDUs/segments must be sent in order to reach that network-entity. The
results of the Route PDU function are passed to the Forward PDU func-
tion (along with the PDU itself) for further processing. Selection
of the underlying service that must be used to reach the "next" sys-
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 provided
directly by the CLNP, through the selection of the Quality of Service
Maintenance parameter and other optional parameters, or through the
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 the
values of the Quality of Service Maintenance parameter (if present),
and other optional parameters (if present).
6.6 Forward PDU Function
This function issues an SN-UNITDATA Request primitive (see Clause
5.5), supplying the subnetwork or SNDCF identified by the Route PDU
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 addressing
domain (this may be an intermediate-system or the destination end-
system), and Quality of Service constraints (if any) to be considered
in the processing of the user data.
When the PDU to be forwarded is longer than the maximum service data
user size provided by the underlying service, the Segmentation func-
tion is applied (See Clause 6.7, which follows).
6.7 Segmentation Function
Segmentation is performed when the size of the protocol data unit is
greater than the maximum service data unit size supported by the
underlying service to be used to transmit the PDU.
Segmentation consists of composing two or more new PDUs (Derived
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 the
PDU to be segmented, with the exception of the segment length and
checksum fields of the fixed part, and the segment offset of the seg-
mentation part, is duplicated in each Derived PDU, including all of
the address part, the data unit identifier and total length of the
segmentation part, and the options part (if present).
Note:
The rules for forwarding and segmentation guarantee that the
header length is the same for all segments (Derived PDUs) of
the Initial PDU, and is the same as the header length of the
Initial PDU. The size of a PDU header will not change due to
operation of any protocol function.
The user data encapsulated within the PDU received are divided such
that the Derived PDUs satisfy the size requirements of the user data
parameter field of the primitive used to access the underlying ser-
vice.
Derived PDUs are identified as being from the same Initial PDU by
means of
(a) the source address,
(b) the destination address, and
(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 with
the Segmentation function:
(a) Segment Offset --- identifies, with respect to the start
of the Initial PDU, the octet at which the segment begins;
(b) Segment Length --- specifies the number of octets in the
Derived PDU, including both header and data;
(c) More Segments Flag --- is set to one if this Derived PDU
does not contain, as its final octet of user data, the final
octet of the Initial PDU; and
(d) Total Length --- specifies the entire length of the Initial
PDU, including both header and data.
Derived PDUs may be further segmented without constraining the rout-
ing of the individual Derived PDUs. The Segmentation Permitted flag
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 in
the network, the flag is set to zero by the source network-entity.
The setting of the Segmentation Permitted flag cannot be changed by
any other network-entity for the lifetime of the Initial PDU and any
Derived PDUs.
6.8 Reassembly Function
The Reassembly function reconstructs the Initial PDU from the Derived
PDUs generated by the operation of the Segmentation Function on the
Initial PDU (and, recursively, on subsequent Derived PDUs). A bound
on the time during which segments (Derived PDUs) of an Initial PDU
will be held at a reassembly point before being discarded is provid-
ed, so that reassembly resources may be released when it is no longer
expected that any outstanding segments of the Initial PDU will arrive
at the reassembly point. Upon reception of a Derived PDU, a reassem-
bly timer is initiated with a value which indicates the amount of
time which must elapse before any outstanding segments of the Initial
PDU shall be assumed to be lost. When this timer expires, all seg-
ments (Derived PDUs) of the Initial PDU held at the reassembly point
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 PDU
lifetime is a local matter, the Reassembly Function must preserve the
intent of the PDU lifetime. Consequently, the reassembly function
must discard PDUs whose lifetime would otherwise have expired had
they not been under the control of the reassembly function.
Note:
1. Methods of bounding reassembly lifetime are discussed in
Annex B.
2. The Segmentation and Reassembly functions are intended to
be used in such a way that the fewest possible segments are
generated at each segmentation point and reassembly takes
place at the final destination of a PDU. However, other
schemes which
(a) interact with the routing algorithm to favor paths on
which fewer segments are generated;
(b) generate more segments than absolutely required in
order to avoid additional segmentation at some subsequent
point; or
(c) allow partial or full reassembly at some intermediate
point along the route
are not precluded. The information necessary to enable the
use of one of these alternative strategies may be made
available through the operation of a Network Layer Management
function or by other means.
3. The originator of the Initial PDU determines the value of the
Segmentation Permitted flag in the Initial PDU and all Derived
PDUs (if any). Partial or full reassembly in an intermediate
system (Note 2 (c) above) cannot change this value in the
Initial PDU or any PDU derived from it, and cannot therefore
add or remove the segmentation part of the header.
6.9 Discard PDU Function
This function performs all of the actions necessary to free the
resources reserved by the network-entity when any of the following
situations is encountered (Note: the list is not exhaustive):
(a) A violation of protocol procedure has occurred.
(b) A PDU is received whose checksum is inconsistent with its
contents.
(c) A PDU is received, but due to local congestion, it cannot be
processed.
(d) A PDU is received whose header cannot be analyzed.
(e) A PDU is received which cannot be segmented and cannot be
forwarded because its length exceeds the maximum service data
unit size supported by any underlying service available for
transmission of the PDU to the next network-entity on the
chosen route.
(f) A PDU is received whose destination address is unreachable or
unknown.
(g) Incorrect or invalid source routing was specified. This may
include a syntax error in the source routing field, an unknown
or unreachable address in the source routing field, or a path
which is not acceptable for other reasons.
(h) A PDU is received whose PDU lifetime has expired or whose
lifetime expires during reassembly.
(i) A PDU is received which contains an unsupported option.
6.10 Error Reporting Function
6.10.1 Overview
This function causes an attempt to return an Error Report PDU to the
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 type
of error detected, and identifies the location in the header of the
discarded PDU at which the error was detected. At least the entire
header of the Discarded PDU (and, at the discretion of the originator
of the Error Report PDU none, all, or part of the data field) is
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 the
source network-entity to indicate that an Error Report PDU is to be
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 the
originating network-entity and not by the NS User. Care
should be exercised by the originator with regard to
suppressing ER PDUs so that error reporting is not suppressed
for every PDU generated.
2. Non-receipt of an Error Report PDU does not imply correct
delivery of a PDU issued by a source network-entity.
6.10.2 Requirements
An Error Report PDU shall not be generated to report the discard of
an Error Report PDU.
An Error Report PDU shall not be generated to report the discard of a
Data PDU unless that PDU has the Error Report flag set to allow Error
Reports.
If a Data PDU is discarded, and the Error Report flag has been set to
allow Error Reports, an Error Report PDU shall be generated if the
reason for discard is one of the reasons for discard enumerated in
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 is
discarded for any other reason, an ER PDU may be generated (as
an implementation option).
6.10.3 Processing of Error Reports
An Error Report PDU is composed from information contained in the
header of the discarded Data PDU to which the Error Report refers.
The contents of the Source Address field of the discarded Data PDU
are used as the Destination Address of the Error Report PDU. This
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 the
network-entity title of the network-entity that originated the Data
PDU. The network- entity title of the originator of the Error Report
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 is
placed in the Segment Length field of the ER PDU header. This field
is not changed during the lifetime of the ER PDU. If the originator