RFC 995
End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473
RFC 995: End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 🎀
Okay bestie, so this one is dated April 1986 and it's filed under the Network Working Group as RFC 995. But it's really a joint paper from two standards crews: ANSI X3S3.3 (doc 86-118) and ISO TC97/SC6/N 4053. The source is SC6/WG2, Project 97.6.41 💅. No individual authors are named in this block, and the front matter doesn't list a category, or say what it obsoletes or updates, so I'm not going to guess 🙈.
This document is a progression of SC6/N3862, edited to incorporate member body comments and discussion at the Florence meeting of SC6/WG2. Pursuant to Recommendation 5 of that meeting, comments from member bodies on this revision text are requested for discussion at the Tokyo meeting of SC6 and WGs.
______________________________________________________________________
| |
| ISO/TC 97/SC 6 |
| TELECOMMUNICATIONS AND INFORMATION |
| EXCHANGE BETWEEN SYSTEMS |
| Secretariat: USA (ANSI) |
| |
| |
|_____________________________________________________________________|Here's the full contents list too, so you can see where everything lives 🗺️✨
Contents
1 Introduction 5
2 Scope and Field of Application 6
3 References 7
SECTION ONE. GENERAL 9
4 Definitions 9
4.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9
4.2 Network Layer Architecture Definitions . . . . . . . . . . . 9
4.3 Network Layer Addressing Definitions . . . . . . . . . . . . 9
4.4 Local Area Network Definitions . . . . . . . . . . . . . . . 10
4.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10
5 Symbols and Abbreviations 10
5.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 10
5.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 10
5.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Overview of the Protocol 11
6.1 Information Provided by the Protocol . . . . . . . . . . . . . 11
6.2 Subsets of the Protocol. . . . . . . . . . . . . . . . . . . . 12
6.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4 Underlying Service Assumed by the Protocol . . . . . . . . . 12
6.4.1 Subnetwork Addresses . . . . . . . . . . . . . . . . . 12
6.4.2 Subnetwork User Data . . . . . . . . . . . . . . . . . 13
6.5 Service Assumed from Local Environment . . . . . . . . . . . . 13
6.6 Subnetwork Types . . . . . . . . . . . . . . . . . . . . . . . 14
6.6.1 Point-to-Point Subnetworks . . . . . . . . . . . . . . 15
6.6.2 Broadcast Subnetworks . . . . . . . . . . . . . . . . 15
6.6.3 General Topology Subnetworks . . . . . . . . . . . . . 16
SECTION TWO. SPECIFICATION OF THE PROTOCOL 18
7 Protocol Functions 18
7.1 Protocol Timers . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.1 Configuration Timer . . . . . . . . . . . . . . . . . 18
7.1.2 Holding Timer . . . . . . . . . . . . . . . . . . . . 18
7.2 Report Configuration Function . . . . . . . . . . . . . . . . 18
7.2.1 Report Configuration by End Systems . . . . . . . . . 19
7.2.2 Report Configuration by Intermediate Systems . . . . . 19
7.3 Record Configuration Function . . . . . . . . . . . . . . . . 20
7.4 Flush Old Configuration Function . . . . . . . . . . . . . . 20
7.5 Query Configuration Function . . . . . . . . . . . . . . . . . 20
7.6 Configuration Response Function . . . . . . . . . . . . . . . 21
7.7 Request Redirect Function. . . . . . . . . . . . . . . . . . . 22
7.8 Record Redirect Function . . . . . . . . . . . . . . . . . . . 23
7.9 Refresh Redirect Function . . . . . . . . . . . . . . . . . . 23
7.10 Flush Old Redirect Function . . . . . . . . . . . . . . . . . 24
7.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . 24
7.12 Classification of Functions . . . . . . . . . . . . . . . . . 25
8 Structure and Encoding of PDUs 25
8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2 Fixed Part . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2.1 General . . . . . . . . . . . . . . . . . . . . . . . 26
8.2.2 Network Layer Protocol Identifier . . . . . . . . . . 27
8.2.3 Length Indicator . . . . . . . . . . . . . . . . . . . 27
8.2.4 Version/Protocol Identifier Extension . . . . . . . . 27
8.2.5 Type Code . . . . . . . . . . . . . . . . . . . . . . 28
8.2.6 Holding Time . . . . . . . . . . . . . . . . . . . . . 28
8.2.7 PDU Checksum . . . . . . . . . . . . . . . . . . . . . 28
8.3 Network Address Part . . . . . . . . . . . . . . . . . . . . . 28
8.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.2 NPAI (Network Protocol Address Information) En-
coding . . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.3 Source Address Parameter for ESH PDU . . . . . . . . 29
8.3.4 Network Entity Title Parameter for ISH PDU . . . . . . 29
8.3.5 Destination Address Parameter for RD PDU . . . . . . . 30
8.4 Subnetwork Address Part . . . . . . . . . . . . . . . . . . . 30
8.4.1 Subnetwork Address Parameter for RD PDU . . . . . . . 31
8.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 31
8.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . 32
8.5.3 Quality of Service Maintenance . . . . . . . . . . . . 33
8.5.4 Priority . . . . . . . . . . . . . . . . . . . . . . . 33
8.6 End System Hello (ESH) PDU . . . . . . . . . . . . . . . . . . 34
8.6.1 Structure . . . . . . . . . . . . . . . . . . . . . . 34
8.7 Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 35
8.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 35
8.8 Redirect (RD) PDU. . . . . . . . . . . . . . . . . . . . . . . 36
8.8.1 Structure . . . . . . . . . . . . . . . . . . . . . . 36
9 Formal Description 37
10 Conformance 37
ANNEX A. SUPPORTING TECHNICAL MATERIAL 38
A.1 Use of Timers . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1.1 Example of Holding Time for Route Redirection . . . . 38
A.1.2 Example of Holding Timer for Configuration Informa-
tion . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 Refresh and timeout of Redirection information . . . . . . . . 39
A.3 System Initialization Considerations . . . . . . . . . . . . . 40
A.4 Optimizations for Flushing Redirects . . . . . . . . . . . . 41
List of Tables
1 Service Primitives for Underlying Service . . . . . . . . . . 12
2 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . 14
3 Categories of Protocol Functions . . . . . . . . . . . . . . . 25
4 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . 28
List of Figures
1 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . 27
2 Address Parameters . . . . . . . . . . . . . . . . . . . . . 29
3 ESH PDU - Network Address Part . . . . . . . . . . . . . . . 29
4 ISH PDU - Network Address Part . . . . . . . . . . . . . . . . 30
5 RD PDU - Network Address Part . . . . . . . . . . . . . . . . 30
6 ESH PDU - Address Part . . . . . . . . . . . . . . . . . . . 31
7 All PDUs - Options Part . . . . . . . . . . . . . . . . . . . 31
8 Encoding of Option Parameters . . . . . . . . . . . . . . . . 32
9 ESH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 34
10 ISH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 35
11 RD PDU Format when Redirect is to an IS . . . . . . . . . . . 36
12 RD PDU Format when Redirect is to an ES . . . . . . . . . . . 371. Introduction 🧚
Okay so this Protocol is one of a set of International Standards made to help open systems interconnect, and that set covers the services and protocols required to make it happen 🔗.
It sits among related standards by the layers in the Reference Model for Open System Interconnection (ISO 7498) and by the structure in the Internal Organization of the Network Layer (DIS 8648). The main point is that it's a protocol of the Network Layer 💅. It lets End Systems and Intermediate Systems swap configuration and routing information, which keeps the routing and relaying functions of the Network Layer running smoothly 🦋.
Here's the tea: the parts of Network Layer routing about end systems and intermediate systems on the same subnetwork are mostly separable from the parts about intermediate systems linking multiple subnetworks. This protocol only handles the former 🌸. It'll get a big glow-up when an additional protocol that swaps routing information among intermediate systems works alongside it, but it's useful whether or not that other protocol is available ✨.
This protocol provides solutions for the following practical problems:
- How do end systems discover the existence and reachability of intermediate systems that can route NPDUs to destinations on subnetworks other than the one(s) to which the end system is directly connected?
- How do end systems discover the existence and reachability of other end systems on the same subnetwork (when direct examination of the destination NSAP address does not provide information about the destination subnetwork)?
- How do intermediate systems discover the existence and reachability of end systems on each of the subnetworks to which they are directly connected?
(part 1 of 9 💖 more coming!)
- How do end systems decide which intermediate system to use to forward NPDUs to a particular destination when more than one intermediate system is accessible? 🤔
Okay so the protocol makes two assumptions, bestie:
- Routing to a specified subnetwork point of attachment address (SNPA) on the same subnetwork is carried out satisfactorily by the subnetwork itself. 🦋
- The subnetwork is not, however, capable of routing on a global basis using the NSAP address alone to achieve communication with a requested destination. 💀
Note: Consequently, it is not possible to use Application Layer communication to carry out the functions of this protocol. 🙈
The protocol is connectionless, and it's designed to:
- minimize the amount of a priori state information needed by end systems before they can begin to communicate with other end systems; ✨
- minimize the amount of memory needed to store routing information in end systems; and 🧠
- minimize the computational complexity of end system routing algorithms. 💅
The protocol is also designed to operate in close conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473). 🎀 Since routing styles are usually closely related to communication styles, the information that this protocol provides to end systems and intermediate systems may or may not be appropriate information for supporting routing functions when a Network Layer protocol other than ISO 8473 is used. 🌈
2. Scope and Field of Application ✨
This International Standard specifies a protocol which is used by Network Layer entities operating ISO 8473 in End Systems and Intermediate Systems (referred to herein as ES and IS respectively) to maintain routing information. 🗺️ The Protocol herein described relies upon the provision of a connectionless-mode underlying service.
This Standard specifies:
- a) procedures for the transmission of configuration and routing information between network entities residing in End Systems and network entities residing in Intermediate Systems;
- b) the encoding of the protocol data units used for the transmission of the configuration and routing information;
- c) procedures for the correct interpretation of protocol control information; and
- d) the functional requirements for implementations claiming conformance to this Standard.
The procedures are defined in terms of:
- a) the interactions between End System and Intermediate System network entities through the exchange of protocol data units; and
- b) the interactions between a network entity and an underlying service provider through the exchange of subnetwork service primitives.
This protocol does not specify any protocol elements or algorithms for facilitating routing and relaying among Intermediate Systems. Such functions are intentionally beyond the scope of this protocol. 🙅♀️
3. References 📚
ISO 7498 Information Processing Systems --- Open Systems Intercon-
nection - Basic Reference Model
DIS 7498/DAD1 Information Processing Systems --- Open Systems Intercon-
nection - 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
Network Service Definition Covering Connectionless-mode
Transmission
ISO 8348/AD2 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Addendum to the
Network Service Definition Covering Network Layer Address-
ing
ISO 8473 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Protocol for Pro-
viding the Connectionless Network Service
DIS 8648 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Internal Organiza-
tion of the Network Layer
SC21/N965 OSI Management Framework --- Seventh Working Draft
DIS 8802 Local Area NetworksSECTION ONE. GENERAL 🌸
4. Definitions 💖
4.1. Reference Model Definitions
This document makes use of the following concepts defined in ISO 7498:
- (a) Network layer
- (b) Network service access point
- (c) Network service access point address
- (d) Network entity
- (e) Routing
- (f) Network protocol
- (g) Network relay
- (h) Network protocol data unit
4.2. Network Layer Architecture Definitions
This document makes use of the following concepts from DIS 8648, Internal Organization of the Network Layer:
- (a) Subnetwork
- (b) End System
- (c) Intermediate System
- (d) Subnetwork Service
- (e) Subnetwork Access Protocol
- (f) Subnetwork Independent Convergence Protocol
4.3. Network Layer Addressing Definitions
This document makes use of the following concepts from DIS 8348/DAD2, Addendum to the Network Service Definition Covering Network Layer Addressing:
- (a) Subnetwork address
- (b) Subnetwork point of attachment
4.4. Local Area Network Definitions
This document makes use of the following concepts from DIS 8802, Local Area Networks:
- (a) multicast address
- (b) broadcast medium
4.5. Additional Definitions
For the purposes of this document, the following definitions apply:
Configuration: The collection of End and Intermediate Systems attached to a single subnetwork, defined in terms of the system types, NSAP addresses present, Network Entities present, and the correspondence between systems and SNPA addresses. 🧩
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. 🪪
5. Symbols and Abbreviations 🔤
5.1. Data Units
PDU Protocol Data Unit
SNSDU Subnetwork Service Data Unit5.2. Protocol Data Units
ESH PDU End System Hello Protocol Data Unit
ISH PDU Intermediate System Hello Protocol Data Unit
RD PDU Redirect Protocol Data Unit5.3. Protocol Data Unit Fields
NPID Network Layer Protocol Identifier
LI Length Indicator
V/P Version/Protocol Identifier Extension
TP Type
CS Checksum
NETL Network entity Title Length
NET Network entity Title
DAL Destination Address Length
DA Destination Address
SAL Source Address Length
SA Source Address
BSNPAL SN Address Length of better route to destination
BSNPA SN Address of better route to destination
HT Holding timer5.4. Parameters
CT Configuration Timer
RT Redirect Timer5.5. Miscellaneous
ES End System
IS Intermediate System
SN Subnetwork
SNACP Subnetwork Access Protocol
SNICP Subnetwork Independent Convergence Protocol6. Overview of the Protocol 🦋
6.1. Information Provided by the Protocol
This Protocol provides two types of information to Network entities which support its operation:
- a) Configuration Information, and
- b) Route Redirection Information
Configuration Information permits End Systems to discover the existence and reachability of Intermediate Systems and permits Intermediate Systems to discover the existence and reachability of End Systems. This information allows ESs and ISs attached to the same subnetwork to dynamically discover each other's existence and availability, thus eliminating the need for manual intervention at ESs and ISs to establish the identity of Network entities that can be used to route NPDUs. 🔍
Configuration Information also permits End Systems to obtain information about each other in the absence of an available Intermediate System. 🤝
Note: The term "configuration information" is not intended in the broad sense of configuration as used in the context of OSI system management. Rather, only the functions specifically defined herein are intended.
Route Redirection Information allows Intermediate Systems to inform End Systems of (potentially) better paths to use when forwarding NPDUs to a particular destination. A better path could either be another IS on the same subnetwork as the ES, or the destination ES itself, if it is on the same subnetwork as the source ES. Allowing the ISs to inform the ESs of routes minimizes the complexity of routing decisions in End Systems and improves performance because the ESs may make use of the better IS or local subnetwork access for subsequent transmissions. 🚀
6.2. Subsets of the Protocol
A Network Entity may choose to support either the Configuration Information, the Route Redirection Information, neither, or both. If the Configuration Information is supported, it is not required that it be employed over all subnetworks to which the Network entity is attached. 🎈
6.3. Addressing
The Source Address and Destination Address parameters referred to in this International Standard are OSI Network Service Access Point Addresses. The syntax and semantics of an OSI Network Service Access Point Address are described in a separate document, ISO 8348/DAD2, Addendum to the Network Service Definition covering Network Layer Addressing. 📬
6.4. Underlying Service Assumed by the Protocol
The underlying service required to support this protocol is defined by the primitives in Table 1. 🧾
_________________________________________________________________
| SN_UNITDATA .Request | SN_Destination_Address, |
| .Indication | SN_Source_Address, |
| | SN_Quality_of_Service, |
| | SN_Userdata |
|_____________________________________|_________________________|
Table 1: Service Primitives for Underlying ServiceNote: These service primitives are used to describe the abstract interface which exists between the 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.
6.4.1. Subnetwork Addresses ✨
okay so the source and destination addresses name the points of attachment to whichever public or private subnetwork(s) get involved in moving the data 🦋 these are called Subnetwork Points of Attachment, or SNPAs!!
the actual subnetwork addresses are defined in the Service Definition of each individual subnetwork, so go check there 💅 this protocol is designed to take advantage of subnetworks that support broadcast, multicast, or other forms of multi-destination addressing for n-way transmission 🔥 it's assumed that the SN_Destination_Address parameter can take on one of these multi-destination addresses, in addition to a normal single destination address:
- All End System Network entities
- All Intermediate System Network entities
if a real subnetwork doesn't natively do broadcast or other multi-destination transmission, a convergence function may be used to provide n-way transmission to those addresses 🌈
when the SN_Destination_Address on the SN_UNITDATA.Request is a multi-destination address, the SN_Destination_Address parameter in the matching SN_UNITDATA.Indication shall be that same multi-destination address 💜
and apart from those properties above, the syntax and semantics of subnetwork addresses are not defined in this Protocol Standard 🙈
6.4.2. Subnetwork User Data
the SN_Userdata is an ordered multiple of octets, and it gets transferred transparently between the specified subnetwork points of attachment 🎀
the underlying service is required to support a service data unit size of at least what's needed to operate the Protocol for Providing the Connectionless Network Service (ISO 8473) 🍓
6.5. Service Assumed from Local Environment
a timer service must be provided so the protocol entity can schedule events ⏰ main character energy 👑
there are three primitives for 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 with the given name and subscript, and keep it running for the duration in the time parameter ⏳
the S--TIMER Response primitive is initiated by the local environment to say the delay requested by the matching S-TIMER Request has elapsed 🧚
the S--TIMER Cancel primitive is basically telling the local environment to cancel the specified timer(s) 🙅♀️ if the subscript parameter isn't specified, then every timer with that name gets canceled. otherwise, only the timer with that exact name and subscript gets canceled. and if no timers match the parameters, the local environment takes no action 💀
the parameters of the S--TIMER service primitives are listed in Table 2 🌸
___________________________________________
| | |
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|__________________________|_______________|Table 2: Timer Primitives
the time parameter tells you how long the specified timer lasts ⌛ an identifying label is attached to a timer through the name parameter, and the subscript parameter distinguishes timers that share the same name. together, the name and subscript form a unique reference to the 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. 💖
6.6. Subnetwork Types
to figure out whether this protocol fits a particular setup of End Systems, Intermediate Systems, and subnetworks, three generic types of subnetwork are identified 🌈
- the point-to-point subnetwork,
- the broadcast subnetwork, and
- the general topology subnetwork
these get discussed in the following clauses ✨
6.6.1. Point-to-Point Subnetworks
a point-to-point subnetwork supports exactly two systems. those two can be two End Systems, or an End System and a single Intermediate System. one single point-to-point data link connecting two Network Entities is an example of this 🎀
Configuration Information on a point-to-point Subnetwork. on a point-to-point subnetwork, the Configuration Information of this protocol tells the communicating Network entities:
- whether the topology consists only of two End Systems, or
- whether one of the two systems is an Intermediate System.
Note: On a point-to-point subnetwork, if both systems are Intermediate Systems, then this protocol is inapplicable to the situation, since an IS-to-IS protocol should be employed instead. However, there is no reason why the configuration information could not be employed in an IS-to-IS environment to ascertain the topology and initiate operation of an IS-to-IS protocol. 🙈
the Intermediate System gets told the NSAP address(es) supported by the Network entity in the End System 🫶 this lets reachability information and routing metrics about those NSAPs be disseminated to other Intermediate Systems, so they can calculate routes to and from this End System.
Route Redirection Information on a point-to-point Subnetwork. Route Redirection Information is not employed on point-to-point subnetworks, because there are never any alternate routes 🙅♀️
6.6.2. Broadcast Subnetworks
a broadcast subnetwork supports an arbitrary number of End Systems and Intermediate Systems. it's also capable of transmitting a single SNPDU to all of these systems, or a subset of them, in response to a single SN_UNITDATA.Request 📣 an example is a LAN (local area network) conforming to DIS8802/2, type 1 operation 🍓
Configuration Information on a broadcast Subnetwork. on a broadcast subnetwork, the Configuration Information of this protocol is used to tell the communicating Network entities:
- End Systems are informed of the reachability, Network entity Title, and SNPA address(es) of each active Intermediate System on the subnetwork.
- Intermediate Systems are informed of the NSAP addresses supported by each End System, and the Subnetwork address of the ES. once the Intermediate System has this information, reachability information and routing metrics about these NSAPs may be disseminated to other ISs, so they can calculate routes to and from each ES on the subnetwork 🧠
- in the absence of an available Intermediate System, End Systems may query over a broadcast subnetwork to find out whether a particular NSAP is reachable on the subnetwork and, if so, which SNPA address to use to reach that NSAP 🔎
Route Redirection Information on broadcast Subnetworks. Route Redirection Information may be employed on broadcast subnetworks to let Intermediate Systems tell End Systems about superior routes to a destination NSAP 👑 the superior route might be another IS on the same subnetwork as the ES, or it might be the destination ES itself, if that ES is directly reachable on the same subnetwork as the source ES 💜
6.6.3 General Topology Subnetworks ✨
okay bestie, a general topology subnetwork supports an arbitrary number of End Systems and Intermediate Systems 🌐 but it does not have a convenient multidestination connectionless transmission facility like a broadcast subnetwork does. an example is a subnetwork using X.25 or ISO 8208 💅
Note: the crucial difference between a broadcast subnetwork and a general topology subnetwork is the "cost" of an n-way transmission to a potentially large subset of the systems on the subnetwork. on a general topology subnetwork, the cost is assumed to be close to the cost of sending an individual PDU to each SNPA on the subnetwork. on a broadcast subnetwork, the cost is assumed to be close to the cost of sending a single PDU to one SNPA on the subnetwork. intermediate situations between these extremes are of course possible. in those cases, it would be possible to treat the subnetwork as either in the broadcast or general topology categories.
Configuration Information on a general topology subnetwork. on a general topology subnetwork, Configuration Information is generally not employed, because this protocol can be very costly in the utilization (and charging for) of subnetwork resources. 🙈
Route Redirection Information on a general topology subnetwork. Route Redirection Information may be employed on general topology subnetworks to permit Intermediate Systems to inform End Systems of superior routes to a destination NSAP. the superior route might be another IS on the same subnetwork as the ES, or it might be the destination ES itself, if it is directly reachable on the same subnetwork as the source ES. main character energy 🦋
SECTION TWO. SPECIFICATION OF THE PROTOCOL 🎀
7 Protocol Functions 💖
This section describes the functions performed as part of the Protocol. not all of the functions must be performed by every implementation. Clause 7.12 specifies which functions may be omitted and the correct behavior where requested functions are not implemented.
7.1 Protocol Timers ⏰
many of the protocol functions are timer based. this means that they are executed upon expiration of a timer rather than upon receipt of a PDU or invocation of a service primitive. the two major types of timers employed by the protocol are the Configuration Timer (CT) and the Holding Timer (HT).
7.1.1 Configuration Timer
The Configuration Timer is a local timer (i.e. maintained independently by each system) which performs the Report Configuration function (see section 7.2). the timer determines how often a system reports its availability to the other systems on the same subnetwork. the shorter the Configuration Timer, the more quickly other systems on the subnetwork will become aware when the reporting system becomes available or unavailable. the increased responsiveness must be traded off against increased use of resources in the subnetwork and in the recipient systems. it's a balancing act, bestie ⚖️
7.1.2 Holding Timer
The Holding Timer applies to both Configuration Information and Route Redirection Information. the value of the Holding Timer is set by the source of the information and transmitted in the appropriate PDU. the recipient of the information is expected to retain the information no longer than the Holding Timer. Old Configuration or Route Redirection information must be discarded after the Holding Timer expires to ensure the correct operation of the protocol. 🚫
further discussion of the rationale for these timers and guidelines for their use may be found in annex 10. 📚
7.2 Report Configuration Function 📣
The Report Configuration Function is used by End Systems and Intermediate Systems to inform each other of their reachability and current subnetwork address. this function is invoked every time the local Configuration Timer (CT) expires in an ES or IS. it is also invoked upon receipt of a Query Configuration PDU from another End System.
7.2.1 Report Configuration by End Systems
An End System constructs and transmits one ESH PDU (ESH stands for "End System Hello") for each NSAP it serves, and issues one SN_UNITDATA.Request with the ESH PDU as the SNSDU on each subnetwork to which it is attached. 🌸
Note: the necessity to transmit a separate ESH PDU for each NSAP served by the Network entity arises from the lack of a formalized relationship between Network Entity Titles and NSAP addresses. if this relationship could be constrained to require that all NSAP addresses be assigned as leaf subdomains of a domain represented by the local Network entity's Network entity Title, then a single ESH PDU could be transmitted containing the ESs Network entity Title. the Network entity Title would then imply which NSAPs might be present at that End system.
The Holding Timer (HT) field is set to approximately twice the ESs Configuration Timer (CT) parameter. this variable is set to a value large enough so that even if every other ESH PDU is discarded (due to lack of resources), or otherwise lost in the subnetwork, the configuration information will still be maintained. the value must be set small enough so that Intermediate Systems can respond in a timely fashion to End Systems becoming available or unavailable. ⏳
The SN_Destination_Address parameter is set to the group address that indicates "All Intermediate System Network Entities". this ensures that a single transmission on a broadcast subnetwork will reach all of the active Intermediate Systems. 💜
Note: the actual value of the SN_Destination_Address used to mean "All Intermediate System Network Entities" is subnetwork dependent and will most likely vary from subnetwork to subnetwork. it would of course be desirable that on widely-used subnetwork types (such as those based on DIS 8802) this value and the value of the "All End System Network Entities" group address be standardized.
7.2.2 Report Configuration by Intermediate Systems
An Intermediate System constructs a single ISH PDU (ISH stands for "Intermediate System Hello") containing the ISs Network Entity Title and issues one SN_UNITDATA.Request with the ISH PDU as the SNSDU on each subnetwork to which it is attached. 🧚
The Holding Timer (HT) field is set to approximately twice the Intermediate System's Configuration Timer (CT) parameter. this variable is set to a value large enough so that even if every other ISH PDU is discarded (due to lack of resources), or otherwise lost in the subnetwork, the configuration information will still be maintained. the value must be set small enough so that End Systems will quickly cease to use ISs that have failed, thus preventing "black holes" in the Network. 🕳️
The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities". this ensures that a single transmission on a broadcast subnetwork will reach all of the active End Systems. 🫶
7.3 Record Configuration Function 🗂️
The Record Configuration function receives ESH or ISH PDUs, extracts the configuration information, and adds or replaces the corresponding configuration information in the local Network entity's Routing Information base. if insufficient space is available to store new configuration information, the PDU is discarded. No Error Report is generated. 😬
Note: the protocol is described such that End Systems receive and record only ISH PDUs and Intermediate Systems receive and process only ESH PDUs. if an ES so desires, however, it may decide to process ESH PDUs as well (on a broadcast network this is easily done by enabling the appropriate group address). there is potentially some performance improvement to be gained by doing this, at the expense of extra memory, and possibly extra processing cycles in the End System. the ES, by recording other ESs' Configuration information, may be able to route NPDUs directly to ESs on the local subnetwork without first being redirected by a Intermediate System. Similarly, Intermediate Systems may choose to receive the ISH PDUs of other ISs, allowing this protocol to be used as the initialization and topology maintenance portion of a full IS-to-IS routing protocol. Both of these possibilities are for further study. 🔮
7.4 Flush Old Configuration Function 🧹
The Flush Old Configuration Function is executed to remove Configuration entries in the routing information base whose Holding Timer has expired. when the Holding Time for an ES or IS expires, this function removes the corresponding entry from the routing information base of the local Network Entity. bye bye, old info 👋
7.5 Query Configuration Function 🔍
The Query Configuration Function is performed under the following circumstances:
- The End System is attached to a broadcast subnetwork,
- There is no Intermediate System currently reachable on the subnetwork (i.e. no ISH PDUs have been received since the last information was flushed by the Flush Old Configuration Function),
- The Network Layer's Route PDU Function needs to obtain the SNPA address to which to forward a PDU destined for a certain NSAP, and
- The SNPA address cannot be obtained either by a local transformation or a local table lookup.
Note: despite appearances, this is actually a quite common case, since it is likely that there will be numerous isolated Local Area Networks without Intermediate Systems to rely upon for obtaining routing information (e.g. via the Request Redirect Function of this protocol). further, if the Intermediate System(s) are temporarily unavailable, without this capability communication on the local subnetwork would suffer unless manually-entered tables were present in each End System or all NSAPs of the subnetwork had the subnetwork SNPA address embedded in them. 🏝️
The End System, when needing to route an NPDU to a destination NSAP whose SNPA is unknown, issues an SN_UNITDATA.Request with the NPDU as the SN_Userdata. The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities". 📮
Subsequently, an ESH PDU may be received containing the NSAP address along with the corresponding SNPA address (see clause 7.6). In such a case, the End System executes the Record Configuration function for the NSAP, and therefore will be able to route subsequent PDUs to that destination using the specified SNPA. If no ESH PDU is received, the End System may declare the destination NSAP is not reachable. The length of time to wait for a response before indicating a failure, or the possibility of repeating the process some number of times before returning a failure, are local matters and are not specified in this standard. ⏱️
7.6 Configuration Response Function 💬
The Configuration Response function is performed when an End System attached to a broadcast subnetwork receives an NPDU addressed to one of its NSAPs, with the SN_Destination_Address from the SN_UNITDATA.Indication set to the group address "All End System Netowrk Entities". This occurs as a result of another ES having performed the Query Configuration function described in clause 7.5. 🥰
The End System builds an ESH PDU that's identical in content to the one the Report Configuration function makes (see clause 7.2.1) for the NSAP the received NPDU was addressed to 💖 Then it sends that ESH PDU back to whoever sent the original NPDU by issuing an SN_UNITDATA.Request, with SN_Destination_Address set to the SN_Source_Address from the SN_UNITDATA.Indication that came with the original NPDU ✨
7.7 Request Redirect Function 🦋
The Request Redirect Function only lives in Intermediate Systems, and it's super close with their Routing and Relaying Functions 💅 It's coupled with the "Route PDU Function" from clause 6.5 of ISO 8473, and it runs after the Route PDU function has figured out the next hop of the Data PDU's path 🧚
When an Intermediate System is about to forward an NPDU, the Request Redirect Function checks the SN_Source_Address attached to the SN_UNITDATA.Indication that delivered the SNSDU (the one carrying this NPDU) 👀 If that SN_Source_Address isn't from an End System on the local subnetwork (you can tell by looking at the Configuration information from the Record Configuration Function), then this function just does no further processing of the NPDU. Not its job, bestie 🙈
If the NPDU came directly from an ES, the IS checks the output of its Routing and Relaying function for this NPDU. That output will include, among other things, these bits of info:
- a local identifier for the subnetwork to forward the NPDU over, plus either
- the Network entity title and subnetwork address of the IS to forward the NPDU to, or
- the subnetwork address of the destination End System.
Now the Request Redirect function MUST determine whether the source ES could have sent the NPDU straight to the Network entity the Intermediate System is about to forward the PDU to 🔥 If any of the following conditions hold, the source ES SHOULD be told about the "better" path (by sending an RD PDU to the originating ES) 💜
- The next hop is to the destination system, and the destination is directly reachable (at subnetwork address BSNPA) on the source ES's subnetwork, or
- The next hop is to an Intermediate System that's connected to the same subnetwork as the ES.
If the better path exists, the IS first finishes the normal processing of the received NPDU and forwards it 💖 Then it builds a Redirect PDU (RD PDU) that contains the Destination Address of the original NPDU, the subnetwork address of the better next hop (BSNPA), and the Network Entity Title of the IS the ES is being redirected to (unless the redirect is to the destination ES) 🌸 It also carries a Holding Time (HT), plus the QoS Maintenance, Priority, and Security options that were in the Data NPDU (these are just copied over from the Data PDU). The HT gets set to the value of the local Redirect Timer (RT). See Annex A for a discussion of how to choose the value of RT ✨
If there aren't enough resources to both forward the original NPDU and generate and send an RD PDU, the original NPDU MUST be given preference 🫶 Then the Intermediate System (assuming it has enough resources) sends the RD PDU to the source End System, using the SN_Source_Address of the received NPDU as the SN_Destination_Address for the SN_UNITDATA.-Reqeust 🎀
7.8 Record Redirect Function 🌈
The Record Redirect Function only lives in End Systems 🧚 It gets invoked whenever an RD PDU shows up. It pulls out the redirect info and either adds or replaces the matching redirection info in the local Network entity's Routing Information base 📚 The key stuff is the redirection mapping from a Destination Address to a subnetwork address, along with the Priority, Security, and QoS Maintenance options, and the Holding Time that says how long this mapping stays valid ⭐ If the redirect pointed to another Intermediate System, the Network Entity Title of that IS gets recorded too 💅
Note: If there isn't enough memory to store new redirection information, the RD PDU may be safely discarded, since the original Intermediate System will keep forwarding PDUs on behalf of this Network entity anyway 🙈
7.9 Refresh Redirect Function 🌸
The Refresh Redirect Function only lives in End Systems 💜 It gets invoked whenever an NPDU is received by a destination ES. It's super tightly coupled with the function that processes received NPDUs at a destination Network Entity, which is the "PDU Decomposition" function in ISO 8473 🧠 Its whole purpose is to make a redirection last longer without letting an incorrect route stick around forever 🦋 The Source Address (SA), Priority, Security, and QoS options get pulled out and compared against any Destination Address and QoS parameters being kept in the Routing Information base (that info would've been stored by the Record Redirect Function) 💅 If there's a matching entry, the previous hop of the PDU is found from the SN_Source_Address parameter of the SN_Unitdata.Indication primitive it came in on. If that address matches the next hop address stored with the redirection info, the remaining holding time for the redirection gets reset to the original holding timer that came from the RD PDU ✨
Note: The purpose of this function is to avoid timing out redirection entries when the Network entity is receiving return traffic from the destination via the same path it's currently sending traffic over. This is especially useful when the destination system is on the same subnetwork as the source, since after one redirect no IS needs to be involved in the ES-to-ES traffic 🔥 This function MUST operate in a very conservative fashion, though, to prevent the formation of black holes 🕳️ The remaining holding time SHOULD be refreshed only under the exact conditions specified above. For a discussion of the issues around refreshing redirection information, see Annex 10 🎀
7.10 Flush Old Redirect Function 🫧
The Flush Old Redirect Function runs to remove Configuration entries from the routing information base whose Holding Timer has expired 🧹 When the Holding Time for an ES or IS runs out, this function removes the matching entry from the routing information base of the local Network Entity. Bye bye, expired vibes 👋
7.11 PDU Header Error Detection 🔐
The PDU Header Error Detection function protects against Intermediate or End System Network entities failing because of erroneous info in the PDU header 🛡️ It's realized by a checksum computed over the entire PDU header 💖 The checksum gets verified at each point where the PDU is processed. If the checksum calculation fails, the PDU MUST be discarded 💀
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 the following formula work out 🧮
(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 = 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 🙃
7.12 Classification of Functions 🗂️
Implementations don't have to support all of the functions described in clause 7 🌷 The functions are split into four categories:
Type A: These functions MUST be supported in all cases. 💜
Type B: These functions MUST be supported by Systems which implement the Configuration Information. 🎀
Type C: These functions MUST be supported by Systems which implement the Redirect Information. 🌸
Type D: These functions are OPTIONAL. 🫶
If a PDU comes in that invokes an OPTIONAL function that isn't implemented, that PDU is discarded 🗑️
Table 3 shows how the functions are split into these four categories, and which type of system (ES, IS, or both) they apply to 📊
______________________________________________________________
| Function | Category | System Type |
|_______________________________|____________|_______________|
| Report Configuration | B | ES,IS |
| Record Configuration | B | ES,IS |
| Configuration Response | A | ES |
| Flush Old Configuration | B | ES,IS |
| Request Redirect | C | IS |
| Query Configuration | B | ES |
| Record Redirect | C | ES |
| Refresh Redirect | D | ES |
| Flush Old Redirect | C | ES |
| PDU Header Error Detection | A | ES,IS |
|_______________________________|____________|_______________|
Table 3: Categories of Protocol Functions8 Structure and Encoding of PDUs 🧩
Note: The encoding of the PDUs for this protocol is compatible with the one used in ISO 8473 🤝
Temporary Note: The method used for describing the encoding of PDUs is provisional. Member bodies are requested to comment on whether another method (such as ASN.1 with an appropriate concrete syntax) would be preferable 🙏
8.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 put into an SNSDU. The bits in an octet are numbered from one (1) to eight (8), where bit one (1) is the low-order bit 🔢 When consecutive octets are used to represent a binary number, the lower octet number has the most significant value 💖
Any subnetwork 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 🌈
Note: When the encoding of a PDU is represented using a diagram in this section, 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 Network address part;
- the Subnetwork address part, if present; and
- the Options part, if present.
8.2 Fixed Part 🎀
8.2.1 General 🌸
okay so the fixed part is the stuff that shows up in every single PDU, bestie 💅 It holds the frequently used parameters, including the type code (ESH, ISH, or RD) that tells you what kind of PDU you've got. The length and structure of the fixed part depend on the PDU code, so it's not one-size-fits-all ✨
The fixed part looks like this:
Octet
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| reserved (must be zero) | 4
|______________________________________|
| 0 |0 |0 | Type | 5
|___|__|__|____________________________|
| Holding Time | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
Figure 1: PDU Header -- Fixed Part8.2.2 Network Layer Protocol Identifier 🦋
this field shall be 1000 0010. The field is how you know this is the network layer protocol ISO SC6/N4053, the End System to Intermediate System Routing Exchange Protocol, which gets used together with ISO 8473 🔥
Temporary Note: The value 1000 0010 is provisional, pending resolution of the NLPID issue in SC6.
8.2.3 Length Indicator 💜
the length is a binary number, and the biggest it can be is 254 (1111 1110). That number is the length of the whole PDU in octets, and since this protocol doesn't carry user data, the PDU is entirely header 🧚 It's counted the way clause 8.1 describes. The value 255 (1111 1111) is reserved for possible future extensions, so hands off it 🙈
8.2.4 Version/Protocol Identifier Extension 🌈
this field is binary 0000 0001. That identifies a standard version of ISO xxxx, the End System to Intermediate System Routing Exchange Protocol that's used together with ISO 8473 ⭐
8.2.5 Type Code 🍓
the Type code field tells you which type of PDU you're dealing with, and the allowed values are listed in table 4 👑
_____________________________________________________
| | Bits 5 4 3 2 1 |
|____________|______________________________________|
|____________|______________________________________|
|ESH PDU | 0 0 0 1 0 |
|____________|______________________________________|
|ISH PDU | 0 0 1 0 0 |
|____________|______________________________________|
|RD PDU | 0 0 1 1 0 |
|____________|______________________________________|
Table 4: Valid PDU Typesevery other PDU type value is reserved, so those are off-limits for now 💀
8.2.6 Holding Time 🫶
the Holding Time field says how long the receiving Network entity should keep the configuration and routing information carried in this PDU. When the holding time runs out, the receiving Network entity should discard any information it got from this PDU out of its internal state ⏳ The Holding Time field is encoded as an integral number of micro-fortnights 😭
8.2.7 PDU Checksum 🔥
the checksum gets computed over the entire PDU header 🧮 A checksum value of zero is reserved to mean the checksum is to be ignored. The PDU Header Error Detection function (Clause 7.11) makes sure that zero is never a valid checksum, so a non-zero value means the checksum must be processed. And if the checksum calculation fails, the PDU must be discarded, no exceptions bestie 💅
8.3 Network Address Part 🎀
8.3.1 General 🌸
address parameters are told apart by where they sit in the PDU, but different PDU types carry different address parameters. The ESH PDU carries a Source NSAP address (SA). The ISH PDU carries an Intermediate System Network entity Title (NET). The RD PDU carries a Destination NSAP address (DA) and possibly a Network Entity Title (NET) ✨
8.3.2 NPAI (Network Protocol Address Information) Encoding 🦋
the Destination and Source Addresses are Network Service Access Point addresses, as defined in ISO 8348/AD2, the Addendum to the Network Service Definition Covering Network Layer addressing. The Network Entity Title address parameter is defined in clause 4.5. The Destination Address, Source Address, and Network Entity Title all get encoded as NPAI, using the binary syntax from clause 8.3.1 of ISO 8348/AD2 💖
the address information is variable length, and each address parameter is encoded like this:
_______________________________________________
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|________|____________________________________|
| Octets | |
| n + 1 | Address Parameter Value |
| thru | |
| n + m | |
|________|____________________________________|
Figure 2: Address Parameters8.3.3 Source Address Parameter for ESH PDU 🧚
the Source Address is the NSAP address of an NSAP served by the Network entity that's sending the ESH PDU. In the ESH PDU, it's encoded like so 🌈
Octet
________________________________________
|Source Address Length Indicator (SAL) | 10
|______________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|______________________________________|
Figure 3: ESH PDU - Network Address Part8.3.4 Network Entity Title Parameter for ISH PDU 🍓
the Network entity Title parameter is the Network Entity Title of the Intermediate System sending the ISH PDU. In the ISH PDU, it's encoded like this 🫶
Octet
_______________________________________________
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
Figure 4: ISH PDU - Network Address Part8.3.5 Destination Address Parameter for RD PDU 💌
okay so the Destination Address is the NSAP address of a destination linked to some NPDU that the Intermediate System sending the RD PDU is forwarding 🦋 it gets encoded in the RD PDU like this:
Octet
_____________________________________________
|Destination Address Length Indicator (DAL) | 10
|___________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|___________________________________________|Figure 5: RD PDU - Network Address Part
8.4 Subnetwork Address Part 🌸
the Subnetwork Address Part only shows up in RD PDUs, and it's giving very specific vibes 💅 its job is to name the subnetwork address of another Network entity on the same subnetwork as the End System (and Intermediate System). that other entity might be a better path to the destination in the Network Address Part, so it's a whole plot twist 👑 the Subnetwork Address parameter is encoded the same way as the Network Address parameters, no new rules to memorize 🫶
8.4.1 Subnetwork Address Parameter for RD PDU 🧚
the Subnetwork Address Parameter gets encoded in the RD PDU like so:
Octet
_______________________________________________
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (BSNPA) :
| | n - 1
|_____________________________________________|Figure 6: ESH PDU - Address Part
8.5 Options Part 🎀
8.5.1 General 💜
the options part is used to carry optional parameters, and it's the bonus round of the header ✨ the options part of the PDU header looks like this:
Octet
___________________________________________________
| | p
: Options :
| | q
|__________________________________________________|Figure 7: All PDUs - Options Part
if the options part is present, it may contain one or more parameters. how many it can fit depends on 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 on how long each individual optional parameter is 🙈
parameters in the options part can show up in any order 🌈 but duplicate options are not allowed. if a PDU shows up with an option duplicated, that must be treated as a protocol error 😭 yikes
the way each parameter gets encoded inside the options part is shown in figure 8 below 🦋
Octets
_________________________________
| n | Parameter Code |
|____________|__________________|
| n + 1 | Parameter Length |
|____________|__________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|__________________|Figure 8: Encoding of Option Parameters
the parameter code field is binary, and without extensions it gives you a max of 255 different parameters. 💀 no parameter codes use bits 8 and 7 with the value 00, so the real max is lower than that. the code 255 (binary 1111 1111) is saved for possible future extensions, so it's basically reserved royalty 👑
the parameter length field tells you how many octets are in the parameter value field. it's a positive binary number, m, with a theoretical max of 254, but the practical max is lower 🍓 for example, if there's only one parameter in the options part, two octets are needed for the parameter code and the parameter length indicators. so m ends up limited to:
m = 252-(length of fixed part +length of address part
+length of segmentation part )for each parameter after that, the max value of m goes down ⭐ the parameter value field holds the value of whatever parameter the parameter code field points to.
the following parameters are permitted in the options part 🌸
8.5.2 Security 🔥
the Security parameter tells you about the security requested in the Data PDU that caused the containing RD PDU to be generated 🔐 it has the same encoding and semantics as the Security parameter in ISO 8473, so it's giving consistency ✨
Parameter Code: 1100 0101
Parameter Length: variable
Parameter Value: See Section 7.5.3 of ISO 84738.5.3 Quality of Service Maintenance 🌈
the Quality of Service parameter tells you about the quality of service requested in the Data PDU that caused the containing RD PDU to be generated 💖
this parameter has the same encoding and semantics as the QoS Maintenance parameter in ISO 8473, so no surprises here 🫶
Parameter Code: 1100 0011
Parameter Length: variable
Parameter Value: See Section 7.5.6 of ISO 84738.5.4 Priority 🦋
the Priority parameter tells you about the priority requested in the Data PDU that caused the containing RD PDU to be generated, and it's the main character of the options 👑
this parameter has the same encoding and semantics as the Priority parameter in ISO 8473 ✨
Parameter Code: 1100 1101
Parameter Length: one octet
Parameter Value: See Section 7.5.7 of ISO 84738.6 End System Hello (ESH) PDU 🧚
8.6.1 Structure 💅
the ESH PDU has the following format, and honestly the layout is iconic 🎀
Octet
____________________________________________
| Network Layer Protocol Identifier | 1
|__________________________________________|
| Length Indicator | 2
|__________________________________________|
| Version/Protocol Id Extension | 3
|__________________________________________|
| reserved (must be zero) | 4
|__________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|_________________________________|
| Holding Time | 6,7
|__________________________________________|
| Checksum | 8,9
|__________________________________________|
| Source Address Length Indicator (SAL) | 10
|__________________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|__________________________________________|
| | m
: Options :
| | p - 1
|__________________________________________|Figure 9: ESH PDU Format
8.7 Intermediate System Hello (ISH) PDU 🌈
8.7.1 Structure ✨
the ISH PDU has the following format, and it's giving clean and organized energy 🍓
Octet
_______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
| | m
: Options :
| | p - 1
|_____________________________________________|Figure 10: ISH PDU Format
8.8 Redirect (RD) PDU 🦋
8.8.1 Structure 👑
the RD PDU has the following format, and this one's the most dramatic plot twist of them all 💀
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | n
|_____________________________________________|
| | n + 1
: Network Entity Title (NET) :
| | p - 1
|_____________________________________________|
| | p
: Options :
| | q - 1
|_____________________________________________|Figure 11: RD PDU Format when Redirect is to an IS
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
| NETL = 0 | n
|_____________________________________________|
| | n + 1
: Options :
| | p - 1
|_____________________________________________|
| Quality of Service | n + 1
|_____________________________________________|Figure 12: RD PDU Format when Redirect is to an ES 🦋
9. Formal Description ✨
{Maybe next pass...} 🙈 the spec authors literally left themselves a note in the doc, iconic behavior tbh 💀
10. Conformance 💅
See Clause 6.2.
ANNEX A. SUPPORTING TECHNICAL MATERIAL 👑
A.1. Use of Timers ⏰
Okay so this protocol leans really hard on timers to keep the info fresh and accurate when it's being shared for the Configuration and Route Redirection functions. This section explains why those timers exist and gives some background on how they work 🫶
Systems using this protocol only learn about each other by getting the PDUs those systems send. In a connectionless environment, a system has to keep periodically receiving updated information so it can be sure what it got before is still correct. For example, if a system on a subnetwork becomes unavailable (either it has stopped operating, or its SNPA has stopped working), the only way another system can notice is that transmissions from that system stop. If information were kept around without new PDUs arriving, the configuration and/or routing information would eventually go wrong 😭 The Holding Timers defined by this protocol make sure old information can't stick around forever.
Think of the configuration and route redirection info as a cache that each system keeps. The cache gets flushed regularly so only up-to-date info is stored. Unlike most caches, though, how long to keep something isn't a purely local decision. Instead, info is held for a period of time that the source of the information sets. Some examples will help clarify this operation ✨
A.1.1. Example of Holding Time for Route Redirection 🍓
End Systems get Route Redirection Information through the Request Redirect function (see clause 7.7). It's totally possible that an Intermediate System redirects an End System to another IS that just became unavailable (this could happen if the IS-to-IS routing algorithm is still converging after a configuration change). If the Holding Timer weren't there, or the sending IS set it really long, an End System would get redirected into a Black Hole that none of its Data PDUs would ever come out of. Basically, the length of the Holding Timer on Redirects decides how long black holes are allowed to exist. 💀
On the other hand, setting the Holding Timer on Route Redirects super short to minimize black holes has its own downsides. First, every PDU that triggers a redirect means an additional PDU beside the original Data PDU must be composed and transmitted, which adds overhead. Second, whenever a "working" redirect's Holding Timer runs out, the redirected End System falls back to a poorer route for at least one PDU 🙃
A.1.2. Example of Holding Timer for Configuration Information 🧚
A similar problem can happen with Configuration information. If the Holding Time of an ISH PDU (see clause 7.2.2) is set really long, and the only Intermediate System that has been sending this Configuration Information on the subnetwork becomes unavailable, a subnetwork-wide black hole can form. While that's going on, End Systems on the subnetwork may not be able to talk to each other, because they assume an Intermediate System is running that will forward their Data PDUs to destination ESs on the local subnetwork and return RD PDUs. Once the Holding Time expires, the ESs will realize no IS is available and will fall back to their only option, which is sending their traffic directly on the local subnetwork.
Given these kinds of problems, it's important that responsibility for incorrect information can be unambiguously assigned to the source of that information. For this reason, all Holding Timers are calculated by the source of the Configuration or Route Redirection information and communicated explicitly to each recipient in the appropriate PDU 🔥
A.2. Refresh and timeout of Redirection information 🔄
The protocol lets End Systems refresh redirection information without waiting for the holding time to expire and getting redirected by an Intermediate System a second (or later) time. These schemes are common in connectionless subnetworks and are often called "reverse path information", "previous hop cache" or something similar 🦋
Refreshing redirection info is a big performance win, but it can be risky unless it's handled in a very conservative way. For a redirection to be safely refreshed, all of the following conditions must hold:
- The source address of the received PDU must be exactly the same as the destination address specified in a prior RD PDU (this defines a "match" on the redirection information). Making assumptions about the equivalence of abbreviated addresses, group addresses, or similar "special" addresses is dangerous, since routing for these addresses cannot be assumed to be the same.
- The Quality of Service parameters of the received PDU must be exactly the same as the QoS parameters specified in the matching (by destination address) redirection entry. Again, there's no guarantee that PDUs with different QoS parameters will be routed the same way. It's quite possible that the redirected path is even a black hole for certain values of the QoS parameters (the security field is a good example) 👀
- The "previous hop" of the received Data PDU must match the "next hop" stored in the redirection information. Specifically, the SN_Source_Address of the SN_UNITDATA.Indication which received the PDU must match exactly the SN_Destination_Address specified in the redirect to be used for sending traffic via the SN_UNITDATA.Request primitive. This comparison ensures that redirects are refreshed only when the reverse traffic is being received from the same IS (or destination ES) as the forward traffic is being sent through (or to). This check makes certain that redirects are not refreshed just on the basis of traffic being received from the destination. It is quite possible that the traffic is simply indicating that the forward path in use is not working! 🚨
Note that these conditions still allow refresh in the most useful and common cases, where either the destination is another ES on the same subnetwork as the source ES, or the redirection is to an IS that is passing traffic to/from the destination in both directions (i.e. the path is symmetric) 💜
A.3. System Initialization Considerations 🌸
This protocol is designed to keep the exchange of information as free as possible from dependencies between the two types of systems. Therefore, it's not possible for an End System to ask all Intermediate Systems on a subnetwork to report their configuration, nor is it possible for an Intermediate System to ask all End Systems on a subnetwork to report theirs.
In certain operating environments there may be a constraint that an ES, once it becomes operational, must discover the existence of an IS as soon as possible. The converse also holds if it's necessary for an IS to discover the existence of End Systems as soon as possible. In both cases, the availability of this information is normally determined by the Configuration Timer of the system that wants the knowledge. So there's a tradeoff between the overhead of performing the Report and Record Configuration functions and how timely the configuration information is. Decreasing the Configuration Timer increases availability at the cost of more overhead 📈
The following solution is recommended for addressing the constraint described above. When the Record Configuration function is invoked in either an End System or an Intermediate System, the function will determine whether the received configuration information was previously unknown. If so, the Report Configuration function may be invoked before the system's Configuration Timer expires. The Hello PDU generated by the Report Configuration function is then sent only to the Network Entity whose configuration was previously unknown. Thus, when an ES or IS first becomes operational, it immediately reports its configuration. As soon as systems of the other type discover the new network entity, they will make their own configuration known to this entity 🎀
The additional overhead incurred by this solution is minimal. Also, since discovery of new configurations is made timely by this approach, the Configuration Timer period can be increased to decrease the overhead of the configuration functions, provided that other factors not discussed here are accounted for by the longer time period. One caveat is that the first Hello PDU generated by a system may be lost during transmission. To solve this problem, one or more additional PDUs may be transmitted at short time intervals during this initialization period 🧠
Note that this solution may be implemented in ISs only, in ESs only, or in both Intermediate and End Systems. This decision is purely a local matter and may be alterable through System Management 🫧
A.4. Optimizations for Flushing Redirects 🌈
An ES will keep trying to forward NPDUs through an IS it has been redirected to until the Holding Timer from the RD PDU runs out 💅, even if that IS is already unreachable. That's a whole black hole situation 🕳️😭
But it can do better! ✨ Sometimes an ES can spot a black hole much sooner. If the ES expects to hear ISH PDUs from the IS it was redirected to, and the Holding Timer for that IS expires, then all knowledge of that IS may be forgotten by the ES 🧚. That includes any redirects, and those may be flushed (see the Flush Old Redirect function) even though their timeouts haven't expired yet 🫶. Main character energy for the ES, honestly 👑.
📦 where this page comes from
- ietf: rfc995 1986-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms