summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc994.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc994.txt')
-rw-r--r--doc/rfc/rfc994.txt3069
1 files changed, 3069 insertions, 0 deletions
diff --git a/doc/rfc/rfc994.txt b/doc/rfc/rfc994.txt
new file mode 100644
index 0000000..abe8c9b
--- /dev/null
+++ b/doc/rfc/rfc994.txt
@@ -0,0 +1,3069 @@
+
+
+
+
+Network Working Group ANSI X3S3.3 86-80
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO 8473 [Page 1]
+
+RFC 994 December 1986
+
+
+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
+
+
+
+
+
+
+
+
+
+
+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 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
+
+
+
+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 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.
+
+
+
+
+
+
+ISO 8473 [Page 6]
+
+RFC 994 December 1986
+
+
+ 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 8473 [Page 7]
+
+RFC 994 December 1986
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO 8473 [Page 8]
+
+RFC 994 December 1986
+
+
+ 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
+
+
+
+ISO 8473 [Page 9]
+
+RFC 994 December 1986
+
+
+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.
+
+
+
+
+
+ISO 8473 [Page 10]
+
+RFC 994 December 1986
+
+
+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
+
+
+
+
+ISO 8473 [Page 11]
+
+RFC 994 December 1986
+
+
+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
+
+
+
+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 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.
+
+
+
+
+
+
+ISO 8473 [Page 13]
+
+RFC 994 December 1986
+
+
+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.
+
+
+
+
+
+
+
+ISO 8473 [Page 14]
+
+RFC 994 December 1986
+
+
+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.
+
+
+
+
+
+ISO 8473 [Page 15]
+
+RFC 994 December 1986
+
+
+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.
+
+
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO 8473 [Page 17]
+
+RFC 994 December 1986
+
+
+ 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.
+
+
+
+
+
+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. 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.
+
+
+
+
+
+
+ISO 8473 [Page 19]
+
+RFC 994 December 1986
+
+
+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-
+
+
+
+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 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-
+
+
+
+ISO 8473 [Page 21]
+
+RFC 994 December 1986
+
+
+ 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
+
+
+
+ISO 8473 [Page 22]
+
+RFC 994 December 1986
+
+
+ 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.
+
+
+
+ISO 8473 [Page 23]
+
+RFC 994 December 1986
+
+
+ (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
+
+
+
+ISO 8473 [Page 24]
+
+RFC 994 December 1986
+
+
+ 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
+ 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 PDU
+ shall be truncated to the maximum service data unit size (see Clause
+ 5.5.3) and forwarded with no other change. Error Report PDUs are
+ routed and forwarded by intermediate-system network-entities in the
+
+
+
+ISO 8473 [Page 25]
+
+RFC 994 December 1986
+
+
+ same way as Data PDUs.
+
+ Note:
+ The requirement that the underlying service assumed by the CLNP
+ must be capable of supporting a service data unit size of at least
+ 512 octets guarantees that the entire header of the discarded Data
+ 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 is
+ obtained as follows. The network-entity title recovered from the NPAI
+ in the Source Address field of the ER PDU header is used to identify
+ the network-entity which generated the Error Report. The reason for
+ generating the Error Report is extracted from the Options Part of the
+ PDU header. The entire header of the discarded Data PDU (and part or
+ all of the original user data) is extracted from the data field of
+ the ER PDU to assist in determining the nature of the error.
+
+6.10.4 Relationship of Data PDU Options to Error Reports
+
+ The generation of an Error Report is affected by options that are
+ present in the corresponding Data PDU. The presence of options in the
+ 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 if
+ 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 which
+ are present in the corresponding Data PDU. In particular, options
+ selected for the original Data PDU affect which options are included
+ in the corresponding Error Report PDU. The selection of options for
+ an Error Report PDU is governed by the following requirements:
+
+ (a) If the Priority Option or the QoS Maintenance Option is selected
+ in the original Data PDU, and the system generating the Error
+ Report PDU supports the option, then the Error Report PDU shall
+ specify the option.
+
+ (b) If the Security Option is selected in the Data PDU, and the system
+ generating the Error Report supports this option, then the Error
+ Report PDU shall specify the option using the value that was
+ specified in the original Data PDU. If the system does not support
+ the Security Option, an Error Report must not be generated for
+ a Data PDU that selects the Security Option.
+
+ (c) If the Complete Source Route Option is selected in the original
+ Data PDU, and the system generating the Error Report PDU supports
+ this option, then the error Report shall specify the Complete Source
+ Route option. The Source Route parameter value is obtained by
+ extracting from the original Data PDU that portion of the complete
+ source route that has already been traversed, and reversing the
+
+
+
+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 selects
+ 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 be
+ derived as a local matter, or they may be based upon the
+ corresponding values in the original Data PDU.
+
+6.11 PDU Header Error Detection
+
+ The PDU Header Error Detection function protects against failure of
+ intermediate or end-system network-entities due to the processing of
+ erroneous information in the PDU header. The function is realized by
+ a checksum computed on the entire PDU header. The checksum is veri-
+ fied at each point at which the PDU header is processed. If the
+ checksum calculation fails, the PDU must be discarded. If PDU header
+ fields are modified (for example, due to operation of the lifetime
+ function), then the checksum is modified so that the checksum remains
+ valid.
+
+ The use of the Header Error Detection function is optional, and is
+ selected by the originating network-entity. If the function is not
+ used, the checksum field of the PDU header is set to zero.
+
+ If the function is selected by the originating network-entity, the
+ 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) = the
+ value of the octet at position i. The first octet in the PDU header
+ is considered to occupy position i = 0.
+
+ When the function is in use, neither octet of the checksum field may
+ be set to zero.
+
+ Note:
+
+ 1. To ensure that inadvertent modification of a header while a
+ PDU is being processed by an intermediate system (for
+ example, due to a memory fault) may still be detected by the
+ 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 be
+ used to calculate the correct value of the checksum field
+ when the PDU is created, and to update the value of the
+ checksum field when the header is modified.
+
+6.12 Padding Function
+
+ The padding function is provided to allow space to be reserved in the
+ PDU header which is not used to support any other function. Octet
+ alignment must be maintained.
+
+ Note:
+ An example of the use of this function is to cause the data field
+ of a PDU to begin on a convenient boundary for the originating
+ network-entity, such as a computer word boundary.
+
+6.13 Security
+
+ The provision of protection services (e.g., data origin authentica-
+ tion, data confidentiality, and data integrity of a single
+ connectionless-mode NSDU) is performed by the Security Function.
+
+ The Security Function is related to the Protection from Unauthorized
+ Access Quality of Service parameter described in ISO 8348/AD1, Adden-
+ dum to the Network Service Definition Covering Connectionless-mode
+ 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 services
+ are to be provided; it only provides for the encoding of security in-
+ formation in the PDU header. To facilitate interoperation between
+ end-systems and network relay-systems by avoiding different interpre-
+ tations of the same encoding, a means to distinguish user-defined
+ security encodings from standardized security encodings is described
+ in Clause 7.5.3.
+
+
+ Note:
+ As an implementation consideration, data origin authentication
+ may be provided through the use of a cryptographically generated
+ or enciphered checksum (unique from the PDU Header Error Detection
+ mechanism); data confidentiality and data integrity may be
+ provided via route control mechanisms.
+
+6.14 Source Routing Function
+
+ The Source Routing function allows the originator to specify the path
+ a generated PDU must take. Source routing may only be selected by the
+
+
+
+ISO 8473 [Page 28]
+
+RFC 994 December 1986
+
+
+ originator of a PDU. Source Routing is accomplished using a list of
+ network-entity titles held in a parameter within the options part of
+ the PDU header. The length of this parameter is determined by the
+ originating network-entity, and does not change as the PDU traverses
+ the network.
+
+ The Source Route parameter includes information used by the originat-
+ ing end-system when determining the initial route of the PDU. Only
+ the titles of intermediate system network-entities are included in
+ the list; the network-entity title of the destination of the PDU is
+ not included in the list.
+
+ Associated with the list of network-entity titles is an indicator
+ 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 the
+ 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 first
+ form, referred to as Complete Source Routing, requires that the
+ specified path must be taken; that is, only those systems identified
+ 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 the
+ specified path cannot be taken, the PDU must be discarded. Clause
+ 6.10 describes the circumstances in which an attempt shall be made to
+ inform the originator of the discard using the Error Reporting func-
+ tion.
+
+ The second form is referred to as Partial Source Routing. Again, each
+ system identified in the list must be visited in the order specified
+ while en route to the destination. However, with this form of source
+ routing the PDU may take any path necessary to arrive at the next in-
+ termediate system in the list, which may include visiting intermedi-
+ ate systems that are not identified in the list. The PDU will not be
+ discarded (for source routing related reasons) unless one of the sys-
+ tems specified cannot be reached by any available route.
+
+6.15 Record Route Function
+
+ The Record Route function records the path(s) taken by a PDU as it
+ traverses a series of intermediate systems. A recorded route consists
+ of a list of network-entity titles held in a parameter within the op-
+ tions part of the PDU header. The length of this parameter is deter-
+ mined by the originating network-entity, and does not change as the
+ PDU traverses the network.
+
+ The list is constructed as the PDU is forwarded along a path towards
+ its destination. Only the titles of intermediate system network-
+ entities are included in the recorded route. The network-entity title
+ of the originator of the PDU is not recorded in the list.
+
+
+
+
+ISO 8473 [Page 29]
+
+RFC 994 December 1986
+
+
+ When an intermediate system network-entity processes a PDU containing
+ the Record Route parameter, the system adds its own networkentity ti-
+ tle at the end of the list of recorded network-entity titles. An in-
+ dicator is maintained to identify the next available octet to be used
+ for recording of route. This indicator is updated as entries are ad-
+ ded to the list as follows. The length of the entry to be added to
+ the list is added to the value of the next available octet indicator,
+ and this sum is compared with the length of the Record Route parame-
+ ter. If the addition of the entry to the list would exceed the size
+ of the parameter, the next available octet indicator is set to indi-
+ cate that route recording has been terminated. The network-entity ti-
+ tle is not added to the list. The PDU may still be forwarded to its
+ final destination, without further addition of network-entity titles.
+
+ If the addition of the entry would not exceed the size of the Record
+ Route parameter, the next available octet indicator is updated with
+ the new value, and the network-entity title is added to the head of
+ the list after the other entries have been moved.
+
+ Two forms of the Record Route function are provided. The first form
+ is referred to as Complete Route Recording. It requires that the
+ list of network-entity titles be a complete and accurate record of
+ all intermediate systems visited by a PDU (including Derived PDUs),
+ except when a shortage of space in the record route option field
+ causes termination of recording of route, as described above. When
+ Complete Route Recording is selected, PDU reassembly at intermediate
+ systems is performed only when the Derived PDUs that are reassembled
+ all took the same route; otherwise, the PDU is discarded, and if
+ selected, an Error Report is generated (see Clause 6.10).
+
+ The second form is referred to as Partial Route Recording. It also
+ requires a record of intermediate systems visited by a PDU. When Par-
+ tial Route Recording is selected, PDU reassembly at intermediate sys-
+ tems is always permitted. When reassembly is performed at an inter-
+ mediate system, the route recorded in any of the Derived PDUs may be
+ placed in the PDU resulting from the reassembly.
+
+ Note:
+ The Record Route function is intended to be used in the diagnosis
+ of subnetwork problems and/or to provide a return path that could
+ be used as a source route in a subsequent PDU.
+
+6.16 Quality of Service Maintenance Function
+
+ The Quality of Service Maintenance function provides information to
+ network-entities in intermediate systems which may be used to make
+ routing decisions where such decisions affect the overall QoS provid-
+ ed to NS users. This information is conveyed to intermediate system
+ network- entities in a parameter in the options part of the PDU
+ header.
+
+
+
+
+ISO 8473 [Page 30]
+
+RFC 994 December 1986
+
+
+ In those instances where the QoS requested cannot be maintained, in-
+ termediate system network-entities shall attempt to deliver the PDU
+ at a QoS different from the QoS requested. Intermediate system
+ network-entities do not necessarily provide a notification of failure
+ to meet the requested Quality of Service.
+
+
+6.17 Priority Function
+
+ The Priority function allows a PDU with a numerically higher priority
+ value to be processed preferentially with respect to other PDUs with
+ numerically lower priority values. The function is realized through
+ selection of a parameter in the options part of the PDU header.
+
+ The lowest priority value is zero; a source network-entity that does
+ not support the Priority function must set the Priority value to
+ zero. The Priority function provides a means whereby the resources
+ of end and intermediate system network-entities, such as outgoing
+ transmission queues and buffers, can be used preferentially to pro-
+ cess higher-priority PDUs ahead of lower-priority PDUs. The specific
+ action taken by an individual network-entity to support the Priority
+ function is a local matter.
+
+6.18 Congestion Notification Function
+
+ To allow NS Users to take appropriate action when congestion is ex-
+ perienced within the NS provider, intermediate systems may inform the
+ destination network-entity of congestion through the use of a flag in
+ the QoS Maintenance parameter in the options part of the PDU header.
+ The value of this flag is initially set to zero (0) by the originator
+ of the PDU and may be set to one (1) by any intermediate system which
+ processes the PDU to indicate that it is experiencing congestion. The
+ criteria for determining when this action is to be taken are a local
+ matter.
+
+ Note:
+ Congestion typically corresponds to inavailability of buffer space
+ to maintain output queues. An appropriate policy for indicating
+ congestion may be based upon the depth of the output queue selected
+ for a PDU (according to its destination address or other routing
+ information). When the depth of a particular output queue exceeds
+ a certain proportion of the depth of that queue, an intermediate
+ system will start to discard PDUs. The intermediate system will set
+ the Congestion Experienced flag in the next PDU to be forwarded
+ and may continue to do so until the condition is alleviated.
+
+6.19 Classification of Functions
+
+ Implementations are not required to support all of the functions
+ described in Clauses 6.1 through 6.18. Functions are divided into
+ three categories:
+
+
+
+ISO 8473 [Page 31]
+
+RFC 994 December 1986
+
+
+ Type 1: These functions must be supported.
+
+ Type 2: These functions may or may not be supported.
+ If an implementation does not support a Type 2 function, and the
+ function is selected in a PDU, then that PDU must be discarded,
+ and an Error Report PDU must be generated and forwarded to the
+ originating network-entity, providing that the Error Report flag is
+ set and the conditions of Clause 6.10.4 are satisfied.
+
+ Type 3: These functions may or may not be supported.
+ If an implementation does not support a Type 3 function, and the
+ function is selected in a PDU, then the function is not performed,
+ and the PDU is processed exactly as though the function had not
+ been selected. The protocol data unit shall not be discarded for
+ this reason.
+
+ Table 4 shows how the functions are divided into these three categories:
+
+ _____________________________________________________________________________
+| | FULL | NON | INACTIVE |
+| FUNCTION | PROTOCOL | SEGMENTING | SUBSET |
+| | | SUBSET | |
+|________________________________|_____________|_________________|____________|
+|PDU Composition | 1 | 1 | 1 |
+|PDU Composition | 1 | 1 | 1 |
+|Header Format Analysis | 1 | 1 | 1 |
+|PDU Lifetime Control | 1 | 1 | N/A |
+|Route PDU | 1 | 1 | N/A |
+|Forward PDU | 1 | 1 | N/A |
+|Segment PDU | 1 | N/A | N/A |
+|Reassemble PDU | 1 | N/A | N/A |
+|Discard PDU | 1 | 1 | N/A |
+|Error Reporting (Note 1) | 1 | 1 | N/A |
+|Header Error Detection (Note 1) | 1 | 1 | N/A |
+|Security | 1 | 2 | N/A |
+|Complete Source Routing | 1 | 2 | N/A |
+|Complete Route Recording | 2 | 2 | N/A |
+|Partial Source Routing | 3 | 3 | N/A |
+|Partial Route Recording | 3 | 3 | N/A |
+|Priority | 3 | 3 | N/A |
+|QoS Maintenance | 3 | 3 | N/A |
+|Congestion Notification | 3 | 3 | N/A |
+|Padding | 3 | 3 | N/A |
+|________________________________|_____________|_________________|____________|
+
+ Table 4: Categorization of Protocol Functions
+
+
+
+
+
+
+
+
+ISO 8473 [Page 32]
+
+RFC 994 December 1986
+
+
+ Note:
+
+ 1. While the Error Reporting and Header Error Detection functions
+ must be provided, they are provided only when selected
+ by the sending Network Service user.
+
+ 2. The rationale for the inclusion of type 3 functions is that in
+ the case of some functions it is more important to forward
+ the PDUs between intermediate systems or deliver them to
+ an end-system than it is to support the functions. Type 3
+ functions should be used in those cases where they are of an
+ advisory nature; they cannot cause a PDU to be discarded
+ when they are not supported.
+
+7 Structure and Encoding of PDUs
+
+7.1 Structure
+
+ All Protocol Data Units shall contain an integral number of octets.
+ The octets in a PDU are numbered starting from one (1) and increasing
+ in the order in which they are submitted to the underlying service.
+ The bits in an octet are numbered from one (1) to eight (8), where
+ bit one (1) is the low-order (least significant) bit.
+
+ When consecutive octets are used to represent a binary number, the
+ lower octet number has the most significant value.
+
+ Any implementation supporting this protocol is required to state in
+ its specification the way in which octets are transferred, using the
+ terms "most significant bit" and "least significant bit". The PDUs of
+ this protocol are defined using the terms "most significant bit" and
+ "least significant bit".
+
+ Note:
+ When the encoding of a PDU is represented using a diagram in this
+ Clause the following representation is used:
+
+ a) octets are shown with the lowest numbered octet to the left,
+ higher number octets being further to the right;
+ b) within an octet, bits are shown with bit eight (8) to the left
+ and bit one (1) to the right.
+
+ PDUs shall contain, in the following order:
+
+ 1. the fixed part;
+ 2. the address part;
+ 3. the segmentation part, if present;
+ 4. the Options part, if present;
+
+ and the data field, if present. This structure is illustrated in Figure 2:
+
+
+
+
+ISO 8473 [Page 33]
+
+RFC 994 December 1986
+
+
+7.2 Fixed Part
+
+7.2.1 General
+
+ The fixed part of the PDU header contains frequently occurring param-
+ eters including the type code (DT or ER) of the protocol data unit.
+ The length and the structure of the fixed part are defined by the PDU
+ code.
+
+ The fixed part has the following format:
+
+ Part Described in
+ ___________________________________
+ | Fixed Part | Section 7.2
+ |_________________________________|
+ | Address Part | Section 7.3
+ |_________________________________|
+ | Segmentation Part | Section 7.4
+ |_________________________________|
+ | Options Part | Section 7.5
+ |_________________________________|
+ | Data | Section 7.6
+ |_________________________________|
+
+ Figure 2: PDU Structure
+
+
+ Octet
+ ________________________________________
+ | Network Layer Protocol Identifier | 1
+ |______________________________________|
+ | Length Indicator | 2
+ |______________________________________|
+ | Version/Protocol Id Extension | 3
+ |______________________________________|
+ | Lifetime | 4
+ |______________________________________|
+ | SP vline M S vline e/R | Type | 5
+ |______________________________________|
+ | Segment Length | 6,7
+ |______________________________________|
+ | Checksum | 8,9
+ |______________________________________|
+
+ Figure 3: PDU Header -- Fixed Part
+
+7.2.2 Network Layer Protocol Identifier
+
+ The value of this field is set to binary 1000 0001 to identify this
+ Network Layer protocol as ISO 8473, Protocol for Providing the
+ Connectionless- mode Network Service. The value of this field is set
+
+
+
+ISO 8473 [Page 34]
+
+RFC 994 December 1986
+
+
+ to binary 0000 0000 to identify the Inactive Network Layer protocol
+ subset.
+
+7.2.3 Length Indicator
+
+ The length is indicated by a binary number, with a maximum value of
+ 254 (1111 1110). The length indicated is the length in octets of the
+ header, as described in Clause 7.1. The value 255 (1111 1111) is
+ reserved for possible future extensions.
+
+ 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.
+
+7.2.4 Version/Protocol Identifier Extension
+
+ The value of this field is binary 0000 0001, which identifies the
+ standard Version 1 of ISO 8473, Protocol for Providing the
+ Connectionless-mode Network Service.
+
+7.2.5 PDU Lifetime
+
+ The PDU Lifetime field is encoded as a binary number representing the
+ remaining lifetime of the PDU, in units of 500 milliseconds.
+
+7.2.6 Flags
+
+7.2.6.1 Segmentation Permitted
+
+ The Segmentation Permitted flag indicates whether segmentation is
+ permitted. Its value is determined by the originator of the PDU and
+ cannot be changed by any other network-entity for the lifetime of the
+ Initial PDU and any Derived PDUs.
+
+ A value of one (1) indicates that segmentation is permitted. A value
+ of zero (0) indicates that the non-segmenting protocol subset is em-
+ ployed. When the value of zero is selected, the segmentation part of
+ the PDU header is not present, and the Segment Length field serves as
+ the Total Length field (see Clause 7.2.8).
+
+7.2.6.2 More Segments
+
+ The More Segments flag indicates whether the data segment in this PDU
+ contains (as its last octet) the last octet of the User Data in the
+ NSDU. When the More Segments flag is set to one (1), segmentation
+ has taken place and the last octet of the NSDU is not contained in
+ this PDU. The More Segments flag cannot be set to one (1) if the Seg-
+ mentation Permitted flag is not set to one (1).
+
+
+
+ISO 8473 [Page 35]
+
+RFC 994 December 1986
+
+
+ When the More Segments flag is set to zero (0), the last octet of the
+ Data Part of the PDU is the last octet of the NSDU.
+
+7.2.6.3 Error Report
+
+ When the Error Report flag is set to one, the rules in Clause 6.10
+ are used to determine whether to generate an Error Report PDU if it
+ is necessary to discard this Data PDU.
+
+ When the Error Report flag is set to zero, discard of the Data PDU
+ will not cause the generation of an Error Report PDU.
+
+7.2.7 Type Code
+
+ The Type code field identifies the type of the protocol data unit.
+ Allowed values are given in Table 5:
+
+ __________________________________________________
+ | | Bits 5 4 3 2 1 |
+ |_________|______________________________________|
+ | DT PDU | 1 1 1 0 0 |
+ |_________|______________________________________|
+ | ER PDU | 0 0 0 0 1 |
+ |_________|______________________________________|
+
+ Table 5: Valid PDU Types
+
+7.2.8 PDU Segment Length
+
+ The Segment Length field specifies the entire length, in octets, of
+ the Derived PDU, including both header and data (if present). When
+ the full protocol is employed and a PDU is not segmented, the value
+ of this field is identical to the value of the Total Length field lo-
+ cated in the Segmentation Part of the header.
+
+ When the non-segmenting protocol subset is employed, no segmentation
+ part is present in the header. In this subset, the Segment Length
+ field specifies the entire length of the Initial PDU, including both
+ header and data (if present). The Segment Length field is not changed
+ for the lifetime of the PDU.
+
+7.2.9 PDU Checksum
+
+ The checksum is computed on the entire PDU header. For the Data PDU,
+ this includes the segmentation and options parts (if present). For
+ the Error Report PDU, this includes the reason for discard field as
+ well.
+
+ A checksum value of zero is reserved to indicate that the checksum is
+ to be ignored. The operation of the PDU Header Error Detection func-
+ tion (Clause 6.11) ensures that the value zero does not represent a
+
+
+
+ISO 8473 [Page 36]
+
+RFC 994 December 1986
+
+
+ valid checksum. A non-zero value indicates that the checksum must be
+ processed. If the checksum calculation fails, the PDU must be dis-
+ carded.
+
+7.3 Address Part
+
+7.3.1 General
+
+ Address parameters are distinguished by their location, immediately
+ following the fixed part of the PDU header. The address part is il-
+ lustrated Figure 4:
+
+
+ Octet
+ ____________________________________________
+ | Destination Address Length Indicator | 10
+ |___________________________________________|
+ | | 11
+ : Destination Address :
+ | | m - 1
+ |___________________________________________|
+ | Source Address Length Indicator | m
+ |___________________________________________|
+ | | m + 1
+ : Source Address :
+ | | n - 1
+ |___________________________________________|
+
+ Figure 4: PDU Header -- Address Part
+
+7.3.1.1 Destination and Source Addresses
+
+ The Destination and Source addresses used by this protocol are Net-
+ work Service Access Point addresses as defined in ISO 8348/AD2, Ad-
+ dendum to the Network Service Definition Covering Network Layer Ad-
+ dressing.
+
+ The Destination and Source Addresses are variable length. The Desti-
+ nation and Source Address fields are encoded as Network Protocol Ad-
+ dress Information using the Preferred Binary Encoding defined in
+ Clause 8.3.1 of ISO 8348/AD2.
+
+ The Destination Address Length Indicator field specifies the length
+ of the Destination Address in octets. The Destination Address field
+ follows the Destination Address Length Indicator field.
+
+ The Source Address Length Indicator field specifies the length of the
+ Source Address in octets. The Source Address Length Indicator field
+ follows the Destination Address field. The Source Address field fol-
+ lows the Source Address Length Indicator field.
+
+
+
+
+ISO 8473 [Page 37]
+
+RFC 994 December 1986
+
+
+ Each address parameter is encoded as illustrated in Table 5:
+
+ ______________________________________________
+ | Octet | Address parameter Length Indicator |
+ | n | (e.g., 'm') |
+ |________|____________________________________|
+ | Octets | |
+ | n + 1 | Address Parameter Value |
+ | thru | |
+ | n + m | |
+ |________|____________________________________|
+
+ Figure 5: Address Parameters
+
+7.4 Segmentation Part
+
+ If the Segmentation Permitted Flag in the Fixed Part of the PDU
+ Header (Octet 4, Bit 8) is set to one, the segmentation part of the
+ header, illustrated in Figure 6, must be present:
+
+ If the Segmentation Permitted flag is set to zero, the non-segmenting
+ protocol subset is in use.
+
+ Octet
+ ________________________
+ | Data Unit Identifier | n, n + 1
+ |______________________|
+ | Segment Offset | n + 2, n + 3
+ |______________________|
+ | Total Length | n + 4, n + 5
+ |______________________|
+
+ Figure 6: PDU Header -- Segmentation Part
+
+7.4.1 Data Unit Identifier
+
+ The Data Unit Identifier identifies an Initial PDU (and hence, its
+ Derived PDUs) so that a segmented data unit may be correctly reassem-
+ bled. The Data Unit Identifier size is two octets.
+
+7.4.2 Segment Offset
+
+ For each Derived PDU, the Segment Offset field specifies the relative
+ position of the segment contained in the data field of the Derived
+ PDU with respect to the start of the data field of the Initial PDU.
+ The offset is measured in units of octets. The offset of the first
+ segment (and hence, the Initial PDU) is zero; an unsegmented (Initial
+ PDU) has a segment offset value of zero (0). The value of this field
+ shall be a multiple of eight 8).
+
+
+
+
+
+ISO 8473 [Page 38]
+
+RFC 994 December 1986
+
+
+7.4.3 PDU Total Length
+
+ The Total Length field specifies the entire length of the Initial
+ PDU, including both the header and data. This field is not changed
+ for the lifetime of the Initial PDU (and hence, its Derived PDUs).
+
+7.5 Options Part
+
+7.5.1 General
+
+ The options part is used to convey optional parameters. The options
+ part of the PDU header is illustrated below:
+
+ Octet
+ ___________________________________________________
+ | | n + 6
+ : Options :
+ | | p
+ |__________________________________________________|
+
+ Figure 7: PDU Header -- Options Part
+
+ If the options part is present, it may contain one or more parame-
+ ters. The number of parameters that may be contained in the options
+ part is constrained by the length of the options part, which is
+ determined by the following formula:
+
+ PDU Header Length -(length of fixed part+length of address
+ part+length of segmentation part)
+
+ and by the length of the individual optional parameters.
+
+ Parameters defined in the options part may appear in any order. Du-
+ plication of options is not permitted. Receipt of a Protocol Data
+ Unit with an option duplicated should be treated as a protocol error.
+ The rules governing the treatment of protocol errors are described in
+ Clause 6.10, Error Reporting Function.
+
+ The encoding of parameters contained within the options part of the
+ PDU header is illustrated in Table 6:
+
+ Octets
+ ___________________________________________
+ | n | Parameter Code |
+ |____________|____________________________|
+ | n + 1 | Parameter Length (e.g.m) |
+ |____________|____________________________|
+ | n + 2 | |
+ | to | Parameter Value |
+ | n + m + 1 | |
+ |____________|____________________________|
+
+
+
+ISO 8473 [Page 39]
+
+RFC 994 December 1986
+
+
+ Table 6: Encoding of Parameters
+
+ The parameter code field is coded in binary and, without extensions,
+ provides a maximum of 255 different parameters. No parameter codes
+ use bits 8 and 7 with the value 00, so the actual maximum number of
+ parameters is lower. A parameter code of 255 (binary 1111 1111) is
+ reserved for possible future extensions.
+
+ The parameter length field indicates the length, in octets, of the
+ parameter value field. The length is indicated by a positive binary
+ number, m, with a theoretical maximum value of 254. The practical
+ maximum value of m is lower. For example, in the case of a single
+ parameter contained within the options part, two octets are required
+ for the parameter code and the parameter length indicators. Thus, the
+ value of m is limited to:
+
+ m = 252-(length of fixed part +length of address part +length of seg-
+ mentation part)
+
+ For each succeeding parameter the maximum value of m decreases. The
+ parameter value field contains the value of the parameter identified
+ in the parameter code field.
+
+ The following parameters are permitted in the options part.
+
+7.5.2 Padding
+
+ The padding parameter is used to lengthen the PDU header to a con-
+ venient size (See Clause 6.12).
+
+ Parameter Code: 1100 1100
+
+ Parameter Length: variable
+
+ Parameter Value: any value is allowed
+
+7.5.3 Security
+
+ This parameter allows a unique and unambiguous security level to be
+ assigned to a protocol data unit.
+
+ Parameter Code: 1100 0101
+
+ Parameter Length: variable
+
+ Parameter Value: The high order two bits of the first octet
+ specify the Security Format Code, where:
+
+ Security Type of Security Field:
+ Format Code
+
+
+
+
+ISO 8473 [Page 40]
+
+RFC 994 December 1986
+
+
+ 00 Reserved
+ 01 Source Address Specific
+ 10 Destination Address Specific
+ 11 Globally Unique
+
+ The rest of the first octet is reserved and must be zero. The
+ remainder of the Parameter Value field specifies the security
+ level as described in the following Clauses.
+7.5.3.1 Source Address Specific
+
+ The Security Format Code value of binary "01" indicates that the
+ remaining octets of the parameter value field specify a security lev-
+ el which is unique and unambiguous in the context of the security
+ classification system employed by the authority responsible for as-
+ signing the source NSAP Address.
+
+7.5.3.2 Destination Address Specific
+
+ The Security Format Code value of binary "10" indicates that the
+ remaining octets of the parameter value field specify a security lev-
+ el which is unique and unambiguous in the context of the security
+ classification system employed by the authority responsible for as-
+ signing the destination NSAP Address.
+
+7.5.3.3 Globally Unique Security
+
+ The Security Format Code value of binary "11" indicates that the
+ remaining octets of the parameter value field specify a globally
+ unique and unambiguous security level. This security classification
+ system is not specified in this Standard.
+
+7.5.4 Source Routing
+
+ The source routing parameter specifies, either completely or partial-
+ ly, the route to be taken from Source Network Address to Destination
+ Network Address.
+
+ Parameter Code: 1100 0101
+
+ Parameter Length: variable
+
+ Parameter Value: 2 octets of control information succeeded by a
+ concatenation of ordered network-entity title entries (ordered
+ from source to destination)
+
+ The first octet of the parameter value is the type code, and has the
+ following significance:
+
+ 0000 0000 partial source routing
+ 0000 0001 complete source routing
+ <all other values reserved>
+
+
+
+ISO 8473 [Page 41]
+
+RFC 994 December 1986
+
+
+ The second octet indicates the octet offset of the next network-
+ entity title entry to be processed in the list. It is relative to
+ the start of the parameter, such that a value of three (3) indicates
+ that the next network-entity title entry begins immediately after
+ this control octet. Successive octets are indicated by corresponding-
+ ly larger values of this indicator.
+
+ The third octet begins the network-entity title list. The list con-
+ sists of variable length network-entity title entries. The first oc-
+ tet of entry identifies the length of the network-entity title which
+ comprises the re- mainder of the entry.
+
+7.5.5 Recording of Route
+
+ The recording of route parameter identifies the route of intermediate
+ systems traversed by the PDU.
+
+ Parameter Code: 1100 1011
+
+ Parameter Length: variable
+
+ Parameter Value: 2 octets of control information succeeded by a
+ con catenation of ordered network-entity title entries (ordered
+ from destination to source)
+
+ The first octet of the parameter value is the type code, and has the
+ following significance:
+
+ 0000 0000 Partial Recording of Route in progress
+ 0000 0001 Complete Recording of Route in progress
+ <all other values reserved>
+
+ The second octet identifies the first octet not currently used for a
+ recorded network-entity title, and therefore also the end of the
+ list. It is encoded relative to the start of the parameter value,
+ such that a value of three (3) indicates that no network-entity ti-
+ tles have yet been recorded. A value of all ones is used to indicate
+ that route recording has been terminated.
+
+ The third octet begins the network-entity title list. The list con-
+ sists of variable length network-entity title entries. The first oc-
+ tet of each entry specifies the length of the network-entity title
+ comprising the remainder of the entry. Network-entity title entries
+ are always added to the beginning of the list; that is, the most re-
+ cently added entry will begin in the third octet of the parameter
+ value.
+
+ Note:
+ The length of the Record Route parameter is determined by the
+ originator of the PDU and is not changed during the lifetime of
+ the PDU; hence, the operation of the Record Route function does
+
+
+
+ISO 8473 [Page 42]
+
+RFC 994 December 1986
+
+
+ not affect the length of the header.
+
+7.5.6 Quality of Service Maintenance
+
+ The Quality of Service parameter conveys information about the quali-
+ ty of service requested by the originating Network Service user.
+ Network-entities in intermediate systems may (but are not required
+ to) make use of this information as an aid in selecting a route when
+ more than one route satisfying other routing criteria is available
+ and the available routes are known to differ with respect to Quality
+ of Service see Clause 6.16).
+
+ Parameter Code: 1100 0011
+ Parameter Length: variable
+ Parameter Value: The high order two bits of the first octet
+ specify the QoS Format Code, where:
+
+ QoS Format Type of QoS
+ Code Field
+ 00 Reserved
+ 01 Source Address Specific
+ 10 Destination Address Specific
+ 11 Globally Unique
+
+ The rest of the first octet is reserved and must be zero. The
+ remainder of the Parameter Value field specifies the QoS as described
+ in the following Clauses.
+
+7.5.6.1 Source Address Specific
+
+ The QoS Format Code value of binary "01" indicates that the remaining
+ octets of the parameter value field specify a QoS which is unique and
+ unambiguous in the context of the QoS Maintenance system employed by
+ the authority responsible for assigning the source NSAP Address.
+
+7.5.6.2 Destination Address Specific
+
+ The QoS Format Code value of binary "10" indicates that the remaining
+ octets of the parameter value field specify a QoS which is unique and
+ unambiguous in the context of the QoS Maintenance system employed by
+ the authority responsible for assigning the destination NSAP Address.
+
+7.5.6.3 Globally Unique QoS
+
+ The QoS Format Code value of binary "11" indicates that the remainder
+ of the parameter value field specifies a globally unique QoS Mainte-
+ nance field. When the globally unique QoS Maintenance function is em-
+ ployed, the parameter value field must have a total length of one oc-
+ tet, which is assigned the following values:
+
+ Bits 8 and 7: QoS Format Code of binary "11"
+
+
+
+ISO 8473 [Page 43]
+
+RFC 994 December 1986
+
+
+ Bit 6: Reserved
+ Bit 5: sequencing vs. transit delay
+ Bit 4: congestion experienced
+ Bit 3: transit delay vs. cost
+ Bit 2: residual error probability vs. transit delay
+ Bit 1: residual error probability vs. cost
+
+ Bit 5 is set to one to indicate that, where possible, routing deci-
+ sions should favor sending all PDUs to the specified destination NSAP
+ address over a single path (in order to maintain sequence) over
+ minimizing transit delay. A value of zero (0) indicates that, where
+ possible, routing decisions should favor low transit delay over se-
+ quence preservation.
+
+ Bit 4 is set to zero by the network-entity which originates the pro-
+ tocol data unit. It is set to one by an intermiediate system to indi-
+ cate that this PDU has visited a congested intermediate system, and
+ appropriate action should be taken by the destination network-entity.
+ Once the congestion experienced bit is set by an intermediate system,
+ it may not be reset by any intermediate system traversed by the PDU
+ further along the path towards the destination.
+
+ Bit 3 is set to one to indicate that, where possible, routing deci-
+ sions should favor low transit delay over low cost. A value of 0 in-
+ dicates that routing decisions should favor low cost over low transit
+ delay.
+
+ Bit 2 set to one to indicate that, where possible, routing decisions
+ should favor low residual error probability over low transit delay.
+ A value of zero indicates that routing decisions should favor low
+ transit delay over low residual error probability.
+
+ Bit 1 is set to one to indicate that, where possible, routing deci-
+ sions should favor low residual error probability over low cost. A
+ value of 0 indicates that routing decisions should favor low cost
+ over low residual error probability.
+
+7.5.7 Priority
+
+ The value of the Priority parameter indicates the relative priority
+ of the protocol data unit. Intermediate systems that support this
+ option shall make use of this information in routing and in ordering
+ PDUs for transmission.
+
+ Parameter Code: 1100 1101
+
+ Parameter Length: one octet
+
+ Parameter Value: 0000 0000 - Normal (Default) through
+ 0000 1110 - Highest
+ <all other values reserved>
+
+
+
+ISO 8473 [Page 44]
+
+RFC 994 December 1986
+
+
+ The values 0000 0001 through 0000 1110 are to be used for higher
+ priority protocol data units. If an intermediate system does not sup-
+ port this option, all PDUs shall be treated as if the field had the
+ value 0000 0000.
+
+7.6 Data Part
+
+ The Data part of the PDU is structured as an ordered multiple of oc-
+ tets, which is identical to the same ordered multiple of octets
+ specified for the NS-Userdata parameter of the N-UNITDATA Request and
+ Indication primitives. The data field is illustrated in Figure 8:
+
+
+ Octet
+ ___________________________________________________
+ | | p + 1
+ : Data :
+ | | z
+ |__________________________________________________|
+
+ Figure 8: PDU Header -- Data Field
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO 8473 [Page 45]
+
+RFC 994 December 1986
+
+
+7.7 Data (DT) PDU
+
+7.7.1 Structure
+
+ The DT PDU has the following format:
+
+ __________________________________________
+ | Network Layer Protocol Identifier | 1
+ |________________________________________|
+ | Length Indicator | 2
+ |________________________________________|
+ | Version/Protocol Id Extension | 3
+ |________________________________________|
+ | Lifetime | 4
+ |________________________________________|
+ | S P vline M S vline e/R | Type | 5
+ |____________________________|___________|
+ | Segment Length | 6,7
+ |________________________________________|
+ | Checksum | 8,9
+ |________________________________________|
+ | Destination Address Length Indicator | 10
+ |________________________________________|
+ | | 11
+ : Destination Address :
+ |________________________________________| m - 1
+ | Source Address Length Indicator | m
+ |________________________________________|
+ | | m + 1
+ : Source Address :
+ | | n - 1
+ |________________________________________|
+ | Data Unit Identifier | n, n + 1
+ |________________________________________|
+ | Segment Offset | n + 2, n + 3
+ |________________________________________|
+ | Total Length | n + 4, n + 5
+ |________________________________________|
+ | | n + 6
+ | Options |
+ | | p
+ |________________________________________|
+ | | p + 1
+ | Data |
+ | | z
+ |________________________________________|
+
+ Figure 9: DT PDU
+
+
+
+
+
+
+ISO 8473 [Page 46]
+
+RFC 994 December 1986
+
+
+7.7.1.1 Fixed Part
+
+ 1) Network Layer Protocol Identifier See Clause 7.2.2
+ 2) Length Indicator See Clause 7.2.3
+ 3) Version/Protocol Id Extension See Clause 7.2.4
+ 4) Lifetime See Clause 7.2.5
+ 5) SP, MS, E/R See Clause 7.2.6
+ 6) Type Code See Clause 7.2.7
+ 7) Segment Length See Clause 7.2.8
+ 8) Checksum See Clause 7.2.9
+
+7.7.1.2 Addresses
+
+ See Clause 7.3.
+
+7.7.1.3 Segmentation
+
+ See Clause 7.4.
+
+7.7.1.4 Options
+
+ See Clause 7.5.
+
+7.7.1.5 Data
+
+ See Clause 7.7.
+
+7.8 Inactive Network Layer Protocol
+
+ Octet
+ ____________________________________
+ |Network Layer Protocol Identifier | 1
+ |__________________________________|
+ | | 2
+ | Data |
+ | | 2 - n
+ |__________________________________|
+
+ Figure 10: Inactive Network Layer Protocol
+
+
+7.8.1 Network Layer Protocol Id
+
+ The value of the Network Layer Protocol Identifier field is binary
+ zero (0000 0000).
+
+7.8.2 Data Field
+
+ The length of the NS-Userdata parameter is constrained to be less
+ than or equal to the value of the length of the SN-Userdata parameter
+ minus one (see Clause 7.7).
+
+
+
+ISO 8473 [Page 47]
+
+RFC 994 December 1986
+
+
+7.9 Error Report PDU (ER)
+
+7.9.1 Structure
+
+ The ER PDU has the following format:
+
+ Octet
+ ______________________________________________
+ | Network Layer Protocol Identifier | 1
+ |____________________________________________|
+ | Length Indicator | 2
+ |____________________________________________|
+ | Version/Protocol Id Extension | 3
+ |____________________________________________|
+ | Lifetime | 4
+ |____________________________________________|
+ | SP= 0 vline MS= 0 vline Reserved | Type | 5
+ |_____________________________________|______|
+ | Segment Length | 6,7
+ |____________________________________________|
+ | Checksum | 8,9
+ |____________________________________________|
+ | Destination Address Length Indicator | 10
+ |____________________________________________|
+ | | 11
+ : Destination Address :
+ | | m - 1
+ |____________________________________________|
+ | Source Address Length Indicator | m
+ |____________________________________________|
+ | | m + 1
+ : Source Address :
+ | | n - 1
+ |____________________________________________|
+ | | n
+ | Options |
+ | | p - 1
+ |____________________________________________|
+ | | p
+ | Reason for Discard |
+ | | q - 1
+ |____________________________________________|
+ | | q
+ | Error Report Data Field |
+ | | z
+ |____________________________________________|
+
+ Figure 11: Error Report PDU
+
+
+
+
+
+
+ISO 8473 [Page 48]
+
+RFC 994 December 1986
+
+
+7.9.1.1 Fixed Part
+
+ The fixed part of the Error Report Protocol Data Unit is composed in
+ the same way as a new (Initial) Data PDU. References are provided to
+ previous Clauses describing the encoding of the fields comprising the
+ fixed part:
+
+ 1) Network Layer Protocol Identifier See Clause 7.2.2
+ 2) Length Indicator See Clause 7.2.3
+ 3) Version/Protocol Id Extension See Clause 7.2.4
+ 4) Lifetime See Clause 7.2.5
+ 5) SP, MS, E/R Always set to zero,
+ (See Clause 6.10)
+ 6) Type Code See Clause 7.2.7
+ 7) Segment Length See Clause 7.2.8
+ 8) Checksum See Clause 7.2.9
+
+
+7.9.1.2 Addresses
+
+ See Clause 7.3.
+
+ The Destination Address specifies the network-entity title of the origi-
+ nator of the discarded PDU. The Source Address specifies the title of the
+ intermediate-system or end-system network-entity initiating the Error
+ Report PDU.
+
+7.9.1.3 Options
+
+ See Clause 7.5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO 8473 [Page 49]
+
+RFC 994 December 1986
+
+
+7.9.1.4 Reason for Discard
+
+ This parameter is valid only for the Error Report PDU.
+
+
+ Parameter Code: 1100 0001
+ Parameter Length: two octets
+ Parameter Value: type of error encoded in binary. Values are listed
+ in Table 7:
+_______________________________________________________________________________
+| Parameter Value | Class of | Meaning |
+| Octet 1 Octet 2| Error | |
+|__________________|_____________|_____________________________________________|
+| 0000 0000 | | Reason not specified |
+| 0001 | | Protocol Procedure Error |
+| 0010 | | Incorrect Checksum |
+| 0011 | General | PDU Discarded due to Congestion |
+| 0100 | | Header Syntax Error (cannot be parsed) |
+| 0101 | | Segmentation needed but not permitted |
+| 0110 | | Incomplete PDU Received |
+| 0111 | | Duplicate Option |
+|__________________|_____________|_____________________________________________|
+| 1000 0000 | Address | Destination Address Unreachable |
+| 0001 | | Destination Address Unknown |
+|__________________|_____________|_____________________________________________|
+| 1001 0000 | | Unspecified Source Routing Error |
+| 0001 | Source | Syntax Error in Source Routing Field |
+| 0010 | Routing | Unknown Address in Source Routing Field |
+| 0011 | | Path not Acceptable |
+|__________________|_____________|_____________________________________________|
+| 1010 0000 | Lifetime | Lifetime Expired while Data Unit in Transit |
+| 0001 | | Lifetime Expired during Reassembly |
+|__________________|_____________|_____________________________________________|
+| 1011 0000 | | Unsupported Option not Specified |
+| 0001 | PDU | Unsupported Protocol Version |
+| 0010 | Discarded | Unsupported Security Option |
+| 0011 | | Unsupported Source Routing Option |
+| 0100 | | Unsupported Recording of Route Option |
+|__________________|_____________|_____________________________________________|
+| 1100 0000 | Reassembly | Reassembly interference |
+|__________________|_____________|_____________________________________________|
+
+ Table 7: Reasons for Discard
+
+ The first octet of the parameter value contains an error type code.
+ If the error in the discarded Data PDU can be localized to a particu-
+ lar field, the number of the first octet of that field is stored in
+ the second octet of the reason for discard parameter field. If the
+ error cannot be localized to a particular field, or if the error is a
+ checksum error, then the value zero is stored in the second octet of
+ the reason for discard parameter field.
+
+
+
+ISO 8473 [Page 50]
+
+RFC 994 December 1986
+
+
+7.9.1.5 Error Report Data Field
+
+ This field contains the entire header of the discarded Data PDU, and
+ may contain some or all of the data field of the discarded PDU.
+
+8 Conformance
+
+ For conformance to this International Standard, the ability to ori-
+ ginate, manipulate, and receive PDUs in accordance with the full pro-
+ tocol (as opposed to the non-segmenting or Inactive Network Layer
+ Protocol subsets) is required.
+
+ Additionally, conformance to the Standard requires provision of the
+ protocol functions described in Clause 6. Provision of the optional
+ functions described in Clause 6.18 and enumerated in Table 9-1 must
+ meet the requirements described therein. Exceptions to this require-
+ ment are described in Clause 8.1 below.
+
+ Additionally, conformance to the Standard requires adherence to the
+ structure and encoding of PDUs of Clause 7.
+
+ If and only if the above requirements are met is there conformance to
+ this International Standard.
+
+8.1 Provision of Functions for Conformance
+
+ The following table categorizes the functions in Clause 6 with
+ respect to the type of system providing the function:
+
+ Note:
+
+ 1. The support of the PDU Composition and Forward PDU functions
+ is necessary for the generation of Error Report PDUs.
+
+ 2. The Segment PDU function is in general mandatory for an
+ intermediate system. However, a system which is to be
+ connected only to subnetworks all offering the same maximum
+ SDU size (such as identical Local Area Networks) will not
+ need to perform this function and therefore does not need to
+ implement it.
+
+ If this function is not implemented, this shall be stated
+ as part of the specification of the implementation.
+
+ 3. The correct treatment of the padding function requires no
+ processing. A conforming implementation shall support the
+ function, to the extent of ignoring this parameter wherever
+ it may appear.
+
+ 4. This function may or may not be supported. If an
+ implementation does not support this function, and the
+
+
+
+ISO 8473 [Page 51]
+
+RFC 994 December 1986
+
+
+ function is selected in a PDU, then the PDU shall be discarded,
+ and an ER PDU shall be generated and forwarded to the
+ originating network-entity if the Error Report flag is set
+ and the conditions of Clause 6.10.4 are satisfied.
+
+ 5. This function may or may not be supported. If an implementation
+ does not support this function, and the function is selected
+ in a PDU, then the function is not performed and the PDU is
+ processed exactly as though the function had not been
+ selected. The PDU shall not be discarded for this reason.
+
+ ___________________________________________________________________
+ | Function | Send | Forward | Receive |
+ |____________________________|____________|___________|___________|
+ | PDU Composition | M | (Note 1) | (Note 1) |
+ | PDU Decomposition | M | - | M |
+ | Header Format Analysis | - | M | M |
+ | PDU Lifetime Control | | M | I |
+ | Route PDU | - | M | - |
+ | Forward PDU | M | M | (Note 1) |
+ | Segment PDU | M | (Note 2) | - |
+ | Reassemble PDU | - | I | M |
+ | Discard PDU | - | M | M |
+ | Error Reporting | M | M | M |
+ | Header Error Detection | (Note 3) | M | M |
+ | | | | |
+ | Security | - | (Note 3) | (Note 4) |
+ | Complete Source Routing | - | (Note 4) | - |
+ | Complete Route Recording | - | (Note 4) | - |
+ | Partial Source Routing | - | (Note 5) | - |
+ | Partial Route Recording | - | (Note 5) | - |
+ | Priority | - | (Note 5) | - |
+ | QoS Maintenance | - | (Note 5) | - |
+ | Congestion Notification | - | (Note 5) | - |
+ | Padding | - | (Note 5) | (Note 3) |
+ |____________________________|____________|___________|___________|
+
+
+ Table 8: Categorization of Functions
+ Key:
+
+ M: Mandatory Function; this function must be implemented.
+
+ -: Not applicable.
+
+ I: Implementation option, as described in the text.
+
+ NOTE: See notes above
+
+
+
+
+
+
+ISO 8473 [Page 52]
+