RFC 994
Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service
Title Block 🎀
okay bestie, let's get the vibes right first 💖 This is RFC 994, and it's dated March 1986. It's giving ISO-meets-Internet energy 💅
The RFC series label at the top is Network Working Group. The RFC number is 994. Two other document IDs also appear on it: ANSI X3S3.3 86-80 and ISO TC97/SC6/N 3998. The text is the Final Text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service 🦋 The source is the DIS 8473 Editor, so no individual author is named.
The title block doesn't spell out a category or status, and it doesn't list anything this RFC obsoletes or updates 🙈
Here's the ISO banner, copied exactly 👑
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) |
| |
| |
|_____________________________________________________________________|Contents 📚
Here's the whole map of the doc, so you can find your way around 🧚 Page numbers are dropped, but every section number and name is still here.
- 1 Scope and Field of Application
- 2 References
- SECTION ONE. GENERAL ✨
- 3 Definitions
- 3.1 Reference Model Definitions
- 3.2 Service Conventions Definitions
- 3.3 Network Layer Architecture Definitions
- 3.4 Network Layer Addressing Definitions
- 3.5 Additional Definitions
- 4 Symbols and Abbreviations
- 4.1 Data Units
- 4.2 Protocol Data Units
- 4.3 Protocol Data Unit Fields
- 4.4 Parameters
- 4.5 Miscellaneous
- 5 Overview of the Protocol
- 5.1 Internal Organization of the Network Layer
- 5.2 Subsets of the Protocol
- 5.3 Addresses and Titles
- 5.3.1 Addresses
- 5.3.2 Network-entity Titles
- 5.4 Service Provided by the Network Layer
- 5.5 Underlying Service Assumed by the Protocol
- 5.5.1 Subnetwork Points of Attachment
- 5.5.2 Subnetwork Quality of Service
- 5.5.3 Subnetwork User Data
- 5.5.4 Subnetwork Dependent Convergence Functions
- 5.6 Service Assumed from Local Environment
- 3 Definitions
- SECTION TWO. SPECIFICATION OF THE PROTOCOL 🔥
- 6 Protocol Functions
- 6.1 PDU Composition Function
- 6.2 PDU Decomposition Function
- 6.3 Header Format Analysis Function
- 6.4 PDU Lifetime Control Function
- 6.5 Route PDU Function
- 6.6 Forward PDU Function
- 6.7 Segmentation Function
- 6.8 Reassembly Function
- 6.9 Discard PDU Function
- 6.10 Error Reporting Function
- 6.10.1 Overview
- 6.10.2 Requirements
- 6.10.3 Processing of Error Reports
- 6.10.4 Relationship of Data PDU Options to Error Reports
- 6.11 PDU Header Error Detection
- 6.12 Padding Function
- 6.13 Security
- 6.14 Source Routing Function
- 6.15 Record Route Function
- 6.16 Quality of Service Maintenance Function
- 6.17 Priority Function
- 6.18 Congestion Notification Function
- 6.19 Classification of Functions
- 7 Structure and Encoding of PDUs 🌈
- 7.1 Structure
- 7.2 Fixed Part
- 7.2.1 General
- 7.2.2 Network Layer Protocol Identifier
- 7.2.3 Length Indicator
- 7.2.4 Version/Protocol Identifier Extension
- 7.2.5 PDU Lifetime
- 7.2.6 Flags
- 7.2.6.1 Segmentation Permitted
- 7.2.6.2 More Segments
- 7.2.6.3 Error Report
- 7.2.7 Type Code
- 7.2.8 PDU Segment Length
- 7.2.9 PDU Checksum
- 7.3 Address Part
- 7.3.1 General
- 7.3.1.1 Destination and Source Addresses
- 7.3.1 General
- 7.4 Segmentation Part
- 7.4.1 Data Unit Identifier
- 7.4.2 Segment Offset
- 7.4.3 PDU Total Length
- 7.5 Options Part
- 7.5.1 General
- 7.5.2 Padding
- 7.5.3 Security
- 7.5.3.1 Source Address Specific
- 7.5.3.2 Destination Address Specific
- 7.5.3.3 Globally Unique Security
- 7.5.4 Source Routing
- 7.5.5 Recording of Route
- 7.5.6 Quality of Service Maintenance
- 7.5.6.1 Source Address Specific
- 7.5.6.2 Destination Address Specific
- 7.5.6.3 Globally Unique QoS
- 7.5.7 Priority
- 7.6 Data Part
- 7.7 Data (DT) PDU
- 7.7.1 Structure
- 7.7.1.1 Fixed Part
- 7.7.1.2 Addresses
- 7.7.1.3 Segmentation
- 7.7.1.4 Options
- 7.7.1.5 Data
- 7.7.1 Structure
- 7.8 Inactive Network Layer Protocol
- 7.8.1 Network Layer Protocol Id
- 7.8.2 Data Field
- 7.9 Error Report PDU (ER)
- 7.9.1 Structure
- 7.9.1.1 Fixed Part
- 7.9.1.2 Addresses
- 7.9.1.3 Options
- 7.9.1.4 Reason for Discard
- 7.9.1.5 Error Report Data Field
- 7.9.1 Structure
- 6 Protocol Functions
- 8 Conformance
- 8.1 Provision of Functions for Conformance
List of Tables 🌸
- Table 1: Service Primitives for Underlying Service
- Table 2: Service Primitives for Underlying Service
- Table 3: Timer Primitives
- Table 4: Categorization of Protocol Functions
- Table 5: Valid PDU Types
- Table 6: Encoding of Option Parameters
- Table 7: Reason for Discard
- Table 8: Categorization of Functions
List of Figures 🎀
1 Interrelationship of Standards . . . . . . . . . . . . . . . . . 6
2 PDU Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . . . 34
4 PDU Header -- Address Part . . . . . . . . . . . . . . . . . . . 37
5 Address Parameters . . . . . . . . . . . . . . . . . . . . . . . . 38
6 PDU Header -- Segmentation Part . . . . . . . . . . . . . . . . . 38
7 PDU Header -- Options Part . . . . . . . . . . . . . . . . . . . . 39
8 PDU Header -- Data Field . . . . . . . . . . . . . . . . . . . . 45
9 DT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10 Inactive Network Layer Protocol . . . . . . . . . . . . . . . . . 47
11 Error Report PDU . . . . . . . . . . . . . . . . . . . . . . . . . 480. Introduction ✨
Okay bestie, so this Protocol Standard is one of a whole set of International Standards made to help open systems interconnect 🌐💖. The set covers the services and protocols that are needed to actually pull off that interconnection.
This Protocol Standard sits in the layers defined by the Reference Model for Open Systems Interconnection (ISO 7498) 🧚. Specifically, it's a protocol of the Network Layer 🔥. It can be used between network-entities in end systems, in Network Layer relay systems, or in both. It provides 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 shown 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 Standards1. Scope and Field of Application 💅
This International Standard specifies a protocol that's used to provide the Connectionless-mode Network Service described in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission. The protocol relies on an underlying connectionless-mode service being provided by real subnetworks and/or data links 🧚. That underlying service can come either directly from a connectionless-mode real subnetwork, or indirectly through an appropriate Subnetwork Dependent Convergence Function (SNDCF) or Protocol (SNDCP) running over a connection-mode real subnetwork. That last setup is described in ISO 8648, Internal Organization of the Network Layer.
This Standard specifies:
- a) procedures for the connectionless transmission of data and control information from one network-entity to a peer network-entity;
- b) the encoding of the protocol data units (PDUs) used for the transmission of data and control information, comprising a variable-length protocol header format;
- c) procedures for the correct interpretation of protocol control information; and
- d) the functional requirements for implementations claiming conformance to the Standard.
The procedures are defined in terms of:
- a) the interactions among peer network-entities through the exchange of protocol data units;
- b) the interactions between a network-entity and a Network Service user through the exchange of Network Service primitives; and
- c) the interactions between a network-entity and an underlying service provider through the exchange of service primitives.
2. References 📚
ISO 7498, Information Processing Systems --- Open Systems Intercon-
nection --- Basic Reference Model
DIS 7498/AD1, Information Processing Systems --- Open Systems In-
terconnection --- Addendum to ISO 7498 Covering Connectionless-mode
Transmission
ISO 8348, Information Processing Systems --- Telecommunications and
Information Exchange between Systems --- Network Service Definition
ISO 8348/AD1, Information Processing Systems --- Telecommunications
and Information Exchange between Systems --- Addendum to the Net-
work Service Definition Covering Connectionless-mode Transmission
ISO 8348/AD2, Information Processing Systems --- Telecommunications
and Information Exchange between Systems --- Addendum to the Net-
work Service Definition Covering Network Layer Addressing*
DIS 8648, Information Processing Systems --- Telecommunications and
Information Exchange between Systems --- Internal Organization of the
Network Layer
ISO 8509, Technical Report --- OSI Service Conventions
ISO 9074, A Formal Description Technique based on an Extended State
Transition Model
________________________________
*At present, at the stage of Draft; publication anticipated in
due course.SECTION ONE. GENERAL ✨
3. Definitions 🎀
3.1. Reference Model Definitions
This document makes use of the following concepts defined in ISO 7498:
- (a) End system
- (b) Network entity
- (c) Network layer
- (d) Network protocol
- (e) Network protocol data unit
- (f) Network relay
- (g) Network service
- (h) Network service access point
- (i) Network service access point address
- (j) Routing
- (k) Service
- (l) Service data unit
3.2. Service Conventions Definitions
This Protocol Standard makes use of the following terms from the OSI Service Conventions Technical Report (ISO TR 8509):
- (a) Service provider
- (b) Service user
3.3. Network Layer Architecture Definitions
This Protocol Standard makes use of the following terms from the Internal Organization of the Network Layer (ISO 8648):
- (a) Intermediate system
- (b) Relay system
- (c) Subnetwork
3.4. Network Layer Addressing Definitions
This Protocol Standard makes use of the following terms from ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer addressing:
- (a) Network addressing domain
- (b) Network protocol address information
- (c) Subnetwork point of attachment
3.5. Additional Definitions
For the purposes of this Protocol Standard, the following definitions apply:
- (a) derived PDU --- a protocol data unit whose fields are identical to those of an initial PDU, except that it carries only a segment of the user data from an N-UNITDATA request.
- (b) initial PDU --- a protocol data unit carrying the whole of the userq data from an N-UNITDATA request.
- (c) local matter --- a decision made by a system concerning its behavior in the Network Layer that is not prescribed or constrained by this Protocol Standard.
- (d) network-entity title --- an identifier for a network-entity which has the same abstract syntax as an NSAP address, and which can be used to unambiguously identify a network-entity in an end or intermediate system.
- (e) reassembly --- the act of regenerating an initial PDU from two or more derived PDUs.
- (f) segment --- a distinct unit of data consisting of part or all of the user data provided in the N-UNITDATA request and delivered in the N-UNITDATA indication.
- (g) segmentation --- the act of generating two or more derived PDUs from an initial or derived PDU. The derived PDUs together carry the entire user data of the initial or derived PDU from which they were generated.
Note:
It is possible that such an initial PDU will never actually be generated for a particular N-UNITDATA request, owing to the immediate application of segmentation.
4. Symbols and Abbreviations 🦋
4.1. Data Units
NSDU Network Service Data Unit
PDU Protocol Data Unit
SNSDU Subnetwork Service Data Unit4.2. Protocol Data Units
DT PDU Data Protocol Data Unit
ER PDU Error Report Protocol Data Unit4.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 Extension4.4. Parameters
DA Destination Address
QOS Quality of Service
SA Source Address4.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 Attachment5. Overview of the Protocol 💖
5.1. Internal Organization of the Network Layer
The architecture of the Network Layer is described in a separate document, Internal Organization of the Network Layer (ISO 8648) 🌸. ISO 8648 breaks down and categorizes the ways functions can be performed within the Network Layer by Network Layer protocols. That gives a uniform framework for describing how protocols that work alone or together 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 providing the Connectionless-mode Network Service defined in that Standard.
This protocol is meant for the Subnetwork Independent Convergence Protocol (SNICP) role. A protocol that fills the SNICP role builds the OSI Network Service on top of a defined set of underlying services. It does the functions needed to keep the OSI Connectionless-mode Network Service looking uniform over a homogeneous or heterogeneous set of interconnected subnetworks 🫶. This protocol is defined to handle variability where Subnetwork Dependent Convergence Protocols and/or Subnetwork Access Protocols don't provide all of the functions needed to support the Connectionless-mode Network Service over all or part of the path from one NSAP to another 😭.
The protocol may take on different roles depending on the configuration (ISO 8648 covers this). It's built with the SNICP role in mind for the internetworking approach to the Connectionless-mode Network Service 💜, but it's a total multitasker. It may also be used for other roles and in other approaches to subnetwork interconnection 🦋.
Before we get into the details, the spec defines the underlying service it assumes 🎀. That service comes from other Network Layer protocols or from the Data Link Service 🫶. The underlying service this protocol assumes is described in Clause 5.5 ✨.
5.2. Subsets of the Protocol 💅
Two proper subsets of the full protocol are defined. They let you use known subnetwork characteristics, so they're not subnetwork independent 🌸.
The Inactive Network Layer protocol subset is a null-function subset 😭. You can use it when you know the source and destination end-systems are connected by a single subnetwork, and none of the full protocol's functions are needed to provide the Connectionless-mode Network Service between any pair of end-systems 💀.
The Non-segmenting protocol subset simplifies the header when the source and destination end-systems are connected by subnetworks whose service data unit sizes are greater than or equal to a known bound. That bound has to be big enough that segmentation isn't required 🍓. You select this subset by setting the Segmentation Permitted flag to zero 🔥.
5.3. Addresses and Titles 🌈
The next Clauses describe the addresses and titles this Protocol uses 💖.
5.3.1. Addresses
The Source Address and Destination Address parameters mentioned in Clause 7.3 of this International Standard are OSI Network Service Access Point Addresses 🧚. Their syntax and semantics are described in a separate document, ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer Addressing 📚.
The encoding this protocol uses to convey NSAP Addresses shall be the preferred binary encoding specified in ISO 8348/AD2 🔢. The whole NSAP address, taken as one piece, is written out explicitly as a string of binary octets. That string gets conveyed in its entirety in the address fields described in Clause 7.3 ✨. The rules for generating the preferred binary encoding are also 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 come from the same name space as NSAP addresses. Whether an address counts as an NSAP address or a network-entity title depends on the context it's interpreted in 🤔. The entries in the Source Routing and Recording of Route parameters from Clauses 7.5.4 and 7.5.5 are network-entity titles 💜. The Source Address and Destination Address parameters in the Error Report PDU from Clause 7.9.1.2 are network-entity titles too 😭.
The encoding this protocol uses 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 🫶. That string is conveyed in its entirety in the fields described in Clauses 7.5.4, 7.5.5, and 7.9.1.2 ✨.
5.4. Service Provided by the Network Layer 🎀
The service this protocol provides is the Connectionless-mode Network Service described in ISO 8348/AD1, Addendum to the Network Service Definition Covering Connectionless-mode Transmission 📨. The Network Service primitives 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 ServiceThe Addendum to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1) states that the maximum 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 ServiceNote: These service primitives are used to describe the abstract interface between the ISO 8473 protocol machine and an underlying real subnetwork, or a Subnetwork Dependent Convergence Function that operates over a real subnetwork or real data link to provide the required underlying service.
5.5.1. Subnetwork Points of Attachment
The source and destination addresses specify the points of attachment to a public or private subnetwork(s) involved in the transmission 📍. Subnetwork Point of Attachment addresses (SNPAs) are defined by each individual subnetwork authority 👑.
The syntax and semantics of SNPAs are not defined in this Standard 🙈.
5.5.2. Subnetwork Quality of Service
Subnetwork Quality of Service describes the aspects of an underlying connectionless-mode service that are attributable solely to that underlying service 💅.
Each connectionless-mode transmission comes with certain measures of Quality of Service, requested when the primitive action is initiated ⭐. These requested measures (or parameter values and options) are based on a priori knowledge of the service(s) the subnetwork makes available 🧠. Knowledge of the nature and type of service available is typically obtained before the underlying connectionless-mode service is invoked 📚.
The Quality of Service parameters identified for the underlying connectionless-mode service may, in some circumstances, be directly derivable from or mappable onto those in the Connectionless-mode Network Service 🦋. The following parameters, as defined in ISO 8348/AD1, Addendum to the Network Service Definition Covering Connectionlessmode Transmission, may be employed:
- (a) transit delay;
- (b) protection against unauthorized access;
- (c) cost determinants;
- (d) priority; and
- (e) residual error probability.
Note: For those subnetworks which do not inherently provide Quality of Service as a parameter when the primitive action is initiated, it is a local matter as to how the semantics of the service requested might be preserved. In particular, there may be instances in which the Quality of Service requested cannot be maintained. In such circumstances, an attempt shall be made to deliver the protocol data unit at whatever Quality of Service is available.
5.5.3. Subnetwork User Data
The SN-Userdata is an ordered multiple of octets, and it 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 subnetworks 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 provide an underlying connectionless-mode service in the case where a real subnetwork does not inherently provide the connectionless-mode service the protocol assumes 🌈. If a subnetwork inherently provides a connection-mode service, a Subnetwork Dependent Convergence Function provides a mapping into the required underlying service 🧚. Subnetwork 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 explicit 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 💅:
- the S--TIMER Request,
- the S--TIMER Response, and
- the S--TIMER Cancel.
The S--TIMER Request primitive tells the local environment to start a timer of the specified name and subscript, and to maintain it for the duration given 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 Request primitive has elapsed 🔔.
The S--TIMER Cancel primitive is an indication to the local environment 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 PrimitivesThe time parameter tells you how long the specified timer runs ⏱️ ✨ A timer gets its identifying label through the name parameter 🎀. The subscript parameter is a value that tells apart timers with the same name 🦋. name and subscript together make one unique reference to a timer 💖.
Timers used with a specific protocol function are defined under that protocol function 🧚
Note: This International Standard does not define specific values for the timers. Any derivations described in this Standard are not mandatory. Timer values SHOULD be chosen so that the requested Quality of Service can be provided, given the known characteristics of the underlying service. 💅
SECTION TWO. SPECIFICATION OF THE PROTOCOL ✨
6 Protocol Functions 🌸
This Clause describes the functions performed as part of the Protocol. 💜
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 constructing a protocol data unit according to the rules for encoding PDUs in Clause 7 🎀. The Protocol Control Information needed to deliver the data unit to its destination is worked out from the current state, local information, and the parameters associated with the N-UNITDATA Request 💅.
The Network Protocol Address Information (NPAI) for the Source Address and Destination Address fields of the PDU header comes 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, decide which optional functions get selected ✨. The user data passed down from the Network Service User (NS-Userdata) becomes the Data field of the protocol data unit 💖.
While the PDU is being composed, a Data Unit Identifier gets assigned so this request to send NS-Userdata to one particular destination NS User can be told apart from other requests like it 🔥. The originator of the PDU MUST choose the Data Unit Identifier so that it stays unique (for this Source and Destination Address pair) for the maximum lifetime of the Initial PDU in the network 😭. This rule also applies to any PDUs derived from the Initial PDU as a result of the Segmentation Function (see Clause 6.7). Derived PDUs count as corresponding to the same Initial PDU, and therefore the same N-UNITDATA Request, if they have the same Source Address, Destination Address, and Data Unit Identifier 👑.
The Data Unit Identifier is also available for ancillary functions such as error reporting (see Clause 6.10) 🌈.
The total length of the PDU in octets is determined by the originator and placed in the Total Length field of the PDU header 💅. This field is not changed in any Derived PDU for the lifetime of the protocol data unit.
When the Non-segmenting protocol subset is employed, neither the Total Length field nor the Data Unit Identifier field is present ⭐. The PDU composition rules are modified in this case as follows. During 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 Identification is provided 🙈.
6.2 PDU Decomposition Function
This function is responsible for removing the Protocol Control Information from the protocol data unit 🫶. Along the way, information needed for the N-UNITDATA Indication gets determined like this 💜. The NS-Source-Address and NS-Destination-Address parameters of the N-UNITDATA Indication are recovered from the NPAI in the Source Address 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 🦋. Together, these form the NS-Userdata parameter of the N-UNITDATA Indication. Information about the Quality of Service provided during transmission of the PDU is determined from the Quality of Service and other information in the Options Part of the PDU header ✨. This information makes up 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 of it 🎀. If the protocol data unit has a Network Layer Protocol Identifier indicating that this is a standard version of the Protocol, this function determines whether a received PDU has reached its destination, using the Destination Address provided in the PDU 🔥. If the Destination Address 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 indicating that the Inactive Network Layer Protocol subset is in use, then no further analysis of the PDU header is required 🌸. In this case, the network-entity determines either that the Subnetwork Point of Attachment address, encoded as network protocol address information in the supporting subnetwork protocol, corresponds directly to an NSAP address served by this network-entity, or that an error has occurred 😭. If the subnetwork protocol data unit has been delivered correctly, then the PDU MAY be decomposed according to the procedures described for that particular subnetwork protocol 🧚.
6.4 PDU Lifetime Control Function
This function is used to enforce the maximum PDU lifetime 💖. It is closely associated with the Header Format Analysis function 🫶. This function determines whether a received PDU MAY be forwarded, or whether its assigned lifetime has expired, in which case it MUST be discarded 💀.
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 milliseconds) 👑. The Lifetime of the Initial PDU is determined by the originating 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 decrements the PDU Lifetime by at least one. The value of the PDU Lifetime field SHALL be decremented by more than one if the sum of:
- the transit delay in the underlying service from which the PDU was received; and
- 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 does not need to be precise 🙈. 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, Error Reporting Function, and it 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 the 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 function (along with the PDU itself) for further processing 🎀.
Selection of the underlying service that MUST be used to reach the "next" system in the route is initially influenced by the NS-Quality-of-Service parameter of the N-UNITDATA Request, which specifies the QoS requested by the sending NS User ✨. Whether this QoS is to be provided directly by the CLNP, through 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 determined prior to invocation of the Forward PDU function 💖. Route selection 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) 🔥. It supplies the subnetwork or SNDCF identified by the Route PDU function with the protocol data unit as user data to be transmitted 💅. It also supplies the address information that subnetwork or SNDCF needs to identify the "next" system within the subnetwork-specific addressing domain (this MAY be an intermediate-system or the destination end-system) 🌈, and any Quality of Service constraints (if any) to be considered in processing 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 function 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 segmentation part, is duplicated in each Derived PDU ✨. That includes 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 service 🍓.
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 containing less than eight (8) octets of user data 😭.
The following fields of the PDU header are used in conjunction with the Segmentation function:
okay so the Derived PDUs get four fields in their header, and they're all super important 💅
- (a) Segment Offset 🎀: counts from the start of the Initial PDU and tells you the octet where this segment begins;
- (b) Segment Length 🦋: the number of octets in the Derived PDU, header and data both included;
- (c) More Segments Flag 🌸: set to one if this Derived PDU does not contain the final octet of the Initial PDU as its last octet of user data; and
- (d) Total Length ✨: the entire length of the Initial PDU, header and data both included.
Derived PDUs can get segmented again, and that doesn't put any limits on how the individual Derived PDUs get routed 🧚. The Segmentation Permitted flag is set to one when segmentation is allowed. If the Initial PDU must never be segmented at any point during its life in the network, the source network-entity sets the flag to zero 🙈. No other network-entity can change the Segmentation Permitted flag for the whole lifetime of the Initial PDU and any Derived PDUs, so it's locked in, bestie 🔒.
6.8 Reassembly Function ✨
okay the Reassembly function is what puts the Initial PDU back together from all the Derived PDUs that the Segmentation Function made from it (and, recursively, from any later Derived PDUs too) 🧩. There's a time limit on how long segments (Derived PDUs) of an Initial PDU get held at a reassembly point before they're thrown out. This is so reassembly resources can be freed up once nobody's expecting more segments of that Initial PDU to show up at that point 💀. When a Derived PDU arrives, a reassembly timer starts, and its value says how long has to pass before any outstanding segments of the Initial PDU are assumed to be lost. Once the timer expires, every segment (Derived PDU) of that Initial PDU sitting at the reassembly point is discarded, the resources for them are freed, and, if it was selected, an Error Report is generated (see Clause 6.10) 😭.
How the reassembly lifetime lines up with the PDU lifetime is a local decision, but the Reassembly Function has to keep the intent of the PDU lifetime. So the reassembly function must throw out PDUs whose lifetime would have run out anyway, if they hadn't been under its control 👑.
Note: 1. Methods of bounding reassembly lifetime are discussed in Annex B. 2. The Segmentation and Reassembly functions are meant to be used so that the fewest possible segments get generated at each segmentation point, and reassembly happens at the final destination of a PDU. Other schemes are not ruled out, though, including ones that: - (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. The information needed to use 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 decides the value of the Segmentation Permitted flag in the Initial PDU and in 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 in any PDU derived from it, so it can't add or remove the segmentation part of the header either 🌈.
6.9 Discard PDU Function 🗑️
This function does everything needed to free the resources the network-entity reserved whenever any of these situations shows up (Note: the list is not exhaustive) 💖:
- (a) A violation of protocol procedure has occurred.
- (b) A PDU is received whose checksum is inconsistent with its contents.
- (c) A PDU is received, but due to local congestion, it cannot be processed.
- (d) A PDU is received whose header cannot be analyzed.
- (e) A PDU is received which cannot be segmented and cannot be forwarded because its length exceeds the maximum service data unit size supported by any underlying service available for transmission of the PDU to the next network-entity on the chosen route.
- (f) A PDU is received whose destination address is unreachable or unknown.
- (g) Incorrect or invalid source routing was specified. This may include a syntax error in the source routing field, an unknown or unreachable address in the source routing field, or a path which is not acceptable for other reasons.
- (h) A PDU is received whose PDU lifetime has expired or whose lifetime expires during reassembly.
- (i) A PDU is received which contains an unsupported option.
6.10 Error Reporting Function 🦋
6.10.1 Overview
This function tries to send an Error Report PDU back to the source network-entity whenever a protocol data unit gets discarded under Clause 6.9 💌.
The Error Report PDU names the discarded PDU, says what type of error was detected, and points to the spot in the discarded PDU's header where the error was found 🔍. At least the entire header of the Discarded PDU goes into the data field of the Error Report PDU. The originator of the Error Report PDU decides whether to include none, all, or part of the data field 🎀.
The originator of a Data PDU can control whether Error Report PDUs get generated 🎛️. The source network-entity sets an Error Report flag in the original PDU to say an Error Report PDU should come back if the Initial PDU or any PDUs derived from it get discarded. If the flag isn't set, Error Reports are supposed to be suppressed 🤫.
Note: 1. The suppression of Error Report PDUs is controlled by the originating network-entity and not by the NS User. The originator should be careful about suppressing ER PDUs, so that error reporting isn't suppressed for every PDU it generates. 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 put together from information in the header of the discarded Data PDU that the Error Report refers to 🧁. The contents of the Source Address field of the discarded Data PDU become the Destination Address of the Error Report PDU. In the context of the Data PDU, this value was an NSAP Address, but in the context of the Error Report PDU it's used 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 carried in the Source Address field of the Error Report PDU header. The value of the Lifetime field is set according to Clause 6.4, and optional parameters are picked according to Clause 6.10.4 ⏳.
Segmentation of Error Report PDUs is not permitted, so there's no Segmentation Part 🙅. The total length of the ER PDU in octets goes in the Segment Length field of the ER PDU header, and that field doesn't change for the life of the ER PDU. If the originator of the ER PDU finds the ER PDU is bigger than the maximum 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 changes. Error Report PDUs get routed and forwarded by intermediate-system network-entities the same way Data PDUs do 🚚.
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 carried in the data field of any ER PDU 💡.
When an ER PDU reaches its destination and gets decomposed, the info needed to read and act on the Error Report is pulled out like this 🔓. The network-entity title recovered from the NPAI in the Source Address field of the ER PDU header identifies the network-entity that generated the Error Report. The reason for generating the Error Report comes from the Options Part of the PDU header. The entire header of the discarded Data PDU (plus part or all of the original user data) is taken from the data field of the ER PDU to help figure out what kind of error it was 🕵️.
6.10.4 Relationship of Data PDU Options to Error Reports
Options present in the matching Data PDU affect whether an Error Report gets generated 🎭. If the system that discarded the PDU doesn't support an option that's present in the original Data PDU, the Error Report can get suppressed, even if the original Data PDU asked for an Error Report to be generated when it's discarded 😬.
Options in the corresponding Data PDU also affect how an Error Report gets processed. In particular, options selected for the original Data PDU decide which options show up in the matching Error Report PDU. Here's what governs picking options for an Error Report PDU 📋:
- (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) okay bestie, if the Complete Source Route Option is picked in the original Data PDU, AND the system making the Error Report PDU supports that option, then the error Report shall specify the Complete Source Route option 💅 The Source Route parameter value comes from pulling out the part of the complete source route that's already been traversed from the original Data PDU, then reversing the order of the network-entity titles in that list 🔄 If the system doesn't support the Complete Source Route Option, then 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 💖
okay so this function is basically the bodyguard for the PDU header 🛡️ It protects against intermediate or end-system network-entities failing because they processed bad info in the header. It's realized with a checksum computed over the entire PDU header 🎀 The checksum gets verified every single time the PDU header is processed. If the checksum calculation fails, the PDU must be discarded 💀 And if PDU header fields get modified (like by the lifetime function), the checksum is modified too, so it stays valid ✨
The use of the Header Error Detection function is optional, and the originating network-entity is the one that selects it 🦋 If the function isn't used, the checksum field of the PDU header is set to zero.
If the originating network-entity selects the function, the value of the checksum field has to make these formulae satisfied 👑
(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) = 0Here, L is the number of octets in the PDU header, and a(i) is the value of the octet at position i. The first octet in the PDU header counts as position i = 0 🧮
When the function is in use, neither octet of the checksum field may be set to zero 🚫
Note:
- To make sure that an accidental change to a header while a PDU is being processed by an intermediate system (say, because of a memory fault) can still be caught by the PDU Header Error function, an intermediate system network-entity must not recompute the checksum for the entire header, even if fields are modified 🔍
- Annex C contains descriptions of algorithms that 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 exists so space can be reserved in the PDU header that isn't used to support any other function 🍓 Octet alignment must be maintained.
Note: An example of using this function: it can make the data field of a PDU begin on a convenient boundary for the originating network-entity, like a computer word boundary 💜
6.13 Security 🔐
The provision of protection services (like data origin authentication, data confidentiality, and data integrity of a single connectionless-mode NSDU) is handled by the Security Function 🫶
The Security Function is related to the Protection from Unauthorized Access Quality of Service parameter described in ISO 8348/AD1, Addendum to the Network Service Definition Covering Connectionless-mode Transmission. It's realized by selecting the security parameter in the options part of the PDU header 🛡️
This Standard does not specify the way protection services are to be provided. It only provides for encoding security information in the PDU header 📝 To help end-systems and network relay-systems interoperate, and to avoid different interpretations of the same encoding, a way to tell user-defined security encodings apart from standardized ones is described in Clause 7.5.3 🌈
Note: As an implementation consideration, data origin authentication may be provided through 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 lets the originator choose the path a generated PDU must take ✨ Source routing may only be selected by the originator of a PDU. It's 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 it doesn't change as the PDU traverses the network.
The Source Route parameter includes information the originating end-system uses when figuring out the initial route of the PDU. Only the titles of intermediate system network-entities go in the list. The network-entity title of the PDU's destination is NOT in the list 🙅
Attached to the list of network-entity titles is an indicator that points to the next entry to be used. The receiver of the PDU advances this indicator when the next title in the list matches its own 🎯 The indicator keeps getting updated as the PDU is forwarded, so it identifies the right entry at each stage of relaying.
Two forms of the Source Routing function are provided 👯 The first form, Complete Source Routing, requires that the specified path must be taken. That means only the systems identified in the list may be visited by the PDU on its way to the destination, and each system must be visited in the order specified. If the specified path can't be taken, the PDU must be discarded. Clause 6.10 describes the circumstances in which an attempt shall be made to tell the originator about the discard using the Error Reporting function 📣
The second form is Partial Source Routing. Again, each system identified in the list must be visited in the order specified on the way to the destination. However, with this form the PDU may take any path necessary to reach the next intermediate system in the list, which may include visiting intermediate systems that aren't in the list 🧭 The PDU will not be discarded (for source routing related reasons) unless one of the specified systems can't be reached by any available route.
6.15 Record Route Function 📜
The Record Route function records the path(s) a PDU takes as it travels through a series of intermediate systems 🐾 A recorded route is 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 list gets built as the PDU is forwarded along a path toward its destination. Only the titles of intermediate system network-entities go in the recorded route. The network-entity title of the PDU's originator is NOT recorded in the list 🙅
When an intermediate system network-entity processes a PDU containing the Record Route parameter, the system adds its own network-entity title at the end of the list of recorded titles 💅 An indicator is maintained to identify the next available octet to be used for recording the route. This indicator gets updated as entries are added, like this: the length of the entry to be added is added to the value of the next available octet indicator, and this sum is compared with the length of the Record Route parameter 🧮 If adding the entry would exceed the size of the parameter, the next available octet indicator is set to indicate that route recording has been terminated. The network-entity title is not added to the list. The PDU may still be forwarded to its final destination, without any further additions of network-entity titles 🛑
If adding 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 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 route recording to be terminated, as described above. When Complete Route Recording is selected, PDU reassembly at intermediate systems is performed only when the Derived PDUs being 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 Partial Route Recording. It also requires a record of the intermediate systems visited by a PDU. When Partial Route Recording is selected, PDU reassembly at intermediate systems is always permitted. When reassembly happens at an intermediate 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 for diagnosing subnetwork problems and/or for providing 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 gives information to network-entities in intermediate systems. They can use it to make routing decisions where those decisions affect the overall QoS provided to NS users 💖 This information is conveyed to intermediate system network-entities in a parameter in the options part of the PDU header.
When the QoS requested can't be maintained, intermediate system network-entities shall attempt to deliver the PDU at a QoS different from the one 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 lets a PDU with a numerically higher priority value be processed preferentially over 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 (0) 💜, and a source network-entity that doesn't support the Priority function MUST set the Priority value to zero. The whole point of Priority is that end and intermediate system network-entities can spend their resources, like outgoing transmission queues and buffers, on higher-priority PDUs first, so those get processed ahead of the lower-priority ones 🚀. How each individual network-entity pulls that off is a local matter 🤷♀️.
6.18. Congestion Notification Function 🚦
So NS Users can take the right action when congestion shows up inside the NS provider 👀, intermediate systems MAY tell the destination network-entity about it using a flag in the QoS Maintenance parameter in the options part of the PDU header. The originator starts this flag at zero (0), and any intermediate system that processes the PDU MAY flip it to one (1) to say "hey, I'm congested rn" 😭. When to do that is a local matter.
Note: Congestion usually means there's no buffer space left to hold output queues 🫠. A solid policy for flagging it might look at how deep the output queue is for a PDU (picked by its destination address or other routing info). Once a queue's depth goes past a certain proportion of that queue's depth, an intermediate system starts discarding PDUs 🗑️. It'll set the Congestion Experienced flag on the next PDU it forwards, and it MAY keep doing that until things calm down.
6.19. Classification of Functions 🗂️
Implementations don't have to support every function in Clauses 6.1 through 6.18 😌. Functions get sorted into three types:
Type 1: These functions MUST be supported.
Type 2: These functions MAY or may not be supported. If an implementation doesn't support a Type 2 function, and that 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 the Error Report flag is set and the conditions of Clause 6.10.4 are satisfied. Yikes, but it makes sense 💀.
Type 3: These functions MAY or may not be supported. If an implementation doesn't support a Type 3 function, and that function is selected in a PDU, then the function is not performed, and the PDU is processed exactly as though the function hadn't been selected. The protocol data unit SHALL NOT be discarded for this reason 🫶.
Table 4 shows how the functions are split across 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
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 they're 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 octets are transferred, using the terms "most significant bit" and "least significant bit". The PDUs of this protocol are defined using those same terms "most significant bit" and "least significant bit" ✨.
Note: When a PDU's encoding is drawn as 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:
- the fixed part;
- the address part;
- the segmentation part, if present;
- the Options part, if present;
and the data field, if present. This structure is illustrated in Figure 2:
7.2. Fixed Part
7.2.1. General
The fixed part of the PDU header holds the frequently occurring parameters, including the type code (DT or ER) of the protocol data unit 💅. The length and 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 Part7.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 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 it's the same as the header length of the Initial PDU. The size of a PDU header won't 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 employed. 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 Segmentation Permitted flag is not set to one (1) 🙅♀️.
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
Okay bestie, let's pick up right where the Error Report flag hits 1️⃣ 💖. When it's set to one, the rules in Clause 6.10 decide whether an Error Report PDU gets generated if this Data PDU has to be discarded. ✨
When the Error Report flag is set to zero, though, throwing away the Data PDU won't generate an Error Report PDU. 🙈
7.2.7. Type Code 🎀
The Type code field tells you what kind of protocol data unit you're looking at. 🦋 The allowed values are 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 Types7.2.8. PDU Segment Length 📏
The Segment Length field gives the whole length, in octets, of the Derived PDU, header and data (if there's data) included. 💅 When the full protocol is used and the PDU isn't segmented, this field matches the Total Length field that lives in the Segmentation Part of the header. 🌸
When the non-segmenting protocol subset is in use, there's no segmentation part in the header at all. 😭 In that subset, the Segment Length field gives the entire length of the Initial PDU, header and data (if present) included. The Segment Length field never changes for the lifetime of the PDU. 🔒
7.2.9. PDU Checksum 🧮
The checksum is computed over the entire PDU header. 🔥 For the Data PDU, that includes the segmentation and options parts (if they're there). For the Error Report PDU, it also includes the reason for discard field. 👑
A checksum value of zero is reserved to mean the checksum should be ignored. 🙈 The PDU Header Error Detection function (Clause 6.11) makes sure zero can't show up as a real checksum value. ✨ A non-zero value means the checksum MUST be processed. 💖 And if the checksum calculation fails, the PDU MUST be discarded. 💀
7.3. Address Part 🏡
7.3.1. General 🌈
Address parameters are identified by where they sit, right after the fixed part of the PDU header. 📍 The address part looks like this in 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 Part7.3.1.1. Destination and Source Addresses 🗺️
The Destination and Source addresses used by this protocol are Network Service Access Point addresses, as defined in ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer Addressing. ✨
The Destination and Source Addresses are variable length. 🦋 The Destination and Source Address fields are encoded as Network Protocol Address Information, using the Preferred Binary Encoding defined in Clause 8.3.1 of ISO 8348/AD2. 💜
The Destination Address Length Indicator field gives the length of the Destination Address in octets. 📐 The Destination Address field comes right after the Destination Address Length Indicator field. 🫶
The Source Address Length Indicator field gives the length of the Source Address in octets. 📐 It follows the Destination Address field, and the Source Address field follows the Source Address Length Indicator field. 🌸
Each address parameter is encoded as shown in Table 5: 🍓
______________________________________________
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|________|____________________________________|
| Octets | |
| n + 1 | Address Parameter Value |
| thru | |
| n + m | |
|________|____________________________________|
Figure 5: Address Parameters7.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 MUST be present, and it looks like Figure 6: 🧩
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 Part7.4.1. Data Unit Identifier 🆔
The Data Unit Identifier identifies an Initial PDU (and so, its Derived PDUs too), which is how a segmented data unit gets put back together correctly. 🧸 The Data Unit Identifier is two octets long. ✨
7.4.2. Segment Offset 📍
For each Derived PDU, the Segment Offset field gives the relative position of the segment in the Derived PDU's data field, measured from the start of the Initial PDU's data field. 🎯 The offset is measured in units of octets. The first segment (and so, the Initial PDU) has an offset of zero, and an unsegmented Initial PDU also has a segment offset value of zero (0). 💫 The value of this field SHALL be a multiple of eight 8). 💅
7.4.3. PDU Total Length 📦
The Total Length field gives the entire length of the Initial PDU, header and data included. 🫧 This field doesn't change for the lifetime of the Initial PDU (and so, its Derived PDUs). 🔒
7.5. Options Part 🎁
7.5.1. General 🌟
The options part carries optional parameters. 🎀 The options part of the PDU header looks like this:
Octet
___________________________________________________
| | n + 6
: Options :
| | p
|__________________________________________________|
Figure 7: PDU Header -- Options PartIf the options part is present, it MAY contain one or more parameters. 🧁 How many parameters fit is limited by the length of the options part, which is worked out with this formula:
PDU Header Length -(length of fixed part+length of address part+length of segmentation part)and also by the length of each individual optional parameter. 📏
Parameters defined in the options part MAY appear in any order. 🌀 Duplicating an option is not allowed. 🚫 Receiving a Protocol Data Unit with a duplicated option SHOULD be treated as a protocol error. ⚠️ The rules for handling protocol errors are described in Clause 6.10, Error Reporting Function. 🧐
The parameters inside the options part of the PDU header are encoded as shown in Table 6: 🍭
Octets
___________________________________________
| n | Parameter Code |
|____________|____________________________|
| n + 1 | Parameter Length (e.g.m) |
|____________|____________________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|____________________________|
Table 6: Encoding of ParametersThe parameter code field is binary and, without extensions, gives a maximum of 255 different parameters. 🔢 No parameter codes use bits 8 and 7 with the value 00, so the real maximum is lower than that. 📉 A parameter code of 255 (binary 1111 1111) is reserved for possible future extensions. 🔮
The parameter length field gives the length, in octets, of the parameter value field. 📏 The length is a positive binary number, m, with a theoretical maximum of 254. 🤯 The practical maximum for m is lower. 🥲 For example, if there's a single parameter in the options part, two octets are needed for the parameter code and the parameter length indicators. So the value of m is limited to:
m = 252-(length of fixed part +length of address part +length of segmentation part)Each succeeding parameter lowers the maximum value of m even further. 📉 The parameter value field holds the value of the parameter identified in the parameter code field. 💖
The following parameters are allowed in the options part. ✅
7.5.2. Padding 🧵
The padding parameter is used to stretch the PDU header out to a convenient size (see Clause 6.12). 🛏️
Parameter Code: 1100 1100
Parameter Length: variable
Parameter Value: any value is allowed7.5.3. Security 🔐
This parameter lets you assign a unique and unambiguous security level 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
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally UniqueThe 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" means the remaining octets of the parameter value field specify a security level that is unique and unambiguous within the security classification system used by the authority responsible for assigning the source NSAP Address. 🧠
7.5.3.2. Destination Address Specific 🎯
The Security Format Code value of binary "10" means the remaining octets of the parameter value field specify a security level that is unique and unambiguous within the security classification system used by the authority responsible for assigning the destination NSAP Address. 💌
7.5.3.3. Globally Unique Security 🌍
Okay so the Security Format Code value of binary "11" 🔐 means the remaining octets of the parameter value field spell out a globally unique and unambiguous security level. This security classification system is not specified in this Standard, so you'll have to look elsewhere for the details 🙈✨
7.5.4 Source Routing 🗺️
The source routing parameter tells you the route to take from the Source Network Address to the Destination Network Address, either completely or partially 💅
- Parameter Code:
1100 0101 - Parameter Length: variable
- Parameter Value: 2 octets of control information, followed 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 it means:
0000 0000 partial source routing
0000 0001 complete source routing
<all other values reserved>The second octet is the octet offset of the next network-entity title entry to be processed in the list. It's relative to the start of the parameter, so a value of three (3) means the next entry starts right after this control octet. Each successive octet gets a correspondingly larger value 🦋
The third octet begins the network-entity title list 📜 The list is made of variable-length network-entity title entries. The first octet of each entry gives the length of the network-entity title that makes up the rest of that entry 💖
7.5.5 Recording of Route 🧾
The recording of route parameter shows the route of the intermediate systems that the PDU has gone through 🛤️
- Parameter Code:
1100 1011 - Parameter Length: variable
- Parameter Value: 2 octets of control information, followed by a concatenation of ordered network-entity title entries (ordered from destination to source)
The first octet of the parameter value is the type code, and it means:
0000 0000 Partial Recording of Route in progress
0000 0001 Complete Recording of Route in progress
<all other values reserved>The second octet points to the first octet that isn't currently used for a recorded network-entity title, which also marks the end of the list 🏁 It's encoded relative to the start of the parameter value, so a value of three (3) means no network-entity titles have been recorded yet. A value of all ones means route recording has been terminated 🙅♀️
The third octet begins the network-entity title list 📜 The list is made of variable-length network-entity title entries. The first octet of each entry says how long the network-entity title is, which is the rest of that entry. New entries always go at the beginning of the list, so the most recently added entry starts in the third octet of the parameter value ✨
Note: The length of the Record Route parameter is set by the originator of the PDU and doesn't change during the lifetime of the PDU. So the Record Route function never changes the length of the header 🫶
7.5.6 Quality of Service Maintenance 🌈
The Quality of Service parameter carries information about the quality of service that the originating Network Service user asked for 💜 Network-entities in intermediate systems MAY make use of this information to help pick a route, but they are not required to. This only matters when more than one route meets the other routing criteria and those routes are known to differ in 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, as shown below.
QoS Format Type of QoS
Code Field
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally UniqueThe 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" means the remaining octets of the parameter value field specify a QoS that is unique and unambiguous in the context of the QoS Maintenance system used 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" means the remaining octets of the parameter value field specify a QoS that is unique and unambiguous in the context of the QoS Maintenance system used 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" means the remainder of the parameter value field specifies a globally unique QoS Maintenance field 🔥 When the globally unique QoS Maintenance function is used, the parameter value field MUST have a total length of one octet. That octet gets the following values:
Bits 8 and 7: QoS Format Code of binary "11"
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. costBit 5 set to one means that, where possible, routing decisions SHOULD favor sending all PDUs to the specified destination NSAP address over a single path (to keep them in sequence) instead of minimizing transit delay 🧵 A value of zero (0) means that, where possible, routing decisions SHOULD favor low transit delay over keeping sequence 🏎️
Bit 4 is set to zero by the network-entity that originates the protocol data unit 🌱 An intermediate system sets it to one to show that this PDU has passed through a congested intermediate system, and appropriate action SHOULD be taken by the destination network-entity 🚨 Once an intermediate system has set the congestion experienced bit, no later intermediate system along the path to the destination may reset it 🔒
Bit 3 set to one means that, where possible, routing decisions SHOULD favor low transit delay over low cost 💸 A value of 0 means routing decisions SHOULD favor low cost over low transit delay 🪙
Bit 2 set to one means that, where possible, routing decisions SHOULD favor low residual error probability over low transit delay 💎 A value of zero means routing decisions SHOULD favor low transit delay over low residual error probability ⚡
Bit 1 set to one means that, where possible, routing decisions SHOULD favor low residual error probability over low cost 🛡️ A value of 0 means routing decisions SHOULD favor low cost over low residual error probability 🤑
7.5.7 Priority 🚀
The value of the Priority parameter shows the relative priority of the protocol data unit 👑 Intermediate systems that support this option SHALL make use of this information when routing and when ordering PDUs for transmission 🏃♀️
- Parameter Code:
1100 1101 - Parameter Length: one octet
- Parameter Value:
0000 0000(Normal, the default) through0000 1110(Highest)<all other values reserved>
The values 0000 0001 through 0000 1110 are meant for higher priority protocol data units 💖 If an intermediate system doesn't support 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 an ordered multiple of octets. It's the same ordered multiple of octets specified for the NS-Userdata parameter of the N-UNITDATA Request and Indication primitives 📦 The data field is shown in Figure 8:
Octet
___________________________________________________
| | p + 1
: Data :
| | z
|__________________________________________________|
Figure 8: PDU Header -- Data Field7.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 PDU7.7.1.1 Fixed Part 🎀
Okay bestie, so these eight fields are the fixed part we already know and love 💅 Each one just points back to the clause where its encoding lives 🧚
Network Layer Protocol Identifier— See Clause 7.2.2Length Indicator— See Clause 7.2.3Version/Protocol Id Extension— See Clause 7.2.4Lifetime— See Clause 7.2.5SP, MS, E/R— See Clause 7.2.6Type Code— See Clause 7.2.7Segment Length— See Clause 7.2.8Checksum— See Clause 7.2.9
7.7.1.2 Addresses 🏡
Addresses are handled in Clause 7.3, so go check that out 🦋
7.7.1.3 Segmentation 🧩
Segmentation has its own home in Clause 7.4 💖
7.7.1.4 Options 🎀
Options are covered in Clause 7.5 ✨
7.7.1.5 Data 🍓
Data is covered in Clause 7.7 🫶
7.8 Inactive Network Layer Protocol 🌙
Okay, this one is giving "quiet but important" vibes 🙈 Here's how it's laid out:
Octet
____________________________________
|Network Layer Protocol Identifier | 1
|__________________________________|
| | 2
| Data |
| | 2 - n
|__________________________________|
Figure 10: Inactive Network Layer Protocol7.8.1 Network Layer Protocol Id 🔢
The Network Layer Protocol Identifier field is set to binary zero (0000 0000). Literally just zeros, no cap 😭
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). So the length has to stay within that limit, periodt 💅
7.9 Error Report PDU (ER) 🚨
This is the one that tells the sender something went wrong 😳 Let's get into the format 👑
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 PDU7.9.1.1 Fixed Part 🧁
The fixed part of the Error Report Protocol Data Unit is built the same way as a new (Initial) Data PDU, so it's giving déjà vu 🌈 The fields point back to earlier clauses for their encoding:
Network Layer Protocol Identifier— See Clause 7.2.2Length Indicator— See Clause 7.2.3Version/Protocol Id Extension— See Clause 7.2.4Lifetime— See Clause 7.2.5SP, MS, E/R— Always set to zero, (See Clause 6.10)Type Code— See Clause 7.2.7Segment Length— See Clause 7.2.8Checksum— See Clause 7.2.9
7.9.1.2 Addresses 📬
Addresses are in Clause 7.3 🦋
The Destination Address specifies the network-entity title of the originator of the discarded PDU. The Source Address specifies the title of the intermediate-system or end-system network-entity initiating the Error Report PDU. So one address is the one who sent the dropped PDU, and the other is the one raising the alarm 🚨
7.9.1.3 Options 🎀
Options are covered in Clause 7.5 ✨
7.9.1.4 Reason for Discard 💀
This parameter is valid only for the Error Report PDU. It's a whole vibe 😤
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 |7.9.1.5. Error Report Data Field 🎀
Okay so this field is literally the whole header of the discarded Data PDU 💖. It may also hold some or all of that PDU's data field, depending on what's left over ✨.
8. Conformance 💅
Okay, babe, this part decides who gets to be an official conformant implementation 👑. To conform to this International Standard, you need the ability to originate, manipulate, and receive PDUs under the full protocol. The non-segmenting and Inactive Network Layer Protocol subsets don't count here 🙈.
Conformance also means providing the protocol functions described in Clause 6 🌸. The optional functions in Clause 6.18, listed in Table 9-1, must meet the requirements written there 🧚. Exceptions to that are covered in Clause 8.1 below ✨.
On top of that, conformance means following the structure and encoding of PDUs from Clause 7 🦋.
Only if all of the above is met is there conformance to this International Standard. No shortcuts, no cap 🫶.
8.1. Provision of Functions for Conformance 🍓
Here's the table that sorts the Clause 6 functions by the kind of system providing them 🌈. Iykyk, it gets detailed fast 😭.
Note:
- The support of the PDU Composition and Forward PDU functions is necessary for the generation of Error Report PDUs 💜.
- The Segment PDU function is in general mandatory for an intermediate system 🔥. However, a system that is only connected to subnetworks all offering the same maximum SDU size (like identical Local Area Networks) will not need to perform this function, so it doesn't need to implement it 🎀. If this function is not implemented, this shall be stated as part of the specification of the implementation ✨.
- The correct treatment of the padding function requires no processing 🌷. A conforming implementation shall support the function, at least to the extent of ignoring this parameter wherever it may appear 🫧.
- 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 PDU shall be discarded. 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 🚨.
- 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 🎀
📦 where this page comes from
- ietf: rfc994 1986-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms