home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-04-21 | 123.0 KB | 3,070 lines |
-
-
-
-
- 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]
-
-